I love vanilla TS (with some micro libraries). However, this article is crap. It's just statements without any examples. How did using vanilla JS improve your app? Is it just performance? What does the project structure look like? Which tips/tricks do you have for vanilla JS? I haven't learned anything new from this article, why does it get upvoted?

The author has missed a critical insight from their evaluation — the fact that they could develop a tool in vanilla JS more simply than React is only because they first developed it in React. Developing with a framework gives you the advantage over bespoke tooling — you can experiment and iterate faster. It is only having had that experience, and exploring the problem-domain so clearly by building it once, does the second build happen to quickly.

So yes, maybe React was over-engineered for their problem. But I think they only realised they over-engineered their problem after having over-engineered their problem...

A better point would be "I used React to test-build an app then to build it again natively for speed."

--

As an aside, I do agree that React (and I'm extrapolating this to many of the web frameworks) have an incredibly steep learning-curve and onboarding cost. I'm an avid Vue fan and I've found the architecture around Vue 3's "single-page components" to have created so much technical debt and complexity that I spend more time debugging the build pipeline then actually developing. I still like the flexibility and acceleration I get with Vue, but Vite often leaves me feeling like I'm just fighting the framework... I guess I just miss Gulp.

There is virtually nothing in this article.

I can only assume we’ve adopted the Reddit pattern of upvoting sentiment at this point.

I'm a VP of Engineering and have been a TL at major React shops.

I don't agree with this statement: "The best benefit to all of this, in my opinion, is that it allows more junior-level people build interfaces that they wouldn’t otherwise be able to build at all. I say, React has commoditized the web app development."

In my experience, React is pretty complicated for junior engineers who don't grok how the actual runtime works. On the other hand, what React has really enabled is for large frontend teams to exist and work together meaningfully. I remember the days of vanilla JS and large codebases. I can imagine that today those codebases would be easier to maintain and work on due to things we've learned and developed (thanks to React, by the way), but I still strongly believe that the productivity gains from React for a team greater than like, 2 front end people on a project that needs to be maintained for longer than 6 months is worth the effort.

As someone who got out of the web dev game before reaact, I feel like everyone using react has led to most of the web sites (and mobile apps) feeling slow. My judgy view is that when you see apps that appear to be single page but take noticeable time to load their content - that's react. And as someone who built a spreadsheet app in.. say 2006, you have to go native to get good performance. But I base my observations on no real data :)

Removing millions of lines of code does speed up your application. Removing react and the 100 NPM modules helps. Removing Java and the 100 Jar files helps. Removing Django/Laravel/Rails/etc... helps reduce calculations and memory.

There are a lot of instruction abstraction layers that just aren't needed. Older games are a great example. I am still amazed at the size of the modern StarCraft, Rollercoaster Tycoon, or CS:GO executables with all the new layers of emulation and compatibility stuff. Sometimes even 10x the original size.

However, there are ways to use libraries like react (preact.js anyone?) without a dozen plugins and a huge runtime layer. Look at HTMLX, the new cool kid that was originally an XHR request that inserts document.querySelector(name).innerHTML = response and is now a large package of 145KB of JavaScript.

Part of the issue is the growth of these frameworks and part is that the developers don't know how to use them in performant ways. They're just trying to ship stuff, performance is optional.

Not a great article. The big thing is JSX; it's so much more pleasant than building UIs with the document/element api.

I felt like I had just finished the introduction and the article was over. I wish this had gone a lot further into depth.

How has this article landed on the frontpage? There is 0 substance - are people even reading it before upvoting?

I was excited to see the author's reasoning and some code to support the claim. Then I reached the end of the page.

> But building complex apps is easier, compared to React.

This is distinctly the opposite of my experience. Being able to reuse common components makes logic encapsulated. The browser sort of has this with custom elements, but that adds its own level of complexity.

React, despite everyone's best efforts with CRA and other tools, is hard to get up and running with. It just takes time, and you inevitably need to eject. But once you codebase gets big, idiomatic React (at least in every case I've worked with) is much easier to scale than rolling your own everything.

Then show the app? Not the screenshot of the app. The app itself.

I will never understand why so many use unnecessary complex things, especially if better and simpler things existed befor and after.

OK, but at what cost ? How much time investment ? How much experience is required ?

Is this article written by a marketer ?

I just don't see how to do this without half-assing a framework and then it's not really Vanilla anymore is it?

A lot of people don't know how to use react. The author is one of them.

Not a single code example. Crap article.

To denigrate so much of modern web technologies in the name of performance, and then use Typescript, over which you have no fine grained control of the performance of the transpiled code, is absolutely laughable.