Web Assembly and Go: A look to the future
brianketelsen.com
brianketelsen.com
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.
IMO it seems like a step backwards, even if it’s better than JavaScript.
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.
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?
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.
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.
Silverlight was developed by a major browser vendor (Microsoft), and Dart was developed by another major browser vendor (Google), which also had NaCl and PNaCl on their browser.
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.
I can see how you came to that conclusion, but I'd offer a different perspective.
The problem in my opinion with the Javascript landscape is, as you said, the fact that it is too fractured.
If you follow the "modern best practices" to make a SPA, you are talking about pulling in at least: npm, webpack, react, react-router, lodash, redux, bootstrap, and perhaps much more.
You are going to need to set up each one of these to play nicely with each-other, and follow tutorials/guides for each one to get them set up before you can even begin to start writing code for your actual application. Just look at the getting started guide for webpack to see how complex this can already be [1].
Why can't there be a consensus on what tooling/libraries are "standard" for writing an SPA React application today? Setting up the above tooling/libraries should not take multiple hours for someone with no frontend experience, but it does.
There are "starter kits" [2] to try and solve this problem, but dear god just look at how many moving parts they already have!
---
My overarching point is this: the Javascript ecosystem does not seem interested in solving this issue ultimately. This fractured-but-whole approach to development seems to be the consensus for that ecosystem. And that's OK.
For a majority of non-frontend devs who would like to enter the frontend, though, it's not okay. And this change in mindset is what WebAssembly can bring. It brings a different ecosystem and a different set of people with diverse mindsets that you just can't find today in the JS ecosystem easily.
[1] https://webpack.js.org/guides/getting-started/ [2] https://github.com/kriasoft/react-starter-kit
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
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.
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.
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.
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.
Err...actually, the theory is hard, and that is a practical problem, because the WASM people actually wanted to have a formal semantics for WASM from the get-go.
That's why they're moving slowly, only releasing what they can specify formally.
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.
Are they here yet? No. Are they performant yet? No idea because they don’t exist.
They’re always brought up by WASM advocates like they solve anything. But they don’t... because the problem isn’t accessing the DOM - it’s doing it performantly in your code and there’s nothing about host bindings that hint they’ll solve that problem any better than JS. So far the signs aren’t positive.
Right, they're not here yet, so you don't know.
> because the problem isn’t accessing the DOM - it’s doing it performantly in your code and there’s nothing about host bindings that hint they’ll solve that problem any better than JS.
WASM solves the problem of allowing languages with different semantics, strong type systems, different paradigms etc. that JS doesn't provide. Some of us care about the language we program in because we want to have somewhat enjoyable experience while doing it and for some JS does not provide that. That is the problem WASM solves. Whether host bindings would give us sufficiently fast access to the DOM isn't clear yet, as you yourself admitted, but I don't see why not and I certainly don't see what you're arguing about here - the problem WASM solves is, again, primarily not about DOM access that is somehow faster than JS, people are even expecting a bit of a penalty, at least initially, but as long as we can get rid of JS monopoly on the front-end, I think WASM achieved its goal.
And neither does anyone posting dumb links to Reddit posts about them or mentioning them like they’re a solution.
Because they aren’t. They might be, but they aren’t yet. Yet WASM advocates like yourself treat them as fully formed solutions to criticism.
Which you kind of have to I suppose: without them WASM is a cool but extraordinarily limited and mostly pointless, outside of some specialized use cases, toy.
Until they are released AND up to par with perf & features (inc accessibility) WASM hasn’t achieved much at all. It certainly hasn’t got rid “of the JS monopoly”. No more than VBScript or Flash did.
As far as I can see, the person who posted the Reddit link just responded to the claim that there's no way to manipulate the DOM as a way of saying that it is known and being worked on. You seem like a bit of an extremist by saying that anyone is claiming it is the solution. It is a potential solution, that's all.
You were the first one to assert what problem WASM supposedly tries to solve, even as not everyone agrees with your assertions. You basically set up a strawman and then shot it down.
> Yet WASM advocates like yourself treat them as fully formed solutions
I, in fact nobody here apart from yourself, has said that they're fully formed solutions, not even close. They're in development, this is not being denied. I am also not an "advocate" for WASM, I made a post explaining why I think it makes sense, that's all. When somebody tells you they like rain, do you respond with "So are you advocating for floods"?
> Until they are released AND up to par with perf & features (inc accessibility) WASM hasn’t achieved much at all. It certainly hasn’t got rid “of the JS monopoly”.
No one is saying it ALREADY DID, we're saying this would be a success, if it did. This is really not that hard to understand. Honestly, I am not sure it's the Reddit posts that are the problem here.
Sure you,ll be able to port different languages to the web but at what cost? The JavaScript library gives a ton of things out of the box. In WASM land one will probably have to compile their standard library of features and send it to browser. So space wise it’s going to be more.
Then you have the debugging problem, browser venders are doing some improvements in this space but seeing how quirky being able to debug minified code is, WASM debuggers will be interesting and that story is weak.
The reason why JS ecosystem is vast is because frontend development is vast. Creating UIs involves a lot of things. Add different browsers to the mix and you get this complexity because different versions of browsers support different things.
To this day you can always create something in Vanilla js. A single .html file with js and css embedded in it. Nothing stopping you. You need nicer tools and libraries when you want to scale the development. This is true for any language.
JQuery - started out as a way to abstract our browser backwards complexity and give standard api. It essentially is a polyfill library with a nicer syntax.
Angular - A nicer way to compose dynamic apps. They piggy back on html syntax and bring templating to it. Same with Backbone and Mustache. Just other libraries.
React/Vdom - View is a function of state. Another way to think about UIs. They bring html to JS with h(tag, attrs, children) calls. This makes building big dynamic UIs easier.
Babel/Typescript - Some browsers support new things, older browsers don’t. A tool to let you write in newer flavor of JS that down compiles to an older flavor depending on what you want to target. Typescript is a way to get more strictness in your code (like a linter). Sure we can get into a way on how Javascript is an aweful language but there are some things it does really well. I love 2018 JS.
Webpack/Rollup - you can ship a giant .js file with all things concatenated but that’s not optimum. You want things to load fast and this means less bytes on the network. Webpack allows you to write code as small modules that depend on each other. Then you give a starting module and it builds you a js and css file with things you need. You can control how things get bundled e.t.c. This is like creating an installer for your app.
In essence, web ecosystem of libraries is vast because the web ecosystem itself is vast. Little libraries let you pick and choose how you want to stack things up to build for your needs.
WASM is a small part of this vast ecosystem solving a specific kind of problem. We’ll still have those 99 other problems.
I would not argue one solution fits all. I think having the ability to write frontend+backend in JS _and_ Go is a good thing.
I mean, I bet that as soon as possibile all the c# consultancy companies - just to pick a common example of big teams using a single language for the backend systems of all the projects of the company - would switch also their frontend to c# when it is supported by all major browsers
But I think it wasn't this easy 2 or 3 years ago.
Other platforms have similar magic, like Visual Studio hides complexity from you but on complex projects or weird issues you will have to learn how it works under the hood(compiler, linker , compiler flags, you may want to drop the GUI for building and use the CLI for flexibility)
I wouldn't call that best practice, more like the hype train. All you really need, at a minimum is a text editor and jQuery. Once you're comfortable with that, you can move on to the more fancy stuff.
I haven't done it, but I'm fairly sure you can use jQuery with Typescript
NPM and Webpack are developer tools, and Bootstrap is a CSS framework. Correct me if I'm wrong but WASM still needs CSS since it generates HTML
As for the others, they're libraries. Optional libraries. There are plenty of optional libraries in the Go ecosystem but we wouldn't say it's "fractured". You can't format a string in Go without importing a string library, but this is acceptable.
Yes, you are a bit wrong. Wasm can also mostly sidestep html and css and write to the canvas directly. Some games compiled to wasm do this. You can imagine that in a near future, it will be possible to use the browser merely as the wasm vm which will run and render your crud written in, say, tcl/tk
You would still need a package manager.
You would still need a view library (React), a router (react-router) and some sort of model or storage (Redux). React originally took a mix-and-match approach, but other popular frameworks like AngularJS and vue.js tried to bundle everything together.
You might also need a style library (not necessarily bootstrap nowadays) or create your own styles from scratch.
And you will need an bundler like Webpack or Browserify, unless you want to make your own with Gulp/Grunt (like people used to do).
You may want a collections utility library such as Lodash or Ramda, though many people go without them nowadays.
Let's so how go would fare here:
There's a new view framework (Vecty) which could eventually grow to bundle its own router, standard components and store (just like the more mature Angular and Vue).
Store, Router, UI components and Styles: MIA?
There are at least 6 widespread competing package management mechanisms: go get, vendored dependencies, godep, Glide, dep and vgo. Hopefully the community will standardize on something (vgo?), but for now, npm and yarn look absolutely fabulous compared to the mess we have to deal with in Go.
Bundler - could possibly be obviated by WebAssembly, but we would need something else that matches what's currently being offered by Webpack (e.g. live reload).
Collection utilities: Fear not! The lack of generic makes it impossible to do with Go, so you'll just have to write boilerplate code.
(The reasoning that a language with a good standard library can obviate the need for Lodash is correct though)
---
My point is that you'll just be getting the same thing again and there is no guarantee you will have a more consolidated standard with Go. The Go community rarely tends to unite around a single solution, unless it's coming from Google.
If you are looking for a language that gives you a single story and a bundled set of tools for doing everything above, there's already one: Elm. And it's been here for quite a while, and still most frontend developers chose Javascript and React, even while they imported Elm's reducer-based data flow model to React (as Redux).
With gowasm you don't need a view library, the "view" library is Go, you can choose to use Go's templating if you want, or you could use a more idiomatic Go system of interfaces that implement a view, with different implementations of those interfaces for different components of your single page app.
With storage Go offers either client side with HTML5 local storage, or backend with simple map[]s for temporary in memory storage all the way to full blown SQL / NoSQL or even distributed decentralised raft options like tendermint. Go offers a much wider ecosystem for storage (client and server side) than even the best JS offerings.
Bundlers / Collections are a red herring in the golang world, golang generally uses monolithic binaries (that tend to be statically compiled where possible) and then use networking to talk between them as a mirror to goroutines and channels internally. golang's package system along with it's tooling (go run vs go build/install) handles "bundling", it's done by the linker / compiler; linking is a well understood problem.
Styles is something that golang would never attempt to handle, it's a CSS thing. Sure there will be libraries that 3rd parties will write to interact with style frameworks (like bootstrap et al), but you just as easily handle that in your own view interfaces.
golang does have a standard vendoring system, true that not everyone uses it; maybe one day it will converge?
And it is very unlikely that go will ever have generics, go has an idiomatic way of handling that with interfaces; probably not everyone's cup of tea, but there it is. You can live without generics.
A lot of the way that Go handles these various issues runs against the grain with a sizeable portion of the programming community, there will always be other options. Ask 10 developers get 11 opinions.
The biggest takeaway though is that WASM is opening up the browser programming interface to more than just JS and its plethora of libraries / frameworks / solutions.
Instead, they think the problem is stuff like:
* developers are not using enough of the design pattern lore developed for use with static manifestly/class-y typed languages like Java
* JavaScript is terrible because you have to think about `this`, because wat, because prototypes, because the aesthetics of another language are better, etc
* mutability or missing functional purity
* the type system isn't type-y enough
* CSS is terrible
* how do you know if you're a real developer if there isn't a build step
* do you even modern bro
And you can route around these problems by switching languages. WASM to the rescue!
I suppose we'll get the chance to find out to what degree those are really The Problem With Development.™
... and, while that is a slightly unfair characterization, I’ve seen many arguments that can be boiled down to that without losing any nuance right here in HN.
It's either an incredibly minority viewpoint, or an incredibly silent majority, though. I think partly because it neatly divides along Static vs Dynamic religious war lines.
I'm going to be really interested in writing some front-end code in Go, just like I was interested in writing some back-end stuff in Node. But I have the feeling that I'll quickly revert back to writing the backend in Go and the frontend in JS. Not out of tradition or tooling, but purely because they've been designed/evolved as better languages for those roles.
The fact that it allows using variety of different language, rather than Javascript, a language which wasn't exactly designed for what it's being used for today by Brendan Eich, is a nice side effect.
Whatever works.
> from what I understand WASM offers from pretty big performance boost over JS and I think that is really where it will shine.
That's exactly the problem WASM was designed to solve. It wasn't meant to solve the perceived problem of a fractured development landscape, it was meant to achieve near-native performance on the web.
As long as modules written in different languages can call into each other, having a broader choice of programming language is a good thing.
I think the majority of 'application style' webpages will have their core parts compiled to WASM from a language that also compiles to native machine code (for the 'native' version of this app -- actually native, not running through Electron that is), and the glue code and HTML UI scripting written in JS (or another scripting language that compiles to JS).
Why would you need to know all of them? Did you need to learn Fortran before you could start making things in Java or C++?
a common compile target makes it easy for developers and companies. Languages and frameworks should never be the common denominator for solution building because it is inflexible.
Web assembly will finally give them a way to do clientside development while avoiding the total disaster that is the Javascript ecosystem. I don't do clientside programming but as a scientist I'm -- very annoyed -- that we have settled for something as bad as Javascript, whilst better languages are languishing.
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.
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.
So if you're building an application, use those frameworks. But if you're building the framework itself, innerHTML is your friend.
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.
[1] https://sourceware.org/glibc/wiki/FAQ#Even_statically_linked...
http://www.etalabs.net/compare_libcs.html
It says musl's smallest static C program can be 1.8k as opposed to glibc's 662k, showing libc doesn't always have to be big and bloated.
Now for heavier applications like graphics or video editing, this would be fine to use.
I agree overwhelmingly with this sentiment. I've been working with JavaScript on an almost daily basis for about 20 years. I very much dislike the new JavaScript environment, it's an atrocious monster of unnecessary complexity (and getting ever worse). Just because things could be done, thanks to dramatically faster JS engines, they were.
The product I'm building now: vanilla JS. No npm, no packages, no package managers, no node, no jquery, no react, no vue, no angular, no webpack, no yarn, no frameworks, no polyfills, etc. It's not even using ES6/7. It's gloriously fast, simple, extremely small in size, universal and nothing more than absolutely necessary. Sub 50kb page sizes, 5x faster load times than Quora or Wikipedia, 20% as many requests (the typical Wiki page makes three dozen or more requests), while still accomplishing everything required for the project (it's a knowledge service).
Push these simple pages through a performance checker:
https://www.quora.com/What-made-George-Washington-a-great-Pr...
https://en.wikipedia.org/wiki/Jack_Dorsey
You'll see 38 requests for Wiki, and 49 for Quora. The simple Quora page has 500kb of scripting junk bloating it and 180kb of css, leading to 1000ms load times. And these are largely considered good outcomes today, that's with billion dollar organizations spending huge sums of money to speed everything up. Oh, the page only has 1mb of unnecessary bloat? A tremendous outcome.
Fuck the new bloated JavaScript and Web dev ecosystem, it needs to crawl back into the hole it came out of and die. There's a better way to build, and it's not by adding vastly more complexity to accomplish the same thing we used to with 5-10kb of JS.
Node, webpack, yarn, npm, frameworks, UMD, AMD, arghhh!
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.
In the process it will be the revenge of plugins.
Instead, projects are mostly using "light" transpilers built to have clean mappings to JS semantics, like TypeScript, where the original source can be recovered and traced by the browser as long as the transpiler generates a source-map.
WASM really won't work with the "source map" paradigm, and so a move to a web where most development uses languages that compile to WASM, is a move to a more opaque, less learnable web. (And also one that browser extensions have far less of an ability to intercede in.)
(written by a non-go-expert)
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
[1] someone should benchmark this.
Which is also a reason why a replacement is being done as part of Project Panama, initially advocated by Charles Nutter due to the JRuby project issues.
http://openjdk.java.net/jeps/191
In alternative, if you have the source code available there is a way not to any transitions.
Java now has GraalVM and .NET had C++/CLI (nee Managed C++) since the beginning.
Web Assembly is gimped because it needs to be compatible with existing JS runtimes - when they add threading support you will no longer be able to run a WASM shim in JS but at the same time WASM will become a lot more general purpose.
Multithreaded WASM isn't here either.
I think WASM will face the same security considerations.
https://github.com/WebAssembly/threads/blob/master/proposals...
There might be a chance to simplify if you're already using Go on the server and you remove a lot of other stuff.
The JS ecosystem is a complicated mess, it's undeniable. But once you take the time to learn it, it's fine. In the majority of cases WebAssembly is just give to give the lazy an excuse to use a language they already know rather than learn something new.
And as for abandoning the DOM... yeah, it's not a great model. But is a dozen incompatible, competing rendering frameworks (that each site downloads separately) going to be good for the web?
For a short period of time, sure.. but the ecosystem evolves quickly, and often in inexplicable ways.
> In the majority of cases WebAssembly is just give to give the lazy an excuse to use a language they already know rather than learn something new.
Most people program in return for money, not for self-satisfaction at learning yet another single-purpose language.
> But is a dozen incompatible, competing rendering frameworks (that each site downloads separately) going to be good for the web?
How is this significantly different from where we are now?
is a weird way of describing learning the language native to the web platform. I don't see a lot of people screaming about having to learn Objective C or Swift to make iOS apps.
> How is this significantly different from where we are now?
Err, because the DOM is a universal standard that comes built-in to every browser? <div style='background:red'/> looks the same everywhere, with no extra code required. If you're building a new renderer from scratch you're going to have a lot more code users need to download.
Now that we think about it, even with the DOM/CSS UI framework built into the browser, people still make use of libraries like jquery so library caching is something the browser needs to do anyway, WASM or not.
For most applications, please don't do that though, unless there's eventually a web accessibility API that's independent of HTML.
Please clarify what this means. Standards are open access and browser engines and JS engines are for the most part (Edge, Safari, Chromium, Firefox) open source, so "closed platform" seems, to me, inaccurate.
> If the people behind wasm were smart, they'd allow generic handles to a graphics context so that people can write/export other rendering frameworks.
Do you see how bloated web browsers are already? Do you really want apps to recreate all of this base functionality, or even to encourage such horrific inefficiency? Hopefully I'm missing something, because this seems like a terrible idea.
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.
The DOM is a relic from the 90s that refuses to die.
Unfortunately, I'm not open sourcing it. Not until I get a proper graphics context, and implement my own rendering engine. I think web assembly is going to revolutionize the web. I see browsers allowing you to cache common libraries/assets, and html/css being replaced by several competing UI paradigms. The one I favour is inspired from functional reactive paradigm, but there are equally valid alternatives. I don't think there will be a single frame work to rule them all, just competing schools of thought. Right now the web doesn't have any competing paradigms, just html, css,and js.
Reason web sucks: HTML/CSS are not suited to define complex UIs with intricate layouts and complex transitions and key frame animation. This problem was better addressed 30 years ago. Look at the menu UIs in games from the n64/ps1 to ps2/gamecube era (I'm talking about the game menus, not the game themselves). Some of them had far more impressive UIs than the webpages of today. This type of UI is an order of magnitude harder with html/css than just doing it all via X11 and C (even with memory management concerns).
The reason for this is that HTML first isn't strongly typed. If you make something complicated, and make a small change, it messes everything up. Your compiler can't help you. HTML tags are somewhat inconsistent. React, Rails etc. are all trying to address this problem. They are all taking inspiration from android, iOS, QT and gtk+ to make it somewhat component based. However, you fundamentally can't achieve this. HTML is in a land of its own, when you create an HTML tag, sure you can wrap it in a JS class, and mimic some of the characteristics that desktop frameworks provide you. You won't get the whole thing. I've seen many times different frameworks reinventing html templates (like handle bars). Templates can't solve all issues.
CSS sucks. The first thing about css that sucks is the "cascading" part of css. It should just be ss. CSS was originally designed to limit bandwidth by having it cascading. That's not the case today, and it messes everything up. The second thing that sucks, similar to why html sucks, is that again css is in a land of its own. It's hard to control css from JS (for interactive site you want this). I'm not even going to talk about how hard it is to position things properly via css when you are building layouts dynamically.
JS just sucks. I don't think I need to elaborate, I've mentioned enough points already.
Every single web framework out there is trying to address some aspect of the problems I mentioned, but my claim is that you can't solve it, you need to start over. Imagine if CPU makers made crappy inconsistent assembly code. Every year a new compilers and languages come out that tries to fix their predecessors. The most logical choice is instead to ditch that chip maker, make a better CPU with a consistent assembly code. You can't do that with web, you can't ditch assembly(html,js,css).
It only took 30 years for the web to get web sockets, webgl and now wasm. I think in another 20 years we'll come a full and get the remaining amenities that modern operating systems provide.
The reason I chose Rust is because it's a low level language with strong typing. It's not quite Haskell, but good enough. Writing a web server and UI with Rust is very nice. It just connects to the backend processes with ease, and doesn't make things awkward the way npm does. I do a lot of low level numerical and mathematical simulations, all done in C/Rust with all coordination & distributed computing done in Rust. I want Rust to take over. The sequence should be: Erlang -> Rust -> C
I chose Erlang because years ago I saw how reactive programming is extremely useful for complex interactions in a AAA game I was working on. In a game system you have the play interacting with the world, with enemies. The enemies interact with the player and each other. The player can pause the game at any point, then you need to bring up a menu screen with its own interactions. I've seen this work flow done in many different ways, and by far the reactive paradigm is the most sane. This was done in a bastardized version of Lua and Lisp.
>> Reason web sucks: HTML/CSS are not suited to define complex UIs with intricate layouts and complex transitions and key frame animation.
CSS does have a concept of keyframes now (I know this may not cover everything you like about flash keyframes, but I figured I'd throw it out there in case you were unaware): https://www.w3schools.com/css/css3_animations.asp
>> This problem was better addressed 30 years ago. Look at the menu UIs in games from the n64/ps1 to ps2/gamecube era (I'm talking about the game menus, not the game themselves).
Those layouts had a known aspect ration, 4:3, and a reasonable expectation of being viewed on a large screen. HTML and CSS are expected to work on a wider variety of screens that may change size and aspect ratio on the fly, possibly during an animation. If I only had to make HTML/CSS animations for use on a normal television screen with a known zoom level in a specific browser, I could make interfaces every bit as beautiful as your N64 games (well... with a competent designer, but my point is that I could write the layout and script the animations). Some of the pain points of HTML and CSS are historical accidents that can't be changed without breaking compatibility, but some of them are quite useful and necessary. Responsive design is a good thing, it just sucks to write an animation that works in a whole range of aspect ratios and zoom levels. It's a problem that Sony and Nintendo never had to design around. The amount to which this constraint cripples and strengthens the web is hard properly convey. I love and hate it, but as time goes on I learn to hate it less and love it more.
>> It's hard to control css from JS (for interactive site you want this)
It's costly, as it touches the DOM, but it's not hard. Just change the class attribute (or even the inline style attribute -- there are cases where this can be argued for). Simple example: https://www.w3schools.com/js/js_htmldom_css.asp
This tells me you hve very little experience with CSS or even HTML. The cascade saves you from declaring "font-size: 16px" in every single element of your page. Think of it as a form of property inheritance
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.
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.
It took 100 years to go from the onset of the printing press to the book form and we are in some weird in between time frame where browsers aren't really enough to do what we want. Conceptually it is going to take something that is revolutionary, yet at the same time extremely familiar... like the book. I bet we would find similar strains in the intervening decades between the printing press and the book.
Games maybe, but for normal applications sounds like would just end up with worse graphics than old Java applets, Swing, etc.
That is not real time, but very difficult to pull off on web (harder than using C++ on desktop! Debugging webGL in JS is a nightmare). I don't see any issues with an ARM processor. The Harvard globe project if done in C++ could definitely run on a 2004 era computer. Most phones these days are much more powerful.
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.
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.
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.
What new capabilities does WASM afford us?
I by no means think JS is beyond criticism, but much of the excitement about WASM revolves around writing web stuff in other languages. Is that really disruptive?
WASM's greatest value on the web is likely to be optimizing high-performance code. Although people want to use it to replace javascript entirely with the compile-to-WASM toolchain of their choice, the actual utility of that is likely to be minimal.
Although in that regard, WASM is objectively better as a compile point than "compiling" to javascript. Having an actual bytecode for the web that isn't proprietary or tied to a single language is better, if not necessarily disruptive.
What, to me, is potentially disruptive about WASM is the potential it offers for archiving, distributing and running "native" software over the web, or if and when thin native clients become available, eliminating the distinction entirely and having a universal, OS agnostic software distribution and installation model based on web caching.
Although we've got a way to go with that, and it may be a stupid and terrible idea. But it would be disruptive.
I 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.
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?
Everything is getting extremely bloated. Can't wait until I need an overclocked Threadripper with 1Gbit Internet to see what the weather forecast is...
Still not quite as good as the original Macintosh from 1984 though.
in 2 years or less, Go, Swift, Rust will be 1/3 of the frontend code
I am not a super expert and maybe someone can enlighten me but I think that is the biggest hurdle.
All united by WASM bytecode.
But, who cares. The web is unfixable at this point.
More details: https://news.ycombinator.com/item?id=12460807
I suspect the WASM port is single threaded and blocks in the GC, but I am not an expert on this.
(see the function names beginning with "gc*")
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.
IMO, the core of modern ES6+ JavaScript is a really nice scripting language that is simpler than alternatives, but doing production JavaScript means contending with all of the other stuff. To be a working JavaScript developer, you need to know multiple ways of doing the same things, from basics like module loading and HTTP requests to UI and concurrency. Legacy and an ecosystem that is fragmented down to the standard library level make JS not the easy option.
Go imho is a lot simpler than Javascript. Not necessarily as a language (although Go is pretty simple, and JS has some very ugly pitfalls). Thing is, getting into the JS ecosystem is an absolute mess. With Go, I felt comfortable with it within a few days. Recently, wanting to create some sort of frontend for a REST API I'm making - I tried getting into "modern" frontend JS, having dabbled in HTML, JS and CSS a decade ago, having created a small internal bootstrap-based app targeted at mobile devices - so I understand the basics
However, the current JS ecosystem? I have no idea where to even start, I haven't even gotten to the point where I would actually have some hacky code that would at least give me an idea how to move forward...
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.
Remeber the desktop RAD platforms, like Delphi and Visual Basic? There is no reason we couldn't have very similar things on the web.
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!
...
> 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. :)