Web Crap Has Taken Control
medium.com
medium.com
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.
So you aren’t using vanilla javascript, you’re using angular - yet another framework/library
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
Fetch API instead of ajax
Canvas API
Webgpu
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.
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.
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 honestly think the real problem is that we have a whole generation of web devs that really only know react.
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.
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.
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".
Meanwhile, as an atypical user, I would much enjoy seeing more stuff like: https://khang-nd.github.io/7.css/
(Certainly in contrast--literal contrast--to some of the flat affordance-less stuff these days.)
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.
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.
Final paragraph of the article.
On Node Kysely[0] looks quite nice and has a type-safe DX with TS. Feels nicer than Prisma, IMO.
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.
> 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
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.
Like, hello, earth to HackerNewsers - the problem is JavaScript itself - not the frameworks.
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.
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.
https://www.destroyallsoftware.com/talks/the-birth-and-death...
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.
Devices and network speeds are so much faster and tech like HTTP/2 and nginx can take it up another notch.
And as the article points out, React and rest of JS ecosystem is so much more complex than using Rails or Laravel.
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.
> 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.
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.
> 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?
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.
I think this explains pretty well the difficulties you are having.
And also, you’ve been hired for the wrong job.
And this mindset + your background just keeps explaining your problems and struggles. Don't blame the tools.