I'm the author of this piece. I no longer think front-end suffers the instability people accuse it of.
I think there are a lot of _vendors_ trying to usher in a revolution around their particular products - there's a lot of VC funding in JavaScript tooling nowadays - but that's a different problem.
And this is just within React, and off the top of my head. Then you add all the ECMAScript versions, browser feature churn, node.js, npm/yarn, immutability, classes, functional components, hooks, fiber, the list goes on and on.
I've used the same React tech as the basis for most projects for 6 years now. Webpack, Redux, Yarn, React Router, all still popular and maintained. We even used hooks for functional components since then, through the "recompose" library, so there wasn't a big paradigm shift for us.
Anyone who feels compelled to jump from one unproven state management library or bundler to another, in serious projects, is just not doing their due diligence.
> I've used the same React tech as the basis for most projects for 6 years now. Webpack, Redux, Yarn, React Router, all still popular and maintained. We even used hooks for functional components since then, through the "recompose" library, so there wasn't a big paradigm shift for us.
Have you worked at different companies or contributed to different OSS projects in those 6 years? If you have, and they've all been set up exactly the same as what you mentioned, that's rare, but great. I think most people's qualms on the amount of different frontend tooling is based on the fact that almost every company or OSS maintainer takes different approaches to accomplish essentially the same thing.
Not OP. At a big tech company. As far as I can tell neither myself nor anyone I work with has touched a system developed in the past 6 years that didn't use React with with Webpack and/or Esbuild for the build system. Of those, 90%
+ used Redux for state management or switched to Redux after starting with a different state management system like mobx or xstate. The only exception to this the only exceptions are apps that needed something Recoil-like (e.g. Redux caused too much computational overhead). Some of them also used Nextjs for static pages.
I’ve experienced similar thing wrt the build system, but haven’t used redux in all but one of the React projects I’ve worked on as a full time product engineer over the past couple of years.
Yes to both, and I can't say many projects followed a radically different approach, at least without good reason. Webpack and Redux for example are many times more common than something like Parcel or Jotai, so it's rare to encounter many of these alternatives in one project.
These are only the mainstream ones I can remember, there have been a ton more! I guess if you've started post-2018 things have been a bit more stable, but there was quite a bit of churn to get here. And it's still happening - no two React projects are alike even in the enterprise.
That’s because react is a library, and not a framework.
React doesn’t have opinions, that’s why you can find 300 state management libraries and 200 routers which do the same thing, just in different ways.
> That’s because react is a library, and not a framework.
React should be considered a framework.
React absolutely imposes a data model (unidirectional workflow) to the developer thus a certain code structure. The fact that it is light weight compared to Angular doesn't change the fact that React is a front end framework. React usage completely replaces the traditional way to interact with the DOM and manage DOM events, thus abstracting it.
> React doesn’t have opinions,
React becomes very hard to use if your data model isn't organized to suit React architecture.
It doesn't have opinions about everything (like AJAX or SPA routing) but it absolutely has an opinion about how you data objects should be structured.
Indeed, it's unfortunate that React bills itself, in its front-page copy, as a library and not a framework, out of a desire to emphasize its portability and being "lightweight"; but the day-to-day of building a React app is more that of working in a framework than calling library functions.
If you don't know these words you haven't been coding JS long enough. Those like myself who started in 2014 or earlier know all of those and more (anyone still remember shrinkwrap for example)?
Depends HOW you coded. I started JS at 11 yo in 2001, and became fulltime around 2012 - 2 more years of JS than you, I'm your grandaddy in this ever changing mess... I do not know Broccoli either. Googling it: "A fast, reliable asset pipeline, supporting constant-time rebuilds and compact build definitions" I raise my eyes to the ceiling and whine "why the hell isn't there an Oracle or IBM for JS to finally standardize just building crap".
It's probably cause I switched 4 years ago from the typical perma-migration grind to rarely using any framework and coding JS like I code the backend. Simple service classes in pure JS, rare dependencies, simple build. I once ditched years of work by a team of 40 to rewrite "everything" in low level javascript and showed the guys that what we spent all this years writing, really, was useless: did we need that enormous angular runtime config resolver that would draw generic components reading from crafted json configuration ? Or could we just write the damn things as we mean it in... javascript directly ?
Don't use a JS framework as long as you can help it, just the simple fact you can trace the whole function chain in a few seconds, vs reverse engineering the damn VueJS, or React, or Angular (does that monster even exist anymore, we hear about it a lot less than when it was all-encompassing, 8 years ago) plumbing, is worth it.
And son, if you want some war stories from your granddad, have you heard of jQuery ? :D
Very, very few places will let you not use a framework nowadays. There is a ton of cargo culting around JS frameworks and coding vanilla is pretty much heresy land these days. Personal projects? Go for it. Commercial apps built for your employer? Good luck with that. Not only will you be raked over the coals for "reinventing the wheel" you'll also be blamed for any stumble along the way, whether it's related to using vanilla or not.
> if you want some war stories from your granddad, have you heard of jQuery ? :D
Bah, whippernsapper! I cut my baby web teeth on CGI and spent the bulk of it in Struts and JSF. Remember THOSE?
I was "born" after Struts was "obsolete" (so I had my honeymoon phase with Spring/Hibernate until I fixed so many mistakes in companies I decided using smaller surface tools and closer to the metal queries would actually save time) and never touched JSF :D CGI for me is prehistory loool.
However, employers dont need to be involved in choosing a framework or not. You ll notice that usually its the little bees building their resumes that bemoan non stop about migrating from react to vue or vue to react :D
I never heard a sales guy tell me: WHAT, it works fine, is cheap to maintain and has no stupid 10k levels dependency graph in npm ? I ll stop making money on this until you completely "standardize" it into a moving sand on npm. And dont forget a pipeline of 3 transpilers, you wouldnt want to write in a browser-native language, caveman.
I do use requireJS to split in nice files and import easily though I admit.
No I don’t. I was too busy programming ENIAC using patch cables. Grace Hopper once made a snide remark about it after lunch. She smelled like corned beef hash.
It’s true that there are a lot of different ways to do the same thing, but the good news is you’re doing the same thing and the difference is mostly just syntax. Someone who has used Redux extensively can get up and running with Zustand in no time, and vice versa. Likewise React Query and Apollo Client are basically the same thing.
Build tools are a bigger issue, but fortunately most front end devs don’t actually need to deal with them all that often.
Some libraries will create code mods to assist in transitions. For example I've used some MUI codemods in the past to make transitions to newer versions of the library more seamless [1].
There are also codemods to say move from underscore to lodash and vice versa (been a while and can't find them at the moment).
ASTs [2] are pretty cool in this regard. Especially if you write your code in a manner that easier to automate against.
There's people out there who chose PostgreSQL twenty five years ago and found out since to have made the right choice. Not sure if that can be said of any item on the list you were responding to.
I would be thrilled to work someplace that uses neo4j. Such a good graph dbms. Too many folks believe the only way to organize data is with relational tables.
Webpack has been the de facto build system for react since 2017
Competing state libraries is to be expected but picking redux or mobx has let you use the same ones since 2017
JS itself has improved but hasn’t really ever deprecated anything, it just grows and adds terse methods to the language
Npm and yarn are among the best package managers
React hooks were the only major change you’ve touched on but even they didn’t deprecate class based react or change library semantics very significantly
These are not really counterarguments to the fact that things change a lot here, and newcomers and veterans alike need to continuously learn, and pick the best. None of these started off as the default choice, I remember when each and every one of these was the weird / risky option.
They are very much counter arguments to the idea that there is big churn still happening.
Webpack 2 was in CRA in 2017
Redux and MobX have been the #1 and #2 state managements for that whole span, and clearly all the observable libs are successors of MobX after Proxy came out
Every language changes, many with breaking version changed that JS avoids
I don’t know how you’d point at package management as an issue in JS land
It’s just that every single popular community has massive amounts of clones or similar libraries, I don’t know how that qualifies as “churn” though. I maintain my 2017 apps including major version bumps with no issues today, using the same libraries and tools. The argument you’re making was fine in 2016 but is half a decade out of date.
> I maintain my 2017 apps including major version bumps with no issues today
Sorry but I have to call bullshit on that, unless you’re taking about tiny one page “apps”. Webpack alone has gone through five major revisions in this time, with large breaking changes meaning all of your plugins and babel extensions needed upgrading (sometimes not readily available), rewriting the entire config, even before you get to upgrade React and dependencies. React Native has changed massively in this timeframe, I’m talking complete API refactoring and packages moving around, not simple function signature changes.
This is simply not reality for people working tech jobs.
For a glaring example, you say it’s #1, but Redux is dead in the water. I haven’t interviewed a single person in the past two years that wants to use it. The creators have been recommending “just using react.Context” for years and that has clearly had an effect.
> > I maintain my 2017 apps including major version bumps with no issues today
> Sorry but I have to call bullshit on that, unless you’re taking about tiny one page “apps”
What a strange stance. It's a React/MobX collaborative model editing internal tool deployed in production to users who generate and analyze models with it. It started on Webpack 2 and React 15 and MobX 4, now it's on Webpack 5 and React 17 and MobX 6. I of course had to update some babel configurations but it was much more version bumping than configuration rebuilding. It still uses decorators and looks like complete dog-shit, and that's my point: the same tricks and patterns available then are not only there, but working identically now.
Re: native, I don't believe in React Native or any webview-based "native" replacement anyways, but it's easy to do this as my user-base is interacting with this app from their company-provided laptops anyways. I would willingly concede React Native is an environment with churn, I don't really recall RN every reaching meaningful stability
Your list of "flummox / redux / unstated / mobx / mobx-state-tree / xstate / apollo / apollo-link-state / swr / react-query / zustand / recoil / jotai" seems to peak at 500k with the exception of "react-query", which I don't really see as applicable to a conversation about state management. Overall, this list perfectly illustrates my point that there's new stuff but you don't need to know it, and the value props aren't convincing alive-and-well shops to drop everything and rebuild
> you say it’s #1, but Redux is dead in the water
I never personally believed in Redux, it struck me as a terrible pattern from the start, thus why I selected MobX; but I find it difficult to believe that you really think React Context scales the same way building an external state management tree does. I like React Context, but it doesn't do a very good job of hiding away complexity from the developer as the application grows. Not to mention it does no render-optimization for you.
Again, I'm not saying things don't change or that there's not alternatives, but I am saying that someone who learned fundamentals in 2017 is still able to get up-to-speed in the updated versions of the library kings of 2017 in virtually no time, and deliver standard-fare webapps. I say this because I've worked at the same place for over 5 years, I use the same tools, and my users regularly are telling me the tools my team puts in front of them are the gold standard. The churn is long gone, everything you describe would have perfect analogues in any other popular modern language / library ecosystem.
> I find it difficult to believe that you really think React Context scales the same way
I don't, and I find the advice on this subject found around the web pretty terrible. But it's the position you'll most often see from React core team and people selling online lessons.
jQuery is still used in > 50% of websites. Popularity in numbers lags way behind developer adoption.
I've been involved in multiple new product development efforts in the last decade, and can tell you it looks a lot different from maintaining one stable product. And it's sped up by 10x if work at an agency putting out a different project every 2-3 weeks. This is where the fatigue comes from.
Lol, where did you get that I maintain one stable app from? I additionally don’t see how your working conditions relate to churn in JS given that you could use the same stack for each of those projects, as I said, as far back as 5 years ago
You said 'It's a React/MobX collaborative model editing internal tool' so I assumed you're commenting based on that particular project. It's not a value judgement either way.
The kind of development you do (product / projects / marketing) makes a huge difference in your experience, how often you get to start from scratch (= latest versions of everything) vs maintaining existing codebases. I don't think that's controversial. You could use the same stack for every project, but people and teams change and want to catch onto the latest "advancements" in the field.
Yes, this whole time you’re assuming I’m doing the bare minimum, and that no one could be using the same tools.
Yet, here I am, new apps in hooks based react, old ones not, and the same stack delivering great performance in either case - DX is only suitable in some tho
I’ve used Context only, SolidJS, Angular, whatever you like these days, I still would only build real apps with MobX. Typescript is the only real change since 2017 you need, otherwise what’s newer is not what’s better since then. That’s the point. Take care and try to not get lost in the noise, it’s very different than what came before it
I’ve never seen a situation where someone hasn’t tried to rebuild something that’s already working (in a big community like JS land). Some people wanted more performance from their build systems, some people like other languages to do the transpilation, some people thought the configuration options were too heavy and opaque. That’s why we saw ESBuild and rollup.
But CRA is still on webpack, and CRA is still the de facto default way to make a new react app. I don’t really see the fact that alternatives exist as implying churn when the same option has been the longest living and most popular.
now that it is 2022, what's the new flavor that would be prescient? I don't ask to actually know, but to reiterate the problem of nothing being solid in this world.
NextJS is still looking pretty good if you're in React land. There's new competition, like Remix, Astro, etc... but I don't see any of them putting NextJS to bed. I'm starting a new application, and I'm still choosing NextJS.
(Now what you couple with NextJS for data access is an interesting question - this is where there's a lot of innovation. Personally, I'm going with tRPC. I would look at Edge DB, but in this application I'll need a recursive CTE and Edge can't do it.)
Edit: I do think Astro might replace NextJS for purely-static sites, or ones where the "islands of interactivity" pattern is compelling.
Some of the vendor backed libraries are among the best. But generally I would agree that marketing, especially certain types, generates a ton of noise, like you beautifully illustrated in your article. I think navigating the web with a BS filter on is an important skill to have.
The old saying goes like this: "if you want freedom on one layer you need stability on the layer below"
My guess is that since frontend web development is at the top of the stack it has an incredible amount of freedom so everything changes every minute. You don't see too many people wanting to subvert HTTP making a billion homemade alternatives
> You don't see too many people wanting to subvert HTTP making a billion homemade alternatives
No? I constantly come across new protocols, promising improvements compared to it. Some even become relatively popular and are included in browsers by default. Just some examples are WebSockets, WebRTC and QUIC. I expect we'll see more of them in the future as specific use cases requires more specific protocols.
I think you make a fair point but on the other hand I don’t see many “top 20 alternatives to http in 2022” articles (which implies there are more than 20 alternatives) like we have for front end technologies.
You could right click "inspect element" in any browser and mess around in the html or the JS console and see things happening live. This is an extremely low barrier to entry.
Low barriers to entry are good, our profession is very well compensated and developed economies could certainly use low effort ways to get people from lower compensated jobs into higher compensated jobs* but that also means that there are a lot of cooks in the kitchen.
---
* yes, tech isn't for everyone (what job is?), and when I say low barrier to entry I mean you don't really need to subject yourself to what could easily be 5-10 years of schooling in medicine or law or engineering.
the level of effort is determined by how deep in the stack you are.
if you make a new JS framework every single browser will run it, if you make a new web scripting language good luck getting support from even one browser
Yeah but to be good, you have to have like at least 5 years of experience shipping stuff. It's kind of like going through many years of law/medicine school.
The article starts off with an outdated take on the space:
"We all know the meme: by the time you’ve learned one front-end technology, another three have just been released. Also, that one you just learned? It’s deprecated."
Maybe it's because the article is 4 years old. I just don't think it's true anymore. Ok there's React and Vue and others, but that's fine. It's basically the same tech, but they have DX/cosmetic differences. It's not like we're still arguing whether or not VDOM is a good thing.
That said, the "Imagine being a junior developer" section sounds spot on still. Maybe it's because those articles that use dogmatic arguments to recommend inferior technologies are still on the internet, and they are not going anywhere.
I'm the author and I agree. Things have slowed down and matured. The "JS moves too fast" meme is well out of date, and in fact I wrote a comment here a few hours ago bemoaning it
I don't know what it's like these days but I recall especially the pernicious 'evangelism'. People on a literal salary promoting frameworks like they were from marketing. As a bargain basement, self-taught, late web 1.0 dev more comfortable on the server side I remember rake-stepping the undiscussed limitations of Backbone JS, and then studying the ridiculous complexities of Angular 1 while reading post after post of Angular doctrine, and then learning that the great leap forward for Angular 2 was "yeah we're going to throw all that bullshit out we were wrong." By the time I was done I genuinely had no interest left in me for another new framework, package manager, or library.
> and then learning that the great leap forward for Angular 2 was "yeah we're going to throw all that bullshit out we were wrong." By the time I was done I genuinely had no interest left in me for another new framework, package manager, or library....
I've seen this more than a few times over the years, and it makes me a lot more skeptical of praise for anything new. Almost always the praise is about technical aspects of a new tech/stack, and the value is almost always in the larger ecosystem. I'm fine - happy, often - with using something slightly out of date if it means there's a community of people who can help support it, answer questions, publish mods, etc. There's a balance somewhere to be found, but I've been burned too many times picking a tool, investing in it, then having much be thrown away for the 'v2' version which is often not backwards compatible (for good reasons, usually, but still problematic).
Marks of maturity of a project - acknowledging upgrade requirements, publishing upgrade guides, supporting previous versions for a publicly stated time range, etc.
> Marks of maturity of a project - acknowledging upgrade requirements, publishing upgrade guides, supporting previous versions for a publicly stated time range, etc.
All of which did happen for AngularJS. And you could still be using your AngularJS components within an Angular application today - or vice versa - thanks to the tools provided to migrate piecewise. End of life for AngularJS was only five months ago after a four year LTS period that started in 2018, given that Angular 2 was released in 2016 that's a five and a half year period where both frameworks were supported.
Libraries deciding to break everything without warning is definitely an issue that's caused me grief in the past. Moving from AngularJS was something we decided on and planned out well in advance.
> and then learning that the great leap forward for Angular 2 was "yeah we're going to throw all that bullshit out we were wrong.
I wasn't in webdev-land when the migration happened, but as someone who maintains both AngularJS and Angular2 code, they don't seem all that different.
Especially considering the later versions of ng1 tossed out all the globals (components with isolate scope by default) and moved to class-based directives. And then ng2 came along and rewrote everything into a prettier API (typescript with decorators and shit). But otherwise they both seem to have the same design when it comes to change detection, dependency injection, controllers / views, etc.
I think it's is very possible that it's the next evolution of innovation in the space. It might actually be a Backbone -> React style quantum leap in terms of tech and adoption. The thing is, that won't happen for another 10 years, if it does at all. It could very well turn out to be a niche technology for most people, with minimal real-life benefits compared to the drawbacks of moving off the mainstream.
Every space has new innovative technologies that risk upsetting the status quo. I'm not saying things are completely boring now. Just that, unlike in the mid 2010s, they are actually stable enough.
As far as I know most native web components use direct DOM manipulations over a virtual DOM. So I think the jury is pretty much out on VDOM and we are witnessing it transition to a relic of legacy frameworks.
As far as other innovations Svelte has brought, Vue with the <script setup> sugar looks quite similar to Svelte, as well as compiling to a render function (just like Svelte). I’m not super familiar with the intrinsics of Vue but the VDOM is starting to feel like a thin MIR of the framework which could be swapped out in a future major release, rather then something essential to it.
I honestly think that 10 years is a very conservative prediction.
Saying React support libraries are at fault here is not fair - React basically reimagined itself over the years and went from OO and class based components to hooks and functions. The fact that you can still do OO isn't really helping it since it adds to the complexity of things you need to learn to grasp the ecosystem.
But that's honestly missing the forest for the trees - JavaScript itself went from asynchronous callback pyramid of doom, to promises and callback chaining, to async/await. The community went through multiple half-assed module approaches/specifications. Several FOTM bundlers with extreme complexity and various tradeoffs. Various build systems.
Features like hot reloading, transpiling, source mapping, shimming are table stakes for any frontend framework and involve a lot of complexity and tooling - because the entire ecosystem is built on a foundation of shit that is JS and the browsers.
So frontend frameworks are the least relevant part here - it's everything that makes them tick that's the problem.
I don't know one single UI/UX development environment which is elegant and nice.
From Android to iOS to Linux to Linux and Windows to browser UI kits. They are all complex and require constant searching for answers. The libraries are very big and require a complex tooling setup. You can never be an expert in all of them. At least not me.
My pet hypothesis for years has been that developers always vastly underestimate the difficulty of doing a UI framework or environment. They think it'll just be a matter of painting widgets and presenting data. As a result they under-build the foundation. The insufficient structure is then released out to the world for everyone else to build upon.
Once people realize the soul devouring chthonic difficulty of doing good modern UI, they've already built on a shit foundation and been forced to realize the full system with a heap of ugly hacks and workarounds.
Then someone thinks "wow, this is way too complex! All I need is a simple UI." Then history repeats.
You can see this with immediate mode clean simple GUI library of the week. They all stagnate after getting all the basics working, and there's a reason for this.
A good mature modern UI is at least on par with a high-end game engine like Unity in terms of feature surface area and difficulty. In some ways it's worse because while the breadth and size of the problem domain is similar the problems you encounter in a game engine are probably a lot more fun. UI is a hell of incredibly hairy state management and a really long tail of edge cases.
My hypothesis has been for a while: UIs essentially are video games. They have animations and interactions that rival the complexity of video games. Sometimes they even have sounds too. The rendering is not quite as complex (usually!), but everything else definitely is.
I'd like to see a UI system that is built by experienced game devs, who also are good at and understand interaction design.
This is probably a better comparison than one might at first think.
A game engine has a second, hidden, part of the iceberg: The production pipeline for all the 3D world/art assets.
That's actually where most of the work goes -- hundreds of artists go into a AAA game, and all the art they produce must be technically excellent along a bunch of dimensions that have nothing to do with what it looks like (and in fact, generally make it harder to achieve the look you want.)
Game engines that can wire physics simulation to 3D rendering to window abstractions are easy-ish to make, similar to how web UI frameworks are easy-ish to make.
All the production pipeline stuff is where the real meat is, similar to how in WebUI and, package management and transpiling and bundling and deploying is a hard problem. I think the game side has it even harder than the web side, though, although they usually have the benefit of only needing to work on a defined set of platforms, rather than in "the" browser.
> developers always vastly underestimate the difficulty of doing a UI framework or environment
Developers, managers, designers, executives, the whole process chain underestimates the complexity of building a stable and maintainable UI.
Everyone feels in their gut how complex building out a data processing pipeline or a scalable backend should be, but even people who should know better can't help but think of the UI as the "easiest" part.
In my experience, the only solution is forced minimalism. A sort of "Dogme 95" for UX. Force your UX to be a haiku, not an open-ended novel. This means pushing back hard on unnecessary complexity and focusing like a laser on what really matters.
In other words, the problems might be technical, but the solution are likely political.
> Then someone thinks "wow, this is way too complex! All I need is a simple UI." Then history repeats.
This gives me flashbacks to writing a Java applet (supporting the MS JVM!) in which my boss has decided AWT (no Swing lol) was verboten and implemented his own widgets. Which was great up until I had to implement dropdowns, because then you need a concept of z-ordering, which meant refactoring almost everything in order to include. And this pattern repeated several times for "simple" new features I was asked to add.
Writing a primitive windowing system with nested menus in GFA Basic and getting lost in a rabbit-hole browsing the Turbo Pascal object hierarchy as a teenager was a good way to teach me to not try and write my own UI library if I wanted to get anything else done :)
Pretty much anything after C/C++ era comes with a usable build system, modules and a package manager. JS is really stuck dealing with insanely low level issues in shit ways for various historic reasons.
As shitty as Android support matrix can be - it doesn't compare to IE6 web days (at least in terms of UI development, stuff like OS services is entirely next level - but you can't even start doing that in JS so it's not really a fair comparison) - and we're still paying for the technical decisions made in that era (how many people are polyfiling all the way back to stone age and including hundreds of KB of useless shit ?).
Very few websites/frameworks/libraries support IE nowadays. And Edge being Chromium-based, means most of the polyfill issues have been resolved. You can reach 99+% of browsers by writing in modern web standards (HTML5/CSS3) without having to worry much. Web dev is probably nicer than it's ever been.
> Pretty much anything after C/C++ era comes with a usable build system, modules and a package manager. JS is really stuck dealing with insanely low level issues in shit ways for various historic reasons.
But of course JS needs neither a build system (runs from source files) nor a package manager (runs from URLs) and recently even plugged the "no modules" hole.
Majority of people using JS with these frameworks are using package management and bundling - and suffering because the ecosystem has such shitty tools for dealing with it.
If you're linking jquery from your favorite CDN and writing your code inside of <script> tags you're not dealing with the issues this article is describing.
Right. But that's their choice. I actually really like what Mithril.js did, regarding decisions on size, complexity, distribution as a single file, etc. Pretty much the only thing I'd like more would be if some similar library targeted both HTML5 web and Sciter (since Sciter does some things in its own -- and very efficient -- way and it would be interesting if something filled in the details in the web platform that web omits but Sciter does not to come up with something Mithil.js-like but also usable on desktop).
This. Use what works and is stable. I strongly dislike JS (PTSD, perhaps) but when it comes to minimal code to get the job done, jQuery is where it's at: the perl of JS frameworks.
Well, they added modules some time ago and now they're widely supported. Not quite sure what more there is to say about that. Aside from botched variable scoping, that was probably my biggest grip with JS (but `let` fixed scoping many years ago as well).
As somebody who followed both Android and web dev, Android UI development was much clunkier. A lot of the patterns in use today (like React's declarative patterns) started in web dev before being adopted by Android. Not to mention, Java's package system was much more annoying to work with than NPM.
Hum... The Great (Web) Frontend Revamping seems to have passed. Nowadays people are still discussing if React or Vue is better, with a clear intonation of "whatever works for you, I prefer X".
Looks like the field is maturing.
Either that or we are on a fake calm before we see a lot of articles about people migrating into wasm in "whatever language has support for it right now" (AFAIK, currently wasm goes with rust).
Don't worry, view layer may be stabilizing but what about
Managing backend requests is too complicated!(react-query)
You *need* gql don't you?
Don't forget forms. Super hard to do right. react-final form, react form hook, etc
We need a monorepo framework!
Nx, turbo, rush, pnpm (too low level), Lerna (too old and unmaintained)
What about bundlers huh?
Vite, esbuild, rollup, webpack
I still see plenty of opportunity for teams to ignore persistent issues and just diagnose a new framework without analyzing their current woes. Silver bullets for everyone!
The difference is that's all ignorable. If you want to standard React with classes, redux, npm and webpack like it's 2017 then you absolutely can, and it's still a maintained and supported solution.
That's very different to say the evolution from JQuery to Backbone to AngularJS to React where you ended up being on an increasingly unsupported platform if you didn't upgrade.
It's not really ignorable, these frameworks come ready made with converts seeking to spread the good news to every codebase they find. Understanding, let alone improving, legacy code is a total waste of their awesome powers. It's raze the city and build paradise from scratch. Using shiny new framework (tm).
That's what tech leads are for. To be the person with experience and judgement who has the authority to set the rules for the rest of the team on these kind of questions. If you're having problems with this I'd suggest you have more of a hiring problem than a framework problem.
you might be right on the money with that. I mean it also reflects badly on me in regards sort of jobs I find myself in where this is a recurring problem. But.. I feel like it may be more widespread problem than most people admit.
If you started with Vue two years ago, you had to learn Vue 3 shortly after that. With a new Vuex. Which has been dropped since in favor of Pinia. Oh, Vite has been developed since, so you may want to add this to your stack, because it makes compiling during development so much faster. Also, be aware of all the breaking changes that Webpack 5 has introduced.
I hope front end development will be more stable in future, but the last two years where full of pretty major changes.
The Vue 3 disaster (in my opinion) shook my trust in the framework forever. I immediately knew this is not a framework I will spend any more time in. What if I "upgrade" my apps to 3 and then Vue 4 comes along with yet another fundamentally different concept? This is not acceptable for apps with any kind of long time support requirement.
Yes I know, Vue 2 paradigms are still usable in 3 but they feel very deprecated.
Coming from Vue 0.x and 1, Vue 2 felt wrong. It didn’t know what it wanted. Classes and hooks and decorators and options and only some obscure combination offered acceptable TS support.
Having only read the docs, Vue redeemed itself with version 3.
There’s the options API we know and love from v1 and the new and intuitive composition API. The docs make it easy to decide and not to mix them up. And no useEffect fuckery.
Don't think Vue 2 to Vue 3 is that bad, certainly nothing like AngularJS to Angular. You can still conservatively upgrade piecemeal elements of your stack and most of the code still just works.
I inherited a vue2 codebase with a vuex store, and upgrading to vue3 and pinia one component at a time over a course of 3-4 months was quite easy. The upgrade path is really clear and they did a good job making everything compatible so that it could be made gradually over a relatively long time.
That seems like a bad idea from an engineer perspective. The migration path is designed to be gradual, that migrated and legacy code can live side by side in production. I honestly don’t know why anyone would enact a policy of migrating all at once when there is an alternative.
This doesn’t feel that different to me from ~2010 era jQuery vs Prototype vs …Dojo(?) these things happen in waves. I’ve wondered if the next revolution will be wasm, or another round of JS magic… or something different.
I'll agree it feels a little more stable in the past 5 years or so. I do have a sense that a lot of the UI libraries we used on our project are working fine, but are also deprecated and have a doom's day clock on them. Oddly, this is as much from "in house" widgets as it is 'in the wild" ones.
Specifically, I know that if we want to bring in some widgets that were created this year, we have a massive upgrade task ahead of us. :(
Here's an unpopular opinion: it is unstable because we don't know what exactly "front-end" means. First it was static HTML pages, then it was CGI (ColdFusion & DHTML FTW!), then it was PHP, then it was Rails, then it was Node, then it was React, Angular, Vue...
Those aren't random progressions. On the contrary, they are front-end devs responding to needs of the UX moreso than the UI. There have been major efforts to make reactivity match what the user is trying to do, but we're still in unstable-land because we're building the bridge while we cross (I hate that analogy but it is true).
UI/UX is a fundamentally flawed field for a number of intersecting reasons, most of which boil down to not really distinguishing between when it's doing engineering, when it's doing psychology, and when it's doing fashion. And these days, on web apps and mobile apps, it mostly does fashion. Fashion must change for the sake of change. To more easily support these frequent changes, more libraries get invented to make doing new things easier. After that, everything in the article makes sense.
> Fashion must change for the sake of change. To more easily support these frequent changes, more libraries get invented to make doing new things easier.
The frontend "ecosystem" libraries discussed in the article are also subject to a fashion hype cycle, independently of UI/UX design trends. A lot of them don't actually make anything easier, or don't make rapid design iteration easier at least.
90% of UI/UX people could disappear overnight and nothing would change. Things might actually get better because they aren't doing a pointless UI overhaul every 6 months.
Wow this is a big, and dare I say baseless, statement. Consumers want and enjoy good UX/UI. If 90% of UI/UX people disappeared, the 10% that were left would be in such high demand that more people would become UI/UX people and fill the gap. And it's not just enjoyment either, there are plenty of examples where UI/UX make a huge difference in the usability of products
This sounds exactly like fashion to me. One just has to look at how often design has changed over the last decade with the many fads and worst UX.
I feel like when you have an org of designers they will justify in wanting to redesign everything because why else do you need them? The same can be said for some POs and devs as well IMO.
Yup. The most brutal environments I've ever worked in canned design folk very quickly once a cost crunch arrived. Some startups would even can designers first to save cash.
I think part of the reason is the evolution of common user networking.
Initially, users had low bandwidth connections, and web pages were mostly static with links.
Then came JavaScript interactivity and AJAX.
As users bandwidth grew, we started having heavier frameworks and SPAs.
I believe there is another revolution that is happening now because of decreased latency. Recently with protocols such as HTTP2, web sockets, and edge computing, round trip latency is greatly decreased. This is resulting in UI where more of the logic lives on the server and has led to such libraries as htmx (client) and Turbo.
It will be interesting to see where this settles out.
Agreed, very interesting things going on in the "edge" space. I personally think this is why HN is so jazzed about things like fly.io. Super low latency opens up a whole new category of applications, it's a "step function" change in that regard.
Front end develoment has never been more fun if you can keep up with the pace. Finally all major browsers have decent standard support (no Internet Explorer anymore), so crutches like jQuery are not needed anymore.
Developers constantly find new ways to implement front end apps, and they are not afraid to break backwards compatibility. This may be bad if you have an old monolith to maintain, but overall it's a good thing IMO.
Also, this is not limited to libraries. Have you looked at what speed Chrome devs are implementing new APIs? It's insane. And great.
> Have you looked at what speed Chrome devs are implementing new APIs? It's insane. And great.
It's not great. It is bad, really. It means no one that hasn't dozen millions of dollars can implement or even just maintain a viable browser that can keep up. And since we expect browsers to be free, that means… "complicated" business models cough mostly¹ relying on ads and tracking cough to maintain the Web.
I which it wasn't this way really. There was a time when it was possible for a few people to implement a quite good browser engine in their free time. KHTML. So good, in fact, that it was chosen as the basis of WebKit (and therefore Blink). This does not seem possible anymore.
1. There's Apple maintaining a browser engine without relying on ads, but their business model is also questionable.
Having started to work more in dev ops lately, I no longer think this problem is unique to FE. The number of tools used in the dev ops scene makes my head spin. There are hundreds of products and services one can employ when building out infrastructure that didn’t exist 5 years ago. Everything being built on top of kubernetes alone will send you into decision fatigue and months of research. I see no meaningful difference. Why’s is that? Do we just feel like the gravity of infra is more deserving of the complexity?
Lack of standardization is the primary reason we have this problem in the JS ecosystem.
"Productive" ecosystems (e.g. Rails, Elixir) usually have one central framework that provides the standard basics. Libraries, tools and other extensions are built on top of the framework to enhance the feature set. Everything typically works well together.
JavaScript has multiple frameworks to implement components, multiple tools to implement bundling, multiple tools to implement modular/extensible stylesheets, multiple package managers with somewhat different features (e.g. when it comes to monorepo support), and multiple libraries to implement basic standard functions.
Many of these are not compatible with each other. Compatibility is a combinatorial explosion problem that cannot be solved without standardization. Without it, you need to have m*n modules to have m things talk to n other things. Extensions to the ecosystem therefore typically have partial compatibility with all the tools, which further widens the breadth of the problem.
There's been very little effort in the community to standardize interfaces and protocols: but for the few things where it has been successful (e.g. see package.json) we've seen much nicer and smoother interop/tool interchangeability. We need more of this, especially when it comes to open-ended "plugin" style stuff (e.g. bundler plugins/extensions, component interfaces, monorepo structures)
It also has to do with the low entry level. The same happened to PHP. Inexperienced programmers can easily create nice things that look great on the outside.
Libs like React and Vue are stable enough but when you throw in a lot of other dependencies it is always the question how experienced the creators were. And when unstable libs become popular bugs and security issues are exposed, pull requests are created and before you know it a next version is launched that is not backwards compatible.
I feel entirely exhausted by the JavaScript ecosystem. Just for me, it takes all the fun and workmanship out of building something. I tend to spend so much time on tooling that by the time I get to do anything creative, my motivation is nearly gone. I just experience the moment over and over that I just don’t want to deal with any of it. Then I wonder where the fascination and enthusiasm has gone that attracted me to and kept me in this area of technology for over 20 years.
Maybe that’s my inner geezer talking or there’s some nostalgic distortion at work but building a website and a small product used to be comparatively easy. Today with the elevated expectations on functionality and the tons of tooling it quickly becomes an almost insurmountable task. Everything appears to be optimized for the large scale, where all the tooling and workflows probably help. There are just so many moving parts, all the time.
I’d like to build performant web sites and products with as little JS as possible, make a good living doing it and spend time refining the foundation. But those jobs are gone. It’s all JavaScript and full-stack development positions now.
Maybe I'm the odd one out, but I feel like the instability is mostly surface-level and FE is not, actually, so much less stable than other areas? I got into tech via web development, migrating further into the backend over time, and about four years ago became pretty much exclusively backend. Just started a new job and I'm back in the front end.
Some things have changed, but not that much.
- Typescript was just getting popular when I left, now it's basically a standard, but 1) after having been in javaland for a while, adding typing to JS makes a lot of sense to me and 2) though it's a change, feels like a change toward more stability, not less?
- React was the big framework when I left, still is the dominant framework.
- There's still a lot of option -- eg vue, etc. nextjs wasn't a thing I knew about that I am starting to learn now. Class syntax felt unecessary to me but seems to be de facto these days. But... these all feel relatively small?
I started in FE back in the days of IE 6. jQuery was a godsend when it arrived, underscore was super helpful. I'll grant the shift from "we use JS to add some interaction, form validation, and sometimes interact with Flash" to "we use JS to write actual programs delivered via your browser" was a huge shift, but since we've made that shift it seems most of the "instability" is more around FE devs adopting practices already common in the rest of the stack.
I think maybe that's where this sense of instability comes from -- a focus on the wide array of possible _implementations_ -- but I feel the really disruptive shift from "interactive decoration" to "web applications" was the really big one, and that's a while back now. And even with the dizzying array of possible implementations, there's obvious market leaders -- you're not going to go wrong by learning React, any more than you're going to go wrong by learning Spring Boot. Always good to explore and get familiar with other libraries and frameworks, but if one feel overwhelmed by options, there's some clear well trodden paths that aren't changing _that_ fast.
One thing I will say is that I do think FE is _harder_ than BE, because the scope is wider. You need to grasp all the aspects of good programming, but _also_ get a decent grounding in design and UX, which are their own disciplines. A backend API doesn't have to think about things like screen readers or color contrast or all the weird ways users will figure out to misunderstand how to interact with your GUI widgets. A UI for humans is inherently harder than a UI for machines. But that's not the same thing as saying that the FE is unstable.
Frontend is the entry level field for all those people who were not developers but wanted a slice of the salary pie. Designers, architect, lawyers. I've seen everything.
I know a few React engineers in my company who can make components and be productive - but they don't know JavaScript and they get stuck when something is slightly different from what they're expecting.
Similarly I'm mentoring a few engineers who started with react and are trying to learn backend and other languages.
Being the field where all the least developer figures start means you'll have tons of people, tons of visibility, tons of cargo culting and tons of crap being built just to make you look cooler.
I'm guilty of this as well, I have my frontend framework on GitHub and it's quite useless - even if it's a nice idea.
Of course nobody bothers to maintain stuff and everything is trying to make money on their junior devs fanboys.
I worked on a play <button> today that was 200 lines of HTML. Just the button. Front end sucks ass, sorry for the language.
The web browser as a platform just sucks to work with, it always has, just now the issues are more nuanced than just dealing with quirks or ms jscipt weirdness.
I think that if you want a page to impress or make a splash then sure, you always have to move to the next greatest thing, however, I don't work for them but I've paid for Telerik Kendo Controls (the react ones specifically)since they were released, before then, the AngularJs ones and it's been great - it keeps my (albeit internal app) UI development stable, fast and looks great with minimal fussing about. It's been years now and it feels very stable and quick. The switch from AngularJs to React was the only unstable part, but it was at an inflection point in the number of apps I had to support and develop, so the change was actually welcome. YMMV
(edit - I just realized I spent the weekend experimenting with MAUI, so I'm full of it)
I had to read your comment twice to be sure we're talking about the same Kendo. I've consulted for a number of companies over the years who have used it (or tried to use it), ever since the jQuery version to up until now, and it's always been pure pain. I understand how their components work, I understand the underlying architecture because I've stepped through it too many times with a debugger, and I still always fail to understand how they have any happy customers. Perhaps there is a good experience to be had if you only use the components exactly the way the documentation examples use them, but the moment you step outside that narrow path, things fall apart. Never mind custom code, simply using two different components from their library together doesn't even always work.
The first time I had a bout with Kendo was some odd ten years ago, and then I was sure it was simply me not understanding the framework. After all, every component library has its own kinks and it takes a while to get up to speed. After seeing them again and again many times over the years, I've changed my opinion. In my eyes, Kendo is what I like to call an MBA trap. It ticks all the boxes that an MBA manager going by a feature checklist is looking for, but under the hood it's garbage software. I'm glad you've had a good experience, at the same time I don't think I will ever stop recommending everyone to stay away from Kendo.
I don't agree with you but I don't disagree either. Our use cases are very vanilla, and now that I have quite a bit of sway in my team, when people deviate from the showcased Kendo way, I push back and see if the desired way deviating from Kendo is a necessity or a nice to have. If it's the former, we sometimes have the experience you described, though I've often be helped by stackoverflow, their forums or Kendo's support team. (We pay for the 24 hour tier). If it's the latter then I force the Kendo way.
FWIW, their ODATA v4 support OOTB with dotnetcore webapi with its ODATA v4 out of the box with an EF model is the perfect pattern for most of our use cases. But again, I don't disagree with you either - but I would stress that any alternatives I've seen have their same range of issues.
Let's use an analogy to maybe get closer to why churn on the front-end tech is so high: A few weeks ago I was reading a discussion on which musical instruments are hardest to play. Someone said that they are all equally hard, because if the instrument is easy to play, people will write more complex music for it.
I think the same happens in front-end dev. It happens here because it's obviously exposed to users and we want to a) follow fashions and b) wow our users. As soon as tools get more powerful and we start to master them we'll start to push the boundaries and everything becomes a pain again and several people will write frameworks or tools to make it easier.
> webdevs being naturally impatient, faddish and incompetent
Well, isn't it the case?
One more article confusing web programming with the whole software development!
Front-end development is unstable only for those applications where the nicest, latest GUI is the only value the developer takes to the table. Learn the business, have your application solve an actual business problem, offer a well-thought and on-spot ergonomic interface, and the users will love the features, and the GUI will not look oldish to them after two years.
I think we should stop talking about libraries and talk about the crap of browser specs. Libraries are just a tool and evolve over the years. but browsers are getting worse every year
Asking sincerely because this take is surprising to me: which specs are you referring to?
From my perspective—started front end, gradually went full stack, spent several years fully back end, dove back in a couple years ago—quite a lot of the APIs introduced in the period I was fully back end (and since) are excellent and vastly improve both development experience and the ability to deliver a better user experience.
I’m not saying your take is wrong necessarily, I just don’t immediately relate to it and I’m curious what specifically you find objectionable.
> Asking sincerely because this take is surprising to me: which specs are you referring to?
I'd like to see the Web Components spec revisited: it has a) no API for passing non-string attributes to other web components, b) no API for declaratively updating your DOM subtree - you either do manual surgical DOM changes, or blow away your (potentially stateful) children and recreate them.
Without these, the raw web components API isn't suitable as an alternative to React et al. You've got to build a whole framework around them (like Lit), and at that point you're just using another framework.
I haven’t worked with web components, and have only had a passing interest generally. But oddly enough I took some time today to dive deeper. It occurred to me that some of the APIs would potentially benefit some work I’m doing in a legacy project. I’m not an expert on the topic, but I have a few thoughts.
First, I agree both of these limitations make the spec less directly useful than a framework, and more likely to be APIs targeted by a framework (however formal or bespoke). That said, that’s pretty much the guiding design philosophy behind nearly all DOM APIs, and it doesn’t seem to me that makes anything worse, just incomplete. I suspect that richer APIs would make things worse. People would still use frameworks, but those frameworks would have to use much more opinionated and much less flexible APIs at a higher level of abstraction. All of that said,
> no API for passing non-string attributes to other web components
This is really a limit of HTML, and not new. But there’s plenty of precedent for raw string attributes to have a more meaningful representation in the DOM state. An area of the spec that seems really well suited to accommodate this is `part`[1]. Like `classList`, it’s a `DOMTokenList`, and has a corresponding CSS selector. It’s a string attribute, but it’s also structured data as a property. I have a long list of things I’m confident will benefit from this.
> no API for declaratively updating your DOM subtree - you either do manual surgical DOM changes, or blow away your (potentially stateful) children and recreate them.
This really is a footgun, but I’m not sure what the appropriate alternative is. I don’t think any spec could accommodate the fact that people choose different declarative implementations for very different use cases, without essentially defining high level interfaces that expect to be overridden. Even then, those interfaces would almost certainly be ill-suited to some specialization or another. If your goal was purely creation, I’d agree that there should be a declarative API. But for updates? I can’t imagine a design which wouldn't be worse.
> Without these, the raw web components API isn't suitable as an alternative to React et al. You've got to build a whole framework around them (like Lit), and at that point you're just using another framework.
I don’t think the goal of any of these APIs should be to replace frameworks. At that point you’re just using a framework forever. It’s an enormous credit to the design behind all of these APIs and their overlapping specs that they continue to produce useful lower-level interfaces without overly steering the ship.
I think it is getting stable recently. It is a choice of React/Vue/Angular for the most.
Be hold there are some choices to make here and there, but if you go with a vanilla setting with popular choices (like Webpack for build), things won't go wrong. Not everything needs to be shiny and edgy.
From that angle, the frontend space doesn't seem to be that different from wrapping around pytorch and offer yet another Trainer API with some callback shenanigans and claims to invent an AI framework.
It isn’t and never has been. Nobody stops you from using the same tools for years, only upgrading when it is truly worth it. The “instability” of front-end development is a “problem” created by front-end developers themselves. Like most problems in software development I might add.
Changing APIs. When the front-end gets JSON from an API. We really don't know what we're getting. We need to liaise with the API team to figure out how these APIs work and when they change, we don't know what changed. Luckily there is a new solution. End to end type safety. Using tools like graphQL allows FED build tools to get the entire API schema and bring that into the typescript build. If the API changes, your build will break allowing you to update your app to the latest API.
Maybe we need a new HTTP method "SCHEMA" that allows the app team to get the schema directly from the API and stop sharing postman links around in chats.
I would say the Web is unstable because it's a disruptive platform. Traditionally we build native clients, be it mobile or desktop, that work offline and connect to back end services. The modern web allows for that but in a simple, cost effective and cross platform way.
Naturally this attracts developers from all backgrounds to target this platform for their projects. These various influences puts pressure on the platform to morph to their preferences and with the platform still being young; that pressure (and profitability) means it tries to appeal to everyone, creating issues.
- Privacy
Privacy on the web is a challenge primarily because of government legislation. With the exception of the deprecated third party tracking mechanisms, the issues faced on the browser are no different to those faced by native applications - it's just that the scale of the web is much larger.
Any app, desktop application or website can opt to send user data to a third party. Cross-site cookies allow for customer tracking, but they are being phased out.
Service worker has recently started being used by advertisers for tracking. Generally though, advertiser networks can always operate in silos and request from their partners that they send customer data in exchange for compensation.
As a developer you may inadvertently subject your customers to tracking, for this I would love to see greater script sandboxing capabilities. Right now we have CSP and need to iframe anything we don't want to have access to the parent document - it would be amazing if we could sandbox _scripts_ directly, allowing us to grant no permissions by default and add them.
<script src="https://..." sandbox="fetch; dom" />
I would also love to see permanent storage (local storage, indexdb, cookie) require a user prompt for approval, where temporary storage (2 weeks) is allowed by default.
- Utility
The web platform has had incredible innovation and is going in a controversial direction that I personally love. While simple documents on the web are great, the platform is increasingly somewhere you can go to interact with rich experiences that operate on every platform.
Some criticize this as overreach of the traditional web, but in reality - Linux can now use MS Word and Photoshop natively on x86, x86_64, ARM, RISC5. Tools we use daily like APMs (DataDog, NewRelic), Google Maps, Email are all available on all platforms without requiring a native client. This is good because no one is going to make Linux clients for these applications.
Electron demonstrates that people want to use HTML/CSS as a UI toolkit (rather than platform native UI kits like QT, GKT, SwitftUI, WinForms, WPF, WinUI, Xamarin, Flutter, etc) and demand greater OS access than installable web applications can offer (like IDEs).
Web assembly demonstrates that people want to update this simple UI model using the language they like the best.
Expanding the Web Sandbox to offer lower level access to things like the permanent storage, filesystem access and hardware through user prompts would eliminate the need for Electron and allow for optimisations in a single browser to operate across these installable applications. The inclusion of Web Assembly would allow for more processor and memory efficient applications to be written - removing the stigma of "those bloated Electron apps"
Perhaps marking your web application as a "wasm" application would allow browsers to trim some JavaScript specific runtime logic allow for smaller memory footprints.
- JavaScript, Testability and Performance
There's a lot of investment in JavaScript tooling and a lot of impressionable developers out there are implementing software that isn't testable or well architected. A lot of these tools are used in improper contexts or, in some cases, are plainly bad tools.
By and large, JavaScript is a great language - or more specifically, a great compile target. A lot of the issues with JavaScript can be resolved by applying a pre-processor like TypeScript to it.
The ecosystem is a point of critique. Being as open as it is, it's unopinionated, lacking a standard library or tools and engineers must stitch together their projects. By comparison - Rust, Go, Kotlin, Swift all offer rich test tooling and strong standard libraries.
As a language itself, the language features of JavaScript have become an amalgamation of various developer preferences. Being that it's the only language that can be executed in the browser - it is under a lot of pressure to morph into every other language used by web developers.
If Web Assembly ends up replacing JavaScript as a compile target, the web would become a significantly nicer place to develop for as you can pick your language ecosystem of preference.
Some languages are better suited to testing, have better tooling or dependency management.
Some languages have access to better multi threading APIs and some languages have more efficient runtime performance. These would bring the development and user experiences on the web as comparable to native applications in performance.
- Rant on WASM
That said, WASM has been the biggest tease for me as they have over promised and under delivered. 5 years ago they were talking about it as a replacement for JavaScript as a compile target for languages like TypeScript, Go, Rust. Smaller binaries, faster parsing, better runtime performance and multi-threading support. Here we are today and I still can't make a div from my WASM-compiled C project.
A lot of it is that UI programming is just difficult and inherently complex.
Expectations of users are very high and always shifting. Browsers/consumer OSes are constantly moving targets. Mistakes and bugs, even small ones, stand out in a glaring way, so there’s low forgiveness. There are more code paths and they’re harder to test.
All that means that unless you want to miss your deadline by a year or leave a bad impression on users, you will need a lot of libraries!
Backend/systems specialists always underestimate how hard UI programming is. Then they try their hand at frontend and quickly run into a wall. They find they either need to build something clunky that users aren’t impressed by or else spend a lot of time learning new tools and paradigms (and yes, installing lots of dependencies /shiver). This is a blow to the ego, so it’s better to criticize the language, the culture, the “churn”... anything to avoid admitting the pixel pushers are solving seriously tough problems too :)
>anything to avoid admitting the pixel pushers are solving seriously tough problems too :)
That's not how I view it, as a SRE/BE-SWE who has done substantial visual/FE work. From my perspective, the majority of problems in FE are due to extremely poor libraries and standards, bolstered by a community where copying and pasting large chunks of unknown code is acceptable. Yes, there are "seriously tough problems" with trying to develop in that world, but they are of a different world than most BE problems, from my experience. So they feel comparably difficult, but for very different reasons.
> The amount of rehashing and reinventing the wheel with new catchy names in the field is staggering.
This is true at every layer of software development.
> TBH, if the field wants to improve -> its time to ditch JavaScript and force Browsers to move to something that makes more sense.
I don’t think I could disagree more. JS is a tool, swapping it out doesn’t remove the unique problems of front end development.
Let’s say we switched to python for the FE. The team wants to use numpy for some of its features. Bam, 30 mb being sent over the wire for one library. What do you do? You decide that’s unacceptable and start extracting the functions from the library you are using. You realize that these functions are useful enough on their own and publish them separately on pypi. You describe the library as fast and only 1kb.
Then someone else comes along and decides this is a tedious task to break up all these libraries and publish small functions as packages. They figure out a smart way to tree shake the library so only the code used gets sent over the wire. Do you see where I’m headed here? In 5 years the python ecosystem for FE development will look shockingly like JS of today.
Your solution does not resonate with me because it does not address the core problems of FE development. The tool isn’t the issue, it’s what the tool is trying to solve for that is the problem.
To be slightly more charitable, front end attracts self-taught devs because the browser is the default dev environment on Windows and on phones/tablets and it’s far more accessible a new players than any other environment.
It’s more fun to write code and make stuff up than to find and evaluate libraries (especially when said libraries are written by self-taught devs), so people tend to reinvent rather than research.
> TBH, if the field wants to improve -> its time to ditch JavaScript and force Browsers to move to something that makes more sense.
Javascript was never the problem. Today there are bazillions of solutions using another language for the people who don't want to hear about Javascript. The problem is all the DOM and WebAPI available to the developer. You can potentially interact with all that in C++ if you wish, but you'll always be limited by the exact API as Javascript in the browser, by design.
Fundamentally there is a mismatch between how the DOM works and how most people develop complex interactive UI, switching to another language doesn't solve that problem.
Thank you! Part of the reason that I love these front-end threads is because inevitably somebody will make a fool of themselves by spouting anti-js-dev "backend master-race" nonsense, and this certainly did not let me down.
Fads are tempered by a community of people anchored in a deep understanding of the technology. As talented as many FE engineers are, I can count on one hand the number that I've met that have a deep understanding of things like await/async + Futures, closures, DOM trees, etc. These things are (perhaps unfortunately) required to do FE work, yet the engineers using them don't fully understand them, so they don't know how to discern if helper libraries are actually helpful.
Additionally, I'd argue FE draws more junior people in general, because of the theoretical rapid feedback loop, and the fact that you can "make something that looks cool" with relatively little effort (relative to a BE engineer). These junior people add confusion to the chaos of the community because they don't know what they don't know, so they're cocksure about their opinions. And as long as they've "made something that looks cool", even if the architecture behind it is hot garbage, it buys them cred in the community.
Somewhat related, I've been using Flutter for a recent FE project and I'm in love with it. It's more for webs/mobile applications than websites, but the ergonomics of it feel like a coherent vision. The people maintaining it (Googlers) are excellent, and the Dart library community seems to know what they're doing. Furthermore, the FE design choices are based on Material Design[0], which is backed by (some informal) research by UI and UX professionals, so you don't have to sweat usability quite as much as you would starting from scratch.
It's interesting how you can look down on front end for being new and naive while suggesting that Google is a fine reliable tech stack provider.
I'm the opposite of everything about this post. A very experienced dev (>20 years professional experience) that has moved primarily to the front end recently in my career (gradually over 4 years). I won't touch flutter simply because the sole vendor and essential dependency is Google.
Fads are present in every corner of development. As is "not invented here" or the general draw to green field.
If you're looking for a response, you're not really giving me much to respond to. Why do you think Google doesn't provide a "reliable tech stack" ? In any case, I wasn't suggesting that specifically (though I tend to agree with it), only that they have a coherent ergonomic vision by competent engineers.
That's fair. I feel more confident about Google's OSS (like flutter) surviving than I do about Google's consumer products. The flutter community is very strong, and as far as offerings go, it's (imo) the strongest product that abstracts UI/UX development over web and mobile, and the demand for that abstraction is very real.
Plus having Dart (which feels a bit like Java, but less verbose) as the foundation language raises the bar in terms of library code quality (compared to Javascript at least)
BTW, nice to have these kinds of pro and con conversations about random tech. I don't get it at work as much as I'd like.
A lot of open source projects die when their corporate investor closes shop. The community is often just dependants who want to use the tech but don't have the ability to keep it running. And it is usually not big enough to come up with the funding for a foundation to run maintenance and development.
Flutter is very ambitious as a project. I have more direct experience with other similar projects like react native, which really struggles despite the investments.
I think there are a lot of _vendors_ trying to usher in a revolution around their particular products - there's a lot of VC funding in JavaScript tooling nowadays - but that's a different problem.