React (and NPM for that matter) is not all web development, in the same way that Windows is not the only OS.
Vanilla JavaScript these days is an absolute joy to code in (and highly performant compared to the past). Even lazy-loading modules are supported natively by the browser these days - you can go a long way just using purely built-in default functionality.
I avoid NPM and React, and live my professional life quite happily without them doing professional development using typescript and angular with bazel. For fun home projects there is deno which is also lovely. Bun looks interesting but appears to want to ape NPM so it is a no from me.
Incidentally, I've been working on a hobby project lately and just for fun decided to use pure vanilla JavaScript to interact with all browser APIs directly -- not even my old friend jquery. It's been surprisingly fun and easy, partly because modern web browser APIs have gotten so good and are insanely well documented at MDN, to the point where stack overflow and LLMs don't really help much (and when I do use either I just use it to find the appropriate MDN pages)
It's been fantastic. And I'll be able to keep my project insanely performant. I'll be posting it in a Show HN when I seen it cool enough.
Couple concrete examples of web apis getting awesome:
Document.querySwlector or whatever it's called, to do something very similar to original jqueery
If you want to enjoy pure JS/HTML/CSS, you can try vanjs with a web components library, for even better experience, or you can create your own components using van-element.
I am not sure the author really knows what they're talking about when comparing today's web development with earlier systems.
First of all, the reason for useEffect() is not directly asynchronicity. It's mostly an optimization to give React control over what code it needs to run when the state changes. This is because with React, you basically re-render a document with every state change, and in order to speed this up, React needs to know what code depends on what part of the state. Admittedly not pretty, but all of the more automated MVC-like systems have mechanisms to detect or handle model changes.
They are completely wrong about asynchronicity. Since the 80s GUIs have been using event loops. Windows 3.x did this, and even really old UIs like GEM did. When using an event loop, you must execute operations asynchronously or the event loop will block. That's not new at all. What's new is that, these days, applications are interacting a lot with the network, and these are blocking operations. They require asynchronicity in an event loop. This wasn't really the case back in the days before the internet, when everything was local. And for longer computations you had to call functions like yield() to give time to the UI.
He mentions threads, but they didn't really became a thing before the early 2000s. And threads never worked very well with most UIs (except the good old BeOS?).
It's easy to complain about issues with today's development frameworks and easy to overlook the limitations in the past. UI development was always a pain, especially for applications that are larger than the typical demo app. I have worked on apps using GEM, MFC, QT, GTK, TCL/TK, AWT, Swing, JavaFX... it doesn't matter. It always sucks one way or the other.
Today's web-based UIs and their dev tools are a marvel in many ways. Like you can easily update them without going from computer to computer, or let user run install programs. They easily adapt to all kinds of screen resolutions and screen orientations. You can easily debug them in the browser, even on an enduser's computer. You have package managers that make it easy to add and later update libraries. Certainly not everything is perfect, I still kind of hate UI development, but it's a huge improvement over everything we had in the past.
Hard agree. They also glossed over JS using a single threaded model precisely to avoid the huge mental overhead of dealing with multi-threaded models (I'm saying this is why it happened and this is the problem they aimed to solve, not advocating either way).
The other thing they've missed in why people moved to react in droves is so simple it's possible we've just forgotten it because it's become such a de-facto approach: co-location of declaration, behaviour and styling.
React took us out of the "X belongs with all the X things" mental model and allowed us to create isolated "X does this and looks like this" things that require far less mental overhead to drop into while making changes to a potential foreign codebase.
This is _exactly why_ Facebook preferred React to the status quo. Engineers changing one thing in one place with predictable effects is wonderful for teams operating at wide/deep scales.
Again, I'm not advocating for any of this, I just don't think skipping over history or twisting it into an unrecognisable ball gives any forward momentum to conversations about the evolution of UI/UX.
> For example, Blazor framework, which uses WebAssembly to run C# code directly in the browser [17]. No bizarre syntax, no winding code flow, no infrastructure madness and, especially, no bad performance.
This is simply not true. Performance here is objectively bad since the payload is quite large. Also, I would comment that the DX with Blazor is not very good overall. For all the things broken with JS UI dev these days, DX with hot module reload is quite a marvel that I wish more platforms could achieve (C# kinda has it).
My team recently did a large browser extension project and ended up using jQuery and web components. One of the younger devs made a humorous comment like "Why does this feel kinda nice?" (paraphrase). We've somehow been convinced that direct DOM manipulation is a no-no when in fact, it's performant and the DOM itself can represent the state without the need for complicated solutions like VDOM diffing. (I don't know about other teams, but even if I plan to use React, Vue, or other front-end libraries, I'd interview candidates on raw HTML+JS+CSS first.)
But yes, overall, the pain is very real. A recent pass with npkll[1] freed 20+ GB of disk space....
I just don't understand React, it makes things slower, less responsive, just a worse browsing experience in general all to serve json instead of html. The user experience is worse and the developer experience is worse.
React was invented to save facebook money on the billions of requests they get by sending minimal json data and having JavaScript do all the rendering. Under facebook I can understand it because it will save them millions in bandwidth but for 99.99999% of other websites it makes no sense.
Also another reason for React was to devalue front-end developers and make them easier to replace.
It's not about the rendering. It's about making sure all the state of the UI is consistent. That when textbox A is changed. All the places in the page that depend on that value are updated. You can do it without react but it's a real pain.
Apparently Facebook can't do it with React either. They still experience the exact same state inconsistency bug as described [0] during React announcement as rationale for using React.
Managing state in the frontend is the worst, no matter the framework.
I understand why a large company like Facebook wants it to be done client side, but for the rest of us, I'd argue its nowhere near worth the hassle.
Yes, the problem isn't react, it's the notion that every website needs to be an application, or that sites serving articles (a large part of the web) need a UI.
I make dynamic apps and I have never had this issue with state. I've made visualization generators, image editors, live charts and html editors that run in the browser. the stuff I'm making has a lot changing elements and handling the state is not an issue for me. Maybe it's because I learned programming from game development I see web dev with a different perspective?
So 10 years ago when React was made public the default way to handle changes on the web was to have a bunch of event handlers that would go over the DOM and make appropriate mutations.
That's kind of typical of retained mode user interfaces. To this day that's kind of how things like QT and GTK kind of work. There are things like data binding, etc. But that's what they do under the hood.
When you are working like that it's easy to forget to do mutations on specific UI components or to make mistakes about the mutation that has to happen.
React handles the mutations, it takes your code, feeds it the current state and gets back what the ui should look like, and then it does a diff with what's on screen and updates accordingly.
If you are coming from game development you are probably used to immediate mode UIs where you specify and update the entire user interface every time.
To slightly refine your question. When a variable changes how do you know which UI elements have to be updated? I think his answer is obviously all of them.
This! There is also an entire generation of management gatekeepers that only approve of React stacks, because the population of React devs is so huge they step over one another for a job.
I have a moderately complex web application, lot's of heavy compute in the backend, in which I wrote a perfectly fine browser based vanilla JavaScript UI that is performant and does everything the application needs. However, ordinary users see it and say "it looks so old, like early web" and they literally don't want to be seen using "such old looking software". Their reason for rejection is a fashion argument, they think it makes them look old using it.
Okay, so I go looking for a front end developer to make my vanilla js look more modern, and I can't afford anybody except 3rd world React developers, who work amazingly fast and build my UI as fast as I can tell them what I need. The front end code is now 2-3 times larger than the backend, the UI looks just like all the other single page applications, and my new beta users are finally treating the project like this is viable new software and not some franken-monster of old and new. I actually receive useful feedback now, rather than complains that it "looks so old".
Html, css, js and react are the worst solutions for graphical user interfaces, except for all the others thought (The only exception is perhaps immediate mode guis).
React is bloated, slow and over-complicated now days, but unfortunately the only sane way to work with retained mode UIs.
In my experience working without react devolves to reimplementing react ad hoc.
Also, there are many UI challenges solved easily by React plugins - e.g. multi-select boxes, datepickers, colour pickers, file uploads, etc. Yes, this is using a sledgehammer to crack a nut. But I don't have a nutcracker, and I do already have a sledgehammer, so why not.
I think the author misses one of the main advantages of react: transformation of application state into ui is a pure function. I've worked with a lot of different UI frameworks (mostly in gamedev) before switching to web development, and I've ran into a million issues that occurred because of procedural approach to UI.
I think the main take is: is ok to do stuff in javascript, but first we should have fixed javascript stupid stuff. Packages like isEven, isOdd, where created by one guy trying to solve javascript weird way to do stuff and now are widespread without considering if all that effort could be used in a better way.
What? The modulo operator always existed in Javascript, isEven and isOdd have always been stupid and unneeded. "n % 2 == 0" and "n % 2 != 0" has never needed to be a dependency.
“Code is unclear. No-one knows that % operator.” — Service companies which require you to produce code of offshorable quality. As if someone without the skill to understand %, can have the skills to understand how to translate your business needs into code.
Nowadays it's common for developers to learn React before they even learn JavaScript, and that's not great but it's not the cause of the problem.
It's the companies that pile on to a stack because it's "easy to hire for". If everyone optimizes for hiring we end up with a local maximum, React. We can't do better because no one else is doing better.
> Some people have been complaining that Medium suffers from the same issues discussed in this article, and that’s true. Medium is definitely bloated and its countless popups are annoying. I’m sorry about that, but I receive no money from these articles and am still considering switching to another platform — you know, most of them start out great and become enshitificated over time.
Dotnet MVC is a breath of fresh air from working on React projects. Going from Prisma to EF Core feels like I'm time traveling back from an Idiocracy (2006) world.
EF Core is highly underrated; amazingly mature, performant, and ergonomic ORM. Pairs nicely with .NET web APIs and OpenAPI for a fully type-safe stack back to front.
On Node Kysely[0] looks quite nice and has a type-safe DX with TS. Feels nicer than Prisma, IMO.
I think with these sorts of rant-like articles, my expectation is the author will tear down the strongest possible contra-arguments. I don't think this author is doing that. Quoting random numbers as "too big" and random examples of web apps as "too slow" really doesn't feel like more than an angry rant. Which is fine! But it's just not something I'm going to praise you for, even if I agree with some of the core points I think you're trying to make.
It would be nice to see examples of React applications commonly considered "the good ones", and showing us that they are actively subverting some element of React's framework to accomplish that feat, or how they could be better implemented with another framework/technology/platform. Show React actively standing in the way, versus ranting about how one of the most common JS frameworks, is commonly used to create sub-par applications on a platform renowned for it's size and accessibility to amateurs.
Although I don't agree with all of the points I have to say the amount of times a year I'm told with a straight face the following for lists with under 200 items in them is getting ridiculous.
> The truth is that it’s simply unacceptable that in 2024 people are still trying to convince us that something as simple as a list could be slow in any reasonable scenario
I stopped worrying about cargo cult web development once I recognized that these frameworks ultimately use the same vanilla APIs and do not represent a fundamentally different path that is in conflict with anything I care about.
Somewhere in that dark JS ecosystem forest exists an actual call to document.getElementById(). The browser is going to execute it in the exact same way it would be executed from my vanilla code. There is no magic here.
So, for me the stakes are more about my experience of browsing the web getting crappier over time. Not sure how avoidable this is considering how much the web has grown in scale & accessibility. Hackernews is still a good experience (IMO), so you can't say it's all gone to hell. I don't care that others use these tools anymore. I used to need frameworks to get things done before I mastered the fundamentals.
I’m always amused that the solution proposed to the JS framework dumpsterfire is always another JS framework dumpsterfire. Instead of something sane like good ole MVC Rails or even cutting edge like Phoenix LiveView.
Like, hello, earth to HackerNewsers - the problem is JavaScript itself - not the frameworks.
"Finally, stack on top of that all this garbage code introduced by JavaScript frameworks. The magnitude of inefficiency is just insane."
Right, and it's why I turn JavaScript off by default. Pages filled with this crap are so slow I reckon I've not enough time left in my life to wait for them to load. If a site's webpages are overly large and bloated it's an indication I shouldn't be there and I'm out and away quick smart.
Moreover, as a general rule, I've found the more boated a site is the less value it has—as so much of the bloat revolves around advertising and stealing one's info. With such pages the more spent on JS junk the less is spent on its valuable content.
Just like that former frontend dev in 2016 who switched to backend, I did the same exact that year, after meeting with React & Angular. ...Although, the rationale for React (hashing and re-rendering data tree only partially) seemed very compelling.
I also remember the 2009 Crockford's lectures on Javascript where he insisted that JS was getting faster with JIT, and all the devs needed to do was to make functions return quickly and postpone the rest of the work to the async event loop.
Turned out, that expectation of high performance from JS was just an optimistic extrapolation of Google Chrome's JS optimizations. They happened in 2007-08 and probably ended in 2009 when the lectures were given.
The person writing this must have little to no experience developing UIs in classic frameworks. React has warts, but it is a decent implementation of reactive UI, given the constraints of the web platform. Of course you can achieve a speedup doing better what React does with less context - updating only the exact parts of the DOM that need updating. You will pay the price in terms of code complexity.
As for asynchronous behavior, this is not something you can avoid. You can not block on network requests, or block until the user clicked somewhere. React does not push you towards async any more than the platform does.
All platforms and ecosystems that reach critical popularity are eventually overdeveloped and under optimized. I'm a little surprised that npm hasn't been replaced yet but I'm not surprised that React is still a thing.
React has its flaws, and there are many articles pointing out its obvious issues today.
Personally, I love Web Components and Lit, but they come with a complexity that can be challenging for juniors to grasp. Making shadow DOM accessible, managing CSS, using the :slotted selector, and handling CSS variables across boundaries are just a few examples of the intricacies involved. This is only scratching the surface for one of the simpler frameworks. You need to manage a lot because it's relatively new and lacks some tooling. Solid is excellent, but its differences from React (while being so similar) can confuse people. If you want to use HTMX, you need to learn something entirely different and understand server-side templating, which becomes even more complicated if different teams in your company use different back-end technologies. Architecture follows the org. structure, so as long as front-end and UX-design stay closer to each other than the back-end, it would also be hard for HTMX to come into play.
So why React? Isn't it more complex? Yes, but it has outstanding tooling, documentation, support, and a vast ecosystem. Almost everyone knows React, even if they don't like it! Despite my personal dislike, it's one of my go-to frameworks for new projects because of these reasons.
While there are performance issues, there are many experienced developers who can address them. There are also a lot of very smart people working on various solutions.
In summary, you can argue for any framework, but please don't believe that nobody knows what they're doing. It's important to take a pragmatic approach. Also, no, front-end developers were not thinking that React were rendering on the server all this time and they also didn't think that static HTML would be slower or anything. Please don't spread false stereotypes.
That said, I believe we'll see a new approach, framework, or technology that will surpass React in the near future. While I appreciate the pragmatic, organic growth and improvement, many feel that a restart is becoming necessary.
Yes, and lit also uses the adoptedStyleSheets to style the components, but it's just one thing to tackle. There's no "just do this and everything will work" template for web components. Lit is close however, and I think web components should be the future for web development, frameworks turning into libraries (like lit) or compilers that output web components (like... stencil? Never used it personally though).
Angry man yelling at cloud (haha) article preaching to the choir. Not sure why I read it to the end, but at least I go to read the absolute gem of:
> However, if the web application is intrinsically complex, JavaScript is just not suitable, period. In this case, it’s recommended to use a proper programming language instead. For example, Blazor framework, which uses WebAssembly to run C# code directly in the browser [17]. No bizarre syntax, no winding code flow, no infrastructure madness and, especially, no bad performance.
Because running .NET on WASM is so much less insane than running JavaScript. Maybe in 30 years when WASM can do things without JS shims will that be a less ridiculous take.
> "Start with the absolute simplest ecosystem possible"
has to be the most javascripty advice ever lol. instead of "solution", uses "ecosystem". lmao.
the problem with web is and always has been that there is a million ways to do the same thing. each one has it's own trade off, and you might not discover that until you're far too deep into the muck.
Just another rant about the supposed bloat in modern web development.
> There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, “I don’t see the use of this; let us clear it away.” To which the more intelligent type of reformer will do well to answer: “If you don’t see the use of it, I certainly won’t let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it.”
But I am surprised, is that what you really see when you click on the link? I posted the direct link of the image and when I click on it I just land on the image without the imgur web page. Is that because you have the app installed?
you know, I been programing for 21 years, mostly php, c# and java.
This year i got my first job as exclusively frontend dev using Nuxt.
Not only modern javascript development is a pain in the ass, it makes me feel stupid for not kowing how to do stuff in the modern way.
The other day I had to put a small form made in other portal inside a div in the botton of the screen. This form have a url that can be accessed directly or sent via email.
I through to myself, well I will just used a iframe. Why not?
Well. aparently I had to get a javascript snipet, put in a composable, write a unit test for this composable (so it dont cahnge test coverage). call the composable from inside a component, make a unit test for this new component, call it from the main page.
But hey, nuxt is full of nuxt magic...
1 week to implement, 2 weeks to pass a god damn pull request approval.
Vanilla JavaScript these days is an absolute joy to code in (and highly performant compared to the past). Even lazy-loading modules are supported natively by the browser these days - you can go a long way just using purely built-in default functionality.
I avoid NPM and React, and live my professional life quite happily without them doing professional development using typescript and angular with bazel. For fun home projects there is deno which is also lovely. Bun looks interesting but appears to want to ape NPM so it is a no from me.