81–90 of 103 posts
Earlier quoted context omitted.
> And, the frontend will start having the same amount of fragmentation as the backend. Err, I think that boat has already sailed?... E.g. Grunt, Gulp, Webpack, make, Parcel, Brunch, Browserify, etc, etc, etc.
As far as tooling, sure. But this will take it up a level to base language. Surely that's an exponential difference? Frontend dev won't mean what it means today.
Earlier quoted context omitted.
Funny. I came here to complain that it's not a standalone app and yet another crappy browser app.
I also would prefer standalone apps, but if my choice is between a browser app and a "standalone app" made with electron, the browser app wins in a landslide.
It would be quite interesting when Browser Apps could also run as native apps without relying on electron (ie, being able to pull up their own UI when not provided one)
The compiler/converters are here: https://github.com/WebAssembly/binaryen
Maybe someone who knows more could help me understand better. It looks the toolchain "stack" is some-lang through LLVM to a special WASM LLVM backend which then is converted to WASM - which is similar to the LLVM-IR.. but more crossplatform-y.. I think? (can someone confirm?). So I guess going forwards WASM is the new crossplatform bytecode and not necessarily tied to the web - right? I don't really get if WASM has memory-managment / garbage-collection by default or it's something optional available to things like Javascript? Or the GC is written in WASM itself...?
With LLVM-IR/WASM/SPIR-V it's kinda a shame we have all these standards doing very very similar things - but I kinda get the rational there
Earlier quoted context omitted.
As far as tooling, sure. But this will take it up a level to base language. Surely that's an exponential difference? Frontend dev won't mean what it means today.
You mean like Dart, Elm, Haxe and whatever else already compiles to javascript?
For those interested, this is using the Monaco editor https://github.com/Microsoft/monaco-editor
Yes! I was so happy when they pulled this out of VSCode. I really want to use it on a future project and I love the idea of code in the browser for sharing learning opportunities!
I'm non-plussed. Their "Hello World" example in C is essentially unparseable for anyone who doesn't already know what's going on. Anyone care to explain it? I don't know how much of this example is written in js and how much in C, how much is boilerplate or anything. It's awful.
Earlier quoted context omitted.
I also would prefer standalone apps, but if my choice is between a browser app and a "standalone app" made with electron, the browser app wins in a landslide.
With WASM this is no longer a problem. Just supply your own JVM-for-WASM. The standard does expect it to be ported natively to platforms eventually. It would be quite interesting when Browser Apps could also run as native apps without relying on electron (ie, being able to pull up their own UI when not provided one)
What do you see as the advantage of native at that point - having its own window?
I have to say I am pretty excited about WebAssembly. I've been through many programming languages. C# might be my favourite and F# always seemed like it would be if I took the time to learn it properly but for quite a few years now, JS has simply had such gravitational pull that I felt like I had to go with it. And I have to say, I've learned to not only like but to love it. Save for the mutable data structures that…
Bytecode formats as portable binaries have always been a thing on the mainframe world all the way back to the 60's, it has just taken quite a few decades to become commodity across mobile, desktop and web worlds.
Earlier quoted context omitted.
With WASM this is no longer a problem. Just supply your own JVM-for-WASM. The standard does expect it to be ported natively to platforms eventually. It would be quite interesting when Browser Apps could also run as native apps without relying on electron (ie, being able to pull up their own UI when not provided one)
> It would be quite interesting when Browser Apps could also run as native apps without relying on electron (ie, being able to pull up their own UI when not provided one) What do you see as the advantage of native at that point - having its own window?
Then there is the efficiency. My suspicion is that electron has a completely misconfigured caching system. Usually only one browser is running on a system and therefore many applications share the caching system. This means each electron application has an oversized cache that wastes memory and disk without meaningfully increasing performance.
The tools for working with WASM are here: https://github.com/WebAssembly/wabt The compiler/converters are here: https://github.com/WebAssembly/binaryen Maybe someone who knows more could help me understand better. It looks the toolchain "stack" is some-lang through LLVM to a special WASM LLVM backend which then is converted to WASM - which is similar to the LLVM-IR.. but more crossplatform-y.. I think? (can someone c…
It's simply not possible to compare LLVM-IR to WASM SPIR-V JVM BEAMVM CLR bytecode.