Going from React to Vanilla JavaScript(alexbezhan.substack.com)
alexbezhan.substack.com
Going from React to Vanilla JavaScript
https://alexbezhan.substack.com/p/going-from-react-to-vanilla-js
35 comments
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.
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 can only assume we’ve adopted the Reddit pattern of upvoting sentiment at this point.
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.
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 :)
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.
I wish I were joking.
I wish I were joking.
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.
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.
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.
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.
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.
Author here. JSX makes it easy to do easy things.
Building DOM is not a hard problem at all. Yes, it's more tedius with Vanilla DOM. But that's not a hard problem.
Hard problem is making it fast, reliable and predictable.
Building DOM is not a hard problem at all. Yes, it's more tedius with Vanilla DOM. But that's not a hard problem.
Hard problem is making it fast, reliable and predictable.
I thought JSX was independent of react, but react built on and popularized it.
> ...building UIs with the document/element api.
When the whole premise is flawed, JSX or not, does it really matter if there is a better or worse way of misusing a technology not meant for UIs?
Leave HTML and JavaScript to Wikipedia and other hypertext document libraries.
Unfortunately, WASM is not there yet, but people are trying: https://platform.uno.
When the whole premise is flawed, JSX or not, does it really matter if there is a better or worse way of misusing a technology not meant for UIs?
Leave HTML and JavaScript to Wikipedia and other hypertext document libraries.
Unfortunately, WASM is not there yet, but people are trying: https://platform.uno.
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?
React is a legacy, 10-year old technology. People are thirsty for something new, even if it is about going back to basics.
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.
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 ?
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.
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.
No you just update the cell. React is extremely fast if you understand how rendering works. Avoid unnecessary rerendering of unchanged data.
Have you tried creating your own table in React that supports just your use case? That would've been a fairer comparison un my opinion.
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.
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?
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.
Of course one could argue that Javascript itself doesn't allow much control over performance.
Ridiculous take. TypeScript turns into JS practically one-to-one. In 5 years I’ve never heard of a performance problem introduced in transpilation.