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.
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.
Frontend is unstable because it attracts ppl whose attention span is often lower than the one of a goldfish. Every JS frontend dev I met was speedrunning trying to prove himself by "inventing something new" which in fact was already a state of art. The amount of rehashing and reinventing the wheel with new catchy names in the field is staggering. TBH, if the field wants to improve -> its time to ditch JavaScript and…
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.
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.
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 n…
> 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.
> recently even plugged the "no modules" hole
I haven’t heard about this. Do you have a link so I can read more?
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…
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.
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 ca…
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 d…
I thought VDom is old school since Svelte and such? https://news.ycombinator.com/item?id=19950253
I was waiting for someone to mention Svelte :) 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 draw…
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 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.
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.
I enjoyed reading your article, thanks for writing it. I think your recommendation to new devs to focus on Next.js in 2018 (!) was prescient. > I no longer think front-end suffers the instability people accuse it of. Do you mind elaborating why you believe this is the case?
>to focus on Next.js in 2018 (!) was prescient.
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.
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 go…
I think you're spot on.
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.