16 ms·

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 co

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.

napo 8y ago
"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
slimsag 8y ago
(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
tagrun 8y ago
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.
wwweston 8y ago
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.™
- abritinthebay 8y ago
  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.
- marcus_holmes 8y ago
  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.
- mmargerum 8y ago
  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.
resource0x 8y ago
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"
drbojingle 8y ago
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.
behindmyscreen 8y ago
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.
nomel 8y ago
My unfounded prediction is WASM used to rendering to canvas, bypassing DOM completely, more or less separating the front end from the browser.
SquareWheel 8y ago
>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++?
tptacek 8y ago
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.
- deleted 8y ago
  [deleted]
- orange8 8y ago
  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..
  - varjag 8y ago
    So your solution is.. everyone sticks to JavaScript?
    - orange8 8y ago
      For front-end development? YES
- irundebian 8y ago
  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.
flohofwoe 8y ago
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).
Vinnl 8y ago
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.
ospider 8y ago
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.
armitron 8y ago
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.

napo 8y ago

"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

slimsag 8y ago

(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

tagrun 8y ago

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.

wwweston 8y ago

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

abritinthebay 8y ago
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.
marcus_holmes 8y ago
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.
mmargerum 8y ago
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.

resource0x 8y ago

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"

drbojingle 8y ago

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.

behindmyscreen 8y ago

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.

nomel 8y ago

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

SquareWheel 8y ago

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

tptacek 8y ago

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.

deleted 8y ago
[deleted]
orange8 8y ago
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..
- varjag 8y ago
  So your solution is.. everyone sticks to JavaScript?
  - orange8 8y ago
    For front-end development? YES
irundebian 8y ago
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.

flohofwoe 8y ago

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

Vinnl 8y ago

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.

ospider 8y ago

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.

armitron 8y ago

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.