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

521–530 of 756 posts

Re: If not React, then what?

#521

Post by halflife »

hombre_fatal wrote: post #496
halflife wrote: post #484

Earlier quoted context omitted.

In class components you just could await the result and perform a set state, and that would be it. Easy as pie. But now in function components when everything is called all the time without your control you have to use escape hatches like use effect just to work around react.

Hooks let you wrap all sorts of logic (and other hooks) and return values that rerender the callsite component when changed. Just keep adding on to my hook example and you get more and more code that you need to repeat in every class component that uses it. Of course, the class component solution to this was to use an HOC, but that had its own issues like complex data flow and wrapper hell. Hooks solve problems of co…

You can just use a service instead, expose public methods and hide private while keep expending and refactoring the internal logic. The same way it’s been done for decades. The only problem is the one that react created for itself in function components which is when to refresh the render from the state.

Re: If not React, then what?

#522

Post by quantadev »

xcrunner529 wrote: post #482
quantadev wrote: post #479

Earlier quoted context omitted.

Yeah because any systems or OS programming is done in type-safe languages. lol. And BTW correlation is not causation.

That was kind of my point. You speak to type safety and all the issues not having is that would be prevented but memory safety is yet another one and is a huge issue with common platforms TODAY. So, obviously your pet issue isn’t the only one out there and there are trade offs made.

Here's how your "point" landed, according to everyone but you:

Me: "Seat belts are important."

You: "Awfully funny considering our major car accidents these days are mostly all ones with seat belts."

You're implying a nonsensical causation that's purely a correlation.

Re: If not React, then what?

#523

Post by Too »

vessenes wrote: post #458
hmeh wrote: post #249

Earlier quoted context omitted.

Ironically the first question you ask is the question people should be asking about React. Specifically, what problem does it solve, and do I have that problem? The problem most teams tend to face, and I believe part of the authors argument is that people reach for React out of an almost superstitious or orthodoxy-based belief. Likely many developers don’t even know how to build something without React. They don’t kn…

Meh. What is that self-evident alternative supposed to be? I ask as someone who crafted HTML with my father's lisp parens on computers running linux kernels which were still delivered with the pl suffix, and as someone who occasionally still occasionally tries to deliver frontend code, much to my dismay. I've made websites in so many stacks and varieties that it would be intensely boring to list or read them, and I h…

Same here. I’ve been through old and new frameworks on both client and server end, since before javascript was even on the map, from cgi, php, aspnet, django, angular, vue, lit, jquery, you name it.

Basically, I know how to build a server side rendered application, I still reach for React, I know it sucks in so many ways, accessibility, performance, complexity, and so on. I just don’t know what to pick instead. It’s the first time a framework allows seamless refactoring into composable components. Powerful, terse and type safe templating language. Clear separation between state and presentation. The developer experience is just easier, even accounting for the additional rpc needed between client and server and the hook footguns.

Do I wish there was a better way to do server side rendering. Of course. For server side rendering to take off, the story for how to gradually add interaction need to be better. Not everything is static text. The moment you need something interactive, even the most fundamental thing: date picker, form validation, expand/collpase, selection, reordering, lazy loading... sprinkling in a bit of js in a server side language become an unmanageable mess. Trust me, I’ve done it with jquery, it can get the job done but it will be a compromise, nowhere near the ease and accuracy that react gives.

Re: If not React, then what?

#524

Post by jwblackwell »

Totally agree. React and Vue are overkill and bloated, and actually lead to a worse experience a lot of the time e.g. users starting at spinning loaders with broken browser functionality (like back buton)

A hybrid approach of server-side views with a simple lib like AlpineJS or HTMX for dynamic bits is far better in most cases. The initial page load is blazing fast because the server does the work. Then, for things like filtering or updating lists, you use the lightweight library for smooth, efficient updates. You get the best of both worlds—a super-fast initial experience and the ability to add dynamic features without the React baggage (and often-neglected backend).

Re: If not React, then what?

#525

Post by Too »

harrall wrote: post #297

I've been building sites since the 2000s and I'll let you know why React or jQuery "won." It's because when you write code using these libraries, your code looks nice . I cannot say that for a LOT of libraries, especially MOST frameworks. Sorry for calling AngularJS out but look at a code sample from early Angular: https://stackoverflow.com/questions/42823436/angularjs-error... (It looks terrible.) React will be unse…

Same reason Python is eating the world. It’s technically one of the worst runtimes. Slow and difficult to distribute. Nobody cares, because code ends up short and pretty.

Re: If not React, then what?

#526

Post by 7sigma »

jwblackwell wrote: post #524

Totally agree. React and Vue are overkill and bloated, and actually lead to a worse experience a lot of the time e.g. users starting at spinning loaders with broken browser functionality (like back buton) A hybrid approach of server-side views with a simple lib like AlpineJS or HTMX for dynamic bits is far better in most cases. The initial page load is blazing fast because the server does the work. Then, for things l…

I've been using Inertia.js with laravel and Vue and its been great, no need to write an API layer. You get the simplicity of writing server rendered with the interactivity of an SPA

Re: If not React, then what?

#527

Post by conradfr »

zmmmmm wrote: post #172
MarcelOlsz wrote: post #145

Earlier quoted context omitted.

You're going to love Vue. Took me about half an hour to switch and be productive and never looked back. I've switched multiple teams/devs to it as well. If not just for the devtools experience. I switched right before all the messy React stuff started getting released.

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…

Have you tried Vue Compat?

Re: If not React, then what?

#528

Post by maigret »

beeflet wrote: post #418
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…

> hundreds of milliseconds. Yes, there are a few specialized domains where this will matter. No, you probably don’t work in one. This is funny to me, because I would think that for hundreds of milliseconds, anything user-facing is impacted. It's on the order of the human reaction time (~200ms). That's noticeable delay. I do not work in frontend, so perhaps I am misguided. But I have had bad user experience using apps…

You are not misguided. Physiology is mostly intangible but consistent. Many of the comments here willingly ignore that “yes but my use case is different and my users are patient”. Their brain will still disconnect quickly and be frustrated.

Re: If not React, then what?

#529

Post by maigret »

drunkenmagician wrote: post #428
palata wrote: post #223

Earlier quoted context omitted.

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

> the same for 25 years. He has a 4 years old desktop mac and the webpage takes more than 20s to load How long did it take to load 20 years ago, on a 20 year old PC/Mac ? - seems like a very big page?

There is supporting data that webpages have become bigger faster than the bandwidth even increased. This is like, very bad. https://www.nngroup.com/articles/the-need-for-speed/

Re: If not React, then what?

#530

Post by leptons »

LegionMammal978 wrote: post #459
leptons wrote: post #405

Earlier quoted context omitted.

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. On the other extreme, completely deferring any loading of 'below-the-fold' content until it's visible can also have horrendous consequences, if that loading involves downloading any external resources. Not every visitor can just make further requests near-instantly, and it's those RTTs that really s…

> Not every visitor can just make further requests near-instantly

We use a "loading" spinner. People know they have a shitty computer, and they'll wait an extra second instead of spending $1000 on a new computer. That kind of page speed problem isn't one we could ever fix, and it's something the user is typically well aware of being on their end, because every site is slow, not just ours.

> completely deferring any loading of 'below-the-fold' content until it's visible can also have horrendous consequences

We use a combination of lazy loading and SSR (not React SSR, it's hosted on a custom CMS). Content is SSR to maximize SEO. In some places we'll only render the first 3 or 4 items and then lazy-load the rest if it's a lot of data. Too many DOM elements at page load is also bad for the page speed score. Javascript is lazy-parsed, meaning the text of the script can be loaded in-line, but not parsed until the page is scrolled and the content is in view. Loading the text of a script isn't what slows the page down, it's the parsing of larger scripts that causes page speed issues. When the page scripts can be parsed in smaller chunks, the scrolling experience can be more fluid and the page speed test is satisfied. All images below the fold are lazy loaded. All 3rd party widgets are lazy loaded where possible, because they all suck and they mess with page speed pretty badly. There are lots of other tricks to get to a perfect 100 score on Google Lighthouse. Fortunately for us, "below the fold" is generally easy to accomplish across all of our sites, by the nature of the type of sites we are building. It doesn't work for all kinds of sites, but for ours it works very well.

Post reply on HN