4 ms·

> Consider this. if you chose SilverLight a few years back, your product is soup today. The amazing part about JS is that most of the code written for browsers

> Consider this. if you chose SilverLight a few years back, your product is soup today. The amazing part about JS is that most of the code written for browsers a decade ago still works today. It is extremely unlikely that we will see a company outright ban JS in their web browsers in the same way that iDevices don't support flash.

Silhouette 10y ago
The amazing part about JS is that most of the code written for browsers a decade ago still works today. Yes, that is mostly true, but it glosses over two big problems with the JS ecosystem. The first is that longevity seems to be a dirty word. I have seen professional JS developers say, without a hint of irony, that their code only needs to last a year, maybe two, so it doesn't need to be designed for long-term maintenance or ongoing development. That same attitude exists in much of the library and tool development, which means while your code might still run in 2 or 5 or 10 years, the dependencies for your code might not have kept up. Even if they still run, they're stuck at whatever level of features and security and flexibility they had when they were abandoned, which might well have been only six months or a year after you added them to your project. Now you have a perma-brake applied to everything you do. The other big problem with the JS ecosystem is that JS itself is a moving target. Thanks to evergreen browsers, Node, and those controlling them, standardisation and stability also seem to be dirty words now. Your code from 10 years ago, using only basic JS language features, might still run. Unfortunately, your code from 2 years ago, using whatever alpha/beta quality JS features supported promises or observers or local storage at that time, might not. And the same goes for code in dependencies you introduced 2 years ago that are already abandonware. Multiply those two factors and you have a recipe for instability and frequent unexpected failures unlike anything I have ever seen on any other platform.
- deleted 10y ago
  [deleted]
- thesagan 10y ago
  Agreed. Adding to your point: If this were NASA, memories of Apollo 1 "go fever" would be a fitting analogy of our present circumstance. "Nothing we did had any shelf life" was one of the core problems identified by Gene Kranz in his "tough and competent" speech to his mission control team after the fire. I think it's a salient point. When all the parts are constantly churning, fires are to be expected. Progress is messy if we're not cautious, and I'm not sure if we are being cautious in the right places. We could learn from Mission Control. (Lots of room for debate, here! And I'm being purposefully vague.)

Silhouette 10y ago

The amazing part about JS is that most of the code written for browsers a decade ago still works today. Yes, that is mostly true, but it glosses over two big problems with the JS ecosystem. The first is that longevity seems to be a dirty word. I have seen professional JS developers say, without a hint of irony, that their code only needs to last a year, maybe two, so it doesn't need to be designed for long-term maintenance or ongoing development. That same attitude exists in much of the library and tool development, which means while your code might still run in 2 or 5 or 10 years, the dependencies for your code might not have kept up. Even if they still run, they're stuck at whatever level of features and security and flexibility they had when they were abandoned, which might well have been only six months or a year after you added them to your project. Now you have a perma-brake applied to everything you do. The other big problem with the JS ecosystem is that JS itself is a moving target. Thanks to evergreen browsers, Node, and those controlling them, standardisation and stability also seem to be dirty words now. Your code from 10 years ago, using only basic JS language features, might still run. Unfortunately, your code from 2 years ago, using whatever alpha/beta quality JS features supported promises or observers or local storage at that time, might not. And the same goes for code in dependencies you introduced 2 years ago that are already abandonware. Multiply those two factors and you have a recipe for instability and frequent unexpected failures unlike anything I have ever seen on any other platform.

deleted 10y ago
[deleted]
thesagan 10y ago
Agreed. Adding to your point: If this were NASA, memories of Apollo 1 "go fever" would be a fitting analogy of our present circumstance. "Nothing we did had any shelf life" was one of the core problems identified by Gene Kranz in his "tough and competent" speech to his mission control team after the fire. I think it's a salient point. When all the parts are constantly churning, fires are to be expected. Progress is messy if we're not cautious, and I'm not sure if we are being cautious in the right places. We could learn from Mission Control. (Lots of room for debate, here! And I'm being purposefully vague.)