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

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

github.com

Post reply on HN
Print view View original

61–70 of 72 posts

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

#61

Post by rcgs »

jackmoore wrote: post #59
tshadwell wrote: post #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…

DOM inconsistencies aside, a big advantage jQuery has over native API is that it is just as easy to work with multiple elements as it is single elements. Modifying your example: var d = document.querySelectorAll('div'); d = Array.prototype.slice.call(d); d.forEach(function(el){ el.classList.add('new') }); Vesus: $('div').addClass('new');

It is possible to do that without the variable assignment in JS...

    [].forEach.call(document.querySelectorAll('div'), function(el) {
        el.classList.add('new');
    });
But I don't disagree that the jQuery example is easier to write/read/remember.

Though with frameworks like Angular or React I'm beginning to question whether we should ever be writing code like this at all.

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

#62

Post by rwaldron »

tshadwell wrote: post #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…

You're conflating "JavaScript the programming language" with "DOM, the awful sack of shit".

Don't do that.

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

#63

Post by sanderjd »

BinaryIdiot wrote: post #53
tshadwell wrote: post #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…

There is a lot of uses of innerHTML in this code which causes browser reflow; might get better performance creating all of the HTML components via document.createElement() and using document.createTextNode() for all text within a tag itself. But yeah cherry-picking may not be the most constructive thing however you do have good points. The DOM API is kinda funky (I wish it did some things like chaining) but it's very…

See, that's why I end up using these libraries. If I found myself doing the three statements for creating a div in your parent's comment, I'd pull that out into a function that does it, then I'd start finding other things to pull out as well, then I'd think "surely somebody has made a library that has these things pulled out nicely", and I'd find one of these libraries. Since I know that would happen, I just start with a library from the beginning.

But I suppose I'd love one that is thinner, like your "very thin wrapper", if anybody has pointers.

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

#64

Post by curiously »

Hey guys found this neat little library

http://vanilla-js.com/

I get 12+ million operation (a true master race class) vs advertised 800,000 and peasantry of jQuery's 300,000.

Not sure if I want to sacrifice performance for aesthetically better looking (debatable ofc) syntax and bother investing time learning how to do something slower.

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

#65

Post by [deleted] »

tshadwell wrote: post #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…

[deleted]

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

#66

Post by Jgrubb »

smt88 wrote: post #54
anentropic wrote: post #34

Earlier quoted context omitted.

they solve different problems though... syntactic sugar from TypeScript et al solve problems with Javascript the language jQuery solve problems with the various builtin APIs like DOM etc that are part of either Javascript or the web browser host

I just assumed the person I was replying to was complaining about document.getElementById('whatever') (etc.) vs $('#whatever') . In response to your comment, polyfills are more future-proof solutions to browser compatibility, which is the only remaining problem that I see jQuery as solving well.

> I just assumed the person I was replying to was complaining about document.getElementById('whatever') (etc.) vs $('#whatever')

Actually that is what I was referring to. I must not have given TypeScript enough of a shake. I couldn't find the section in the early tutorial that showed me that sugar, and I also couldn't figure out how the typing stuff would help me working with a bunch of network-y type apps. Obviously this is my own failing. Inspired now to give it another shot, so thanks.

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

#67

Post by nicksardo »

tshadwell wrote: post #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…

Regarding toArray, the creator probably went that route to be more performant. http://jsperf.com/array-prototype-slice-call-vs-slice-call/1...

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

#68

Post by jackmoore »

rcgs wrote: post #61
jackmoore wrote: post #59

Earlier quoted context omitted.

DOM inconsistencies aside, a big advantage jQuery has over native API is that it is just as easy to work with multiple elements as it is single elements. Modifying your example: var d = document.querySelectorAll('div'); d = Array.prototype.slice.call(d); d.forEach(function(el){ el.classList.add('new') }); Vesus: $('div').addClass('new');

It is possible to do that without the variable assignment in JS... [].forEach.call(document.querySelectorAll('div'), function(el) { el.classList.add('new'); }); But I don't disagree that the jQuery example is easier to write/read/remember. Though with frameworks like Angular or React I'm beginning to question whether we should ever be writing code like this at all.

Agreed. I mainly use React these days, and directly modifying the DOM is starting to feel dirty.

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

#69

Post by smt88 »

Jgrubb wrote: post #66
smt88 wrote: post #54

Earlier quoted context omitted.

I just assumed the person I was replying to was complaining about document.getElementById('whatever') (etc.) vs $('#whatever') . In response to your comment, polyfills are more future-proof solutions to browser compatibility, which is the only remaining problem that I see jQuery as solving well.

> I just assumed the person I was replying to was complaining about document.getElementById('whatever') (etc.) vs $('#whatever') Actually that is what I was referring to. I must not have given TypeScript enough of a shake. I couldn't find the section in the early tutorial that showed me that sugar, and I also couldn't figure out how the typing stuff would help me working with a bunch of network-y type apps. Obviously…

It's entirely my own fault, but this has been a really muddled conversation.

When I mentioned TypeScript, I only meant that it (and other languages that compile to JavaScript, like Go) is a better syntax overall. I didn't actually mean that it helps with DOM selection/manipulation.

So if you want short DOM syntax, I'd suggest using vanilla ES6[1] with polyfills, and then figure out what's really wasting your time. Then, you can write your own sugar for it.

In my opinion, document.getElementById is something that you end up writing a lot and is really long, but with autocomplete in a good IDE, it's not a big deal. Plus, any JS developer who sees it will know exactly what it does and what it returns.

1. https://babeljs.io

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

#70

Post by BinaryIdiot »

masklinn wrote: post #60
BinaryIdiot wrote: post #57

Earlier quoted context omitted.

> 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. Why would things so south? The DOM API, while not very elegant, is very simple and straight forward. So you need some loops because jQuery hides that for you, so what? Why does using the DOM API make you think things go south fast ?

> Why would things so south? The DOM API, while not very elegant It's not just "not very elegant", it's highly inconvenient and horrendously verbose, and generally fails to take advantage of or correctly integrate with the host language as it's originally expressed in a restrictive and alien IDL. > is very simple and straight forward I completely disagree on both count, the API is neither simple nor straightforward,…

There are plenty of reasons to not like the DOM API but you're not doing a good job stating your case.

> It's not just "not very elegant", it's highly inconvenient and horrendously verbose, and generally fails to take advantage of or correctly integrate with the host language as it's originally expressed in a restrictive and alien IDL.

This is kinda what you already said before but haven't really clarified. What doesn't integrate correctly with the host language? It's certainly inelegant but "horrendously verbose" seems quite extreme. Creating, deleting and modifying elements is easy and straightforward, adding and removing event handlers is easy and straightforward; you rarely need more features than that. Could you provide some insights here?

> repeatedly adding children at the start of a possibly child-less element

What are you referring to here? insertChild has let you do this and has been part of the standard since 1997. Are you referring to something else or a specific issue?

> enjoy handrolling element-relative events delegation

What are you referring to when you say "handrolling"? Are you referring to jQuery's ability to set, say, a click event on a parent to target the children so the children can be removed without changing it? I hope that's not all you're referring to because that's dead simple to deal with and using jQuery's event bubbling isn't always very speedy. If you're creating these elements why can't you attach and detact event handlers?

> Element#matches is a pointless waste of API space

Matches allows you to look to see if a match exists without returning the data. This may provide slightly better performance if all you need to do is a check for something. I agree it's not entirely useful but a "waste of space" is a bit extreme; it can serve a purpose and it's a very small addition. Nit-picking on single methods isn't exactly helpful.

> such as the live nodelists which serve no other purpose than making implementations slower, more complex and event less integrable with the host language

First you complain the DOM API doesn't integrate into the host language and now you complain about live NodeLists when this is using a JavaScript semantic. You need to pick one and not conflate the two. JavaScript passes objects by copy of reference (meaning you can modify the original but not replace). Implementing NodeList to be live makes perfect sense here. Would you prefer the DOM API actually NOT follow standard JavaScript and do something...funny?

> So that means overly complex user code for no good reason but the base API being garbage. And jQuery does not "hide loops", that's just a side-effect of jQuery working at a higher conceptual level of manipulating nodesets.

The features you sighted previously allow you to act on multiple NodeList items without iterating through them directly. jQuery is still iterating through them in the background. How a loop is "overly complex" for "no good reason" I do not understand.

Post reply on HN