4 ms·

If you are making another dom traversal library, you must (imho): * Explain why someone should use it over the standard: jQuery * Clearly explain the s

by sequoia 13y ago

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

rquantz 13y ago
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.
- reflectiv 13y ago
  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).
  - nadabu 13y ago
    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. :)
    - reflectiv 13y ago
      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...
      - nadabu 13y ago
        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.
    - SimHacker 13y ago
      More like "Syntactic Olestra".
adeaver 13y ago
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.
- Recoil42 13y ago
  > 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.
  - adeaver 13y ago
    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.
    - emn13 13y ago
      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.
      - adeaver 13y ago
        It 'selects' all the section nodes. That's what .only() is for.
      - nadabu 13y ago
        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?
deleted 13y ago
[deleted]
1qaz2wsx3edc 13y ago
Most of these frameworks remind me of JSS. http://en.wikipedia.org/wiki/JavaScript_Style_Sheets http://en.wikipedia.org/wiki/JavaScript_Style_Sheets

by sequoia 13y ago

rquantz 13y ago

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.

reflectiv 13y ago
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).
- nadabu 13y ago
  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. :)
  - reflectiv 13y ago
    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...
    - nadabu 13y ago
      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.
  - SimHacker 13y ago
    More like "Syntactic Olestra".

adeaver 13y ago

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.

Recoil42 13y ago
> 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.
- adeaver 13y ago
  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.
  - emn13 13y ago
    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.
    - adeaver 13y ago
      It 'selects' all the section nodes. That's what .only() is for.
    - nadabu 13y ago
      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?

deleted 13y ago

[deleted]

1qaz2wsx3edc 13y ago

Most of these frameworks remind me of JSS. http://en.wikipedia.org/wiki/JavaScript_Style_Sheets http://en.wikipedia.org/wiki/JavaScript_Style_Sheets