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

461–470 of 756 posts

Re: If not React, then what?

#461

Post by lolinder »

ysavir wrote: post #433
lolinder wrote: post #379

Earlier quoted context omitted.

> 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.

What middle ground do you propose that's as efficient to get rolling as React in 2024? You talk about not reinventing state and history in JS, but at this point the reinvention is already done and React is the pragmatic choice that you pick when you don't want to reinvent the frontend.

There are a bunch of stacks that I prefer to work in for my own projects, but what I need at work is almost always the standard option that everyone is already used to.

Re: If not React, then what?

#462

Post by wyclif »

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…

One of the ways you know a project is going wrong is when it's using JS to do things that HTML and CSS should be doing.

Re: If not React, then what?

#463

Post by johnfn »

yawaramin wrote: post #391
smrq wrote: post #377

Earlier quoted context omitted.

They literally just said "unless the frontend is doing something profoundly stupid".

That's the norm in the React world nowadays. You should take a look at https://infrequently.org/2024/08/object-lesson/

This article is better, but has very little to do with React. The major issues I see are 1) loading a 2.5 MB AWS library (not React), 2) not doing SSR (not React) and 3) not tree shaking (not React). I agree these are all problems. But shouting to the skies about React is not going to solve them.

Re: If not React, then what?

#464

Post by albedoa »

leptons wrote: post #405
johnfn wrote: post #311

Earlier quoted context omitted.

> 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 l…

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…

> Nothing that is visible "below the fold" should ever run or load until the page is scrolled down by the site visitor.

I really hope nobody takes this "advice". What are you trying to save me from?

Re: If not React, then what?

#465

Post by diob »

johnfn wrote: post #168

Reading 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…

Yeah, poor performance is possible in any system using any tech. Being able to diagnose it and fix it is what matters.

I've never had a performance issue I couldn't fix in React.

Re: If not React, then what?

#466

Post by slotrans »

johnfn wrote: post #168

Reading 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.

Many years ago I worked at a wonderful company that made the terrible decision to rebuild the frontend in React. We had a performance dashboard permanently displayed on a TV in the office, prominently showing the p99 time-to-interactive of our home page. It sat at TWENTY SECONDS for at least 2 years. No progress was ever made, to the best of my knowledge.

This was an e-commerce site, more or less. As per the author's reasoning, it absolutely should not have been an SPA.

Re: If not React, then what?

#467

Post by slotrans »

ls_stats wrote: post #303
afavour wrote: post #228

Earlier quoted context omitted.

> 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…

>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. that was the case in 2015 when entry level android devices were quite slow, nowdays a cheap $200 android phone has at least 4-6GB of RAM and an eight core processor. if that isn't enough for your react powered site, you are doing something very wr…

Multiple times daily I encounter sites that are brutally slow not just on my beefy Android phone, but on my 3GHz+ 8-core 64GB desktop machine.

You need to take performance seriously or it will just be bad. Most of the industry has chosen to be bad.

Re: If not React, then what?

#468

Post by quantadev »

baobabKoodaa wrote: post #389
quantadev wrote: post #380

Earlier quoted context omitted.

Even considering chatbot.js, it's still a small enough toy project to just barely get by without type safety. I don't consider a project "large" until it's in the 30K to 50K LOC at least, where it becomes impossible to literally remember where each use of any given variable is. Type Safety catches most typos at build time, and also allows ease of refactoring. Only these small projects can get by without type safety,…

The question in this thread is not TypeScript vs JavaScript. It's framework vs no-framework. Specifically, is it possible - possible at all - to create an interactive web app without frameworks - one that isn't "just a document" or "brochure-ware". I've demonstrated pretty clearly that yes it is possible. You people just keep shifting the goalposts further and further... Now it doesn't count unless it's 50K LoC? As i…

I never saw anyone on this thread deny that JS CAN be used without frameworks. As a developer since before the internet even existed I've written probably at least two to four million lines of JS in my life, so I'm well aware.

What people are saying is that for LARGE projects you NEED a framework. And your app is tiny. It's got like two source files. So it's just an example of a tiny project getting by without a framework. I have a couple of those currently myself, because I don't need a framework for them. They're just HTML+CSS+JS.

Re: If not React, then what?

#469

Post by quantadev »

baobabKoodaa wrote: post #392
quantadev wrote: post #381

Earlier quoted context omitted.

I literally said the exact opposite. I don't care what language you use as long as it's type-safe. Any language that lacks type-safety is completely inappropriate for large-scale projects. There's no seasoned developer on the planet who disagrees with that sentiment. None. Zilch. If some guy claims to be #1) decades experienced and #2) doesn't like type-safe languages, then he's lying about either #1 or #2 or both.

First it was "10+ years experience", which would qualify me, but now you shifted the goalposts again to "decades" experience. Lol. I guess you can keep pretending that everybody who matters agrees with you when you just count everybody who disagrees as someone who doesn't matter

I originally typed "seasoned developer" and then I edited it to say decades. Neither one of us has perfect definition of "seasoned developer" in terms of precise years, and it doesn't even matter.

But there are some things that are obvious to any seasoned developer and the value of type-safety is one of them. It's not my opinion. Is a fact. And yes if you say you have 10+ yrs and you don't prefer type-safe languages, then yes I indeed do not even believe you.

Re: If not React, then what?

#470

Post by quantadev »

baobabKoodaa wrote: post #396
quantadev wrote: post #381

Earlier quoted context omitted.

I literally said the exact opposite. I don't care what language you use as long as it's type-safe. Any language that lacks type-safety is completely inappropriate for large-scale projects. There's no seasoned developer on the planet who disagrees with that sentiment. None. Zilch. If some guy claims to be #1) decades experienced and #2) doesn't like type-safe languages, then he's lying about either #1 or #2 or both.

Also, we're talking about the web here. How many type-safe supersets of JavaScript are there? When you say "I don't care what language you use as long as it's type-safe", you're pretending as if there's more viable options than just TypeScript.

There is a choice on the server side too, to go with type-safe languages or non-type-safe ones. When I'm stating something as true and general as the importance of type-safety I speak as broadly as possible, because I'm indeed NOT talking about just TS when I say "type safety", I mean it everywhere computer code exists. All untyped languages are garbage.
Post reply on HN