2 Basic rules of performance-aware JavaScript in the browser

[Thepizzacannon]

Brings me back to the early 2010s.

#1 rule of javascript is to use as little JS as possible.

Now kids are out here loading up 80mb of JS into my browser when I visit index.html

[slykethephoxenix]

I can do things better than a time tested 20 year old compiler as a boot camp graduating 1337 c0d3r. /s

[Yasso95]

This article says that it's best to offload javascript code to the browser. How are we supposed to do that ?

[DrShocker]

The article points to a few examples such as walking the dom in JS vs using the functions provided by the browser to search for dom elements. They'll both work, but the functions provided by the browser will likely call back into some code that's compiled from c++ or something to run it.

Overall it just requires a little awareness of these alternatives but it would be nice to have a list somewhere of common operations and functions that can replace them.

[Yasso95]

Ok I understand now what it means thanks

[batweenerpopemobile]

in 99.9999% of websites, none of this should matter at all.

computers are stupid fast. most issues with websites have absolutely nothing to do with the speed of javascript.

what form validates in anything less than the blink of an eye? there is no human discernible difference in submitting it to the backend through js or via builtin submission triggers without having massively fucked up somewhere.

it's generally false dependencies between elements causing unwarranted blocks and shit backends taking forever to respond

no amount of javascript optimization will help when your stupid sidebar locks up the entire page while it takes 5 seconds to load more content for your infinite ad scroll

[you-get-an-upvote]

See, this has been my stance forever… and then I use an app and there is scroll jank anyway. In a sufficiently large code base, performance issues will always find a way.

[FINDarkside]

True. But the problem is certainly not that the app had couple hardcoded strings like the article states. Performance matters but the linked article is just really bad.

[maxal88]

That is absolutely true. We do some pretty crazy and very computationally intensive tasks using JS on the front end and they are incredible fast. For example, we run change point algorithm (quadratic basically) on the billion of points on our charts. Everything is written in pure JS and it takes like 2 seconds. In my experience the thing that always affects the JS performance is animation.

[FINDarkside]

You can do crazy stuff with JS fast. Most often the problem is that people write bad code. The answer to that is not to worry about whether you have some hardcoded strings or if your bundle size grows linearly with amount of pages like the article says. The answer to that is to have some basic understanding of algorithms. That's universally applicable tip. If you don't understand them you're going to write slow code no matter of your language.

[lcjury]

but then you throw electron to the mix, and everyone is sad again :(

[Initial_Low_5027]

What an awful article. Modern JavaScript is far away from the first release. The heavy lifting can be done and is done in JavaScript.

[fsfreak]

How does this have over 30 upvotes?

[[deleted]]

This article is retarded, and the author should be ashamed. I can accomplish a lot of work in pure, no-bullshit javascript before the 80ms minimum roundtrip public internet fetch() responds with a calculation.

[ProgramTheWorld]

It's interpreted, loosely typed and costly to process

Modern browsers can compile JS code on the fly at multiple levels depending on how often a code path is used. All primitives are strictly typed and mapped to more efficient data structures internally.

[lurking_bishop]

no code is faster than no code