Live data from Hacker News

Does anybody like React?

jsx.lol

241–250 of 353 posts

Re: Does anybody like React?

#241

Earlier quoted context omitted.

But why over vue? My biggest frustration has been how vue ends up moving in the direction of react. The original component architecture with the html template, JavaScript state and css styles in vue was so nice. Even the data fetching a url in the component was so intuitive.

A bit out of date, but I like the point-of-view of "The single most important factor that differentiates front-end frameworks" : https://mjswensen.com/blog/the-single-most-important-factor-...

Great article. I prefer the react model over the other models. Now it'd be good to know, with every framework, which of these it implements.

Re: Does anybody like React?

#242
post #216

After spending so long writing React code, I'm now working on a large Vue project at work. Everyone used to say Vue was the easier of the two, the more approachable option — but I'm starting to see it differently. React, in its elegance, gives you components that are essentially just functions — and beyond that, there's not much more to it (setting aside the whole Next.js ecosystem). It's the most elegant thing I've…

I never get this take. A react component is not just a function, it's a function plus a magically injected context that is accessed through hooks which requires all kinds of guarantees that you have to be aware of otherwise it will have hard to debug consequences. Imo it's anything but elegant. I did projects in all major frameworks and am building a huge angular web app currently. In angular a component is represent…

> I never get this take. A react component is not just a function,

Exactly.

I did a somewhat longer writeup a while back.

https://blog.metaobject.com/2018/12/uis-are-not-pure-functio...

The pull request is still open :-)

Re: Does anybody like React?

#243
post #123

Earlier quoted context omitted.

React was a major improvement over Backbone + Marionette. Pre-jQuery was a shit-show as they hadn't even standardised the DOM. Before that was XMLHttpRequest (particularly during my .Net WebForm days) and even had to use the ActiveXObject in IE that predated JSON.

XML, XMLHttpRequest, and XSLT in IE 5 was peak web dev for me. Never been more productive.

This feels like the equivalent of "whatever music you liked at 16 defines your taste"

Re: Does anybody like React?

#245
post #126

Earlier quoted context omitted.

>I see a lot of these "bare HTML pages" and they are lacking important stuff like i18n/a11y/WCAG compliance. Try adding all that back in and you'll see your website bloat right up. having lots of JavaScript tends to make more WCAG problems, because you do interactive stuff that needs to be described. Having bare HTML and the accessibility that is required for that is not tending to bloat in my experience.

Users need interactive stuff. If your site isn't interactive and your competitor's site IS interactive, customers almost certainly will prefer your competitor. When you try to chain that stuff across multiple backend-rendered pages, you get a whole other list of problems. If you need to track all the otherwise transient UI stuff on the BE, you have now created a whole mess of stateful APIs and turned horizontal scali…

>Users need interactive stuff.

so you argued that the need for internationalization and Accessibility was such that if you tried to add that in to bare html - css solution that you would end up getting bloated, I argued (based on my experience) that accessibility bloat actually comes from the need to support various JavaScript bits of accessibility.

To which you then argue that the JavaScript parts are needed.

If so it is the JavaSript that adds the bloat, because the accessibility bloats to support the JavaSript.

I mean I'm not against JavaSript but I have seen many sites that didn't need it; and I've been forced by work requirements to add in too much of it on sites that needed very little or even none at all.

Re: Does anybody like React?

#246
post #99

Earlier quoted context omitted.

I have never been able to pick the framework and libraries for my day job. I’m almost always working on something someone started years prior or bound to an organization that has strict choices. Personally I wouldn’t pick react :) React wins because it has become a default choice and folks like what’s comfortable to their preferences

I mean, that means someone at your work liked React enough to choose it over the alternatives. I see a lot of personal projects, solo founder applications etc running made in React. I respect your opinion but other people definitely do choose it when they have fully control of what they use.

I've been in the situation a couple of times where we had full control over choosing the frontend framework. Every time we chose React, the main argument was hirability and the fact that the engineers in question were most proficient in React. That is, inertia.

Secondly, when someone new asks me what web framework to learn, I tell them React. And the main reason, every time, is that this is more likely to get them a job, i.e., inertia.

We got here somehow. Clearly, React didn't get here purely on momentum, and must have done something less poorly than the other frameworks. But I think it's hard to deny that inertia plays a big role in its current popularity.

Re: Does anybody like React?

#247
I can see where the arguments for React's alternatives like Preact, Vue, Svelte, Solid, etc. come from. All of them are better than React at least in one aspect and React's dominance is mostly due to inertia: Developers (and now LLMs) know it better and the ecosystem is richer.

But having built websites and apps since before jQuery times, I strongly disagree with manual DOM manipulation as an alternative. Declarative, component-based approach won for a reason. These frameworks allow you to tell how the UI should look based on the state and manages the transition (either via virtual DOM diffing or fine-grained reactivity) for you. DOM manipulation requires you to write some code for every single state transition (instead of every _state_). And, in practice, it becomes unmanageable very fast, and you give up, and start writing code like `element.innerHTML = ...`, causing problems with focus and event management. It's fine for small widgets, even enjoyable, but only until you need to manage a complex UI. Then, you end up with a mess of code that is hard to maintain and debug.

I know some still feel web is not the right platform for building complex UIs but that battle was lost more than two decades ago. Web is good. It comes with accessibility features (like zooming) and works everywhere. As someone with age-related farsightedness, I hate native apps that don't allow me to zoom in with a passion (which is, almost all of them). Of course I hate websites that don't allow me to zoom even more because they had to go out of their way to disable a basic browser feature. But getting decent accessibility is harder with native apps. You basically have to build everything yourself. Web gets you 90% there for free.

React might not be the best out there and might be, one day, replaced by one of the competitors or something new. But declarative, component-based UI development is not going anywhere.

Re: Does anybody like React?

#248

As someone who lived through all major waves of JS for the last ~16 years, I do love react, in a sense: React is the worst JS framework except for all the others we've tried. I'd take React over the Angular 1 days any time. I'd take Angular 1's full-bodied MVC over the "build it yourself from scratch every time" approach of Backbone. I'd take Backbone's minimal MVC structure over the classic JQuery Soup architecture.…

But why over vue? My biggest frustration has been how vue ends up moving in the direction of react. The original component architecture with the html template, JavaScript state and css styles in vue was so nice. Even the data fetching a url in the component was so intuitive.

The company I work for uses Vue. I think the non-backwards-compatible move from Vue 2 to Vue 3 burned a lot of the current devs, so now they're stuck working on Vue 2 apps that are in maintenance mode with no viable case to clean up the mess by moving everything to Vue 3. The experiments to do it with Copilot mostly failed, although that was in the early days so another try today might work better. If we're doing something drastic to improve though, we might as well solve our "Vue devs are hard to find" problem by rebuilding it all in React at the same time.

Re: Does anybody like React?

#249
post #8

I like React. And I have seriously tried the HTMX/Hotwire camp. I wanted to make a back button use browser APIs to go back if the coming from the inbox, just link to the inbox otherwise to preserve scrolling. I had to wire the actions from the html to call the function that goes back, then in my controller determine the previous page and send the JS enabled back button or the hard link. My logic was spread out over 3…

Isn't the best way to solve the back button question to not be so damned complicated and just make certain that only things which you want to go back to ends up in the history? The whole framing of the problem just screams "structure your thing better and it won't be a problem to solve".

Re: Does anybody like React?

#250
post #170

Earlier quoted context omitted.

I've built quite complex applications (e.g. a spreadsheet app) using SolidJS as a base layer, and in that sense it scales really well. It's very easy to separate data management from the UI, so architecturally it scales well, and performance-wise we rarely had issues with it at all. The biggest issue is in finding people to work with it. If you're hiring React developers over web developers, they will probably strugg…

Implementing spreadsheets with fine-grained reactivity is basically cheating.

Haha, that was part of the reason we originally went down this route. In practice, as soon as you want to implement spills, you lose a lot of the benefits because the contents of a spill can depend on any other cell and affect almost any other cell, and you need to evaluate the spill to figure out which cells are relevant. In the end, we rewrote the spreadsheet engine to use a different mechanism that was simpler and that we could optimise better, and then hooked that into SolidJS for everything else.

I guess technically that part of the application didn't scale so well in SolidJS, but it scaled a lot better than it would have in any other framework, and we got to delay writing the engine "properly" until we'd already built everything else and got it running with real users in production.

Post reply on HN