a micro-site for micro-frameworks

May 5, 2011 4:53 PM

Fantastic Micro-Frameworks and Micro-Libraries for Fun and Profit
posted by the noob (21 comments total)

I like this, I like Thomas Fuchs, and if you write JS you should do yourself a favor and use Backbone and Underscore in your next project.

Also, subscribe to this.
posted by thedaniel at 5:16 PM on May 5, 2011 [4 favorites]

Also, I am kicking myself SO HARD for not immediately buying JSConf tickets - everyone there seems to be cranking out something like this. It's like a crazy vortex of genius productivity!
posted by thedaniel at 5:17 PM on May 5, 2011

if you write JS you should do yourself a favor and use Backbone and Underscore in your next project.

I also like microframeworks, and I also like Thomas Fuchs, but without some qualification, I suspect this statement is going to get no small number of people into trouble.
posted by weston at 5:27 PM on May 5, 2011

Yeah... I love javascript weekly, too. Fantastic resource.

This stuff is pretty fun... thanks for sharing it. It's an exciting time to be programming in Javascript...
posted by ph00dz at 6:18 PM on May 5, 2011

Very slick stuff in here. I just recommend checking each the license on each micro-library. At least one (Estro) is Affero GPL, which is copy-left on steroids.

Nothing wrong with that, it's his work, but it put's it off limits for anything not already GPL.
posted by PissOnYourParade at 6:57 PM on May 5, 2011

Do my eyes deceive me, or is that a library for manipulating a Logo-style turtle in JavaScript?
posted by JHarris at 6:59 PM on May 5, 2011

This is... interesting... and I like a lot of the snippets that are in there. But as a friend of mine noted today, isn't a "microframework" just what people have been calling a "library" for the past couple decades?

It's interesting that a generation of developers has grown up with the assumption that frameworks are always the starting point, and that the alternative isn't "Write code" but to use an incrementally smaller framework.
posted by verb at 8:18 PM on May 5, 2011 [3 favorites]

Oh, I'm totally coding my next webapp in LOGO.
posted by schmod at 9:24 PM on May 5, 2011

It's interesting that a generation of developers has grown up with the assumption that frameworks are always the starting point, and that the alternative isn't "Write code" but to use an incrementally smaller framework.

I could be making this up, but I think the popularity of the "framework" concept is more about people looking for idioms to work with than for discrete chunks of application functionality. Like more "make JavaScript friendlier" or "give me a simple rubric for laying out a web application" than "manipulate this file format" or "frobnicate the baffle". And this strikes me as a pretty natural evolution of things, though I often find myself Just Writing Some Code because some existing framework feels a good bit too all-encompassing.

(Well, and because I spend too much time over here in the PHP ghetto.)
posted by brennen at 10:11 PM on May 5, 2011 [3 favorites]

I think the popularity of the "framework" concept is due to an oversize supply/demand ratio, with lots of silly libraries hoping to be the next paradigmatic shift. Many developers want to be the next Thomas Fuchs or John Resig.

The best argument regarding the latent danger of framework reliance I've seen comes from Rebecca Murphy:
* http://www.slideshare.net/rmurphey/the-jquery-divide-5287573
* http://blog.rebeccamurphey.com/on-jquery-large-applications

Which isn't to say I've not found lots of things to love in YUI3 and jQuery. They offer excellent specific functionality when you can successfully navigate around the implied worldview.
posted by migurski at 10:24 PM on May 5, 2011 [1 favorite]

I think Javascript is wonderful, and I didn't always think that. Its first-class functions enable libraries like Underscore to be incredibly thin but still provide a lot of value. The whole concept of polyfills still blows my mind - that Javascript could end up being easier to write in a cross-platform manner than, say, Python, is mind-blowing; and it's all due to a few simple, wonderful, fundamental language design choices which have been hidden in a context of other terrible choices (such as the global scope) but are now just evident.

It's great.
posted by doteatop at 11:14 PM on May 5, 2011 [1 favorite]

The best argument regarding the latent danger of framework reliance I've seen comes from Rebecca Murphy

Murphy has some good ideas in that piece, but to the extent that the takeaway is about the danger of frameworks like jQuery, it's incorrect.

As I've written here, some people seem to think that jQuery's purpose is to supersede JavaScript itself, when really it's nothing of the sort. Instead, it's essentially a replacement for the bad native browser/DOM APIs.

This is an easy mistake to make, given that (a) people have *long* had a problem making a distinction between the JS language and the DOM API (b) there are lots of libraries/frameworks/languages/compilers out there whose purpose is to avoid writing JavaScript (c) because jQuery introduces a lot of developers to certain idioms (fluent/chained method calls and callback passing) for the first time, it's easy for those who don't know better to think they're jQuery idioms rather than general ones.

But it's the confusion at the heart of problem. Nobody would talk about writing a "DOM API RIA." It's understood you don't build a big application out of those kinds of things. But a lot of people who are confused about what jQuery is try because they've promoted it to near-language status.

This isn't really jQuery's problem. And it's not really a matter of the danger of using any library/framework, except insofar as it allows you to get farther without really knowing what you're doing (which no framework except a really crappy one is going to save anyone from :).

I do think Murphy is sortof on the right track suggesting education in modularity is part of the solution, but I see some danger in this being interpreted as a matter of modularity/size of the frameworks, which really isn't the issue at all. Ideally, a good developer is writing components that are abstracting away the details of interacting with the DOM (either directly or through jQuery or something similar) and eventually produces code where nobody but the devs working on specific components has to understand how they display themselves. Stuff like Backbone.js seems to be built around encouraging this, but myself, I think it's part hype... the raw material needed to do this is already present in JavaScript itself, all most developers need is an exposure to the idioms, no includes needed.

I'm still on the microframework wagon to some extent myself, not because I think there's any problem with generally using something like jQuery, but because I think people will actually read these various little things and it'll spread idioms and general literacy and will help developers out with the situations where they do need to worry about small sizes and speed and rolling their own solutions from scratch or out of granularized pieces.

At least, I hope so. It's always possible this is going to become another one of those things where people who don't understand the principles involved adopt "best practices" as a proxy for understanding and "small/modular is good" becomes the new "tables/flash/goto are baaaad."
posted by weston at 1:17 AM on May 6, 2011 [5 favorites]

Apparently, the future is compiling to javascript. I know it works well for lots of people, but it seems completely wrong to me. Why is it that compiling to such a high-level language is better than compiling to a VM with a small number of verifiable opcodes? Something went completely wrong with browser standards.
posted by vanar sena at 1:47 AM on May 6, 2011

I don't understand why the linked article had huge, randomly-colored boxes for each "framework". A filter-able table would've done the trick.

Murphy has some good ideas in that piece, but to the extent that the takeaway is about the danger of frameworks like jQuery, it's incorrect.

I think the key idea in Murphy's piece is that she's concerned that (on the technical side) the lack of clear delineation of function in jQuery produces (on the social side) common misunderstandings about how jQuery fits in with the rest of your application. People do misinterpret jQuery as being a general-purpose javascript-replacement (this is something that you seem to agree with in your blog post), and it really is

 ___    __    ___  _____  _    __    _     _     _    
| |_)  / /\  | |_)  | |  | |  / /\  | |   | |   \ \_/ 
|_|   /_/--\ |_| \  |_|  |_| /_/--\ |_|__ |_|__  |_| 

jQuery's fault for not adequately modularizing its function. And beyond that, it is the result of javascript library/framework authors not adhering to any particular convention for modularization. When you say "it's the confusion at the heart of problem" and "This isn't really jQuery's problem", I believe that Murphy is contending that jQuery has contributed to the confusion. That's what I got out of it.
posted by a snickering nuthatch at 4:15 AM on May 6, 2011

It's always possible this is going to become another one of those things where people who don't understand the principles involved adopt "best practices" as a proxy for understanding and "small/modular is good" becomes the new "tables/flash/goto are baaaad."

I believe this is nearly certain to happen, but it's not necessarily a bad thing. If a bunch of people adopt good practices because they're fashionable... well, they've still adopted good practices.
posted by a snickering nuthatch at 4:23 AM on May 6, 2011

Weston, Jpfed - jQuery is definitely complicit in encouraging overuse of the "magic dollar". From the front page of the website where it says that "jQuery is designed to change the way that you write JavaScript" to the How It Works page, I see enumerations of features but not a lot of focused mission statement. That's probably fine if everyone's basically on board with the idea that the dollar sign is for DOM traversal and maybe Ajax requests, but the the church of method chaining and inline callbacks has an attractive message to share.

A friend who's been an advanced front-end developer for a few years has said that jQuery is a lot like Rails: "great for you and your 500 closest friends", increasingly graceless and finally a nuisance as your needs grow beyond what it's designed handle.

On an only tangentially-related note, if you're a JS developer and you haven't ever viewed source on Quora, check it out some time - you will see through time.
posted by migurski at 9:08 AM on May 6, 2011 [1 favorite]

and it really is partially jQuery's fault for not adequately modularizing its function

I'm not sure I understand this criticism -- what exactly isn't adequately modularized, and what would it look like if it were?

jQuery is definitely complicit in encouraging overuse of the "magic dollar". From the front page of the website where it says that "jQuery is designed to change the way that you write JavaScript" to the How It Works page, I see enumerations of features but not a lot of focused mission statement.

I might buy the idea that jQuery's creators/community haven't adequately explained what it's not good for along with what it's good for, but this is a distinct issue from whether or not the framework itself causes the problem.

If a bunch of people adopt good practices because they're fashionable... well, they've still adopted good practices.

Kindof.

I have an essay boiling in my head called "Best Practices Considered Harmful." Because I think there's no such thing. There's "Good Principles", but "Best/Good Practices" are essentially rules-of-thumb boiled down from the principles for would-be practitioners who don't understand the underlying principles yet. They may (depending on how well they're boiled down and transmitted) help with the common cases, in which case they're useful, but still somewhat dangerous. Dangerous because it's all a bit like having the cargo cult operating a real functioning airport. The staff is operating at a low level of extrapolated understanding, but the planes are taking off and landing and dropping the cargo. When something unusual happens, is the staff is likely to be equipped to make decisions that let them adapt and avoid disaster?

jQuery is a lot like Rails: "great for you and your 500 closest friends", increasingly graceless and finally a nuisance as your needs grow beyond what it's designed handle.

If you accept the proposition that jQuery is really specifically designed to replace the DOM/browser APIs rather than JavaScript itself, does this criticism still make sense?
posted by weston at 10:03 AM on May 6, 2011 [1 favorite]

I'm not sure I understand this criticism -- what exactly isn't adequately modularized, and what would it look like if it were?

There would be more than one function, $(). It might look a little more like YUI.

If you accept the proposition that jQuery is really specifically designed to replace the DOM/browser APIs rather than JavaScript itself, does this criticism still make sense?

Absolutely: when your page grows in complexity, that one line of jQuery with the DOM selector hides a lot of internal looping. If you don't know what it's doing, you have a slow page. If you do know what it's doing, you start using Deferreds and timeouts and pretty soon you're wrapping your entire application around jQuery's own ideas of how to handle complexity. Then you are on slides 7 or 28 of Rebecca Murphy's presentation. Might as well be writing Perl at that point.
posted by migurski at 3:00 PM on May 6, 2011

There would be more than one function, $().

There's definitely more than one function. jQuery/$ is certainly the most high-visibility and frequently used function, given that jQuery is primarily a DOM replacement and this is its function for picking DOM nodes out of a document. But I don't see why methods calls on the jQuery object wouldn't count as different functions, and if that's not enough, there's bunches of AJAX/utility methods are properties of the jQuery "namespace."

That aside, though.... as a functional abstraction for what it does, I don't see why you'd want to split it out into something else. Are there specific DOM-selecting cousins you're thinking $ should have?

Or are you thinking it would be nice if jQuery had higher level constructs -- like "YAHOO.widget.Menu"? If so, I guess that's fair enough, but then I think we're back to discussing a mismatch between what people expect jQuery to be be and what it actually is. It's not a widget library. It's not that high-level. It's mostly just a better DOM/http API.

when your page grows in complexity, that one line of jQuery with the DOM selector hides a lot of internal looping. If you don't know what it's doing, you have a slow page.

I'd agree that when a dev doesn't pay attention to the complexity of the selectors their using and the semantics of the jQuery method calls, this can be a real problem.

But personally, I'd much rather have this problem than the problem of clambering around a DOM tree using the lattice of built in references and manually testing nodes to see if I want to operate on them.

If there's an elegant API for direct DOM manipulation that can save developers from both problems simultaneously, I'm definitely intrigued, but I'm also skeptical.

If you do know what it's doing, you start using Deferreds and timeouts and pretty soon you're wrapping your entire application around jQuery's own ideas of how to handle complexity.

I'm pretty sure the idea that you have to start using deferreds and timeouts for simple DOM manipulation is false. If you've got a specific situation in mind where you think jQuery might require someone to organize around that, I'd like to see if I can unwind it into simple procedural but structured code.

Once you get into animation, it's trickier, but I'd also argue this isn't a problem unique to jQuery. Your choices are pretty much keeping track of the timing yourself, or passing functions to something that will keep track of the timing for you. And this is also true of http/network calls. They're asynchronous operations. You can isolate developers from this to some extent but you're not going to be able to get rid of it.

I'd argue further that it's not impossible or even particularly difficult to organize an application built around explicitly asynchronous operations (using deferred calls and timeouts/intervals), and given how often they pop up in a browser context, it's probably worth learning to do well. But if you don't animate and are careful about when/how your network calls are processed, you can avoid having to know this. I also have my doubts that another library is going to save anybody from this dilemma.

Then you are on slides 7 or 28 of Rebecca Murphy's presentation.

I have a couple of problems with these slides, particularly as examples of what you're talking about, and to some extent as examples of what Murphy's talking about.

Slide 7 isn't an example of the dangers of callbacks and timeouts or, for that matter, what jQuery forces people to do. It's an example of somebody who didn't create or find themselves a proper tab pane abstraction and doesn't know how to stick their information in "model" objects. You could probably refactor it fairly readily with no additional dependencies. I think it's also possible an author who isn't ready to do those things would indeed benefit from using something higher level like YUI (which is likely to have some kind of tabbed pane), but then again, even that isn't going to help them package appearance and logic into nice components, it's just going to give them higher level widget invocations. And in any case, jQuery isn't to blame here any more than document.getElementById and the native node style object would be if jQuery weren't there.

Slide 28... I don't think most of it actually *is* vanilla jQuery. The pieces that are ($.subscribe,$.proxy,$.map) look like they're doing the job of providing nice uninvolved abstractions to me. I don't know exactly what require.def is, but at a guess, I'd say it's some kind of small framework for promoting modularity and handling dependencies, which seems ironic to me, given the presentation context.
posted by weston at 4:55 PM on May 6, 2011 [1 favorite]

Actually, Slide 28 is Murphey's example of good design.
posted by revfitz at 11:13 PM on May 6, 2011

Actually, Slide 28 is Murphey's example of good design.

I see. The OMG-WTF is the response from the putative client/unitiated JavaScript dev?

Also:

"In this screencast I respond to a twitter challenge by @thomasfuchs. I <3 modules and dig microlibs, but I think that having consistent cross-browser support is more easily obtained by using a modular/buildable library or framework instead of a bunch of independent microlibs."

Seems to validate Tom Dale: "The golden rule of software, however, is that unless it is designed to work well together, it usually won’t."
posted by weston at 2:18 PM on May 9, 2011