from libraries to frameworks #
The smaller, “helper” libraries, like underscore and jQuery, tend to have better chances of staying relevant. They’re usable both in larger and smaller projects. There are quite a many of these smaller packages, which is not necessarily a bad thing, as they’re usually interchangeable or do many different things. In fact, it looks like the old behemoths are restructuring themselves into more of a modular structure.
Still, massive frameworks like Meteor, Angular, or Ember have higher learning curves and investment cost. Using any of them can be somewhat of a gamble in the long run. The paradox of choice is combined with unforeseeable return of investment.
React.js (and perhaps the different Backbone.js components) fall somewhere between them. They have a smaller learning curve, and they tend to provide a solution to one problem. The Flux architecture recommended to be used with react can in fact be used with or without it. It has multiple implementations, and is indeed not tightly coupled with React.
where do they come from? #
I suspect a piece of the “problem” is that people tend display their Github profile as a demonstration of their skills. While this is totally legitimate and there’s nothing inherently wrong with it, this habit has the side effect of generating the same things over and over again. Companies reap karma by contributing to open source and helping out the community.
Instead of contributing to an existing library, and solving some of the more difficult problems there, it’s easier to start from scratch. Doing something on your own surely takes time, but is perhaps considered more worthy, original and sexy. Your personal stamp as a creator can be uplifting for your ego.
So instead of collaboration, we get this weird kind of self advertisement. It’s definitely better than nothing, as good can arise from even the smallest of efforts. It is somewhat analogous to the “20% non-billable / own projects” or “ship/fedex day” mentality.
Quite many of the libraries are indeed legitimate ones, and solve real-world problems. They reuse ideas from other languages. Forking a project can disperse the effort, but it can allow more experimentation and faster development speed. There’s good and bad.
“If you do anything in 2015, please make more libraries and frameworks. We don’t want a totalitarian open source community, we want a big wonderful mess, because open source is an ongoing conversation with no truly right solutions.” - Alex R. Young, from the now-defunct dailyjs.com
ageing in reverse #
There’s softish this rule of thumb about non-perishable things that applies to software development too. What has been in existence for a some time, is prone to stick around roughly the same amount of time.
Languages evolve and one can argue that ES 6/7 will have assimilated some things from Underscore and Coffeescript, making both of them useless. But the situation might be interpreted as either being around forever. One cannot be certain, as these are indeed predictions, but the statistics usually favour the older technology.
Thinking about this helps myself with pressure of learning all those new and shiny things that keep popping up. The shelf life of the hottest new library can be surprisingly small these days.
Learning complex libraries will take time, so choosing a library can be daunting. No matter how soon a library becomes obsolete, the time spent learning something new is never time totally wasted. The only problem is, of course, something must be postponed or given up because of that spent time. Learning is good for your brain, it encourages the formation of new synapses and whatnot, keeping your brain “younger” and helping against degenerative diseases.
After investing time learning some specific skill, people can overvalue that skill, and expose themselves to the sunk cost effect. We should be willing to consider new options and approaches, even if they invalidate our current skills or status. Trying to enforce our current position and skills and working with outdated technologies or models rarely lead to positive end results. We should, therefore, be comfortable to be beginners again.
The worry of wasted time can lead to stagnation and lack of confidence in decision making. Since the offering is so vast, there arises a need for some kind of curation. While researching for this, I stumbled upon this great source of different tactics.
In short, follow notable people on twitter, read blogs, listen to podcasts and go to events. Look to placing yourself amidst of other interested and enthusiastic people. The most time-effective way to achieve this is to have your colleagues to be the ones filtering that signal from all the noise, with yourself of course participating.
to understand is to perceive patterns #
Instead of actively trying to learn a new library, I try to observe the actual ideas and patterns behind them. So instead of concentrating on a specific implementation, I believe it’s more important to understand the implications of the underlying idea. Observing the adoption or rejection of an idea or a pattern is vital. The adoption of technology reaching critical mass, the “tipping point”, is getting faster and faster. As is the rejection of previously hot ideas.