
Web Assembly and Go: A look to the future - rch
https://brianketelsen.com/web-assembly-and-go-a-look-to-the-future
======
bketelsen
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.

~~~
eksemplar
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.

~~~
davidgrenier
The problem is that right now we're all talking about WebAssembly because it's
too early to tell where it lies.

Comparing JavaScript to WebAssembly is apples to oranges because Java
programmers typically don't think of Java Bytecode just like C# programmers
don't think of CIL. They think of the programming language and the ecosystem
of libraries that go with it.

JavaScript is to Java what WebAssembly is to JavaBytecode, it's an
infrastructure to then build a stack on top.

WebAssembly has more hindsight than say Flash, Silverlight and Dart because it
does things the latter three failed to address. Those tried to fix many of the
warts of the web development of their days without caring about lock-in effect
those had (both on the developers and the competing browsers perspective).
This is why none of the major browser vendor jumped on the bandwagon and why
those technologies were doomed to fail. From that perspective, something like
WebAssembly was the only right thing to do, and incidentally all major browser
vendor agreed and are pitching in.

And you get so much more with this because now, just like C# programmers share
libraries with F# programmers, it'll be possible to have all sorts of
functionality (even some that don't exist on the web today) available to
anyone who has a compiler targeting WebAssembly. This is actually something
that could kill offline development if they working hard enough to make it
near-zero cost to target the web. I think that GC will be a major part of
making libraries universal (something Java succeeded but C++ somewhat failed
at), but as far as I know it's been on the todo list from the start (post-
MVP).

It's also difficult to appreciate what is possible to do when you have a
single compiler that can target server and client-side. It'll help those
working in a typed programmers target the web but also, it's possible to make
transparent call between server-side and client-side code letting the compiler
wire up everything for you. There's also a lot that you typically do on the
server-side where no reason exists other than performance. Those can be moved
to the client side and thankfully, existing implementation in your programming
language of choice will just work.

We probably can't even think of all the benefits this'll bring.

~~~
Taek
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?

~~~
tylerl
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.

~~~
Taek
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.

~~~
sjellis
"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.

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

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

~~~
slimsag
(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/](https://webpack.js.org/guides/getting-started/) [2]
[https://github.com/kriasoft/react-starter-
kit](https://github.com/kriasoft/react-starter-kit)

~~~
randomfool
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

~~~
AsyncAwait
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.

~~~
abritinthebay
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.

~~~
curun1r
> 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.

~~~
abritinthebay
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.

~~~
armitron
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.

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

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

~~~
gedy
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

~~~
MatthewPhillips
You know _something_ has to perform low level DOM operations, right?

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

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

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

~~~
orange8
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.

------
MatthewPhillips
Great article! I attempted something very similar and wrote about it here:
[https://matthewphillips.info/programming/wasm-golang-
ce.html](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.

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

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

~~~
axaxs
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.

------
adventured
> 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://www.quora.com/What-made-George-Washington-a-great-President)

[https://en.wikipedia.org/wiki/Jack_Dorsey](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.

~~~
encore2097
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) ?

------
TekMol

        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.

~~~
billybolton
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.

~~~
derefr
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.

~~~
billybolton
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.

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

~~~
Felz
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.

~~~
billybolton
> 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.

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

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

~~~
ern
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.

~~~
Wintamute
> 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.

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

~~~
bitL
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.

~~~
lucidone
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?

~~~
bitL
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...

~~~
orange8
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.

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

~~~
orange8
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..

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

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

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

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

~~~
oaiey
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 :)

------
perpetualcrayon

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

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

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

~~~
pjmlp
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.

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

------
woah
How does the Go GC work here?

~~~
masklinn
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](https://matthewphillips.info/programming/wasm-golang-ce.html))

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

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

~~~
erik_seaberg
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".

------
provlem
Nice article - Thanks for sharing insight.

~~~
jjkk
:-))

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

~~~
throwawayjava
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.

~~~
marcosdumay
> 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.

~~~
meredydd
Obligatory plug: we've built one!

[https://anvil.works](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!

------
stevage
>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. :)

