Live data from Hacker News

If not React, then what?

infrequently.org

201–210 of 756 posts

Re: If not React, then what?

#201
post #172

Earlier quoted context omitted.

I'm having trouble forgiving Vue for the backwards compatibility issues and short support period from Vue 2.x => Vue 3.x. I'm now faced with unnecessary cost to upgrade line of business apps built with Vue that in full maintenance mode but now have critical security vulnerabilities popping up in scanners with no way to fix them other than large scale code migration. I saw they are now dropping support for Vue 2 even…

That's actually fair and my one gripe with Vue, and I just spent the past week and a half porting over my old project that I wanted to resurrect. If they screw with my vue3 using composition API then I'll dust off my pitchfork.

Week and a half… sounds nice :,)

Has gitlab finished upgrading yet? Last time I checked they spent 2+ years and that’s with codemod tools and super smart engineers.

At work, I spent a month upgrading one project to work with the compatibility build and we’ve been slowly migrating for the past 18 months. After the end of this year, we should be out of the woods for that project but then we have 3 more so…

Luckily, Evan has said that he has zero interest in fracturing the community again and I believe him. The new architecture of Vue 3 also makes it very easy to adopt almost any new paradigm into Vue as evidenced by the numerous demos Evan has made to compare Vue to other JS frameworks like Svelte and Solid.

Re: If not React, then what?

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

Yes, I think you’re right. I overwhelmingly agree with his articles, but when I share the content with my colleagues it gets at best a careless shrug, but most often what amounts to “but [technology referenced] is good because it’s popular.” React is one of those problematic choices companies continue to make.

Re: If not React, then what?

#203

I never liked React. I'm primarily a backend developer, and preferred server generated HTML with a sprinkling of Javascript. It may sound ridiculous to some, but I miss the JQuery days. For newer projects I'm looking at Elixir / Phoenix / LiveView and HTMX.

Look at Imba. If you are strong enough to avoid cargo culting and try things which aren't popular, they are some of the best ways to build frontend apps out there: https://imba.io/

Re: If not React, then what?

#205
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. 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…

> This is fine for solving random business integration concerns, but for application software we have to use on a daily basis, it really sucks.

And more than it just sucking, it is unnecessary. We have mature, well documented, cost effective solutions for developing software that have been around from years to decades. We know how to develop software. The problem is people trying to develop software with web tools.

Re: If not React, then what?

#206
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. 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…

> Heavy software users spend hours within are where those hundreds of milliseconds per action really add up. We should be angry about anything worse than single digit milliseconds with these tools.

I think in the article writers mind here we are talking hundreds of milliseconds on first load and the majority of actions are instantaneous after that.

This can be achieved, but it takes some diligence and product mind focus to optimize what you can how you can and even big companies like Google don’t always prioritize this the way they should

Re: If not React, then what?

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

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.

Re: If not React, then what?

#208

I don't think the author of this article actually understands the pressures that increasingly drive all frontend development into javascript frameworks, but those pressures are actually very straightforward: • A large portion of the cost of maintaining a code repository goes toward maintaining the build. • Multiple builds per repo create significant costs. • Any web application with a UI _requires_ a frontend build f…

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 of static assets etc. The fact is the "islands of interactivity" model still requires two builds.

Re: If not React, then what?

#209
post #52

Earlier quoted context omitted.

Out of curiosity I checked on iPhone 14/4g and 2018 Intel MBP. I don't get what the point of these comments is ? If you're using RPI with a 2g connection you'll have a bad experience shopping at the site ? And somehow that's supposed to factor in to my tech stack decisions ?

Alex's position is that the average consumer is on a cheap Android phone, which has severe CPU weaknesses compared to any iPhone from the last ~five years: https://infrequently.org/2024/01/performance-inequality-gap-... Software engineers tend not to experience the web on the same class of device as most of their users.

But is the average Target shopper on a cheap Android phone accessing over non-broadband? Wayfair?

It's a fair point to note devs and users might have different devices, but in some cases they don't and the decision to use React might be well-founded with that fact.

Re: If not React, then what?

#210

I think almost any technology gets to the "this is stupid" point. Not it "was" stupid, but it is. We understand something so well, we know that despite being useful it is fundamentally flawed. This is not usually verbal knowing, but initially more from an intuition and understanding a pattern. I have used react, it was certainly a better choice than the alternatives. I like it. But it is now "stupid", at least for me…

These are cool demos, I agree, and they definitely show a glimpse of what the future of the web could look like. Right now though, pretty much all of them take ages to load, then spin my fans up as they run at low fps. And this is on a dev laptop, can't imagine what they're like on mobile or an older device.
Post reply on HN