Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Great. We will soon have an entire JVM running inside each browser's tab, just to run an animated slider. Maybe even more than one. Plus a .NET VM, several Python and Ruby interpreters, and so on.

Because webmasters will keep loading ready-made plugins from CDNs, exactly like they are doing now, except that the new generation of web software will carry their own interpreter or runtime with them, because the developer wanted to use Python or whatever.

The web is getting better by the day.




I'd like to interject for a moment here, and pitch my idea about what I call the "Web 4.0". It's basically a binary equivalent of HTML, without the many inconveniences of HTML for content providers.

Web 4.0 pages are obfuscated WebAssembly payloads, that draw their contents via WebGL. This way, adblocking becomes impossible, as the actual content and ads are within the same opaque WebGL framebuffer. Stealing copyrighted text is also made significantly harder, beause the Web 4.0 platform leaves it up to the publisher to enable glyph selection and copying. You have concerns about accessibility? Web 4.0 is 100% accessible thanks WebAudio based realtime speech synthesis!


it'll also be harder to learn how things work... i wonder how much we've learned from reverse engineering the easy to read inline script tags... I definitely remember teaching myself JavaScript by reading blizzard.com's late 90s markup... figuring out that mouse over effect with onmouseover and onmouseout... works in ie4... but whats that strange bug in netscape 4..


You can't really do that today anymore though


> adblocking becomes impossible

No, it'd just take a sufficiently smart AI.


Just like the good old days with sites built in Flash :)


wasm is modular, so in theory, you could produce a jvm9.wasm file, put it on a CDN with caching, and every site that wanted to do that could share it, and you'd only download it once.

I do agree that runtime-less languages have an advantage here though.


We're still a long ways off from garbage-collected languages inside wasm.

That said, it's not the technology's fault that people abuse or otherwise make poor use of it. I see no point in limiting it on that basis.


> That said, it's not the technology's fault that people abuse or otherwise make poor use of it.

I felt like I should respond to this, too.

It's not, but it is not unreasonable to object to implementing new ways for browsers to hog resources pretty much at the hosts' discretion. In this case it can be argued that it's poor use of technology to implement it in the browser.

On a similar basis, one might argue that it's poor use of technology to kill people with dynamite, but it is also reasonable to take a step back and argue that it is poor use of technology already at the point at which you gave a toddler the detonator. Regardless, dynamite is an excellent and useful technology.


I understand your point, and admittedly I have many of the same concerns.

That said, some of us have legitimate uses for said dynamite, pyromaniac infants be damned.


> We're still a long ways off from garbage-collected languages inside wasm.

I'm not sure what you mean by that. Is there some limitation inherent to WebAssembly that makes implementing garbage collection particularly difficult?

For what it's worth, here's Lua (which implements a garbage collector in its runtime) in WebAssembly: https://github.com/vvanders/wasm_lua


I'm impressed. It seems to be in total working order when trying out collectgarbage, __gc and __mode[0].

Code:

  print(_VERSION)
  local a = setmetatable({}, {__mode = 'v'})
  local b = setmetatable({}, {__gc = function(x) print("Deleting: " .. tostring(x)) end})
  a[1] = b
  a[2] = 2
  print(table.unpack(a))
  print(collectgarbage'count')
  b = nil
  collectgarbage()
  print(table.unpack(a))
Result:

  Lua 5.3
  table: 0x50a748 2
  21.4033203125
  Deleting: table: 0x50a748
  nil 2
[0] - 3 features tied to the Lua GC, to simplify, they basically are (respectively): forcefully running the GC, finalizers that run when object is collected and weak refs that don't hold the object alive on their own.

Perhaps http://www.lua.org/demo.html could be replaced with that for users who have JS enabled.

Again - just wow, that's really nice, Lua in a browser.


>I'm not sure what you mean by that. Is there some limitation inherent to WebAssembly that makes implementing garbage collection particularly difficult?

Yes, in that you'd have to implement the GC inside the wasm module itself (as in your example). In contrast to other languages, Lua is very lightweight. Many GCs are non-trivial.

Moreover, proper GC support is a piece of the puzzle for the wasm/JS/DOM interop story to get better.

See: https://github.com/WebAssembly/design/issues/1079


> Yes, in that you'd have to implement the GC inside the wasm module itself (as in your example).

That is essentially the same problem people implementing garbage collectors on real machines are facing. You have some memory and you have to implement the algorithms and data structures necessary to allocate and free it as necessary.

> Lua is very lightweight. Many GCs are non-trivial.

Yes, but don't confuse the problem of implementing a garbage collector with the problem of implementing a system that can support a garbage collector. The former may be non-trivial, while the latter only supposes an architecture where you can arbitrarily manage memory "manually". From what I understand, you just hand WASM an array of memory and it can do whatever it wants with it, since it's a linear bounded automaton.

> Moreover, proper GC support is a piece of the puzzle for the wasm/JS/DOM interop story to get better.

The link seems to be addressing the use of VM-managed GC objects within WASM programs. That would certainly a nice feature, especially when it comes to interoperability with JS, but the lack of it is not a showstopper for implementing your own garbage collector as it has always been done.


>Yes, but don't confuse the problem of implementing a garbage collector with the problem of implementing a system that can support a garbage collector. The former may be non-trivial, ...

In most cases it isn't non-trivial, and that's further compounded by the fact that the GC currently has to be part of the module payload at the moment.

If we're talking strictly implementation difficulty, then interop with VM-managed GC objects may in fact be more difficult; I'm certainly not an expert so I couldn't tell you.

>... but the lack of it is not a showstopper for implementing your own garbage collector as it has always been done.

Per the very first sentence of mine you quoted, I never said it was. It certainly is likely to be far from practical, however.

Also I suggest reading the sibling comment that Steve Klabnik replied with prior. The wasm host bindings proposal is now separate from the GC proposal.


> In most cases it isn't non-trivial, and that's further compounded by the fact that the GC currently has to be part of the module payload at the moment.

My point here is that it is beside the point whether it's trivial or non-trivial to implement a garbage collector. With regards to it having to be part of the module payload, that's how garbage collectors are typically implemented today, meaning it's very practical in the sense that you can just re-target that portion of your language runtime implementation like any other part without making the web a special case. Just target the new instruction set architecture and you have your garbage collector exactly as intended, tuned for the use case you designed it for.

> If we're talking strictly implementation difficulty, then interop with VM-managed GC objects may in fact be more difficult; I'm certainly not an expert so I couldn't tell you.

It may be more difficult, but in the end also an entirely different problem. If you have implemented a garbage collecting language runtime for your language, you've already solved the problem of garbage collection.

> Per the very first sentence of mine you quoted, I never said it was. It certainly is likely to be far from practical, however.

My question from the start was about how exactly it is impractical. Your reply focusing on the hardships of implementing a garbage collector and using the VM GC is an interesting side note, and I appreciate the response and discussion, but it ultimately doesn't answer the question. The evidence to my point is a fully functioning garbage collected language runtime compiled seemingly without modification (it's written in ANSI C, after all) for the WebAssembly platform. You can do that now, without additional hurdles and without considering the garbage collection semantics of the browser runtime. That seems very practical to me.

It is also very practical to be able to use objects allocated and managed by the browser instead of a contiguous array of memory, but that doesn't somehow make the obvious approach less practical.


>My point here is that it is beside the point whether it's trivial or non-trivial to implement a garbage collector.

>My question from the start was about how exactly it is impractical. Your reply focusing on the hardships of implementing a garbage collector and using the VM GC is an interesting side note, and I appreciate the response and discussion, but it ultimately doesn't answer the question.

The hardships of the implementation are central to why it's impractical. That said, I think we may be using different definitions of the word impractical here.[0] I'm talking strictly in a general sense, that packaging an entire language's runtime with code is—for most uses right now—not sensible.

You are correct in that it's entirely possible to use GCed languages inside wasm, and indeed it has been done—I'm not disputing that.

I also understand your point about the multi-platform advantages of keeping the GC portion of the runtime inside of wasm. Funny enough that may turn on its head in the distant future once GC support lands, assuming wasm ends up being a popular compilation target outside of the web. In that case you'd have wasm-managed GC objects on desktop and mobile.

>The evidence to my point is a fully functioning garbage collected language runtime compiled seemingly without modification (it's written in ANSI C, after all) for the WebAssembly platform. You can do that now, without additional hurdles and without considering the garbage collection semantics of the browser runtime. That seems very practical to me.

Lua is very lightweight. The story changes if you try to compile the .NET, JVM, Go or even V8 runtimes into wasm. All possible, but a hell of a lot more difficult.

One case study is Blazor.[1] The FAQ in its own readme states that it's not practical currently due to binary sizes, albeit not for GC-related reasons. But it will be practical. That was the gist of what I was trying to say, that GCed languages (i.e. ones that include their own runtime) are currently not terribly practical relative to the compiled alternatives, most of which are production-ready now.

Of course, having seriously evaluated Unreal Engine 4 for web use with its 50MB runtime, I view even Blazor's current 4MB binary size as quite practical, but it depends on the use case. For general web use, 4MB isn't practical.

In support of your point, I concede that whether the GC resides in the module or VM is largely immaterial to practicability as a whole. My point was that packaging the runtime with the payload is usually not sensible relative to the alternatives. I regret that I incorrectly generalized my original statement in terms of garbage collection rather than runtime overhead.

[0] https://en.oxforddictionaries.com/definition/impractical

[1] https://github.com/SteveSanderson/Blazor


> The hardships of the implementation are central to why it's impractical.

That's a very general statement. There are many hurdles that will make porting some things to WebAssembly a pain, but I don't think GC in particular is one of them.

> That said, I think we may be using different definitions of the word impractical here.[0] I'm talking strictly in a general sense, that packaging an entire language's runtime with code is—for most uses right now—not sensible.

I don't we have a different idea of what impractical means. I am not talking so much about porting an entire language run-time for a language with a very system dependent run-time, and I am not talking about useful libraries of these languages, I am talking about garbage collection.

> I also understand your point about the multi-platform advantages of keeping the GC portion of the runtime inside of wasm. Funny enough that may turn on its head in the distant future once GC support lands, assuming wasm ends up being a popular compilation target outside of the web. In that case you'd have wasm-managed GC objects on desktop and mobile.

I doubt that using a single opaque garbage collector is a good option for many languages. It's interesting and would certainly make the implementation of new languages easier, but a garbage collector that performs well will probably always be quite language dependent. I also don't see the advantage of WebAssembly as a compiler target in general. We already have LLVM IR and the tooling that makes it a (relative) breeze to work with independent of the target.

> Lua is very lightweight. The story changes if you try to compile the .NET, JVM, Go or even V8 runtimes into wasm. All possible, but a hell of a lot more difficult.

Don't ignore that it's a very broadly applicable and quite popular language. There are plenty of languages not particularly dependent on large runtimes that use garbage collectors. It is not fair to conclude that a language with a garbage collector necessarily has a very complex runtime when implementations of the concept have existed since the late 50s. CLR (I assume that's what you mean by .NET), JVM and V8 are all JIT compilers. Porting that likely dwarfs the complexity of porting their garbage collectors. As for Go, I'm not sure why porting its run-time would be that much of a hassle. For JVM, there are already plenty of relatively tiny implementations.

> One case study is Blazor.[1] The FAQ in its own readme states that it's not practical currently due to binary sizes, albeit not for GC-related reasons. But it will be practical. That was the gist of what I was trying to say, that GCed languages (i.e. ones that include their own runtime) are currently not terribly practical relative to the compiled alternatives, most of which are production-ready now.

So it's impractical in some cases because of large binaries, not for any of the reasons you've pointed out so far. Giving WebAssembly programs a way to integrate with the VM GC will change this how, exactly? In Blazor's case the large file size can likely be attributed to things not strictly related to the run-time, like the core libraries.

> Of course, having seriously evaluated Unreal Engine 4 for web use with its 50MB runtime, I view even Blazor's current 4MB binary size as quite practical, but it depends on the use case. For general web use, 4MB isn't practical.

What is general web use, and how does it relate to WebAssembly? By jamming this technology into a browser in the first place, we've already conceded that the web is a generic application platform for which using plain documents or simple JavaScript is sometimes unsuitable. I don't necessarily agree that it should be, but here we are, and there are plenty of uses, given those terms, where large binary sizes may be justifiable. A large download may be worthwhile if it ends up in my browser cache and I am likely to use the application often. That doesn't mean it's suitable for serving ads in novel ways or implementing trivial web applications that you can easily implement in JS.

> In support of your point, I concede that whether the GC resides in the module or VM is largely immaterial to practicability as a whole. My point was that packaging the runtime with the payload is usually not sensible relative to the alternatives.

What are the alternatives? As far as I am concerned, it's either using regular non-web applications or using plain JS. If that's what you mean, I agree that those alternatives are better in a large majority of cases. The best case scenario is that WebAssembly will end up being "here's something closely resembling the CPU, here's some memory, here's some way to access and manage VM objects, and here's a way for JS to call your code". That's not going to make it much easier to port a language run-time or its libraries than it is for any other platform. It will make it easier to write code that interacts with the existing browser environment.


>I am not talking so much about porting an entire language run-time for a language with a very system dependent run-time, and I am not talking about useful libraries of these languages, I am talking about garbage collection.

I'm talking about the former as pretty much the entirety of my previous comment tried to convey.

>I also don't see the advantage of WebAssembly as a compiler target in general.

The advantage is it would be a single target.

>So it's impractical in some cases because of large binaries, not for any of the reasons you've pointed out so far. Giving WebAssembly programs a way to integrate with the VM GC will change this how, exactly?

It's impractical primarily because it's not production-ready. In the interests of pedantry however, reliance on a VM GC would likely result in a somewhat smaller binary size.

>In Blazor's case the large file size can likely be attributed to things not strictly related to the run-time, like the core libraries.

Per its readme: "This is because Mono on WASM doesn't yet have any IL stripping or minification, and bundles a large runtime that includes many desktop-related features that are irrelevant on the web."

>What is general web use, and how does it relate to WebAssembly?

Most people use the internet to visit websites. Most major websites optimize their page loads as much as possible to fit as many ads in as they can without completely tanking the user experience. Using the previous example, a 4MB binary doesn't fit that use case. It would be more the realm of specialized applications.

>What are the alternatives?

Javascript ecosystem or production-ready compiled languages that target wasm.


> We already have LLVM IR and the tooling that makes it a (relative) breeze to work with independent of the target.

http://webassembly.org/docs/faq/#why-not-just-use-llvm-bitco...


> Moreover, proper GC support is a piece of the puzzle for the wasm/JS/DOM interop story to get better.

I commented with a link elsewhere, but it seems that people have found a way around that!


Relevant discussions in case anyone's interested:

https://news.ycombinator.com/item?id=15694292

https://news.ycombinator.com/item?id=15694289

I didn't see those, thanks. That's good news. Hopefully host bindings land sooner now than they otherwise would have if tied to the GC proposal.

The wasm32-unknown-unknown LLVM backend target for Rust is also quite exciting. I say this after having just spent a minor eternity compiling the Emscripten toolchain. :)


And to have different pythons running together we need docker with ubuntu.


I hope to have at least 128GB of ram in my phone by that time :)


Then there should be a huge market opportunity to provide identical services at far smaller and faster downloads.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: