Show HN: Minified.js – a fully-featured, 4K alternative to jQuery and MooTools

People who say "hey, what's an extra 30KB for one library? It's only like 10x larger" will tend to reach a similar conclusion at every decision point. And that's why the internet is full of massive, bloated, slow web pages. Single decisions don't cause bloat. Bloat comes from a slack attitude towards efficiency.

I'm not saying this project is an important breakthrough, but I definitely applaud the effort. I've always been surprised at the large size of jquery. I'd love to see a benchmark for runtime performance, including a comparison of parsing time and a benchmark of common operations.

What does that video possibly prove? That if you compare completely different sites, you can't use reductionist measures of individual attributes to compare speed? Is there anyone on HN who actually doesn't already know that? This is asking which of a collection of mystery vehicles is the fastest by engine size, and then revealing that one is a dump truck, one a train, and the other a motorcycle, with results that should surprise no one.

The only people who would possibly be interested in this project are people who are attempting to optimize the experience their app provides, presumably in a holistic fashion. It is pretty much part and parcel that such a person is going to minimize elements, CSS, images, and scripts in such a case, and aren't simply going to replace jQuery with something like this and assumes that it will make everything fast.

The reality of something like jQuery, like Ruby on Rails or MongoDB, is if you start with it you'll likely be stuck with it. You can't simply make a full site and run it through the profiler and swap out components without significant rewriting.

Writing a bit of "raw" code can really make you understand why jQuery may do things in a certain way or why they have chosen certain abstractions.

If you do it right you don't even have the client send/receive an HTTP 304. For our app we have a lot of modular dependencies but we serve all of them from a unique prefix per build (eg. 'assets-SHA(build)/js/foo.js'). The second page load and beyond has zero requests for the same static asset. Whenever we have a new build of the app the unique prefix gets auto updated to force clients to use the latest versions.

For HTTPS make sure to mark your assets as public or they won't be cached:

    Cache-Control:max-age=31557600, public

Now that jQuery 2.x drops IE 8- support, a credible question is whether such libraries (which are more in the 95KB range, minified) are even necessary at all.

Quite outside of the time to download, there is a measurable cost to parse all of that boilerplate code as well. This has more of an impact on mobile, obviously.

(And I do curse Microsoft for making IE 9 Vista+ only browser, which is quite likely explainable by use of some shiny new undocumented API, that wasn't available in XP and before. Microsoft and their browser tightly coupled with OS...)

Actually one of the ways I used to decide what features to squeeze in was making a list of all jQuery functions and re-implementing the functionality with Minified. To make sure that I don't miss anything important.

There are some things that are more complicated to do, because you need to work with anonymous functions, but honestly most of them were functions that I had never heard of before and would probably have re-implemented even when using jQuery :)

Yes, it is.

1) For poorer countries with spotty internet, or mobile only that is slow.

2) For mobile, where data use matters.

3) Ideally with a library this small, it's mostly doing exactly what you need it to and nothing else. So it should be faster for what you're using it for. It's not trying to be all things to all people, and the trade off for that should be giving up long-tail features in exchange for more speed.

Also, if you want to optimize for file-size, you won't get very good results with a collection of micro-libraries. A compiler like Closure is capable of inlining functions and removing unused code only as long as you have all of it in a single file as private functions. But when every library exports all its features, Closure is not able to optimize them properly anymore.

$("#dataTable tbody").on("click", "tr", function(event){ alert($(this).text()); });

In Minified, the easiest way to get exactly the same event handler is this: $("#dataTable tbody").each(function(tbody) { $('tr', tbody).on("click", function(){ alert($(this).text()); }, tbody);

I also guess that almost all sites the cost of parsing and executing the libraries is more significant than the actual runtime. I mean, there are sites that parse 200kb of ungzipped source code only to execute the 2 kb of them that are required to have some pull-down menus or sliders a couple of times.

Edit: oh, no, this time it was me unintentionally editing the compiled index.html.

BTW to get down to the final size of 4089, I compress the source code with Closure Compiler in Advanced Mode, and then compress again using UglifyJS to get rid of the last 20 bytes. Closure is not perfect...

Another example are jQuery's the complex selector/stacked set features, like 'andSelf()' or 'next()'. Minified only has simple lists and a couple of callback-using helper methods like 'collect()' and 'filter()'. If you are doing something complex and know jQuery's API well enough, jQuery is more powerful.

    {$left: '10px', $top: '10px'}

    {'$left': '10px', '$top': '10px'}