Going from React to Vanilla JavaScript • Hacker News Board

Re: Going from React to Vanilla JavaScript

#21

Post by 3oH2y869 » Sat, Jul 08, 2023, 2:20 PM UTC

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.

Re: Going from React to Vanilla JavaScript

#22

Post by eastbound » Sat, Jul 08, 2023, 2:20 PM UTC

harshaw wrote: post #6

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…

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.

Re: Going from React to Vanilla JavaScript

#23

Post by aydio » Sat, Jul 08, 2023, 2:20 PM UTC

alexbezhan wrote: post #17

Ylmaz wrote: post #11

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.

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.

Re: Going from React to Vanilla JavaScript

#24

Post by Xeoncross » Sat, Jul 08, 2023, 2:21 PM UTC

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.

Re: Going from React to Vanilla JavaScript

#25

Post by Dudester230602 » Sat, Jul 08, 2023, 2:21 PM UTC

joeldo wrote: post #9

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.

Re: Going from React to Vanilla JavaScript

#26

Post by flohofwoe » Sat, Jul 08, 2023, 2:22 PM UTC

KnobbleMcKnees wrote: post #4

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.

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.

Re: Going from React to Vanilla JavaScript

#27

Post by nness » Sat, Jul 08, 2023, 2:23 PM UTC

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.

Re: Going from React to Vanilla JavaScript

#28

Post by progx » Sat, Jul 08, 2023, 2:23 PM UTC

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

Re: Going from React to Vanilla JavaScript

#29

Post by progx » Sat, Jul 08, 2023, 2:24 PM UTC

aydio wrote: post #23

alexbezhan wrote: post #17

Earlier quoted context omitted.

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.

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.

Why should he build his own, you can compare existing things.

Re: Going from React to Vanilla JavaScript

#30

Post by paulgb » Sat, Jul 08, 2023, 2:25 PM UTC

duxup wrote: post #12

There is virtually nothing in this article. 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.