7 ms·

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) app

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.

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.