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.
It makes sense since WASM's SIMD isn't ready yet, and a paper saying “WASM is slower because SIMD isn't ready yet” would be rather uninformative to browser vendors.
I think the problem when you're doing X vs. native is you're implicitly saying "X vs. the best possible situation." I think it's fine to compare it against vector-less operations, but they should also benchmark against more vanilla native compiler settings.
WASM will be the default for any non-trivial web apps in the next few years (assuming the DOM access gets addressed). Why would you ship JavaScript of the internet to then get compiled locally? I know there's arguments for JIT, but I don't think they make sense for JavaScript. Also devs hate JavaScript! Okay, I know we don't all hate it and I know it's popular, but really why does TypeScript exist? It's just a rational way to produce JS that hides the silly nature of JS. Now you don't need JS (or TypeScript) choose the language that works best.
Compilation speed should be part of the benchmarks, as it's critical for WebASM. The best would be to use the Clang optimization setting with the most similar compilation speed to compare runtime speeds.
As an example the article mentions suboptimal register allocation, but without compile time comparision there's no way to know if there really is a simple way to improve WebGL implementation.
It's true that Clang can't compete with the JITs in question on speed. Even at the settings with the most comparable quality of generated code, Clang will be much slower, because its internal design is primarily geared towards maximum optimization potential at high optimization levels, with lower optimization levels as more of an afterthought.
But that's beside the point. The paper isn't suggesting switching to Clang or to the algorithms Clang is using. Rather, it's treating Clang's output as an approximation of 'optimal' code generation for the given C code. There are various reasons to compare it to WebAssembly JITs:
- For one, the paper identifies specific reasons the JIT output is slower, which shows potential areas of improvement they could focus on.
- The comparison also provides a sort of upper bound on how much the JITs theoretically could be improved. It's only a weak upper bound; the upper bound of code quality achievable at the required performance levels is lower and would be more relevant, but there's no way to measure that.
- It also indicates the potential of adding a higher tier to the JIT that optimizes very hot code using slower algorithms.
- And finally, most entertainingly, the benchmarks help answer age-old questions like "can WebAssembly replace native code?" :) Or, at least, "for what applications can WebAssembly replace native code and have acceptable performance?"...
The problem is that the compilation budget is much smaller when it impacts the perceived startup time of the application. For a performance critical application it is much easier to throw resources to offline compilation than for online compilation.
Do typical web assembly implementations cache the result of compilation?
The benchmark seems to use only browsers' built in VMs to run WebAssembly (more like the the efficiency of different VM JIT compilers compared to native). How about running them in standalone webassembly VM like WAVM (it does more aggressive optimization, use LLVM for JIT), Asmble (running in JVM), or Wasmer (use Cranelift like Firefox does, maybe a little bit faster than Firefox)
(I just skimmed the paper, sorry if i miss something)
Some projects are looking forward to using WASM as a general replacement for their current Turing-complete query language engine (e.g. Javascript in CouchDB, Lua in Redis, etc.) WAVM is probably what such systems would embed.
That and distribution of applications without having to provide the source, although currently you can of course minimize and compile the source, but still it's much more readable than an actual assembly -output.
I wonder if wasm is feasible to target in hardware. I mean, there were hardware Java bytecode implementations, and that's a lot higher level, so it's definitely possible - but is it worthwhile? Are there any idiosyncrasies in wasm that make it slower than x86 or ARM, that could be fixed if the underlying architecture was more accommodating?
WASM is a poor target for hardware, for reasons that don't matter at all to JITs. It has an unbounded stack, its branch instructions use tags rather than relative offsets, its calls use a function table which would be doubly-indirect in hardware, and such.
> "I wonder if wasm is feasible to target in hardware. I mean, there were hardware Java bytecode implementations, and that's a lot higher level, so it's definitely possible - but is it worthwhile? Are there any idiosyncrasies in wasm that make it slower than x86 or ARM, that could be fixed if the underlying architecture was more accommodating?"
You're asking for unified, standardized, cross-vendor hardware + instruction sets.
Why not do this other way around though? "Compile" JS to WASM, then to x86/x64. Finally just execute on the bare metal.
Let me rephrase that. Is x86/x64 (or ARM, for that matter) architecture ideal to compile WASM into? Or could a different architecture be designed that would result in better performance?
> "Let me rephrase that. Is x86/x64 (or ARM, for that matter) architecture ideal to compile WASM into? Or could a different architecture be designed that would result in better performance?"
I'm sure you could compile WASM into Japanese or French if you had to. Maybe then, our French-native CPUs would finally be able to process "sudo fais moi un sandwich". My point being, you're asking a very broad, very theoretical question.
Are CPUs these days not performing well enough for most applications? If so, is it necessarily due to the complex instruction sets powering those platforms?
I'm sure you aren't doing this consciously, but you're answering completely different ones that are easier to dismiss than the original one that more difficult to answer. It comes across as using a straw man.
int_19h is not asking a very broad, theoretical question so much as that it is a difficult question to answer, requiring specific technical know-how about CPUs and compiler design.
Saying that one can compile WASM into Japanese or French is not an answer to "is x86/x64 (or ARM) an ideal target architecture for WASM", so irrelevant.
Whether or not "CPUs these days [are] not performing well enough for most applications" is not relevant for answering GPs question. It's a justification for you not to have to answer his question. But ultimately, whether or not there would be a point to targeting WASM in the hardware is unrelated to whether it is possible, and what the limitations are. Also: did most websites need the performance of V8 when it came out? No, because no website used JavaScript intensely due to its slow performance.
Theoretically it would let you ditch a lot of outdated instructions for something a lot simpler, enabling smaller, more efficient (power-wise) hardware.
ARM abandoned their JVM bytecode execution tech a decade ago because JIT compilers became faster than it. So the same would probably be true with WASM.
Worthwhileness would depend on your motivation for doing it.
I guess a very tiny microcontroller could be a use case, where it's a good tradeoff to save some memory (=cost) by eliding the JIT even if execution is slow. Even then you could just replace this with offine binary translation.
> Root Cause Analysis and Advice for Implementers:
> We conduct a forensic analysis with the aid of performance counter results to identify the root causes of this performance gap. We find the following results: (1) code compiled to WebAssembly yields more loads and stores than native code (2.1× more loads and 2× more stores in Chrome; 1.6× more loads and 1.7× more stores in Firefox). We attribute this to reduced availability of registers, a sub-optimal register allocator, and a failure to effectively exploit a wider range of x86 addressing modes; (2) increased code sizes lead to more instructions being executed and more L1 instruction cache misses; and (3) generated code has more branches due to safety checks for overflow and indirect function calls.
A surprisingly large amount of this boils down to "x86 needs more registers", but there's quite a lot of detail here. It validates my personal experience that Chrome doesn't do a very good job relative to Firefox, for example
> Code generated by Firefox
has 1.15× more branch instructions retired and 1.21× more conditional branch instructions retired than native code, while code generated by Chrome has 4.13× branch instructions retired and 5.06× more conditional branch instructions retired.
> Chrome executes 2.9× more instructions and Firefox executes 1.53× more instructions on average than native code.
> On average, Chrome suffers from 3.88× more L1 instruction cache misses than native code, and Firefox suffers from 1.8× more L1 instruction cache misses than native code.
Overall, it was always obvious that Chrome's deficit compared to Firefox was just engineering work, but what is new is figuring out how difficult the native code deficit would be to close. Some aspects are quite straightforward; browsers probably need to develop a more aggressive tier-2 WASM JIT, now that both listed have a tier-1 baseline that is very fast to compile. This should include:
1. a better register allocator,
2. better peephole optimizations,
3. sophisticated loop optimizations.
Unavoidable slowdowns might include:
1. register pressure from reserved registers,
2. stack overflow checks,
3. function table bounds checks.
———
Is this line a typo? I can't make sense of it; I read 1.5 and 1.9 respectively from the table. (There's another mistyped sentence starting ‘Clang,’ but it is not a major issue.)
> On average WebAssembly in Firefox runs at 1.9× over native code and in Chrome runs at 1.75× over native code.
This isn't very surprising. C compilers have developed all kinds of low level optimizations over decades, trying to extract the last bits of performance they could. In contrast, JIT compilers for JS focused on recovering missing type information through type inference and other low-hanging fruits.
It's also the case that there's a lot more pressure on JS JITs to produce code fast, and so running multiple passes of low level optimizations was not desirable in a web context. This is somewhat bad news for WASM: better low level optimizations could mean longer compilation times. However, AFAIK, Chrome has been working on caching compiled code, so you may only have to compile WASM when it changes (or when you reinstall/update your browser).
Yes, a mistake on their part. They changed now to properly show that WASM is slower (not faster) then native code.
Now it reads:
"applications compiled to WebAssembly run slower by an average of 50% (Firefox) to 89% (Chrome)"
Chrome and Firefox performance should be closer, at least in Chrome 72 and 73. I think the comparisons may have been done without trap handler support in Chrome (virtual memory tricks for fast memory bounds checks).
Most performance spec for WASM are not even finished (SIMD, Thread, ...). Doing a benchmark will be interesting when at least SIMD as been properly finished and implemented.
In the old days there were websites using flash or silverlight and they had a screen "in order to use this you must use flash" and for some reason, people did download and install flash so that they could watch the cat videos or whatever.
Apple has shown and continues to show willingness to embrace web technologies once they show clear promise or stability[1]. They might not implement "hemorrhaging edge" technologies immediately, but if the technology supports it, and it contributes positively to the user experience, they will do it.
I don't think that's right. Apple are consistently late to the party as far as Safari goes. I mean, they don't even support web push notifications yet, while other browsers have been supporting them for years. It's down right annoying.
I'd say there's a difference between a 'web site' and a 'web app'. If there's a web app for which you'd allow notifications if it was a native app, why wouldn't you do so for the web app?
Because every single website I visit today on my desktop shows me a popup asking me to enable their desktop notifications.
Nah, useless functionality. I've got feedly if I'd like to keep track of their news.
That being said I work in ad arbitrage, so I understand the presumed efficiency of these notifications. As they say our business is middle-aged Americans who can't use the Internet.
> Because every single website I visit today on my desktop shows me a popup asking me to enable their desktop notifications.
I know what you mean, but that's usually traditional news sites and the like. Having the Spotify web app notify you of the currently playing song or a remainder app reminding you of an appointment is of course a different case, Hence the "web site" vs "web app" distinction I made.
I don’t know: frankly I find them incredibly annoying (that includes Spotify, email and the likes).
But besides the point: imo the semantics of these notifications severely differ between applications. Moreover, the usefullness of them heavily depends on the ability for someone to integrate them in the whole ecosystem.
Thus notifications from news websites fit right in: they don’t need a snooze button as it in for OS X Calendar app. But they are the least useful.
So we are back to square one: if you allow notifications, then what kind of? Do you allow any HTML payloads or only some?
That being said my reply is re. subj.: I understand why Apple doesn’t like them. Because they are generally useful only for a small amount of use-cases, 99% of which is spam. And an average user is going to blame Apple for allowing him to accept them in the first place.
But all that is very much true for native app notifications as well. So it may be that you don't like notifications in general, not PWA notifications specifically?
Just because you don't like something doesn't mean it's not useful to other people. Case in point: my mom and a lot of her friends don't know how to use smartphones, or don't have one at all. But they like to stay connected with people on Facebook. The problem is, they hardly ever go to Facebook specifically, so the chrome notifications are very useful for them.
I think it's laughable that you differentiate between the notifications of an app vs the notifications from a web app. Both are opt-in, with web apps being even more explicit about the opt-in process, in my opinion. Also, once you disallow notifications, the web app will not be able to request permissions again. Why do you feel this is problematic?
It's easy to disable notifications for native apps (on iOS at least) - just don't grant the permission in the first place.
The reason I feel web notifications are more problematic is the nagging aspect that I think would happen (like, for example, the 'install our app' interstitials and prompts). That's annoying enough without adding notifications to the mix.
I sort of agree with you. The web is the wild west, reckless and unrestricted. The app stores are considerably more tame, yet intrinsically restrictive in many ways. Eventually we will tame the web app/PWA ecosystem, while keeping things much more flexible than the app stores. I agree some aspects of PWAs are a little rough round the edges (as you described), but there is plenty of polishing ongoing, and I bet PWAs will eventually emerge shinier than their native counterparts.
That's interesting, haven't cared about iOS in a long time though.
PWA's are since 2015, so mid 2018 does indeed seem pretty fast for Apple for implementing it.
I might believe it all when they have "approved 3rd party web rendering engines". Which is ( to be honest) the only thing that will change my opinion about it. Implementing it very slow is just a little better than not implementing it at all.
And i don't think Apple will ever do that. So, it's a rock-steady argument since 2010.
Edit:
If the user doesn’t use the app for a few weeks, iOS will free up the app’s files. The icon will still be there on the home screen, and when accessed the app will be downloaded again
If the user doesn’t use the app for a few weeks, iOS will free up the app’s files. The icon will still be there on the home screen, and when accessed the app will be downloaded again.
Not very trustworthy for using a PWA on iOS it seems :)
I agree that better/modern PWA support was added only recently, but the actual "Add to Home Screen" option has been around since 1.1.3.
I'll admit it's been little more than a fancy way to add a bookmark to your home screen with the option to hide the browser chrome, but it's been there for a long time.
This applies to all apps, not just PWAs, and can be enabled/disabled. I don’t know what you’re quoting as it doesn’t appear in the link (apologies if it does, perhaps my ctrl+f is malfunctioning), so I don’t know if your source is claiming otherwise.
I think that "add to home screen" is a stupid browser API, serving no genuine technical necessity. Feature creep of browsers must be forcefully stopped.
I'm with you. The potential for websites to add themselves is far too dangerous; the web being open, wild, and dangerous, adding a website to the home screen should only ever be a browser-based task.
And no, asking the user for confirmation is never sufficient to stop unsuspecting people from accidentally causing their own compromise. It's a trust thing. Once they trust one dialogue from a legit website, they'll trust it over and over.
Let web sites leave the home screen on my phone the same way web sites have always left my bookmarks/favourites: alone
As far as I’m aware this Add to Home Screen API you’re describing controlled by the website doesn’t exist, adding a PWA is a process controlled by the browser which occurs according to its heuristics, on Chrome it’s something to do with repeated visits to the same site. The only control the website has is a manifest, which sets the icon, loading screen colour, and whether the website can run without browser chrome.
Edit: It looks like Chrome may have changed this, what I’m referring to above was the initial implementation. I think it’s a reasonable objection to say this should be under the control of the browser. But Safari could just implement the former without the latter.
My main gripes with Safari at least with my use of webapps is that it doesn’t allow users to install PWA’s without the browser chrome, and its implementation of service workers is subtlely broken. Those are the biggest usability issues.
If a user goes out of their way to go to the share menu, scroll along and click ‘add to homescreen’ why not allow them to specify to use what is clearly an app-like link without browser chrome? And why implement Service Workers but not according to the standard?
It's just about showing a banner to add to home screen, and the person is not wrong — there is no technical necessity for it. There is already, and always has been, an "Add to home screen" button in Safari. Since the very start.
Having said that, if PWA support in iOS moves forward I wouldn't be surprised if that API is added to iOS, since then it'd be part of a bigger-picture thing.
There's an add to home screen button, but it's buried deep in the share sheet and the average user doesn't know about it.
We already have a "X company has an app" banner API on iOS, it seems fitting that webapps have an option to match.
And the Safari provided "X company has an app" banner is a lot less annoying than any third party "HEY WHY AREN'T YOU USING OUR APP" banners in that it goes away when you scroll down instead of being fixed to the top of your screen. If a native feature can keep people from making a shittier version and sticking it all over, then I vote yes.
Your example, though, directly contradicts the point you're trying to make. Apple does have a native feature for showing when there's a native app available, and -yet- we see those third-party banners.
Having the native API to do something doesn't make the third-party crap banners go away.
Yes, not every site wants it to be unobtrusive, they view the nagging as a feature. But for sites that aren't assholes I think they should have a standardized option like the app store's smart banners.
I guess the real question is "If we didn't have smart banners, would even more websites use obnoxious full screen popovers and fixed position headers that pop back up every time you visit the page?" I think the answer is yes, fixed position headers are a really easy/lazy thing to tack onto a webpage, and not bothering to persist the fact that you already closed it 10 times is easier than saving that preference and checking it.
If you want people to consider doing it the nicer way you have to make it just as easy.
I think the answer is no: smart banners only increased the pop-over spam, and adding a smart banner is pretty much free, it's a single line to add to a header and is guaranteed to only trigger on the relevant / target population. A hand-rolled version not only is significantly more expensive to implement but it will misfire and lose visitors.
> There's an add to home screen button, but it's buried deep in the share sheet and the average user doesn't know about it.
What? It's a single tap to open the share sheet and the button is in the system row "above the fold" (because there aren't even enough items for anything to even be below the fold). If that's "buried deep" I'd shudder to know what you think of uninstalling an application or adding a keyboard.
If the user doesn’t use the app for a few weeks, iOS will free up the app’s files. The icon will still be there on the home screen, and when accessed the app will be downloaded again
So much for PWA's on iOS... Apple's willingness to embrace web technologies is a joke.
The evidence to the contrary is overwhelming. Their W3C compliance is abyamal, and it's certainly NOT because they care for the user.
The way they banned Steam from streaming games, by retroactively changing app-store rules, it appears like the motivation is to increase (app-store) revenues, by crippling the iOS browser.
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.