Partial WebAssembly backend for the GNU toolchain
sourceware.org
sourceware.org
[1]: https://www.destroyallsoftware.com/talks/the-birth-and-death...
In any case, I would very much like to see an implementation of this.
In the past, backends for anything usable as an intermediate language received pushback as possible "escape hatches" by which one could glue proprietary code (whether frontends, backends, or optimization passes) into the GNU toolchain. That pushback mostly went away when the GCC Runtime Library Exception came out, which makes such proprietary combinations much less viable.
So, hopefully this will get merged, or at least get on the path to merging after further development.
There's been a bunch, from java backends, etc.
Admittedly, the concern about the JVM backend was different from what got Google in trouble; indeed, GNU had their own reimplementation of Java (GCJ / GNU Classpath) which was equally potentially infringing (and was the main reason bytecode output was a problem in the first place - because GCC supported bytecode input already, it could allow for round tripping). But the overall message of avoiding proprietary programming languages/environments seems prescient.
A sample of such statements, from https://github.com/biergaizi, can be found at http://weibo.com/1219205751/Dov1ynGLk (login-walled).
As for desktop as such, my tablets are also fine with an external keyboard and the right set of native apps.
"Browsers won't and should never have the full capabilities of native APIs. It's certain that many more applications will shift into web apps, but there are limits to what I'll want my browser to do."
Which given the increase in mobile OS across the planet and their use of native apps, is something I wish will turn the tide.
There's nothing in its essence that makes it different from the virtual machines in Java or C# or Python, other than having several alternate working implementations, available in every device that runs a modern browser (true, the latest wouldn't count as "native", but nothing stops you from running a headless WebAssembly instance directly on the metal without the intermediate application layer).
The solutions you proposed (iOS, Android and UWP) may count as native, but they definitely don't count as "universal" in the same way that WebAssembly would.
This has not changed since the HTML5 is going to change the world kind of thing, and I doubt WebAssembly will change that.
Simple stuff like Web Components are still pretty much a Chrome thing and WIP everywhere else, let alone more specific OS APIs.
Are you talking about implementations not being there (yet, though that could change with time) or is there a fundamental difference in the platform architecture that I'm unaware of?
I don't understand why you think providing all those services in UWP is a good thing, but extending HTML5 + the Javascript VM to cover them would be a terrible idea.
It is not that is a terrible idea, it is that it will never happen, thus always being a 2nd class UI/UX.
I am still waiting for a version of WebGL that can actually fully use my graphics card, WebGL 2.0 surely isn't it yet.
Or for web components to be ready across devices and multiple browsers. How many years has Google been talking about them at Google IO now?
Once you have a development stack with a good toolchain and widely available on many platforms, many people will be interested , and it will grow. Having a standardization body that will incorporate the best is a good thing to have, but it's not a requirement for the platform to get the tech support by third parties (see what happened with Flash or Silverlight, which required a separate unsupported engine as a plugin). Having a single target will surely accelerate development?
Current spec is extremely limited in capabilities anyway for the full RIA spectrum of needs (strings, objects, dom), at this stage practically useful mostly for numeric calculations and such. Certainly there are loftier goals and a lot of optimism with regards to implementation timelines, "buuut"...
We need a next generation WebGL with features comparable to DX11 before web graphics can catch up with the state of the art in native PC/console graphics.
One supports the other and both need to be incredibly efficient and compact.
And it will always be way too high for VR.
Nvidia has a game streaming service that does this already. I've only tried it briefly but it worked great.
Currently Emscripten uses a fork of Clang/LLVM called fastcomp with a ASM.js backend.
This is a fork of GCC/Binutils with a WebAssembly and ASM.js backend.
It would be interesting to get that working and do some code comparisons on the output.
In the long term, we might see WebAssembly used as a means to implement JavaScript, such that you can count on the same set of features in every browser.
That'll depend on how well WebAssembly can interface with the DOM and with other browser APIs without needing JavaScript shim layers.
The requirements for an instruction set aren't really the same as the requirements for a language well suited to writing, say, video poker games.
Right now we have Javascript and its assorted libraries, which, as bad as they are, come with the browser or at least are generally reused/cached very frequently.
People seem to fail to realize that everyone and their mother will dump their runtimes and their VMs on top of WebAssembly as soon as they will be able to. Java Applets 1, 2, ..., 100.
Yes, they will present it in a very fancy and attractive way, but fundamentally that's what will happen, cause who wants to rewrite everything for Javascript-land when they're not forced to? Competitive pressure will always push towards bloat, just look at Facebook and they Android-runtime busting app for an example.
I, for one, am looking forward to the day where, besides the 500MB of Javascript my 40 tabs are loading, I'll also load 1.5 GB of WebAssemblied formerly native runtimes.
Legitimate purposes include spam-proofing message boxes, as well as cryptocurrencies whose PoW is somewhat CPU friendly, such as those bottlenecked by DRAM latency.
Similarly, node.js got at least part of its popularity because it was the only thing that used _the_ language you can also run in the client.
This levels that playing field at least a bit (completely, if it can manipulate the DOM with little friction)
I expect to see many server-side languages will fairly soon compile to WebAssembly, so that they can position themeselves as an alternative to node (For example, I think Apple would be stupid if it wasn't working on a Swift-to-WebAssembly compiler).
In my book, that is good; competition in that field will improve all tools.
https://hacks.mozilla.org/2017/02/what-makes-webassembly-fas...
Developers mostly discuss JavaScript shortcomings and new possibilities offered by WebAss, but seem otherwise happy to completely throw the fundamental architecture of the web under the bus.
Technically, what WebAss can do has since long been possible with native applications; the only thing added here are new software licensing models, eg. pay-per-use, but mostly tracking/ad-financed.
Almost every page needs JS to use. Almost all JS is thoroughly munged beyond readability. It's normal for even page navigation (surely a browser function) to be handled in JS, and for resource loading (again a browser function) to be done through JS making AJAX requests to URLs generated deep in a minified blob. The accessibility nightmare is real.
Ads are common as ever and adblocking is an arms race never won. DRM has been here for years, and HBO isn't putting .mp4s on an FTP server any time soon. YouTube is almost unwatchably saturated with ads and is run by Google, the search and analytics company. Targeted advertising and analytics are a bell that can't be un-rung.
The web you are trying to save became a victim of its own success, somewhere around when everyone decided it was going to be HTTP and HTML instead of gopher, the browser wars started and AOL users started to flood USENET.
This is going to ruin so much about the web, and this 'lets just give up' attitude is one of the reasons why
What are you talking about? I think I saw 2-3 ads top through all my browsing for the last year. The arms race is won by the adblocker. There was a slight upset when adblock detectors appeared, but Anti-Adblock killer took care of them.
However, at the end of the day, content providers have to make their content available in plain HTML format in order for search engines to index it. If they did the above without offering a plain HTML alternative, they'd lose traffic from search engines. But, if they are offering that format to search engines, they have to offer it to us too.
(Okay, they could lock it down so the plain HTML is only available if User-Agent = Googlebot/Bingbot/etc and source IP is coming from Google/Bing/etc network. But, will the search engines let them get away with that? I would hope Google would refuse to index it on the grounds that their crawler is getting something very different from what the real user sees, but I guess that's their decision.)
IMO, the bigger obstacle to "content that can't be linked, saved/archived, mirrored, cached, shared, translated or made otherwise accessible" is the "fundamental architecture of the web": HTTP. You can't link it (who knows if the person who clicks the link will get the same page?), you can't cache it (who knows when to invalidate it?), you can't mirror it (who can enumerate the dependencies?), and so on. Something like IPFS would fix these things (and should fix these things). But in practice, a fairly cacheable, linkable, mirrorable, sharable web has been built on HTTP and I expect nothing much will change when wasm is thrown into the big vat of web technologies too.
Mind you, I have nothing against Google nor ads in general (but I do have an issue with tracking, even though it has legitimate uses).
If publishers are replacing browser functionality, it's probably because the current way to reach browser functionality from wasm is bad/slow. See the second stick man graphic here:
https://hacks.mozilla.org/2017/02/where-is-webassembly-now-a...
For bigger games, maybe. For applications, not so much.
However, it will give you the ability to mix and match different languages more freely. E.g. you can write processing-intensive modules in Rust/C/C++ and continue to script the UI with JS/TS/Dart.
This way you won't have to recompile tens or even hundreds of thousands of lines of code for minor UI changes.
So, at some point, you should be able to compile any language to WASM, including Javascript. The only real barrier would be the size of the runtime / standard library for the language. If WASM supports also supports some kind of hashed cache where many sites can share a language runtime, that's not even much of a barrier.
I suspect once it's stable, you'll see all sorts of languages being used in the browser.
https://users.rust-lang.org/t/compiling-to-the-web-with-rust...
(This post is a bit old, it works on stable nowadays, but it gives you the basic idea)
I don't think this is a fair criticism of javascript. In javascript if you want to you can define all your callbacks as top level functions and just pass a function pointer through, the same way you would in classic C or C++. But nobody does that because its an awful way to write your code. If you want to do async programming you need callbacks of some form, and putting the callback inline is better. (Hence lambda functions being added to C++ and java). Arguably await/defer is better still, and unlike C, javascript now supports await if you want to write code that way.
The only other decent way to write high performance code is to use lightweight threads and message passing (go or erlang). But again, (as far as I know) C and C++ make this sort of code really hard to write correctly because of the memory model. I'm looking forward to seeing that battle played out in rust, where both models can work side-by-side.
As for resource loading in JS, promises aren't perfect but they make deferring code execution on resources loading work great. Just bundle your resource loading into a promise and then require('./resources').then(whatever => {...}).