- cross-posted to:
- webdev@programming.dev
- cross-posted to:
- webdev@programming.dev
You must log in or register to comment.
I read this article a few weeks ago and it sent me on a rabbit hole of web performance articles.
I think a good budget for basic websites (articles, landing pages, and small to medium functionality web apps) is what I call the “GZ250”, or 250KB of gzipped JavaScript, which is more than plenty. I picked this amount such that yesterday’s budget phones will be able to load the website in a few seconds at 1Mbps (and the name references my motorcycle).
For comparison, my full on games take way less than that. The Unscaled Incremental and Elemental Incremental are 52KB and 19KB of compressed JS respectively, and v1.0 of my new deckbuilding game is about 27KB. The unreleased V1.1 is massive but will still be around 50-60KB of compressed JS.
I don’t understand how an article uses 60x the script as my games, but cutting back to 6x would be a win for accessibility and efficiency.
How big is 10 MB anyway?
To be honest, after typing all these numbers, 10 MB doesn’t even feel that big or special. Seems like shipping 10 MB of code is normal now.
If we assume that the average code line is about 65 characters, that would mean we are shipping ~150,000 lines of code. With every website! Sometimes just to show static content!
And that code is minified already. So it’s more like 300K+ LoC just for one website.
An important takeaway, as I feel byte size can be hard for people to intuitively visualize. And for those who didn’t read the article, many of the sites tested sent significantly more than 10 megs of JS, even sites containing nothing more than simple input boxes that should be doing any processing server-side.
I want to see the difference with ad-block enabled. Analytics and tracking are certainly complex enough to account for a lot of that payload. Same with an addon like Decentraleyes to see how much is bloated frameworks that could easily be cached locally.
now let’s enable ublock origin
WASM still hasn’t convinced enough people to drop JS and write their website in something other than JS/TS. Maybe someday…
Isn’t DOM manipulation notoriously tedious with WASM? That seems quite a showstopper for most client-side js I’d say.
Got it, but if you expect people to switch from JS to Rust , you’re going to be disappointed. That’s like asking people who just got their driving license to hop into a fighter jet just because it’s faster. JS is a simple language. Its widespread adoption is not due only to it being ubiquitous, but also because it’s pretty easy to learn. Rust, on the contrary, not so much.
Rust is only one of the languages. There are other languages which compile to WASM: Kotlin, Swift, Zig, Go, C#, and more.
I still have no idea what WASM really is. I’ve tried looking at articles but it still confuses me. I know how to use HTML, CSS, JS, and actual ARM assembly language at a basic level, but I don’t see how any of this could be used with WASM.
WASM is just like assembly. It has instructions similar to
MOV,JMP,STA, etc. It can be distributed as the textual instructions or as the compiled binary format.When it started it was interpreted by JS or could be compiled to JS directly. It proved to be faster than hand-written JS. However, it still had to go through a JS interpreter. Now, there’s a WASM interpreter / virtual machine built into browsers. It’s very much the new java bytecode but without running an unsandboxed, external (outside of the browser) java virtual machine.
Given it’s an intepreter / virtual machine, it of course has limited APIs in the browser. For a while, it was not possible to access the DOM from WASM, so JS would do the DOM stuff and WASM was called (just like calling an external function in a lib in C/C++/Rust/…) upon to do computationally complex stuff since it was faster than running it in JS through the JS interpreter. IINM, WASM now does have access to the DOM.Of course there are WASM interpreters outside of browsers that can be included as libraries in other languages. Rust devs are using it for example for plugin systems in their software.
I had to look up what IINM means. For anyone wondering, it means “If I’m Not Wrong”.
Not sure this is worthy of an acronym, but that’s your choice! I just wanted to contribute context for people like me.
Thanks
I thought it was pretty common 🤔 Like LGTM (looks good to me) and IIRC (if I recall correctly).
It’s the first time I see it, but that doesn’t mean it’s uncommon! 🙂
Honestly I’m better off this way, personally. At least javascript is text, and very often readable after pretty printing and debuggabke as a user, I’m not comfortable with loading basically opaque binaries for websites.
Isn’t production JavaScript usually minified/obfuscated to make it hard to read?
Also wasm is actually bytecode, which I believe has a 1:1 conversion into a text-based format called wat.
I agree with your main point though, it’s kinda creepy when you realise just how much we are expected to allow other people’s code to run on our machines.
Isn’t production JavaScript usually minified/obfuscated to make it hard to read?
Somewhat, but often it’s still readable. Or maybe I just don’t look at it often enough to notice the worse cases…
Also wasm is actually bytecode, which I believe has a 1:1 conversion into a text-based format called wat.
That’s good to be aware of, thanks!
