Web Crap Has Taken Control

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.

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.

    > 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....

[0] https://chrlschn.dev/blog/2023/02/react-is-the-new-ibm/

[1] https://npkill.js.org/

I honestly think the real problem is that we have a whole generation of web devs that really only know react.

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.

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.

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.”

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.