4 ms·

For blogs, sure, JavaScript is "fast enough". But in the context of applications, JavaScript is slow as dog shit. It takes "seconds" to open my spreadsheet? T

by veidr 4y ago

For blogs, sure, JavaScript is "fast enough". But in the context of applications, JavaScript is slow as dog shit. It takes "seconds" to open my spreadsheet? That is an absolutely deplorable regression. Personally, I'm fine with 200KB initial downloads, sure that's great and I don't mind repeating them. (But, also don't care about 50MB or even 500MB downloads that I only do once.) But for the browser to really become the "single best application distribution method humanity has ever created" it needs to be capable of delivering software that executes efficiently or else it is regresssion to barbarism by a thousand cuts. Not just the putrid UX, but we now understand that slow, inefficient code also cooks the planet and destroys various life forms. I work at a company that uses Google Sheets. So yeah, it does often take seconds to open a document. And I've spent way more time waiting for those sheets to load over the past 5 years than I have waiting for software installers. And many web apps bog down and lag behind even just typing, because they are doing some (trivial) computation on every keystroke. It doesn't have to be that way, but it often is... because JavaScript. I'm also bullish on the browser's future as an app-delivery channel — but that is only because I think doing it without JavaScript will become easy, and thus common. JavaScript is relevant because of the browser, not the other way around.

zozbot234 4y ago
> it needs to be capable of delivering software that executes efficiently or else it is regresssion to barbarism by a thousand cuts. WebAssembly executes efficiently, it keeps its overhead within a small multiple of natively compiled binaries which is totally par for the course for any JIT-compiled intermediate code. You can write slow and inefficient code in any language, but Rust makes it a bit easier to do things the efficient way.
- veidr 4y ago
  Yeah, that's why I remain optimistic about the browser's future. My ranting was mainly about JavaScript itself. We are already seeing real world web apps using WASM. (What I have seen is indeed mostly Rust, but in theory there are lots of other languages that can already, or will be able to, play in that same sandbox.) The other fun thing about WASM is that there are already a bunch of ways to run it on the server (including "at the edge"). That makes it really easy to chop apps up into pieces that run in the browser, or run elsewhere.

by veidr 4y ago

zozbot234 4y ago

> it needs to be capable of delivering software that executes efficiently or else it is regresssion to barbarism by a thousand cuts. WebAssembly executes efficiently, it keeps its overhead within a small multiple of natively compiled binaries which is totally par for the course for any JIT-compiled intermediate code. You can write slow and inefficient code in any language, but Rust makes it a bit easier to do things the efficient way.

veidr 4y ago
Yeah, that's why I remain optimistic about the browser's future. My ranting was mainly about JavaScript itself. We are already seeing real world web apps using WASM. (What I have seen is indeed mostly Rust, but in theory there are lots of other languages that can already, or will be able to, play in that same sandbox.) The other fun thing about WASM is that there are already a bunch of ways to run it on the server (including "at the edge"). That makes it really easy to chop apps up into pieces that run in the browser, or run elsewhere.