React also gives you React Native, that's why.
https://infrequently.org/2024/11/if-not-react-then-what/#%22...
His response to native code and plug and play native plug-ins is using webviews?
If not React, then what?
431–440 of 756 posts
Re: If not React, then what?
#432Earlier quoted context omitted.
>No more JavaScript limitations. But you accept a whole host of other limitations with WASM. It's a trade-off. You still need to access the DOM, which can't be done directly from WASM. Maybe someday it will happen? Okay, so use canvas instead and do all UI inside WASM? That seems like reinventing the wheel that is Javascript + DOM. WASM has plenty of uses, but replacing Javascript probably isn't where it shines. Java…
> You still need to access the DOM, which can't be done directly from WASM. Maybe someday it will happen? You can access the DOM through JavaScript glue. These Rust WASM frameworks do that: - Leptos: https://www.leptos.dev/ - Sycamore: https://sycamore.dev/ - Yew: https://yew.rs/ - Dioxus: https://dioxuslabs.com/ Eventually you won't need the glue. > Okay, so use canvas instead and do all UI inside WASM? You can do t…
>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 frameworks you mentioned are used very much, there's simply not the ecosystem for them that there is for Javascript for user interfaces.
And this is what they mean when they say "use the right tool for the job". I'm not going to use ffmpeg ported to Javascript, because that would be slow - of course I'm going to use ffmpeg in WASM to transcode video in the browser. And I'm not going to replace React with something in WebAssembly no matter what language, because it's just far easier to write the UI in React. Or even jQuery, or even just plain old vanilla Javascript.
Javascript is a very easy language to work with, in spite of what the people that don't really understand Javascript think about it. The only reason to do UI in WASM is that you don't understand Javascript or you have an irrational hate for it, or "because reasons". But sure, do whatever you want to do, I'm in no way saying you can't. Just don't expect that WASM will be replacing Javascript in any real way, anytime soon.
Re: If not React, then what?
#433Earlier quoted context omitted.
The top sites using react are all e-commerce or social sites. I would bet the majority of react sites and devs that use them are not building apps that require SPA or something like React. Which is the problem.
> I would bet the majority of react sites and devs that use them are [n]ot building apps that require SPA or something like React. [edited to restore what I assume is the ended meaning] On what basis do you bet this, though? Sure, you see sites that bug you by being slow in contexts where you'd choose something else, but most devs are working on sites and apps that you will never see , because you're not the target d…
But there is a wide gulf between backend + JQuery and SPA. The frustration often shown is people treating the extremes as the only options available. Having a use case for which backend + jQuery doesn't cut it doesn't require reinventing navigation state and history in JS, or loading every stat on the page via JSON. There are middle grounds.
Re: If not React, then what?
#434Reading 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. Try opening facebook.com; click the messenger, (+1 second) Click one of your chat groups (~2 seconds) This is merely just to show something From what I have seen, its quite easy to have performance issues with React
So easy in fact that even the company that makes React can’t use it in a way that makes their site fast.
Re: If not React, then what?
#435Re: If not React, then what?
#436Earlier quoted context omitted.
Why would you think rust will make the web sing? Their HTML documentation generator uses 571+ dependencies. So, hello more bloat! If the core rust team can't avoid it why would you think any other rust project would?
Why would an HTML generator need to slim down on dependencies? It's designed to run in CI, not respond in real time to user requests. It very infrequently runs and generates production artifacts with humans out of the loop. This is a bad argument against Rust in the frontend. Web frontend development is very nascent in Rust, but there's already cool stuff taking shape: - https://www.egui.rs/ - https://leptos.dev/
You’re both right. It’s not as important that a documentation generator be blazing fast, but it’s a bad sign. If the core team finds themselves using 571 dependencies for something as simple as a documentation generator, how many thousands of dependencies will the average small business, trying to deliver value to customers quickly, end up using to create a line-of-business web app?
Re: If not React, then what?
#437Earlier quoted context omitted.
You're going to love Vue. Took me about half an hour to switch and be productive and never looked back. I've switched multiple teams/devs to it as well. If not just for the devtools experience. I switched right before all the messy React stuff started getting released.
I started with Vue and switched to React, because of better library and TypeScript support. Every other framework pales in comparison to React due to its ecosystem, and I'm not gonna spend time building new packages to bridge that gap when I have my own work I need to get done, so I'll just use React and npm install what I need.
What gap needed bridging for you?
Re: If not React, then what?
#438Earlier quoted context omitted.
You're completely right, but I think it's worth adding that the O(n^2) to O(n) change isn't specific to React or UI. That same improvement is often seen when migrating other code from a mutating style to a pure-functional style. "A pure function which transforms the entire input into the entire output" is obviously the simplest possible architecture for many programs, but people hesitate to use that architecture beca…
React doesn't have this "pure function" feature what-so-ever. hooks are magic stateful functions, not pure functions. They behave differently the second time called and therefore have all kinds of side-effects and restrictions on when, where, and how they can be used.
Accumulative recursive functions also behave differently the second time they are called...
Hooks are a declarative DSL for accumulator arguments to the recursive function (the component).
If you would rather rewrite the render loop in continuation passing style, and have a 46 line recursive call expression which conditionally changes like 15 immutable parameters to set up the next render iteration for your component, I'd like to see the code when you are done.
Re: If not React, then what?
#439Earlier quoted context omitted.
> You still need to access the DOM, which can't be done directly from WASM. Maybe someday it will happen? You can access the DOM through JavaScript glue. These Rust WASM frameworks do that: - Leptos: https://www.leptos.dev/ - Sycamore: https://sycamore.dev/ - Yew: https://yew.rs/ - Dioxus: https://dioxuslabs.com/ Eventually you won't need the glue. > Okay, so use canvas instead and do all UI inside WASM? You can do t…
>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 climate change catastrophe than ever before.
So not only is JavaScript slow it's also an ecological disaster.
You've convinced me. Brendan Eich has a lot to answer for.
Re: If not React, then what?
#440Earlier quoted context omitted.
I started with Vue and switched to React, because of better library and TypeScript support. Every other framework pales in comparison to React due to its ecosystem, and I'm not gonna spend time building new packages to bridge that gap when I have my own work I need to get done, so I'll just use React and npm install what I need.
What gap needed bridging for you?
Back when I switched, I was looking for a good drag and drop library as well as a node based diagramming library. React Flow for the latter is best in class, and it's simply unavailable for other frameworks.