81–90 of 91 posts
Summarizing the "JSC https://news.ycombinator.com/item?id=14489577 Now that these points are out of the way, let's discuss implementation details, WebAssembly, and things!
Give me qt in the browser, the rest are details.
Earlier quoted context omitted.
Also, nobody wants to pay a C++ dev for doing a JS devs work, haha
you can still code in js or any other language.
I just thought, with JavaScript front-end development has been commoditized and C++ is harder than JavaScript. So I don't think many people would pay a more expensive C++ dev to use Qt for a WASM based app, if they could get it all going with a cheap JS dev.
Earlier quoted context omitted.
We're a long way away from that. Here's what you'd need: - GC types in WebAssembly. That's still an open problem, but that would give you API access. - Ability to load WebAssembly via something like . - WebAssembly would have to load and start as quickly as JS. The last one is probably the hardest in the long run, since wasm is being optimized for the kinds of apps where you want to pay some cost up front so that you…
> GC types in WebAssembly. That's still an open problem, but that would give you API access. Nothing prevents one to implement a GC on top of existing WebAssembly as it is, no different than when implementing bare metal runtimes. Of course having a GC as part of WebAssembly does simplify implementations, but only as an easy solution, because the best GC implementations need to be language aware for optimal performanc…
Except that efficient GC implementations use concurrency with a shared memory space and locking and memory-barrier instructions that are not yet available in WASM. (AFAIK, please prove me wrong)
Earlier quoted context omitted.
It's implementation dependent. Most implementations JIT Wasm up front (I think Chakra is the only engine that interprets). So, JS loads faster because almost all engines interpret first (all?).
Is “interpreting” necessarily faster? Consider also this is perhaps a false distinction. V8 always produces machine code when running JS IIRC. And that code is JITed doesn't mean the entire module is.
They used to. They stopped doing that because it made initial load too slow...
Earlier quoted context omitted.
> GC types in WebAssembly. That's still an open problem, but that would give you API access. Nothing prevents one to implement a GC on top of existing WebAssembly as it is, no different than when implementing bare metal runtimes. Of course having a GC as part of WebAssembly does simplify implementations, but only as an easy solution, because the best GC implementations need to be language aware for optimal performanc…
> Nothing prevents one to implement a GC on top of existing WebAssembly as it is Except that efficient GC implementations use concurrency with a shared memory space and locking and memory-barrier instructions that are not yet available in WASM. (AFAIK, please prove me wrong)
Earlier quoted context omitted.
> GC types in WebAssembly. That's still an open problem, but that would give you API access. Nothing prevents one to implement a GC on top of existing WebAssembly as it is, no different than when implementing bare metal runtimes. Of course having a GC as part of WebAssembly does simplify implementations, but only as an easy solution, because the best GC implementations need to be language aware for optimal performanc…
> Nothing prevents one to implement a GC on top of existing WebAssembly as it is Except that efficient GC implementations use concurrency with a shared memory space and locking and memory-barrier instructions that are not yet available in WASM. (AFAIK, please prove me wrong)
So GC were implemented within those constraints, which means it is possible to do within the current state, even if it isn't the most optimal one versus the availabilities of such CPU features.
Also, it probably means the end of the Web as we know it.
Browsers very likely should treat closed source like they treat our microphone or camera: don't give access unless the user consents.
But do allow it to run without consent if, and only if, the source code is public.
WebAssembly means closed source binaries all over again, and threatens our ability in all the metrics Stallman advocates. Also, it probably means the end of the Web as we know it. Browsers very likely should treat closed source like they treat our microphone or camera: don't give access unless the user consents. But do allow it to run without consent if, and only if, the source code is public.
You can get text out of WebAssembly as well as you can get text out of minified JS.
Further, users don't care about this. It's literally just developers. Open Source / Free Software is a super valid discussion to have, but I highly doubt any non-technical user cares.
Amusingly, pcwalton brought up this discussion recently: https://twitter.com/pcwalton/status/872151997473972224
Earlier quoted context omitted.
Give me qt in the browser, the rest are details.
Please no. We only just finished killing Flash (mostly); the last thing we need is another UI framework which doesn't respect standard features of the web platform taking its place.