Hacker News Reader

Comment by superfrank | Hacker News Reader

Problem: The Javascript landscape is too fractured and complicted. There's too many different frameworks and technologies that can be used to write front end code. There's no way I can be expected to know all of them.

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.

View on HN

(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/ [2] https://github.com/kriasoft/react-starter-kit

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.

The reason the solution doesn't seem to fit the problem is that lots of developers don't think the problem with front-end web dev is tooling/framework complexity or overdiversity.

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

I always characterize it as “the problem with web development is that it doesn’t work how my favorite language works and UI is easy anyhow, lol”

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

yeah. I love Go and I enjoy javascript. For completely different reasons, and many of the things I love about Go I hate about JS, and vice versa.

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.

My background is strongly typed languages and I’ve been doing it for almost 30 years. I recently built an app in js/vue and I loved it. JS is incredibly powerful. I never really enjoyed writing a bunch of scaffolding anyhow.

The problem wasm addresses has nothing to do with the fractured state of javascript frameworks. It's about turning the browser into a virtual machine for performance reasons and started with asm.js.

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.

Why should web front-end be any different than the rest of software development? There's much more diversity on the backend than there is on the front-end, and nobody complains about fragmentation.

Whatever works.

Because it's wise to not put too much complexity on browsers which in the end have to process and parse all inputs from front-ends. While on the rest of software development (e. g. desktop applications) you're mostly free to decide if you install untrusted code or not, the web only works if you allow untrusted code to be executed on your machine.

I've seen so many comments and articles over the years viciously bashing PHP, then within PHP itself, there's atleast 100 different frameworks, and the same bashings going on - just ask a drupal dev what they think of a wordpress dev. And this is just within PHP; there's still python, .NET, java, ruby etc to talk about..

So your solution is.. everyone sticks to JavaScript?

For front-end development? YES

You're already hinting at why it doesn't make sense to you:

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

I don't care what programming language a native program is written in, why should I care what web applications are written in?

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

"Before you at least knew a front end project was probably written in JS, now... who knows?" => Not really. Don't forget about CoffeeScript, Dart, TypeScript, ScalaJs, Fable, ClojureScript, etc

>There's too many different frameworks and technologies that can be used to write front end code. There's no way I can be expected to know all of them.

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++?

My unfounded prediction is WASM used to rendering to canvas, bypassing DOM completely, more or less separating the front end from the browser.

Think of WASM like you think of assembly code for the desktop. C, C++, Delphi, etc....All with their own libraries and frameworks to do the same thing...namely, not write desktop apps.

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.

wasm is not just about using other languages in the browser, it allows you to reuse many different libs that are well-written in other languages. For example, in my company, we compiled ffmpeg in wasm so that people can actually edit videos in the browser.

I think the advantage of wasm (at least eventually) will be for people who know c++ or rust or go and want to make web apps without having to learn a whole new ecosystem.

There are a lot of people out there that don't want to deal with Javascript or (worse) Node.js. since they consider them to be abominations. Life is too short to be spending it in these environments.

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.

Interesting... Those of us who thought "web technologies" have reached the peak of absurdity were proven wrong. Again. Never underestimate the power of human creativity! :) But seriously, I believe the cycle is over now. The darkest hour is just before the dawn :) Something much simpler will come up, like JSON at the peak of "XML revolution"

Reply on news.ycombinator.com