Earlier quoted context omitted.
Jesus Christ, a 1300 line single file codebase.
Not a single file codebase
Sorry:
a codebase with a 1300 line file.
If not React, then what?
741–750 of 756 posts
Re: If not React, then what?
#742Earlier quoted context omitted.
> If they were using useState() correctly and provided a button or link to call the update function, yeah, React would call into their code as many times as the user clicked the button. As it is though, it's just once (useEffect with that second argument is "only run the passed-in function once on mount"). As I understand it both the useState and useEffect create points where their code will be suspended and resumed…
Nope: The first run through, useState() returns the default value and your code runs to completion. When the update function is called, that entire React function is run again, but this time useState() returns the new value instead of the default value. Likewise useEffect(), your React function runs all the way through and the callback passed to it is run afterwards at various times depending on the dependencies arra…
> The first run through, useState() returns the default value and your code runs to completion.
Your function was still sliced into the part before and the continuation (Dispatch) after though, right? The React runtime calls that continuation immediately with the default value, so you don't notice the suspension, but control flow wise it's still React calling your code twice rather than once.
Re: If not React, then what?
#743Earlier quoted context omitted.
Nope: The first run through, useState() returns the default value and your code runs to completion. When the update function is called, that entire React function is run again, but this time useState() returns the new value instead of the default value. Likewise useEffect(), your React function runs all the way through and the callback passed to it is run afterwards at various times depending on the dependencies arra…
> The first run through, useState() returns the default value and your code runs to completion. Your function was still sliced into the part before and the continuation (Dispatch) after though, right? The React runtime calls that continuation immediately with the default value, so you don't notice the suspension, but control flow wise it's still React calling your code twice rather than once.
Nope, it's a normal function that updates some variables in the React module then returns two values. There's a little bit of magic going on, with how it knows which component it's in, but that's happening outside of the individual hooks.
Re: If not React, then what?
#744Earlier quoted context omitted.
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…
How do you know that was a React issue and not a memory leak, or an error in your own code perhaps? This smells of a memory leak, particularly if you forgot to add a dependency to a hook for example, but there is plenty of non react related code that could go wrong with drag and drop interfaces too
Not using any hooks, it's simple old-school react started from create-react-app, then converted over to Preact, and then updated to use latest webpack and all libs updated to latest versions, so this project has gone through many changes and I have no doubt if I started it new today from the ground up things would be different. I think the problem was with the drag-drop library, react-dnd I think. But the point is that switching from DOM to a canvas solution fixed all the problems I was having.
Re: If not React, then what?
#745Earlier quoted context omitted.
Phones are literally sold at different prices when they have more storage. People are familiar with being unable to install more apps or take more pictures. Happens all the time. Get out of your bubble.
You are in the HN bubble. Layman users do not notice . They only care if the app works or not. A 700MB app on a phone with at minimum 128GB is nothing.
If you use your phone for just 1 app… sure.
I've never encountered anyone at all doing that though.
Re: If not React, then what?
#746I've spent years slowly migrating a personal project from PHP to Scala/React, and I'm devastated if React is out-of-date already. The web tech treadmill is relentless! Seems the author recommended HTMX as an alternative in a couple of scenarios including my own use case ( https://caption.me ). I checked out HTMX. The canonical example on the homepage ( https://htmx.org/ ) was a button where a click calls the server a…
yes, htmx is very much suggesting returning HTML rather than JSON from the server, and collapsing a layer of complexity in the process. this has turned out very well for some applications, dramatically lowering complexity: https://htmx.org/essays/a-real-world-react-to-htmx-port/ looking at caption.me, I see nothing that couldn't be effectively addressed using this hypermedia approach, and I suspect it would simplify…
As I understand it, HTMX front-end components aren't re-usable in the same way as ReactJS components.
HTMX components are 1:1 coupled with back-end code. So if I try to build a complex UI with nested structures, I'm going to have to build a parallel structure in back end.
The back end will have to manage all state, so there will be round trips for everything and things in server side memory that could be managed easily on the client side. That would affect the scalability and maintainability.
I'm not getting a sense of why HTMX would be better than a pure client/server approach. I have no attachment to "hypermedia," or any other concepts penned in the 1960s!
Re: If not React, then what?
#747Reading 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…
To your third point - the author would recommend doing research and prototyping with all the options you might consider based on your use-cases. He actively avoids being prescriptive in generic contexts like this because he wants to avoid arbitrary dogmatic solutions (like React tends to be). Source: I work closely with him and have been frustrated with this stance until I saw people using Next and Remix for things l…
This is a really good article that puts very clearly some of the WTF moments I've had since having to take over a React project. However, if the title is "If not React, then what?", then the author should've answered that question.
I did find some recommendations for other reactive front-ends buried in the article, but I didn't see anything that set them apart aside from the fact that they are smaller projects. Now, if I want to follow the article's advice and get off of React I have a ton of research to do, research that the article's title didn't hint that I'd have to get going on.
Re: If not React, then what?
#748Earlier quoted context omitted.
yes, htmx is very much suggesting returning HTML rather than JSON from the server, and collapsing a layer of complexity in the process. this has turned out very well for some applications, dramatically lowering complexity: https://htmx.org/essays/a-real-world-react-to-htmx-port/ looking at caption.me, I see nothing that couldn't be effectively addressed using this hypermedia approach, and I suspect it would simplify…
As I understand it, HTMX front-end components aren't re-usable in the same way as ReactJS components. HTMX components are 1:1 coupled with back-end code. So if I try to build a complex UI with nested structures, I'm going to have to build a parallel structure in back end. The back end will have to manage all state, so there will be round trips for everything and things in server side memory that could be managed easi…
I don't know what you mean by reusable: you can reuse anything you create on the server side via various techniques (e.g. template inclusion, or using something like JSX for SSR, etc.)
A complex UI with nested structures covers a lot of area: the DOM is fundamentally a complex UI with nested structures. I'd need more specific examples to say anything intelligent about it.
htmx certainly doesn't necessitate round-trips for everything. HTML itself doesn't (see detail elements and HTML5 form validations) and client-side scripting is perfectly compatible with htmx:
https://hypermedia.systems/client-side-scripting/
htmx is better than a pure client/server approach in some cases because it relies on the already-built hypermedia client, the browser. This can, in some cases, dramatically simplify & improve applications:
https://htmx.org/essays/a-real-world-react-to-htmx-port/
(67% reduction in LoC, 96% reduction in dependencies, halved memory usage, 50% decrease in first load time)
Looking at your application, it appears to be amenable to the hypermedia approach, but I didn't do a deep dive on it. OTOH of course, if you are happy with the current approach I don't see any reason to move to hypermedia for its own sake.
Re: If not React, then what?
#749Earlier quoted context omitted.
As I understand it, HTMX front-end components aren't re-usable in the same way as ReactJS components. HTMX components are 1:1 coupled with back-end code. So if I try to build a complex UI with nested structures, I'm going to have to build a parallel structure in back end. The back end will have to manage all state, so there will be round trips for everything and things in server side memory that could be managed easi…
I don't know what you mean by reusable: you can reuse anything you create on the server side via various techniques (e.g. template inclusion, or using something like JSX for SSR, etc.) A complex UI with nested structures covers a lot of area: the DOM is fundamentally a complex UI with nested structures. I'd need more specific examples to say anything intelligent about it. htmx certainly doesn't necessitate round-trip…
Interesting. Thanks for the details, and for the link to the React->htmx migration.
Re: If not React, then what?
#750Reading 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…
> React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds. 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 pa…
> 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 low end devices.
Try doing it on a flagship handset like a Pixel 8 Pro, and it's still a slow and miserable experience.
m.facebook.com, as an example.