
Show HN: Minified.js – a fully-featured, 4K alternative to jQuery and MooTools - tjansen
http://minifiedjs.com/
======
dmethvin
I know it's awfully tempting to obsess on something that is _easy to measure_
, like file size. I also know it's tempting to imply things like "twice the
file size means twice the page load time". But it's not true. _It 's NOT
true._

Look at this video at 6m30s:
[http://channel9.msdn.com/Events/Build/2012/3-132](http://channel9.msdn.com/Events/Build/2012/3-132)

Productively optimizing a web page is no different than optimizing any other
code. If you want to know why a web site is slow, profile it or run it through
a tool like webpagetest.org. Don't just set off to rewrite all your loops to
run backwards, or eliminate function calls, or reduce the amount of this or
that without any understanding of the result.

~~~
paulsutter
There's only one way to make a tiny page that loads super fast - and that's to
make every single decision with an eye towards efficiency.

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.

~~~
hnriot
But the reality is, everyone that visits your site already has jQuery in their
cache, because the common cdn sources are so ubiquitous, this making this 4k
library actually add to your page load footprint. Using the most common, most
likely to be a cache hit library is more efficient than using the smallest.

~~~
LocalPCGuy
People need to stop saying this.

~~~
rralian
Please elaborate.

~~~
adventured
It's a reasonable point. Given the vast array of jQuery versioning across just
the top thousand web sites, it's very plausible a user will not have each one
of those cached, and then a lot of sites vary on what cdn (if not local)
they're using.

I would be willing to bet that among just the top 1,000 sites, a user would be
required to have 25 to 30 copies of jQuery cached to cover all the sites.

------
WickyNilliams
This month I decided to go on a jQuery diet, as a kind of fun challenge. I'd
increase my familiarity with the standard DOM and selector APIs, and reduce my
dependency on jQuery.

After a few hours of working without jQuery, it became obvious that the
standard DOM & selection APIs are verbose and a little awkward. In about 20
minutes I produced a little wrapper that was compatible with a small - but
common - chunk of jQuery's surface, and it made life so much more bearable. It
clocked in at about 1kb minified (no GZIP).

Obviously it wasn't battle hardened and didn't deal with cross browser issues,
as it was just for hacking with - but it felt like proof that a wrapper of
some form, if not jQuery, is pretty much always necessary

~~~
jakejake
I think that's an accurate observation. Ironically, if you only code with a
library then it's easy to lose track of what that library actually does for
you.

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.

------
gioele
I see a licensing problem.

Releasing thing into the public domain is not as easy as writing

"Minified has been released into the Public Domain. You can use, copy,
distribute and modify Minified without any copyright restrictions. You may
even release it under your name and call it yours, if that's your thing."

As the CC0 page explains [1]:

> a waiver may not be effective in most jurisdictions

> Dedicating works to the public domain is difficult if not impossible for
> those wanting to contribute their works for public use before applicable
> copyright or database protection terms expire. Few if any jurisdictions have
> a process for doing so easily and reliably.

Please use a proper PD waiver tool such as CC0.

[1]
[http://creativecommons.org/about/cc0](http://creativecommons.org/about/cc0)

~~~
tjansen
I have CC0 on the download page, but yes, I should also add this to the source
code. Thanks.

------
Wintamute
The full, concatenated and uglified source of one-page JS web apps can easily
run to >600kB. Whether my DOM manipulation library consumes 4kB of that or
35kB isn't especially important to me. I'm more concerned about features,
cross browser support and familiarity other developers may, or may not have,
with the API. I'll be happy to check this lib out though, the API and docs
look nicely put together.

~~~
corresation
_Whether my DOM manipulation library consumes 4kB of that or 35kB isn 't
especially important to me._

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.

~~~
dmethvin
> 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.

Well my answer to the credible question is that jQuery has to normalize and
fix bugs for just about all the browsers it supports, it's not just an oldIE
problem. Plus, jQuery provides abstractions above the basic DOM operations
which are pretty low level. So if you don't want to use jQuery you'd probably
want some other library to provide equal or greater abstraction.

> 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.

Measurable of course. Significant as a portion of the page load time for most
pages? Well that's a different thing. And of course if you want it, jQuery
1.8+ provides the ability to create custom builds if you know you don't need
parts of it.

~~~
corresation
jQuery would never have come into popularity if not for oldIE and its often
dramatic variances from competitors: If you are willing to forsake that old
browser, there is little added but a layer of inefficiency between you and web
standards. We have become so accustomed to jQuery that it becomes the default,
many unaware of the dramatic improvements in all major browsers since.

As to the cost, assuming that everyone is pulling it from the same CDN (and
there aren't the often considerable times simply to check an etag, which is
the case with the overwhelming majority of jQuery hosts), an iPhone 4S takes
about 80-100ms to simply parse the jQuery file (and given the plateauing of
the integer core on on the A _n_ chips since, it is a reasonable assumption
that every Apple variant since is similar). On each and every page render. A
tenth of a second is a long time (and a lot of battery) for what is often of
minimal value.

------
ctoestreich
Just on the surface the potential for the minified library with its reduced
size and browser support sounds great. In just checking a few features it
seems as though the performance doesn't line up with jquery atm. In a large
application space would I rather trade off js performance for saving initial
DL time (cache)? I start to wonder where diminishing returns set in, if I
should I really care about IE6 anymore or if the clean and simple API you say
won't change will in fact never change.

[http://jsperf.com/test-jquery-vs-minified](http://jsperf.com/test-jquery-vs-
minified)

And to the community at large, feel free to add more tests.

~~~
tjansen
That's cool, thank you (even if the results don't look so good, but it's not
that surprising).

------
api
Love it!

The more experienced I become as a programmer, the more respect I have for
minimal programs that work very well. It's often very hard to "work your way
up to simplicity," as my father likes to call it. (He's an EE.)

------
ricardobeat
RyeJS is another alternative, though it focuses on speed, modularity and
having an understandable source instead of size. Clocking at 6.2kb.

[http://ryejs.com/](http://ryejs.com/)

(disclaimer: I'm one of the authors)

~~~
przemoc
Focus on speed and modularity next to the clear code sounds interesting, but
supporting IE 9+ only is kind of a bummer here, because it means "no" for XP
users (I use XP64 on my desktop for instance) and there is still substantial
number of them.

(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...)

~~~
ricardobeat
It does support it if you include es5-shim, though IE8 is effectively dead.
It's at < 5% share globally, around the same point we all dropped IE6 in the
past, and effectively at 0% for any web service / startup out there. It's
commonly surpassed by visits from Safari/iOS/Android.

Firefox, Chrome and Opera are available for Windows XP :)

~~~
tmzt
I wonder if libraries from Wine or Reactos could be used to run IE9 on XP.

I seriously doubt the reasons Microsoft gave for not supporting it are valid.
Even if the sandbox mode could not be used there is no reason why the browser
and rendering engine could not run on XP if the proper system DLLs were
present, and these could have easily been included with the install as
Microsoft does in many other cases.

------
colinm
Probably 4kB more than loading jQuery from cache :)

~~~
dclowd9901
Are people really referencing jquery from other servers in production
environments?

~~~
adventured
Yes, it's extremely common to call jQuery from, for example, Google's
googleapis.com domain.

Here's a quick sampling from a random group of top sites:

stackoverflow.com (googleapis.com), kickstarter.com (googleapis.com), cnn.com
(their own cdn), businessinsider.com (jquery.com), foxnews.com (their own
cdn), nbcnews.com (aspnetcdn.com), espn.com (espncdn.com), tumblr.com
(secure.assets.tumblr.com), lastfm.com (googleapis.com), lyricsmode.com
(googleapis.com), reference.com (sfdict.com, cdn for ask etc), qz.com
(googleapis.com), theverge.com (googleapis.com), ehow.com (googleapis.com),
wikia.com (googleapis.com), chacha.com (googleapis.com)

~~~
toble
Just a passing tinfoil comment... Google has so many fingers in the analytics
pie, if you're not being recorded by Adsense or Analytics, then there's always
CDN.

No idea if it's all linked up, but it means that using alternative search
engines doesn't really matter if you still visit Google-enhanced destinations.

~~~
eps
Of course it's all linked up, including other freebies such as Google Fonts.
Why else would they be offering it for free.

~~~
toble
If that's the case then maybe it would be better for society if we all started
self hosted these sorts of resources. Longer load times, more bandwidth usage
but better privacy for the public.

~~~
amalag
[http://cdnjs.com/](http://cdnjs.com/)

------
Alex3917
This is interesting, but what percentage of the time spent downloading jQuery
is actually transferring the file? I would imagine that jQuery is already
small enough that the majority of the time is spent just establishing the
server connection.

~~~
SkyMarshal
Most browsers probably have all versions of it cached by now too.

~~~
graue
Test this, you might be surprised. I strongly doubt it, because there are so
many versions in use, and as of 2012 only 25% of jQuery sites even used Google
CDN, by far the most popular CDN — most hosted it elsewhere.
[http://royal.pingdom.com/2012/06/20/jquery-
numbers/](http://royal.pingdom.com/2012/06/20/jquery-numbers/)

I have vague memories of reading a post with a stronger conclusion — that CDN
caching was basically a non-issue, it would so rarely work — but to my
frustration I can't find that right now.

~~~
babby
I wouldn't link to the Google CDN anyway, personally. If your whole site is
hosted on your servers and then you add this because maybe some people won't
have to reload JQuery, it just means google knows everybody who visits your
site. Free analytics you don't get to benefit from.

~~~
graue
I doubt Google is getting any useful analytics from their CDN. CDNs are
optimized for static content, and in particular are hosted on domains that
don't have cookies set (because cookies break caching). All Google would get
is

* an IP,

* a referrer from the first page on your site that included the script (no subsequent pages, because now the client has jQuery cached).

All in all, a pretty poor source of information compared to AdWords, Google
Analytics, G+, hundreds of millions of Android users, and running the world's
most popular search engine. At most they could crunch some browser stats or
jQuery usage stats, but they already get that and more from their own services
+ crawling the web.

And even if this tiny amount of info were somehow a boon to Google, so what?
It doesn't hurt you as a site owner.

------
rschmitty
Is this the full comparison?
[http://minifiedjs.com/#featCmp](http://minifiedjs.com/#featCmp)

It seems like that would cover most things I would use, however surely there
is more to jquery (that I may or may not be using..)

I like that they are including IE6-8, that was a bummer when zepto came out
aimed at mobile/modern only

~~~
tjansen
What exactly would you miss (other than some utilities like each(), which are
I would like to keep out of the library)?

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 :)

~~~
mattmanser
Sizzle is actually a big one, CSS1 doesn't really cut it for anything but the
most trivial use cases, although if you're only targeting modern browsers than
I guess you can rely on their support.

Also, if you don't support each, I assume you don't support method chaining on
enumerables?

As for actual missing features, the jQuery data stuff is really useful, but if
the intention is to use minified with something like backbone, I guess it's
kinda moot.

EDIT: I forgot to say nice library and I like the source code too.

~~~
tjansen
My replacement for more advanced CSS features are the methods filter(), sub()
and collect(). For example, instead of $('li:odd') you would write
$('li').filter(function(v, index) { return index%2;}). But, admittedly, if you
are well-versed in those advanced CSS features, they will always be easier to
use.

You can chain list methods, as in $('li').filter(function(v, index) { return
index%2;}).set({$backgroundColor: '#000'}).animate({$backgroundColor: '#fff'})
to fade every second list element from black to white. The number of
collection functions is limited to a minimum though. The Util module will add
a lot more collection features (but at a cost of another 4kb).

Yes, that's true, data() is something I intentionally omitted because I don't
think that it's worth its bytes today. For simple lower level effects toggle()
offers a very different approach of handling state, and for larger apps you
should use a MVC framework, as you suggested.

------
Nurdok
A novice question - how significant is the relative size here. Sure - 4 is
smaller than 32, but is that really the biggest concern with a JS library (and
modern internet speeds)?

~~~
recuter
In my opinion absolute relative size is actually less important than how many
TCP roundtrips it takes. It is no accident the author of this library is
trying to fit in under 4KB specifically.

~~~
tjansen
Frankly it is an arbitrary number, mostly. I started with the goal of having
no more than 7 functions, because that's the number of functions the first
version had. It didn't take long for me to figure out that this wasn't enough
for every-day use. My next goal was to be a number of magnitude smaller than
jQuery, and thus 3.3kB. That was a lot better, but still not enough to be a
viable alternative. So I settled with 4kB.

While 4kB may fit well in certain packet sizes, this does not help with HTTP
headers that can easily have 100 bytes or more.

------
Link-
Nice work! But it always starts small, then users need a feature here, a
feature there next thing you know you have a fat ass library just like the
pre-existing ones.

~~~
tjansen
Actually my goal is that the library will always stay under 4kB. Setting
yourself a limit is the only way to prevent feature creep, and 4kB seems quite
ok. Over time, when support for older browsers can be dropped, there will be
space for additional features. I am already working on a second <4kB module
though, with support for collections, strings, templates, dates and
number/date formatting and parsing. So yes, I know that 4kB is not realistic
goal for a complete app framework. But I am confident that I can do it in
12-16 kB.

~~~
Link-
The problem with optimization is that you always have to compromise, either
speed, features and performance for size or features and size for speed etc..
I think a probable solution would be to create a dynamically generated
framework which allows the user to specify the needed features (jQuery-ui
style).

~~~
tjansen
Actually there's a builder that allows you to pick the functions you need and
compiles custom versions:
[http://minifiedjs.com/builder/](http://minifiedjs.com/builder/) I don't think
that this is a practical approach for most people though. After a while it
becomes quite annoying to create a new version everytime you need a function.
It would be great, but unfortunately also quite difficult, to automate this.

------
ahallock
Thanks for putting this out there. I understand this is supposed to be a
swiss-army-knife style library, but I thought we were moving toward focused
(Unix philosophy) libraries. For example, why would I use your HTTP request
functionality when I could use Superagent, microjax, etc.?

~~~
tjansen
Personally I don't think it's worthwhile to use a large number of micro-
libraries, because of the huge overhead that comes with it. Every library has
slightly different naming conventions, you have to be sure that they play well
with another (e.g. compatible collections and Promises implementations), you
don't have a single point to look for documentation and so on.

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.

------
latchkey
Sure, I can switch my code to use this, but how compatible is this with common
3rd party libraries that are dependent on jquery? For example, will this run
the bootstrap js code ok? If it doesn't run that code cleanly, then we are
still stuck importing jquery.

~~~
tjansen
Not at all. While some things use a similar syntax, Minified is not compatible
with jQuery (and does not try to be).

~~~
latchkey
Anyone working on a project that has the remote chance of ever including a 3rd
party dependency on jquery should never use this project. Otherwise you risk
ending up needing to import jquery AND this project and now you're even
farther down the rabbit hole.

~~~
lrem
That's why it's called _alternative_ , not a _drop-in replacement_.

But yes, your point is valid. Also, jquery is so ubiquitous that I see no
reason to steer clear of it. If you use a CDN version of it, it's most
probably already in client's cache.

~~~
LocalPCGuy
The point about the CDN cache is not true. It is commonly claimed, but often
times it is not the case that jQuery is often cached if you use a CDN. It is
"sometimes" cached, and best performance for most websites is probably to
concatenate and minify jQuery in with the site's JS files.

~~~
lrem
I can see why your statement _can_ be true, but do you have any actual data on
this? Or are we both just guessing? ;)

(No, I don't have data on mine, I don't even work in this field.)

~~~
LocalPCGuy
Discussion of the issue here (disclaimer, I started the pull request) -
[https://github.com/h5bp/html5-boilerplate/pull/1327](https://github.com/h5bp/html5-boilerplate/pull/1327)

The basic gist is that there is great fragmentation in the cache eco-system,
and so there is no guarantee that the user actually has the version of jQuery
cached that you are requesting. Alex Sexton brought up in a talk at jQueryTO
that there are also the time for the DNS request itself to consider in any
discussion of speed, if you concatenate/minify your code it will eliminate a
DNS request.

Resources discussed in that page: [http://statichtml.com/2011/google-ajax-
libraries-caching.htm...](http://statichtml.com/2011/google-ajax-libraries-
caching.html) [http://www.stevesouders.com/blog/2011/08/17/http-archive-
nin...](http://www.stevesouders.com/blog/2011/08/17/http-archive-nine-months/)
[http://www.stevesouders.com/blog/2013/03/18/http-archive-
jqu...](http://www.stevesouders.com/blog/2013/03/18/http-archive-jquery/)

The end conclusion was that for H5BP it didn't make sense to remove the CDN
reference, but for your own site it might - you should test it and see. It
also depends on your audience (will the CDN move the files closer
geographically?).

In the end, ~40k (gzipped) is not going to make or break your website's
performance.

~~~
glitchdout
I disagree with your assessment (and so does the majority of people on that
pull request, it seems).

It's _always_ better to use a CDN because:

1\. It has a chance to be already cached (specially if you use Google's CDN).

2\. All browsers nowadays do 6 parallel requests per host. So using DNS
prefetching with `rel=dns-prefetch` will be faster.

3\. If you bundle jQuery with your site's JS files, every time you change a
single JS file of your own, your users will be forced to re-download your
bundled jQuery. Seems pretty inefficient to me.

~~~
youngtaff
If you're using HTTPS then "it's always better to use a CDN" is unlikely to be
true due to the costs of negotiating the secure connection.

1\. Is open to debate and we have no real numbers of this - hopefully the
resource timing API will all us to shed some light on the issue

2\. Not sure how the number of connections is relevant as the connection to
the CDN will be a new one.

3\. Agree with this, people need to merge files that naturally fit together an
have similar patterns of change

------
wassago
Looks good! Added it to the official list of frameworks on JSFiddle.

------
hippich
In case you need mobile support and not IE, also checkout Zepto. I updated
test with Zepto - [http://jsperf.com/test-jquery-vs-
minified/4](http://jsperf.com/test-jquery-vs-minified/4)

URL: [http://zeptojs.com/](http://zeptojs.com/)

------
samguddy
Minified.js has potential. If given the chance, it will be successful and I
for one love rooting for the under dogs. The Custom Builder is a lovely
addition. The Library is well documented and easy to understand.

Trying it out right now! Nice work Tim.

------
platz
What about event delegation? In JQuery there exists an overload to .on() that
can pass a selector string to filter the descendants of the selected elements
that trigger the event.

Is there something similar in Minified?

~~~
tjansen
No, not directly. From the jQuery API docs:

$("#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);

~~~
dmethvin
That's not exactly the same at all.

~~~
tjansen
Where's the difference? Admittedly I don't know that function in jQuery very
well, but I though it would register a 'click' handler for every tr, just with
the difference that it passes the parent tbody instead of the tr in 'this' to
the handler. What else does it do?

~~~
dmethvin
Delegated events let you handle events for child elements that aren't even in
the DOM at the time you attach the handler. The jQuery docs explain it:

api.jquery.com/on/#direct-and-delegated-events

> Delegated events have the advantage that they can process events from
> descendant elements that are added to the document at a later time. By
> picking an element that is guaranteed to be present at the time the
> delegated event handler is attached, you can use delegated events to avoid
> the need to frequently attach and remove event handlers. This element could
> be the container element of a view in a Model-View-Controller design, for
> example, or document if the event handler wants to monitor all bubbling
> events in the document. The document element is available in the head of the
> document before loading any other HTML, so it is safe to attach events there
> without waiting for the document to be ready. ... In addition to their
> ability to handle events on descendant elements not yet created, another
> advantage of delegated events is their potential for much lower overhead
> when many elements must be monitored.

~~~
WickyNilliams
Event delegation is entirely different to how you would normally do it. It
relies on the events from the inner elements bubbling up through the parent
elements. So you put an event listener on some common ancestor (the tbody in
this case) to the elements you care about (the tr elements). A click event on
some tr will bubble up to the tbody*, the event handler there can check
whether the originating element matches the selector "tr", and if it does, it
does something like: `yourCallback.call(event.srcElement, event)`.

The obvious benefit of this is that if there are 10,000 tr elements, it is
quicker to attach your listeners (there's only a single listener on the tbody)
and less memory is consumed (again, only a single listener). A more subtle set
of benefits come from manipulation of the DOM. Your listener is able to
respond to events on elements that have been inserted after the listener was
first registered. Also, when removing tr elements from the DOM you don't have
to remember to unbind all your event handlers (a common source of memory
leaks, as they can be GC'd)

------
pacomerh
A good choice would be to customize a download of jQuery to fit your project
needs. Similar to what you do with initalizr based on checkboxes. And just
unselect any stuff you wont use.

------
ggurgone
Did you make performance tests and comparisons with other libraries?

~~~
tjansen
No, actually I wasn't really interested in that yet. I wouldn't expect it to
be that bad performance-wise, but if performance would be my goal, there'd be
a number of things I would have done differently.

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.

~~~
LocalPCGuy
I would make this a priority if you want to try to differentiate in something
besides size as compared to jQuery. Performance is quite important, and I
frequently find myself spending the time testing pure JS solutions compared to
a jQuery solution to make sure my code is optimized. jQuery does a really good
job in this regard most of the time, but there is always room for
improvements.

------
przemoc
I see:

    
    
       tml xmlns:fn="http://www.w3.org/2005/xpath-functions" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:page="http://tjansen.de/minifiedPage" xmlns:i="http://tjansen.de/internal" xmlns="http://www.w3.org/1999/xhtml">
    

at the top of the page. Apparently the minification went too far. :)

~~~
tjansen
No, that's the %^&%#! XSLT processor that keeps inserting unused namespaces.

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

~~~
gavinpc
Ha, I'm glad I'm not the only one who has this problem with XSLT processors.

------
tmlee
Nice one! i am digging it so far! Gonna try using it in one of my smaller
projects to see how it goes.

btw anybody would like to use this in their Rails project, just drop
[https://github.com/tmlee/minifiedjs-
rails](https://github.com/tmlee/minifiedjs-rails) into your app for asset
pipeline. just did a quick one for that.

------
Yver
It's nice to see a library use Closure Compiler's advanced compilation mode.

~~~
tjansen
What's funny is that it hardly makes any difference. If you feed the source
code into Closure in advanced mode, the size is 9258 bytes pre-gzip and 4109
post-gzip. In simple mode, the numbers are 9267 pre-gzip and ... also 4109
post-gzip! It was hardly worth the (relatively huge) effort to get the library
working correctly in advanced mode.

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...

~~~
cromwellian
That's mostly because its a library, and so most of the optimizations you're
getting are purely local in-method and no dead-code pruning.

Where Closure shines is building an app whole-world, compiling both the client
code, and library code together, then it can prune away all unused methods in
the library.

------
pearjuice
So where does this library compromise? Why isn't jQuery this small?

~~~
tjansen
There are a lot of specialized features in jQuery that Minfied does not have.
For example, the only way to register an event with Minified is using on().
jQuery has on() as well, but it also has a number specialized functions like
'click()' and the legacy 'bind()'.

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.

------
kailuowang
30KB distributed by a free CDN with a high chance that it's already cached in
the browser VS 4KB that probably have to be served by myself.

I am sorry, I probably would still go with the 30KB solution.

~~~
js-coder
jQuery _might_ be directly cached but does that really matter? You could make
the browser cache Minified.js after the first loading. And I'm pretty sure
it's faster to parse / run a 4KB script than a 30KB script.

~~~
jasonlotito
> And I'm pretty sure it's faster to parse / run a 4KB script than a 30KB
> script.

That's always a dangerous assumption to make. I can guarantee you that size
has nothing to do with parsing and running times. As others have already
pointed out, this library is already less performant than jQuery for their
needs.

------
EGreg
The first caveat I saw is all the uses of $left, $top etc. Makes me wonder
what other variables the library puts into the global namespace.

~~~
roryokane
In JavaScript’s syntax, if $left and $top are not defined as variables, then

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

is equivalent to

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

The library doesn’t have to define global variables for that code to work. So
it probably doesn’t define them as global variables.

~~~
hk__2
Even if $left and $top are defined as variables, these codes are equivalent.

------
wiradikusuma
this looks good! probably its sweet spot is for HTML5-based apps, e.g.
PhoneGap, BlackBerry WebWorks and even Firefox OS.

------
halayli
If you use a common cdn to load jquery, chances are it's in the user's browser
cache is very high.

------
robinduckett
It's a bit misleading when you say Zepto has no AMD support, when it actually
does.

~~~
tjansen
In the standard version on zeptojs.com? Just did a short search on the source
code and can't find any 'define' invocations.

------
dfischer
How does this compare to Zepto.js?

~~~
Ziomislaw
has support for old browswers

------
ishbits
Aaaq

------
detay
not enough jquery.

------
camus
Poor name , sounds like a uglify like lib , not a DOM manipulation lib. You
should changed it.

And it's no alternative to jQuery or Mootools since your lib doesnt support a
lot of stuffs these libs provide.

~~~
bpicolo
Not providing the same features doesn't mean it isn't an alternative. It has
different goals.

~~~
VMG
The headline says _fully featured_

~~~
tjansen
And I believe it is. It does not support every single feature that jQuery and
MooTools have, but you probably wouldn't say that jQuery is not fully featured
because it lacks support for Cookies and color animation.

It's true that Minified doesn't support many features in the same breadth as
the other libraries. Instead the focus is on making the essentials easy (often
easier) and offering you powerful functions to do the rest. Basically that's
how I keep both API size and file size down.

