Hacker News Reader

Comment by kerkeslager | Hacker News Reader

Monocultures develop because one tool is far better than all the others.

Javascript isn't a monoculture because all the tools are bad.

Monocultures develop because of corporate backing. The web being open and unclaimed is what leads to the great diversity. As someone who does both server and JavaScript development, the tools are not bad. Often times they solve real problems well.

That's silly - if anything it's the other way around. Web tools have a ridiculous degree of corporate backing, especially with the countless libraries from Facebook and Google (React, Angular, Go, Dart, Flow, IMMUTABLE, etc.), and even Microsoft with TypeScript and others. Meanwhile, Make and friends don't have any corporate backing.

None of them can lay claim to the web though, contrasted with other ui platforms like windows, ios, etc.

Plus IE and Chrome, fwiw

The web is pretty much corporate. All the major tools are built by major corporations, all the browsers are developed by major corporations (with the exception of Firefox, but Mozilla gets most of its money from major corporations) all the major web players are major corporations, all the major web monetization is rented by corporations.

The web's no longer an open platform. Yeah you can put up a blog on your own server using only FOSS. But if you want to drive traffic to it, you're using a huge corporate ad network or some SEO company. If you want to scale it, you're using a huge corporate cloud. If you want to make money on it, you're using a huge corporate ad network.

Firefox started out as Netscape so you can trace it back to big company.

Ah and so what good monoculture can you direct us to?

Rails? Ruby isn't a monoculture, but Rails does seem pretty dominant.

If you like the Rails monoculture, you may like Ember as a front-end framework. Most of the choices are made for you, and on the whole they're very good default choices. If you choose Ember, you get: a CLI tool (ember-cli), a templating/rendering engine (Glimmer), a router, a persistence layer (ember-data), a unit testing tool (qunit), a server-side renderer (fastboot), etc. If you want to swap one of things out you can, but the default has great support. There have been some bumps along the way, but everything fits together and works.

By the way, the OP I responded to said "front-end", not "JavaScript". How does your attitude jive with WebAssembly which will allow you to compile C++ or Rust for the browser?

I've been struggling to understand how WebAssembly will change things on the web. Will you be able to compile an arbitrary C/C++ binary to run on a browser? Will syscalls be emulated? What about the filesystem?

It looks like to get such a thing working we would need an OS running on top of JS. But maybe I'm missing something.

There is clearly some sort of mapping available to a JavaScript FFI for doing I/O, as both the Unreal engine and Unity have been ported to WebAssembly. If you can run a video game engine in the browser you can run anything. I believe there are proposals in place as well to add opcodes to directly interface with browser capabilities rather than going through a JS FFI.

> If you can run a video game engine in the browser you can run anything

enlighten us

ok, assuming your request is not sarcastic:

- operating systems

- hardware drivers

- a networking stack

- trading algorithms

- fighter jet firmware

- ultra low latency DSP

- processing data from LHC collisions or imaging satellites.

- etc

just because webgl enables fast gpu processing (by basically writing a small subset of C that is shader code) doesnt now mean the web platform can be used for evetything.

The implication was applications. But even then, everything on your list is emphatically not true:

- operating systems

Ironically Linux was one of the first things to ever be compiled to run in the browser using empscripten.

- hardware drivers

Linux doesn't run without hardware drivers. In this case, the hardware drivers were wrapping JS FFIs.

- a networking stack

Yes you can.

- trading algorithms

Why not?

- fighter jet firmware

It's not a fighter jet, but the SpaceX Dragon 2 space capsule's UI is built using Chromium.

- ultra low latency DSP

Why not?

- processing data from LHC collisions or imaging satellites.

Why not?

You can emulate a network stack and hardware drivers, but your "network stack" can't directly send packets outside of HTTP/Websockets/WebRTC/etc. and your "hardware drivers" just emulate hardware that doesn't actually exist.

Trading algorithms, ultra low latency DSP, "processing data from LHC collisions or imaging satellites" are I think references to performance limitations. WebAssembly requires a fair bit of runtime checks (though some can be pawned off to the hardware if you're clever), and has a number of other quirks that hurt performance, like the fact that most languages end up needing two stacks when compiled for wasm.

The issue is even clearer when you move to processing large data sets because WebAssembly only allows a 32-bit address space at the moment. Add to that the lack of concurrency or native SIMD, and it's pretty clear it is way too early to dance on the graves of native executables.

Runtime checks don't stop you from doing heavy data processing or having microsecond-level response times. It seems like your objections fall into two categories. One is caused by it running in ring 3, which can be solved by correcting "anything" to "any user program". The other is moderate performance limitations that don't stop it from running full video game engines. Those may not be ideal but they won't stop you from running anything. Video games are among the most demanding things you can do in most ways. The single core of today is better than the multi core of a few years ago, and nobody claimed that those couldn't run all programs.

The memory limits will definitely completely prevent you from running some real-world programs. Programs that don't fold well into a single threaded event loop are also a problem at the moment (including Unreal/Unity games that use background threads).

Also, unless you definition of "can run a game" includes "can run a game at 3fps" I'm pretty skeptical that the entire repitoire of games for those engines can make the jump to WebAssembly today.

Concurrency and SIMD support are in the works.

I'm aware, but "If you can run a video game engine in the browser you can run anything" isn't exactly hedged on the future is it?

wish i had more time for the multitude of your generic "why not?"s, but i don't :(

any language (high or low level) that allows you to write and execute deterministic assembly or machine code can be used to implement whatever you want. whether WASM ever reaches this type of broad security-sensitive wild-west remains to be seen, but my money is on "never".

wasm will certainly expand into additional areas, but they will all be security-gated and will not have unfettered, raw access to all hardware (even with some additional user-grokkable permission model), because it has to run on the web: "W"asm

That's entirely addresed by "The implication was applications."

Nobody was trying to make a claim about web assembly drivers. Just applications.

A tool called Emscripten provides a runtime environment. You can include things from that, like a virtual filesystem. That said, a lot of WebAssembly code doesn't have a dependency on file APIs. For example, you can check out the web-dsp project: https://github.com/shamadee/web-dsp

If you're looking for an intro, I wrote a series of posts on WebAssembly (there are 5 links at the bottom of this intro): https://hacks.mozilla.org/2017/02/a-cartoon-intro-to-webasse...

> It looks like to get such a thing working we would need an OS running on top of JS. But maybe I'm missing something.

You're not missing anything, that's exactly what's happening. WebGL/VR, WebCL, WebRTC, Filesystem API... the browser is becoming a simple feature-rich client OS for the cloud, and WebAssembly is the machine language.

Reply on news.ycombinator.com