Hacker News new | past | comments | ask | show | jobs | submit login
Web Assembly and Go: A look to the future (brianketelsen.com)
329 points by rch on June 23, 2018 | hide | past | web | favorite | 208 comments



Hello - author here. Just wanted to point out that this isn't a new framework, it's a proof of concept that existing GopherJS (go transpiled to javascript) apps can run in Go/wasm with little or no modification. Any future work in this area will hopefully look & feel more like Go and less like something else.


I'm intrigued why would you pick Go, out of all languages out there - or conversely, why would you pick React and Redux as the UI model to emulate when using Go.

Go is an unapologetically structural language, which eschews both most OOP and Functional Programming patterns.

The Redux model, on the other hand, is strongly rooted in functional programming, and demands immutable data structures, something that is quite hard to do with Go. You would have to deep-clone every map and slice, which is extremely cumbersome and error prone in Go.

Or perhaps you could just create a mutable store (this is what the TodoMVC does), but then you lose all the advantages of Redux like predictability, reproduceability and the time-travelling debugger.


(Author of the framework, Vecty, here) Also happy to answer any questions anyone has. =)


Why is WASM a less complicated stack than, say angulartDart, flutter and Firebase?

IMO it seems like a step backwards, even if it’s better than JavaScript.


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.


One 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?


With 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.


Simply having an open codebase is not enough to promote diversity in implementation. Sure, you can get an exact clone, but if there's a piece of the code you don't like or want to replace, it's going to take a large team and likely a few experts who worked on the original to get through it. And through all of that, your codebase is just falling behind what teams of hundreds of engineers are doing on the upstream of your fork.

If the major browser vendors today team up and decide to implement something people find hostile, say strict DRM, there's not much the world can do to stop them. It's just too much code to work through if you make a fork.


"If the major browser vendors today team up and decide to implement something people find hostile, say strict DRM, there's not much the world can do to stop them. It's just too much code to work through if you make a fork."

It's probably very hard to quantify how lucky we are that Mozilla exists as a non-profit. They aren't perfect, and they don't have the weight to directly oppose Google and Apple even if they had to, but they have a seat at the table, and provide a viable alternative for those that want it.


For example, most likely Dart or NaCL would have had another outcome.


A 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.


The 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.


But 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.


We 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.


Problem: The Javascript landscape is too fractured and complicted. There's too many different frameworks and technologies that can be used to write front end code. There's no way I can be expected to know all of them.

Solution: Let's make it so anyone can write front-end code in any language they want!

Personally, I just don't see how that makes sense. It seems allowing all these different languages to be used to write front-end code just creates more of a mess. Before you at least knew a front end project was probably written in JS, now... who knows?

Maybe WASM will catch on and what it means to be a front end dev will change to be more language based, but that seems like it would create its own problems. Most devs I know that want to write in Go and C don't want to fuck with HTML and CSS.

For the record, from what I understand WASM offers from pretty big performance boost over JS and I think that is really where it will shine. I think the ability to bring really high performance applications into the browser will be the bog selling point of WASM.

That being said, I don't foresee a future where every brochure website and online restaurant page is written in C or Go and compiled down to WASM. I think people who are excited for WASM because they don't want to learn Javascript are going to be really disappointed in it's adoption rate over the next few years.

IMO, WASM is an awesome new tool to add to your tool box, but not a technology that is going to change the development landscape as a whole.


(disclaimer: Author of Vecty here, the toolkit being used by OP)

I can see how you came to that conclusion, but I'd offer a different perspective.

The problem in my opinion with the Javascript landscape is, as you said, the fact that it is too fractured.

If you follow the "modern best practices" to make a SPA, you are talking about pulling in at least: npm, webpack, react, react-router, lodash, redux, bootstrap, and perhaps much more.

You are going to need to set up each one of these to play nicely with each-other, and follow tutorials/guides for each one to get them set up before you can even begin to start writing code for your actual application. Just look at the getting started guide for webpack to see how complex this can already be [1].

Why can't there be a consensus on what tooling/libraries are "standard" for writing an SPA React application today? Setting up the above tooling/libraries should not take multiple hours for someone with no frontend experience, but it does.

There are "starter kits" [2] to try and solve this problem, but dear god just look at how many moving parts they already have!

---

My overarching point is this: the Javascript ecosystem does not seem interested in solving this issue ultimately. This fractured-but-whole approach to development seems to be the consensus for that ecosystem. And that's OK.

For a majority of non-frontend devs who would like to enter the frontend, though, it's not okay. And this change in mindset is what WebAssembly can bring. It brings a different ecosystem and a different set of people with diverse mindsets that you just can't find today in the JS ecosystem easily.

[1] https://webpack.js.org/guides/getting-started/ [2] https://github.com/kriasoft/react-starter-kit


I'm tired of the 'too fractured' trope. Backend programming is too fractured too then- should I use Java? Go? Python? Rust? What database? What build system? What CI system?

Frontend is massive, why would one suppose that a single solution would work for everyone?

Horrible metric, GitHub stars:

- 104k React

- 58k Angular.js

- 43k Go

- 42k WebPack


For back-end programming, once you pick up a language, you use its standard set of tooling like you would for every other type of program and by making a choice of language, you can select the style of programming you prefer, (functional, OO), or tap into your existing knowledge.

With JavaScript, it is the only choice available, so if you want a different style of programming you have to involve all kinds of additional tooling in addition to the language's native tooling, on top of having to involve JavaScript's tooling, frontend package manager, backend package manager, transpillers, babel, gulp etc. etc. it's just a mess, not really comparable with having to invoke Bundler or Cargo for the backend side of things.

> Frontend is massive, why would one suppose that a single solution would work for everyone?

The problem is that JavaScript is the single solution that essentially has to work for everyone right now, hence the push for WebAssembly.


WASM solves a set of problems orthogonal to most JS use though.

It doesn’t touch the DOM and there’s a VERY good reason for that.

To which most advocates end up saying that’s because the DOM is bad and should be scrapped. Maybe, but now we have put the cart firmly so far in front of the horse that’s is a few days ride away.


> It doesn’t touch the DOM and there’s a VERY good reason for that.

Yes, because they haven't gotten to it yet and wanted to release the MVP without that functionality. But that feature is coming (hint: it's called host bindings), so implying that there's some other reason why DOM access from WASM wasn't added is pretty disingenuous. Once that feature and garbage collection arrive in WASM, there will be almost no reason why JS needs to be used on the front end.


Right, but the core reason they’re doing it that way is that it is a hard problem to solve practically speaking (rather than theoretically) without tanking perf.

Which it will anyway so WASM devs will end up having to be just as careful as JS devs about DOM & UI manipulations or run into the exact same problems.

At which point (the the same problems and issues) there’s really no reason to use anything other than JS for that portion of the application.

WASM is great, but it’s going to be for the parts of the web that JS is not good at dealing with - and that’s less than the crowd here on HN would like to believe.


> hard problem practically (rather than theoretically)

Err...actually, the theory is hard, and that is a practical problem, because the WASM people actually wanted to have a formal semantics for WASM from the get-go.

That's why they're moving slowly, only releasing what they can specify formally.


Javascript is a horrible language, this by itself is a good enough reason to use something else to a lot of people out there. I think the number of programmers who are currently doing JS but hate it and would jump to something else the moment it becomes viable is enormous.

Then there is also the issue of the proliferation of substandard JS programmers, a lot of them knowing nothing about basic CS principles, that are viewed as "necessary evil" today. Opening up that space to better programming languages will be a net gain on many fronts.



Yes, I’m very familiar with host bindings.

Are they here yet? No. Are they performant yet? No idea because they don’t exist.

They’re always brought up by WASM advocates like they solve anything. But they don’t... because the problem isn’t accessing the DOM - it’s doing it performantly in your code and there’s nothing about host bindings that hint they’ll solve that problem any better than JS. So far the signs aren’t positive.


> Are they here yet? No. Are they performant yet? No idea because they don’t exist.

Right, they're not here yet, so you don't know.

> because the problem isn’t accessing the DOM - it’s doing it performantly in your code and there’s nothing about host bindings that hint they’ll solve that problem any better than JS.

WASM solves the problem of allowing languages with different semantics, strong type systems, different paradigms etc. that JS doesn't provide. Some of us care about the language we program in because we want to have somewhat enjoyable experience while doing it and for some JS does not provide that. That is the problem WASM solves. Whether host bindings would give us sufficiently fast access to the DOM isn't clear yet, as you yourself admitted, but I don't see why not and I certainly don't see what you're arguing about here - the problem WASM solves is, again, primarily not about DOM access that is somehow faster than JS, people are even expecting a bit of a penalty, at least initially, but as long as we can get rid of JS monopoly on the front-end, I think WASM achieved its goal.


> Right, they're not here yet, so you don't know.

And neither does anyone posting dumb links to Reddit posts about them or mentioning them like they’re a solution.

Because they aren’t. They might be, but they aren’t yet. Yet WASM advocates like yourself treat them as fully formed solutions to criticism.

Which you kind of have to I suppose: without them WASM is a cool but extraordinarily limited and mostly pointless, outside of some specialized use cases, toy.

Until they are released AND up to par with perf & features (inc accessibility) WASM hasn’t achieved much at all. It certainly hasn’t got rid “of the JS monopoly”. No more than VBScript or Flash did.


> And neither does anyone posting dumb links to Reddit posts

As far as I can see, the person who posted the Reddit link just responded to the claim that there's no way to manipulate the DOM as a way of saying that it is known and being worked on. You seem like a bit of an extremist by saying that anyone is claiming it is the solution. It is a potential solution, that's all.

You were the first one to assert what problem WASM supposedly tries to solve, even as not everyone agrees with your assertions. You basically set up a strawman and then shot it down.

> Yet WASM advocates like yourself treat them as fully formed solutions

I, in fact nobody here apart from yourself, has said that they're fully formed solutions, not even close. They're in development, this is not being denied. I am also not an "advocate" for WASM, I made a post explaining why I think it makes sense, that's all. When somebody tells you they like rain, do you respond with "So are you advocating for floods"?

> Until they are released AND up to par with perf & features (inc accessibility) WASM hasn’t achieved much at all. It certainly hasn’t got rid “of the JS monopoly”.

No one is saying it ALREADY DID, we're saying this would be a success, if it did. This is really not that hard to understand. Honestly, I am not sure it's the Reddit posts that are the problem here.


WASM is treated like this God like abilities. I’ve spent time playing with it on and off every couple of months.

Sure you,ll be able to port different languages to the web but at what cost? The JavaScript library gives a ton of things out of the box. In WASM land one will probably have to compile their standard library of features and send it to browser. So space wise it’s going to be more.

Then you have the debugging problem, browser venders are doing some improvements in this space but seeing how quirky being able to debug minified code is, WASM debuggers will be interesting and that story is weak.

The reason why JS ecosystem is vast is because frontend development is vast. Creating UIs involves a lot of things. Add different browsers to the mix and you get this complexity because different versions of browsers support different things.

To this day you can always create something in Vanilla js. A single .html file with js and css embedded in it. Nothing stopping you. You need nicer tools and libraries when you want to scale the development. This is true for any language.

JQuery - started out as a way to abstract our browser backwards complexity and give standard api. It essentially is a polyfill library with a nicer syntax.

Angular - A nicer way to compose dynamic apps. They piggy back on html syntax and bring templating to it. Same with Backbone and Mustache. Just other libraries.

React/Vdom - View is a function of state. Another way to think about UIs. They bring html to JS with h(tag, attrs, children) calls. This makes building big dynamic UIs easier.

Babel/Typescript - Some browsers support new things, older browsers don’t. A tool to let you write in newer flavor of JS that down compiles to an older flavor depending on what you want to target. Typescript is a way to get more strictness in your code (like a linter). Sure we can get into a way on how Javascript is an aweful language but there are some things it does really well. I love 2018 JS.

Webpack/Rollup - you can ship a giant .js file with all things concatenated but that’s not optimum. You want things to load fast and this means less bytes on the network. Webpack allows you to write code as small modules that depend on each other. Then you give a starting module and it builds you a js and css file with things you need. You can control how things get bundled e.t.c. This is like creating an installer for your app.

In essence, web ecosystem of libraries is vast because the web ecosystem itself is vast. Little libraries let you pick and choose how you want to stack things up to build for your needs.

WASM is a small part of this vast ecosystem solving a specific kind of problem. We’ll still have those 99 other problems.


Seriously go has 43k stars? Either I’m missing something or software development commoditisation is much more extensive that I’d have thought possible...


The backend can also be too fractured. Isn't that one of the reasons why people pitch Node.js for backend applications? "Write in one language, reduce fracturing"?

I would not argue one solution fits all. I think having the ability to write frontend+backend in JS _and_ Go is a good thing.


It could actually very good for productivity for teams who use other languages in the backend.

I mean, I bet that as soon as possibile all the c# consultancy companies - just to pick a common example of big teams using a single language for the backend systems of all the projects of the company - would switch also their frontend to c# when it is supported by all major browsers


Best practice is to use a zero-config build tool like create-react-app or angular-cli. Or a next-gen static site generator like GatsbyJS. From the developers point of view this is one moving part and one devDependency. I think your assessment of the SPA ecosystem is out of date, it has stabilised hugely in the last few years.


Interesting! Thank you for mentioning that. I think that does resolve a lot of the problems I have mentioned, but it is still telling that I've tried to start two React SPAs in the past two years and didn't manage to find create-react-app. I wonder how many others are in the same boat.


It's right there in the official tutorial: https://reactjs.org/tutorial/tutorial.html#setup-option-2-lo...

But I think it wasn't this easy 2 or 3 years ago.


It depends on how long ago you last tried to make a React app. If it was recently, I'm quite surprised you didn't find it as it's heavily mentioned on the official React site, but if was say earlier than a couple years ago, that would be understandable.


create-react-app or similar tools work only for toy projects , in the end you are forced to learn how things work under the hood, this includes all the automagic tools, eventually something goes bad or you need to change something and you are forced to go dig and look at the code.


I'm a senior JavaScript dev and consultant - we ship create-react-app and angular-cli apps to production frequently, having to eject and dig into the build process is the exception rather than the norm. The win for keeping things zero-config is so huge, its worth working around some of the restrictions.


I assume that most senior developers in the team had to learn all the components used and how they work, you can use npm without knowing what package.json is but you will have to learn the details eventually, if you use gulp you will have to learn how to edit the gulp file when you need to do a specific task,l you probably had to learn what source files are and how to set them up and others. If you do not know this eventually you will have to learn them.

Other platforms have similar magic, like Visual Studio hides complexity from you but on complex projects or weird issues you will have to learn how it works under the hood(compiler, linker , compiler flags, you may want to drop the GUI for building and use the CLI for flexibility)


I fail to see how Go would help to solve the lack of complexity.

You would still need a package manager.

You would still need a view library (React), a router (react-router) and some sort of model or storage (Redux). React originally took a mix-and-match approach, but other popular frameworks like AngularJS and vue.js tried to bundle everything together.

You might also need a style library (not necessarily bootstrap nowadays) or create your own styles from scratch.

And you will need an bundler like Webpack or Browserify, unless you want to make your own with Gulp/Grunt (like people used to do).

You may want a collections utility library such as Lodash or Ramda, though many people go without them nowadays.

Let's so how go would fare here:

There's a new view framework (Vecty) which could eventually grow to bundle its own router, standard components and store (just like the more mature Angular and Vue).

Store, Router, UI components and Styles: MIA?

There are at least 6 widespread competing package management mechanisms: go get, vendored dependencies, godep, Glide, dep and vgo. Hopefully the community will standardize on something (vgo?), but for now, npm and yarn look absolutely fabulous compared to the mess we have to deal with in Go.

Bundler - could possibly be obviated by WebAssembly, but we would need something else that matches what's currently being offered by Webpack (e.g. live reload).

Collection utilities: Fear not! The lack of generic makes it impossible to do with Go, so you'll just have to write boilerplate code.

(The reasoning that a language with a good standard library can obviate the need for Lodash is correct though)

---

My point is that you'll just be getting the same thing again and there is no guarantee you will have a more consolidated standard with Go. The Go community rarely tends to unite around a single solution, unless it's coming from Google.

If you are looking for a language that gives you a single story and a bundled set of tools for doing everything above, there's already one: Elm. And it's been here for quite a while, and still most frontend developers chose Javascript and React, even while they imported Elm's reducer-based data flow model to React (as Redux).


Go already has a built in router in it's standard library, sure it's more targetted at the server side, but extending to the client side wouldn't be a huge effort.

With gowasm you don't need a view library, the "view" library is Go, you can choose to use Go's templating if you want, or you could use a more idiomatic Go system of interfaces that implement a view, with different implementations of those interfaces for different components of your single page app.

With storage Go offers either client side with HTML5 local storage, or backend with simple map[]s for temporary in memory storage all the way to full blown SQL / NoSQL or even distributed decentralised raft options like tendermint. Go offers a much wider ecosystem for storage (client and server side) than even the best JS offerings.

Bundlers / Collections are a red herring in the golang world, golang generally uses monolithic binaries (that tend to be statically compiled where possible) and then use networking to talk between them as a mirror to goroutines and channels internally. golang's package system along with it's tooling (go run vs go build/install) handles "bundling", it's done by the linker / compiler; linking is a well understood problem.

Styles is something that golang would never attempt to handle, it's a CSS thing. Sure there will be libraries that 3rd parties will write to interact with style frameworks (like bootstrap et al), but you just as easily handle that in your own view interfaces.

golang does have a standard vendoring system, true that not everyone uses it; maybe one day it will converge?

And it is very unlikely that go will ever have generics, go has an idiomatic way of handling that with interfaces; probably not everyone's cup of tea, but there it is. You can live without generics.

A lot of the way that Go handles these various issues runs against the grain with a sizeable portion of the programming community, there will always be other options. Ask 10 developers get 11 opinions.

The biggest takeaway though is that WASM is opening up the browser programming interface to more than just JS and its plethora of libraries / frameworks / solutions.


> If you follow the "modern best practices" to make a SPA, you are talking about pulling in at least: npm, webpack, react, react-router, lodash, redux, bootstrap, and perhaps much more.

I wouldn't call that best practice, more like the hype train. All you really need, at a minimum is a text editor and jQuery. Once you're comfortable with that, you can move on to the more fancy stuff.


That's true and definitely the fastest route to take - but if you were to tell me I was going to take over maintenance of a JQuery project at this point, I would be visibly upset. After working in an environment where two-way databinding is "free" and some measure of type-safety is available, it's hard to go back. I just have more drive to work on projects where I don't need to manually wire up every onChange event under the sun and coordinate data-flow through some observer. Not if I can help it.


JQuery is a low level DOM library, so "JQuery project" in reality is an SPA thats built without any kind of architectural framework. You can just start with jQuery and build a maintainable, robust SPA on top of it - if you had the time and resources. Infact, frameworks like angular started out with having "a light jquery core" which they then built on top of.


> some measure of type-safety is available

I haven't done it, but I'm fairly sure you can use jQuery with Typescript


> to make a SPA, you are talking about pulling in at least: npm, webpack, react, react-router, lodash, redux, bootstrap

NPM and Webpack are developer tools, and Bootstrap is a CSS framework. Correct me if I'm wrong but WASM still needs CSS since it generates HTML

As for the others, they're libraries. Optional libraries. There are plenty of optional libraries in the Go ecosystem but we wouldn't say it's "fractured". You can't format a string in Go without importing a string library, but this is acceptable.


> Correct me if I'm wrong but WASM still needs CSS since it generates HTML

Yes, you are a bit wrong. Wasm can also mostly sidestep html and css and write to the canvas directly. Some games compiled to wasm do this. You can imagine that in a near future, it will be possible to use the browser merely as the wasm vm which will run and render your crud written in, say, tcl/tk


Fair enough. I was going off the linked article in which he generates html in Go. Tcl/tk is cool, but wouldn't you have to import it just like bootstrap?


I used tcl/tk just as an example and because i love it :) But you could say the same about gtk, qt, etc. Or flutter. And yes, you would have to import the libs and some libs are not small, right? But this is also a problem that we face nowadays already, where the stack in a typical "modern" website requires the download of css and js frameworks that often weigh more than one megabyte of code. Maybe once wasm is popular enough, the web browser will start shipping common stuff like libc when you install it? And then it would start resembling an OS instead of a VM. I don't know if I like this idea, but it seems to be the direction we're heading to. We started with the browser being a system to access documents that can link to each other, and at some point a scripting language was introduced. Over time, it started being used as a application distribution plataform. Then people realized that maybe bending the scripting language to achieve that was becoming too much, and wasm was born. Now the browser is a VM. Soon we'll find out that we don't need a VM, but a distributed OS instead. And maybe we will look again at what Plan9 already did in the 80's.


JS and CSS libraries can be cached so that in theory you only need to download it once for several apps. The large file size with Js apps is more commonly the app itself, transpiled for older browsers using Babel. That makes for some massive code. But changes are coming. Webpack can compile separate versions for es6 compatible and incompatible browsers so only IE need download the monster Js file and chrome and Firefox can have light code of just a few hundred kb


The reason the solution doesn't seem to fit the problem is that lots of developers don't think the problem with front-end web dev is tooling/framework complexity or overdiversity.

Instead, they think the problem is stuff like:

* developers are not using enough of the design pattern lore developed for use with static manifestly/class-y typed languages like Java

* JavaScript is terrible because you have to think about `this`, because wat, because prototypes, because the aesthetics of another language are better, etc

* mutability or missing functional purity

* the type system isn't type-y enough

* CSS is terrible

* how do you know if you're a real developer if there isn't a build step

* do you even modern bro

And you can route around these problems by switching languages. WASM to the rescue!

I suppose we'll get the chance to find out to what degree those are really The Problem With Development.™


I always characterize it as “the problem with web development is that it doesn’t work how my favorite language works and UI is easy anyhow, lol”

... and, while that is a slightly unfair characterization, I’ve seen many arguments that can be boiled down to that without losing any nuance right here in HN.


yeah. I love Go and I enjoy javascript. For completely different reasons, and many of the things I love about Go I hate about JS, and vice versa.

It's either an incredibly minority viewpoint, or an incredibly silent majority, though. I think partly because it neatly divides along Static vs Dynamic religious war lines.

I'm going to be really interested in writing some front-end code in Go, just like I was interested in writing some back-end stuff in Node. But I have the feeling that I'll quickly revert back to writing the backend in Go and the frontend in JS. Not out of tradition or tooling, but purely because they've been designed/evolved as better languages for those roles.


My background is strongly typed languages and I’ve been doing it for almost 30 years. I recently built an app in js/vue and I loved it. JS is incredibly powerful. I never really enjoyed writing a bunch of scaffolding anyhow.


The problem wasm addresses has nothing to do with the fractured state of javascript frameworks. It's about turning the browser into a virtual machine for performance reasons and started with asm.js.

The fact that it allows using variety of different language, rather than Javascript, a language which wasn't exactly designed for what it's being used for today by Brendan Eich, is a nice side effect.


Why should web front-end be any different than the rest of software development? There's much more diversity on the backend than there is on the front-end, and nobody complains about fragmentation.

Whatever works.


Because it's wise to not put too much complexity on browsers which in the end have to process and parse all inputs from front-ends. While on the rest of software development (e. g. desktop applications) you're mostly free to decide if you install untrusted code or not, the web only works if you allow untrusted code to be executed on your machine.


I've seen so many comments and articles over the years viciously bashing PHP, then within PHP itself, there's atleast 100 different frameworks, and the same bashings going on - just ask a drupal dev what they think of a wordpress dev. And this is just within PHP; there's still python, .NET, java, ruby etc to talk about..


So your solution is.. everyone sticks to JavaScript?


For front-end development? YES


You're already hinting at why it doesn't make sense to you:

> from what I understand WASM offers from pretty big performance boost over JS and I think that is really where it will shine.

That's exactly the problem WASM was designed to solve. It wasn't meant to solve the perceived problem of a fractured development landscape, it was meant to achieve near-native performance on the web.


I don't care what programming language a native program is written in, why should I care what web applications are written in?

As long as modules written in different languages can call into each other, having a broader choice of programming language is a good thing.

I think the majority of 'application style' webpages will have their core parts compiled to WASM from a language that also compiles to native machine code (for the 'native' version of this app -- actually native, not running through Electron that is), and the glue code and HTML UI scripting written in JS (or another scripting language that compiles to JS).


"Before you at least knew a front end project was probably written in JS, now... who knows?" => Not really. Don't forget about CoffeeScript, Dart, TypeScript, ScalaJs, Fable, ClojureScript, etc


>There's too many different frameworks and technologies that can be used to write front end code. There's no way I can be expected to know all of them.

Why would you need to know all of them? Did you need to learn Fortran before you could start making things in Java or C++?


My unfounded prediction is WASM used to rendering to canvas, bypassing DOM completely, more or less separating the front end from the browser.


Think of WASM like you think of assembly code for the desktop. C, C++, Delphi, etc....All with their own libraries and frameworks to do the same thing...namely, not write desktop apps.

a common compile target makes it easy for developers and companies. Languages and frameworks should never be the common denominator for solution building because it is inflexible.


wasm is not just about using other languages in the browser, it allows you to reuse many different libs that are well-written in other languages. For example, in my company, we compiled ffmpeg in wasm so that people can actually edit videos in the browser.


I think the advantage of wasm (at least eventually) will be for people who know c++ or rust or go and want to make web apps without having to learn a whole new ecosystem.


There are a lot of people out there that don't want to deal with Javascript or (worse) Node.js. since they consider them to be abominations. Life is too short to be spending it in these environments.

Web assembly will finally give them a way to do clientside development while avoiding the total disaster that is the Javascript ecosystem. I don't do clientside programming but as a scientist I'm -- very annoyed -- that we have settled for something as bad as Javascript, whilst better languages are languishing.


Interesting... Those of us who thought "web technologies" have reached the peak of absurdity were proven wrong. Again. Never underestimate the power of human creativity! :) But seriously, I believe the cycle is over now. The darkest hour is just before the dawn :) Something much simpler will come up, like JSON at the peak of "XML revolution"


> todoList.Root.Set("innerHTML", string(newTree.HTML()))

Using examples like this are really unconvincing when it looks like old jQuery or vanillaJS. Yes, I appreciate that folks like whatever they are familiar with and JS is not elegant, but web assembly doing old school DOM manipulation, but now in N number of different languages sounds terrible for maintenance.


Criticizing a language that just got wasm support last week for not having mature high level solutions yet is a bit ridiculous.


Wasn't exactly my point, it's the criticism of JS the language and the tooling, but then just repeats the same difficult to maintain approach seen in a lot of JS, but now in a new language and even more tooling


This is what exploring the envelope looks like. New wasm stuff is going to look like hot garbage until new sets of abstractions and new conventions start to shape up. There’s a lot of ground to re-explore and re-cover before wasm starts punching at its weight.


You know something has to perform low level DOM operations, right?


Sure, but I was under impression that it's best left to the C++ the browsers are written in?


The browsers written in C++ are not doing DOM manipulation, they're providing the DOM abstraction itself.


Using innerHTML kind of is leaving the DOM manipulation to the C++ the browsers are written in!


Using innerHTML is leaving the DOM manipulation to the C++ the browsers are written in.

Using createElement is leaving the DOM manipulation to the C++ the browsers are written in.

Using HTML is leaving the DOM manipulation to the C++ the browsers are written in.

Using your framework (react/angular/etc) is leaving the part of the framework thats using innerHTML/createElement to leave the DOM manipulation to the C++ the browsers are written in.

Whichever path you take, the browser must do some DOM manipulation to render anything.. because that is what browsers are built to do.


You'll see much more mature looking code once Web Assembly Host Bindings [0] land. Until then, using non-JS languages require crossing the WASM-JS boundary to manipulate the DOM. There's a performance penalty to that, so it makes sense that current solutions create a massive HTML blob and send it to JS to inject as innerHTML. That doesn't mean those languages are repeating JavaScript mistakes, it just means that there's still a technical barrier to doing it correctly.

[0] https://github.com/WebAssembly/design/issues/1148


Those are some good points, but it looks like the author is mostly just injecting a React-like framework into the root element.


Ah thanks, I missed that


At the end of the day, if you look under the hood of your favorite front-end tech stack, its doing the exact same thing. Everything end up as vanillaJS with ugly DOM manipulations, all your framework does is hide those details for you, so you can work and think on a higher level.

So if you're building an application, use those frameworks. But if you're building the framework itself, innerHTML is your friend.


Great article! I attempted something very similar and wrote about it here: https://matthewphillips.info/programming/wasm-golang-ce.html

Like the author I'm pretty enthusiastic about using Go for web development. The interop story is quite strong.

My biggest concern is the binary size. 1.3mb for what is essentially a hello world. Given that Go needs to include garbage collection I'm a tad worried they won't be able to cut down the size enough to make it worthwhile to use.


Sadly, 1mb is not that big for web pages lately. So that could be competitive with a js stack for some apps.


This is changing, I (think|hope). Two years ago I was building 1MB+ sites (because: SPA). Now I am down to 500KB, due to SSR and code splitting. Performance is back on the menu.


I think some very simple (tens of loc) Go programs I wrote ended up compiling to Linux binaries of about 5mb.


This can be the case, depending on imports(looking at you, fmt). But it doesn't scale that way, I assure you. So you may hit 5 to 8mb early on in building a basic 100loc webserver. Then at 100k loc you can be looking at 10mb. I've found most of our rather large webservers unoptimized, to be in the 10 to 15mb range.


There have been talks of adding a GC to WASM for a long time, so there's hope yet


I believe there's been some debate within the go team as to how well a non-go GC would work with go, as the current GC is pretty tuned to the quirks of go (go routine stacks etc.)


libc is not tiny either. Try compiling helloworld.c using gcc with -static option. You get a similar size. I don't use Go much but I recall comparing binaries and a Go binary was about 200k larger than a binary from gcc compiling C.


glibc cannot be linked statically.[1] Compile hello world against musl libc with -static and you get an 8kb binary.

[1] https://sourceware.org/glibc/wiki/FAQ#Even_statically_linked...


Here's another link which compares musl, uClibc, dietlibc, and glibc sizes, features, and performance.

http://www.etalabs.net/compare_libcs.html

It says musl's smallest static C program can be 1.8k as opposed to glibc's 662k, showing libc doesn't always have to be big and bloated.


Neat! That was my original hope, to move down the component path, but I got nerd-sniped by how well everything worked and started playing with making existing gopherjs apps work. Great article.


Will webassembly allow for shared code so, a framework might be cacheable and each app does not need to package the whole thing? Did I just ask for dll hell...


Worth bearing in mind that hopefully a lot of that will be runtime overhead, so it won't scale linearly with the size of your program.


That's great, but 1.3mb as a baseline is just too big for most common DOM manipulation type of use cases. You want your UI drawn within a couple of seconds or the experience becomes bad. Even if they were able to cut it in half I'm not sure I'd be comfortable using it. I'd really want to profile and see how fast you can get to interactive using something like this.

Now for heavier applications like graphics or video editing, this would be fine to use.


I don't know, if your making a LOB app. It's a one time hit just like installing an app. It might not be that big of a deal. If you us it for your mobile website, big trouble.


> When I look at modern web development I shudder; the ecosystem is so confusing for someone who has been out of touch as long as I have. Node, webpack, yarn, npm, frameworks, UMD, AMD, arghhh!

I agree overwhelmingly with this sentiment. I've been working with JavaScript on an almost daily basis for about 20 years. I very much dislike the new JavaScript environment, it's an atrocious monster of unnecessary complexity (and getting ever worse). Just because things could be done, thanks to dramatically faster JS engines, they were.

The product I'm building now: vanilla JS. No npm, no packages, no package managers, no node, no jquery, no react, no vue, no angular, no webpack, no yarn, no frameworks, no polyfills, etc. It's not even using ES6/7. It's gloriously fast, simple, extremely small in size, universal and nothing more than absolutely necessary. Sub 50kb page sizes, 5x faster load times than Quora or Wikipedia, 20% as many requests (the typical Wiki page makes three dozen or more requests), while still accomplishing everything required for the project (it's a knowledge service).

Push these simple pages through a performance checker:

https://www.quora.com/What-made-George-Washington-a-great-Pr...

https://en.wikipedia.org/wiki/Jack_Dorsey

You'll see 38 requests for Wiki, and 49 for Quora. The simple Quora page has 500kb of scripting junk bloating it and 180kb of css, leading to 1000ms load times. And these are largely considered good outcomes today, that's with billion dollar organizations spending huge sums of money to speed everything up. Oh, the page only has 1mb of unnecessary bloat? A tremendous outcome.

Fuck the new bloated JavaScript and Web dev ecosystem, it needs to crawl back into the hole it came out of and die. There's a better way to build, and it's not by adding vastly more complexity to accomplish the same thing we used to with 5-10kb of JS.


Completely agree. Though I'm curious on how you made vanilla JS universal -- how much duplicate/messy code was necessary for cross-browser and platform (mobile) ?


    Node, webpack, yarn, npm, frameworks, UMD, AMD, arghhh!
Yes, the way most web developers click together their project these days is a bloated mess. But Web Assembly is not a solution to it.

Just use a leaner stack to output your html+css+js. Throwing Web Assembly into the mix is not going to do that for you. If anything, your stack will become even more complex.


That is the only way Web will ever catch up with native, by becoming itself yet another generic purpose VM platform.

In the process it will be the revenge of plugins.


The web already is 'generic purpose'. Outputting JS or WA does not make any difference in that regard. It just makes things a bit faster.


Sure, the web is sometimes used that way currently, but few projects are using full-on Foo-to-JS compilers like GWT or ClojureScript that make the original source entirely illegible when viewed through the browser console.

Instead, projects are mostly using "light" transpilers built to have clean mappings to JS semantics, like TypeScript, where the original source can be recovered and traced by the browser as long as the transpiler generates a source-map.

WASM really won't work with the "source map" paradigm, and so a move to a web where most development uses languages that compile to WASM, is a move to a more opaque, less learnable web. (And also one that browser extensions have far less of an ability to intercede in.)


This just means you won't debug things using a browser console, but using a debugger designed for the host language instead. And that would be a blessing: I'm far more proficient in GDB than I am in the Chrome/Firefox developer tools.


Why won't WASM really work with the "source map paradigm"? Is there something fundamentally different about bytecode that means it cannot be traced back to its original source, given tooling support?


WASM will have source map support, if it does not already. There is already support on Firefox nightly it seems: https://github.com/yurydelendik/wasm-source-map-emscripten


But there's an upside, no? There is no way to reference an undefined variable in go? So if the compiler is correct, so will be the result, and errors would be found compile time.

(written by a non-go-expert)


While you cannot reference an undefined variable in Go, you can still dereference nil pointers and invoke other operations that result in a panic (some of the standard library functions can panic).


It’s not necessarily any faster. You can shoot yourself in the foot quite easily too, performance wise.


It's more predictable, when generated from a strongly typed language.

Most of the times, due to the strong typing, it is faster. However, there's a cost involved in compiling, invoking and passing data in and out of a wasm module. If the overhead cost is greater than the raw performance gain, there's no discernable difference


Don't forget about crossing language boundaries. Using JNI can be slower than pure Java code, and I think the same is true for wasm-js interop [1]. When wasm gets "native" access to the DOM and other browser features this may change, but until then, DOM manipulation is probably going to be faster in js.

[1] someone should benchmark this.


JNI transitions (at least on OpenJDK and Android) are much more expensive that WebAssembly<->JavaScript transitions. For the latter the same JIT is being used on both sides and there is no need for a GC transition. JNI is also far from as fast as it could be; .NET’s PInvoke is much more efficient (and easier to use).


Mark Reinhold already stated on a few talks, including at JavaONE that Sun designed it that way on purpose as they wanted to keep everyone true to WORA without carrying native code around.

Which is also a reason why a replacement is being done as part of Project Panama, initially advocated by Charles Nutter due to the JRuby project issues.

http://openjdk.java.net/jeps/191

In alternative, if you have the source code available there is a way not to any transitions.

Java now has GraalVM and .NET had C++/CLI (nee Managed C++) since the beginning.


In this version of web assembly only !

Web Assembly is gimped because it needs to be compatible with existing JS runtimes - when they add threading support you will no longer be able to run a WASM shim in JS but at the same time WASM will become a lot more general purpose.


Existing JS runtimes actually use shared-memory concurrency a ton, even ignoring the (currently disabled) SharedArrayBuffer. Code generation and garbage collection have at least some concurrent stages on all the major JS engines. JavaScriptCore even exposes this in its API.


Javascript already has multithreading via webworkers. That's not something WASM will introduce.


SharedArrayBuffer is only available in chrome and FF and they disable it by default so no way to do standard multithreading via webworkers.


It was disabled because of spectre.

Multithreaded WASM isn't here either.

I think WASM will face the same security considerations.


Webworkers are multithreading. You just have to use slower, async communication methods. WASM will likely be the same way, given the security considerations.



By itself, adding the Go SDK to the mix is unlikely to simplify the toolchain. To do that, you need to remove more complexity than you add.

There might be a chance to simplify if you're already using Go on the server and you remove a lot of other stuff.


But if catching up means taking on baggage and complexity, is that still a win. Technology is a means, not an ends. Of course non-native should evolve, but taking a copy-cat approach seems like a not so good plan.


Luckily the "plugins" will be bundled with the apps. The trade-off is ever-increasing download sizes.


In the age of using JavaScript to render text.


You don't throw web assembly in there and keep js, you throw js out at the same time.


If you look at the sheer number of requests to fetch some JS from some random website happen when loading a modern web page this will not be possible. Web pages rendering depend on JS being pulled from many places, and often not under the dev's control. So we'll end up with a mix of JS and WASM whether we like it or not.


Strange... I’ve seen plenty of “modern” websites without 3rd party JS bloat.


It would be tricky to completely throw JS away until WASM is able to call into the "browser APIs" (DOM, XHR, etc.)


Initially you'll use JavaScript as a top-level glue and all the submodules in WebAssembly. Then once it's stable you just get rid of all the JavaScript. You can even completely abandon DOM/HTML if you like and won't feel speed penalty for it.


JavaScript as glue and WebAssembly modules is more complicated, though, not less.

The JS ecosystem is a complicated mess, it's undeniable. But once you take the time to learn it, it's fine. In the majority of cases WebAssembly is just give to give the lazy an excuse to use a language they already know rather than learn something new.

And as for abandoning the DOM... yeah, it's not a great model. But is a dozen incompatible, competing rendering frameworks (that each site downloads separately) going to be good for the web?


> But once you take the time to learn it, it's fine.

For a short period of time, sure.. but the ecosystem evolves quickly, and often in inexplicable ways.

> In the majority of cases WebAssembly is just give to give the lazy an excuse to use a language they already know rather than learn something new.

Most people program in return for money, not for self-satisfaction at learning yet another single-purpose language.

> But is a dozen incompatible, competing rendering frameworks (that each site downloads separately) going to be good for the web?

How is this significantly different from where we are now?


> self-satisfaction at learning yet another single-purpose language

is a weird way of describing learning the language native to the web platform. I don't see a lot of people screaming about having to learn Objective C or Swift to make iOS apps.

> How is this significantly different from where we are now?

Err, because the DOM is a universal standard that comes built-in to every browser? <div style='background:red'/> looks the same everywhere, with no extra code required. If you're building a new renderer from scratch you're going to have a lot more code users need to download.


Would it though? I'm guessing something like the OpenGL spec would be standardized across browsers, and `<div style='background:red'/>` would be replaced by `glClear(1.0, 0.0, 0.0, 1.0)`.


Sure. Clearing the screen is one thing. But if you've done any work in WebGL you'll know that building an entire UI library with it would be a huge, huge endeavour.


But that doesn't seem like something that should be standardized anyway. There is no one way to do web UI, and the current popular paradigm (DOM/CSS) isn't particularly good either. Going to a lower-level gives more control to web developers, and the browser could always cache popular frameworks.

Now that we think about it, even with the DOM/CSS UI framework built into the browser, people still make use of libraries like jquery so library caching is something the browser needs to do anyway, WASM or not.


You see a lot of people screaming about it if they're web developers; that's why PhoneGap/Cordova, Ionic and Flutter exist.


For DOM - we will see I guess. It simply opens the door for some much needed competition ;-)


So we return to the dark ages of Flash for people who rely upon the standard DOM/HTML for accessibility?


> You can even completely abandon DOM/HTML if you like

For most applications, please don't do that though, unless there's eventually a web accessibility API that's independent of HTML.


No webassembly is a solution to it. JS just sucks. Actually so does HTML and CSS. The entire web ecosystem is a closed platform. The reason that the front end stack is constantly bloated is because JS,HTML & CSS are awful. If the people behind wasm were smart, they'd allow generic handles to a graphics context so that people can write/export other rendering frameworks. Strong typing is good, reactive programming is good. Using html and css strings is idiotic, and we couldn't build alternatives to this model for the past 30 years.


> The entire web ecosystem is a closed platform.

Please clarify what this means. Standards are open access and browser engines and JS engines are for the most part (Edge, Safari, Chromium, Firefox) open source, so "closed platform" seems, to me, inaccurate.

> If the people behind wasm were smart, they'd allow generic handles to a graphics context so that people can write/export other rendering frameworks.

Do you see how bloated web browsers are already? Do you really want apps to recreate all of this base functionality, or even to encourage such horrific inefficiency? Hopefully I'm missing something, because this seems like a terrible idea.


HTML (or any SGML-derivative, really) + CSS is the only application view format we have in common use that allows for clients of all shapes and sizes to reformat the page to fit them (with reflow rules, browser-default styles, and user-agent styles); and for alternative clients like screen-readers or "scraper"-like API clients to work with the view without the author having considered their needs ahead of time; and, best of all, for client-supplied optional third-party extensions to go into the view and mutate it to suit whatever custom purpose the client desires.

In other words, by mandating that the application view layer interacts with the client by delivering declarative (HTML) or imperative (JS) instructions to populate a semantic document (the DOM), rather than to populate a particular viewport; and by mandating that styling considerations are kept as separated as possible from that document; we can then operate on that document apart from the application's control, and render it the way we want to, or parse it into something entirely else.

A large part of the point of "the web" as a technology stack, is to provide exactly that capability. There's even a name for explicitly targeting such use-cases as a developer: HATEOAS (i.e. making your API endpoints act like web pages as well, in that they're also "documents" embedding hyperlinks to related documents, and form-input descriptions for making queries against the document—so that API clients can "navigate" your API just like browsers navigate your site. In extremis, your API becomes your site—since, if every endpoint is already responding with hyper-documents, your controllers can just have a logic for "Accept: text/html" that renders that hyper-document into hypertext, and attaches styling to it.)

If you don't care about any of that, you don't need the web. You just need a Hypercard viewer with an address bar. Or Lotus Notes.


HTML and DOM is the current way that is forced on us. What if I had a better model? I can't implement it myself. The DOM was meant to describe documents, not interactive webpages. HTML and CSS never had to compete with other ideas or technologies, because you physically can't do it.

The DOM is a relic from the 90s that refuses to die.


Implement it yourself, rendering to WebGL (with a canvas fallback if you really care). When you're done, show HN! We'll probably mock you, unless it's somehow awesome. The DOM is horrible, and knowing what we know now we could at least make it less weird, but some of the big annoyances really are its greatest strengths.


I am doing something similar. The problem is not just HTML/CSS it's also JS. You need a strongly typed language, and have a scripting language on top. What I'm doing now is a Rust based framework, with an Erlang like scripting language to define complex interactions. Taking inspiration from Flash, all animations and transitions can be keyframed with tweens. Taking inspiration from the C/C++ to python interoperability, I want the same with Rust and Erlang. Now my entire backend can be written in Rust.

Unfortunately, I'm not open sourcing it. Not until I get a proper graphics context, and implement my own rendering engine. I think web assembly is going to revolutionize the web. I see browsers allowing you to cache common libraries/assets, and html/css being replaced by several competing UI paradigms. The one I favour is inspired from functional reactive paradigm, but there are equally valid alternatives. I don't think there will be a single frame work to rule them all, just competing schools of thought. Right now the web doesn't have any competing paradigms, just html, css,and js.

Reason web sucks: HTML/CSS are not suited to define complex UIs with intricate layouts and complex transitions and key frame animation. This problem was better addressed 30 years ago. Look at the menu UIs in games from the n64/ps1 to ps2/gamecube era (I'm talking about the game menus, not the game themselves). Some of them had far more impressive UIs than the webpages of today. This type of UI is an order of magnitude harder with html/css than just doing it all via X11 and C (even with memory management concerns).

The reason for this is that HTML first isn't strongly typed. If you make something complicated, and make a small change, it messes everything up. Your compiler can't help you. HTML tags are somewhat inconsistent. React, Rails etc. are all trying to address this problem. They are all taking inspiration from android, iOS, QT and gtk+ to make it somewhat component based. However, you fundamentally can't achieve this. HTML is in a land of its own, when you create an HTML tag, sure you can wrap it in a JS class, and mimic some of the characteristics that desktop frameworks provide you. You won't get the whole thing. I've seen many times different frameworks reinventing html templates (like handle bars). Templates can't solve all issues.

CSS sucks. The first thing about css that sucks is the "cascading" part of css. It should just be ss. CSS was originally designed to limit bandwidth by having it cascading. That's not the case today, and it messes everything up. The second thing that sucks, similar to why html sucks, is that again css is in a land of its own. It's hard to control css from JS (for interactive site you want this). I'm not even going to talk about how hard it is to position things properly via css when you are building layouts dynamically.

JS just sucks. I don't think I need to elaborate, I've mentioned enough points already.

Every single web framework out there is trying to address some aspect of the problems I mentioned, but my claim is that you can't solve it, you need to start over. Imagine if CPU makers made crappy inconsistent assembly code. Every year a new compilers and languages come out that tries to fix their predecessors. The most logical choice is instead to ditch that chip maker, make a better CPU with a consistent assembly code. You can't do that with web, you can't ditch assembly(html,js,css).

It only took 30 years for the web to get web sockets, webgl and now wasm. I think in another 20 years we'll come a full and get the remaining amenities that modern operating systems provide.

The reason I chose Rust is because it's a low level language with strong typing. It's not quite Haskell, but good enough. Writing a web server and UI with Rust is very nice. It just connects to the backend processes with ease, and doesn't make things awkward the way npm does. I do a lot of low level numerical and mathematical simulations, all done in C/Rust with all coordination & distributed computing done in Rust. I want Rust to take over. The sequence should be: Erlang -> Rust -> C

I chose Erlang because years ago I saw how reactive programming is extremely useful for complex interactions in a AAA game I was working on. In a game system you have the play interacting with the world, with enemies. The enemies interact with the player and each other. The player can pause the game at any point, then you need to bring up a menu screen with its own interactions. I've seen this work flow done in many different ways, and by far the reactive paradigm is the most sane. This was done in a bastardized version of Lua and Lisp.


I pretty much agree about JS and Rust, but I find myself disagreeing with some of your points regarding CSS/HTML.

>> Reason web sucks: HTML/CSS are not suited to define complex UIs with intricate layouts and complex transitions and key frame animation.

CSS does have a concept of keyframes now (I know this may not cover everything you like about flash keyframes, but I figured I'd throw it out there in case you were unaware): https://www.w3schools.com/css/css3_animations.asp

>> This problem was better addressed 30 years ago. Look at the menu UIs in games from the n64/ps1 to ps2/gamecube era (I'm talking about the game menus, not the game themselves).

Those layouts had a known aspect ration, 4:3, and a reasonable expectation of being viewed on a large screen. HTML and CSS are expected to work on a wider variety of screens that may change size and aspect ratio on the fly, possibly during an animation. If I only had to make HTML/CSS animations for use on a normal television screen with a known zoom level in a specific browser, I could make interfaces every bit as beautiful as your N64 games (well... with a competent designer, but my point is that I could write the layout and script the animations). Some of the pain points of HTML and CSS are historical accidents that can't be changed without breaking compatibility, but some of them are quite useful and necessary. Responsive design is a good thing, it just sucks to write an animation that works in a whole range of aspect ratios and zoom levels. It's a problem that Sony and Nintendo never had to design around. The amount to which this constraint cripples and strengthens the web is hard properly convey. I love and hate it, but as time goes on I learn to hate it less and love it more.

>> It's hard to control css from JS (for interactive site you want this)

It's costly, as it touches the DOM, but it's not hard. Just change the class attribute (or even the inline style attribute -- there are cases where this can be argued for). Simple example: https://www.w3schools.com/js/js_htmldom_css.asp


> The first thing about css that sucks is the "cascading" part of css.

This tells me you hve very little experience with CSS or even HTML. The cascade saves you from declaring "font-size: 16px" in every single element of your page. Think of it as a form of property inheritance


Sorry, you can’t say “CSS sucks” when the only limitation it has is your lack of knowledge. If YOU can’t build complex layouts with it, it’s not the language’s fault. Plenty of people can. Open an “awards” site and see what people can do and you can’t.


It depends on what you compare it to, most native stacks have a more simple and understandable way of handling styling and control layout. You can cut a lot of things with an ax, but you shouldn't criticize someone for wanting a saw, even if you can build the skill set to do the same with an ax.


Implement the better model on top of current tech and show us. It is a competition, it's just that noone is competing.


The fundamental problem is that if you do end up reimplementing a slightly better DOM yourself, you end up with (e.g.) 20 MB of browser and rendering code. This will have to be downloaded by the client. If this were a onetime thing (perhaps some kind of "install"), it wouldn't be a problem.

But browser caches aren't generally up to the task of making it a onetime thing because:

-They're usually pretty small.

-They'll evict pretty frequently.

-They're limited to same-origin, even if the content cached is exactly the same. (For security reasons, yes, but there's no way to opt out.)

If caches were fixed, I think we would see a much healthier web ecosystem. Incidentally, it would make the browser vendors themselves fairly obsolete, which is probably why it hasn't happened yet.

I think billybolton is right that HTML/CSS/JS/the DOM all kind of suck, and that they can't feasibly be replaced is problematic. The heroic modern struggle of the web ecosystem is an attempt to encapsulate and work around the suckiness.


> Incidentally, it would make the browser vendors themselves fairly obsolete, which is probably why it hasn't happened yet.

Mostly, but not entirely true. It's been a while seen we've seen a new browser come out, but the time is ripe to begin work on one, and release it in a few years. Just fork webkit to maintain backwards compatibility. I see browsers just becoming a sandbox virtual machine with a key ring, with minimal functionality.

Apple has the strongest incentives to build what I am mentioning. Not sure if they will.


I could see a case for all the other big tech companies, but why Apple?


Given that web tech is used to build mobile and desktop apps that might not be a bad trade-off for those cases.


That is a good way to put it.

It took 100 years to go from the onset of the printing press to the book form and we are in some weird in between time frame where browsers aren't really enough to do what we want. Conceptually it is going to take something that is revolutionary, yet at the same time extremely familiar... like the book. I bet we would find similar strains in the intervening decades between the printing press and the book.


It feels like we are in the video/book choose your own adventure stage. It's clunky and it more or less works. But there will be a better way.


> If the people behind wasm were smart, they'd allow generic handles to a graphics context so that people can write/export other rendering frameworks

Games maybe, but for normal applications sounds like would just end up with worse graphics than old Java applets, Swing, etc.


If that's your opinion then why bother targetting web browsers with WASM at all? You've been able to create highly interactive apps and games using native development for ages. I simply see no need for a new bytecode format, especially when mobile is ARM-only already, and even less so in Web browsers. WASM doesn't define a rendering or sound API, nor does it solve any other single problem game developers are having on established platforms. And, like JavaScript, needs HTML and CSS or another graphic API such as WebGL or canvas.


It's not for games. We are dealing with big data, we need to highly interactive UIs on the web that we can use to communicate and interact with this information. Something like this is where I see the future of web: http://globe.cid.harvard.edu

That is not real time, but very difficult to pull off on web (harder than using C++ on desktop! Debugging webGL in JS is a nightmare). I don't see any issues with an ARM processor. The Harvard globe project if done in C++ could definitely run on a 2004 era computer. Most phones these days are much more powerful.


Got any examples of other systems that you prefer for ui?


Not sure I follow the reasoning here. I mean, it's not like JavaScript and its associated tooling is the barrier to entry to frontend anymore for anyone that has the energy and interest to spend even a trivial amount of time looking into it.

The tooling and framework outlook has stabalised massively over the last few years, and settled on zero-config build tools (create-react-app, angular-cli etc.) and mature frameworks (React is 5 years old now) with great developer ergonomics (components and uni-directional data flow are here to stay).

JavaScript itself has sorted itself out to a large extent if you just want to roll ES6+, and there's any number of compile-to-javascript languages to satisfy every stripe of programmer - ClojureScript, ReasonML, Elm, TypeScript, etc.

Respectfully I'd suggest that the reason the majority of Go or C++ devs aren't building single page webs is not because of the tooling and languages around the web platform, but because they're simply not sufficiently interested in it - there's a lot required to work on the web platform that has nothing to do with what flavour of programming language you find acceptable ... you need design sensitivity, experience with UI, UX and animation/motion, experience working cross platform and cross browser, experience working with graphic designers and CSS skills to name just a few.


More of a general observation than something directed at you in particular: back in the 2004-2005 timeframe, I saw a cohort of developers thinned out by the jump from ASP/VB6 to ASP.NET/C#. They made similar arguments (mature framework, lots of documentation, de facto standards, also lots of FUD). Microsoft appeased them with VB.NET,and made soothing noises about them not being replaced.

I suspect that the move to the current JavaScript-heavy ecosystem killed more careers.

WASM represents another potential shift. If one wants to survive, one has to prepare for these shifts, and not emotionally invest in a particular tech stack.


> If one wants to survive, one has to prepare for these shifts, and not emotionally invest in a particular tech stack.

Couldn't agree more. I'm already a refugee twice over from previous tech stacks, and keep on enjoying where I end up! That said, I've always stayed within the realm of creative, visual and UI development. I'm just floating the idea that transitioning into a web/UI development stack from a backend or systems programming background might not be all that easy, whether ones favourite programming language now compiles to WASM or not.


And yet, people still put together world class interfaces (and consequently, experiences) using html, css and javascript. Some may not like it, but it works, and I'm unconvinced using a different programming language will adversely effect end products, or that users will even notice a difference.


Digging latrines by hand worked well for thousands of years, but that doesn’t mean there aren’t better technologies. The weirdest part of the tech industry by far is this frankly insane “but it works well enough” reaction to criticisms of JS. Seriously, everyone’s all about disruption and crazy-fucking-Byzantine front-end dev frameworks, but when it comes to the actual languages used to produce those frameworks, we have sacred cows? What’s up with that?


In my view, it comes down to a few questions, the most important of which is:

What new capabilities does WASM afford us?

I by no means think JS is beyond criticism, but much of the excitement about WASM revolves around writing web stuff in other languages. Is that really disruptive?


Web stuff? Probably not.

WASM's greatest value on the web is likely to be optimizing high-performance code. Although people want to use it to replace javascript entirely with the compile-to-WASM toolchain of their choice, the actual utility of that is likely to be minimal.

Although in that regard, WASM is objectively better as a compile point than "compiling" to javascript. Having an actual bytecode for the web that isn't proprietary or tied to a single language is better, if not necessarily disruptive.

What, to me, is potentially disruptive about WASM is the potential it offers for archiving, distributing and running "native" software over the web, or if and when thin native clients become available, eliminating the distinction entirely and having a universal, OS agnostic software distribution and installation model based on web caching.

Although we've got a way to go with that, and it may be a stupid and terrible idea. But it would be disruptive.


I will bite: "world class interfaces" - are you sure?

I haven't seen any UI on the web that would at least resemble some interfaces from top end games from 10 years ago that were arguably world class. All I can see lately are clunkers where I have to wait ~10s until the whole page loads and I can finally do something, often with terrible responsivity on a top end i9.


I suppose it depends how we're defining world class.

An intensely graphical UI in a game may require the performance native code offers - in that case, absolutely, native will likely outshine the current web stack for developing that specific UI, because the web stack will likely introduce a noticeable difference (ie: lag).

However, I think the essence of the 'good-ness' (usability, aesthetics, intuitiveness, whatever) in the majority of interfaces isn't in the extra 10 - 20% of performance you can squeeze out, but in its design.

If we entertain that idea, and html/css/js allows you to implement that idea bang-on, and there's a huge ecosystem surrounding this tech in assisting those implementations, and generally page loads aren't ~10s (I haven't experienced that myself - anyone can write bad code in any language, however), what's the trouble?


If a page contains multiple sections it often waits ~10s until it's usable and I have to wait looking at rotating busy signs (compare e.g. NHL.com and its previous version that loaded instantly). Lately I am also getting extremely upset when on a recent i5 NUC just vertically scrolling on a trivially looking page stutters and NUCs fan goes to overdrive. It's getting ridiculous. It's not like you can pan in 2D or 3D an move in any direction, doing creative things, it's just a silly looking page with some title, links on the right and some images and embedded videos (just a large preview pic) in the main body.

Everything is getting extremely bloated. Can't wait until I need an overclocked Threadripper with 1Gbit Internet to see what the weather forecast is...


If your "world class" games from 10 years ago were online based, they'd have the same problem. So its not really the web tech you are against, its the client-server application model.


So, your argument is that it's not the implementation, but that the technology itself is fundamentally broken.


That's not my argument, and I can see how it got misunderstood: mean to reply to the grandparent comment, which was comparing the responsiveness of a desktop app where all required resources are installed and locally available, to that of a web application. Whatever you build it with, if the data has to come down "through the wire" then you will wait..


My objection was that the previous designs provided exactly the same real-time information, used client-server architecture as well, but were fast.


World class interfaces compared to what? Desktop? Desktop is still superior.


Compared to Gopher.

Still not quite as good as the original Macintosh from 1984 though.


1.3mb binary size, untyped elements (compare to Typescript/JSX), and a Makefile that will inevitably rival webpack.


Somehow I have the feeling the "one big statically linked binary" approach of Go won't make people too happy.


I think what we'll see next is something like react rendering to a canvas, beating html rendering & dom manipulation, maybe subsets of the good parts of the DOM, dropping old-cruft support, but all rendered on a canvas. This will, in turn, create framework cults.


This will be horrible. Like applets rendered on a CSS style web page. Some young people will experience this for the first time, but the old devs will remember :)


  in 2 years or less, Go, Swift, Rust will be 1/3 of the frontend code
I'm not sure the author understands exactly how much frontend code already exists. Maybe he means all frontend code "currently in development"?


I'd like to hear more about why the author thinks WASM is the future of web development, because the only reason he mentions in the conclusion sounds like a simple description of WASM itself.


I think wasm needs some years of evolvement. Many of the good languages like C#, Java, Go or (God forbid) PHP will need a functional cross language and per language framework incorperated shared/cooperating GC which will allow a cross language interchange of objects. Otherwise all wasm will be only app solutions and not an ecosystem like JavaScript.

I am not a super expert and maybe someone can enlighten me but I think that is the biggest hurdle.


It will be just another target for the Java ecosystem, Go ecosystem, .NET ecosystem, Haskell ecosystem, OCaml ecosystem, C ecosystem, C++ ecosystem, ...

All united by WASM bytecode.


In the end of the day, Composition is the last thing you do to complete one cycle development phase. So components matter for the ease of composition.


How does the Go GC work here?


The Go wasm arch/target generates and bundles a GC. That likely contributes to the significant size of the wasm output (https://matthewphillips.info/programming/wasm-golang-ce.html)


The "Javascript is bad and webpages are too big" crowd is going to have a tough time coming up with an opinion about this.


Nah, it's pretty simple. Javascript is bad, web pages are too big, and this is just a continuation of the insanity. The solution is to stop trying to shoehorn everyfuckingthing into the web browser.

But, who cares. The web is unfixable at this point.


At some point GC API will be exposed by the browsers themselves.


GC depends too much on how a language runtime chooses to store the types of objects in heaps, because in the ideal case the answer is "store nothing, that type is statically known in this language".


But the big question is: is it a concurrent GC, like in native Go?


I believe it's basically just bundling the runtime, so yes, it's concurrent, however WASM doesn't provide threads I believe so it's still effectively running single threaded (ie: same as GOMAXPROC=1).


No, GOMAXPROC=1 is not single threaded. GOMAXPROCS=1 uses one kernel thread for running user Go code, but it uses other kernel threads for running system (runtime) Go code, or for executing system calls.

More details: https://news.ycombinator.com/item?id=12460807


Yes, but if WASM is single-threaded, then how can the GC run in a different thread?


I don't have a deep understanding on how the WASM Go port works, sorry. I was simply responding to the parent comment about GOMAXPROCS=1.

I suspect the WASM port is single threaded and blocks in the GC, but I am not an expert on this.


A GC is bundled in the wasm.

(see the function names beginning with "gc*")


Nice article - Thanks for sharing insight.


:-))


Honestly, i am a bit sceptical.

In my opinion the super hype over Javascript is because of it's simplicity(compared to GO for example).

It is already very hard to find a decent backend developer, if the frontend is written in backend language like GO, it kind of makes it worse.

I don't know. Personally as a nerd, this makes me excited, but from the business perspective in current time, seems like a bad deal.


It is a matter of perspective. For my personal projects I decided some time ago that I would use javascript both frontend and backend. That was a world of pain, mostly attributed to the lack of static typing, asynchronous nature implemented through callbacks, and the pain of choosing alternatives in the chaotic ecosystem. It was somewhat alleviated when I switched to Typescript, started to use async and await, and settled in some choices (Bootstrap, React, webpack...). But then I tried the golang. Yes, the lack of generics hurts a bit, but otherwise it is an absolute damn pleasure to use: static typing, reliable completion in IDEs, batteries included, more clarity in choice of modules. It just felt right. Granted, it is my multi-year background in C and C++. For me multi-threading and co-routines just feel more natural way of doing concurrency than callbacks and CPS.


> In my opinion the super hype over Javascript is because of it's simplicity(compared to GO for example).

IMO, the core of modern ES6+ JavaScript is a really nice scripting language that is simpler than alternatives, but doing production JavaScript means contending with all of the other stuff. To be a working JavaScript developer, you need to know multiple ways of doing the same things, from basics like module loading and HTTP requests to UI and concurrency. Legacy and an ecosystem that is fragmented down to the standard library level make JS not the easy option.


> In my opinion the super hype over Javascript is because of it's simplicity(compared to GO for example).

Go imho is a lot simpler than Javascript. Not necessarily as a language (although Go is pretty simple, and JS has some very ugly pitfalls). Thing is, getting into the JS ecosystem is an absolute mess. With Go, I felt comfortable with it within a few days. Recently, wanting to create some sort of frontend for a REST API I'm making - I tried getting into "modern" frontend JS, having dabbled in HTML, JS and CSS a decade ago, having created a small internal bootstrap-based app targeted at mobile devices - so I understand the basics

However, the current JS ecosystem? I have no idea where to even start, I haven't even gotten to the point where I would actually have some hacky code that would at least give me an idea how to move forward...


First, it makes wonderful sense for certain projects even without productivity/learning-curve gains. E.g., anything that's not particularly supported by the HTML+CSS paradigm. Think "stuff that would today be a native application".

But let's jump into the "finding labor/business case" problem.

> It is already very hard to find a decent backend developer

And why is that?

> In my opinion the super hype over Javascript is because of it's simplicity(compared to GO for example).

Agreed! You totally hit the nail on the head! The reason frontend is easier to hire for, is because HTML+CSS+Javascript provides a relatively small minimal viable set of abstractions that allow you to be productive.

Of course, I don't want to diminish the fact that there's an infinite rabbit hole of complexity here (see e.g., wavethrough); serious engineers can definitely thrive in front-end work. But for "productive enough frontend dev", the set of things you have to learn is relatively small compared to backend.

> if the frontend is written in backend language like GO, it kind of makes it worse.

On the contrary, I think WASM could enable a fix to your problem!

The question is, could we build a WASM-backed unified development environment that allows people to learn full-stack development in the same amount of time that it currently takes to learn just the front-end stuff? And can you produce productive full-stack engineers for a particular full-stack framework while skipping a lot of the fundamental CS stuff?

If the answer to both is "yes", then coding bootcamps could step into that environment that churn out lots of relatively cheap/easy-to-find full stack development talent!

So. Who can build a single framework providing a small set of abstractions (learnable in 6-12 weeks from scratch) that allows for both front-end and back-end development? If someone can do that, and build an educational commodity around it (i.e., a scalable model for bootcamps), then I could see wasm enabling a whole new approach toward web development in which "not top-tier but definitely good enough" fullstack developers are at least as easy to find and for the same price as today's "not top-tier but definitely good enough" frontend developers.


> Who can build a single framework providing a small set of abstractions (learnable in 6-12 weeks from scratch) that allows for both front-end and back-end development?

Remeber the desktop RAD platforms, like Delphi and Visual Basic? There is no reason we couldn't have very similar things on the web.


Obligatory plug: we've built one!

https://anvil.works - it's explicitly modeled on VB6/Delphi. All Python (front and back end, with a simple RPC interface from client to server), and learnable in a lot less than 6 weeks. Check it out!


>When I look at modern web development I shudder; the ecosystem is so confusing for someone who has been out of touch as long as I have. Node, webpack, yarn, npm, frameworks, UMD, AMD, arghhh!

...

> To get started with wasm in Go you need to checkout Go from source and build it....Because Go requires a working go installation to bootstrap itself, you'll end up with two different installations of Go when you're done.

Couldn't help laughing at this. Getting started building staff in JS is actually really simple, even if there are different paths you can go down (it really doesn't matter if you use yarn or npm, for instance). Having to install Go once just to build a newer version of Go to try this? Sounds like a total nightmare. Each to our own, I guess. :)




Applications are open for YC Winter 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: