At least the next few years JavaScript will continue to reign in web browsers. Google tries to make Dart a new standard language. We are using frameworks and other programming languages that can be compiled to JavaScript. Imagine that you will have a real affect on choosing new standard web browsers language. Which one you will select and why?
Personally, I’d be glad if I could replace a JavaScript with Elixir.
In my opinion lots of features that was designed for current and future service requirements are as important in frontend code as in backend code. Supervisors and fault-tolerant, function guards, easy to write docs and tests and lots more. I’m really interested in elixirscript github project and I’m really wonder on using it in my further projects.
But … maybe you have other arguments for languages that will be better than Elixir in writing frontend code?
I’d choose some new variant of assembly. Webassembly is already mostly there, something that is easy to compile down to, like a variant of LLVM assembly or so as it is fairly easy to optimize.
@OvermindDL1: I heard something about it. If I good remember we can compile code from small list of supported languages (at least: C/C++). Do we have access to full DOM structure, styles and events? Or it’s only for C/C++ with OpenGL that is rendered like one element? If so which variant of assembly would you choose? C, secure Rust or other?
WebAssembly is just an assembly that is optimized in structure for browser compiling. A ‘module’ of WebAssembly is === a javascript module in the new javascript standard, thus for a browser to support WebAssembly it must also supported ECMAScript with modules. It is undergoing initial testing now, firefox and chrome are adding basic support, which does not include touching the DOM ‘yet’, however it can call out to javascript modules (and vice-versa) to do that work. However, by the time of version 1.0.0 it will be able to do everything javascript can do and more. So ‘right now’ no, but ‘when finished’ yes. It is not just for C++ at all, it is a generic back-end that you could even compile javascript to to save compilation time and JIT time in the browser itself. It is already quite a secure assembly, locked down hard (will be unlocked over time as proofs can be done to ensure security).
As for a variant of assembly, well LLVM is already an immutable and type safe assembly, I’d choose it (consequently LLVM compiles to webassembly pretty directly already. ^.^
So yeah, WebAssembly is coming, and once it is out you will be able to use pretty much any language you want on the web, and they will be able to call each other through what each expose via the module system.
Also, C, secure rust, etc… are not assembly languages, they are too high level for this purpose.
WebAssembly is so exciting. The time of a more performant and rich web platform is near!
Not just those, I believe. You can almost use anything as long as it can compile down to wasm. The WebAssembly demo page features a playable Unity game directly from your browser. Since it’s Unity, I suppose it’s written mainly in C# or JS (CMIIW), which is as high-level language as it can be.
As @OvermindDL1 said, assembly is on a lower level than these languages. Taken from the example, here’s a wasm code in text format:
It’s possible, but I think the question then is what you’d hope to gain from it?
Hmm, an idea, with emscripten it is ‘already’ possible to compile the BEAM (single-threaded) to run in the browser. Would be interesting to wrap workers and everything to do multi-threaded things. ^.^
The only thing anyone would gain out of it is the feeling of being comfortable writing in a syntax that is familiar to them, Instead of ruby style syntax ( Elixir) you would have something else for JS programmers who are too lazy to learn Elixir or Erlang.
The main reason I’ve decided to take up Elixir is to learn an alternative to node.js style callbacks (Erlang processes) and to leverage the Erlang environment.
Yah, I pretty much share this perspective (while not being very knowledgeable about LLVM in particular). I think giving developers the freedom to choose whatever language/toolchain deemed most appropriate for the given domain/application, and compiling it down into something like WASM is the best route.
As much as I have loved my journey with JS over the years, I wouldnt mind if it just disappears someday soon
Also +1 for elixir in the browser / “elixirscript”
As has been said by everyone else, webassembly or another assembly like language would be an excellent long term choice for web development as it eliminates the expensive step of compilation when javascript is loaded. So for web development webasm is probably the future.
Now that being said, I can imagine that if webassembly gains sufficient support we may see webassembly VMs for running applications that are not in the browser, but rather for everyday use like normally installed applications. Perhaps in the future webassembly would serve as a common compilation target for almost everything, sort of like what Java was thought of as but far more expansive. A universal target that runs on almost all devices, giving you consistent results during development.
Unpopular opinion: Web Assembly will explode the complexity of frontend development. At least now the uniting factor is [ultimately] Javascript, as flawed and hated as it is. With WASM in wide usage there will almost be no transferable knowledge between companies when a frontend dev decides to move jobs. Some will use Dart, others Clojure, others OCaml, then Elixir, F#, C# even, etc. Everybody will evangelize their own language that compiles to WASM.
Even if a good decompiler is introduced in an effort to have a common dialect – to convert WASM bytecode to a readable vanilla Javascript – many devs won’t know Javascript just a few short years after WASM becomes mainstream, and thus a decompiler would be ultimately pointless.
IMO let’s just have two languages – one imperative and one functional so both camps are happy – and only have WASM compiling target for those. But then people would go to war to decide which two…
I don’t think that’s necessarily a bad thing - hopefully the best will emerge and become the most used, and similar to what you said, there would be a good handful to choose from which should hopefully accommodate most people’s needs and tastes
Well yeah, but we have been hoping for that ever since the first programming languages were invented.
The IT world is divided enough already. I fear WASM will only make things worse ultimately, knowing us the humans and our love for conflict and cargo-culting.
Here’s hoping that I am grumpy due to staying one night at a hospital and I’m just being too pessimistic.
Already quite a few for a few different languages actually.
Plus WASM’s IR is pretty readable as it is. Kind of Lisp’y.
Don’t forget that different WASM modules made in different original languages can talk to each other all through the same interface though, like the C interface on the kernel, but slightly higher level.
They can talk to each other theoretically, if people bother to try and reuse. To quote OOP’s critics: “When was the last time you really reused a base class in another project’s object hierarchy?” They have a point.
Don’t get me wrong, I like the idea a lot. It could not come quick enough. I just fear a huge divide in the frontend community. But maybe the hiring practices of the tech giants will reduce the camps to 5-6 instead of 50-60.
Well, what I meant is that us the programmers suffer from the disease I’d call “I am the smartest of you all, you will never catch me reusing other people’s code alive”… So while many languages and runtimes provide very good ways of reusing, IMO they are used much less than they should be.
You worked with better programmers than me. I envy you!
Not the same though, that’s a need you and others have because they cannot manage by themselves. In corporate setups people keep reinventing wheels several times a week, believe me.
Eh, not my experience either (Xerox and so forth), where the other programmers tried to shim EVERYTHING into existing libraries, even old Perl XML libraries on modern systems to broken Java libraries generating broken code, none of it made internally, it was horrible…
