Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

minifiedjs.com

Post reply on HN
Print view View original

81–90 of 145 posts

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

#81

Post by tjansen »

dmethvin wrote: post #80
tjansen wrote: post #79

Earlier quoted context omitted.

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

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?

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

#82

Post by corresation »

Wintamute wrote: post #67

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.

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.

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

#83

Post by 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

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.

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

#84

Post by gavinpc »

tjansen wrote: post #73
przemoc wrote: post #70

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

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.

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

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

#85

Post by ggurgone »

tjansen wrote: post #29
ggurgone wrote: post #25

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…

In the real world preformance matters my friend. Personally I care more about that than 4kb vs 32 or 69 :P

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

#86

Post by jasonlotito »

js-coder wrote: post #76
kailuowang wrote: post #74

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.

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.

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

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

#87

Post by dmethvin »

corresation wrote: post #82
Wintamute wrote: post #67

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.

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

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

#88

Post by dmethvin »

tjansen wrote: post #81
dmethvin wrote: post #80

Earlier 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?

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.

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

#89

Post by cromwellian »

tjansen wrote: post #39
Yver wrote: post #35

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

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 Cl…

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.

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

#90

Post by amalag »

toble wrote: post #62
eps wrote: post #31

Earlier quoted context omitted.

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

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.

http://cdnjs.com/
Post reply on HN