Between this and Blazor ( http://blazor.net/, among other wasm projects I'm forgetting right now), I'm glad more complicated UIs are being once again designed on the backend and keeping bundle sizes (relatively) small, rather than making everything in JS on the frontend and expecting everyone to download megabytes of code to visit a website.
I'm looking in your direction Medium, at 6MB with a cold cache!
Large bundle sizes are not a consequence of creating UIs on the frontend, they are a consequence of bad practice. I have created plenty of purely frontend apps that don't even approach 1 MB let alone 6 MB. In fact, most languages that can target WASM seem to produce enormous modules compared to a reasonable frontend JavaScript app. Rust is an outlier in my experience because of its minimal runtime.
It's also worth noting for example that only 1/5th of the data transferred when I load medium.com cold is their JavaScript, so WASM can't really help them either way.
I did not know about tinygo and this is pretty impressive. However, it is only a subset of Go missing a few features, most notably the fact that memory is never deallocated.
Also, the equivalent JavaScript is still a fraction of this size. That's actually roughly the size of Preact, which implements nearly all of React.
Agreed, though it's a lot easier for bad practice to happen with JavaScript than a lot of other languages, and frameworks like this (hopefully) will make for a larger 'pit of success'.
Uuuggghhh, the baseless and ignorant JavaScript hate is a weak argument. It’s not any different than other baseless, weak, ignorant arguments; such as: ______ because _____(protected class) people.
I am paid well to do no work, essentially on retainer, because it’s so common for people to dick this up and then blame the technology for one’s own incompetence. Like anything else it only requires a little bit of practice. Running screaming into the night only to bury your head in the sand behind the magnificent glory of favorite pet framework x isn’t practice.
I describe this to nonprogrammers as hating on pianos because there is too much potential for bad music.
I said it was bad practice that led to the large size of Medium's website, but only 20% of that download size is their application's JavaScript. In what way did the use of JavaScript make it “easier” for the remaining 80% of the download size to happen?
My bet is LiveView will become the king of the fast prototype. It doesn't do SPA, but it does damn near everything else with ease and so few lines of code.
If I get this correctly, both this and Blazor are handling most of the UI logic in front-end, despite they are WASM.
So WASM is just another bytecode encoding that relatively smaller than JavaScript, without solving the problem from the root.
In contrast, a server-side heavy solution like Phoenix LiveView that has been heavily mentioned in this thread would do hold the logic on the server side, so in the client, there's only very few generic logic handling the DOM patching.
It depends on the JS and the WASM framework... Blazor in particular carries a lot of framework overhead with it. Also, like mentioned elsewhere in the article, something similar to JSX for one of these WASM frameworks would be very useful. As would a close to in the box UI toolkit that at least used or resembled material design or bootstrap.
Blazor is nowhere near optimized yet - give Microsoft some time. They just committed to Blazor officially (it was an 'experimental' project until the 19th of April.)
Comments
Between this and Blazor ( http://blazor.net/, among other wasm projects I'm forgetting right now), I'm glad more complicated UIs are being once again designed on the backend and keeping bundle sizes (relatively) small, rather than making everything in JS on the frontend and expecting everyone to download megabytes of code to visit a website.
I'm looking in your direction Medium, at 6MB with a cold cache!
Large bundle sizes are not a consequence of creating UIs on the frontend, they are a consequence of bad practice. I have created plenty of purely frontend apps that don't even approach 1 MB let alone 6 MB. In fact, most languages that can target WASM seem to produce enormous modules compared to a reasonable frontend JavaScript app. Rust is an outlier in my experience because of its minimal runtime.
It's also worth noting for example that only 1/5th of the data transferred when I load medium.com cold is their JavaScript, so WASM can't really help them either way.
Subset of Go + LVVM = 4.1k wasm demo (2.3k gzip'd)
Demo: https://richardanaya.github.io/wasm-module/examples/tinygo_c...
Article: https://medium.com/@richardanaya/hyper-efficient-front-end-d...
I did not know about tinygo and this is pretty impressive. However, it is only a subset of Go missing a few features, most notably the fact that memory is never deallocated.
Also, the equivalent JavaScript is still a fraction of this size. That's actually roughly the size of Preact, which implements nearly all of React.
Agreed, though it's a lot easier for bad practice to happen with JavaScript than a lot of other languages, and frameworks like this (hopefully) will make for a larger 'pit of success'.
Uuuggghhh, the baseless and ignorant JavaScript hate is a weak argument. It’s not any different than other baseless, weak, ignorant arguments; such as: ______ because _____(protected class) people.
I am paid well to do no work, essentially on retainer, because it’s so common for people to dick this up and then blame the technology for one’s own incompetence. Like anything else it only requires a little bit of practice. Running screaming into the night only to bury your head in the sand behind the magnificent glory of favorite pet framework x isn’t practice.
I describe this to nonprogrammers as hating on pianos because there is too much potential for bad music.
To be fair, working in this industry you could have been doing that without doing JavaScript :)
I said it was bad practice that led to the large size of Medium's website, but only 20% of that download size is their application's JavaScript. In what way did the use of JavaScript make it “easier” for the remaining 80% of the download size to happen?
Another lightweight contender, not WASM though, is Phoenix Live View[1]
[1] https://github.com/phoenixframework/phoenix_live_view
My bet is LiveView will become the king of the fast prototype. It doesn't do SPA, but it does damn near everything else with ease and so few lines of code.
I wonder how this copes with long-running pages. What happens if the server is updated and the minimal update format changes?
I have no experience doing this, but Erlang and Elixir do support hot upgrades.
The Big Elixir 2018 - Desmond Bowe - Hot Upgrade Are Not Scary https://www.youtube.com/watch?v=IeUF48vSxwI
Does Phoenix Live View currently support or intend to support SSE over HTTP2 instead of websockets?
Where are you seeing 6MB on Medium? It looks everything aside from images is <1MB compressed.
https://www.webpagetest.org/result/190426_YD_9088b86bbe21e61...
If I get this correctly, both this and Blazor are handling most of the UI logic in front-end, despite they are WASM.
So WASM is just another bytecode encoding that relatively smaller than JavaScript, without solving the problem from the root.
In contrast, a server-side heavy solution like Phoenix LiveView that has been heavily mentioned in this thread would do hold the logic on the server side, so in the client, there's only very few generic logic handling the DOM patching.
iirc WASM will tend to be larger than minified javascript.
It depends on the JS and the WASM framework... Blazor in particular carries a lot of framework overhead with it. Also, like mentioned elsewhere in the article, something similar to JSX for one of these WASM frameworks would be very useful. As would a close to in the box UI toolkit that at least used or resembled material design or bootstrap.
Blazor's bundle size (assuming client/wasm rendering) is pretty damned big. Also, JS is a pretty cool language imho.
Blazor is nowhere near optimized yet - give Microsoft some time. They just committed to Blazor officially (it was an 'experimental' project until the 19th of April.)