Hacker News Reader

Comment by paulgb | 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.

View on HN

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/

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.

Reply on news.ycombinator.com