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
URL: http://zeptojs.com/
Show HN: Minified.js – a fully-featured, 4K alternative to jQuery and MooTools
111–120 of 145 posts
Re: Show HN: Minified.js – a fully-featured, 4K alternative to jQuery and MooTools
#112Earlier quoted context omitted.
That's not exactly the same at all.
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?
I love what you are doing, but if you are trying to provide a comparable framework, a thorough understanding of what the functionality you are replicating is vital. The delegation of .on() is quite handy (for reasons others have elaborated already).
Re: Show HN: Minified.js – a fully-featured, 4K alternative to jQuery and MooTools
#113A 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.
Re: Show HN: Minified.js – a fully-featured, 4K alternative to jQuery and MooTools
#114Earlier quoted context omitted.
> Is there anyone on HN who actually doesn't already know that? I see a lot of discussion here based on the premise that this smaller script will make a big difference in overall page load time. It's why the audience in that video was leaning towards the site with the most JavaScript being the slowest. The first benefit listed on the minified.js page is "Minified is smaller!" so exactly what benefits does "smaller" i…
"Smaller" on a slow connection does make a big difference. That's almost everyone, everywhere.
My phone is fast enough that the difference between 4KB of data and 80KB is not huge.
Re: Show HN: Minified.js – a fully-featured, 4K alternative to jQuery and MooTools
#115Earlier quoted context omitted.
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.)
Discussion of the issue here (disclaimer, I started the pull request) - 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 consi…
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.
Re: Show HN: Minified.js – a fully-featured, 4K alternative to jQuery and MooTools
#116The 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.
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.
Even if $left and $top are defined as variables, these codes are equivalent.
Re: Show HN: Minified.js – a fully-featured, 4K alternative to jQuery and MooTools
#117Earlier quoted context omitted.
That's certainly true, but for what kind of use case do you need 1 million rows? It think that 1000 is already a lot, and if you exceed this, maybe it's better to design the app in a way that you need fewer rows...
It's not just for large numbers of elements. If you have dynamic elements that get added/removed you can define a single event handler on the parent with a filter condition on it's children that handles them all. The following CoffeeScript event handler would be fired for every table cell with the foobar class that is a child of #myTable: $('#myTable').on 'click', 'td.foobar', () -> # Do something What's great here i…
That's not how I would do it in Minified. I'd rather set up the event handler when creating the table row, one at a time, using the element factory (EE() or clone()) onCreate handler. Because otherwise you'd have to store data in the DOM model, which IMHO is not a very elegant design.
But it's certainly faster or at least easier on memory consumption if you have many thousand rows.
Re: Show HN: Minified.js – a fully-featured, 4K alternative to jQuery and MooTools
#118Earlier quoted context omitted.
Most browsers probably have all versions of it cached by now too.
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/ 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 fr…
You might be looking for this - http://statichtml.com/2011/google-ajax-libraries-caching.htm...
Re: Show HN: Minified.js – a fully-featured, 4K alternative to jQuery and MooTools
#119Earlier quoted context omitted.
Discussion of the issue here (disclaimer, I started the pull request) - 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 consi…
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 sin…
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
Re: Show HN: Minified.js – a fully-featured, 4K alternative to jQuery and MooTools
#120Earlier quoted context omitted.
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.
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.)
I have some data:
http://w3techs.com/blog/entry/jquery_now_runs_on_every_secon...
Of the top 10k sites 58.8% use jQuery. That's good!
But only 26.6% use a cdn. Leaving only 15.6%. That's bad...
But 94.2% use Google's. Which is still 14.7%! That's good!
http://www.stevesouders.com/blog/2013/03/18/http-archive-jqu...
But only 1% use the newest version of jQuery. Leaving only 0.15%. That's bad...
http://www.quora.com/User-Behavior/How-many-websites-does-an...
But users visit on average 89 sites per month. Which gives us 12.5%. That's good!
http://stevesouders.com/cache.php
But default browser cache sizes are small. That's bad...
http://www.webperformancetoday.com/2013/06/05/web-page-growt...
But the average website is about 1MB so with a 50MB cache about 50 sites can be cached. Which leaves about 7.2%. That's... OK?
OK. So I don't actually know if a cdn cache hit is all that likely, but the situation is a bit worse, and a bit better than most people think.
Of course, using a cdn is still better than hosting yourself. If you bundle your jQuery then every time your site updates it needs to be redownloaded. If you serve it seperately on your domain, you won't have the distribution benefit of a cdn.
Should you use Google's cdn instead of a different commercial cdn provider that's faster? In that case I'm not sure.