Live data from Hacker News

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

minifiedjs.com

101–110 of 145 posts

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

#101
post #42

Earlier quoted context omitted.

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.

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.

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.

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

#102

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 Productively optimizing a web page is no different than optimizing any other code. If you want to know why a web…

Look at this video at 6m30s 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 moto…

> 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" imply?

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

I agree, and creating your own homebrew framework for a large project in a holistic fashion has its own pitfalls. Especially if you've never done it before.

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

#103

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.

Might want to research whether or not there is really any benefit from using the CDN other than offloading the bandwidth and getting a (relatively small) chance at a cached solution. From a pure performance standpoint, concatenating/minifying on your own server is more performant in most cases.

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

#104
post #42

Earlier quoted context omitted.

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.

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

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

#105
post #29

Did you make performance tests and comparisons with other libraries?

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…

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.

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

#108

Earlier quoted context omitted.

Look at this video at 6m30s 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 moto…

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

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

#109
post #104

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

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 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://www.stevesouders.com/blog/2011/08/17/http-archive-nin... http://www.stevesouders.com/blog/2013/03/18/http-archive-jqu...

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.

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

#110
post #91

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.

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.
Post reply on HN