Hacker News Reader

Comment by sequoia | Hacker News Reader

If you are making another dom traversal library, you must (imho):

    * Explain why someone should use it over the standard: jQuery
    * Clearly explain the stance toward browser compatibility (not hand-waving & "oh who uses ie8 anyway?")
    * Come up with something better than "It's smaller than jQuery!"

Without these points hit I don't even bother looking at DOM library. :/

View on HN

Not to say that their argument is sufficient to abandon jQuery, but it looks like what they're offering is working directly with the DOM, instead of jQuery's wrapper. Again, I can't say I'm convinced, but at the same time, at some point, won't it be time to move to the native DOM? jQuery itself is abandoning support for old IEs, and once that happens (are they really going to still be supporting 1.9 in five years?) then the main reason to use jQuery, cross browser compatibility, will be gone, and it will be time to reassess what should be the standard JS standard library.

Edit: on the other hand, I feel like DOM traversal is becoming a smaller and smaller part of the JS I write. Maybe we'll find in five years that we don't need a DOM wrapper at all.

This isn't letting you work with the DOM directly...it is yet another library which encompasses the DOM API...just like jQuery.

It only feels a bit more natural since the style it uses feels more direct...this is just another javascript wrapper for the DOM...a problem we (basically) solved with jQuery.

I also find myself rarely using jQuery for much these days when I use various MV* javascript libraries. This library looks neat, but I don't need to replace a library I use less and less...and has no real benefits other than size and API differences (that can basically be mapped to each other 1:1).

Eh, not a wrapper, sorry. It's a helper that directly extends the DOM to provide syntax sugar. Yes, it is not pure DOM interface, but if it were, then the library would be a whopping 0KB. :)

That teaches me for not looking at the source prior to commenting...my apologies (I am at work on limited time)...

I still feel this library (with the exception of the cleaner feeling API) is not much more than a wrapper/extension around the native functionality.

But good job on making it pleasing to work with (as it appears to be), and the website around introducing it is also quite nice...if I was using these DOM-wrapper-sugarizing libs to any serious degree these days I would likely consider it.

Overall this looks nice, but I feel like the javascript world is mostly moving away from the whole 'modify the layout that is pre-generated' and more towards a data driven/render what I specify world...

Yeah, i agree, which is one reason heavy-weight DOM manipulators are losing ground to small components. There will always be some need for working with the DOM though.

More like "Syntactic Olestra".

For you they must answer those questions. For some (like myself) these are enough. I don't need or want to load all of jQuery unless I'm using more than just DOM selectors and manipulation. The projects I'm working on now all target the latest browsers so I don't care about IE 6/7 or backwards compatibility.

Yes, I could write one myself but this way I don't have to maintain the codebase. Nothing is a 'one size fits all' solution but for some this is a good start.

My point being don't dismiss it just because it doesn't fit your needs right now. It's still worth taking a look at.

> I don't need or want to load all of jQuery unless I'm using more than just DOM selectors and manipulation.

Then why not just use Sizzle, which is jQuery's core selector engine without all the extra fluff? Again, the same question applies.

Sizzle is one of the engines we are checking out. Is HTML.js better? No idea. Worse? Same answer.

HTML.js is still smaller (a huge factor for me right now) and less 'robust', but that isn't always a bad thing.

By the looks of it, HTML.js is worse than plain DOM. Try `HTML.body.div.section.ul` in the example on its homepage, for instance - I'm willing to bet that's not doing what you'd expect.

It 'selects' all the section nodes. That's what .only() is for.

I'm hoping it returns undefined. Dot-traversal on a list goes into the first item, the first item should be empty. I have had some issues with the demo, since it hacks some things for presentation's sake. What did you expect?

isn't Sizzle just a selector engine? Just seems selector + manipulation

If the amount of DOM manipulation you're doing is that light, and you don't care about IE7, you could just use .querySelectorAll()... (At least, you'd know what type it returns)

If you just need the selection/traversal/manipulation of jQuery then just make a custom jQuery build with that. If that is still "too big" then use the alternate (qSA minimally wrapped) selector engine instead of Sizzle. Instructions are in the README in the jQuery repo.

The advantage of this approach is that if you decide you need more of jQuery (for example to support a plugin) you can pull in what you need rather than reinvent and debug your own.

Most of these frameworks remind me of JSS.

http://en.wikipedia.org/wiki/JavaScript_Style_Sheets

Reply on news.ycombinator.com