Bytecode Alliance could bring a stampede of new users

Read the link above for WebAssembly runtime outside of the browser! This could even obsolete the browsers themselves!

3 Likes

Thanks for the link, now i have enough motivation to switch to NetSurf yet this weekend on every machine around me.

Eh, no use claiming the sky is falling about this… people have been running obfuscated JS for an eternity.

This just means there is an official bytecode so people can stop writing crap JS code and use real programming languages on the web, which means yes they can make bloat ware but code that is well written will also be faster. The only way you can combat bad websites is te shame them not plug a hole in the stream of progress. You’ll also be able to dissasemble and decompile the code much like you can for .net code (which decompiles surprisingly well).

WebAssembly started on the Web but won’t end there. This article is about running WebAssembly outside the browser. We’re talking application code.

2 Likes

And… javascript also does that… java does that. I don’t see the point in worrying about it.

JavaScript is slower and only runs in a JIT. When running Node.js on a server it’s still just a dynamically typed scripting engine.

Java is memory hungry and run by a lawsuit-happy company. It’s increasingly useless for modern code since C#.NET has taken Java’s meal ticket.

In time, WebAssembly running stand-alone instead of in the browser could actually eliminate the browser altogether IMO. It compiles statically, JITs or interprets depending on how it’s used. An app developed in WebAssembly runs like native code but doesn’t care what CPU or OS it’s written on as long as there’s a backend for the CPU/OS combo that you want to run it on. The runtime will just plug into the host OS function calls.

As far as comparisons go, JavaScript needs to run bulky Elektron or some such thing to get its user interface which is practically a browser in a library anyway. Awkward.

It won’t be immediate but the mainstream OS’s don’t benefit as much as the small ones with this thing. Written on Linux but suddenly runs on Haiku without manual porting. Self-porting code is what I’m talking about.

You are mixing up languages and what developer communities do with them.

I’ve run Java and a full UI stack all written in it on microcontrollers with 256 kilobytes of RAM, and we got better performance than C there on some aspects. Whatever language you use, there will be people squishing out every bit of performance out of it, and there will be people writing bloatware.

What is the plan for user interface for WebAssembly? It’s a language, which does not come with its own UI. And since the project is coming from Web technologies and they want a portable framework, what else than HTML/CSS would they use for that?

To me it just looks like people behind WebAssembly noticing that it’s just impossible to get the web to evolve past Javascript, and so trying to sell their tech elsewhere instead.

Also Java is not bound to Oracle… there are other companies such as Red Hat maintaining and working on Java.

I mean I don’t see webassembly in this case going anywhere that node.js hasn’t… but it could be useful for allowing people to write code for the same use cases in thier language of choice.

The thing is webassembly isn’t a language, it’s a target.

Well yes, it’s like the JVM which can run Java but also Kotlin, Scala, etc. and could also run C or C++ if we wanted to and wrote a compiler for that. So you can make your C app need the heavy Oracle JVM and make a few kilobytes app need gigabytes of RAM. Sounds cool!

The WebAssebly System Interface is POSIX looking but the standard for GUI is not complete yet.

EDIT:
Their website is up now. That should help answer some questions. https://bytecodealliance.org/

The question for me is how much is it depending on a Internet connection? Not all people have interest to be connected to the Web all the time.

Although I believe, WebAssembly can do better than JavaScript, I doubt it will be easier way to write truly portable applications.

When it comes to back-end, it can be very tiny and easily portable but useless without tons of other more-or-less standard libraries, as C++ std is. Or it can be very large and almost universal but very hard to port to new system, as Java standard classpath is. Unfortunately, the intermediate state is worse than both extreams making it both hard to port and useless.

There is no such magic piece of code as “runtime that just plugs into the host OS function calls”. This one is really the system abstraction layer, which hides all system incompatibilities. But there is no one-to-one mapping among features of different OSes, so no such universal abstraction could exist. Each time the runtime is ported to new OS, it becomes clear that at one hand, the OS doesn’t provide some features necessary for the language and at other hand, some features of the OS are not covered by the language.

That depends on if it gets integrated with the package manager on all the POSIX OS variants. It will take time.

I hope they use wxWidgets or some similar gadget library for their API wrappers.

No. WASM “is” JavaScript just in a “binary notation”. The byte code is run “inside a JavaScript VM” so it has the same problems as JavaScript has.

I’ve worked with WASM before and it is a pain… any language which returns “undefined” or doing “nothing” in case of errors instead of throwing exceptions that you can actually trace and debug making you hunt bugs for many days is a crap language.

You’re still using it in a browser? I feel for you. Ugh! Maybe that’s why there is so much demand to drop the JavaScript-based sandbox and use it for native applications like the Bytecode Alliance is doing.

No, I’ve used WASM in browser, node.js and similar. The problem is not “where” it runs but that it runs “inside a JavaScript VM”… no matter how you twist and turn it. And this “alliance” crap is changing exactly nothing on that matter because the entire WASM construct breathes and oozes JavaScript through all its pores due to the way it is designed. You can’t flee the crappy heritage no matter where you go.

Please, please read up on how V8 runs before anyone else makes uneducated statements on how slow it is. Pay particular attention to the compilation pipeline and code generation

Then read it again

Then read up on Webassembly, LLVM, etc

I was at a React conference in San Francisco a few months ago where the guy behind Docker stated that if Webassembly was as mature now as it was then, they’d not have created Docker.

3 Likes

Sort of, it’s attached to the DOM through the JS VM, but it is not a JS VM it is it’s own thing… obviously it is immature but as such things are actually used such pet peeves can get fixed.

Also the intention was to remove this limitation at some point from what I remember it was just faster to do the initial implementation this way.