Hacker News Reader

Comment by nopassrecover | Hacker News Reader

So I’ll say that I absolutely echo the post and general comments.

I’ll also say, which I feel is a pariahable comment in 2024, that with 18 years of dev exp through the cycles of Web 1.0, 2.0, everything being a SPA, server-side rendering craze, and then wherever we are now, I just don’t get the hype around React for 95%+ of the scenarios it is used for. It is just so much more harder to get things done, to maintain them, to skill up. The complexity just feels superfluous. Like the Weekend at Bernie’s situation that is “agile methodologies” these days, my gut says this current world of tech must be far more shaped by economic and organisational factors.

By contrast, on face value alone, something like Svelte feels so much closer to how programming used to feel.

View on HN

On the contrary, I think React still is fantastic, and I have been using it since 2015. I think you all have forgotten how terrible it was to get anything done without breaking things in the server side rendered apps of yesteryear. I remember, because I maintained one of those until 2021. Endless cycles of regression testing. Trying to make any of those pages client interactive, within two days you are longing back to something like React. In theory, you could introduce a little React on those pages, but since it is an older server side rendered app, there are no APIs to call, all the features are html pages that return mountains of markup. None of the css is consistent, and even a button is not a single button, its 25 slightly-almost-the-same-button. At least with React there is a good chance those would actually have ended up as the _same_ button component.

In my opinion, the reason React still has staying power is the care with backward compatibility, and the fact that its very focused on being a View Library. State management and routing frameworks come and go, but those all live outside of React the library. React doesn't directly force you to have your CSS a single particular way. It's still mainly concerned about being a javascript library, even as JSX is quite far from JS, it is mostly fairly obvious how it ends up being plain JS.

I agree, I recently had a client pay me to use ASP.NET MVC for a new website and it was _terrible_. So many easy things were not only hard, but the docs were just not there. It was extremely difficult to handle even basic layout changes. If I knew it really well, I still think it would have been slower than react to build, by an order of magnitude.

I don’t get the hype either. React makes some very difficult things easy but it consumes anything it touches. You’re stuck reimplementing basic browser behavior because React treats the browser as a compiler. It doesn’t extend the browser.

React throws away decades of development and tooling.

Before anyone starts screaming, you can use react for progressive enhancement. But I’ve never seen it used that way.

imo remix (https://remix.run/) does a great job at that

I literally have no idea what you are talking about. What "basic browser behavior" are you reimplementing that React is blocking you from?

React is a great component-based (functionally pure-ish? puritan!) view library, but when all you have is a render() function things start to look like components even if they looked like something else before.

And then, of course, a whole cottage industry sprung up around it, from create-react-app to hideous HOC form managers. It soon started to became a proper cult, attracting true believers who shunned types, who got burnt by just a bit too much webpack configuration craziness, and then VC money pured in and ...

And now the king is dead, long live the king. All hail HTMX!

Conflating React with webpack is disingenuous at best.

I think some version of HTMX / SvelteKit for bigger apps is the future. React is a dead-end, and it only lumbers on because so many people have staked their careers on it. It's the string theory of the webdev world.

HTMX is nice if you really really really want to couple your backend to whatever happens on the frontend.

And yes, yes of course, it makes sense for at least half of whatever anyone is doing nowadays. I'd even go as far as to say that HTMX with the microfrontends idea is the ideal for large organizations with microservices-like independentish features.

... that said, there's a good chance that eventually HTMX will become a WASM kernel capable of transmogrifying a well-annotated OpenAPI endpoint into some kind of UX-positive behavior. And at that point we can, again, finally free the forms from the frozen frontend frontier!

I'm not even convinced that Javascript + JSON fat client architecture is decoupled. It hides the fact that the browser is for better or worse a hypermedia client.

It's a spectrum! (Insert bell curve meme with "everything is connected" on the tails and "noo! that's too coupled" in the middle ! :D)

It's also a lot of trade-offs in a big bundle. (How many people will work on the codebase? At the same time? Is the problem well-defined enough to agree on an API? How much "API evolution" are we expecting? Are there going to be wildly different user journeys based available based on state? Is this Roy Fielding persona in the room with us now? How experienced the developers are? What tools do they know well? How's the infra/devops/deployment story? Do we need to setup Maven and rebuild the whole J2EE JAR/WAR thing in order to change the CSS? Insert everything is an optimization problem meme! :`] )

And whatever stack a particular project ends up picking is just the current culmination of roughly two decades of very strong path-dependence, which itself is a result of a very weird non-cooperative speedrunning through various iterations of these problems. [0] And while the ecosystem will happily continue to churn the project will likely not have the luxury to rewrite everything every few years, so the developers ought to pick something they are comfortable with for the next X years. (And to solve for X we need to know whether this is a personal project or it's the current flagship darling of a soon-to-be multi-trillion dollar company...)

[0] For example both Flash and Java have been sent to sleep with by JavaScript, because they were not able to coevolve with that scrappy thing which was initially thrown together by in 10 days. So it made a lot of sense to not pick JS, and to keep as much as possible on the server-side, or pick Flash for some amazing UX! But the JS engine was eventually secure and built-in to every browser and JS code could be delivered fast.

Having a "backend-for-the-frontend" is unavoidable even in a SPA. Your real backend starts behind that.

React is the closest to just letting me write code in a real programming language, making HTML/CSS/Web stuff a detail. At first glance, HTMX and Svelte are unappealing, because they put these web concepts on a pedestal.

Svelte is too opinionated about how I need to structure my files for me

I prefer unopinionated frameworks

Maybe SvelteKit is, because it offers file-based routing (which I like), but Svelte itself is very unopinionated.

It's the weirdest thing to me how opinionated sveltekit is compared to how unopinionated svelte is. Hard to believe it's from the same people.

I've bitten the bullet with sveltekit, and it does get the job done I have to admit.

Honestly, I think that's great. If you want a full-featured, batteries-included framework that makes most of the hard choices for you, SvelteKit is a great alternative to Angular or Next.js. On the other hand, if you just want some interactive sugar on your HTML pages, Svelte will stay out of your way.

Sort of a newbie to agile/devops here but could you explain the comparison to Weekend at Bernie's? I only know the basic premise of the movie but can't follow how to fit agile methods vs older programming methods into the movie. Thanks!

Bernie was dead but only two guys knew that, he appeared alive and well to everyone else.

Don't worry Svelte 5 will "rune" that feeling and pull you back into the React world.

Solidjs is hitting the spot for me lately. It’s basically react rewritten to actually use reactive views instead of virtual DOM diffing. Your code looks like react but the js bundle is smaller, simpler and faster.

But if you aren’t interested keeping up with “JavaScript framework of the week”, you can do a lot worse than react.

Reply on news.ycombinator.com