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.
Show HN: Minified.js – a fully-featured, 4K alternative to jQuery and MooTools
91–100 of 145 posts
Re: Show HN: Minified.js – a fully-featured, 4K alternative to jQuery and MooTools
#92Earlier quoted context omitted.
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.
> 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…
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 An 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.
Re: Show HN: Minified.js – a fully-featured, 4K alternative to jQuery and MooTools
#93This 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
Re: Show HN: Minified.js – a fully-featured, 4K alternative to jQuery and MooTools
#94Earlier 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?
A HUGE difference, performance-wise. Delegation is O(1), while using any form of `each()` is going to be O(n).
To elaborate -- jQuery does not set an event-handler for each TR -- it sets one on the parent element (the table), and basically when the table is clicked jQuery gets the event and asks: "are you a TR?", and if so, then the handler is called with the clicked element as the context. So even if your table has 1million rows, only 1 event handler is attached and the DOM is only accessed once.
Of course, accessing the DOM 1 million times within a loop is going to take forever.
Re: Show HN: Minified.js – a fully-featured, 4K alternative to jQuery and MooTools
#95Earlier quoted context omitted.
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?
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 ev…
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)
Re: Show HN: Minified.js – a fully-featured, 4K alternative to jQuery and MooTools
#96Earlier quoted context omitted.
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?
A HUGE difference, performance-wise. Delegation is O(1), while using any form of `each()` is going to be O(n). To elaborate -- jQuery does not set an event-handler for each TR -- it sets one on the parent element (the table), and basically when the table is clicked jQuery gets the event and asks: "are you a TR?", and if so, then the handler is called with the clicked element as the context. So even if your table has…
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...
Re: Show HN: Minified.js – a fully-featured, 4K alternative to jQuery and MooTools
#97Earlier quoted context omitted.
A HUGE difference, performance-wise. Delegation is O(1), while using any form of `each()` is going to be O(n). To elaborate -- jQuery does not set an event-handler for each TR -- it sets one on the parent element (the table), and basically when the table is clicked jQuery gets the event and asks: "are you a TR?", and if so, then the handler is called with the clicked element as the context. So even if your table has…
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
Re: Show HN: Minified.js – a fully-featured, 4K alternative to jQuery and MooTools
#98This 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 j…
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.
Re: Show HN: Minified.js – a fully-featured, 4K alternative to jQuery and MooTools
#99RyeJS is another alternative, though it focuses on speed, modularity and having an understandable source instead of size. Clocking at 6.2kb. http://ryejs.com/ (disclaimer: I'm one of the authors)
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 b…
[deleted]
Re: Show HN: Minified.js – a fully-featured, 4K alternative to jQuery and MooTools
#100I 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 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.