7 ms·

Going from React to Vanilla JavaScript

43 points by alexbezhan 3y ago

2h 3y ago
Not a single code example. Crap article.
joeldo 3y ago
How has this article landed on the frontpage? There is 0 substance - are people even reading it before upvoting?
- Dudester230602 3y ago
  React is a legacy, 10-year old technology. People are thirsty for something new, even if it is about going back to basics.
revskill 3y ago
OK, but at what cost ? How much time investment ? How much experience is required ? Is this article written by a marketer ?
KnobbleMcKnees 3y ago
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.
- crabmusket 3y ago
  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?
- aCoreyJ 3y ago
  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
- flohofwoe 3y ago
  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.
- dcre 3y ago
  Ridiculous take. TypeScript turns into JS practically one-to-one. In 5 years I’ve never heard of a performance problem introduced in transpilation.
raincole 3y ago
Then show the app? Not the screenshot of the app. The app itself.
harshaw 3y ago
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 :)
- eastbound 3y ago
  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.
  - notjoemama 3y ago
    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.
- notjoemama 3y ago
  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.
smallerfish 3y ago
Not a great article. The big thing is JSX; it's so much more pleasant than building UIs with the document/element api.
- alexbezhan 3y ago
  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.
- HWR_14 3y ago
  I thought JSX was independent of react, but react built on and popularized it.
- Dudester230602 3y ago
  > ...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 https://platform.uno.
Ylmaz 3y ago
A lot of people don't know how to use react. The author is one of them.
- alexbezhan 3y ago
  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.
  - Ylmaz 3y ago
    No you just update the cell. React is extremely fast if you understand how rendering works. Avoid unnecessary rerendering of unchanged data.
  - aydio 3y ago
    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.
    - progx 3y ago
      Why should he build his own, you can compare existing things.
      - Ylmaz 3y ago
        Why should he compare a random package that does not fit his use case to his custom solution?
duxup 3y ago
There is virtually nothing in this article. I can only assume we’ve adopted the Reddit pattern of upvoting sentiment at this point.
- paulgb 3y ago
  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.
donatj 3y ago
I felt like I had just finished the introduction and the article was over. I wish this had gone a lot further into depth.
surrTurr 3y ago
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?
bastawhiz 3y ago
> 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.
aydio 3y ago
I was excited to see the author's reasoning and some code to support the claim. Then I reached the end of the page.
3oH2y869 3y ago
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.
Xeoncross 3y ago
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.
nness 3y ago
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.
progx 3y ago
I will never understand why so many use unnecessary complex things, especially if better and simpler things existed befor and after.
Vanit 3y ago
I just don't see how to do this without half-assing a framework and then it's not really Vanilla anymore is it?

43 points by alexbezhan 3y ago

2h 3y ago

Not a single code example. Crap article.

joeldo 3y ago

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

Dudester230602 3y ago
React is a legacy, 10-year old technology. People are thirsty for something new, even if it is about going back to basics.

revskill 3y ago

OK, but at what cost ? How much time investment ? How much experience is required ? Is this article written by a marketer ?

KnobbleMcKnees 3y ago

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.

crabmusket 3y ago
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?
aCoreyJ 3y ago
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
flohofwoe 3y ago
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.
dcre 3y ago
Ridiculous take. TypeScript turns into JS practically one-to-one. In 5 years I’ve never heard of a performance problem introduced in transpilation.

raincole 3y ago

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

harshaw 3y ago

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 :)

eastbound 3y ago
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.
- notjoemama 3y ago
  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.
notjoemama 3y ago
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.

smallerfish 3y ago

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

alexbezhan 3y ago
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.
HWR_14 3y ago
I thought JSX was independent of react, but react built on and popularized it.
Dudester230602 3y ago
> ...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 https://platform.uno.

Ylmaz 3y ago

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

alexbezhan 3y ago
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.
- Ylmaz 3y ago
  No you just update the cell. React is extremely fast if you understand how rendering works. Avoid unnecessary rerendering of unchanged data.
- aydio 3y ago
  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.
  - progx 3y ago
    Why should he build his own, you can compare existing things.
    - Ylmaz 3y ago
      Why should he compare a random package that does not fit his use case to his custom solution?

duxup 3y ago

There is virtually nothing in this article. I can only assume we’ve adopted the Reddit pattern of upvoting sentiment at this point.

paulgb 3y ago
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.

donatj 3y ago

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

surrTurr 3y ago

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?

bastawhiz 3y ago

> 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.

aydio 3y ago

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

3oH2y869 3y ago

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.

Xeoncross 3y ago

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.

nness 3y ago

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.

progx 3y ago

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

Vanit 3y ago

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