18 ms·

Web Assembly and Go: A look to the future

329 points by rch 8y ago

k__ 8y ago
Somehow I have the feeling the "one big statically linked binary" approach of Go won't make people too happy.
bketelsen 8y ago
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.
- slimsag 8y ago
  (Author of the framework, Vecty, here) Also happy to answer any questions anyone has. =)
- eksemplar 8y ago
  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 8y ago
    The problem is that right now we're all talking about WebAssembly because it's too early to tell where it lies. Comparing JavaScript to WebAssembly is apples to oranges because Java programmers typically don't think of Java Bytecode just like C# programmers don't think of CIL. They think of the programming language and the ecosystem of libraries that go with it. JavaScript is to Java what WebAssembly is to JavaBytecode, it's an infrastructure to then build a stack on top. WebAssembly has more hindsight than say Flash, Silverlight and Dart because it does things the latter three failed to address. Those tried to fix many of the warts of the web development of their days without caring about lock-in effect those had (both on the developers and the competing browsers perspective). This is why none of the major browser vendor jumped on the bandwagon and why those technologies were doomed to fail. From that perspective, something like WebAssembly was the only right thing to do, and incidentally all major browser vendor agreed and are pitching in. And you get so much more with this because now, just like C# programmers share libraries with F# programmers, it'll be possible to have all sorts of functionality (even some that don't exist on the web today) available to anyone who has a compiler targeting WebAssembly. This is actually something that could kill offline development if they working hard enough to make it near-zero cost to target the web. I think that GC will be a major part of making libraries universal (something Java succeeded but C++ somewhat failed at), but as far as I know it's been on the todo list from the start (post-MVP). It's also difficult to appreciate what is possible to do when you have a single compiler that can target server and client-side. It'll help those working in a typed programmers target the web but also, it's possible to make transparent call between server-side and client-side code letting the compiler wire up everything for you. There's also a lot that you typically do on the server-side where no reason exists other than performance. Those can be moved to the client side and thankfully, existing implementation in your programming language of choice will just work. We probably can't even think of all the benefits this'll bring.
    - Taek 8y ago
      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?
      - LamaOfRuin 8y ago
        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.
        norswap 8y ago
        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.
      - Perseids 8y ago
        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.
      - tylerl 8y ago
- unscaled 8y ago
  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.
TekMol 8y ago
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.
- pjmlp 8y ago
  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.
  - TekMol 8y ago
    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.
    - erikpukinskis 8y ago
      It’s not necessarily any faster. You can shoot yourself in the foot quite easily too, performance wise.
      - mankash666 8y ago
        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
        uluyol 8y ago
        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.
woah 8y ago
How does the Go GC work here?
- masklinn 8y ago
  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 8y ago
    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 8y ago
      At some point GC API will be exposed by the browsers themselves.
      - erik_seaberg 8y ago
        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".
    - ori_b 8y ago
      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.
  - amelius 8y ago
    But the big question is: is it a concurrent GC, like in native Go?
provlem 8y ago
Nice article - Thanks for sharing insight.
- jjkk 8y ago
  :-))
MatthewPhillips 8y ago
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.
- bketelsen 8y ago
  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.
- erikpukinskis 8y ago
  Sadly, 1mb is not that big for web pages lately. So that could be competitive with a js stack for some apps.
  - solarkraft 8y ago
    I think some very simple (tens of loc) Go programs I wrote ended up compiling to Linux binaries of about 5mb.
    - axaxs 8y ago
      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.
  - GijsjanB 8y ago
    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.
ivrrimum 8y ago
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.
- mynegation 8y ago
  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.
- throwawayjava 8y ago
  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.
anothergoogler 8y ago
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.
gedy 8y ago
> 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.
- woah 8y ago
  Those are some good points, but it looks like the author is mostly just injecting a React-like framework into the root element.
  - gedy 8y ago
    Ah thanks, I missed that
- MatthewPhillips 8y ago
  Criticizing a language that just got wasm support last week for not having mature high level solutions yet is a bit ridiculous.
  - gedy 8y ago
    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 8y ago
      You know something has to perform low level DOM operations, right?
      - klibertp 8y ago
        Sure, but I was under impression that it's best left to the C++ the browsers are written in?
lucidone 8y ago
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 8y ago
  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.
  - deleted 8y ago
    [deleted]
  - lucidone 8y ago
    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 8y ago
      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...
greg45n 8y ago
1.3mb binary size, untyped elements (compare to Typescript/JSX), and a Makefile that will inevitably rival webpack.
superfrank 8y ago
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.
- napo 8y ago
  "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
- slimsag 8y ago
  (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
Wintamute 8y ago
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 8y ago
  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 8y ago
    > 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.
adventured 8y ago
> 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-President https://www.quora.com/What-made-George-Washington-a-great-Pr... 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 8y ago
  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) ?
stevage 8y ago
>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. :)
revskill 8y ago
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.
perpetualcrayon 8y ago
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"?
Zooper 8y ago
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 8y ago
  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 :)
oaiey 8y ago
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 8y ago
  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.

329 points by rch 8y ago

k__ 8y ago

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

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.

slimsag 8y ago
(Author of the framework, Vecty, here) Also happy to answer any questions anyone has. =)
eksemplar 8y ago
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 8y ago
  The problem is that right now we're all talking about WebAssembly because it's too early to tell where it lies. Comparing JavaScript to WebAssembly is apples to oranges because Java programmers typically don't think of Java Bytecode just like C# programmers don't think of CIL. They think of the programming language and the ecosystem of libraries that go with it. JavaScript is to Java what WebAssembly is to JavaBytecode, it's an infrastructure to then build a stack on top. WebAssembly has more hindsight than say Flash, Silverlight and Dart because it does things the latter three failed to address. Those tried to fix many of the warts of the web development of their days without caring about lock-in effect those had (both on the developers and the competing browsers perspective). This is why none of the major browser vendor jumped on the bandwagon and why those technologies were doomed to fail. From that perspective, something like WebAssembly was the only right thing to do, and incidentally all major browser vendor agreed and are pitching in. And you get so much more with this because now, just like C# programmers share libraries with F# programmers, it'll be possible to have all sorts of functionality (even some that don't exist on the web today) available to anyone who has a compiler targeting WebAssembly. This is actually something that could kill offline development if they working hard enough to make it near-zero cost to target the web. I think that GC will be a major part of making libraries universal (something Java succeeded but C++ somewhat failed at), but as far as I know it's been on the todo list from the start (post-MVP). It's also difficult to appreciate what is possible to do when you have a single compiler that can target server and client-side. It'll help those working in a typed programmers target the web but also, it's possible to make transparent call between server-side and client-side code letting the compiler wire up everything for you. There's also a lot that you typically do on the server-side where no reason exists other than performance. Those can be moved to the client side and thankfully, existing implementation in your programming language of choice will just work. We probably can't even think of all the benefits this'll bring.
  - Taek 8y ago
    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?
    - LamaOfRuin 8y ago
      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.
      - norswap 8y ago
        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.
    - Perseids 8y ago
      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.
    - tylerl 8y ago
unscaled 8y ago
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.

TekMol 8y ago

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.

pjmlp 8y ago
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.
- TekMol 8y ago
  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.
  - erikpukinskis 8y ago
    It’s not necessarily any faster. You can shoot yourself in the foot quite easily too, performance wise.
    - mankash666 8y ago
      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
      - uluyol 8y ago
        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.

woah 8y ago

How does the Go GC work here?

masklinn 8y ago
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 8y ago
  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 8y ago
    At some point GC API will be exposed by the browsers themselves.
    - erik_seaberg 8y ago
      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".
  - ori_b 8y ago
    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.
- amelius 8y ago
  But the big question is: is it a concurrent GC, like in native Go?

provlem 8y ago

Nice article - Thanks for sharing insight.

jjkk 8y ago
:-))

MatthewPhillips 8y ago

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.

bketelsen 8y ago
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.
erikpukinskis 8y ago
Sadly, 1mb is not that big for web pages lately. So that could be competitive with a js stack for some apps.
- solarkraft 8y ago
  I think some very simple (tens of loc) Go programs I wrote ended up compiling to Linux binaries of about 5mb.
  - axaxs 8y ago
    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.
- GijsjanB 8y ago
  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.

ivrrimum 8y ago

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.

mynegation 8y ago
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.
throwawayjava 8y ago
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.

anothergoogler 8y ago

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.

gedy 8y ago

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

woah 8y ago
Those are some good points, but it looks like the author is mostly just injecting a React-like framework into the root element.
- gedy 8y ago
  Ah thanks, I missed that
MatthewPhillips 8y ago
Criticizing a language that just got wasm support last week for not having mature high level solutions yet is a bit ridiculous.
- gedy 8y ago
  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 8y ago
    You know something has to perform low level DOM operations, right?
    - klibertp 8y ago
      Sure, but I was under impression that it's best left to the C++ the browsers are written in?

lucidone 8y ago

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 8y ago
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.
- deleted 8y ago
  [deleted]
- lucidone 8y ago
  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 8y ago
    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...

greg45n 8y ago

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

superfrank 8y ago

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.

napo 8y ago
"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
slimsag 8y ago
(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

Wintamute 8y ago

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 8y ago
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 8y ago
  > 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.

adventured 8y ago

> 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-President https://www.quora.com/What-made-George-Washington-a-great-Pr... 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 8y ago
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) ?

stevage 8y ago

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

revskill 8y ago

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.

perpetualcrayon 8y ago

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

Zooper 8y ago

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 8y ago
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 :)

oaiey 8y ago

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 8y ago
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.