Mozilla, Intel, and More Form the Bytecode Alliance To Take WebAssembly Beyond Browsers (neowin.net) 91
slack_justyb writes: Mozilla has been heavily invested in WebAssembly with Firefox, and today, the organization teamed up with a few others to form the new Bytecode Alliance, which aims to create "new software foundations, building on standards such as WebAssembly and WebAssembly System Interface (WASI)." Mozilla has teamed up with Intel, Red Hat, and Fastly to found the alliance, but more members are likely to join over time. The goal of the Bytecode Alliance is to create a new runtime environment and language toolchains which are secure, efficient, and modular, while also being available on as many platforms and devices as possible. The technologies being developed by the Bytecode Alliance are based on WebAssembly and WASI, which have been seen as a potential replacement for JavaScript due to more efficient code compiling, and the expanded capabilities of being able to port C and C++ code to the web. To kick things off, the founding members have already contributed a number of open-source technologies to the Bytecode Alliance, including Wasmtime, a lightweight WebAssembly runtime; Lucet, an ahead-of-time compiler; WebAssembly Micro Runtime; and Cranelift.
Original Source (Score:5, Informative)
Where it belongs (Score:4, Insightful)
Good. A movement to put WebAssembly where it belongs -- not in the browser! The Web Browser should remain a display interface and should not ever execute code from third-parties. JavaScript should be banned in the browser along with WebAssembly.
You Might Not Need JavaScript (Score:2)
A website can be interactive without needing script. For example, it can use CSS checkboxes and animations and/or the <details> element for accordions and tabbed panes, as well as the <form> and <input> elements to formulate queries. See You Might Not Need JavaScript [youmightnotneedjs.com].
Re:Where it belongs (Score:4, Insightful)
You fill out a big form of information. Hit that submit button have a full page refresh, re-render all the HTML again to tell you that you had filled out a bunch of fields wrong.
Because we don't have any client side processing to do things like.
Input formatting and validation.
Running asyncronious requests to the server to get and validate information
replacing an HTML segment with different HTML just for a notification.
Today the Web Browser is less of graphical dumb terminal, and considered the UI layer of the nTier architectural setup.
One can argue HTTP and HTML is a bad protocol for robust internet based applications. I myself would had preferred X11/SSH for this. But like most of this sector the winning standard isn't the best one, but good enough that has a lot of developers who can write for it.
If Microsoft added an X11 client default in Windows 3.1 the world may be different.
Re: (Score:2)
So the good old days.
You fill out a big form of information. Hit that submit button have a full page refresh, re-render all the HTML again to tell you that you had filled out a bunch of fields wrong.
We could have had more of that functionality without actually running supplied code in our browsers, though. All you really need is frames/iframes, form validation, rollovers, and maybe some basic animation effects to cover the functionality of 99% of dynamic websites.
replacing an HTML segment with different HTML just for a notification.
That still happens. It's just mediated through javascript.
If Microsoft added an X11 client default in Windows 3.1 the world may be different.
You mean X server?
Re: Where it belongs (Score:1)
Re: Where it belongs (Score:2)
Re: (Score:2)
Re: (Score:2)
frames and iFrames were a bad idea.
Why?
And it doesn't fix the problem of form validation and text formatting.
Read the whole comment before replying, it'll save us both some time.
Re: (Score:2)
You fill out a big form of information. Hit that submit button have a full page refresh, re-render all the HTML again to tell you that you had filled out a bunch of fields wrong
Yeah we had a solution to that. It was called XForms [wikipedia.org] and everyone decided to just do it in JavaScript instead. This notion that we have to have complex execution of code is ridiculous for basic validation. Hell even the Telenet TN5250 protocol had basic validation without the need for complex code execution. What JavaScript is used for today is just plain laziness on the W3 and related steering committees.
Today the Web Browser is less of graphical dumb terminal, and considered the UI layer of the nTier architectural setup
And even that is incorrect for today's browser. The browser has become an entire platform for code
Re: (Score:3)
Oh sure I agree with you, but to date none of the replacement proposals can do everything that I rely on X11 for every day. First and foremost is individual app remoting over ssh. It boggles my mind that this sort of thing is so far down the list of priorities for those focused on Wayland. So much energy is focused on mythical "new users" that the needs of actual user base of Linux appear to often be ignored.
Re: (Score:2)
Re: (Score:2)
It boggles my mind that this sort of thing is so far down the list of priorities for those focused on Wayland
I'm just going to clear something up here. That will never ever, ever be a priority for Wayland developers, end of story. [freedesktop.org] Implementing per app net transparency will have to be some other application that works with Wayland, but adding it to Wayland's core protocol will never happen unless some group replaces every single dev currently working on Wayland. If you are waiting to leave Xorg because of this matter, then you might as well go ahead and accept that you will never leave Xorg.
It is also possible to put a remoting protocol into a wayland compositor, either a standalone remoting compositor or as a part of a full desktop compositor.
And honestly I think
Pattern validation without script (Score:2)
So the good old days.
As it still ought to be, according to script haters.
You fill out a big form of information. Hit that submit button have a full page refresh
Cached CSS, cached fonts, cached images, new HTML document.
Input formatting and validation.
Since then, HTML5 introduced several new <input type="..."> values that display custom pickers, as well as <input pattern="..."> validators based on regular expressions that don't need script. See <input> on MDN [mozilla.org]. I concede that there are things I wish were in HTML5, such as <input> elements that are conditionally required based on the value of another <input> element.
Re: (Score:2)
A movement to put WebAssembly where it belongs -- not in the browser!
You don't understand the movement at all. ... Now how people use a browser evidently.
Please keep your anti-progress rant to the Amish forum where it belongs.
Re: (Score:2)
Just so long as your "progress" can be limited to you and your ilk, and I have the ability to turn it off. And if you subsequently cry up a storm about the bad outcome of your "progress" (such as RansomWare locking up all your files, or some other nastiness befalling you) then please keep it in your own teacup because I am not particularly interested in having to point out "I believe I told you this is exactly what the result would be and you proceeded anyway, obtaining exactly the result you intended".
To
Re: (Score:2)
I doubt ransomware running from a website can lock up your files except for those few files and folders that you have given that site permission to write.
This sounds bad (Score:2)
Looking it up, I am just seeing a lot of Python.
Re: (Score:1)
Trying to make the rest of the world that doess not already program in Javascript, program in Javascript. Ever seen Invasion of the Body Snatchers? [wikipedia.org]
Re: (Score:2)
Ever seen Invasion of the Body Snatchers? [wikipedia.org]
No I haven't. I don't like horror movies.
Re: (Score:1)
Ever seen Invasion of the Body Snatchers? [wikipedia.org]
No I haven't. I don't like horror movies.
I guess that means you don't like Javascript.
Re: (Score:2)
The reason I didn't get into web development.
Java! (Score:4, Insightful)
Bytecode Alliance is Java 2.0.
Runs anywhere*!
* Certain exclusions apply.
Re: (Score:2)
Runs anywhere*!
Has no exploitable holes*!
* Certain exclusions apply.
Re: (Score:2)
* For sufficiently loose definitions of "runs" and "anywhere".
Re: (Score:2)
Without Oracle (Score:2)
Bytecode Alliance is Java 2.0.
This time, without the corrupting influence of One Rich American Called Larry Ellison.
I Wish (Score:5, Insightful)
WebAssembly can not access the DOM so how could it possibly replace Javascript? Don't get me wrong, the thought of being able to write an single app in a native language that can run inside a browser or in the desktop environment sounds great but unfortunately this will not replace Javascript. If anything, it's yet another technology that needs to run alongside Javascript and thus props up a language that should have been killed off many years ago.
Re:I Wish (Score:4, Funny)
WebAssembly can not access the DOM so how could it possibly replace Javascript?
You run WebKit compiled in WebAssembly and paint your contents using OpenGL ES, silly.
Re: (Score:2)
Create,Read,Update and Delete
WebAssembly without access to the DOM really serves no point.
Like Java (Score:1)
Re: (Score:2)
Re: (Score:2)
WRT the performance of Java, the JVM is simply put the fastest virtual machine currently available; as everything man-made, it has its defects, which we may discuss, but bad performance is not one of them.
WRT to the "half-baked object model that you can't replace", there are many languages other than Java that are implemented on the JVM, for instance Python and JavaScript,
Re: (Score:3)
the JVM is simply put the fastest virtual machine currently available
That might be debatable, given the availability of LLVM JIT features, IBM i TIMI, etc.
Unsigned numbers were removed from the language because signed numbers are an extension of unsigned numbers, so there is no use case for unsigned numbers that cannot be satisfied by signed numbers as well
Yes, in theory, anything can be emulated. In practice, some kinds of programs ran like complete shit so Go people lea
Re: (Score:1)
the JVM is simply put the fastest virtual machine currently available
That might be debatable, given the availability of LLVM JIT features, IBM i TIMI, etc.
None of those are general purpose VMs though, their bytecode is an intermediate representation for producing compiled code, which of course will be faster. You are not comparing apples to apples.
Yes, in theory, anything can be emulated. In practice, some kinds of programs ran like complete shit so Go people learned their lesson from that mistake and included them in their language so that their programs of that kind *wouldn't* run like complete shit. And somehow they also managed to do that without making the language look like the other shitfest you mentioned called C.
Normally CPUs perform calculations in signed arithmetic at the same speed as they do in unsigned arithmetic. The only programs whose performance will be affected by the absence of unsigned math are those which need to load and store large amounts of unsigned integers: a very specific use case, that certainly in the
Re: (Score:2)
The only programs whose performance will be affected by the absence of unsigned math are those which need to load and store large amounts of unsigned integers:
What about needing specific sizes of data? For example, if you have a count that is
And how does having unsigned values affect simplicity and safety/lack thereof significantly?
Re: (Score:2)
Re: (Score:2)
For example: File format encoding and decoding, including compression and decompression, is a big user of unsigned integers. And before GP says "So what if bits are wasted?", consider that these "wasted bits" add up to more data cache capacity misses, more garbage collection passes, and more swap file thrashing.
Re: (Score:2)
You can perfectly well write those with signed integers, as in these cases the sign doesn't even matter as compressors just push groups of bits out. Operators like shifts and logical and/or don't care about the type of integer, and for the one case that it does matter (right shift) Java has a special operator.
In fact, most "unsigned" stuff can be done perfectly well with signed values; only comparison operators require a bit of more thought.
Just because it was written in C and then literally ported does no
Re: (Score:2)
In fact, most "unsigned" stuff can be done perfectly well with signed values; only comparison operators require a bit of more thought.
And a bit of extra CPU time to handle the abstraction inversion caused by the comparison difference. Or is the OpenJDK JVM's JIT compiler known to automatically recognize idioms to implement the unsigned comparison behavior on top of signed comparison and automatically translate those to the underlying unsigned comparison instruction for the CPU?
Also consider that Java was not intended for these kinds of low level manipulations (and is also rarely used as such in practice)
Are you trying to claim that a program "rarely" reads or writes a file in a binary format whose encoder and decoder happen not to be included in the Java SE spec? I
Re: (Score:2)
You can still store it any way you want, just promote it when reading (which happens anyway).
However, have you ever considered that a number like 255 or 65535 are only popular because of unsigned limits? There's very few real world cases where those "limits" make real sense, and when they do it's usually a lot closer to hardware than you'd be writing in Java.
Also consider that signed integers are a lot less error prone, simply because the range of numbers you are usually using is a lot safer. If you eve
Re: (Score:2)
However, have you ever considered that a number like 255 or 65535 are only popular because of unsigned limits?
Perhaps I am just tired from a long day, but I am not sure the use of "popular" is correct, so much as these are limits in storing numeric values of an unsigned nature in their respective bit widths that cannot be achieved within said widths if we are forced to deal with one bit being spent on the sign whether we want it or not.
Re: (Score:2)
Unsigned numbers were removed from the language because signed numbers are an extension of unsigned numbers, so there is no use case for unsigned numbers that cannot be satisfied by signed numbers as well
No use case? Isn't that a bold (and potentially dangerous (err... risky would probably be more correct)) assumption?
Re: (Score:1)
Re: (Score:2)
Signed integers are a superset of unsigned integers.
But ⦠I wasn't talking about if it was a superset or subset but whether the assumption about use cases is one that is valid enough to warrant the lack of unsigned integers in the language.
Re: (Score:1)
Re: (Score:2)
The first VM did not have jit compiling. .Net VM is using different opcodes for signed and unsigned math/bit manipulations.
They simply wanted an easy to implement VM, which is not to slow. They kinda ran out of opcodes, I think the byte code uses about 240 codes, already. Strictly you would not need a different set of instructions for signed or unsigned integers, so I'm not sure why they did not include unsigned ints. However the
Obviously it would not have had a big impact if they had interpreter code that
Re: (Score:3)
there is no use case for unsigned numbers that cannot be satisfied by signed numbers as well
Except fitting into the data cache.
- An array of values from 0 to 255 takes twice the memory if stored as an array of 16-bit signed integers compared to 8-bit unsigned integers.
- An array of values from 0 to 65,535 takes twice the memory if stored as an array of 32-bit signed integers compared to 16-bit unsigned integers.
- An array of values from 0 to 4,294,967,295 takes twice the memory if stored as an array of 64-bit signed integers compared to 32-bit unsigned integers.
Re: (Score:2)
Maybe I've not been paying attention to the debate over this in general, but thank you for being that SEEMINGLY rare someone who actually makes this point.
Re: (Score:2)
byte b = (byte) 0x83;
Re: (Score:2)
You can store an unsigned value in the same memory area where you can store a signed value.
If the sign matters with regards to the value being positive, that value being unsigned reduces the max number of positive values that can be stored. Doesn't matter how much of an "edge" case it may be, it still has a non-zero possibility of happening. And you mentioned before part of the reason being simplicity ⦠how the hell is keeping track of casts, and where/why they are done, easier than just having an unsigned type, at least from the perspective of the person doing the coding (or mainta
Re: (Score:1)
You can store an unsigned value in the same memory area where you can store a signed value.
If the sign matters with regards to the value being positive, that value being unsigned reduces the max number of positive values that can be stored.
Look at my example: 0x83 is larger than 127, and still it gets stored into what is interpreted by default as a signed byte. Storing an unsigned value is not a problem, it's the interpretation of the stored value that makes a difference.
Doesn't matter how much of an "edge" case it may be, it still has a non-zero possibility of happening.
Why, it's the only thing that matters! Surely a language that makes the common case harder in order to better support an uncommon edge case, isn't nice?
And you mentioned before part of the reason being simplicity ⦠how the hell is keeping track of casts, and where/why they are done, easier than just having an unsigned type, at least from the perspective of the person doing the coding (or maintaining the code)?
You don't have to "keep track" of casts: the compiler does that for you. If you don't put them, the code will not compile, a
Re: (Score:1)
Re: (Score:2)
And to read the unsigned value back from a byte[], you use b[index] & 0xFF. Likewise with short[] or int[] arrays.
But with the & 0xFF (for byte[]), & 0xFFFF (for short[]), and & 0xFFFFFFFF (for int[]) all over the place, don't those extra AND operations cause the JIT to emit a lot of extra instructions? Or is the OpenJDK JIT smart enough to apply "as if" and elide them?
Re: (Score:1)
Re: (Score:2)
Signed numbers are not an extension to unsigned numbers, how do you come to that retarded idea?
The lack of unsigned numbers makes bit fiddeling a pain in the ass in Java.
Re: (Score:1)
Re: (Score:1)
Perhaps you're thinking of NaCl? Webassembly still has to be run on an interpreter, or JITed, or AOC'd.
If you want apps make apps (Score:3)
If you want web pages make web pages. If you want apps make apps.
It sounds like this could be useful in a few situations, but mainly web analytics and ads will be chewing up the CPU and that's bad.
A lot of web sites could easily be rendered on devices with much less horsepower but we're seeing a lot of browsers get bogged down quickly with simple layouts. The culprit is all the analytics, telemetry, and ads. This will abuse your device even more.
Re: (Score:3)
Re: (Score:1)
Why are telemetry, analytics and ads a domain of just websites? That seems orthogonal to the application deployment, display methodology and executable method you've chosen (web vs native). I can write an ad-free website and an ad-ful application.
Re: (Score:2)
apps could just be used offline and wouldn't be able to send/receive data.
A Progressive Web App can run offline as well.
I'm not on Windows/Android/iOS and don't use many (or any) commercial apps
Do you ever see "Sorry! This application is not available for macOS" or "Sorry! This application is not available for desktop Linux"? I use Xubuntu as my primary PC's OS, and I have seen the latter on numerous sites, including Google Drive, OneDrive, and various game pages on Steam.
Re: (Score:2)
For games I use consoles.
Until you see something like this:
Hello darkness my old friend... (Score:3)
Re: (Score:2)
It will have to be _very_ sophisticated, because (a) WASM execution environment prevents most of the existing styles of exploit by design, and (b) the _point_ of the exercise is to sandbox even sub-modules of programs into spaces so small that they can't do any harm. Capbility-based system access, assuming they can get that to work. Similar levels of sandboxing to running apps in Docker images, but at much finer grain and much lower overhead.
Can we return to 1996 please? (Score:2)
Re: (Score:2)
Re: (Score:1)
Re: (Score:1)
And apparently you don't know that by definition a "Millennial" is between 38 and 23 depending on the year you use, so its possible half of them are over 30! I mean seriously, we've been hearing about Millennials for what, 10 years now? They've gotta be aged out of "destroying" whatever they're destroying this week. (Toast, movies, insurance, cars?)
Re: (Score:2)
> I never understood the reason for programming in the web, can't we just go back to HTML + CSS and maybe CGI?
Because people realised it was a huge pain in the ass to keep installing and updating things. Because people realised it was a huge pain in the ass to make any interaction between a website and the server hosting it synchronous.
> Why does everything need to be responsive (which only uses up half the screen and looks the same on every webpage)
That has nothing to do with responsiveness. Responsi
Re: (Score:2)
Yes, not being burdened with micro optimisations and dealing with various levels of abstraction just to squeeze as much as possible onto some shitty 386 machine with 16mb of ram is just such a relief.
They don't need to be micro optimizations (you're not coding in assembler) and have you used an first gen i5 lately? With 4GiB of ram it has trouble with the web, I don't use this machine everyday as it is old for what I do, but there is zero excuse for buying a computer every 5 minutes because the modern web and it's 128 layers of non-sense, if the web was meant for programming low level not the reverse, now we need assembly (web assembly) to fix this mess, well what happens when even web assembly isn't en
Re: (Score:2)
can't we just go back to HTML + CSS and maybe CGI?
No. Even though HTML5 expanded the capability of <input type="..."> values, there is still no way to catch a drag action without script. The <input type="image"> element [mozilla.org] sends one (x, y) for the click position, not a sequence of coordinates forming a drag path. This makes a web-based image editor or collaborative whiteboard impractical, as the end user has to click, reload, click, reload, click, reload, click along the path.
Why does everything need to be responsive (which only uses up half the screen and looks the same on every webpage)
Because clients' displays vary from 3 inches wide to 20, and a 3-inch-wi
Why the backlash against bytecode? (Score:5, Insightful)
I used to dislike the idea of sending binaries to the browser because of fear of running arbitrary code on the processor, and the concern about obfuscation. But those objections are out-of-date. The obfuscated Javascript we get is almost as bad as bytecode. And the security difference between bytecode and javascript isn't that big. We might as well gain the performance benefits at this point.
Re: (Score:2, Interesting)
Re: (Score:2)
It's a mix of fake outrage from people who don't know what they're talking about - a la Twitter - and a dose of "64k should be enough for everybody!" tier nonsense from a bunch of obsolete geezers who haven't upgraded their skills since the 80s.
I had to check to see if I was still on Slashdot because this single handedly is the most insightful thing I've ever read on this site, full stop.
LibreJS (Score:3)
The obfuscated Javascript we get is almost as bad as bytecode.
Which is why the GNU project has developed an extension to block obfuscated JavaScript in the IceCat and Firefox web browsers. A browser with the LibreJS extension [gnu.org] installed will execute any nontrivial script only if the document calling the script contains a link to source code* under a license that respects some basic rights of users [gnu.org]. By definition, minified or obfuscated code is not source code.
* GNU GPL versions 2 and 3 define a work's source code as "the preferred form of the work for making modificati
Webassembly (Score:3, Interesting)
Yes, mod parent up! (Score:2)
Parrot is a good place to look for evolutionary guidance; however, the history of problems with everything involves too much system/API access. Security revolves around managing access.
The BIG objection experienced people are making is the expansion of access to this plug-in / Java Applet replacement having learned the lessons of history. It must be severely constrained with paranoid security upfront at the expense of performance or convenience.
Frankly, I think ONLY an extremely limited bridge be allowed t
Re: (Score:2)
Re: (Score:2)
They are fundamentally different things. NPAPI runs inside the browser process and thus has the same level of access to the underlying OS as the browser itself. WebAssembly runs in the same sandbox as Javascript and only has access to Javascript APIs.
Parrot (Score:2)
They should hire Dan Sugalski, who probably knows the most about implementing register-based VM's these days, after spending time in the trenches with Parrot.
The error the consortium could make now would be not architecting a vm correctly so that some languages would be hard to port, even assuming new bytecode mnemonics. Or doing something stack-based with security worries.
Intel wants it (Score:2)
Whats the (Score:1)
Like https://xkcd.com/2044/ predicted (Score:3)
Re: (Score:2)
I'd up-vote you, but I've already commented elsewhere. This comment, and the XKCD cartoon, are exactly correct, as far as I can tell.
The tightly-constrained "nano-VM" model of module isolation has exactly the same restrictions as CSP-based parallelism, or the Actor model, compared to threads and shared data, and will very probably be about as successful. (I.e., there will be successful niches, but most code will continue to play fast-and-loose and be a security problem.)