I never expected WebAssembly to be as fast as native only to be significantly faster than JavaScript.
Considering the popularity of Electron, if WebAssembly does get as fast as native or at least 80% there (and that's a really big if) it would easily become the cross platform language for the vast majority of desktop applications.
For mobile we will always be dragged down by Apple and its reticence to embrace web technologies. It's 2019 and we can't even show a add to home screen native banner.
What's the point of using this for native applications ?
I mean yeah, it might be a little easier to distribute but it's kind of absurd to agree to throw away 20% performance for a bit of convenience and then sched tears on how the latest intel chips only delivered 5% improvement over the previous ones.
It’s not “a bit of convenience” when you are the business owner having to write multiple cheques instead of one, because each platform enforces its own incompatible technologies.
Plus there is another big argument. Some app written in wasm is not just compatible with today’s platforms (iOS, Android, MacOS, Windows, etc), but also with tomorrow’s platforms. The lack of apps is probably what killed windows mobile and resulted in the current duopoly. If all apps become compatible with any platform as long as they implement a standard, then there is a chance for a challenger to break the duopoly.
Hrmn. Isn't this cross-platform argument the same thing we heard for using Java instead of C (write once run anywhere) or, for that matter, using C instead of assembly (portable assembly language)?
Don't get me wrong, this is all to the good. But does WASM have some special way to prevent the various platforms from implementing their own unique, special, and (of course) incompatible APIs?
It caught on plenty for that purpose. See also: Minecraft and Android.
It probably would've caught on more/sooner on the desktop if it had adopted a native-look-and-feel GUI toolkit earlier rather than later. Hopefully a WASM reincarnation of Java's cross-platform goals will prioritize that sort of look-and-feel integration.
Android certainly satisfies the user-facing requirement, but not the cross-platform.
Specifically, if all we knew about user-facing Java was that most Android app are written in Java (or something that differs from Java only enough to try to avoid infringing the intellectual property rights of Java's owner) then we would expect many cross-platform user-facing apps to be written in Java.
But we have no need for such indirect evidence because we can directly count the cross-platform user-facing apps that are written in Java. You mentioned one, Minecraft, and I will add Eclipse, IntelliJ and its derivatives and Jin (a "client" used to connect to the Free Internet Chess Server and Internet Chess Club). Since I know how hundreds of user-facing cross-platform apps are implemented, and since four out of hundreds is not much, I stick to my claim that Java never caught on for writing cross-platform user-facing code.
"Android certainly satisfies the user-facing requirement, but not the cross-platform."
Depends on how you define "platform". Android apps certainly run on multiple architectures (mostly ARM, but also x86 and MIPS). They also run on non-Android operating systems (namely: ChromeOS; theoretically-speaking, other operating systems could run Android apps, too, so long as Dalvik runs on those operating systems, though unfortunately this is not the case for most operating systems).
And sure, we can provably claim that Java didn't "catch on" compared to the sheer volume of user-facing programs written in C or C++, but by that logic macOS didn't "catch on" compared to the sheer volume of user-facing computers running Windows (which might indeed be true depending on how you define "catch on").
There might be some differences in API. But if your base runtime + UI (html5) + basic apis (http, storage, location, etc) are the same, you are left having to deal with edge cases about platform specific features. That's not really different from the browser compatibility problems web developers consistently run into now.
So from an absolute purist point of view, yes, but practically it will be as cross-platform as it gets.
> you are left having to deal with edge cases about platform specific features
Which is always the case. The more you abstract the less you control, the more you need to control the less you can abstract. We've played this game before with Java.
In my opinion it is not the performance of JavaScript or WebAssembly that is the real problem, it has not been for the past few years, it is the performance of the entire web stack (e.g. electron) that is the problem.
Combining all of the technologies in the web stack has performance hit far higher than 20%.
One of things I find myself having to teach people over and over again about performance:
It's like personal finance. At the end of the day you are not going to 'balance the checkbook' by identifying the 2 places where you are misbehaving the worst. You have to get every aspect of your spending below a % of your overall budget or you will always be in debt. Starting with the big things can be very motivational but it's not a strategy that works (or rather, it works by accident).
The relevant part for this discussion is that if you fix the slowest thing, (interpreting code) then the effects of all of the other sources of slowness are magnified. Everything else gets 'slower' by comparison (if you fix the thing that takes 50% of the time, then all of the things that used to take single digit percentages jump to double digits). You'll eventually get near your goal that way but the entire process is a game of whack-a-mole, and nobody will ever support you going back for the last 2% in some section of the code, leading to death by a thousand cuts (and honestly, I've watched a lot of people interpret performance reports and most of us can't even spot problems that small.)
20% performance or, as I like to say, 20% battery life.
Anyways, there are good uses for WASM even outside browser. Plugins and when you have multiple architectures you need to deal with.
Sandboxing and deterministic memory consumption is a great fit in certain applications. I'd like to use WASM on relatively small embedded devices (even as small as 64 - 256 kB RAM), to provide extendibility, for example.
By the same token, writing native apps in anything other than C++ is a waste of performance, sometimes much more significantly so... but we still do it.
Performance just doesn't matter all that much in so many cases.
>What's the point of using this for native applications ?
The point is that javascript isn't actually a bytecode (javascript as the "bytecode for the web" is just a metphor and a necessary evil,) and compiling to javascript isn't as efficient as compiling to bytecode. Also, that webassembly provides an open (non-proprietary) general purpose compile target for multiple languages, as opposed to Flash or Java, which are proprietary and meant to target only a single language. Also, to allow for seamless transitions between applications on the web and off the web, allowing the web to serve as a primary channel for the distribution of native software.
you don't have to deal with the distribution issues related to the app store, you can easily roll out changes quickly, you can create "shareable applications" (URLs!) quite easily.
You can also build hybrid apps, where you can take advantage of web tech for certain presentational stuff and still go fast for stuff in the backend
The biggest advantage is the same as using Javascript with Electron: being able to use web technologies on the desktop for easy cross-platform GUI applications. WebAssembly addresses two big downsides of that approach: speed, and having to program in Javascript.
Apple is willing to "work on" any technology that might affect them, but you can't read a lot into their participation, and it certainly doesn't imply and intent to adopt. Also, Apple is an extremely siloed company in terms of goals, technology, standards, etc. Don't expect the Safari team and the iPhone team to share a common vision.
>Considering the popularity of Electron, if WebAssembly does get as fast as native or at least 80% there (and that's a really big if) it would easily become the cross platform language for the vast majority of desktop applications.
Still won't be a panacea for the Chromium runtime.
>Still won't be a panacea for the Chromium runtime.
It will if native WebAssembly applications don't ship in Electron.
It's probably inevitable that all WebAssembly applications will ship in Electron until the heat death of the universe, simply due to network effects and inertia, but that doesn't actually have to be the case. It being called "WebAssembly" doesn't mean it has to run in a browser.
Whats the advantage of WA being used for cross platform development if it is not used along with the web stack? It would have a clear advantage if say the main difficulty with writing cross platform native apps was simply writing portable C++, rather than integrating with the various native UI frameworks
The advantage is having something more optimal than the web stack for application design, specifically than HTML, CSS and the DOM, which while surprisingly capable given their origins, are still a series kludges and necessary evils.
If we decide that the web stack is what Web Assembly runs in both on and offline, then we're stuck with the limitations of those formats forever, rather then at least trying to come up with something more fitting.
The main difficulty with cross platform native apps is that nobody's willing to pay for C++ devs with UX experience anymore. Electron makes such things possible even at the expense of code quality and performance - but by that point you simply won't care.
From what I've seen speed isn't usually the issue with Electron based applications (except Atom), the issue is every other performance metric; memory use, disk use, start up time, etc. How will WebAssembly help here? Will it allow Electron to cut its memory use or startup time?
WebAssembly could become the universal crossplatform language and that would open up a lot of possibilities.
From writing a hybrid app and replacing all the native parts with it (so Node in Electron), to even writing everything with WebAssembly and using native GUI.
It is already possible to remove Node and Chrome from a hybrid app by using webviews and Swift in macOS and C# in Windows. We're developing a crossplatform app using that technique and it's awesome. With WebAssembly the native part could be completely crossplatform with comparable performance.
The only project I know that does this is NodeKit but it seems to be a bit abandoned.
Every other popular scripting language is much slower in comparison across almost every benchmark, yet you don't hear complaints about writing an application with some other scripting language (eg, python).
The problem isn't JS performance -- scripting performance crown was won over a decade ago. The issue is DOM being slow. If you write bindings to a native GUI framework and write your app in JS, performance is going to be extremely acceptable. The biggest issue is that most JS devs aren't comfortable in that universe.
It isn’t even DOM performance. DOM performance has been fast for about 9 years. The problem is not the DOM but rather all the slow abstractions, including query strings, insecure developers cannot live without.
If you are comfortable with the standard DOM methods your UI performance should generally be about 25% of JavaScript execution speed with exception to the visual render of large DOM node injection. It’s typically fast enough that you wouldn’t be able to tell the difference in performance compared to a GUI written in efficient native code.
DOM has always been incredibly slow. Quantum showed that CSS layout has been incredibly slow. Servo showed that HTML layout is incredibly slow. In addition, the DOM is extremely memory intensive no matter what you use.
A great example is VS Code switching from HTML to Canvas for Terminal. Performance increased by several times. React Native is another example. It performs much better than a Webview even though it still uses JS. Gnome and GJS perform better than any electron app out there while using way less memory.
I assume that when you say query string, you are talking about document.querySelector() rather than the actual query string in the URL. Modern apps using something like React almost never use those. Even with a lot of care, those apps will still be slower than apps written with native GUI frameworks.
Honest question: does webassembly do anything about speeding up the Dom API? For example low-latency text input is non-existent in any browser engine today (short of rendering text using webgl). Does wasm do anything about this?
Currently there's no way to interact with the Dom API from WASM directly, you have to interop with JS functions, so if anything, it's slower than JavaScript due to the interop bottleneck.
It makes it worse. Eventually it might make it slightly better via strong typing and reduced GC. Latency is largely a deficiency in the design of browsers (multiprocess rasterization, gc blocking the event loop, etc)
Yeah textarea and also keyboard events. I was wondering because the comment to which I was replying implies that wasm could make the browser the defacto framework for cross platform code. But I don't think this will be the case if the native APIs continue to be low performance.
Not really. Progressive Web Apps are a much better model for users than the App Store because they get to use the app immediately then decide later whether they want to keep it on their home screen or not. We've all become very used to the App Store but honestly the experience is pretty crappy.
Web apps are inherently mediocre on every platform.
There’s enough advantage from being accessible via URL, usable on any device, live updating, etc. to compensate that for many uses. But using web apps daily for any serious work is a huge loss in resource use, usability, polish, ...
The one that makes me saddest though is that web apps seem to be getting worse over time. For example most of Google’s suite of web apps were dramatically better a decade ago.
On the web the apps are barely usable for the users because the users are acceptable bystanders, not clients. The clients are data hoarders, advertisers, and trackers. In fact a tuned web app focusing on user experience and performance, with the current state of ES, DOM, HTML5, CSS3, and general performance of web browsers would be mindblowing.
The problem of mediocre apps is not what they're written in. Millions of people happily use apps built on web technologies every day without even realising. Similarly, millions of people use badly made native apps and hate every second. The tech is not the problem.
I’ve dabbled with iOS development and Xcode doesn’t seem that braggable as a tool.
Of course the modern Javascript web stack isn’t pretty either, so I guess what I’m saying is everything sucks a bit.
I’ve seen nice results and crappy results regardless of what particular stack it’s made in. IMO the biggest difference shows up in integration with the rest of the system. If you want to hook into the Files app or Siri Shortcuts, native apps certainly have a leg up.
That depends. I agree that the tooling around hybrid apps is pretty bad (debugging React Native layout issues is painful), but the tooling around web apps is really good these days, and that carries over to PWAs (and Electron, Ionic, etc) to a large extent. Chrome's perf flame chart is ace, and if you use VS Code you can get decent IDE debugging going. It's fragile and it takes effort to start but it's waaaay better than it was 5 years ago.
CSS (or Yoga) is proper layout if you know how to use it. Most native APIs are available to JS even on iOS. Most animation is rendered on the GPU in web tech unless you're doing things very wrong. We even have things like Lottie, AirBNB's SVG-based After Effects animation tool.
All this stuff is just done now regardless of what tech you choose. The arguments against web tech are old. The platform has caught up.
It has not. There are no tools for the web approaching even a Delphi RAD or a Qt Creator ca 2001.
CSS layouts are a joke, and trying to create anything as complex as a modern app with CSS is a road of blood and tears (go ahead and use CSS to implement something like Sencha. Hell, start with any constrained layout available for most native frameworks and toolsets out of the box).
By "most native APIs" you mean a very small subset deemed more-or-less safe to execute in the browser (you won't ever have full access to, let's say, UIKit, or AVFoundation).
And even if animation is rendered on GPU, 1) if you have a lot of them, the browser will struggle, and 2) web animations are extremely limited, primitive, and extremely constrained by layout. Good luck not running into reflow issues for animations which are a breeze on the native platforms. And good luck working around these issues using only animations which won't trigger them.
> All this stuff is just done now regardless of what tech you choose.
There are people who build OSes using only assembly. It doesn't mean that tools or capabilities of assembly are anywhere near available for other tech.
I broadly agree about complicated apps, but there are plenty of mobile websites which are more useful than apps for me precisely because of their simplicity. The killer benefit is the ability to deep link, for instance I have three or four icons on my homescreen going to the timetables for different bus stops, and two or three for the weather for different places. For my use case I want to go straight to a simple stateless page which tells you what you want to know, not be subject to the UX whims of the app designer. The drawbacks are created by iOS, I would prefer these websites to be able to use a cache which worked and wasn’t broken in small subtle ways, and to be able to set them fullscreen.
My biggest objection to PWAs is that a significant part of the value of the app store is the constant scanning for various kinds of malware. I'm not sure that there's a way around that, and that makes the various app stores infinitely better in my book.
That's all assuming you trust the efficacy of the app store scanners of course, and my trust in google on that is pretty low.
Why not just build a web app that works as a regular (mobile) web app, but has additional features when launched in the context of a PhoneGap-style app-store app? Then have the web version offer to install the "native-ish" version. That's progressive enhancement, no?
> Progressive Web Apps are a much better model for users than the App Store because they get to use the app immediately then decide later whether they want to keep it on their home screen or not
The banner being a factor… how? iOS has let users add web applications to their home screen for over a decade.
> We've all become very used to the App Store but honestly the experience is pretty crappy.
As opposed to every fucking site spamming you to install on your home screen being a stellar experience.
Not an issue: as the application author, if / when you see that the user seems invested (not at a random point 30 seconds in or some crap like that) you can add callout or button to suggest installing on their device, and provide the relevant steps then.
So just like an add to homescreen banner, then, except with more steps required by the user, and a requirement by you to customise it for every different UI the user might see it in?
All of which is a feature, not a bug: it makes the prompt more expensive to implement and way more intrusive to the user, meaning significantly less likely for drive-by prompter to implement.
Further bonus: no unstable proprietary API to reverse-engineer and implement and it teaches the user that there's nothing specific to it, they can pin any site they commonly use to their home page whether that site provides specific PWA support or not, such that they can perform the action at any point they want.
The browser is simpler, the method is less scammy and the user is empowered.
Its not about whats a better experience for the user its about what gives apple more money and control. Apple gets to pick which apps make it on to the app store and they take a huge cut of all sales on apps.
I really get annoyed when I see people talking about the "huge cut of all sales on apps" in isolation, as though hosting high-traffic downloads, handling financial transactions (purchases, in-app purchases, subscriptions, credit card handling, fraud investigation, etc.), and occasional spots of marketing and publicity when an app does particularly well or is featured in the Stories cost nothing.
It's not like these things are cheap, and plenty of developers wouldn't have a shot of successfully delivering an app without the infrastructure in place to support them.
It should come as a surprise to absolutely nobody that the vendor wants their cut.
If we are having an honest conversation about who gets a cut of what, we have to realise that web apps still have bills to pay and people getting their cut of something — credit card handlers, payments systems, web hosting (and that ain't cheap, especially when demand rises) on top of the cost of hosting an API and databases, and plenty of other costs.
You know that in Android, if you as a developer use in app purchases, you have to pay a cut to the play store, right? But the thing is, you can also do payments on your own (although users are much less likely to trust you), in which case there is no cut. This is why I can buy a book in Kindle on my android phone, but no on my dad's ipod.
That's what people are asking for. If you want to provide services, sure, charge for them, but also allow developers to not use your services in this case.
Apples monopoly enforcement in both this and in html rendering is one of the biggest causes of stagnation in tech right now.
When I run a web app, sure, I need to pay lots of different middle men. But I get to choose which ones I use.
Its the same situation for steam. Steam provides real value for indie devs who can't set up payment systems and download servers but once you get to a large size you are just having all your money sucked out by valve who provide nothing that you couldn't do yourself cheaper.
Considering the popularity of Electron, if WebAssembly does get as fast as native or at least 80% there (and that's a really big if) it would easily become the cross platform language for the vast majority of desktop applications.
For mobile we will always be dragged down by Apple and its reticence to embrace web technologies. It's 2019 and we can't even show a add to home screen native banner.