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 <reng...@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 < > golang-nuts@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+unsubscr...@googlegroups.com. >> To view this discussion on the web visit https://groups.google.com/d/ >> msgid/golang-nuts/CAN4yCu_nHObFToYaM-7CwuiK42EWGinVZNGZt0Ow4x73DXu5 >> 2Q%40mail.gmail.com >> <https://groups.google.com/d/msgid/golang-nuts/CAN4yCu_nHObFToYaM-7CwuiK42EWGinVZNGZt0Ow4x73DXu52Q%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- > 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+unsubscr...@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/golang-nuts/CAEkBMfGF%2BYbMWk0hAzU2GTFLXLbsJ4pvurejV > VNrZF43Yh0kZA%40mail.gmail.com > <https://groups.google.com/d/msgid/golang-nuts/CAEkBMfGF%2BYbMWk0hAzU2GTFLXLbsJ4pvurejVVNrZF43Yh0kZA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAN4yCu9j9m1T%3Ds8a90REdGnAK5Ztxd-zEP6QFWS9om-BXY0hPA%40mail.gmail.com.
