5 ms·
The problem is that right now we're all talking about WebAssembly because it's too early to tell where it lies. Comparing JavaScript to WebAssembly is apples t
by davidgrenier 8y ago
The problem is that right now we're all talking about WebAssembly because it's too early to tell where it lies.
Comparing JavaScript to WebAssembly is apples to oranges because Java programmers typically don't think of Java Bytecode just like C# programmers don't think of CIL. They think of the programming language and the ecosystem of libraries that go with it.
JavaScript is to Java what WebAssembly is to JavaBytecode, it's an infrastructure to then build a stack on top.
WebAssembly has more hindsight than say Flash, Silverlight and Dart because it does things the latter three failed to address. Those tried to fix many of the warts of the web development of their days without caring about lock-in effect those had (both on the developers and the competing browsers perspective). This is why none of the major browser vendor jumped on the bandwagon and why those technologies were doomed to fail. From that perspective, something like WebAssembly was the only right thing to do, and incidentally all major browser vendor agreed and are pitching in.
And you get so much more with this because now, just like C# programmers share libraries with F# programmers, it'll be possible to have all sorts of functionality (even some that don't exist on the web today) available to anyone who has a compiler targeting WebAssembly. This is actually something that could kill offline development if they working hard enough to make it near-zero cost to target the web. I think that GC will be a major part of making libraries universal (something Java succeeded but C++ somewhat failed at), but as far as I know it's been on the todo list from the start (post-MVP).
It's also difficult to appreciate what is possible to do when you have a single compiler that can target server and client-side. It'll help those working in a typed programmers target the web but also, it's possible to make transparent call between server-side and client-side code letting the compiler wire up everything for you. There's also a lot that you typically do on the server-side where no reason exists other than performance. Those can be moved to the client side and thankfully, existing implementation in your programming language of choice will just work.
We probably can't even think of all the benefits this'll bring.
- Taek 8y agoOne of my biggest problems with the existing web stack is how complicated it is. You basically need to be a company with a budget in the hundreds of millions per year to make a functioning web browser. That gives web browser vendors a ton of control and political power over the internet, a place that ideally is free of all of that. I believe strongly that the Internet would be a more free place and a better place if the barrier to entry to building your own web browser from scratch were an order of magnitude lower. We keep adding more standards and more practices and more compatibility requirements, and so the cost of making a major web browser is just going up. Is WebAssembly something that can help us move in the other direction, or is it yet another standard piled on top of the mountain that already exist?
- LamaOfRuin 8y agoThe core of every leading browser is open source. You can create your own browser if you can run the build process. This is how dozens of new browsers have been created over the last 15 years.
- norswap 8y agoBut then you don't understand your new browser. Also, as new features arrive in the original browser, you fall behind. You can't even hope to review the new changes, you can either merge them blindly or fall behind.
- Perseids 8y agoA path that might bring us out of there would be if the browser vendors defined a subset of HTML, CSS and the DOM API that guarantees an extra fast path through rendering and JIT. Basically leave out everything that makes browsers hard and resource intensive to implement. The increased speed would be the selling point for developers and the simplified and efficient APIs would make it possible to implement something like Electron-Light from scratch which would only need tens of MB RAM, instead of hundreds.
- tylerl 8y agoWith one increasingly irrelevant exception, all the major players in the browser space are open source with "fork all you want" licenses. The barrier to entry for a new player from a coding perspective is zeroish. That's not what keeps new players out and what gives incumbents the edge; what keeps them out is precisely the opposite problem, driven by the fact that it's TOO EASY to launch a new platform. There's enough new players that the novelty is gone and the world is _done_ caring. Nobody gives a damn about your new freedom/speech/privacy/blockchain -oriented browser. You're not starting from scratch, but that's like saying that the transportation industry would be better off the barrier to entry for designing new bullet-trains from scratch was lower. Like... OK. Sure. Maybe. But that's probably not the crux of the problem.
- Taek 8y ago
- pjmlp 8y agoWe do think about JVM bytecode and CIL, but that is when the time comes to do low level optimizations, or integration issues between languages on the platform. Silverlight was developed by a major browser vendor (Microsoft), and Dart was developed by another major browser vendor (Google), which also had NaCl and PNaCl on their browser.