React will be unseated like jQuery got unseated when someone makes something that looks nicer. Every time you write a library (or even API at work), make sure to look at your code samples and you better be 100% be able to say "this is pretty."
I call that "developer happiness". It's extremely subjective but yeah, writing and then maintaining React code makes me the most happy in the best case scenarios, makes me feel like I can do more with less, it's easy for me to read and design. I feel like I have more friction with other JS tools.
Just in case you're unaware of it and wish to read similar content, there's a term/thing floating around for some time now, called "Developer Experience" (often abbreviated as "DX") that seems to cover this, and more.
React code looks good for clicker example, when building real application I think it's much harder to read than vanilla JS, especially when hooks and all the dependency arrays flying around, constantly worried about how many times will things fire and super easy to make mistakes no matter the skill level.
To me it goes beyond the looks. Angular terminology and semantics were always very alien. React is no angel either, but it seems influenced by older, more tested concepts (FP and such).
That said, I think client side UI/UX is about to see yet another large wave of change. Hearing chats from solidjs devs make me feel that there's a whole new and saner space to describe simple and fast programmable interactions.
I’m going to be the devil’s advocate because I’m from the team "no SPA at all unless you have a real need like real time" but to me, Angular is the less worse when it comes to writing SPAs in teams.
Clumsy and hard to learn ? Sure. The code looking less cool than other frameworks ? Of course. Unbearably slow compiler ? Check.
But at least you got a full fledged, batteries included framework, with a powerful DI system and an established architecture to follow. Not the funniest framework but it works.
The only powerful thing but also big flaw with angular is that they deliberately expose a lot of the framework internals with a very neutral documentation that never explains that you shouldn’t touch this or this in most cases. It allows very nice and clean extensions of the framework but, oh my, if you inherit a codebase from a "smart guy" who knows the framework inside and out and "did better" than the boring angular architecture, then good luck.
I know this can happen in any codebase and I’ve seen it everywhere but Angular exposes so much things that you can make horrible things.
But in a team who have a boring CRM or SaaS front end it’s a pretty good framework to use. Except if you can do everything server side.
In fact the "write a component" part is the center of React but only one of the features of Angular. In my experience, the big advantage of Angular is that you rarely need anything else and so it’s totally possible and reasonable to write a full fledged application without any other dependency than Angular itself. In $prev_job, we had nothing else in package.json than angular, some internal libs and the internal design system (which were exposed as angular providers) and some wysiwyg editor like quill.
It’s far from the funniest framework, but for writing boring things in team setting, it’s actually pretty good.
In fact having worked on the oldest AngularJS framework, it’s very interesting how it made a full 180 from "magic everywhere" to a boring "enterprise" framework.
I would never make a side project in angular because it can be pretty boilerplatey but in a team of 3 or more devs in a multi months dev project that I’ll have to maintain for years, that’d be my choice.
Except if I can reasonably do it without an SPA beforehand but that’s a totally inaudible proposition in corporate world anyway.
I was going to write a counter argument that codebases using earlier versions of React did not look nice, and that they only started to look nice when React moved to Hooks and functional components.
But I realized that actually supports your argument. React with Hooks and functional components unseated old school React.
> they only started to look nice when React moved to Hooks and functional components
Is this a widely held opinion? Call me crazy, but I really liked class components. It was nice to see the lifecycle stages in the actual method names, and encapsulate the behavior inside of a method block. To me that was really nice to read.
With hooks, everything is inside a function without clear delineation. The lifecycle stages are put anywhere in there with (to me) strange looking calls to useEffect and such.
Before, I used to love whipping up a quick UI in React, but since hooks I loathe doing that. I really don't want to upgrade my existing apps to newer versions. And for potential future project I'm looking for an alternative.
Perhaps I don't like it so much because I'm primarily a back and systems engineer, and only do small frontends on the side.
Hooks are awful. They’re a faux-functional interface, accessing implicit local state, with so much magic going on behind the scenes that it’s obscene. At least in class component days it was obvious which components were stateful. Now you’ve got to remember which magic hook incantation is causing your “functional” component to improperly cache state and why. I cannot for the life of me see it as an improvement in any way other than “it looks nicer,” which aligns with the top-level parent’s point.
Anyway I think react in general is kind of terrible. I’ve worked at three places whereFE teams made a react codebase that wound up being so scary and difficult to work in that essentially no one would touch it, until it eventually got rewritten. Two of those just rewrote it in react again, hoping that whatever faddish state library would save them from themselves. At the third, they rewrote it in svelte, which went much better. At least for me as someone who only writes FE code when I have to, svelte is much more comprehensible and sensible.
But you accept a whole host of other limitations with WASM. It's a trade-off. You still need to access the DOM, which can't be done directly from WASM. Maybe someday it will happen? Okay, so use canvas instead and do all UI inside WASM? That seems like reinventing the wheel that is Javascript + DOM. WASM has plenty of uses, but replacing Javascript probably isn't where it shines. Javascript is still great for front-end tasks, WASM is good for lots of other things that aren't user-interface related, like running ffmpeg inside the browser. I'm doing this on a project and the front-end was easy to create a drag-and-drop file upload in javascript (React) and handle all user interface stuff like progress bars, etc. ffmpeg runs as WASM code doing whatever the Javascript tells it to do. I can't imagine also writing a front-end in Rust or something else that's supposed to run inside a web browser in WASM just because of vague "JavaScript limitations", when Javascript is really a good solution for front-end UI inside a web browser.
>It's not vague. Despite 28 years of effort optimizing JavaScript, WebAssembly outperforms it:
That's great that WebAssembly outperforms Javascript. But only in processing power - and not all programming tasks require the most bleeding-edge performance. User interfaces do not require the speed of WASM. They require being easy to develop, and Javascript is almost always the right solution for UI. None of the WASM frameworks you mentioned are used very much, there's simply not the ecosystem for them that there is for Javascript for user interfaces.
And this is what they mean when they say "use the right tool for the job". I'm not going to use ffmpeg ported to Javascript, because that would be slow - of course I'm going to use ffmpeg in WASM to transcode video in the browser. And I'm not going to replace React with something in WebAssembly no matter what language, because it's just far easier to write the UI in React. Or even jQuery, or even just plain old vanilla Javascript.
Javascript is a very easy language to work with, in spite of what the people that don't really understand Javascript think about it. The only reason to do UI in WASM is that you don't understand Javascript or you have an irrational hate for it, or "because reasons". But sure, do whatever you want to do, I'm in no way saying you can't. Just don't expect that WASM will be replacing Javascript in any real way, anytime soon.
So you mean JavaScript is less efficient than WebAssembly, which means every time a piece of JavaScript runs on the billions of systems running its suboptimal runtime there is higher power usage, which means there is a greater demand on energy supply, which means there are greater carbon emissions, which means more global warming, which means we're closer to a climate change catastrophe than ever before.
So not only is JavaScript slow it's also an ecological disaster.
You've convinced me. Brendan Eich has a lot to answer for.
If you're a large hosting provider like a Google or a Microsoft or an Amazon or a CloudFlare, you want to be eco. You want to be eco for PR reasons, for financial reasons, and for practical engineering reasons.
Yes, let's save the electrons so we can mine bitcoin with them. /s
oh, oh, wait - I have an idea! Let's just write everything in 8-bit assembly language, that will let us really optimize and save all the electrons for bitcoin mining! /s
You really are barking up the wrong tree. Going after Javascript as if it's the reason the planet is doomed, or even makes any difference at all in the grand scheme of things, is just looney tunes crazy. Sorry, it just is.
I stopped using semicolons in my code to support your cause. Think of all the power it will save by not switching on a few pixels! We'll save the world! /s
Sure, I wrote nice code in Go, the language I want, and compiled to wasm. The most simple apps were 2MB+ of wasm compressed, browsers won’t even reliably cache blobs that large, got evicted all the time. And 100KB of react is bloated? Lol wtf.
Don’t tell me “whatever language you want” means “whatever language named Rust you want”, thank you.
No, none of my Go wasm projects worked with TinyGo (maybe reflection support is better now, but I’m not going to start a new project in it just to find out midway that it’s yet another disappointment). TinyGo is not the language I want, but rather, an unclear subset of the language I want.
Interesting take. On the other side, many library developers drop TypeScript[1] because it requires a build step and might be tricky to deliver to library users.
I wonder how much would WebAssembly suffer from this and compatibility issues. I hope browsers to improve WASM ecosystem so that it can be used more widely and without the need to ship the whole runtime with your website.
I wouldn't call it a win. Web UIs plateaued about 10-15 years ago. It was never the state of the art in what is possible with user interfaces; it always was a huge compromise between having something that feels vaguely responsive shoehorned into a platform (browsers) not really designed for being a platform for implementing UIs. Mediocrity is the norm on the web. And react is just the gold standard for shoveling that shit out. It's not good, or great, or nice, etc. It's just that the rest is just more of the same level of mediocrity.
My feeling is that the core issues were never really addressed. Javascript was utter shit 25 years ago and it still is. CSS was an inflexible complex mess. And it still is. And the browser's DOM tree was more or less an accident that resulted from a brief industry wide obsession with things like XML. Hacking UI frameworks on top of that is basically what most frameworks do. But it's just not a very good basis for any of that. Design by committee stuff. All of it. The worst is that there's a lot of good UI out there on other platforms.
The web was awkward and painful 25 years ago and it has gotten a bit better but actually not a whole lot. There's nothing pretty about it. Or state of the art (not even close). It's just a lot of mediocrity and a culture of people confusing this mediocrity with "apparently this is how it's done" and not even questioning it anymore. It was easier to do some things with Flash twenty years ago than it is with web technologies today. People have stopped bothering to attempt to even do a lot of these things. Just not worth the pain. And mediocre is good enough. Slap a drop shadow on it and call it a day. Maybe a cheesy css transition here and there.
I love brutalist websites like HN calling bullshit on this crap. Dang and his friends don't even attempt to dress it up. It's orange! Forever! Enjoy. It looked dated ten years ago, the same it does now. But it's also a major news website running circles around most of its competition. At best they might weak 1 CSS color around Christmas or so from orange to red. That's about the extent of "web design" that happens on this website. It doesn't need it. It would be just window dressing.
I agree on all your points. The basic web technologies are still primitive, and therein lies the problem.
All these arguments about frameworks and libraries would be moot if the web technologies were properly designed, so i believe that is where we should focus our energies.
Why is it that after several decades HTML, CSS and JS are still so primitive?
I actually think the more powerful factor was that React and jQuery before it were easy to pick up and start integrating without a lot of fuss. You don't need to build a dedicated website, you can just start incorporating these libraries into your existing stuff. Compare to Angular which basically demanded a rewrite to start using it.
For similar reasons, I thought Vue.js would win over React, but it's starting to seem I was wrong.
Same reason Python is eating the world. It’s technically one of the worst runtimes. Slow and difficult to distribute. Nobody cares, because code ends up short and pretty.
It's because when you write code using these libraries, your code looks nice.
I cannot say that for a LOT of libraries, especially MOST frameworks. Sorry for calling AngularJS out but look at a code sample from early Angular: https://stackoverflow.com/questions/42823436/angularjs-error... (It looks terrible.)
React will be unseated like jQuery got unseated when someone makes something that looks nicer. Every time you write a library (or even API at work), make sure to look at your code samples and you better be 100% be able to say "this is pretty."