This feels a lot like a self-fulfilling prophecy that Javascript just happened to be chosen for.
- Javascript is "easy" and the only option for browsers, so lets teach it to beginners.
- We have all of these beginner programmers who can't work on the backend without learning a new language, so lets put javascript on servers.
- CPU, memory, and bandwidth have continued to become cheaper, so lets just run everything in javascript because "we can"
- Let's hire javascript developers because we've made them the easiest to hire for
- It's too expensive to use a different technology because our entire engineering team is javascript developers
I honestly can't fathom the reasons why we've encouraged Javascript to eat the world, but I don't think there's any arguing that it has. Is this good or bad for business in the long term? My personal take is that it isn't, but there are enough variables to make this really difficult to say with any kind of certainty. It feels more like we've just:
- Lowered the bar for acceptable quality over time
- Convinced ourselves that the Javascript ecosystem is a one-size-fits all optimization for time-to-product
> I honestly can't fathom the reasons why we've encouraged JavaScript to eat the world
Who is "we"? The scenario isn't some God-like figure who made the decisions and handed them down to mortals to live with. The reality is more like evolution (one you actually described very well), where many different, independent players are each working in their own interest.
> Lowered the bar for acceptable quality
Define "quality". Especially given the evolution prism, I'd argue that quality is not a rubric like "best technical performance" but rather one like "permits as many people as possible to engage with as many parts of the stack as possible." With that definition of quality, the JS ecosystem is by far and indisputably the king of the mountain. Graveyards are littered with many "best technical quality" options (Betamax, Itanium...).
> time-to-product
Nitpick, the term is time-to-market. What matters is not just building and shipping your MVP (which can be done by one person, who can choose whichever technology stack) but continually shipping at high velocity over time as the company grows, the original engineers leave, etc.
"we" is everyone in the industry. I recognize it's more of an evolutionary thing, it's just my stance that the current environment is pushing us towards an evolutionary dead end.
> Define "quality"
I also agree that software quality is fairly subjective depending on your lense, unfortunately. For example, I wouldn't view quality as permitting as many people as possible to work at every level. Diversity of ideas is great, but I want those ideas to come from folks who have the skillset. If someone who roofs houses decides to pour foundations without gaining the proper skillset or picking up different tools I would view that as a loss of quality, not a gain.
> the term is time-to-market
I chose time-to-product fairly intentionally, because I think the benefits of something like Javascript start to rapidly decay once you start approaching any sort of product maturity. The problem is teams rarely optimize towards stability and quality until they have literally no other option
> I want those ideas to come from folks who have the skillset
When the industry/society comes around and finally can get behind the idea of requiring licensing for software engineers to practice, get back to me :) . Until such a level playing field is imposed on all players, such practices impose a cost that your competitors are not paying, and they will out-manuever you and out-ship you.
> start to rapidly decay once you start approaching any sort of product maturity
Perhaps time-to-maturity then? Because it's besides the point that maturity is a characteristic necessarily of successful products. You find success by iteratively shipping.
> teams rarely optimize towards stability and quality until they have literally no other option
First make it run, then make it stable, then make it optimized. Pre-mature optimization is the root of all evil. This additionally lends focus to why the business can get behind such efforts: you need product flexibility to grow from $0 to $Xmillion/year, then you need to protect the $Xmillion/year so that it's not at risk from incompetence, hackers, etc., then after your user count stops growing, you continue to grow profits by cutting costs (e.g. by using more efficient languages like Rust that let you serve the same customers on less hardware).
This feels a lot like a self-fulfilling prophecy that Javascript just happened to be chosen for.
- Javascript is "easy" and the only option for browsers, so lets teach it to beginners.
- We have all of these beginner programmers who can't work on the backend without learning a new language, so lets put javascript on servers.
- CPU, memory, and bandwidth have continued to become cheaper, so lets just run everything in javascript because "we can"
- Let's hire javascript developers because we've made them the easiest to hire for
- It's too expensive to use a different technology because our entire engineering team is javascript developers
I honestly can't fathom the reasons why we've encouraged Javascript to eat the world, but I don't think there's any arguing that it has. Is this good or bad for business in the long term? My personal take is that it isn't, but there are enough variables to make this really difficult to say with any kind of certainty. It feels more like we've just:
- Lowered the bar for acceptable quality over time
- Convinced ourselves that the Javascript ecosystem is a one-size-fits all optimization for time-to-product