7 ms·
Is the web not salvageable? Look at web assembly. The browser vendors added a VM and a bytecode format that runs on it. And they did it pretty quickly. In m
by trgv 9y ago
Is the web not salvageable? Look at web assembly. The browser vendors added a VM and a bytecode format that runs on it. And they did it pretty quickly. In my mind, this is the way things are going to improve in web-land. Not "throw it all out and start over."
If someone/a company wants to build an "app browser" and associated protocols and publish it then the market will decide how that goes. I think it's a cool idea, but I doubt it would gain traction because almost everything enumerated in this post is a developer concern, not a user concern.
In software, there's always going to be that temptation to start all over again due to fundamental mistakes that were made years ago. But I feel there are far too many entangled interests in the web for that strategy to make sense. Hey, if someone wants to work on it, god bless them.
- jacquesm 9y agoWeb assembly is a step backwards, not forwards.
- dmitriid 9y ago> Is the web not salvageable? Look at web assembly. The browser vendors added a VM and a bytecode format that runs on it. It only solves one part of a multipart equation: intermediate format for the web that multiple languages can compile to.
- mike_hearn 9y agoWebAssembly is symptomatic of the wider problems. There have been many initiatives over the years to add more languages to the web platform than just JavaScript. I remember one from Google that tried to add a form of Java that had better integrated DOM access and didn't use a separate/traditional JVM (more like another mode on top of V8, iirc). There was NaCL, two attempts. Of course there were plugins as well. They were all killed off with justifications that ranged from the reasonable-sounding to the quite obviously ideological. WebAssembly is the latest attempt to scale this wall, and what does it give us? A new bytecode format that nothing uses and which is accepted by no hardware. It looks suspiciously similar to JVM bytecode, featuring a small set of bytecodes and a bytecode verifier, except that there's no support for expressing patterns that all high level languages have, like exceptions or garbage collected memory allocation. The primary new capability, after years of work, seems to be that you can now embed C into a web page (as long as you bring your own C library, I guess) and run it slowly until it warms up. Although they handwavingly claim that in future they'll add GC support and that'll unlock support for other languages, it will come at a massive performance penalty that makes it effectively useless because such languages require complex JIT compiling runtimes to achieve good performance and you won't be able to do that sort of thing inside a wasm module. The web's designers had many other options that would have been far more useful but they went with this one. What is their solution to avoid web apps now importing the world of manual memory management vulnerabilities? They don't have one: the best you get is preventing the C code from affecting the browser. The only thing I find sadder than WebAssembly is the undeserved adulation it seems to be garnering from the web dev community. I get it - at least there's progress of sorts. But, sigh. > I doubt it would gain traction because almost everything enumerated in this post is a developer concern, not a user concern. That's true for any developer platform. Users ultimately don't care how software is built, unless problems of the platform hurts the quality of the apps.
- deleted 9y ago[deleted]
- niutech 9y agoAFAIK, WebAssembly is based on asm.js, which can be compiled from any LLVM language, not only C, using Emscripten. There are full implementations of Lua (https://daurnimator.github.io/lua.vm.js/lua.vm.js.html https://daurnimator.github.io/lua.vm.js/lua.vm.js.html), Python (http://pypyjs.org http://pypyjs.org) and even Java (http://teavm.org/ http://teavm.org/) in asm.js. You don't need to write in the C language at all.
- MarkMc 9y ago> I doubt it would gain traction because almost everything enumerated in this post is a developer concern, not a user concern I'm not sure this is true. My Mom doesn't really know the difference between an app and a website, but if I showed her the Facebook web app instead of the Facebook iPhone app I'm sure she would complain that it was not quite as responsive or didn't implement the same touch gestures.