7 ms·

(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

(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
Best practice is to use a zero-config build tool like create-react-app or angular-cli. Or a next-gen static site generator like GatsbyJS. From the developers point of view this is one moving part and one devDependency. I think your assessment of the SPA ecosystem is out of date, it has stabilised hugely in the last few years.
- slimsag 8y ago
  Interesting! Thank you for mentioning that. I think that does resolve a lot of the problems I have mentioned, but it is still telling that I've tried to start two React SPAs in the past two years and didn't manage to find create-react-app. I wonder how many others are in the same boat.
  - smsx 8y ago
    It depends on how long ago you last tried to make a React app. If it was recently, I'm quite surprised you didn't find it as it's heavily mentioned on the official React site, but if was say earlier than a couple years ago, that would be understandable.
  - unscaled 8y ago
    It's right there in the official tutorial: https://reactjs.org/tutorial/tutorial.html#setup-option-2-local-development-environment https://reactjs.org/tutorial/tutorial.html#setup-option-2-lo... But I think it wasn't this easy 2 or 3 years ago.
- simion314 8y ago
  create-react-app or similar tools work only for toy projects , in the end you are forced to learn how things work under the hood, this includes all the automagic tools, eventually something goes bad or you need to change something and you are forced to go dig and look at the code.
  - Wintamute 8y ago
    I'm a senior JavaScript dev and consultant - we ship create-react-app and angular-cli apps to production frequently, having to eject and dig into the build process is the exception rather than the norm. The win for keeping things zero-config is so huge, its worth working around some of the restrictions.
    - simion314 8y ago
      I assume that most senior developers in the team had to learn all the components used and how they work, you can use npm without knowing what package.json is but you will have to learn the details eventually, if you use gulp you will have to learn how to edit the gulp file when you need to do a specific task,l you probably had to learn what source files are and how to set them up and others. If you do not know this eventually you will have to learn them. 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)
randomfool 8y ago
I'm tired of the 'too fractured' trope. Backend programming is too fractured too then- should I use Java? Go? Python? Rust? What database? What build system? What CI system? Frontend is massive, why would one suppose that a single solution would work for everyone? Horrible metric, GitHub stars: - 104k React - 58k Angular.js - 43k Go - 42k WebPack
- slimsag 8y ago
  The backend can also be too fractured. Isn't that one of the reasons why people pitch Node.js for backend applications? "Write in one language, reduce fracturing"? 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.
  - yulaow 8y ago
    It could actually very good for productivity for teams who use other languages in the backend. 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
- AsyncAwait 8y ago
  For back-end programming, once you pick up a language, you use its standard set of tooling like you would for every other type of program and by making a choice of language, you can select the style of programming you prefer, (functional, OO), or tap into your existing knowledge. With JavaScript, it is the only choice available, so if you want a different style of programming you have to involve all kinds of additional tooling in addition to the language's native tooling, on top of having to involve JavaScript's tooling, frontend package manager, backend package manager, transpillers, babel, gulp etc. etc. it's just a mess, not really comparable with having to invoke Bundler or Cargo for the backend side of things. > Frontend is massive, why would one suppose that a single solution would work for everyone? The problem is that JavaScript is the single solution that essentially has to work for everyone right now, hence the push for WebAssembly.
orange8 8y ago
> 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. 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.
- lewisinc 8y ago
  That's true and definitely the fastest route to take - but if you were to tell me I was going to take over maintenance of a JQuery project at this point, I would be visibly upset. After working in an environment where two-way databinding is "free" and some measure of type-safety is available, it's hard to go back. I just have more drive to work on projects where I don't need to manually wire up every onChange event under the sun and coordinate data-flow through some observer. Not if I can help it.
  - orange8 8y ago
    JQuery is a low level DOM library, so "JQuery project" in reality is an SPA thats built without any kind of architectural framework. You can just start with jQuery and build a maintainable, robust SPA on top of it - if you had the time and resources. Infact, frameworks like angular started out with having "a light jquery core" which they then built on top of.
  - GordonS 8y ago
    > some measure of type-safety is available I haven't done it, but I'm fairly sure you can use jQuery with Typescript
roryisok 8y ago
> to make a SPA, you are talking about pulling in at least: npm, webpack, react, react-router, lodash, redux, bootstrap 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.
- bigato 8y ago
  > Correct me if I'm wrong but WASM still needs CSS since it generates HTML 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
  - roryisok 8y ago
    Fair enough. I was going off the linked article in which he generates html in Go. Tcl/tk is cool, but wouldn't you have to import it just like bootstrap?
    - bigato 8y ago
      I used tcl/tk just as an example and because i love it :) But you could say the same about gtk, qt, etc. Or flutter. And yes, you would have to import the libs and some libs are not small, right? But this is also a problem that we face nowadays already, where the stack in a typical "modern" website requires the download of css and js frameworks that often weigh more than one megabyte of code. Maybe once wasm is popular enough, the web browser will start shipping common stuff like libc when you install it? And then it would start resembling an OS instead of a VM. I don't know if I like this idea, but it seems to be the direction we're heading to. We started with the browser being a system to access documents that can link to each other, and at some point a scripting language was introduced. Over time, it started being used as a application distribution plataform. Then people realized that maybe bending the scripting language to achieve that was becoming too much, and wasm was born. Now the browser is a VM. Soon we'll find out that we don't need a VM, but a distributed OS instead. And maybe we will look again at what Plan9 already did in the 80's.
unscaled 8y ago
I fail to see how Go would help to solve the lack of complexity. 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).
- tankenmate 8y ago
  Go already has a built in router in it's standard library, sure it's more targetted at the server side, but extending to the client side wouldn't be a huge effort. 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.

Wintamute 8y ago

Best practice is to use a zero-config build tool like create-react-app or angular-cli. Or a next-gen static site generator like GatsbyJS. From the developers point of view this is one moving part and one devDependency. I think your assessment of the SPA ecosystem is out of date, it has stabilised hugely in the last few years.

slimsag 8y ago
Interesting! Thank you for mentioning that. I think that does resolve a lot of the problems I have mentioned, but it is still telling that I've tried to start two React SPAs in the past two years and didn't manage to find create-react-app. I wonder how many others are in the same boat.
- smsx 8y ago
  It depends on how long ago you last tried to make a React app. If it was recently, I'm quite surprised you didn't find it as it's heavily mentioned on the official React site, but if was say earlier than a couple years ago, that would be understandable.
- unscaled 8y ago
  It's right there in the official tutorial: https://reactjs.org/tutorial/tutorial.html#setup-option-2-local-development-environment https://reactjs.org/tutorial/tutorial.html#setup-option-2-lo... But I think it wasn't this easy 2 or 3 years ago.
simion314 8y ago
create-react-app or similar tools work only for toy projects , in the end you are forced to learn how things work under the hood, this includes all the automagic tools, eventually something goes bad or you need to change something and you are forced to go dig and look at the code.
- Wintamute 8y ago
  I'm a senior JavaScript dev and consultant - we ship create-react-app and angular-cli apps to production frequently, having to eject and dig into the build process is the exception rather than the norm. The win for keeping things zero-config is so huge, its worth working around some of the restrictions.
  - simion314 8y ago
    I assume that most senior developers in the team had to learn all the components used and how they work, you can use npm without knowing what package.json is but you will have to learn the details eventually, if you use gulp you will have to learn how to edit the gulp file when you need to do a specific task,l you probably had to learn what source files are and how to set them up and others. If you do not know this eventually you will have to learn them. 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)

randomfool 8y ago

I'm tired of the 'too fractured' trope. Backend programming is too fractured too then- should I use Java? Go? Python? Rust? What database? What build system? What CI system? Frontend is massive, why would one suppose that a single solution would work for everyone? Horrible metric, GitHub stars: - 104k React - 58k Angular.js - 43k Go - 42k WebPack

slimsag 8y ago
The backend can also be too fractured. Isn't that one of the reasons why people pitch Node.js for backend applications? "Write in one language, reduce fracturing"? 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.
- yulaow 8y ago
  It could actually very good for productivity for teams who use other languages in the backend. 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
AsyncAwait 8y ago
For back-end programming, once you pick up a language, you use its standard set of tooling like you would for every other type of program and by making a choice of language, you can select the style of programming you prefer, (functional, OO), or tap into your existing knowledge. With JavaScript, it is the only choice available, so if you want a different style of programming you have to involve all kinds of additional tooling in addition to the language's native tooling, on top of having to involve JavaScript's tooling, frontend package manager, backend package manager, transpillers, babel, gulp etc. etc. it's just a mess, not really comparable with having to invoke Bundler or Cargo for the backend side of things. > Frontend is massive, why would one suppose that a single solution would work for everyone? The problem is that JavaScript is the single solution that essentially has to work for everyone right now, hence the push for WebAssembly.

orange8 8y ago

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

lewisinc 8y ago
That's true and definitely the fastest route to take - but if you were to tell me I was going to take over maintenance of a JQuery project at this point, I would be visibly upset. After working in an environment where two-way databinding is "free" and some measure of type-safety is available, it's hard to go back. I just have more drive to work on projects where I don't need to manually wire up every onChange event under the sun and coordinate data-flow through some observer. Not if I can help it.
- orange8 8y ago
  JQuery is a low level DOM library, so "JQuery project" in reality is an SPA thats built without any kind of architectural framework. You can just start with jQuery and build a maintainable, robust SPA on top of it - if you had the time and resources. Infact, frameworks like angular started out with having "a light jquery core" which they then built on top of.
- GordonS 8y ago
  > some measure of type-safety is available I haven't done it, but I'm fairly sure you can use jQuery with Typescript

roryisok 8y ago

> to make a SPA, you are talking about pulling in at least: npm, webpack, react, react-router, lodash, redux, bootstrap 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.

bigato 8y ago
> Correct me if I'm wrong but WASM still needs CSS since it generates HTML 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
- roryisok 8y ago
  Fair enough. I was going off the linked article in which he generates html in Go. Tcl/tk is cool, but wouldn't you have to import it just like bootstrap?
  - bigato 8y ago
    I used tcl/tk just as an example and because i love it :) But you could say the same about gtk, qt, etc. Or flutter. And yes, you would have to import the libs and some libs are not small, right? But this is also a problem that we face nowadays already, where the stack in a typical "modern" website requires the download of css and js frameworks that often weigh more than one megabyte of code. Maybe once wasm is popular enough, the web browser will start shipping common stuff like libc when you install it? And then it would start resembling an OS instead of a VM. I don't know if I like this idea, but it seems to be the direction we're heading to. We started with the browser being a system to access documents that can link to each other, and at some point a scripting language was introduced. Over time, it started being used as a application distribution plataform. Then people realized that maybe bending the scripting language to achieve that was becoming too much, and wasm was born. Now the browser is a VM. Soon we'll find out that we don't need a VM, but a distributed OS instead. And maybe we will look again at what Plan9 already did in the 80's.

unscaled 8y ago

I fail to see how Go would help to solve the lack of complexity. 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).

tankenmate 8y ago
Go already has a built in router in it's standard library, sure it's more targetted at the server side, but extending to the client side wouldn't be a huge effort. 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.