Hacker News new | ask | show | jobs
by CharlieDigital 1335 days ago
I'm at a startup that builds an e-comm platform. Currently on Next.js; evaluating Astro.

We're slowly coming to the realization that none of these platforms are either simpler or faster than what we could do with modern vanilla.

Some very basic things like show/hide images and blocks of text based on user selection require an obscene amount of code/complexity in React that in vanilla is just

  element.style.display = condition ? 'none' : 'block'
Bonus is that there's no need to think about component re-render. No need to think about hooks, callbacks, memos, effects, etc. A whole layer of complexity disappears.

From a performance perspective, there's no contest. Not only is the resultant JS more performant, having the content actually in HTML at download results in faster renders and time to interactive. Our stats show 90+% of our users are mobile so being fast and light are key parameters.

I think the author's point is that while HTML, JS, and CSS have been advancing, a generation of developers have been invested in React rather than learning the fully capable and often better underlying capabilities of modern browser platforms. There are many, many developers who have been trained in React + component frameworks with only a very cursory understanding of the underlying HTML, JS, and CSS.

Should any team use component libraries or roll vanilla? It depends on the objectives of each team. Often that tradeoff is time to market and future tech debt versus absolute performance. (I have not worked on a React project that didn't have massive tech debt not because of React itself, but the complexity ramp that arises with additional packages, dependencies, state management, and general lack of deep understanding of React's render model).

We still like Astro because it allows us the flexibility to use React (or Vue, or Svelte) in dollops where it makes sense.

3 comments

I worked with React.js for more than 5 years in a big projects and I finally burnout of it, I agree with all you said, React added a extremely complexity for simple thing, added a lot of side affects that sometimes are hard to debug and fix, fix re-render will be your daily work more that create features and in the end you get a slow application in mobile devices due the size/re-render etc.

In the end I decided to re-evaluate was I was doing, I want make the web better but with React.js I was doing worst the web

From engineering perspective react-dom is being 130kB (.min) while the other is 6-8kB AND faster in benchmark, yet the industry decided this is acceptable, I know that our engineering principle is rotten.
Indeed. This is something the the staunch React folks are missing: with vanilla, I can cut out a LOT of excessive payload.
> Some very basic things like show/hide images and blocks of text based on user selection require an obscene amount of code/complexity in React

That’s just a ternary conditional in React. How is it complex?

I'd encourage you to write it once in vanilla and once in React in jsfiddle and compare the implementations.

Then consider the render model and how it would affect page time to interactive for a large content oriented page.

I’ve written this sort of thing in both. Personally, I find the “make your view a function of your state” approach to be much easier to reason about and more maintainable. Obviously, not if the only thing your site does is this one feature. But as soon as your site becomes non-trivial, I prefer the functional / React approach.
Well, frameworks vs vanilla JS doesn’t cash out into whether it’s hard to write ‘element.style.display = “…”’ or not.
It's been while since I've heard frontend devs even speak about actual frontend. Layouts, fonts, accessibility, that sort of thing.
When I interview front-end devs, I still focus on core fundamentals and I want to see if they can build simple interactions and layouts in HTML, CSS, and simple JS via jsfiddle. My assumption is that if they can do vanilla well enough, having them do React is easy enough. The reverse is often not the case.
That's very wise.