I make GoJS, a HTML canvas-based diagramming library with all sorts of useful features. Node and link concepts (with data binding, templating), layouts, an undo manager, lots of customizable tools, drag and drop/cut and paste.
In other words, a very rich set of diagramming features atop HTML5 canvas.
I think its cool, because it took two years of canvas tomfoolery to get working well, and I think its much faster than similar diagramming libraries for canvas out right now. A lot of technically interesting stuff was encountered while making it, but I haven't had the time to write about my collected intricacies yet.
Firefox warning for that specific sample though. I need to change the default sample this week.
http://browserify.org/ because it will fundamentally change how you approach writing and organizing front end code. The moment you stop writing boilerplate code to glue your disparate files together and start using a simple module system you will never look back. This is more than a library, it is a way of re-thinking how you can maintain js libraries going forward.
I found that browserify tried to do too much by emulating Node within the browser so wrote JoinJS which just implements CommonJS modules without trying to parse the JS files: https://github.com/olegp/joinjs
Even though it's not "cool" in the sense that it's very low level and doesn't do fancy UI stuff, my asynchronous code has become significantly cleaner and easier to maintain through using promises rather than having callback pyramids. The ability to wait for a number of promises to resolve before firing the next makes life so much easier too.
It breaks down large frameworks like jQuery, Underscore, Backbone, Twitter Bootstrap, etc into small, reusable, and composable micro libraries. There are UI elements like tool tips and modals, wonderful and tiny DOM manipulation tools, well documented AJAX libraries, and more low-level functional and control-flow related tools. It's really amazing.
It's by TJ Holowaychuk too, who is huge in the node community (Express, Jade, Mocha, Stylus, Connect, and many others).
Prototype.js seemed to be targeting the problem of providing a familiar class system, standardizing some functional features, and some utility functions. It was something else, and I loved experimenting with it and reading the source, but ultimately, I think fewer people were finding this to be their pain point with the language or that using it made them significantly more productive.
Of course, considering the fact that they seem to solve different problems, it may be an interesting question why they were fighting for mindshare in the same space.
Because Prototype does what the name says, i.e. pollutes the prototype chain. Also, Prototype tries to monkey 'classical inheritance', whereas jQuery encourages chaining, which obviously people like more.
d3 is an amazing library, both for the beauty of the framework API itself, and for how it can be used not just for SVG manipulation, but for general DOM manipulation itself. The power of d3.js is just beautiful.
I'm a huge fan of Enyo (http://enyojs.com). It's stupid-easy to get a native-feeling app running that works across (nearly) every modern device. Mostly, I love its UI components (which are expanded by the associated Onyx library), which means I have less lines of code to write -- which is always better.
This is going to be the most shameless plug I've ever done in my life, but I actually believe my css selector engine ( https://github.com/chjj/zest ) beats every other one into the ground in terms of speed, features, and extensibility. I've probably just been waiting for an opportunity to shout it from the rooftops. Unfortunately, it's kind of hard for a selector engine to gain momentum since people don't really use them standalone unless they're writing a dom library.
It's not the coolest, but I think it's the coolest selector engine. I'm also totally biased.
Amazingly, work on Flapjax dates all the way back to 2006! Let that sink in ... the point is that it was way ahead of its time, and with all due respect to bacon.js, I think Flapjax is still in in a league of its own with respect to how it's implemented.
I studied the internals for months back in 2010, and that learning experience was a huge catalyst in pushing me toward functional programming, Clojure and ClojureScript.
The reason Flapjax never quite caught on was in part, I think, that it was so ahead of its time. And also that its internals, while well engineered, are much harder to understand than those of jQuery and other popular libraries. It's harder to use something truly effectively if you can't quite wrap your head around how it works, and understanding Flapjax certainly takes dedication.
My vote is for TypeScript (http://www.typescriptlang.org/). It fixes some of the problems that I encountered while creating an enterprise class application and not being able to strongly type parameters, classes, etc (which meant that I had to open up every JS file to figure out what parameters a function truly required).
Knockout (http://knockoutjs.com/) definitely rocked my world. Forget about manipulating the DOM with code (using jQuery or anything): now you have a nice separation between your UI (defined declaratively) and your business logic. Just change some observable values and voila, your UI is updated. I strongly recommend trying the site's tutorial: http://learn.knockoutjs.com
Why I think it's cool? Well it's really fast, and it's lazy which allows you to work with really big arrays. Plus it's a really tiny library providing you with a streamlined set of APIs for working with lists (similar to array.js/Enumerable)
If you're working with smaller lists it's probably best to go the lodash route, but if you want it to be lazy then I believe lz is the right tool for the job.
Just instantiate a model with an endpoint and an ID and Backbone will do all your syncing for you. You can have views listen for changes to the models and update automatically. You can add easy support for client-side navigation via push state.
Backbone takes tedious tasks and makes them fun. Highly, highly recommended.
Pretty difficult to parse "coolest JS library". The "42" for that question came up as "it depends for what" ;-)
Anyway, I use this site as a quick reference to see what is new in JS world. www.functionn.in
The author seems to be pretty meticulous in his updates, so there's a lot of interesting libraries. Seems like a labour of love for him. (P.S: Thanks, Hirvesh)
There's also Hakim who comes up with some interesting stuff from time to time www.hakim.se
Speaking of data tables, I wrote a little function to make table headers sticky so they stay at the top of the viewport as you scroll down a large table. https://github.com/kingkool68/stickyHeader No options, just include on the page, add a class of stickyHeader on the table and you're done.
Shameless plug here but I'd say Common Node is pretty good: https://github.com/olegp/common-node - it lets you write your server using a synchronous style while retaining the low memory usage and quick start up speed of Node.js.
For example https://starthq.com is using about 35MB of RAM and is easy to debug despite some pretty complex business logic around generating site thumbnails.
As a proof of concept yes (scaling, rotation, moving the background work) but it doesn't do much yet. I wanted to make something like Irfanview that could handle basic transforms with a minimalist ui, but it still needs a ton of work. Drawing is more or less broken - I got as far as adding pixels to the canvas before other (paying) projects just got in the way.
When I figure out how to get it to work on a github page I'll have a demo up.
An obvious use could be as a library building tool. i.e. All the macros could be restricted to the internal methods used to construct the library DSL. All the public methods could look like standard js, and the library users would be none the wiser to the magic used internally to make the library construction more efficient.