Now that wasm is 'standard'... bundle common lang runtimes with browsers

145 views
Skip to first unread message

Russtopia

unread,
Dec 22, 2019, 3:16:11 AM12/22/19
to golang-nuts
Crazy idea, but:

Now that wasm is 'official', why not push browser vendors to put the Go runtime/stdlib, built for wasm, right into the browser so it doesn't need to be downloaded with every single *.wasm project?

Of course, to be fair, not just Go -- why not also python-wasm-runtime, c-wasm-runtime, rust-std-runtime, ...

This would require some sort of 'runtime plugin' standard with versioning, feature-query and supply-chain security/update mechanisms, of course, but wouldn't it be nice?

I've been playing with gopherjs and go-wasm, and the big downside to both is that the baseline *.js file is 1.5-2MB or more, due to bundling a complete language runtime that must download with every app.

With official 'blessed' wasm runtimes for major languages we could finally break the deadlock on JS in the browser.

Axel Wagner

unread,
Dec 22, 2019, 6:33:56 AM12/22/19
to Russtopia, golang-nuts
ISTM that this requires being able to distribute the runtime of the language separately from the "user code" and link them together again successfully. Once you have that - it seems a problem far better solved by decent caching. That is, as a Go-user, I'd put a "load Go runtime from https://golang.org/wasm/<hash_of_version>" or something in my page. That resource is then infinitely cacheable, thus must only be downloaded approximately once (just as if it's bundled). What you get is, that as a developer, you don't need to wait until your favorite version of the runtime of your favorite language is available in all common browsers.

I'd see "the runtime is bundled with a browser" as replicating exactly the main problem with javascript - that you can't use all its features, because you constantly have to worry about whether or not it's supported in the browser. It seems to subvert what I'd perceive as the main goal of wasm: Decouple the browser engine from the code the developer wants to run in it.



--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAN4yCu_nHObFToYaM-7CwuiK42EWGinVZNGZt0Ow4x73DXu52Q%40mail.gmail.com.

Robert Engels

unread,
Dec 22, 2019, 10:04:39 AM12/22/19
to Axel Wagner, Russtopia, golang-nuts
Pretty much the JVM in the browser all over again... if I can live long enough maybe I can see people touting the ergonomics and simplicity of the 3270. 

Russtopia

unread,
Dec 22, 2019, 4:47:37 PM12/22/19
to Robert Engels, Axel Wagner, golang-nuts
Points well taken. Hadn't considered that simply caching should negate any load time issues.

Also agreed, reinventing applets is probably a bad idea... <shudder>
No more posting hare-brained ideas whilst half-asleep :)

Cheers,
-R.

On Sunday, 22 December 2019, Robert Engels <ren...@ix.netcom.com> wrote:
Pretty much the JVM in the browser all over again... if I can live long enough maybe I can see people touting the ergonomics and simplicity of the 3270. 

On Dec 22, 2019, at 5:33 AM, 'Axel Wagner' via golang-nuts <golan...@googlegroups.com> wrote:

ISTM that this requires being able to distribute the runtime of the language separately from the "user code" and link them together again successfully. Once you have that - it seems a problem far better solved by decent caching. That is, as a Go-user, I'd put a "load Go runtime from https://golang.org/wasm/<hash_of_version>" or something in my page. That resource is then infinitely cacheable, thus must only be downloaded approximately once (just as if it's bundled). What you get is, that as a developer, you don't need to wait until your favorite version of the runtime of your favorite language is available in all common browsers.

I'd see "the runtime is bundled with a browser" as replicating exactly the main problem with javascript - that you can't use all its features, because you constantly have to worry about whether or not it's supported in the browser. It seems to subvert what I'd perceive as the main goal of wasm: Decouple the browser engine from the code the developer wants to run in it.



On Sun, Dec 22, 2019 at 9:16 AM Russtopia <rma...@gmail.com> wrote:
Crazy idea, but:

Now that wasm is 'official', why not push browser vendors to put the Go runtime/stdlib, built for wasm, right into the browser so it doesn't need to be downloaded with every single *.wasm project?

Of course, to be fair, not just Go -- why not also python-wasm-runtime, c-wasm-runtime, rust-std-runtime, ...

This would require some sort of 'runtime plugin' standard with versioning, feature-query and supply-chain security/update mechanisms, of course, but wouldn't it be nice?

I've been playing with gopherjs and go-wasm, and the big downside to both is that the baseline *.js file is 1.5-2MB or more, due to bundling a complete language runtime that must download with every app.

With official 'blessed' wasm runtimes for major languages we could finally break the deadlock on JS in the browser.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages