Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

If not React, then what?

infrequently.org

Post reply on HN
Print view View original

451–460 of 756 posts

Re: If not React, then what?

#451

Post by leptons »

peutetre wrote: post #439
leptons wrote: post #432

Earlier quoted context omitted.

>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 fram…

> But only in processing power Only in processing power? 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…

Wow. I've never seen anyone make a sky-is-falling argument about Javascript to this level before. Bravo? /s? Either way it's an impressive reach.

Re: If not React, then what?

#452

Post by peutetre »

leptons wrote: post #451
peutetre wrote: post #439

Earlier quoted context omitted.

> But only in processing power Only in processing power? 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…

Wow. I've never seen anyone make a sky-is-falling argument about Javascript to this level before. Bravo? /s? Either way it's an impressive reach.

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.

Slow scripting languages don't make you eco.

You have to think bigger.

Re: If not React, then what?

#453

Post by oefrha »

peutetre wrote: post #450
oefrha wrote: post #447

Earlier quoted context omitted.

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.

Ah, so you want to use TinyGo. Makes smaller binaries: https://tinygo.org/

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.

Re: If not React, then what?

#454

Post by wordofx »

johnfn wrote: post #168

Reading over the authors primary reasons to not use React, they strike me as fundamentally misguided - mostly solving problems that most people don’t have. One reason it says that React is a poor choice is performance issues. But front end performance issues are almost never the most pressing issue to deal with. React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds…

In 2024. React is probably the worst choice you could make when creating a new web application.

Re: If not React, then what?

#455

Post by crabmusket »

throwaway284534 wrote: post #254

I hope that I’m not the only one who feels the anger emanating from these sort of blog posts. It’s stuff like the Qwik developers claiming things like “Hydration is pure overhead” as if it’s the mathematical proof that keeps their reality from crumbling. It’s the same thing on YouTube with people like Theo, gnashing their teeth at how Tailwind is incredible; You’re objectively stupid for not liking what I like; You’r…

> Server-side templates, especially the “stringly” typed variety, are a demonic chimera suitable only for depraved alchemists

I couldn't agree more with this. Components and TSX are a much nicer way to build UI trees, even on the backend.

Re: If not React, then what?

#456

Post by wordofx »

synergy20 wrote: post #18
hu3 wrote: post #11

Earlier quoted context omitted.

No need for personal attacks. And there's also the other side: people who insist in overusing React. Perhaps that's what the author refers to. I for one have see HTMX eat React for breakfast in a few of my clients during consulting.

Really? HTMX for me brings spaghetti code on the server side. Fine for small projects but not so for large ones. I would prefer the clear separation between frontend and backend beyond small scale projects.

React does not create a clear separation. Anyone who claims that hasn’t worked on any react bigger than a todo list.

If you struggle with backend code then you’re just not a good backend developer. Maybe just stick to HTML/CSS.

Re: If not React, then what?

#457

Post by beeflet »

firefoxd wrote: post #426
beeflet wrote: post #419

Earlier quoted context omitted.

There are some good use cases for this, for example soundcloud uses this to prevent reloading the page (and thus stopping the music when you click a link)

Fun fact, soundcloud uses links. React can use links and still be dynamic. The problem is without it, you break the browser history, you break long press menu on mobile, you lose the link preview in the status bar.

damn that's true. Soundcloud history sucks. It's unfortunate that there isn't a solution to this in the web standard.

Re: If not React, then what?

#458

Post by vessenes »

hmeh wrote: post #249
johnfn wrote: post #168

Reading over the authors primary reasons to not use React, they strike me as fundamentally misguided - mostly solving problems that most people don’t have. One reason it says that React is a poor choice is performance issues. But front end performance issues are almost never the most pressing issue to deal with. React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds…

Ironically the first question you ask is the question people should be asking about React. Specifically, what problem does it solve, and do I have that problem? The problem most teams tend to face, and I believe part of the authors argument is that people reach for React out of an almost superstitious or orthodoxy-based belief. Likely many developers don’t even know how to build something without React. They don’t kn…

Meh. What is that self-evident alternative supposed to be? I ask as someone who crafted HTML with my father's lisp parens on computers running linux kernels which were still delivered with the pl suffix, and as someone who occasionally still occasionally tries to deliver frontend code, much to my dismay.

I've made websites in so many stacks and varieties that it would be intensely boring to list or read them, and I have NO IDEA what he thinks is better, or even if he is able to disambiguate the React architecture from the React library/stack, or which one he is talking about.

It's a tome, a full tome, without a clear position.

Mine is this: a truly state based rendering and eventing engine for frontends is a dream, a beautiful dream, not unlike the beautiful dream of a purely functional language based on the lambda (or rho?) calculus. The dream giveth and it taketh away, and it is always a fundamentalist dream; where that fundamentalism hits the cracks of reality is where engineers have to make tradeoffs.

The React architecture stack (well, the stack without prop drilling) stays somewhat beautiful as a dream in my opinion, which is to say it provides guide- and guard-rails to stay relatively productive delivering mid size applications across millions of devices without a ton of moments where I'm like "what the fuck is the rule of hooks, and how did I break it here?"

The react library stack, and by extension the node stack: sucks balls, full stop. I'm happy to get some other framework which has write/compile-time type safety, modularity and an eventing/rendering system that abstracts away most of my concerns for delivering over the web and is lighter weight, has less dependencies, etc. However, if the author wants me to change my ill-begotten ways, it would probably be more effective to explain how it is that each of the items in his list: "Preact, Stencil, Svelte, Lit, FAST, Qwik, or any of a dozen faster, smaller, reactive client-side systems" provide a better world.

In this area, I believe I'm a journeyman, reading a senior / master engineer's writing -- fine. But he is not informing me at all. I don't want to go learn the recommended 18 (12 unnamed) smaller client-side systems that apparently require less mental bookkeeping of me. I'm not even sure what that means -- I code tsx in vim, and do not feel like I have to do a lot of bookkeeping.

So, back to you -- what's your recommendation? I'm genuinely curious what you think would be better. Or the author, if he wants to butt in here. I just don't understand what you (or the author) thinks should be done. The forms processing and server rendering (say with Perl 5 and tcl were two early langauges for me) were not that great.

Re: If not React, then what?

#459

Post by LegionMammal978 »

leptons wrote: post #405
johnfn wrote: post #311

Earlier quoted context omitted.

> I disagree. Try loading up a library heavy site (i.e. React plus a half dozen associated helpers for state, UI and whatever, which is pretty common) on an old or cheap Android device. It can take multiple seconds before the page is fully loaded. Even once the libraries are loaded, React sites often involve parsing a giant lump of JSON before you can do anything, that’s particularly CPU intensive and takes time on l…

API requests at page-load are definitely going to lower the page speed score. No API requests should happen at all, ideally, and all script and CSS to render everything "above the fold" should be loaded in-line. Nothing that is visible "below the fold" should ever run or load until the page is scrolled down by the site visitor. Only the bare-minimum script parsing that is required for the content "above the fold" sho…

> Nothing that is visible "below the fold" should ever run or load until the page is scrolled down by the site visitor.

On the other extreme, completely deferring any loading of 'below-the-fold' content until it's visible can also have horrendous consequences, if that loading involves downloading any external resources. Not every visitor can just make further requests near-instantly, and it's those RTTs that really slow pages down, in my experience. Excess API calls are just one (very common) source of excess RTTs.

The obvious compromise would be to load 'below-the-fold' content ASAP once all 'above-the-fold' content is finished, unless it's unacceptably heavy for the target device. (Then again, some people still won't be happy: I recently talked to one person who derided the load times of a certain blog, but I found that all of its meaningful content was loaded and visible very quickly: they were only taking issue with the Disqus comment widget at the bottom at the page.)

Re: If not React, then what?

#460

Post by vessenes »

wordofx wrote: post #454
johnfn wrote: post #168

Reading over the authors primary reasons to not use React, they strike me as fundamentally misguided - mostly solving problems that most people don’t have. One reason it says that React is a poor choice is performance issues. But front end performance issues are almost never the most pressing issue to deal with. React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds…

In 2024. React is probably the worst choice you could make when creating a new web application.

...and the best would be?
Post reply on HN