Hacker News Reader

Comment by thermodynthrway | Hacker News Reader

I appreciate the throwback to more reasonable websites, but really these days you can get something quite good with Vue. Its not hard to get a site under 200 kb. Webassembly is bound to make sites even 2-5x smaller in the near future.

The real problem is poliferation of ads and site owners that "don't care" if sites are hard to load on slow devices and connections. It's not something people really optimize for anymore.

The real problem, which Google tried to "fix" with their dubious AMP program, is that search engines don't punish huge and dog slow websites. Basically every large site is optimized for ads and SEO. Something we wouldn't see if the largest search engine didn't base their business on the same.

If a search engine half as good as Google appears that doesn't tolerate such trash in the search results all these slow sites will go away overnight

View on HN

I’m just baffled by this, there are many high profile sites that barely work on the misc mobile browsers I use. I avoid them, obviously. I can’t be the only one. The only thing I can think of is that due to business demands, and code cruft, the developers just “make things work” on their desktop.

Then when the managers ask them to speed up the site, they literally can’t do it.

I've worked at plenty of places like this. Sales team wants another analytics WordPress plugin because they barely know how to login to the tools we already have. Slows down page loads by 50%. Sales team complains they they will lose sales, developers told to make the plugin faster because we need it.

Try to load the plugin async and run the hairball through closure compiler. Now only slows down site by 30%. Sales team happy, development manager happy. Cue a repeat in a month

"Webassembly is bound to make sites even 2-5x smaller in the near future."

That's true if you hand code your webapp in WAST :) Otherwise there will be tons of libraries included from C++, Rust or god knows where from. So if you want to draw a few pixels, then prepare for 5 - 10x time size increases.

It's not the goal of WebAssembly to replace JS and HTML/CSS.

It's not a goal but it will happen because the benefits are huge. JavaScript s "tree shaking" is a joke compared to a compilers ability to remove unused code. Since it's all compiled down to WASM bytecode it's possible to remove unused code no matter what the original language. Close to the holy grail

Why would WASM reduce code size? WASM is quite low-level. JS has the advantage of a runtime already being present.

It's compiled bytecode, designed to be compact. JS is "minified" but there's limits to how far you can go. JVM and WASM bytecode is designed to use as little space as possible.

Not sure about WASM but the instruction set in JVM bytecode is intentionally limited in a ton of ways to keep instruction length to 1 byte

Reply on news.ycombinator.com