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

311–320 of 756 posts

Re: If not React, then what?

#311

Post by johnfn »

afavour wrote: post #228
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. 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.

The entire site may take multiple seconds to load, sure, but it's quite rare that this is a React issue. Typically, the real issue is something like the website making a bunch of API requests in serial rather than parallel. For instance, the issue of JSON parsing that you cited is actually an SSR issue; that's entirely orthogonal to React, and you can make the same error in any other popular web framework.

> I actually think most of the problem isn’t React itself, it’s the ecosystem and the philosophy that surrounds it so often. You’ll have React, you’ll have some extra state management library on top, you’ll have some hideous CSS in JS bulk on top because no one wants to actually learn CSS… it’s all prioritisation of developer experience over user experience. And it’s industry standard these days.

I think you're saying "React is slow" when you mean to say "the entire frontend ecosystem is slow". To which I respond... sure? None of this is React-specific. If you don't use React, you'll still have to use state management (or manage it yourself; have fun!), figure out something to do with CSS, etc, etc.

Re: If not React, then what?

#312

Post by hasanhaja »

troupo wrote: post #270
simonw wrote: post #37

A fun thing about reading Alex is that you can tell he's had the same arguments over and over again for a decade now and he's frustrated with having to keep on making the same points and getting the exact same responses. Most of the people commenting on this piece won't have read this whole article (it's long, and internet attention spans are short). As a result, you'll find plenty of the comments here were exactly p…

> A fun thing about reading Alex is that you can tell he's had the same arguments over and over again for a decade now and he's frustrated with having to keep on making the same points and getting the exact same responses. The sad part is that it's the same increasingly hostile arguments he's making while he spent the decade making sure that browsers remain bloated and tech requires Javascript to even barely function…

> and tech requires Javascript to even barely function: see his entire work on web components.

I'm confused by this characterization of web components. While they can minimally work without JS now (i.e., declarative shadow DOM), the whole premise builds atop of how the web and the browser works, and that is progressive enhancement. Your browser starts showing you the content before all of the content has finished downloading, and as it finishes, it progressively enhances the content of the page. Web components is a part of that story.

Why do you want web components to work without JS? Do you also put the same constraints on frameworks?

Re: If not React, then what?

#313

Post by johnfn »

qudat wrote: post #227
johnfn wrote: post #188

Earlier quoted context omitted.

I agree with most of what you said. As a minor nit, my understanding is that you call into a library, whereas a framework calls into you. Since React typically does most of the calling into my components I think it’s fair enough to call it a framework.

That’s a nice description but it is not perfect. React does one thing well: view = func(state) It doesn’t have a great story for virtually anything outside of that single function which means for many large apps it is never enough.

I didn't say it does? I am just spliting hairs over the definition of framework.

Re: If not React, then what?

#314

Post by lolinder »

afavour wrote: post #228
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. 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…

These disagreements almost always boil down to one side saying "some people use React to build content-oriented websites" and the other side saying "but most of us are building web applications".

In a typical web application use case (yes, there are exceptions) you're only rarely looking at usage from old or cheap Android devices. Occasionally you'll see a tablet, but even that's rare. The vast majority of the time your users are on either Chrome or Safari on a relatively modern Mac or Windows machine. In many cases the application loads once at the start of at least 10+ minutes of work, so initial load times rarely matter much.

If you're building a website that needs SEO, then yeah, React is completely the wrong tool, and you should just make a proper static site or hook your marketing team up with WordPress (or whatever takes its place once Matt is finished blowing it up). But those use cases, while common, represent a tiny fraction of total engineering effort across the industry, so most web developers here don't have the design constraints that make React a bad choice.

Re: If not React, then what?

#315

Post by johnfn »

LtWorf wrote: post #273
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…

> But front end performance issues are almost never the most pressing issue Tell me your websites are unbearably slow without telling me your websites are unbearably slow :D

I've spent plenty of time optimizing performance. It almost always comes down to a backend issue, unless the frontend is doing something profoundly stupid, like making multiple API requests in serial when they could be batched or parallelized.

Re: If not React, then what?

#316

Post by quantadev »

baobabKoodaa wrote: post #284
philipwhiuk wrote: post #131

Earlier quoted context omitted.

Jesus Christ, a 1300 line single file codebase.

Not a single file codebase

> Not a single file codebase.

Yes it is. App.js is all the code there is. You can't count the two other files with 10 lines each. lol. Let's be honest here.

And yeah for a tiny toy project like this you can get away with having zero design, zero architecture, zero object models, zero classes, and sure since everything is zero, we can throw in "Zero TypeScript" and "Zero Frameworks". Looks like some high-schooler's first ever coding project.

Re: If not React, then what?

#317

Post by 4ntiq »

dang wrote: post #125
4ntiq wrote: post #43

Earlier quoted context omitted.

[flagged]

No personal attacks, please. https://news.ycombinator.com/newsguidelines.html Edit: since you've been doing this a lot already, I've banned the account. If you don't want to be banned, you're welcome to email hn@ycombinator.com and give us reason to believe that you'll follow the rules in the future.

[flagged]

Re: If not React, then what?

#319

Post by baggy_trough »

flimsypremise wrote: post #208
deergomoo wrote: post #147

Earlier quoted context omitted.

I think the author understands that just fine (I follow him on Mastodon and this is something he is very passionate about). To me his argument is that this shouldn't—and doesn't need to—be the case. The vast majority of sites out there would be just fine, and in many cases much better, as traditional server-rendered pages with a thin layer of JS on top for enhancements and for islands of interactivity. That massively…

Building a web application with a UI in a professional context without a frontend build is borderline malpractice. Even a "thin" layer of JS on top requires some degree of dependency management, and I personally have no desire to go back to the days of vanilla CSS, so you need a SASS/SCSS transpiler. Then there's a lot of handy things that frontend builds do, like normalizing SVG icon formats, automatic organization…

> Building a web application with a UI in a professional context without a frontend build is borderline malpractice.

This is outdated nonsense for most sites.

Re: If not React, then what?

#320

Post by quantadev »

baobabKoodaa wrote: post #308
quantadev wrote: post #115

Earlier quoted context omitted.

For any large project you need type-safe languages. 99% of experience developers (10+ years of experience) will agree with this opinion. Sure you can develop very large projects in JS, as long as you don't mind being 1% as efficient, and having 100x more bugs. In JS, refactoring a huge project is the biggest nightmare in the world and really no human is capable of doing a great job of it in a reasonable time, even if…

I don't share your opinion but I'm too tired to go into another JS vs TS debate

Me too. lol. People who don't think type-safe languages are important are the ones who simply haven't yet run into the problems you run into without type safety, and no amount of HackerNews posting is going to suddenly give them the experience to understand.
Post reply on HN