Read the link above for WebAssembly runtime outside of the browser! This could even obsolete the browsers themselves!
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.
Like everything new WASM has a certain amount of irrational excitement around it. While it sure looks a lot like Java or the CLR I think it has potential to be better, and a framework could be made to be a much better version of Electron, without a full browser behind the scenes. Electron proves people are fine without “native widgets” for big apps, so the runtime does not need to be as heavy as Qt and a ton of garbage from the web can be tossed. Security could also be a lot better and could use things like capabilities and tight per-app permissions, and in addition WASM is designed to run sandboxed.
I have an idea for an interesting proof of concept involving seamless software updates using a WASM app runtime. Imagine the “instant updates” we get on the web, but with the user in full control, tiny binary diffs, and of course no need to always be online. I think it could be interesting. Of course Haiku could do some of this with binary package diffs and some improvements in the software updater and HaikuDepot (other ideas I have had.)
Overall though a tiny OS like Haiku should support these sorts of efforts because it could bring a lot of high quality software if a WASM app framework takes off and we provide a runtime for it. I definitely plan to look at this stuff deeper over the next year.
1 Like
Ryan, nice to see you back and active again, hi!
Being a developer who doing open source development can be pretty hard sometimes. First the work-life balance, then doing what required, and finding a joyful new rechnology what one can use to keep up with the technology advancement, so the collected experiences can be used in their cv.
It is visible you are interested in wasm because lately almost all your forum posts was at least tangential about it.
As a mortal user i find it great to be able to see the plans of the developers.
But: your wrap up concentrates only to the gains, to the positive results. I can understand this, you like this technology, you would like to use, and why not making some hype then? Nothing wrong with it, except: it is way too realistic, it is way too possible, it sounds way too good, so simple minded users like me would say Lets do it!, something new for our belowed os, maybe it will make Haiku relevant in the big league.
But: lets not forget, what the project and the users would lose with the using of wasm in Haiku, and how much impact would it result in the philosophy of Haiku. I think it is also important, but i got not enough experience to be able to give an overview. I just got this feeling reading your post: technology went too far and became so abstract, layers over layers, a user have no chance to understand The inner workings of their os anymore, unlike for example in the old DOS time.
We see development only for the sake of development.
Some of the Haiku users using Haiku because it is plain, understandable system. I assume most critic about the PM Is because it makes the OS less understandable. Niw they wont be happy to seeing wasm involved in Haiku.
I am personally completely against introducing wasm in Haiku, but probably i amnot the person who can express why it is a bad idea.
Lets just say: it is a big decision, it will have serious impact on Haiku, to its use cases and its phylosophy.
Private aspect: if wasm will be introduced in Haiku i will say leave Haiku behind in the same second.