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

631–640 of 756 posts

Re: If not React, then what?

#631

Post by pier25 »

goobert wrote: post #149
pier25 wrote: post #108

Earlier quoted context omitted.

If React is so great how come Amazon isn't using it in their store? I think last year an Amazon frontend engineer wrote some tweets explaining they tried React and it was too slow. So they keep using Java for SSR and sprinkle vanilla JS. They were still using jQuery until a couple of years ago and probably still are in some parts of their site.

React is in use in many heavily used frontends at Amazon, maybe not the retail site But there's no inherent reason React couldn't be used for a page that basically shows pictures of products with a description next to them, the bottlenecks will have nothing to do with the frontend in a well engineered system for that type of site

> maybe not the retail site

I'm discussing the retail site specifically because that's where CWV matter.

If a company has internal tools that take seconds to load it doesn't really matter. Captive users don't have much of a choice.

Re: If not React, then what?

#632

Post by pier25 »

andybak wrote: post #177
pier25 wrote: post #104

Earlier quoted context omitted.

I doubt it's a matter of style. There's a lot of tribalism and irrational opinions around React.

I strongly dislike React on pragmatic and philosophical grounds. I don't feel particularly irrational.

I was arguing the opposite. That there's a lot of irrationality in devs using React.

Re: If not React, then what?

#633

Post by pier25 »

whs wrote: post #625

I'm trying to build server rendered websites, but I find React (or other SPA-API systems) hard to resist: - Form is hard. Doing it in backend make it even harder when the form is complicated. For example, a form with tab needs JS to operate and you need to signal the JS which tab the error is. - If you're using backend form framework, you don't have control over the HTML unless you learn the hook points of it (do you…

> a form with tab needs JS to operate

Yes, this use case is better solved client-side but even in an SSR app you can always use rich widgets/web components in React, Preact, Vue, Svelte, etc.

> I wanted to build a new user wizard

Use some JS component(s) or web component(s) as I pointed out earlier.

> In HTMX your backend needs to have a "full render" endpoint and a "table only" render endpoint

See fragments:

https://htmx.org/essays/template-fragments/

> I haven't see any good backend framework that has similar server-rendered frontend component like React

Plenty of backend solutions give you SSR components that are composable and where you can colocate template with backend logic. See Razor pages in dotnet or Astro.

> but I know of no Next.js-style library for any frontend framework that actually allow form submission without JavaScript AND progressive enhancement with JavaScript using the same code

I'm 99% certain SvelteKit and Remix allow you to do this.

Re: If not React, then what?

#634

Post by gls2ro »

Wool2662 wrote: post #575
gls2ro wrote: post #492

Earlier quoted context omitted.

So the company that invented it does not know how to properly use it? Or are you implying that React does not fit FB use case?

He's literally saying the front end technology doesn't matter at all in this. Are you just going to defend React to the bitter end? Or do you just enjoy imaginary binary choices?

I think I was not clear in my question:

I don't defend React. My question was almost the opposite and I was trying to ask:

So if even Facebook has a problem with using React then who has a better examplea about why and how to use it?

Re: If not React, then what?

#635

Post by [deleted] »

exceptione wrote: post #584
gf000 wrote: post #564

Earlier quoted context omitted.

E-commerce sites are a pretty good fit for SPAs. Sounds like a bad rewrite, nothing more, nothing less.

Why do you think that? The only client side component of interest would be filtering and sorting, (although the server could render the new state too). I would choose traditional server side + a little bit of client side code here.

[deleted]

Re: If not React, then what?

#636

Post by johnfn »

gls2ro wrote: post #634
Wool2662 wrote: post #575

Earlier quoted context omitted.

He's literally saying the front end technology doesn't matter at all in this. Are you just going to defend React to the bitter end? Or do you just enjoy imaginary binary choices?

I think I was not clear in my question: I don't defend React. My question was almost the opposite and I was trying to ask: So if even Facebook has a problem with using React then who has a better examplea about why and how to use it?

Like I said, React has nothing to do with the slowness issues of messenger.com.

Re: If not React, then what?

#637

Post by johnfn »

ramones13 wrote: post #505
johnfn wrote: post #441

Earlier quoted context omitted.

(Sorry, somewhat copying this, since I responded to a similar point elsewhere.) This is not practical advice for the vast majority of software engineering teams. Most teams do not have the privilege of being able to do research and prototypes across multiple options, at least in a way representative of what their final product will look like. Most teams - at least those in small to mid-size startups - will start out…

My experiences don’t really align with yours - most people are playing “follow the leader” with tech - “X uses Y, so we should to” and that’s it. To your point though - use the platform. Vanilla HTML, CSS, and JS. All of that will be reusable no matter where you pivot and not lock you in to a pattern that might not work well for where you land.

> Vanilla HTML, CSS, and JS

This is a non-answer. It only really is an admissible solution if you're just working by yourself. React solves real problems when building web applications. If you use vanilla HTML, CSS and JS, you're going to have to solve those same problems. How are you going to do it? How are you going to manage state? How are you going to synchronize your state with the DOM? How are you going to organize your components?

Teams that use vanilla HTML, CSS, and JS end up eventually building an internal, buggy, half-implemented, undocumented version of React.

Re: If not React, then what?

#638

Post by CSSer »

plantwallshoe wrote: post #398
ninkendo wrote: post #257

Earlier quoted context omitted.

Maybe it’s time I learn it… Last time I looked at react was 2016 or so and every tutorial was referencing some different mutually incompatible version of some component (router, redux, flux, some other alphabet soup) and everyone had their own list of essential ingredients in a basic hello world app. I came away from the whole experience thinking here’s an ecosystem that needs to mature another 10 years or so before…

IME there is a general consensus: Routing: react router (not very good imo but widely accepted and good enough) state: No libraries. Just use “useState” and if necessary “useReducer” Builds: vite Then pick a query caching library so you don’t need to treat fetched data like its application state… ReactQuery is widely accepted and very good. Apollo if you’re using graphql

I'd throw in the occasional context provider store. However, the point absolutely stands that most likely don't need a state library in React anymore unless you're learning it to maintain an older codebase.

Re: If not React, then what?

#639

Post by azangru »

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…

> It means downloading MBs of javascript just to render a simple page.

React + react-dom minified gzipped is around 60kB. Yes, this is a lot; but no, this is not MBs of javascript. If your (simple) pages download MBs of javascript, that means you have added lots of other stuff on top of react.

While I completely agree that react is unnecessary for simple sites, react itself is not guilty of megabyte-size javascript bundles.

Re: If not React, then what?

#640

Post by hmeh »

bluecheese452 wrote: post #627
hmeh wrote: post #590

Earlier quoted context omitted.

> The problem is building a front-end UI with compositional components (essentially the only way to build anything substantial) Server-rendered front end frameworks (like Rails) have units of composition as well (partials, helpers). > with sane handling of state, and with acceptable performance for interactive use (which means not round-tripping to the server every time, sadly, otherwise I'd keep using Wicket) What "…

Not really surprising that a rails shop is going to have a easier time with rails than react.

Not a Rails shop. We did React and Node almost exclusively for 6 or more years. My first React project started in 2014 or so. I mentioned this in several comments. We had done Rails in the distant past, but using Rails was actually a risk for us because there were things we knew how to do with React from recent experience we would have to learn for Rails server rendering.
Post reply on HN