Hacker News Reader

> For a web app the speed of the language is rarely the bottleneck anyway

I think there’s some selection bias in this; the apps that get built as web apps tend to be the ones that are not bottlenecked by JavaScript. For exceptions that are pushing the limits of performance, you’ll more often than not find Rust/C++ compiled to Wasm in the stack.

I've always wondered what kind of apps these are. The vast majority of web apps I use are all CRUD. I can't think of a single webapp or electron app I use which performs heavy computation. Maybe VSCode? But I don't know if any of the computation is happening on the frontend. People have been extolling the virtues of WASM to me for a while but I have yet to find a use for it where it improved the speed of development, since that's the only metric that matters to me working on CRUD apps

>I've always wondered what kind of apps these are. The vast majority of web apps I use are all CRUD.

This page has a list of examples: https://madewithwebassembly.com/

Many apps that are not CRUD need more efficient cpu performance of WASM... physics rendering engines, AutoCAD modeling, machine learning, etc.

Oh yeah I'm sure those applications exist, I just don't seem to use or work on any of them

Figma is a good example. Likewise, many games. Google Sheets? GIS apps? Probably the next big things in both DAWs and video editing will be in the browser too…

Oh yeah I guess Figma is one, but I'm not in the design department. I guess there are a lot of apps out there that benefit from it, but I don't seem to use any of them

>I've always wondered what kind of apps these are. The vast majority of web apps I use are all CRUD. I can't think of a single webapp or electron app I use which performs heavy computation.

Figma

Teams (the web version)

Outlook (the web version)

MS Word (the web version)

MS Excel (the web version)

Google Documents

Google Sheets

Google Earth

(similarly the iCloud versions for Pages, Numbers, etc)

Canva

Lightroom (the web version)

VSCode

Soundtrap

and a whole lot more.

Google Sheets is a big one. It really does seem like CRUD when compared ti Excel.

Desktop or web Excel?

Desktop.

I see it mostly with what I would call “industrial applications”: video editing, CAD, etc. Besides games, consumer software tends not to be computationally intensive, so there are few consumer examples (which I think leads to a sort of “JavaScript is fast enough for everything” fallacy among web devs)

I happen to write a newsletter where I interview this sort of company, here are some recent examples that use Wasm:

- Rayon (CAD): https://digest.browsertech.com/archive/browsertech-digest-ho...

- Modyfi (raster image editing): https://digest.browsertech.com/archive/browsertech-digest-ho...

Webdevs seem to have a blind spot around UI. Plenty of end-user apps - like music players - and websites - like e-commerce stores - tend to have compute-intensive UIs. They may not look compute-intensive for a dev on a beefy machine, playing with mockups and toy loads, but they absolutely become noticeable compute hogs on real machines with real loads.

And by "real loads" I really mean just more than two dozen items on a list of whatever it is the app displays.

My company has several tables in our UI whose API endpoints simply query for all records in that table without pagination. hundreds of rows are loaded into a table plugin, even if you'll never get past the first page

That's... good. Hundreds of rows is a trivial amount, so unless they're expensive to generate on the backend and/or meaningfully large, it should be a non-issue. The question is, what is the page size in the UI, and why is it less than "hundreds of rows"?

Browsers can handle hundreds of rows just fine, even on, say, a modest Chromebook. No problem. If you're looking for someone to blame, you need to blame the crummy UI frameworks in use on the site and the half-rate developers who chose not to vet (and veto) their use. And blame the screwy job requirements and hiring practices at the company that insisted that those developers—the ones who took this development approach and worked with this kind of tech—were the right ones to hire and others were the wrong ones.

Of course. I'm definitely not blaming browsers for this - we're talking about trivial requirements here, while browsers themselves are absurdly well-optimized these days. Which makes it even harder to watch the webdevs casually throw that all away using crummy tools, too focused on moving fast themselves to give a damn about letting users move fast too.

Even those CRUD apps you and I use daily have substandard performance, as they get bottlenecked by amount of data they can process, in at least two major ways:

1. Code "fast enough" to manipulate a few things (say, listings) will not be fast enough to handle hundreds of them;

2. UI frameworks and components people use are designed to look nice for demo case, which is again few elements, and tend to choke under actual, real workload of dozens, or hundreds, or thousands of elements.

Next time you see a website that paginates your results, like e.g. a store that shows you 20 results per page, look for a dropdown controlling the pagination threshold. See if you can bump it to 50 or 100 elements per page, and ask yourself, why do you dread doing so.

We build a full game creation IDE and game engine which is entirely browser-based and almost entirely written in JavaScript (including all the performance-sensitive stuff), and the performance is ridiculously good[1]. You don't need WASM for good performance[2].

[1] https://www.construct.net/en/blogs/construct-official-blog-1...

[2] https://surma.dev/things/js-to-asc/

Fair enough, Construct looks cool. If you or anyone from your team is interested in doing an interview for a technical newsletter about browser-based apps[1] I'd be glad to get a JS perspective on high performance in the browser.

[1] https://digest.browsertech.com/archive/

> JavaScript isn't as fast as C++ or Rust, but it's pretty fast. Around the speed of Java and Go in some cases, which are compiled.

Sorry, not even remotely close. I want to see some serious evidence.

JS id as unoptimizable as can be, thanks to its hyper dynamic nature. And js developers without any clue about memory will happily allocate hundreds of thousands of unnecessary objects to save a line of code. Completely unknowingly of course.

Quake 1 (about 100k lines of C) runs in the browser just fine: https://www.netquake.io/quake

Yes, it's a 30 year old game but the typical CRUD web app doesn't have close to the complexity of quake. Good C++ code is significantly faster than JS, that's true, but JS is also much, much faster than you'd think.

That quake demo is surely running on the WASM runtime which isn't really related to JavaScript: https://en.m.wikipedia.org/wiki/WebAssembly

now you can make web apps in your compiled language of choice (limited choice) and not worry (as much) that its not fast enough

Webassembly started its life as a JS hack, called asm.js: https://en.wikipedia.org/wiki/Asm.js, which itself was fully capable of running Quake.

Here's the Unreal engine demo from 10 years ago: https://www.youtube.com/watch?v=XsyogXtyU9o

> Sorry, not even remotely close. I want to see some serious evidence.

Funny that you say "not even remotely close" while providing zero evidence yourself, but then ask other people to present their evidence.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

There you go. There's the evidence. No goalpost-moving, please.

For evidence that Javascript can be used to build large, production-quality applications, see coldtea's comment: https://news.ycombinator.com/item?id=37568707

Speed is achieved via optimization, which is achieved via constraints. Javascript is being known for its inefficiency. Saying JS is just as fast is a hot take and whoever claims that has the burden to proof otherwise.

Sorry, about benchmarks I just quote myself: > I take these performance benchmarks with a rock of salt. They are mostly hyper-optimzied generics which are as far away from actual production code as it can be. They are written in a way to allocate as little memory as possible and is done by people who know exactly what they are doing.

> done by people who know exactly what they are doing

Do you think we should only compare JavaScript written by newbies?

> JS id as unoptimizable as can be, thanks to its hyper dynamic nature.

And yet it has been optimized.

> Sorry, not even remotely close. I want to see some serious evidence.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

JS is ~30% slower than Java or Go.

Go is a lot closer to JS perf than to C++ perf.

---

For real-world applications....compare IntelliJ, Eclipse, Visual Studio, or Sublime against VSCode.

I take these performance benchmarks with a rock of salt. They are mostly hyper-optimzied generics which are as far away from actual production code as it can be. They are written in a way to allocate as little memory as possible and is done by people who know exactly what they are doing.

Especially the garbage collection strategies of Java are second to none (sorry, don't want to be a shill).

> For real-world applications....compare IntelliJ, Eclipse, Visual Studio, or Sublime against VSCode. My experience is that VSCode has horrible input latency and Intellij is blazingly fast once indexing is done.

My experience is that IntelliJ takes way longer to start and freezes more frequently.

How often do you start up your IDE a day?

This is classic goal-post moving - you started out by saying that Intellij was faster than VSCode, then after a commentator said that their experience was the opposite, you moved the goal-post to "well it doesn't matter". You should be willing to admit when you're wrong.

Some pictures:

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

I did a double take when I read this too. However, I’d wager that in 99% of cases the bottleneck isn’t at the language level for most desktop apps or GUI apps in general.

I have an app that has one pretty frequent cpu intensive call (it computes the lcs for diffing). I decided to benchmark a rust wasm bindgen implementation against the js one I was using and found that ironically enough, node did perform better than rust. To be fair to the rust version, I think the JS implementation was slightly better optimized. I then looked into parallelizing LCS, (which is possible) but bindgen and almost all node:rust ports don’t support multithreaded calls, I can think of a myriad of ways to overcome this but not in a browser context. At that point I gave up on worrying about porting to lower level languages for cpu intensive work because if you’re forced into a single threaded context the gains of a memory managed language are going to be trivial at best and add ipc overhead at worse.

The main culprit of poor JS performance in native contexts is almost always bridges and the serialization/deserialization that comes with them. Electron apps don’t really suffer from the bridge problem. While, I’d never claim that JS is as fast as GO or Java (objectively it isn’t), it’s seems equally naive to suggest that using memory managed languages without exploiting multicore is going to lead to significant performance gains in a native app or web app.

I think the real power of wasm is the power of virtualization, it won’t be performance unless web APIs decide to break the single thread paradigm.

Just use Workers API and spawn another JavaScript thread

Well then you’re back to the bridge problem. postMessage is crazy slow. There are some problems where parallelization will outperform the ipc cost with postMessage but those problems are few and far between. I haven’t dove into the new web GPU api but it does look kinda promising (shared memory is hard, so I’m apprehensive). I’m sure some of these things will get solved in the long run but for the time being, the bottleneck to browser performance is not necessarily JavaScript itself but the webapis that are crafted around a single threaded model. This is really my only point. Aside from providing systems engineers familiarity with syntax/devex and possibly some portability with some llvm/wasm compatible libs, there is little point in wasm runtimes at this current time imo.

citation:

https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers...

“Data is sent between workers and the main thread via a system of messages — both sides send their messages using the postMessage() method, and respond to messages via the onmessage event handler (the message is contained within the message event's data attribute). The data is copied rather than shared.”

Transferable objects have been part of the spec for a while now, making it possible to send data back and forth contexts with no copying.

https://developer.chrome.com/blog/transferable-objects-light...

> Sorry, not even remotely close. I want to see some serious evidence.

There was this blog post of a company trying improve their clients' webpage performance by incrementally migrating them from JS to WASM/Rust: https://zaplib.com/docs/blog_post_mortem.html

In short, their idea failed. Those rewrites did not yield the "orders of magnitude" perf improvements that they were hoping for. A quote from the article:

> Rust is faster than JS in some cases, but those cases are rarer than we expected, and the performance gain is on the order of 2x some of the time, not 10x most of the time.

Having had a good deal of experience programming in JS, this doesn't surprise me. JS engines are extremely good at JIT optimizing, especially if you know what you're doing and give them code that's suitable for optimization (e.g. using mostly primitives and arrays, simple loops, avoid creating tons of intermediate data structures, etc).

IDK if any of this counts as "serious evidence". It's purely anecdotal really. But it's on par with the "evidence" presented as a counter to this.

Comparing WASM and JS is fine.

Claiming JS has the same performance as Java or Go is not.

JS also has had decades of optimizations. So if WASM with essentially no optimization is just as fast as JS, that's a huge interoperability win.

> > Around the speed of Java and Go in some cases …

> Claiming JS has the same performance as …

"in some cases"

The key words here are: "around", which is to say same order of magnitude for performance, and "in some cases" which is to say for certain applications. I've already posted evidence for this claim specifically in sibling posts.

Also, why do you compare JS written by amateurs with Go/Java experts? There are JS experts too.

I once wrote an image generation program that used every color in a provided palette exactly once, then ported it to a few different languages. The main data structure was a kd-tree to store RGB points, with each point being marked as used after returning it.

Rust and C++ were both within about 10% of each other. Python was about 3 orders of magnitude slower. The surprising result was that JavaScript was only about 7-8x slower than the C++ version, which was much faster than I had expected.

> Around the speed of Java and Go in some cases, which are compiled.

That is quite the claim, I wonder if you have any data to back that up. As it goes against everything I've seen.

You really should take benchmarks with a grain of salt, but:

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

There are others as well like:

https://programming-language-benchmarks.vercel.app/go-vs-jav...

That being said, the specific performance characteristics isn't really the point. Even if you accept JavaScript and Go being similarly fast (same order of magnitude), JavaScript uses way more memory (which I'd argue doesn't really matter, but it's worth mentioning) and the DOM is the main bottleneck in the browser, so WASM won't save you completely there.

"In some cases" seems reasonable to me. Google poured a lot of money into V8 performance for 15 years. There's also situations like AWS's Lambda environment where more time was spent getting node/JS optimized for the environment.

Is it "quite the claim"?

The Javascript JIT arms race was the most heavily funded dynamic language arms race since forever - involving three major players (Apple, Google, Mozilla), dedicated teams, tons of benchmarks, constant tracking of performance improvements, total rewrites of the engines and additional JIT stages added, and public boasts in the official company blogs and marketing material!

It is still quite the claim.

Given the disadvantage that it starts at, JavaScript is astonishingly fast, due to the extreme investment in it that you mention. However, in almost all real-world scenarios, it’s still generally pretty easily beaten by ahead-of-time-compiled languages, even if on some microbenchmarks and for a few specific sorts of tasks it can end up competitive with certain of these compiled languages.

>However, in almost all real-world scenarios, it’s still generally pretty easily beaten by ahead-of-time-compiled languages

The claim to be refuted was not "Javascript is faster than AOT compiled languges" however.

Instead, the claim was: "[Javascript is] around the speed of Java and Go in some cases, which are compiled", which is not far off. Especially given that these two are not in general among the fastest kids like C, C++, and Rust.

Yeah, what I expressed was a bit sloppy. Go is AOT-compiled, but kinda the weak link among most such languages as regards performance. Java is somewhere in between the two, and the HotSpot JVM is also generally handily faster than JavaScript engines (it also has had rather a lot of effort put into optimising it, and without most of the starting disadvantages of JavaScript).

> I'm honestly surprised the Chromium team hasn't already addressed this with the Electron team somehow by now

Well, a solution might be to share the chromium "vm" across all electron app, but maintaining compatibility will be horribly difficult so, no I guess.

you solve it the same way you do with iOS and Android - an LTS release with careful deprecation of APIs.

Microsoft has this on Windows: https://learn.microsoft.com/en-us/microsoft-edge/webview2/

Teams 2 is supposed to use it (and there's a couple smaller system apps that use it).

I think that one of JavaScript’s biggest problems is that on average, the quality of code written in it is somewhat low due to its lower barrier to entry, its relatively loose nature, and the less-engineering-inclined nature of many who write it enabled by that looseness. It doesn’t matter how fast your runtime is if it’s running crappy code.

That’s not to say that all code written in Rust or Swift is all AAA grade or anything, but to write those to the point of being able to publish a product that functions reasonably well, a deeper level of understanding is required which acts as something of a filter.

It would be interesting to see what would happen if all browsers added support for a sort of “JavaScript Next Gen” that were much more strict, sitting somewhere between TypeScript and Swift without the various escape hatches that TS currently has. My bet is that sites and web apps written with this would be on average of higher quality than their legacy JS counterparts.

> JavaScript isn't as fast as C++ or Rust, but it's pretty fast. Around the speed of Java and Go in some cases, which are compiled.

Indeed, JS is pretty darn fast.

Not because of innate characteristics, but because of the human-centuries spent optimizing JIT VMs.

> I guess with newer apis such as the File System one Electron is slowly becoming unnecessary

Last time I tried, it was still a pain point. For one, the API felt... alien. Also, the performance was not good. I'm not sure why, maybe it's my Javascript-FU that's bad, but all in all I'd still use another language for this if possible.

I suspect MS is working on some sort of common browser layer for Electron apps on Windows.

Their primary reasoning for picking V8 for Edge was that node, electron etc were built on V8.

We haven’t seen anything specific to those environments in Windows yet. I expect that to probably change pretty soon.

>For a web app the speed of the language is rarely the bottleneck anyway, other than some exception cases like WebGL-type stuff.

If we're talking about a glorified form/CRUD app, no.

For web apps proper, that's not really the case.

Sure it is - the vast majority of webapps are glorified CRUD. I'm not saying there are not high performance use cases. I'm saying if you list every app, most of them would be fine with exclusively JavaScript, and for the rest you have careful use of WASM or backend delegation to a faster language.

And to the author's point, something slow in JavaScript is better than nothing at all.