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 Anonymous Coward on Tuesday April 02 2019, @08:30PM (17 children)
No, it needs to have a wooden stake driven DEEPLY into it's heart.
"Javascript" should never have been allowed to exist.
(Score: 2) by bob_super on Tuesday April 02 2019, @08:42PM (2 children)
javascript is how we broke out of HTML restrictions and opened up the door to such wonderful experiences as Facebook, Twitter, disqus, 4chan, Gab ...
I'm low on wooden stakes, how about nuking from orbit with a side of spreading Ebola ?
(Score: 0) by Anonymous Coward on Wednesday April 03 2019, @12:38AM
The web is great if cheap borked content is not a show-stopper. But for business GUI's meant for real work, it's a buggy time-drain.
(Score: 2) by DannyB on Wednesday April 03 2019, @02:42PM
Please not to forget the final T in disqust.
The lower I set my standards the more accomplishments I have.
(Score: 4, Insightful) by Anonymous Coward on Tuesday April 02 2019, @08:44PM (5 children)
It's not just Javascript. This jumped out at me:
How many times do we need to make this same mistake? Yeah, sure, this time the VM will be secure. That's what they said for:
- ActiveX (well, sorta, this wasn't VM iirc so it's the worst offender on this list)
- Java (Sun then Oracle applets and web start, not JS)
- Flash
- Silverlight
It's a shame that the CxOs at Netscape didn't allow Eich (let's elide the political stupidity--this is a tech discussion) to deliver his Scala-like vision for web scripting. Instead what we got was an abomination of a language that isn't OO, isn't functional (functional as in Haskell or Scala), is sorta kinda procedural but not really, is really just a steaming pile of dung that's somehow Turing-complete in an academic sense.
(Score: 1, Insightful) by Anonymous Coward on Tuesday April 02 2019, @08:48PM
Steaming pile of dung that's somehow Turing-complete in an academic sense.
If only academics were less concerned about Turing, and better at sensing dung!
(Score: 4, Insightful) by arslan on Tuesday April 02 2019, @09:50PM (1 child)
Unfortunately, this thing takes it a step further, it allows you to develop in different languages making it even more accessible to create bad code to be pushed to browsers.
(Score: 2, Funny) by Anonymous Coward on Tuesday April 02 2019, @11:54PM
Right now it's only Rust and C/C++. Hopefully they'll add support for more languages in the near future. I can't wait for it to support JavaScript so I can node.js it like a boss.
(Score: 2) by DannyB on Wednesday April 03 2019, @02:56PM
The real flaw here was NOT having a good, cross compatible JavaScript with the ability to draw good snappy interfaces and graphics. Something that modern browsers have fixed. If browsers had this from the start, there would not have been any (real or perceived) need for ActiveX, Java, Flash or Silverlight.
ActiveX -- everyone said this was flawed from the beginning. It allowed executing native code on a Windows machine. The server would deliver a native code blob to the browser and ActiveX would execute it. Oh, but it is digitally signed! -- protested Microsoft. So nobody would use it for malware -- because you can see who signed it. Of course that doesn't mean anything when anybody can get a code signing certificate and the malware signers are simply a drop in the ocean. If depending on code signing is your security model then you're
doing it wrongMicrosoft. But this is the company that created the nightmare of executable emails -- without even reading them first.Java Applets -- seemed good: sandboxed, or required code signing (see previous) to escape sandbox. Because it could interact with JavaScript, the malware could be hidden in JavaScript which merely used a Java Applet to do native operations (read / save files, etc).
Flash -- if all it were allowed to do was draw fancy accelerated graphics and create UIs for the user it would have been, just OK. (Because many browsers on some OSes didn't have Flash making Flash sites only work on the mostly Windows part of the web).
Silverlight -- Microsoft's attempt to take over Flash and make it Windows only. When it was introduced, it was clearly already too late. Clear to some at least, including me.
The lower I set my standards the more accomplishments I have.
(Score: 2) by Bot on Thursday April 04 2019, @12:20PM
I agree, this is a binary software package infrastructure, so it should behave like one, explicit execution and digitally signed. What will happen instead is, "you download minified js already, stfu and exec this too).
OTOH if they ported something like picolisp to webassembly so it could run with DOM access and js interoperability it would be fun.
Account abandoned.
(Score: 2, Insightful) by Anonymous Coward on Tuesday April 02 2019, @09:54PM (6 children)
Amen Cubed! We need a GUI-friendly web standard. Trying to get HTML/CSS/DOM/JS to act like a normal desktop has repeatedly failed. New browser versions come out and the JS libraries flub up. The more desktop-like one makes it, the bigger the libraries, meaning more bugs and version dependencies.
They had 2.5 decades to get it right and failed failed failed. GivvitupAlready. I'm sick and tired of diddling with web sh&t to get common familiar and true-and-tried GUI idioms that have been around longer than my kids. Yuuuge waste of time and money.
(Score: 0) by Anonymous Coward on Wednesday April 03 2019, @05:58AM (3 children)
Not to discuss any point but out of curiosity: why did You write 2.5 decades, when "25 years" is shorter, more understandable, conveys the same information and does not require a decimal?
(Score: 0) by Anonymous Coward on Wednesday April 03 2019, @07:36AM
He did because as everyone knows a float is so much more efficient than integers!
(Score: 0) by Anonymous Coward on Wednesday April 03 2019, @07:56AM (1 child)
Because greybeards who rant against JavaScript are mentally unstable.
(Score: 0) by Anonymous Coward on Thursday April 04 2019, @12:33PM
Are you implying the rest of the human race is mentally stable?
(Score: 2, Insightful) by pTamok on Wednesday April 03 2019, @07:15AM
We need a GUI-friendly web standard.
If only there were some existing standard that could be built upon or re-engineered that gives a standard transport mechanism for GUI elements across a network.
(Score: 2) by DannyB on Wednesday April 03 2019, @05:54PM
Web apps are not desktop apps. They don't exactly the same UI.
But millions of workers use thousands of commercial web apps every single day.
The lower I set my standards the more accomplishments I have.
(Score: 0) by Anonymous Coward on Wednesday April 03 2019, @12:44PM
And "web apps" should die, they should be called "websites". The more complex it is, the more it ties you to a subscription or vendor lock-in when no one else or nothing else supports it.
who cares if the code runs; i want to know if it will demand payment.
(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.
(Score: 2, Insightful) by Anonymous Coward on Tuesday April 02 2019, @08:38PM
Not particularly about the project. To that I'm just indifferent. I'm thinking about the naming. It should have been called WasABI.
(Score: 5, Insightful) by SomeGuy on Tuesday April 02 2019, @08:42PM (13 children)
Are we still beating this dead horse? It has been shown over and over and over again that desktop applications stuffed in to a freaking web browser are SHIT. Faster? Great, the UI will still be wonky half-assed shit, it will conk out at every little network hiccup, and it brings back that old mainframe time-shared badness.
Oh, but vendors love this shit because instead of making a single software purchase, now they can keep you on a subscription for your entire life.
(Score: 0) by Anonymous Coward on Tuesday April 02 2019, @08:53PM (1 child)
It is amusing that this is what will drive the adoption of open hardware / software. "Suckers, I OWN my phone!"
(Score: 0) by Anonymous Coward on Wednesday April 03 2019, @05:09AM
do you have root access to your phone?
if they answer is no then you do not own your phone.
you may have paid for the hardware and you might be a user of your phone but it belongs to whomever controls the OS
(Score: 5, Interesting) by arslan on Tuesday April 02 2019, @10:07PM (3 children)
Us geeks may agree, and there's lots of technical reasons for it. Unfortunately, the masses disagree and the proof is in the pudding. Desktop apps provide a much poorer experience than web apps.
Here's some of the stuff that desktop apps suffers from from a UX perspective:
There's probably a bunch of other factors.
Now I see lots of whinging about why we need to move apps back to desktop but yet no actual desktop apps that addresses the UX factors that causes the web apps to take off..
(Score: 2) by deimtee on Wednesday April 03 2019, @03:14AM
This is the important one. I don't have any devices/apps that do this unless I sync them myself because I don't like the privacy implications, but I can see how useful it is to people I know who do have them. Ongoing messaging that follows from laptop to desktop to phone and back again. Reading/playing anything on any device and it automatically picks up where you left off, no matter which device you use. Look up somewhere on the desktop and the map and route is automagically on your phone.
Yeah, that level of integration would be sweet. Shame you can't do it without dropping your pants for google/facebook/microsoft/apple.
If you cough while drinking cheap red wine it really cleans out your sinuses.
(Score: 0) by Anonymous Coward on Wednesday April 03 2019, @05:16AM
you make some good points
I look forward to the day when all Ubuntu apps are 'snap' packages
perhaps the year of the linux desktop is not as far off as we thought
(Score: 0) by Anonymous Coward on Wednesday April 03 2019, @06:12PM
jami [jami.net] addresses some of this stuff, in a way, at least. you create your app account and it is published to the etherium blockchain. you can hop from one device to another using your same account. you can find other users via opendht and the eth blockchain. it's not released as a flatpak or appimage (even more windowzy and simpler) yet, i don't think. For distros with a binary package for it it's super simple.
(Score: 1, Informative) by Anonymous Coward on Wednesday April 03 2019, @05:06AM
or get turned back into shit
look at gmail
it was awesome as a replacement for pop or imap email fricking awesome
then after a few years google decided to screw with the interface making it crap
what can you do
(Score: 2) by DannyB on Wednesday April 03 2019, @05:25PM (5 children)
The application I develop was available in two modes. Hosted in the cloud. Available to be installed on the customer equipment. (let me stroke myself for a moment about that capability. It was an accomplishment. A single SETUP.EXE. Next, I Agree, Next, Next, (pause), Finish. Server is up and running with no reboot. Connect to web based control panel and configure database connection. App is then running. Ah . . . I feel better now.)
Surprise: market demand. Despite that it costs more to have it hosted by us, where we take care of backups and all upgrades are automatic -- customers overwhelmingly voted for that with their wallets and budgets.
Let me tell you a few advantages of a Web Application. Even if you host it in house within your own organization on your own servers. (Which as I mention in previous paragraph doesn't seem the popular option. Except when IT is wanting to extend its fiefdom.)
1. Web apps are Zero Install.
This is a big thing. Back in the 80's and 90's, and early 2000s, our apps were desktop applications. You run a SETUP.EXE on every workstation. When there is a software upgrade, IT generally has to go run the SETUP.EXE on every workstation -- despite that it is designed to be so simple that the end user ought to be able to do it. They don't. Or won't. Or maybe just can't.
Or by the 2000s, more sophisticated customers might manage this centrally by grope policy.
2. Web apps are Zero Maintenance.
With a web app, you may never have to visit workstations, or use grope policy to distribute software upgrades. But, software updates still happen. Maybe state or federal mandated changes. New features. Etc.
If you are hosting it in the clone, you don't even deal with maintenance. You come in Monday morning, and the previously announced new version is just there as promised. As easy as an upgrade to Gmail. You do nothing. It just happens.
Obviously customers have made it clear that the costs of Software As A Service are worth it -- at least to them. It's always there. It always works. Help is a phone call away with knowledgeable staff in the US. Our support is well regarded in our particular business, and we use NPS scores. Support is part of the appeal of or products.
3. You don't have problems with the Technology
In the olden days, when apps were desktop apps, many support calls were not about the application (how do I set up this particular payroll situation?) but about the technology: Jane Can't Print!
Support people have to deal, to some degree, with the customer's IT, and whatever equipment they use. Etc.
With a web based app, printed pages materialize as a downloaded PDF as soon as you click the Start Report button. Even printed forms, like tax forms, checks, etc. And the text ALWAYS hits the boxes on the printed paper form -- EVERY TIME -- no matter what kind of printer the end user is using. Which is great for me the developer.
4. Platform and OS are not an issue
Back in the day, our system was on Mac Classic and Windows. Needless to say, being the only one on Mac made us king of the hill there, in the 80's and early 90's. But by the mid 90s we were Windows only.
It was always my ambition to not be beholden to Microsoft. Web apps just need a browser. I don't ware what OS the end user has. Even an iPad will do.
In summary
Commercial web applications are going to the web for a reason. Not only do the vendors and developers love it, the customers do as well. No customers want to go back to desktop apps. Everything just works. It is a reality.
Web apps are here to stay.
We finally have the non-monopolist controlled application execution platform and it is the web browser. Now I only hope Google doesn't end up monopolizing it.
The lower I set my standards the more accomplishments I have.
(Score: 1, Interesting) by Anonymous Coward on Wednesday April 03 2019, @06:20PM (3 children)
Sure, except the masters control the registrar, dns system and can exert pressure on the centralized datacenters. I'm rethinking desktop apps because of these factors. I want enemy/parasite proof applications. Decentralized, anonymizing, etc. This wasi might be the way forward.
(Score: 2) by DannyB on Wednesday April 03 2019, @08:50PM (2 children)
There may be applications where what you describe is important.
I don't see most commercial applications that way.
One vendor is happy to take our money for domain names. Another vendor is happy to take our money for TLS certificates.
As for enemies / parasites, there are things you do. Progressively limit failed login attempts. Especially if from an IP range not normally used by that user. Keep your attack surface area small as possible.
The lower I set my standards the more accomplishments I have.
(Score: 2) by Pino P on Thursday April 04 2019, @03:46PM (1 child)
I think AC's point is that external actors, be they state actors or competitors, will pressure that vendor to stop taking your money.
(Score: 2) by DannyB on Thursday April 04 2019, @04:18PM
I see your point there. If we could be independent of IP addresses and domain names, we would.
Heaven knows I made a big effort to be completely Microsoft free in my particular product.
As for competitors playing that way: two can play that game. Or there may be other legal remedies, tortious interference with business, etc. That is not my direct concern. The technical matters are.
I don't see any reason we would be of interest to state actors.
Someone pressuring a vendor to stop taking our money would have to be able to effectively pressure ALL of them. There are competitors.
At this point, this speculation seems to be getting really off into the weeds.
The lower I set my standards the more accomplishments I have.
(Score: 0) by Anonymous Coward on Sunday April 07 2019, @04:57AM
1: People seem to have gotten used to "apps" and "app stores". These usually update automatically.
2: Yea, zero maintenance until some dickhead web developer forces you to change to a different browser, throw out your entire machine, or breaks functionality with no way to keep running the "old" versions that worked.
3: The last time I checked, Adobe Acrobat Reader was still a desktop application and printers still required drivers. Most web applications don't even allow for printing (print a script-infested HTML page and get garbage).
4: As long as the OS is Windows 7/10, the latest MacOS, or the latest Linux and all of the latest malware/misfeature updates. Apparently nothing else exists. Ok, congrats on at least not being Windows only.
In summary, there is a lot of stuff desktop applications can do that that a web application can not. Web stuff has its use, but some things will always need a desktop application, at least if you want to do it the non-insane way.
(Score: 4, Funny) by c0lo on Tuesday April 02 2019, @08:54PM (2 children)
Yay! Now I can run Firefox in Chrome.
Or even emacs in Chrome in Firefox in an AOL browser!!
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 2) by sgleysti on Wednesday April 03 2019, @03:58AM
emacs is a good operating system, but it could use a better text editor.
The AOL browser probably isn't compatible with this stuff, but you will probably be able to run emacs in Chrome in Firefox in Edge.
(Score: 0) by Anonymous Coward on Wednesday April 03 2019, @05:11AM
so recursive
Firefox is Chrome now, pretty much
the only major difference is that in Firefox you can disable the trimming of the protocol in the urlbar so you can actually tell that you are looking at a http:// site
(Score: 2) by Farkus888 on Tuesday April 02 2019, @09:05PM (1 child)
I applaud the author for managing to avoid using the infamous phrase "arbitrary code". I suspect this may be the last time we hear about this technology without it being used though.
(Score: 0) by Anonymous Coward on Wednesday April 03 2019, @04:56AM
But that is exactly what this will be used for, just like JavaScript. DRIVE-BY MALWARE
(Score: 0) by Anonymous Coward on Tuesday April 02 2019, @09:42PM
Is it not to late to fire warheads?
(Score: 0) by Anonymous Coward on Wednesday April 03 2019, @12:17AM (4 children)
In the context of webapps, until they reach the point where you can write WASM+HTML instead of JS+HTML and have DOM APIs docs that give examples in wasm rather than ecmascript, C/C++ devs won't use it. And in the meantime to-javascript compilers and docs are getting better and more standalone.
As for web sites, we don't need to replace javascript here. We need to remove it.
(Score: 1, Informative) by Anonymous Coward on Wednesday April 03 2019, @12:31AM (3 children)
"Pure" document delivery HTML websites haven't been a "thing" for at least 15 years.
It's never coming back. I hope you can accept those things that you cannot change.
(Score: 0) by Anonymous Coward on Wednesday April 03 2019, @12:37PM (2 children)
This very site is an example that people CAN get fed up with the crap AND do something about it.
(Score: 0) by Anonymous Coward on Wednesday April 03 2019, @04:52PM
Hey, triggered Soylentil, I can accept that it will not change without liking that fact.
(Score: 2) by DannyB on Wednesday April 03 2019, @05:37PM
This site is an example that certain kinds of web sites CAN avoid using JavaScript. And I applaud the effort and its obvious success.
Free Clue: real commercial web applications that have HUNDREDS of forms that users interact with and also produce hundreds of reports with all kinds of filters and controls, are not going to develop without JavaScript or other rich interactive frameworks on the browser. It is a simple necessity. All kinds of interactive operations need to happen instantly without page refreshes.
You already see these kinds of applications. Go to the doctor? Get a look at the application they use. Go to a lab to get your blood drawn? Go to the public library, look at the applications they use. Go to get your oil changed, etc, etc.
It is a fact of life. It is the 21st century.
What we need is to have a confined, sandboxed, secure way to execute interactive web apps on the browser.
The lower I set my standards the more accomplishments I have.
(Score: 2, Insightful) by Anonymous Coward on Wednesday April 03 2019, @12:28AM (2 children)
Web apps are just an attempt at reinventing an OS and GUI over a foundation that is 100% NOT designed for that.
I mean, we've got compilers now that spit out JS, the equivalent of linkers with node, "tree shaking" to not link in unused code, etc. etc.
Just admit that what we use now is holding us back with no vision of it EVER being "good." Use something that was designed to be proper code from the start!
Web dev is 10 times harder than it has to be.
(Score: 2) by Pino P on Wednesday April 03 2019, @04:26PM
Correct: the foundation is instead currently designed to lock users into buying Windows™ products or buying Mac™ products.
Which raises the question of how to make "proper code" that can be used on all major operating systems, both free ones and popular ones, without requiring the user to have to take a step of permanent installation.
(Score: 2) by DannyB on Wednesday April 03 2019, @05:42PM
The dream of Web Applications begin in the 90's. While Netscape was still around.
Even stupid Microsoft (finally) realized the danger. Web applications threaten their desktop monopoly! So along came IE. And it attempted to "microsoftize" the internet. Along with IIS and FrontPage.
Thank goodness it failed and we have have web standards.
But it was a slow long road to get here. By the year 2000 I was looking for a way we could rebuild our desktop apps into web apps. There was just nothing up to the task -- and IE deliberately tried to make it impossible to do without having to do it the IE way and the Other Browser way.
The lower I set my standards the more accomplishments I have.
(Score: 4, Interesting) by crafoo on Wednesday April 03 2019, @01:44AM (3 children)
So I read that right? It's a full blown OS, running in the browser, running byte-interpreted code? So now I have two sources of potential OS incompatibilities and versioning to worry about to run "web applications". So why not just run a native application built using a consistent and tested cross-plotform framework like Qt? I mean, Qt has networking built in, and webkit as well in case you just really need to open a web page inside your application. Which, you know, makes more sense to me than the other way around everyone seems to have a hard-on for.
(Score: 1, Funny) by Anonymous Coward on Wednesday April 03 2019, @06:50AM (2 children)
it's a brand new way to hack your computer now across multiple devices!
are you not EXCITED!
(Score: 3, Insightful) by DannyB on Wednesday April 03 2019, @05:43PM (1 child)
Java provided a platform neutral way to hack your computer without the necessity of a web browser!
The lower I set my standards the more accomplishments I have.
(Score: 0) by Anonymous Coward on Thursday April 04 2019, @11:11AM
yes yes but java failed in its core promise of Write Once Backdoor Everywhere
(Score: 2, Insightful) by Anonymous Coward on Wednesday April 03 2019, @04:30AM (1 child)
A major reason web apps became popular is because they solved the software installation issue.
The software installation issue was vexing because before, you had to deal with:
1. Different APIs/OSes to target (platforms you write your code to run on)
2. How to handle updates to already installed code
3. Having the required authorization as a user to install code
Web apps also provide sandboxing of the app so it can't do too much damage if it fails or is malicious.
Web apps solve the storage issue by storing all your data on another server.
The rest of the web experience is pure shit, but the factors I listed above are so compelling that we put up with it.
(Score: 2) by DannyB on Wednesday April 03 2019, @05:44PM
Yes. That.
I elaborate on some of that in a post up above yours.
The lower I set my standards the more accomplishments I have.
(Score: 2) by shortscreen on Wednesday April 03 2019, @06:55AM (1 child)
Can you run arbitrary code in a sandbox? Arbitrary code means potentially malicious code. You might as well assume it's malicious, especially if it came from the internet. Side channel attacks have shown that just because you have a sandbox doesn't necessarily mean that running malicious code inside it is a great idea. And if that sandbox happens to be a web browser, it becomes a much worse idea. Even if the browser sandbox isn't full of gaping holes, the user simply doesn't want malicious code running in their browser.
You can stop abusing the word "assembly." Assembly language has nothing to do with webcrap or bytecode.
Competition has nearly been eliminated in the browser space, since the cost of keeping up with the horrendous "standards" that change every week is too high. Building for an OS that runs on top of a browser isn't going to increase the size of anyone's potential market because the same thing would happen. The number of current implementations would dwindle until only few platforms are supported, and you might as well have built for that underlying platform in the first place.
(Score: 0) by Anonymous Coward on Wednesday April 03 2019, @07:47AM
Spectre has shown that just because you have a processor doesn't necessarily mean that running malicious code on it is a great idea.
(Score: 0) by Anonymous Coward on Wednesday April 03 2019, @09:28AM
Obviously it is time to have a separate computer for important data, never connected to a network, and a separate one for running web-shit anonymously.