Microjs: JavaScript Micro-Frameworks and Micro-Libraries
microjs.com
microjs.com
Microjs displays popularity from the release repo, which in my case is low compared to the development repo ( https://github.com/lhorie/mithril.js ), so even the little information that is displayed in the microjs site is not super useful for someone trying to figure out what libraries are worth looking into.
Myself, I primarily use it as a starting point resource for looking at how someone might have tackled a small-ish domain, to minimize getting tripped by caveats I might not be familiar with.
At the same time though, I love having a good list like this. If I could have this for Golang, it'd be a godsend. Having an upkept list of relevant libraries to put things together makes so much possible- if not for certain libraries existing, I don't know that I'd ever have embarked on many of the projects I do. They make me realize how much more is possible.
Have you checked out the Go wiki?
Many programmers suffer from blank canvas fright, which is why they find comfort in frameworks. Frameworks tell the programmer "I've divided your problem for you; just put this kind of thing here and those other things there in those special files in this particular folder" and that somehow is supposed to make it easier for others to join a project (to the detriment of properly modeling the problem domain).
Well, let's be honest - it kind of does make it easier. If I'm joining a Rails team, say, I can skim a project pretty quickly using body-memory knowledge of where stuff is likely to be.
Additionally, I can rely on the assumption that certain common tasks will be abstracted in well-known common ways. I'm not typically going to have to learn a new way to draw URL routes, or run-of-the-mill database queries.
I agree that this is inevitably "to the detriment of properly modelling the problem domain", but it's a real trade-off, not an illusion. Doing things, for example, in 'the rails way' makes parts of your life easier, and the judgement call is whether it makes them more easier than it makes other parts harder. Such is the nature of our line of work (and most others, come to think of it).
Certainly the framework-monolith is not as fashionable now as it once was; but that's hardly surprising, since domains change as well as libraries and frameworks.
Please don't forget to contribute if you see a package you like missing from the readme file.
Also the colors make my eyes bleed, so I had to close after a few seconds. Nice dataset, bad presentation.
Also, can JavaScript developers finally learn how to program instead of looking up 0.03 Kb sized "libraries" for every tiny thing. I'm all for code reusability and 3rd party software, but you need to consider the cost of each dependency in your chain. Small utility one-liners rarely worth a full-blown package.
I've used this resource before and it's actually a really useful way to figure out which different libraries are out there. Sometimes you only need a minor library for what you're doing and chances are this website help you find it really quickly.
I agree that good js developers should be able to code a lot of this themselves. The vast majority of it I have probably coded over my career, that doesn't mean I want to code it again myself - that's just wasteful. I looked at a few < 0.5kb libraries on that list and there tended to be sufficient code to make at least looking at them worthwhile.
Having said that, I often won't put other people's libraries in because I know I'll probably spend more time dealing with the limitations/assumptions and making css play nice as just doing it myself.
Special eye illness? If not, then a little over the top reaction...
Because there is no dead code removal. All of it goes over the wire. Even the stuff you don't use.
If you use a 70kB library, you'll pay 70kB in page weight for it. Even if you only use half of it.
The Closure Compiler can remove unused code if its "advanced mode" is used. However, it requires everything to be annotated and to be written in a particular style. Very few libraries meet these requirements.
Those micro libraries and micro frameworks try to address this issue by doing only one specific thing.
[Personally, I prefer something Dart's built-in dead code removal. I really don't want to think about that stuff. Let me put 30 tween functions into one lib and simply don't ship those functions I'm not using.]