3 ms·

People complain that the JavaScript ecosystem changes too frequently. It is perfectly logical to believe that this is true, while simultaneously believing that

People complain that the JavaScript ecosystem changes too frequently. It is perfectly logical to believe that this is true, while simultaneously believing that allowing new language ecosystems to target the browser, could result in a new ecosystem that is much more conservative and changes at a slower pace than the JS ecosystem for whatever reason (a language with a larger standard library, a language with a different culture etc...). A one time change to another ecosystem and then a slower pace of changes. Who knows if this is will be the case, but it is a logically consistent position to hold, and there's nothing ironic about it.

root_axis 6y ago
It's not logically consistent. Why does it matter whether the tooling compiles down to js or wasm, if anything, expanding the web development ecosystem to include dozens of new languages and frameworks will increase "churn" as many new approaches become popularized on the front-page of HN. It's absolutely no different than a new js framework.
- FridgeSeal 6y ago
  Not being JS, and therefore not having to deal with all the traps that it contains is a pretty big point of difference. It also provides a boost to other languages, which I think is good, there's no really good reason why JS should continue to be the only browser 'blessed' language.
  - root_axis 6y ago
    > therefore not having to deal with all the traps that it contains is a pretty big point of difference. The primary complaint expressed regarding front-end churn is that the landscape is confusing because there is too much tooling and too many options and that they're unnecessary and that people should just use JS, if you're saying "not having to deal" with js is a positive thing then you're implicitly saying "churn" is not a problem since "not having to deal with js" is the only reason that "churn" exists in the first place. Either "churn" is bad and something like rust-to-web is another example of unnecessary tools complicating the landscape or tooling that helps to avoid the warts of js is a good thing and "churn" is a non-issue; you can't have it both ways.
- learc83 6y ago
  That depends on the scope of what you're looking at. Instead of looking at webdev as a whole, if you're just looking at individual ecosystems then while global churn may increase, it's entirely possible that you could move into an ecosystem with a lower level of churn. It's perfectly logical to criticize the JavaScript ecosystem for having too much churn, while calling for a change that will increase Global web development churn, while simultaneously creating another subset of the global ecosystem with a locally lower level of churn--assuming you are only planning on working in that particular ecosystem.
  - root_axis 6y ago
    It's not logical, it doesn't matter if the source code is javascript or not, if it compiles down to js or wasm it is definitionally equivalent to "js churn" because it represents an additional option in the js tooling landscape that a developer has the option of choosing from, rust is no different from typescript or purescript or babel or elm or any of the other variety of options available for producing web applications. If you're suggesting otherwise, you'd have to explain what exactly is bad about churn in general and why those negative properties somehow dissipate based on the source language. Using your logic if every tool in the existing js landscape compiled down to wasm somehow "churn" would be a non-issue, but if that's the case then "churn" must mean something different than what is regularly complained about on every js technology thread on this forum.
    - learc83 6y ago
      You seem to be deliberately missing any point I'm making. I think it's because you've dug yourself in and you're more concerned about winning an argument than in what I'm saying. But here goes. First, I don't care about churn--doesn't bother me. It does bother a lot of people though. Imagine there's a console called a ChurnBox. ChurnBox only runs code written in Churn. The Churn ecosystem is known for adopting and then abandoning frameworks at a rapid pace. People who run Churn teams have a reputation for for quickly adopting the newest Churn framework of the moment. Now you are a developer who wants to work on the ChurnBox, but you absolutely despise learning new frameworks. You could try to find a company that uses Churn with no frameworks, but you're a bit lazy and it's hard to find that kind of thing out just from reading job advertisements, so you stick with your old trust language--Molasses. Molasses is known for its very expansive standard library and its very slow release cycle. The community is also very conservative, so most Molasses developers stick with the standard library and new frameworks are rarely released. One day the company that makes ChurnBox announces that they are going to run code written in a low level language called Chasm that is designed to be easy to compile to. Then some of the Molasses maintainers announce that they are releasing a Molasses to Chasm compiler. You're excited because you think that maybe in the future you can completely ignore the Churn ecosystem, but still get to write programs for the Churnbox. You think that maybe in the future you'll be able to easily find Molasses Churnbox shops to work with that will adopt the conventions of the existing Molasses ecosystem, and thus rarely adopt new frameworks.

root_axis 6y ago

It's not logically consistent. Why does it matter whether the tooling compiles down to js or wasm, if anything, expanding the web development ecosystem to include dozens of new languages and frameworks will increase "churn" as many new approaches become popularized on the front-page of HN. It's absolutely no different than a new js framework.

FridgeSeal 6y ago
Not being JS, and therefore not having to deal with all the traps that it contains is a pretty big point of difference. It also provides a boost to other languages, which I think is good, there's no really good reason why JS should continue to be the only browser 'blessed' language.
- root_axis 6y ago
  > therefore not having to deal with all the traps that it contains is a pretty big point of difference. The primary complaint expressed regarding front-end churn is that the landscape is confusing because there is too much tooling and too many options and that they're unnecessary and that people should just use JS, if you're saying "not having to deal" with js is a positive thing then you're implicitly saying "churn" is not a problem since "not having to deal with js" is the only reason that "churn" exists in the first place. Either "churn" is bad and something like rust-to-web is another example of unnecessary tools complicating the landscape or tooling that helps to avoid the warts of js is a good thing and "churn" is a non-issue; you can't have it both ways.
learc83 6y ago
That depends on the scope of what you're looking at. Instead of looking at webdev as a whole, if you're just looking at individual ecosystems then while global churn may increase, it's entirely possible that you could move into an ecosystem with a lower level of churn. It's perfectly logical to criticize the JavaScript ecosystem for having too much churn, while calling for a change that will increase Global web development churn, while simultaneously creating another subset of the global ecosystem with a locally lower level of churn--assuming you are only planning on working in that particular ecosystem.
- root_axis 6y ago
  It's not logical, it doesn't matter if the source code is javascript or not, if it compiles down to js or wasm it is definitionally equivalent to "js churn" because it represents an additional option in the js tooling landscape that a developer has the option of choosing from, rust is no different from typescript or purescript or babel or elm or any of the other variety of options available for producing web applications. If you're suggesting otherwise, you'd have to explain what exactly is bad about churn in general and why those negative properties somehow dissipate based on the source language. Using your logic if every tool in the existing js landscape compiled down to wasm somehow "churn" would be a non-issue, but if that's the case then "churn" must mean something different than what is regularly complained about on every js technology thread on this forum.
  - learc83 6y ago
    You seem to be deliberately missing any point I'm making. I think it's because you've dug yourself in and you're more concerned about winning an argument than in what I'm saying. But here goes. First, I don't care about churn--doesn't bother me. It does bother a lot of people though. Imagine there's a console called a ChurnBox. ChurnBox only runs code written in Churn. The Churn ecosystem is known for adopting and then abandoning frameworks at a rapid pace. People who run Churn teams have a reputation for for quickly adopting the newest Churn framework of the moment. Now you are a developer who wants to work on the ChurnBox, but you absolutely despise learning new frameworks. You could try to find a company that uses Churn with no frameworks, but you're a bit lazy and it's hard to find that kind of thing out just from reading job advertisements, so you stick with your old trust language--Molasses. Molasses is known for its very expansive standard library and its very slow release cycle. The community is also very conservative, so most Molasses developers stick with the standard library and new frameworks are rarely released. One day the company that makes ChurnBox announces that they are going to run code written in a low level language called Chasm that is designed to be easy to compile to. Then some of the Molasses maintainers announce that they are releasing a Molasses to Chasm compiler. You're excited because you think that maybe in the future you can completely ignore the Churn ecosystem, but still get to write programs for the Churnbox. You think that maybe in the future you'll be able to easily find Molasses Churnbox shops to work with that will adopt the conventions of the existing Molasses ecosystem, and thus rarely adopt new frameworks.