Live data from Hacker News

Sprint – A high-performance, DOM library for modern browsers

github.com

41–50 of 72 posts

Re: Sprint – A high-performance, DOM library for modern browsers

#41

Earlier quoted context omitted.

The DOM API remains complete garbage unless you're operating readonly on a single node (then it's merely bad).

Do you have any examples? In my opinion the DOM API only sucked pre-IE9 because of all the inconsistencies and incompatibilities. I have dropped jQuery completely except for when I need some of its plugins because I end up having to access the internal DOM objects too often and using $el.get(0) all over the place is ugly and a PITA.

    $('.something').toggleClass('collapsed')
                   .click(somethingClicked);
This simple and readable statement will turn into a lot of lines with DOM API.

Re: Sprint – A high-performance, DOM library for modern browsers

#42

Earlier quoted context omitted.

Do you have any examples? In my opinion the DOM API only sucked pre-IE9 because of all the inconsistencies and incompatibilities. I have dropped jQuery completely except for when I need some of its plugins because I end up having to access the internal DOM objects too often and using $el.get(0) all over the place is ugly and a PITA.

$('.something').toggleClass('collapsed') .click(somethingClicked); This simple and readable statement will turn into a lot of lines with DOM API.

[deleted]

Re: Sprint – A high-performance, DOM library for modern browsers

#44
Not supporting the selector for .on() and .off() is a pretty serious limitation; catching bubbled events on child DOM elements is a super-common jQuery pattern, and makes event-handling over a DOM that's having stuff added to it much more pleasant to write. It's also pretty fundamental to some third-party libraries that run on top of jQuery, like Backbone (at least if you use its View event handling).

Re: Sprint – A high-performance, DOM library for modern browsers

#45
post #42

Earlier quoted context omitted.

$('.something').toggleClass('collapsed') .click(somethingClicked); This simple and readable statement will turn into a lot of lines with DOM API.

[deleted]

> I would argue that the second half is a little unfair, since that style of coding is entirely influenced by jQuery. You usually don't actually need to trigger a real DOM event there, you just want to execute some callback as if the element was clicked.

Maybe I'm missing something, but the second half is adding an event handler (`somethingClicked` is presumably a function). That seems like a _very_ common thing to do regardless of jQuery.

Re: Sprint – A high-performance, DOM library for modern browsers

#46

Not supporting the selector for .on() and .off() is a pretty serious limitation; catching bubbled events on child DOM elements is a super-common jQuery pattern, and makes event-handling over a DOM that's having stuff added to it much more pleasant to write. It's also pretty fundamental to some third-party libraries that run on top of jQuery, like Backbone (at least if you use its View event handling).

agreed. lacking event delegation is a show-stopper.

Re: Sprint – A high-performance, DOM library for modern browsers

#47
post #42

Earlier quoted context omitted.

[deleted]

> I would argue that the second half is a little unfair, since that style of coding is entirely influenced by jQuery. You usually don't actually need to trigger a real DOM event there, you just want to execute some callback as if the element was clicked. Maybe I'm missing something, but the second half is adding an event handler (`somethingClicked` is presumably a function). That seems like a _very_ common thing to d…

[deleted]

Re: Sprint – A high-performance, DOM library for modern browsers

#49
post #42

Earlier quoted context omitted.

$('.something').toggleClass('collapsed') .click(somethingClicked); This simple and readable statement will turn into a lot of lines with DOM API.

[deleted]

> This does get a little uglier if the intent is that you have multiple '.something' elements, though. That part of the DOM API will always be pretty gross compared to jQuery, I think.

Well yeah hence my remark. Working on a single node in a single modern browser, the snippet will turn into

    var node = document.querySelector('.something');
    node.classList.toggle('collapsed')
    node.addEventListener('click', somethingClicked);
but if you need multiple nodes, now you have to manually loop and beware your closures.

And that's a best-case scenario, then you start traversing the DOM tree, adding elements, using events delegation and changing attributes and things go south fast.

Re: Sprint – A high-performance, DOM library for modern browsers

#50
Or, you know, use the Javascript DOM APIs? They're really not at all that bad.

  var d = document.createElement("div");
  d.className = "new";
  d.innerHTML = "

Hi Sprint

";
Skimming through the code I'm not sure the authors really grok Javascript anyway, which might explain why they need a (pretty thin) custom API for the standard APIs. toArray should be simply this:

function toArray(o) { return Array.prototype.slice.call(o) }

Instead it's:

  var toArray = function(obj) {
    var arr = []
    var i = obj.length
    while (i--) {
      arr[i] = obj[i]
    }
    return arr
  }
This is just silly:

    prepend: function() {
      insertHTML.call(this, "afterbegin", arguments)
      return this
    },

  var insertHTML = function(position, args) {
    var argsLen = args.length
    var contents = args
[...]

  var domMethods = {
    afterbegin: function(el) {
      this.insertBefore(el, this.firstChild)
    },
Perhaps this isn't so constructive and I should fork the library and annotate every method with its vanilla Javascript equivalent. I'm sure this post is non-constructive in some respects but I like Javascript, I just wish people would learn how to work with the language it instead of replacing the API wholesale.
Post reply on HN