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

611–620 of 756 posts

Re: If not React, then what?

#611

Post by gf000 »

ricardobeat wrote: post #567
gf000 wrote: post #556

Earlier quoted context omitted.

Which react sites? Are you sure you are not a victim of confirmation bias? How often do you check what framework does a smooth and performance website uses? Because demo sites are snappy on even low-end devices. It's not react itself that causes slowness, but all the other libraries/tracking/ads.

This answers your questions: https://astro.build/blog/2023-web-framework-performance-repo...

Which (correctly) doesn't even have react listed, only frameworks that (may) use react as a library.

So at least be specific what is problematic, is it a particular framework, a particular library, the whole idea behind react (v=f(s)) or what? Anything can be proven against something non-concrete.

Re: If not React, then what?

#612

Post by grey-area »

alexanderchr wrote: post #594
grey-area wrote: post #549

Having seen some large react codebases I’d agree wholeheartedly with this article. React solves problems we don’t have any more (eg IE), badly, at the cost of poor performance, lock-in and a host of other problems that other solutions just don’t have. It means downloading MBs of javascript just to render a simple page. It encourages multiple loads of massive json payloads for bits of the page which are then translate…

React was never intended to solve browser inconsistencies. Of course it developed hand-in-hand with the tools that solved those (transpilers, polyfills, bundlers), but that was not the main reason it was invented or became popular. The original motivation was to describe UI as a function of state. It sounds trivial, because it is when server rendering, but once you start sprinkling enough interactivity it can get mes…

Yes that’s a good point sorry I just gave one e.g. from the article of IE event handling.

Re the original purpose of react being syncing state, I’m really not sure this small problem is actually worth the trade-offs of massive complexity and lock-in, nor that react is a good solution for it (double renders, persistent rendering bugs, use state, hooks etc).

It’s not something important to lots of apps and there are loads of other options from simple polling to web sockets to reloads, this can be done in a far simpler way without react. Also the use cases where this is central are really quite small.

Re: If not React, then what?

#613

Post by grey-area »

branko_d wrote: post #588
grey-area wrote: post #552

Earlier quoted context omitted.

I disagree that SPAs are the only solution to some problems. This is an orthodoxy which people buy into but there are always a few different approaches possible. What do SPAs actually offer which is unique? There are multiple possible solutions to most problems, including gmail or google maps for example. Just because you want to load code and data dynamically doesn’t mean you need to buy into SPAs (the followers of…

> I disagree that SPAs are the only solution to some problems. I disagree with that too. Did I ever say otherwise? I do believe, however, that there are problems for which a SPA offers the best trade-off. Not the only solution, but the best trade-off. > This is an orthodoxy which people buy into but there are always a few different approaches possible. Like the orthodoxy that "nobody needs an SPA"? > What do SPAs act…

I think we mostly agree, I meant people choose it - they don’t need to do things that way.

Re: If not React, then what?

#614

Post by agumonkey »

pjerem wrote: post #493
agumonkey wrote: post #326

Earlier quoted context omitted.

To me it goes beyond the looks. Angular terminology and semantics were always very alien. React is no angel either, but it seems influenced by older, more tested concepts (FP and such). That said, I think client side UI/UX is about to see yet another large wave of change. Hearing chats from solidjs devs make me feel that there's a whole new and saner space to describe simple and fast programmable interactions.

I’m going to be the devil’s advocate because I’m from the team "no SPA at all unless you have a real need like real time" but to me, Angular is the less worse when it comes to writing SPAs in teams. Clumsy and hard to learn ? Sure. The code looking less cool than other frameworks ? Of course. Unbearably slow compiler ? Check. But at least you got a full fledged, batteries included framework, with a powerful DI system…

> an established architecture to follow. Not the funniest framework but it works.

yeah, that's worthy, especially in teams, it avoids friction most of the time

Re: If not React, then what?

#615

Post by gf000 »

hmeh wrote: post #593
gf000 wrote: post #563

Earlier quoted context omitted.

So now you have two, entirely separate worlds that don't compose in any way, and you have to create "DTO"s to convert from one to the other and back. Don't get me wrong, I would much prefer coding in a single language for both backend and frontend, and I would not choose JS/TS for that. But your choice is that, only a decent choice. Just like react is. There are so many ways to do web development, and neither of thes…

> So now you have two, entirely separate worlds that don't compose in any way, and you have to create "DTO"s to convert from one to the other and back. "Now" being what specifically? The technologies I mentioned allow everything to happen on the server. We've got a relatively complex set of applications: 30 deployed apps, composition using SSI (server-side include), collaborative form entry for complex form including…

Then every significant (you can get away a lot with very tiny js and/or css, like menus) user interaction will necessarily cause a server round-trip, which is definitely perceptible by humans, no matter how fast your internet is - so it's a bit dishonest to claim that React is "slow".

As I said, this is definitely a viable approach, but so is react. Both would fit like 80% of all websites just fine, given that they are developed by decent developers.

Re: If not React, then what?

#616

Post by peutetre »

pier25 wrote: post #109
peutetre wrote: post #90

The only sure cure for the JavaScript blues is WebAssembly. Use something like Leptos and be happy: https://www.leptos.dev/

Leptos is even worse than React in memory consumption and startup metrics. https://krausest.github.io/js-framework-benchmark/current.ht...

But faster overall, one code base front and back, and it will only improve as new WebAssembly features roll out (js-string-builtins, Memory64, eventually component model DOM access).

And any high performance functions you need on the front end will be higher performance than JavaScript. Like bloom filters for example: https://nuenki.app/blog/bloom_filters_optimisation

Re: If not React, then what?

#617

Post by peutetre »

leptons wrote: post #534
peutetre wrote: post #452

Earlier quoted context omitted.

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.

Yes, let's save the electrons so we can mine bitcoin with them. /s oh, oh, wait - I have an idea! Let's just write everything in 8-bit assembly language, that will let us really optimize and save all the electrons for bitcoin mining! /s You really are barking up the wrong tree. Going after Javascript as if it's the reason the planet is doomed, or even makes any difference at all in the grand scheme of things, is just…

Some people just have no ambition.

Re: If not React, then what?

#618

Post by peutetre »

incrudible wrote: post #341
peutetre wrote: post #90

The only sure cure for the JavaScript blues is WebAssembly. Use something like Leptos and be happy: https://www.leptos.dev/

WebAssembly can't do anything without Javascript. You're still using the same annoying Web APIs with another layer of indirection between. Plus, now you're using the slow Rust compiler so your iteration times are going to suffer. We already have type-safety in Typescript. We don't have to care about lifetimes, either.

> WebAssembly can't do anything without Javascript.

But it's JavaScript glue code generated by Rust's wasm-bindgen that you don't need to care about. And eventually the glue code will be unnecessary with wasm component model DOM access.

Re: If not React, then what?

#619

Post by ricardobeat »

gf000 wrote: post #611
ricardobeat wrote: post #567

Earlier quoted context omitted.

This answers your questions: https://astro.build/blog/2023-web-framework-performance-repo...

Which (correctly) doesn't even have react listed, only frameworks that (may) use react as a library. So at least be specific what is problematic, is it a particular framework, a particular library, the whole idea behind react (v=f(s)) or what? Anything can be proven against something non-concrete.

Yes.

Re: If not React, then what?

#620

Post by Marazan »

mikl wrote: post #325
Marazan wrote: post #260

Earlier quoted context omitted.

React is really easy to learn. Stupidly easy. It was so easy that people strived very, very hard to make it seem complicated - and they succeeded. Back in the day every React tutorial layered in soooooo much other stuff, Redux and a million middleware layers that completely obscured what React was. The core of React though is really simple and no amount of attempts at complexification can destroy that.

Hello world might be simple, but you don’t have to build very much before you start to run into problems with the simple “props down, events up” and you start needing to learn about contexts, hooks in general and so on. Hooks is really one of those things where you need an IDE to tell you that you’re doing it wrong, since there’s a whole bunch of footguns. It’s doing its best to solve a hard problem inside the limita…

As someone who developed in Adobe Flex back in the day I find React so straightforward that as long as you keep an iota of discipline then even events, contexts and hooks feel "easy" compared to every other attempt at large Rich Internet Application approaches I've seen.

Just like in Flex the difficulty (and don't get en wrong often extreme awful difficulty) comes when someone fights against the system and can cause a cascade of terribleness. There were always telltale red flags when looking at Flex code when someone tried to circumvent the component lifecycle and the same smell can be spotted in React code.

Post reply on HN