SoylentNews is people
SoylentNews
Mozilla Extends WebAssembly Beyond the Browser with WASI:
Mozilla’s WebAssembly started as an experiment, almost a question: is it possible to run arbitrary code in a browser without breaking the browser sandbox? A side benefit would be faster web applications that would outperform current web technologies, allowing developers to bring existing desktop applications to the web.
[...]Since its initial launch, WebAssembly has been adopted by all the major browsers, with support from Mozilla, Google, Microsoft, and Apple, who’ve all contributed code.
Best thought of as a definition of a virtual machine, WebAssembly works with the browser’s JavaScript engine to run code at speeds that compare well with native code. Instead of JavaScript’s byte code approach, it takes code written in familiar languages like C and C#, and converts it first to an assembly language-like bytecode before a final compilation as binary. WebAssembly executables are compiled before being delivered to browsers, making them a compact and efficient way of adding complex functionality to web applications.
[...]Experiments with WebAssembly outside the browser are all very well, but if it’s going to be a tool that supports cross-platform as well as cross-browser development, it needs to have new standards built around it. Mozilla recently announced the start of such an effort, with the first release of WASI: the WebAssembly System Interface.
You can perhaps consider WASI as the boundary between system level code running on the host platform and applications running in user mode.
Where WebAssembly works as an implementation of a virtual processor, WASI goes a step further and offers developers an entire conceptual operating system. With a virtual processor, there’s only one target architecture, and the JavaScript engine can handle translation between its implementation and ARM, Intel, Power, or whatever hardware you have. WASI does the same, offering WebAssembly programs its own low-level implementations of common OS functions, that are then translated into OS calls via the host JavaScript engine. Target WASI in your code, and you’re able to produce applications that run identically on macOS, on Windows, on UNIX, and more, even on mobile operating systems.
[...]It’s also important to note that you won’t be writing code that accesses the WASI interfaces directly. Instead, these will be what’s implemented in the WebAssembly equivalents of the standard libraries we use in most common languages. That way we’ll know that if we’re running a C application in WebAssembly through WASI a printf command will write to a console, no matter if it’s on Windows or UNIX. WASI implements the interfaces for WebAssembly compilers and the underlying JavaScript engine handles the actual system calls to whatever OS it’s running on. You don’t need to install the appropriate standard libraries for each target OS for your code, and you only need to compile once.
[...]There are already three implementations of WASI, Mozilla’s own implementation and a polyfill that will allow anyone to experiment with WASI in a browser. Perhaps the most interesting from a developer standpoint coming from edge delivery network Fastly. Its Lucet WebAssembly compiler is now also a runtime, with an open source release on GitHub. Currently used in Terrarium, Fastly’s experimental edge service, it’s seen as a fast alternative to JavaScript running on Google’s V8 engine.
In a blog post, Pat Hickey, a senior software engineer at Fastly, describes Lucet as able to “instantiate WebAssembly modules in under 50 microseconds, with just a few kilobytes of memory overhead. By comparison, Chromium’s V8 engine takes about 5 milliseconds, and tens of megabytes of memory overhead, to instantiate JavaScript or WebAssembly programs.”
(Score: 4, Insightful) by Pino P on Tuesday April 02 2019, @08:33PM (25 children)
Some users think putting applications on the web in the first place was a mistake. To them, the web is for documents, and applications ought to be native, built with a cross-platform GUI library such as Qt, and distributed in the form of source code that a user can download, inspect, compile, and install. But how practical would this be, particularly for phone users?
(Score: 2, Insightful) by Anonymous Coward on Tuesday April 02 2019, @08:36PM (10 children)
Why is a phone different than a computer?
(Score: 2) by c0lo on Tuesday April 02 2019, @08:43PM (9 children)
Phone = consumer
Computer = maker (potentially)
You can't develop your own apps on a phone. You may not even be able to install or run on your phone apps that you developed yourself.
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 1, Offtopic) by PlasticCogLiquid on Tuesday April 02 2019, @08:45PM (7 children)
You just found the void that needs filled, go get rich.
(Score: 4, Interesting) by Unixnut on Tuesday April 02 2019, @10:33PM (5 children)
> You just found the void that needs filled, go get rich.
It is a void for a reason. Namely, it was tried before, and fell flat on its face. The Nokia N800 to N900 series phone/tablets ran a Debian derivative, and you had the full GNU toolchain on it. You could install most GNU apps (including openoffice!) on the phone, and with an X server, you could even have apps forwarded to a thin client from the phone. You had C compilers, Perl, Python, every single programming language Linux had, with all the standard libraries and APIs.
And was it popular? Hell no, it flopped massively. Nobody apart from nerds bought it, and Nokia itself is no more. Normal people just could not understand the draw of being able to run vim on your phone to code up a Perl script to send SMS messages automatically.
Android, which when it came out was lambasted by nerds for being inferior in almost every way, took over the mobile world, despite being a locked down spyware infested piece of crap, that was buggy as hell until KitKat (and is now only slightly less buggy in my experience). I can't see a future phone offering a similar OS experience to the old N900 becoming popular, most people don't want nor care about being able to hack their phone, or even so much about privacy and control. Many are happy as long as their social media, game and IM apps work.
It is like the same thing with the iPod when it first came out. It wasn't the first portable mp3 player, indeed by specs it was ranked pretty poorly compared to the competition, yet decades later, most of the masses have never even heard of "iriver", but they all have heard of "ipod".
(Score: 1, Interesting) by Anonymous Coward on Wednesday April 03 2019, @05:03AM (1 child)
and now users can't disable google services it is perpetual spyware
or uninstall apps like bixby
or properly firewall apps so they can't connect to the internet
yes, android is privacy destroying crap in this aspect
what to replace it with though?
(Score: 2) by urza9814 on Wednesday April 03 2019, @03:17PM
I currently have an Android device and have no problem doing any of those things. Just install a better distro -- LineageOS is my personal preference. But this is likely why Google is trying to kill Android now with this Fuscia crap.
Or you could buy a Librem 5 if those ever become available. I'm hoping to, but the constantly shifting release dates makes it a bit difficult to commit....it'll never be more than a niche product, but maybe it could at least be a *healthy* niche...
(Score: 4, Informative) by coolgopher on Wednesday April 03 2019, @06:10AM
Then N900 was my most feature-rich phone. That is, rich with features *I* wanted, not the ad-pushers.
(Score: 2, Funny) by Anonymous Coward on Wednesday April 03 2019, @07:57AM
You can just emulate an N900 on your phone using JavaScript.
(Score: 2, Informative) by Anonymous Coward on Wednesday April 03 2019, @05:55PM
uhh, it was purposely torpedoed by stephen elop who was sent in to nokia by microsoft for that express purpose. i think you know that with that nickname...
(Score: 2) by Bot on Thursday April 04 2019, @12:29PM
The first smartphones, the nokias, were EXACTLY like that, linux on a phone. Dream came true, yet I NEVER saw one on sale. When the price dropped a bit I would have bought it without blinking.
Fact, putting a fully programmable radio on a pocketable pc would have enable too many nifty things nobody really wanted. Not the carriers, not the hardware producers, not the police, not the guys in charge.
So they toyfied the concept and promoted the heck out of it at the expense of PCs.
Account abandoned.
(Score: 2) by DannyB on Wednesday April 03 2019, @05:50PM
Have you tried Android? You don't need anyone's (eg Apple) permission to download and use the development tools. You can install your own app onto your own phone through ADB. On your phone, you have to enable this and are clearly warned that you are installing an untrusted app that is not from the play store. But it will install and run just fine.
With Apple, you have to bow down to them to get their tools, just out of spite they make you buy a Mac to develop on, and then you have to pay and bow down in order to even put your app onto your phone -- at Apple's pleasure. All this before you even try to submit your app to the iTunes store and hope and pray for acceptance.
The lower I set my standards the more accomplishments I have.
(Score: 3, Insightful) by Anonymous Coward on Tuesday April 02 2019, @08:49PM (6 children)
From a user perspective, web apps are safer. Installing software entails risk. From a developer perspective, you don't have to worry that new OS versions will kill your app. Are you going to use Qt to target Windows, Mac, Linux, iOS, Android, Windows Phone? And then deal with all the app stores? Easier to just make a web app.
(Score: 2, Insightful) by Anonymous Coward on Tuesday April 02 2019, @08:58PM (2 children)
"you don't have to worry that new OS versions will kill your app"
no, you'll have to worry that the world will change and the browser of the day will croak at the code you're pushing down
the throat of its now incompatible VM
(Score: 2, Touché) by Anonymous Coward on Wednesday April 03 2019, @12:34AM
You say that as if browser incompatibility isn't a problem NOW.
Uh, have you tried running it in Chrome? Works for me!!
(Score: 3, Funny) by DannyB on Wednesday April 03 2019, @05:52PM
Browser compatibility and standardization has pretty much stabilized.
The lower I set my standards the more accomplishments I have.
(Score: 2) by DrkShadow on Wednesday April 03 2019, @02:06AM
You forgot the letters b, r, w, e, and r.
https://kotaku.com/google-updates-chrome-breaks-tons-of-web-games-1825899640 [kotaku.com]
(Score: 0) by Anonymous Coward on Wednesday April 03 2019, @04:52AM
This might perceptually be so but it's the running of random software that poses the risk, no difference whether it's native or "web app" (= be it either JS or WA)
(Score: 2) by maxwell demon on Wednesday April 03 2019, @06:57AM
Well, they superficially seem safer. But the illusion of security is worse than insecurity you know about.
When all your stuff is online, web apps are no more safe than local apps are when all your stuff is local.
On the other hand, the ability of the web to have apps makes the web as a whole insecure. When the web was just a document delivery system, it was very secure. Not absolutely, as there's no such thing as absolute security. But the security risks were negligible. Today, even web pages that apparently just deliver documents may pose a security risk.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by DannyB on Wednesday April 03 2019, @03:00PM (6 children)
I develop a web application.
How I think it should work.
You SHOULD be able to inspect the JavaScript code in your browser, if you want to. All that code should be doing is merely creating the local user interface experience.
Information is then sent to the server which does the actual business.
The JavaScript, HTML, and CSS are your user interface toolkit. No Applets, ActiveX, Flash or Silverlight.
Many security problems with only the JavaScript model have been fixed. But the mistake, IMO was allowing this to be ANYTHING other than merely a way to offer improved user interface.
The lower I set my standards the more accomplishments I have.
(Score: 2) by Pino P on Wednesday April 03 2019, @04:23PM (1 child)
Except nowadays, users expect web applications to work even while a device is temporarily disconnected from the Internet, such as while a tablet or laptop is between one open hotspot and the next. Progressive Web Applications do more of the application logic client-side, synchronizing with the server for authoritative validation when available. For example, a webmail client would download new messages for the user to read and reply offline and send once online again. It attempts to replicate the overall experience that would otherwise require an OS-specific native application that the device's owner must approve to install before the user can use it.
(Score: 2) by DannyB on Wednesday April 03 2019, @04:58PM
Okay. And interesting. For an application that is used on the go, like webmail as you say. Office accounting applications would develop progressive web apps based on market demand.
Progressive web apps doesn't mean that the browser side technology needs to have any capabilities other than to create the offline experience, which means the browser provides a database API. That still doesn't mean the web app tech needs to have any way to escape from the box. Not for a legitimate application.
The lower I set my standards the more accomplishments I have.
(Score: 0) by Anonymous Coward on Wednesday April 03 2019, @05:58PM (3 children)
this is what i do. no ajax.
(Score: 2) by DannyB on Wednesday April 03 2019, @08:45PM (2 children)
No JavaScript also? Or just no ajax?
Without ajax you can still use JS to have a significantly better interactive experience. Tabbed panels. Sections that can show and hide. (Yes, I know that today some of this can be pure CSS.) Enabling / Disabling some controls or panels based on the state of other controls. Popup dialogs in browser (done with pure html / css / js).
With ajax: grids that can page through groups of rows without refreshing the entire page.
Autocomplete fields. As you begin typing into a certain field, it can suggest autocomplete possibilities much like Google does.
The lower I set my standards the more accomplishments I have.
(Score: 2) by Pino P on Thursday April 04 2019, @03:23PM (1 child)
What we can do in pure CSS and HTML5 forms we do in pure CSS and HTML5 forms. What we cannot we do our best to design out of the design.
If users want "Popup dialogs in browser", then why do web browsers have a pop-up blocker?
From a JavaScript abstainer's point of view, having to refresh the entire page in order to make any view changes that pure CSS alone cannot make is an acceptable tradeoff for the abuses that adtech has made of JavaScript in the past and looks to make of WebAssembly in the near future. Instead, we engineer to make "refreshing the entire page" painless by caching subresources.
(Score: 2) by DannyB on Thursday April 04 2019, @04:12PM
When speaking as a commercial web developer:
Adtech is irrelevant. We don't run ads in our commercial product.
JS malware is irrelevant. We don't run any malware in our end users' browser. It's strictly business. They are paying for our product to do something faster, easier, more efficiently, and cheaper than they could do it any other way. That is what comes above all else, including abstaining from JS.
Popup blockers are irrelevant. We don't open popup windows. When I said pop up dialogs, I mean it looks like a popup dialog, but is purely markup within the page. The dialog or window may be movable and resizable, but it is pure HTML, CSS and JS within the page. No popup window was used. No native browser dialogs were used.
Sometimes modal dialogs make sense in a UI to bring up an error message, or momentarily expand upon something the user wants to see. Or to fill in some details about something that the dialog then collapses back down into.
Are you a JavaScript abstainer as a commercial web application developer? I would think those are almost mutually exclusive these days.
The lower I set my standards the more accomplishments I have.