Earlier quoted context omitted.
what is wrong with vuejs?
Nothing is wrong with Vue.js, but saying that it is less complex than React is just false.
If not React, then what?
251–260 of 756 posts
Re: If not React, then what?
#252Earlier quoted context omitted.
> 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…
With React Server Components, you can have your cake and eat it too, by sending only the necessary HTML to the browser (thereby having good performance and SEO) but also hydrating with more interactivity if necessary. And I'm not sure where you think CSS in JS means you don't learn CSS, I'm not sure how you'd use it otherwise... Either way, there are CSS in JS (TypeScript) libraries that compile down to regular CSS c…
Server and client rendering? You must concern yourself with both. The best frameworks will not perfect abstract this for you. They can’t, it’s leaky. When the cracks show, it will be painful.
CSS-in-JS? I’ve used it and fought for it. Have you ever looked at the css output? That’s not a cake I’d want to eat. Compare it to a codebase with a well architected set of css and the markup and css actually do work for you. They are clarifying and reinforce structure. There are levels of productivity you gain based solely on things being clear and not convoluted that many people in our industry cannot recognize because they are fixated on the wrong thing. Whether that be what other people are using, or what gives dopamine hits (hot reloading, cool tech, etc)
Re: If not React, then what?
#253Earlier quoted context omitted.
The overwhelming majority of default HTML actions (no JS) that happen from a mouse click do not trigger a page load. You're trying to make it sound like selecting an item from a dropdown or selecting a textbox to enter text will cause a complete page load every time unless you use an SPA framework and that's just literally completely untrue. By your measure though, it sounds as though you'd be fine if these page load…
Static sites have their place in the world, for sure. But for large sophisticated apps where a mouse click might cause a state change that might update an unpredictable number of discreet individual visual changes throughout the entire page, that's where an SPA is needed. If you call this "absurd" it really shines more of a light on your own credibility than mine.
In my experience, these apps are rare, yet SPAs are prevalent. Which is a problem.
It would be nice, from a user perspective, if boring "apps" that are mainly forms and tables would quit it with SPAs already.
Re: If not React, then what?
#254I really wish these people would pick up a history book. Unlike back-end developers, whose worth is intrinsically recognized as necessary, front-end development was lowly micro-managed job that must simultaneously keep up with customer expectations in a variety of formats while also rendering whatever slop passes for a REST API. React’s adoption was a combination of talented marketing and a genuine empathy for the frustrations of a 2010s web developer. They gave us a white-lie to pitch the idea to our managers: “It’s just the ‘V’ in ‘MVC’!”
JSX freed us from the jQuery-Rails template spaghetti. A quiet revolution soon followed and everyone’s been butthurt ever since.
Look — Server-side templates, especially the “stringly” typed variety, are a demonic chimera suitable only for depraved alchemists. There’s no type-safety, no IDE references. You’re in Hokey Pokey Hell — we start with a string, now we’re interpolating, back again, now once more deeper and let’s really put your editor’s syntax highlighter to the test!
It’s no surprise that stringly typed tools like HTMX and Tailwind are so deeply admired by mid-career developers who are frustrated by their lack of experience and eager to prove their talent. That’s all very normal and healthy, but the problem isn’t that React is too complex. Building software as team is a complex task of communication, and pretending to be illiterate doesn’t make the hard words any less difficult to read.
There’s most definitely room for improvement in React, and the team at Svelte demonstrated that you could have your state and skip the boilerplate too. Svelte’s compiler is a genius move and unfortunately for them, React’s upcoming v19 will commodify their complement.
It’s never been about replacing React — it’s about empathizing with developers and making it easier to work together.
Re: If not React, then what?
#255Earlier 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.
Re: If not React, then what?
#256Earlier quoted context omitted.
With React Server Components, you can have your cake and eat it too, by sending only the necessary HTML to the browser (thereby having good performance and SEO) but also hydrating with more interactivity if necessary. And I'm not sure where you think CSS in JS means you don't learn CSS, I'm not sure how you'd use it otherwise... Either way, there are CSS in JS (TypeScript) libraries that compile down to regular CSS c…
React Server Components strikes me as React solving a React-caused problem with yet more React. Which is fine, I guess, if you’re already locked into the React ecosystem. But as someone that isn’t, looking at the whole proposition from the outside, it just screams vendor lock-in to me. There are too many devs out there only expert in the way React does things and can’t step outside of it. RSC is an additional crutch…
Re: If not React, then what?
#257I'll continue using vanilla React, for the same reason I use Java: it's reached the coveted "boring technology" status where it's mature, stable, fast enough, and has a huge community, resources, and ecosystem. I won't let go of that easily. However, this is a pretty epic rant nonetheless.
Last time I looked at react was 2016 or so and every tutorial was referencing some different mutually incompatible version of some component (router, redux, flux, some other alphabet soup) and everyone had their own list of essential ingredients in a basic hello world app. I came away from the whole experience thinking here’s an ecosystem that needs to mature another 10 years or so before I want to even look at it (I’m not a frontend person, it’s all academic to me.)
Is there a consensus on any of it yet? How to do routing, state, builds, etc? Or is there still as many combinations of components as there are tutorials?
Re: If not React, then what?
#258Over the years, I'm seeing more and more unlearning of fundamental web from new frontend devs forged in boot camps.
Re: If not React, then what?
#259Earlier quoted context omitted.
> 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 fo…
Re: If not React, then what?
#260WOW this is a long article! Still waiting for the substance though... The only point I can agree with is that React is stupidly hard to learn. It feels like a tool made for aliens, though once you master it, it can be pretty efficient. Sorry to be the bearer of bad news, but the JS-free web isn't coming back. And if you're using modern JS, you might as well use React (or a similar tool). The user won't be able to tel…
It was so easy that people strived very, very hard to make it seem complicated - and they succeeded. Back in the day every React tutorial layered in soooooo much other stuff, Redux and a million middleware layers that completely obscured what React was.
The core of React though is really simple and no amount of attempts at complexification can destroy that.