4 ms·
My theory, which I think goes fairly against what others will say here, is that JavaScript/Node is the first truly post-internet environments to reach critical
by tolmasky 10y ago
My theory, which I think goes fairly against what others will say here, is that JavaScript/Node is the first truly post-internet environments to reach critical mass. By post-internet I mean they consider sharing and open source as foundational to the environment (as opposed to tacked on later, or merely supported).
The "JavaScript standard library" (or lack thereof) is a clear example of this: NPM is the LARGEST collection of packages of any language, and you can almost always find someone who has already written what you need most the time. It never ceases to surprise me. During the Pokemon Go craze I was curious to play with the protocol: there was already a package to do it. I wanted to ping my find my iPhone, there's already a package to do that. Its incredible. And yet the actual built in standard library is notoriously lacking. Although not by design, certainly the end result is that that has become "OK" thanks to NPM.
Compare this to something like AppKit (and UIKit), which were very much in the pre-internet/sharing mentality: there is one framework everyone has and becomes experts in and is fairy stable, because its kind of the only thing you can rely on being around. Sharing code is very difficult, to the point where just copying and pasting files is still a valid contender.
The explosion of options and the increase in churn is a natural consequence of this. There are simply more people working on more problems, all encouraged by an environment where sharing code is a fundamental property. If step 1 of setting up node is downloading other people's random packages then it should be no surprise that step 4 of sharing your own packages will seem natural. We should expect this to only get faster -- the more people program, the more crazy ideas will be tried, the more switching there will be. I really don't understand what the alternative is: arbitrarily choosing frameworks to be around for a 5 years (a decade?).
We are simply taking the last measure of stability, which was largely governed by how long it used to take information to disseminate to the entire community, how long it used to take one controlling body to get their large waterfall releases out the door, and using that as an arbitrary comparison point to how long it takes hundred of individuals to release their individual takes on software. Asking to "stop the churn" is a strange request: there's no single entity pushing stuff out "too fast", this is the aggregate affect of all programmers in the node community publishing their ideas. Who are we asking to slow down exactly? I can understand saying the single case of Angular 1/2, but the "JavaScript fatigue" people actually feel is due to the interaction of all the JavaScript projects that each gain and lose popularity.
Unless you believe we're really close to figuring this whole "software development" thing out (whatever that means), I wholeheartedly believe that programming 20 years from now will look more like this -- faster pace of developments.
- inimino 10y ago"post-" usually means after, so I initially thought you were saying the internet is over. Maybe you could say "internet native" or something. I don't think it's true, by the way (the CPAN folks would have a word with you, just to mention one that comes to mind). In response to your point, eventually, most of us who build software just want to use tools we know to get things done. There's a tremendous benefit to having few and highly trusted dependencies. Imagine civil engineering if every week there was a new flavor of concrete with different construction methods and structural properties. Not too many people with a decade or more of development experience think that "downloading other people's random packages" is a fantastic or a confidence-inspiring idea. Ideally, those line-of-business CRUD apps that the modern world runs on should be write-and-forget, not rewritten continuously. This is why "churn" is a bad word to some. And yes, writing CRUD apps is pretty much solved, that is, it hasn't gotten that much more efficient in the last ten years if you look at the best tools.