Live data from Hacker News

If not React, then what?

infrequently.org

221–230 of 756 posts

Re: If not React, then what?

#221
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 to deal with. Maybe not to you, but it's by far and away the biggest complaint with any website or app that uses React/Angular under the hood in my experience. On any computer older than a few years, the sheer amount of JavaScript being demanded to be run creates serious system bottlenecks. This is literally why I cancelled Spotify, because i…

> because it's fucking absurd to me that I need a (then anyway) 700 MB app to stream music.

You only know that factoid because you're an engineer and you looked it up. Users have absolutely no clue, and literally do not care.

Re: If not React, then what?

#222

> It's the rewarding side of real engineering, trying out new materials under well-understood constraints to improve user outcomes. Good thing we’re mostly keeping the attitude to hobby projects. Can’t imagine hundreds of artisans™ bikeshedding over what the hell this even means. And I can’t read with a straight face an article talking about complexity of React while suggesting Vue (sic!) as an alternative. Lol!

what is wrong with vuejs?

Re: If not React, then what?

#223
post #207

Earlier quoted context omitted.

> But front end performance issues are almost never the most pressing issue to deal with. Maybe not to you, but it's by far and away the biggest complaint with any website or app that uses React/Angular under the hood in my experience. On any computer older than a few years, the sheer amount of JavaScript being demanded to be run creates serious system bottlenecks. This is literally why I cancelled Spotify, because i…

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 that the websites are developed by people who buy (or get from their company) a Macbook M3 and therefore don't see how much their website sucks on a reasonable machine.

I can track it very well on my father's homepage which has been the same for 25 years. He has a 4 years old desktop mac and the webpage takes more than 20s to load. On an M3 it takes 2s. This homepage is still loading exactly the same kind of information than 25 years ago, yet it is almost unbearable on a 4 years old desktop computer. Does my father say that this webpage is slow? No, because all software goes like this. My father says that his computer is now old and considers buying a new one.

Re: If not React, then what?

#225

Earlier quoted context omitted.

> But front end performance issues are almost never the most pressing issue to deal with. Maybe not to you, but it's by far and away the biggest complaint with any website or app that uses React/Angular under the hood in my experience. On any computer older than a few years, the sheer amount of JavaScript being demanded to be run creates serious system bottlenecks. This is literally why I cancelled Spotify, because i…

> because it's fucking absurd to me that I need a (then anyway) 700 MB app to stream music. You only know that factoid because you're an engineer and you looked it up. Users have absolutely no clue, and literally do not care.

> Users have absolutely no clue, and literally do not care

When their smartphone is 3 years old and has no more storage space, they say "the smartphone is old, I need a new one".

Because they don't know that this is a problem of the software industry being extremely bad doesn't mean that it has no impact on them.

Re: If not React, then what?

#226

Earlier quoted context omitted.

I'm glad you like it, but https://mithril.js.org/simple-application.html is some "uh-huh, thanks but no"

Care to be specific? Is it the documentation you don’t like? Is it the example application’s design you don’t like? Or is it something about Mithril itself?

Two things, in descending order of rage-close-tab for me: that m(.., [m(), m()]) is deeply unserious, and .then((result) => User.list = result) just seems oppressively singleton (although I'm open to that being a tutorialism but why even show users antipatterns if that's not how it's going to work for real?)

I tried to be neutral in my reply, so if you like it then I'm glad for you, and I hope your colleagues find gainful employment when they have to go to their next job that also uses Mithril. But I hope I never ever have to work in an organization which thinks a shitload of m() functions is easier to read than JSX

Re: If not React, then what?

#227
post #188
post #187

> The choice isn’t between JavaScript frameworks, it’s whether SPA-oriented tools should be entertained at all. For most sites, the answer is a clearly “no”. “Most sites” sit in the world of marketing, ecommerce, blogs. True, they don’t need an SPA. Then there are businesses that “require” highly dynamic websites with tons of data funneling through them. I use require here in the sense of business requirements set by…

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.

Re: If not React, then what?

#228
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 parsing a giant lump of JSON before you can do anything, that’s particularly CPU intensive and takes time on low end devices.

> Yes, there are a few specialized domains where this will matter. No, you probably don’t work in one.

Again: I beg to differ. Anyone hoping that their site will rank well on Google needs to factor in site performance via core web vitals. Time and time again I’ve seen React-based sites perform horribly and it’s very difficult to dig your way out of the hole after the fact.

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.

Re: If not React, then what?

#229
post #207

Earlier quoted context omitted.

> But front end performance issues are almost never the most pressing issue to deal with. Maybe not to you, but it's by far and away the biggest complaint with any website or app that uses React/Angular under the hood in my experience. On any computer older than a few years, the sheer amount of JavaScript being demanded to be run creates serious system bottlenecks. This is literally why I cancelled Spotify, because i…

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.

People just stopped complaining and search for workarounds on themselves or just suffer silently.
Post reply on HN