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.
Sadly, I don’t see an alternative. To make it on HN, an article needs to break off of /new. If an article only lasts on /new for 20-40 minutes, an article that takes 20 minutes to read and digest is unlikely to garner enough upvotes to make it off /new.
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 :)
No no. Your observations are correct. The coolness of web hooks prevents anyone from seeing how chaining multiple async operations into a single call chain makes things slow. I know...I know. This is Javascript and the level of abstraction is far beyond the metal I just described. But that's kind of the point here. It's possible to abstract yourself into a performance problem. We've reached peak abstraction.
You’re missing part of the picture. It also takes a huge time to develop, and requires people with a lot of experience in FE architecture, or you’ll mess up your redux.
Yeah, state management has always been a problem on the web.
For others who might not be familiar, redux is a library you can add to your react project to help manage state. There are others but redux seems to be the most popular.
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.
> 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.
Author here. I've used React Table for this, which has like 20k+ stars on Github.
It's slow.
Imagine you want to edit a cell in a spreadsheet with 40k rows. You MUST create a new array, otherwise React won't update the DOM.
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.
Very little typescript changes your code in a way that would be meaningful for performance. I think enums are one case. It's not like it changes your loops or adds object copies or anything like that
Typescript is pretty much a 1:1 mapping to "modern" Javascript plus type annotations. It will only do non-trivial code transforms when compiling to an old JS version.
Of course one could argue that Javascript itself doesn't allow much control over performance.
Do you know any specific cases in which typescript generates badly performing code as part of transpiring to JS? Any cases that aren't due to targeting older JD versions for browser compatibility?
