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[1] for that specific sample though. I need to change the default sample this week.
[1] Super frustrating! The new IonMonkey JavaScript engine crashes under very certain conditions that are met during my link avoidsNodes algorithm. This means that Firefox 18 and 19 (but not 17 and 20) will crash on the Flowchart sample, because the link routing is set to use avoidsNodes. It's unfortunate but even though they're aware of the bug they aren't going to bother fixing it for FF19.
By the way, if there are other canvas library authors out there who have had interesting (or downright weird) issues with various canvas implementations, I'd love to hear from you!
Wow. Very very nice job there. I had project a while back and couldn't find too many options when it came to Javascript diagramming and had to settle with jsPlumb. I wish this was around at the time [edit] or at least more visible from my quick searching.
PouchDB is a full reimplementation of CouchDB inside the browser (using browser storage), you can build applications that work offline then sync your data with 'the cloud'
I know this is a crap answer to this question, but for me what is "cool" is what can easily do things that I think are awesome. For me, that's Angular.js.
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.
Another library that tries to make async code much cleaner is async.js (https://github.com/eligrey/async.js#readme). It uses yield and generators to abstract away the callback jungle.
For example, you can easily condense tens of lines of event code into a single `event = yield document.next("click")`
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).
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.
My guess is that jQuery targeted and solved a problem that was bigger for a broader base of people doing JavaScript development: the DOM API (and some other browser APIs) was both pretty awkward and inconsistent.
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.
I never looked that close, but I thought that prototype extended the base objects with the prototype property? If this is the case, then it wasn't a great idea. Meta programming is acceptable when you control the compiler or spec of the language, but as ECMA specifications move forward, and those functions are added, you'll get conflicts. And you can't control what browser is interpreting your javascript.
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.
I think it was because of the lack of documentation. Back then prototype had none and jQuery had a lot. They had a rich site and prototype had a single spartan page.
This is not what I remember. I even have a printout of the full prototype doc hidden somewhere, it had clean and straightforward explanations for all the API.
Scriptaculous, built upon prototype.js, was nice too.
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.
I discovered underscore.js recently, I really like it as well. After learning a little functional programming, it is cool to see things like map, contains, select, etc. brought into JavaScript in an easy-to-use way.
TypeScript. Fastest JS parser I've seen (at least in JS compared to coffeescript, esprima, narcissus, etc), bootstrapped in its own language, great type checker/inferencer, easy to follow codebase.
Cappuccino (with Objective-J). One of those, 'so batsh#t crazy, it's brilliant' things. Note they are one of those that make a distinction between a library and framework.
Bacon.js: https://github.com/raimohanska/bacon.js -- functional reactive programming in javascript. It's another way out of callback hell when doing UI work.
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
Also if you like Backbone.js, don't miss Knockback.js (http://kmalakoff.github.com/knockback/). Now you have observable (view)models and collections. Definitely cool.
Every so often, someone writes a tool that makes you (or me, at least) super excited about web development. In 2006, that was jQuery. In 2013, that tool for me is Backbone.
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.
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.
Im the creator of JSDB, so thanks for the mention! In the interest of equality, theres a few more that are worth taking a look at: microjs.com, and http://jster.net/
Shameless plug time: I built Rekapi, which is a context-agnostic keyframe animation library. That means it works with DOM, Canvas, or whatever you need: http://rekapi.com/
I've been having a lot of fun with https://github.com/harthur/brain (neural network implementation in JavaScript) lately. Perhaps it's not something you would use on a real, live site, but it is fun to prototype neural network stuff in the browser with easy access to the DOM, canvas, and WebGL.
Rohan,
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
"Sugar is a Javascript library that extends native objects with helpful methods. It is designed to be intuitive, unobtrusive, and let you do more with less code."
I like TinySort which is a no-frills jQuery plugin to sort HTML elements. Great for data tables -> http://tinysort.sjeiti.com/
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.
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.
did you see they compiled QT against emscripten recently. That's pretty insane if you ask me. Now they just need to compile KHTML too, so it's webkit all the way down.
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.
I love underscore. It's basically the first thing I add on any project if I'm not using coffee script. Life is too short for programming everything from the ground up.
Not a JS lib but for JS devs CouchDB/CouchApp rocks. Fully JS webapps with no db/app server distinction. Why does no one care about it anymore? Add BigCouch for scalability.
box2d-jquery, (note: i mashed, hacked'n'slashed it myself) when it's done it will be an html/dom based (physics) game engine (then it might even be useful), now the feedback i get is just:cool
I bet a bunch of you actually searched for that on google. What's sad is that is probably the name of some obscure testing library. What have we come to...?
but it's honestly terrible and even mentioning it in this thread is a terrible thing to do. I'm going to go think about what i've done now, over in the corner, there.
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.
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.
http://gojs.net/beta/
Or straight to samples:
http://gojs.net/beta/samples/flowchart.html
Firefox warning[1] for that specific sample though. I need to change the default sample this week.
[1] Super frustrating! The new IonMonkey JavaScript engine crashes under very certain conditions that are met during my link avoidsNodes algorithm. This means that Firefox 18 and 19 (but not 17 and 20) will crash on the Flowchart sample, because the link routing is set to use avoidsNodes. It's unfortunate but even though they're aware of the bug they aren't going to bother fixing it for FF19.
https://bugzilla.mozilla.org/show_bug.cgi?id=830063
~~~
By the way, if there are other canvas library authors out there who have had interesting (or downright weird) issues with various canvas implementations, I'd love to hear from you!