{"id":91,"date":"2009-11-19T10:24:45","date_gmt":"2009-11-19T18:24:45","guid":{"rendered":"http:\/\/adam.yanalunas.com\/blog\/?p=91"},"modified":"2009-11-19T10:24:45","modified_gmt":"2009-11-19T18:24:45","slug":"making-friends-with-the-dom","status":"publish","type":"post","link":"http:\/\/adam.yanalunas.com\/blog\/archives\/91","title":{"rendered":"Making friends with the DOM"},"content":{"rendered":"

Any JavaScript developer who spends more than a blink of an eye working with the DOM has probably come despise the API. It’s not that there’s a dearth of features (welll….); I think it’s the verbosity that causes modern application development woes. For the one-off script that adds an onclick<\/code> or modifies some text the DOM API is fine and dandy. Try scaling up to developing an application or, perhaps, a framework<\/a> and things get annoying and messy right quick.<\/p>\n

When Tommy<\/a> finally gave jQuery a try and discovered there was no native DOM manipulation tools he decided to roll his own plug-in he calls FluentDom<\/a>. The code is clean and quality, as I’d expect from him, but the interface drives me bonkers.<\/p>\n

I’m a fan of configuration over convention<\/a>, a concept which, when combined with my MooTools history, has lead me to favor using object literals as configuration “objects”. When I use MooTools to create a new element<\/a> the only arguments are the element type and an object literal with any configuration options. This is where Tommy’s code style differs. In FluentDom you set a specific attribute with specific methods with calls able to be chained together. This isn’t to say that FluentDom couldn’t be used with a configuration object, it’s just not as clean an implementation as I prefer.<\/p>\n

In a message to him I said this:<\/p>\n

\nThe benefit to setting attributes via an object literal is that I can use one set of preset attribute values and pass that around. Quite handy if you\u2019re doing something like iterating and creating a list of similar elements but particular ones might have subtle differences. Also easier to maintain and extend. Given your code it\u2019d be a trivial modification to do this during a create call.\n<\/p><\/blockquote>\n

Which do readers prefer, specific, chainable method calls or ambiguous configuration object?<\/p>\n","protected":false},"excerpt":{"rendered":"

Any JavaScript developer who spends more than a blink of an eye working with the DOM has probably come despise the API. It’s not that there’s a dearth of features (welll….); I think it’s the verbosity that causes modern application development woes. For the one-off script that adds an onclick or modifies some text the […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[6],"tags":[27,40,16],"_links":{"self":[{"href":"http:\/\/adam.yanalunas.com\/blog\/wp-json\/wp\/v2\/posts\/91"}],"collection":[{"href":"http:\/\/adam.yanalunas.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/adam.yanalunas.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/adam.yanalunas.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/adam.yanalunas.com\/blog\/wp-json\/wp\/v2\/comments?post=91"}],"version-history":[{"count":4,"href":"http:\/\/adam.yanalunas.com\/blog\/wp-json\/wp\/v2\/posts\/91\/revisions"}],"predecessor-version":[{"id":95,"href":"http:\/\/adam.yanalunas.com\/blog\/wp-json\/wp\/v2\/posts\/91\/revisions\/95"}],"wp:attachment":[{"href":"http:\/\/adam.yanalunas.com\/blog\/wp-json\/wp\/v2\/media?parent=91"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/adam.yanalunas.com\/blog\/wp-json\/wp\/v2\/categories?post=91"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/adam.yanalunas.com\/blog\/wp-json\/wp\/v2\/tags?post=91"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}