Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

mrale.ph

Post reply on HN
Print view View original

41–50 of 186 posts

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

#41

Post by petre »

sametmax wrote: post #20
bitL wrote: post #5

So much work to achieve what should be default behavior :-/ How did we end up in wasting so much time on trivialities?

When JS came out, it was poorly designed, but nobody cared because we used it only to make snowflakes appear on the web page. Then MS gave us AJAX and 37 signals made it popular, until apps like gmail made it so mainstream it was impossible to go back to old static pages. But it was too late. The shitty language we had was the only one available everywhere to do dynamic web pages now. IE would not move, and Firefox a…

> So instead of implementing a better language, they also used JS

They did implement a better language, Dart. But it was too late, like you said. Maybe we'll have a change of using it for mobile apps with Flutter.

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

#42

Post by kibwen »

greenhouse_gas wrote: post #39

The problem with these tricks is that they're dependant on V8 internals, which means that there's no guarantee that it will be fast on Firefox (or edge, or even Safari). So now if google changes the back end, websites will slow down, which means that Google has to ossify implementation details, furthering this sort of black magic into CS lore forever. This, honestly, is what I hate with modern dev. A few days back th…

The article does mention SpiderMonkey, though not Safari or Edge, and the point does stand that profiling four different JS JITs to guarantee that you trigger their optimizations is always going to be more work than profiling one C++/Rust program generated by a single compiler toolchain (though it remains to be seen how much individual browsers' implementations of WASM will diverge in runtime optimization potential).

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

#43

Post by gear54rus »

themihai wrote: post #9

I wonder if the performance gain is worth the effort. Surely you can always squeeze more performance from JS like from any other language but what's the point if you spend hours to match the performance you get for "free" from other languages? As far as WASM is concerned I'm more excited about the possibility to run any programming language on the web than the raw performance gains. So far it is still year(s) away fr…

> hours to match the performance you get for "free" from other languages?

In a sense, you pay those hours that you saved up by using an easier, more intuitive language like JS. Or you can choose not to and still have pretty good performance and blazing fast dev cycles.

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

#44

Post by Jasper_ »

jandem wrote: post #34
anp wrote: post #25

I think this is an interesting exploration because I really enjoyed the description of profiling and improving performance, but I came away feeling exactly the opposite of the title. I think it's really cool that JS optimization can provide so many wins, but this article makes it seem fairly fickle and if they're not familiar with VM internals I would not expect most developers to complete this journey. Using wasm+ru…

I work on SpiderMonkey JS performance (and got mentioned in the article for fixing a perf bug!) and this is exactly the point I wanted to make. If you're not a VM engineer, it's much harder to write fast JS. Wasm also gives you much more predictable performance across engines, without requiring (often engine-specific) 'hacks' like function cloning.

From what I can tell, doing basic things like a property get on an object in WASM/host-bindings will require a spill to function, with no chance of specialization:

https://github.com/WebAssembly/host-bindings/issues/11#issue...

If you think the assembly in this article is bad, WASM/host-bindings appear to be even worse.

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

#45

Post by masklinn »

faitswulff wrote: post #21
lmm wrote: post #3

I'm excited about compiling to WASM not for performance but for correctness. Typescript is better than nothing but it really can't compete with the safety and ease you get from a language with a really good type system.

One thing I've been confused with about transpiled languages is how does correctness transfer? How do types or lifetimes etc. transfer to WASM, for instance? Or does it just depend on the correctness to be verified in the pre-compilation/transpilation stages?

Same way it does when compiling to C or assembly, the correctness is checked on the source and assume the codegen and platform you run on behave correctly (and fix/work around bugs which inevitably arise).

So the correctness transfers in the sense that the code the compiler output should always be correct.

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

#46

Post by masklinn »

Too wrote: post #17
lmm wrote: post #3

I'm excited about compiling to WASM not for performance but for correctness. Typescript is better than nothing but it really can't compete with the safety and ease you get from a language with a really good type system.

What would you consider to be a "good type system"? I find typescript to have one of the most sane and still strict type systems of all languages that doesn't fall into the extreme functional spectrum or those that care about memory ownership.

> I find typescript to have one of the most sane and still strict type systems of all languages that doesn't fall into the extreme functional spectrum

MLs (OCaml, F#, Reason) are hardly "extreme functional spectrum".

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

#48

Post by masklinn »

orf wrote: post #10
Animats wrote: post #4

Source maps are a debug tool. Why does the performance matter? (And if you're shipping so much JavaScript to your site users that you need to "minify", maybe you're doing it wrong.)

Tools like Sentry parse them, and need consistent fast performance in this area. Other debugging tools use them. Your statement in brackets seems very "those damn kids"-ish. You need to "minify" your JS files even if you're shipping a small amount of JS, because loading performance matters and JS minifies very well.

Browsers also use them do display "expanded" code in the console and debugger.

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

#49

Post by nocman »

aschampion wrote: post #37
maxxxxx wrote: post #26

Earlier quoted context omitted.

No offense taken! I am pretty new to the JS world. "WASM will eventually allow the same choice in the browser." When will that actually be? That's the big question.

Since November WASM is enabled by default in the major browsers now: https://caniuse.com/#feat=wasm

I guess if you don't include IE11 as one of the "major browsers".

I wish that was the case. Yes, I know it is only receiving security updates -- but it will supposedly get those until Windows 10 is no longer supported (if I'm reading things right).

Unfortunately, that doesn't stop a bunch of people from using it. It still has a considerable amount more marketshare than Edge does (if netmarketshare.com is to be believed).

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

#50

Post by wereHamster »

devit wrote: post #28
Too wrote: post #17

Earlier quoted context omitted.

What would you consider to be a "good type system"? I find typescript to have one of the most sane and still strict type systems of all languages that doesn't fall into the extreme functional spectrum or those that care about memory ownership.

It's not: the TypeScript type system is unsound (accepts code that violates it), and there are no runtime checks, so it doesn't actually guarantee anything: a TypeScript variable may in fact contain any value regardless of its declared type. I'd say the best type systems are found in Rust (naturally models zero-cost abstractions but doesn't have dependent types) and Idris and Coq (have dependent types but don't natur…

> a TypeScript variable may in fact contain any value regardless of its declared type.

That's true in pretty much all languages. Even in Haskell you can use `unsafeCoerce`. In Rust you have 'unsafe' blocks. And any language which has a FFI you can implement the type-safety-violating functions in the foreign language (often C).

Post reply on HN