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.

(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