Hacker News Reader

Comment by bketelsen | Hacker News Reader

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.

View on HN

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

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

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

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

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

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

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

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

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

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

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

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

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

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

One of my biggest problems with the existing web stack is how complicated it is. You basically need to be a company with a budget in the hundreds of millions per year to make a functioning web browser.

That gives web browser vendors a ton of control and political power over the internet, a place that ideally is free of all of that. I believe strongly that the Internet would be a more free place and a better place if the barrier to entry to building your own web browser from scratch were an order of magnitude lower.

We keep adding more standards and more practices and more compatibility requirements, and so the cost of making a major web browser is just going up.

Is WebAssembly something that can help us move in the other direction, or is it yet another standard piled on top of the mountain that already exist?

The core of every leading browser is open source. You can create your own browser if you can run the build process. This is how dozens of new browsers have been created over the last 15 years.

But then you don't understand your new browser. Also, as new features arrive in the original browser, you fall behind. You can't even hope to review the new changes, you can either merge them blindly or fall behind.

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.

With one increasingly irrelevant exception, all the major players in the browser space are open source with "fork all you want" licenses. The barrier to entry for a new player from a coding perspective is zeroish.

That's not what keeps new players out and what gives incumbents the edge; what keeps them out is precisely the opposite problem, driven by the fact that it's TOO EASY to launch a new platform. There's enough new players that the novelty is gone and the world is _done_ caring. Nobody gives a damn about your new freedom/speech/privacy/blockchain -oriented browser.

You're not starting from scratch, but that's like saying that the transportation industry would be better off the barrier to entry for designing new bullet-trains from scratch was lower. Like... OK. Sure. Maybe. But that's probably not the crux of the problem.

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

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

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

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

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

We do think about JVM bytecode and CIL, but that is when the time comes to do low level optimizations, or integration issues between languages on the platform.

Silverlight was developed by a major browser vendor (Microsoft), and Dart was developed by another major browser vendor (Google), which also had NaCl and PNaCl on their browser.

Reply on news.ycombinator.com