If anyone's interested in anedoctes from a library dev point of view, I've my framework listed there (it's called Mithril), and microjs is not a big source of traffic despite microjs being around for a while.
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.
It's funny; As I get better at any given language or system, I inevitably move away from frameworks into individual libraries more and more. I don't think it's to be effective as much as because it's fun to force yourself to learn the things you just don't when someone else has handled it for you; then again, I still use Rails in my day job and Ember for my side projects.
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.
> As I get better at any given language or system, I inevitably move away from frameworks into individual libraries more and more.
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).
> 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
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.
Most of these "libraries" are way less than 1 Kb in size, so why is it a factor so important it must be emphasized this much?
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.
> why is [file size] a factor so important it must be emphasized this much?
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.]
The biggest problem with just writing some actual JS is a poor compatibility; when you try to generalise some one-liner working in a cutting edge browser you usually end up with a small library, plus the process is pretty painful. Thus those libraries' value mainly lies in research and testing required to make them work rather than in their core function.
I like this as a reference & have used it, but to be honest between the npm registry & bower registry this site feels pretty redundant. I believe most of the tools on this site are in one of the aforementioned registries. I think the main utility of this site is to teach jQuery-only users that there's more than one way to skin a cat.
I've been looking for a library that handles the CRUD forms, but is not tied to a specific back-end... I don't see a category for that kind of thing. Anyone know of anything like this?
The really important thing here is that these libraries have no dependencies, so, unlike npm libraries, you can plug them in a no-CommonJS environment, like a browser, and them will do their work, you won't need any browserify or other stuff.
Looks like a useful resource. It's a little strange that you have to scroll through the entire list of libraries to get to the description at the bottom though.
interesting and useful content. nice presentation. this page will help me learn more about development by enumerating needs that exist and possible solutions.
I like the idea, but can't love the design just yet. The information density is a bit low for me, and I'd like to be able to filter in more ways. Promising though.
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.