Live data from Hacker News

Maybe you don't need Rust and WASM to speed up your JS

mrale.ph

181–186 of 186 posts

Re: Maybe you don't need Rust and WASM to speed up your JS

#181
post #105

We should be more wary about premature optimizations, like in the article where caching in the original code made it slower! Always measure! Write naive code and measure, the JavaScript engines are very good at optimization, especially V8 and the others are catching up. However when I do optimize JavaScript code I often get 10-100x performance. Usually by writing better algorithms . Eg no "black magic". So the origin…

> like in the article where caching in the original code made it slower!

Caching could have been originally faster, but became slower thanks to the continual improvement of the Javascript VMs.

Re: Maybe you don't need Rust and WASM to speed up your JS

#182

Earlier quoted context omitted.

Can you elaborate on how JS is more intuitive than, say, Rust? I can give a simple counter example - make a JS object, assign another object as a key, copy it three times into a list (without deepcopy) and modify the object inside. Suddenly you've modified all three objects. Not intuitive at all, and easily missed if you're a less experienced developer. Rust would stop you in your tracks and force you to explicitly s…

JS has more than its share of problems, but I wouldn't consider that to be one of them. It's the same reference semantics as Java and Python, and people are used to it.

People are used to it but saying that is kind of a cop out. It's very easy to write code that reads well logically but forgets about reference semantics, especially if you're a junior developer.

Re: Maybe you don't need Rust and WASM to speed up your JS

#183

Earlier quoted context omitted.

I agree regarding JS not being the easiest or most intuitive language, but I don't see JS going away any time soon and I don't think that's a bad thing. The last 5 years or so have seen JS transform from one of the most frustrating languages to one of the better ones. I think Typescript is where the future of web dev lies. Typescript for your main logic and WASM for optimising the parts that need it.

Yeah, JS is better now but I bet we could do even better starting with a clean slate. Web dev shouldn't be tied to a single programming language. How would you like using PHP and its derivates(i.e. Hack) for everything web APIs/back-end? I could tell you that it made great progress since PHP 4.

Oh I'm sure we can do better. Would it be worth throwing away decades of libraries, many of which have ironed out many subtle logic bugs over time? That's a different argument. Not going to say it's not worth it (there is a lot of mess that could be removed if we started from scratch).

It's the same argument any junior engineer makes when they start at a company with a legacy codebase. They always want to start from scratch but don't realise the cost or the fact that while they'll avoid 100 mistakes of the past, they'll also make 100 new ones. Why not just make JS better? It's already happening year by year.

Re: Maybe you don't need Rust and WASM to speed up your JS

#185
post #80
post #55

For me the purpose of wasm would not be just performance, but to let me avoid javascript entirely. Javascript is already very fast, but compiling to javascript feels awkward.

I don't think you can avoid JavaScript even with WASM - and WASM in it's current form is, for some languages, a worse compilation target than JavaScript.

Well sure it doesn't support the DOM yet, but I think the design goal of WASM is to do just that.

Since the beginning of computers, it should be trivial to distribute programs online efficiently.

The web is already platform dependent, but it also need to be fast and language independent.

Re: Maybe you don't need Rust and WASM to speed up your JS

#186

Tangent: I see that the author focused on improving sorting algorithms, and also at some point switches to a Uint8Array (although not in the sorting part). I recently discovered that a JavaScript implementation of radix sort up to four times faster than the the built-in sorting algorithms for TypedArrays[0][1][2]. Imagine how much faster a good WASM implementation could be! It also makes me wonder why browsers don't…

On my OnePlus 5T the standard sort() was twice as fast as the radix sort for the UInt8 array, but it was only 30% slower for the Float64 and regular arrays, whereas sort() was hundreds of times slower - strange...
Post reply on HN