Hacker News Reader

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

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.

WASM solves a set of problems orthogonal to most JS use though.

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.

> It doesn’t touch the DOM and there’s a VERY good reason for that.

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.

Right, but the core reason they’re doing it that way is that it is a hard problem to solve practically speaking (rather than theoretically) without tanking perf.

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.

> hard problem practically (rather than theoretically)

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.

Javascript is a horrible language, this by itself is a good enough reason to use something else to a lot of people out there. I think the number of programmers who are currently doing JS but hate it and would jump to something else the moment it becomes viable is enormous.

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.

https://www.reddit.com/r/WebAssembly/comments/7wlmjt/will_wa...

Yes, I’m very familiar with host bindings.

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.

> Are they here yet? No. Are they performant yet? No idea because they don’t exist.

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.

> Right, they're not here yet, so you don't know.

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.

> And neither does anyone posting dumb links to Reddit posts

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.

WASM is treated like this God like abilities. I’ve spent time playing with it on and off every couple of months.

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.

Seriously go has 43k stars? Either I’m missing something or software development commoditisation is much more extensive that I’d have thought possible...

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.

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

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.

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.

It's right there in the official tutorial: https://reactjs.org/tutorial/tutorial.html#setup-option-2-lo...

But I think it wasn't this easy 2 or 3 years 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.

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.

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.

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)

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

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.

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.

> some measure of type-safety is available

I haven't done it, but I'm fairly sure you can use jQuery with Typescript

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

> 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

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?

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.

JS and CSS libraries can be cached so that in theory you only need to download it once for several apps. The large file size with Js apps is more commonly the app itself, transpiled for older browsers using Babel. That makes for some massive code. But changes are coming. Webpack can compile separate versions for es6 compatible and incompatible browsers so only IE need download the monster Js file and chrome and Firefox can have light code of just a few hundred kb

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

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.