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

421–430 of 756 posts

Re: If not React, then what?

#421

Post by nox101 »

fleabitdev wrote: post #342
lihaoyi wrote: post #243

The fundamental magic of react is that it lets you write code that renders O(n) UI states in a functional manner (i.e. by returning the HTML you want) rather than O(n^2) UI state transitions in a mutable manner (by mutating the page via nested callbacks), and somehow makes it kind of fast-ish People love complaining about React, but I don't know if they remember the pre-React world where you had to write the code to…

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.

Re: If not React, then what?

#422

Post by beeflet »

teddarific wrote: post #357
firefoxd wrote: post #258

The fundamental problem with React and the like, is that it forced developers to unlearn the anchor tag. If you can change the url via js why use an actual hyperlink tag? Over the years, I'm seeing more and more unlearning of fundamental web from new frontend devs forged in boot camps.

The entire disappearance of semantic HTML tags has been sad to see. It's just all inside of inside of these days.

To be honest, as someone who like semantic HTML, it's a pain to search for an appropriate tag and then try to figure out how to undo all its quirks and re-style it.

Re: If not React, then what?

#423

Post by nox101 »

codeptualize wrote: post #361
lihaoyi wrote: post #243

The fundamental magic of react is that it lets you write code that renders O(n) UI states in a functional manner (i.e. by returning the HTML you want) rather than O(n^2) UI state transitions in a mutable manner (by mutating the page via nested callbacks), and somehow makes it kind of fast-ish People love complaining about React, but I don't know if they remember the pre-React world where you had to write the code to…

This. I still have nightmares sometimes. If you don't use a framework you will probably end up building one, and it's not going to be as good as the existing options.

I don't know if I'm convinced. I have several react projects stuck in dependency hell. If I upgrade from build in node 18+ (from 16) I start getting errors. If I try to upgrade react then 1 of the 3 external widgets I'm using barfs out. If I do manage to get upgrade I get complaints about all the best practices from react 16 that have been deprecated. If I'd written my own all of these issue would disappear because I wouldn't have made breaking changes to my own framework.

Note: you might say node 16 is old and I agree. I'd much rather be on 22. But since I can't get out of this dependency hell without days or weeks of work the projects have been stuck for years.

Re: If not React, then what?

#424

Post by satvikpendem »

hmeh wrote: post #252
satvikpendem wrote: post #236

Earlier quoted context omitted.

With React Server Components, you can have your cake and eat it too, by sending only the necessary HTML to the browser (thereby having good performance and SEO) but also hydrating with more interactivity if necessary. And I'm not sure where you think CSS in JS means you don't learn CSS, I'm not sure how you'd use it otherwise... Either way, there are CSS in JS (TypeScript) libraries that compile down to regular CSS c…

You literally cannot. You can bake two cakes. You can’t have your cake and eat it too. Server and client rendering? You must concern yourself with both. The best frameworks will not perfect abstract this for you. They can’t, it’s leaky. When the cracks show, it will be painful. CSS-in-JS? I’ve used it and fought for it. Have you ever looked at the css output? That’s not a cake I’d want to eat. Compare it to a codebas…

> You literally cannot. You can bake two cakes. You can’t have your cake and eat it too.

It is a common saying, not to be taken "literally."

> The best frameworks will not perfect abstract this for you. They can’t, it’s leaky. When the cracks show, it will be painful.

Better than before with pure server side solutions like Rails or Django, however. I use RSCs and they work just fine, because you are using TypeScript on both the client and the server, meaning there are greater abstractions that can be leveraged.

> Have you ever looked at the css output?

Not sure what CSS in JS library you used but with something like Typestyle or PandaCSS, you write CSS but in JS objects, so the generated CSS is simply turning those objects into the CSS you already wrote, not sure why it would be any different.

Re: If not React, then what?

#425

Post by satvikpendem »

afavour wrote: post #244
satvikpendem wrote: post #236

Earlier quoted context omitted.

With React Server Components, you can have your cake and eat it too, by sending only the necessary HTML to the browser (thereby having good performance and SEO) but also hydrating with more interactivity if necessary. And I'm not sure where you think CSS in JS means you don't learn CSS, I'm not sure how you'd use it otherwise... Either way, there are CSS in JS (TypeScript) libraries that compile down to regular CSS c…

React Server Components strikes me as React solving a React-caused problem with yet more React. Which is fine, I guess, if you’re already locked into the React ecosystem. But as someone that isn’t, looking at the whole proposition from the outside, it just screams vendor lock-in to me. There are too many devs out there only expert in the way React does things and can’t step outside of it. RSC is an additional crutch…

Perhaps it is vendor lock in, but the concept as a whole is not that difficult to generalize, as other frontend frameworks have their own sorts of implementations of the concept. Phoenix in the Elixir world has LiveView, for example. It's just that React's is more seamless, especially with TypeScript, as you can run JS (TypeScript) on both the client and server, so that you have greater control over exactly which components you want to be on the client versus the server without having to do so manually if you were to use something like Rails or Django. Therefore, even if you are making something like blogs, you can still use React as essentially a templating language via JSX and also use React for interactivity, for example a comment form component.

Re: If not React, then what?

#426

Post by firefoxd »

beeflet wrote: post #419
firefoxd wrote: post #258

The fundamental problem with React and the like, is that it forced developers to unlearn the anchor tag. If you can change the url via js why use an actual hyperlink tag? Over the years, I'm seeing more and more unlearning of fundamental web from new frontend devs forged in boot camps.

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.

Re: If not React, then what?

#427

Post by mythz »

My preferred Technology for non-SSG Web Apps is Blazor + Vue [1]. Where Blazor's Enhanced Navigation still gives you SPA-like navigation without any heavy client state, no client-side routing, no client build tools, no large download bundles in SPAs, etc.

Blazor static rendering provides a great UX for rendering static content, Streaming Rendering is great for pages that needing to dynamically update and any pages requiring client interactivity I just progressively enhance Blazor's static content with Vue - avoiding any npm node_modules dependencies or client build tools.

[1] https://servicestack.net/posts/net8-best-blazor

Re: If not React, then what?

#428

Post by drunkenmagician »

palata wrote: post #223
johnfn wrote: post #207

Earlier quoted context omitted.

Is it? On Hacker News it probably is, and I agree that it can drive engineers nuts to know that apps are more bloated than they have to be, but I think we’re a relatively small percentage of the population. Among my less technically/inclined friends and family I haven’t heard one complaint about, say, Spotify being slow, and certainly never any complaints about its size.

> Among my less technically/inclined friends and family I haven’t heard one complaint about, say, Spotify being slow, and certainly never any complaints about its size. They don't say "modern software is slow", they say "my computer is slow, I need to buy a new one" and they do. Let's be honest: for what the vast majority of people do on their computer, there is absolutely no need for a Macbook M3. The only reason is…

> the same for 25 years. He has a 4 years old desktop mac and the webpage takes more than 20s to load

How long did it take to load 20 years ago, on a 20 year old PC/Mac ? - seems like a very big page?

Re: If not React, then what?

#429

Post by echelon »

nox101 wrote: post #417
echelon wrote: post #192

Earlier quoted context omitted.

> React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds. Yes, there are a few specialized domains where this will matter. No, you probably don’t work in one. This is fine for solving random business integration concerns, but for application software we have to use on a daily basis, it really sucks. Modern web applications sometimes feel incredibly shitty to use. Gm…

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/

Re: If not React, then what?

#430

Post by switz »

afavour wrote: post #244
satvikpendem wrote: post #236

Earlier quoted context omitted.

With React Server Components, you can have your cake and eat it too, by sending only the necessary HTML to the browser (thereby having good performance and SEO) but also hydrating with more interactivity if necessary. And I'm not sure where you think CSS in JS means you don't learn CSS, I'm not sure how you'd use it otherwise... Either way, there are CSS in JS (TypeScript) libraries that compile down to regular CSS c…

React Server Components strikes me as React solving a React-caused problem with yet more React. Which is fine, I guess, if you’re already locked into the React ecosystem. But as someone that isn’t, looking at the whole proposition from the outside, it just screams vendor lock-in to me. There are too many devs out there only expert in the way React does things and can’t step outside of it. RSC is an additional crutch…

> React Server Components strikes me as React solving a React-caused problem with yet more React.

This is not the case. RSC solves the hydration problem, in which hydration is profoundly expensive (larger bundle sizes, more client JS to parse and execute, and slower time to interactive), when most of the UI on any website can be non-hydrated. This also gives you the ability to write server only code (which as it would turn out, reduces sending third party deps to the client even more) for free with beautiful composability to client side hydration when you need it.

Everyone hydrates at some point. Maybe you write isomorphic javascript or maybe you render a rails or python app and sprinkle in some JS. RSC enables you to do this with complete composition and re-usability.

I'll put my money where my mouth is: RSC will continue to grow in adoption and its patterns will be adopted across many UI frameworks and libraries. This wasn't a solution in search of a problem, this was a large step forward in giving us more optionality as to how we architect websites.

> There are too many devs out there only expert in the way React does things and can’t step outside of it.

This is a weird ad hominem, attacking developers' skill instead of the actual technology. There are millions upon millions of React developers, and many of us have been building successful software for a long time and step outside of React every day.

> But if you’re making something like a blog with lots of drive by visits and only small islands of reactive content IMO it’s the wrong choice.

For some use-cases it is not the best choice, and for others it's the correct one. No one is hailing React as a one-size-fits-all solution, rather it remains a great balance that scales remarkably well to many needs.

Post reply on HN