▲ 316 points
back
303 comments
Personally, I think this is terrible (and it really is a game-changer, only not the kind that I'd be happy about). The further we get away from the web as a content delivery vehicle and more and more a delivery for executables that only run as long as you are on a page the more we will lose those things that made the web absolutely unique. For once the content was the important part, the reader was in control, for once universal accessibility was on the horizon and the peer-to-peer nature of the internet had half a chance of making the web a permanent read/write medium.
It looks very much as if we're going to lose all of that to vertical data silos that will ship you half-an-app that you can't use without the associated service. We'll never really know what we lost.
It's sad that we don't seem to be able to have the one without losing the other, theoretically it should be possible to do that but for some reason the trend is definitely in the direction of a permanent eradication of the 'simple' web where pages rather than programs were the norm.
Feel free to call me a digital Luddite, I just don't think this is what we had in mind when we heralded the birth of the www.
I hate to break it to you, but we're already there. People have been using the web to deliver desktop-like applications for the past decade. Over that period of time, the number of people connected to the Internet has more than doubled [1] and will continue to increase. Whether or not an application is delivered through a browser or natively is inconsequential to most of these users. If we look at the list of the most popular websites [2] we see mostly content-delivery platforms (Google, Bing, Wikipedia etc.) with some popular web apps which resemble desktop software in complexity (Facebook, YouTube, Windows Live etc.)
So we have two paths forward. One, we could try to influence the habits of billions of Internet users who use desktop-like web applications in an attempt to restore the document-based nature of the web; or two, we could provide an alternative to the artifice of modern JavaScript development which allows for better applications to be written and distributed to users that use and rely on them. The latter initiative is the more realistic and productive one, in my opinion.
WebAssembly will not lead to the end-of-times of the Internet as a content delivery vehicle. It is a net positive for the parts of the web that do not fulfill that purpose. If you're worried about the free and open web as a publishing platform, look more to governments and corporations around the world that collude to limit our freedom of expression (Facebook, we're all looking at you [3]).
[1] http://www.internetlivestats.com/internet-users/
[2] https://en.wikipedia.org/wiki/List_of_most_popular_websites
[3] http://www.theatlantic.com/technology/archive/2016/02/facebo...
Eh, I think things were a lot worse during the heyday of Flash and Java applets. Sites have been delivering this kind of content since WebRunner in 1997. At least now we have an open, vendor-neutral, consensus-based standards process and a commitment to multiple major open source implementations, which is something we never had with Java or, worse, Flash.
The web is an amazing content delivery vehicle, I totally agree! There's a whole class of content I want to be able to just `wget` and be done with it.
The goal of WebAssembly is to open up the reach and easy user experience of the web browser to new types of applications that just aren't possible to build efficiently with current tech.
We're also making sure that wasm is a first-class citizen of the open web: see, for example, our thoughts around ES6 module interop, GC + DOM integration, and view-source to see the textual encoding of wasm [0][1].
[0]: https://github.com/WebAssembly/design/blob/master/Web.md
[1]: https://github.com/WebAssembly/design/blob/master/TextFormat...
(Disclaimer: I work on V8.)
I agree. I'm really running dry on respect for Brendan Eich. None of the moves he's making are for the benefit of user privacy - look at Brave, his new browser project. It replaces ads on the web with his own ads, tracks you, and puts money in his pocket instead of the publisher's pockets. I'm struggling to remember why he was respectable in the first place - for making JavaScript, an awful programming language we've spent 20 years trying to fix? I don't think that his word on these issues is worth anything any longer.
I prefer the term "mindful" to luddite. Luddite's opposed technology, you oppose the direction it's headed.
But I think you're completely right. We took all that made the web unique, and turned it into a black box for abstracting away hardware/OS.
It's hardly surprising though... you can decentralize a network, but power and control over the medium was bound to become centralized in some form.
I think what I worry about the most is how poorly the modern web partners with assistive technology: it feels like we're actually taking steps backwards.
Despite all the javascript, the content stayed on the web. That's the big win, thats what draws people to use it, and what guarantees its popularity for a long time. The really great, awesome thing about the web is its openness. No company can tie you to their programming language , their "app store" ecosystem , insane policies and authoritative restrictions. We should be eternally greeatful to Berners-Lee for that.
The silos exist today, facebook platform etc. Despite how hard they tried, they did not take over the web.
> "It's sad that we don't seem to be able to have the one without losing the other, theoretically it should be possible to do that but for some reason the trend is definitely in the direction of a permanent eradication of the 'simple' web where pages rather than programs were the norm."
What does it matter what is the norm? Static HTML/CSS is going nowhere, you can still create static content, as you well know (IIRC you run a static blog). The improvements to the dynamic side of the web do not come at the expense of the document-oriented side, both currently coexist and I see no reason why making the dynamic side faster will change that.
Furthermore, changes to dynamic content can enhance the functionality of the document-focused side of the web. Consider Wikipedia. In some ways a Wiki is a set of documents, but it's a set of documents that grows based on utilising input from those using the service, democratising the accumulation of knowledge. For all its flaws, I can think of no other resource that better embodies the virtues of the web than Wikipedia, and Wikipedia would not have grown to the size it is now without the technology that supports web apps.
That said, I don't agree with the trend for moving everything to the cloud, and I hope we can see that trend reverse with better tools for people to take control of their own data. If more people had cheap home servers that were easy to maintain then the issues surrounding lack of control should be greatly reduced.
the web is and will always be a 'content delivery vehicle'. Apps which run on the web are a form of content.
Not all data is open, that is unfortunate, but realistic. At the same time, huge amounts of data is open and available without an app.
What is the use case where we lose to something because of native performance improvements in javascript?
Anybody who wants to build a simple static site can still do that, and I'd suggest the majority of the web is still just that, or very close to it.
I really don't understand your comment about 'executables that only run as long as you are on a page'. You can only read content as long as you are on a page as well. Or are you concerned about our ability to do search and data-mining on large volume of available data?
I upvoted you, but I want to add my voice too.
The web succeeded in part because it was possible for anyone to do "view source" and see what was going on under the hood.
Having that source available is also an important aspect of software freedom.
Losing all that--especially the freedom to see exactly what your browser is executing--for a slight speed increase is ludicrous and I'm very, very sad to see this is being taken so seriously.
We had a huge opportunity here to shape an open and free web. Turning the web into nothing more than a binary distribution platform will undo decades of work and we may never again find ourselves in the lucky confluence of economic prosperity, technological advancement, and governmental benign neglect, that made the open web possible.
The further we get away from the web as a content delivery vehicle and more and more a delivery for executables
Interactivity is an increasingly important aspect of media and of our culture. People spend more money and time on games than on movies and TV.
I just don't think this is what we had in mind when we heralded the birth of the www.
It's never like the framers imagined. It's always stranger and more wonderful than they could have imagined. (And horrible in some ways they couldn't have imagined.)
> Feel free to call me a digital Luddite
Sure. But don't despair, because this future isn't as bleak as you'd assume. With things like Hoodie[0], GunDB[1] and other amazing bits of technology, we can keep the benefits of web-tech for application development, but allow the user to own their data still. Offline-first, easy sync when needed. And really, anything more complex than delivering static HTML pages has the downsides you're mentioning, so unless you want to live in 1995 I can't really understand it from a practical perspective ;)
[0] http://hood.ie/
I agree with quite a lot of your critique and share some of those concerns, but something doesn't quite add up to me. Why are you assuming that the two models of web-as-delivery-system are mutually exclusive? I don't see how web assembly competes with or causes movement away from the web as we've known it.
There's always an element of "one step forward, two steps back" with major technology shifts. Every time we've had a big change in platforms, we also had to redo existing engineering work.
I don't think this is doom and gloom for accessibility, though. The future is in general-purpose assistance technologies that mediate any application. You can smell it with the new work in ML. It is not here now, but as with everything in technology, by the time it's mature and widely available, it's nearly obsolete.
On the Rust side, we're working on integrating Emscripten support into the compiler so that we're ready for WebAssembly right out of the gate. Given that the initial release of WebAssembly won't support managed languages, Rust is one of the few languages that is capable of competing with C/C++ in this specific space for the near future. And of course it helps that WebAssembly, Emscripten, and Rust all have strong cross-pollination through Mozilla. :)
If anyone would like to get involved with helping us prepare, please see https://internals.rust-lang.org/t/need-help-with-emscripten-...
EDIT: See also asajeffrey's wasm repo for Rust-native WebAssembly support that will hopefully land in Servo someday: https://github.com/asajeffrey/wasm
As we get closer to having a WebAssembly demo ready in multiple browsers, the group has added a small little website on GitHub [0] that should provide a better overview of the project than browsing the disparate repos (design, spec, etc.).
Since the last time WebAssembly hit HN, we've made a lot of progress designing the binary encoding [1] for WebAssembly.
(Disclaimer: I'm on the V8 team.)
[0]: http://webassembly.github.io/ [1]: https://github.com/WebAssembly/design/blob/master/BinaryEnco...
Since I started hearing about WebAssembly I cannot stop thinking about the possibilities. For example: NPM compiling C-dependencies together with ECMAScript/JavaScript into a single WebAssembly package that can then run inside the browser.
For people thinking this will close the web even more because the source will not be "human"readable. Remember that JavaScript gets minified and compiled into (using Emscripten) as well. The benefits I see compared to what we have now:
- Better sharing of code between different applications (desktop, mobile apps, server, web etc.)
- People can finally choose their own favorite language for web-development.
- Closer to the way it will be executed which will improve performance.
- Code compiled from different languages can work / link together.
Then for the UI part there are those common languages / vocabularies we can use to communicate with us humans: HTML, SVG, CSS etc.
I only hope this will improve the "running same code on client or server to render user-interface" situation as well.
Considering how critical SharedArrayBuffer is for achieving parallelism in WebAssembly, I'm hoping we see major browsers clean up their Worker API implementations, or even just comply with spec in the first place.
Right now things are a mess in Web Worker land, and have been for quite some time.
If anyone at infoworld.com reads these comments:
On the top of the page, there is a horizontal menu containing "App Dev • Cloud • Data Center • Mobile ..."
When I position my cursor above this menu and then use the scroll wheel to begin scrolling down the page, once this menu becomes aligned with my cursor, the page immediately stops scrolling and the scroll wheel functionality is hijacked and used to scroll this menu horizontally instead.
It took a few seconds to realize what was happening. At first I thought the browser was lagging - why else would scrolling ever abruptly stop like that?
I closed the page without reading a single word.
I still think there is a lot of room for static pages with links in the style that people seem to be prematurely waxing melancholy about when forecasting where WebAssembly _may_ lead the internet. I was always able to find sites of interest that didn't include Flash, Java applets, and company when I just wanted to read something. I find some of the scroll-hijacking, and other javascript goodies on modern pages to either be a distraction, or non-functional on some different devices. On the other hand, I am particularly happy about, and working with Pollen in Racket, a creation by Matthew Butterick. Pollen is a language created with Racket for making digital books, books as code, and bringing some long-needed, real-world publishing aesthetics back to the web [1,2]. I may even by a font of his to get going and support him at the same time!
[1] http://docs.racket-lang.org/pollen/
[2] http://practical.typography.comIf you want to see Brendan's keynote from O'Reilly Fluent yesterday, a sample went up https://www.youtube.com/watch?v=9UYoKyuFXrM with the full one at https://www.oreilly.com/ideas/brendan-eich-javascript-fluent...
I think the web may split into two.
1) 'Simple' web pages will stick with jquery, react, angular, etc type code. Where you can still click view source and see whats going on. Where libs are pulled from CDNs etc.
2) 'Complex' saas web apps, where you need native functionality. This will be a huge bonus. I'm in this space. I would love to see my own application as a native app. The UI wins alone make it worth it!
To me, it's more about choice of programming language than performance. Though the latter is very important, I think the former is what will open up doors to making the browser a platform of choice (pun intended). Currently, it feels like JavaScript is the Comcast of the web. Everyone uses it, but that's only because there aren't any other options available to them.
Video of the talk?
EDIT: Here is the full-length one - https://www.oreilly.com/ideas/brendan-eich-javascript-fluent...
Sorry, but most of the discussion here is completly missing the point about WebAssembler.
It is just a technology, to make things brought through the web, faster. And it is open. And no less secure, than js. So I think it's great.
Good technology does exactly, what the creator wants. And if people don't like some of the things, that gets created with it, then it is not a problem of the technology itself.
So people can do good things, or bad things with it. But in the web, we have the freedom to choose, where we go.
And if we don't like ads for example, we should be aware, that Web-Site creators still want money for their work, so maybe we should focus and support a different funding model. I like the pay-what-you-want or donation model the most, Wikipedia shows, that this is possible on a large scale ...
I want to agree with him, I'd like to see a future where WebAssembly closes the gap between native apps and the web. For better or worse browsers are the new OSes, and I dream of a future were all vendors come up with the equivalent of a POSIX standard where any web application can access all (or a wide common subset) of any device's capabilities, from the filesystem to native UI elements.
WebAssembly... Wow, if we keep going, we'll re-invent what Sun achieved 20 years ago with Java. If only they hadn't f-ed it up...
A question to WebAssembly experts: How easy it is to use WebAssembly as a sandboxed embedded scripting mechanism in my own native (C++) application? I am writing a native real-time system (a distributed 3D engine for VR) in which I send scripts on the wire between machines, and I need to call an update() method of these sent scripts like 90 times a frame. I need complete sandboxing, because my trust model is that what is trusted on machine A may be absolutely not trusted on machine B: not only not letting the scripts do any functions other than what I explicitly let them call, but I need to have hard limit on their memory usage and execution time also, but preferably they should execute in-process, so they can reach memory I let them and be called from the thread I want. Currently I go wtih Lua, but to have really good performance I will need to research this topic more deeply later.
Are those boxes in the picture Firefox OS phones?
Is this an old picture?
What is the upgrade path for Emscripten users? I understand that LLVM will have WebAssembly backend, but how will OpenGL to WebGL translation work, for example?
If you think WebAssembly (or asm.js) is a good idea, I would very much like you to do the thought experiment of what design decisions something like WebAssembly would have made 15 or 25 years ago, and what consequences those would have today.
Helpful research keywords: Itanium RISC Alpha WAP Power EPIC Java ARM Pentium4 X.25
I'm conflicted. One one hand I support open data/raw documents. But this prevents native-like, real-time applications. It also forces developers to work on Javascript which is a terrible language.
On the other hand we have lock-in ecosystems, closed silos, that are detrimental to the commons.
The only consolation I have is that if WebAssembly provides a bytecode instead of machine code then we still have the ability to perform reverse engineering.
In the end, we have ALL have to do the hard task to inform every single person why Apple/FB/MS/Google are harmful to us and why we should boycott their programs/services.
I wonder if along with these byte code engines we'll get capability grained control systems too. Somehow I doubt it though.
So in the future, when you visit a website they'll be able to Eg: open windows, pop up unblockable modals, webGL, bytecode loaded spam/ads, etc. The end users option will be to block everything, or live with it.
I do not like this bold new world we're entering.
WebAssembly shouldn't be for the end users to use, it should used for implementations of other languages so they can access the same APIs Javascript can.
Add Lua to the browser, add Perl 6 to the browser, etc. There are plenty of decade old W3C specifications that never made it to the browser properly, like XSLT 2.0, XQuery 1.0, XForms, never mind the latest versions of the specs.
Is WebAssembly going to be host url resource based (like current .js files are) or will it be used as part of some centralized global assembly cache (GAC) solution where assemblies are only usable from a CDN type of authority?
What exactly will be better? One can compile a lot of languages to JavaScript today. JavaScript is fast enough and size doesn't really matter for most use cases. Is WebAssembly going to be much faster than JavaScript?
Has anyone tried NativeScript? https://www.nativescript.org
Heard about it on a podcast recently, haven't had a chance to try.
If we keep this up, the web will be almost as good of an application framework as a '90s era desktop application. Yay, progress!
I wish the browser vendors focused on CSS Grid module support as much as they did WebAssembly.
This looks AWESOME
Thanks for that update that no one asked for.
WebAssembly = SWF with diff name. Come on!
The format of WebAssembly could be Java ByteCode.
Yeah, great. Transform everything into opaque binary blobs, as far as the eye can see. Wonderful.
Thanks for nothing.
I don't know. I am not sure yet. What the HN folks think about this?