036 JSJ DOM Rendering and Manipulating

by woody2shoes on November 30, 2012

Podcast: Play in new window | Download (Duration: 48:09 — 44.1MB)

Panel

AJ O’Neal (twitter github blog)
Jamison Dance (twitter github blog)
Joe Eames (twitter github blog)
Merrick Christensen (twitter github)
Charles Max Wood (twitter github Teach Me To Code Intro to CoffeeScript)

Discussion

01:29 – Merrick Christensen is a new regular panel member

CascadiaJS 2012
JavaScript Modules: AMD, Require.js & Other Wins: Merrick Christensen

03:58 – DOM Rendering and Manipulating

Backbone.js
Ext.js

06:49 – Differences

Load times
Ease of use
backbone.syphon

09:49 – The Ext.js approach vs the Backbone.js approach

15:51 – Templating engines

dust.js
handlebars.js
mustache.js
hogan.js
underscore
jquery

16:46 – handlebars.js vs mustache.js

18:08 – Templating engines (cont’d)

Mold.js
Ember.js
Metamorph.js
Knockout.js
Pure.js
Plates.js

26:34 – Difference between the click handler and the delegate function

31:49 – Template engines and string generations

33:01 – Writing templates and learning APIs

35:03 – Ext.js issues

39:32 – Dojo

Picks

Aldo (AJ)
On Being A Senior Engineer (Jamison)
Joshua James: From the Top of Willamette Mountain (Merrick)
sparks.js (Merrick)
grunt.js (Merrick)
knit-js (Merrick)
Functional Programming for the Object-Oriented Programmer by Brian Marick (Chuck)
New Media Expo 2013 (Discount code Wood20) (Chuck)
Skyfall (Joe)
LEGO Lord of the Rings (Joe)
Global Day of Coderetreat 2012 (Joe)

Transcript

JOE: If AJ talks on JavaScript Jabber, does anybody hear it?

CHUCK: [laughs]

AJ: Not if I don’t have my function key pressed down.

[This episode is sponsored by ComponentOne, makers of Wijmo. If you need stunning UI elements or awesome graphs and charts, then go to wijmo.com and check them out.]

[This episode is sponsored by Gaslight Software. They are putting on a Mastering Backbone training in San Francisco at the Mission Bay Conference Center, December 3rd through 5th of this year. This three day intensive course will forever change the way you develop the front-end of your web applications. For too long, many web developers have approached front-end as drudgery. No more! We’ll help you build the skills to write front-end code you can love every bit as much as your server-side code.]

[Hosting and bandwidth provided by the Blue Box Group. Check them out at bluebox.net]

CHUCK: Hey everybody and welcome to episode 36 of the JavaScript Jabber Show! This week on our panel, we have AJ O’Neal.

AJ: Yo, yo, comin’ at you from the cowboy sphere of Orem, Utah.

CHUCK: We also have Jamison Dance.

JAMISON: I’m coming at you from bathrobe sphere of Orem, Utah. It’s much more comfortable than a cowboy sphere.

CHUCK: We have Joe Eames.

JOE: Comin’ at you from a cluttered office.

CHUCK: And Merrick Christensen.

MERRICK: Hey guys!

CHUCK: So, Merrick is new. Merrick, do you wanna introduce yourself real quick?

MERRICK: Sure. My name is Merrick Christensen. I’ve been developing JavaScript for a number of years — big fan of it. You can find me on twitter and GitHub and all that kind of stuff.

JOE: Did you just recently speak at any conferences?

MERRICK: Yeah actually.

[laughter]

I just spoke at CascadiaJS on require.js. And actually, what’s really cool is they just barely put the videos for that up today and I was so stoked at how high quality. So to the CascadiaJS team, you guys did an excellent job.

JOE: Are the videos free?

MERRICK: Oh yeah. All free up on YouTube. And there’s some cool stuff — there’s stuff on like robots — it was an amazing conference. The organizers just did an amazing job.

CHUCK: Sounds like fun. Was that up in the North West somewhere?

MERRICK: Yeah it was actually in Seattle.

CHUCK: Nice.

MERRICK: Yeah it was beautiful.

JAMISON: I heard that as one of the after party things, they took everybody up to see the James Bond movie?

MERRICK: They did yeah.

JAMISON: Which is really a cool idea.

MERRICK: It was amazing man. They like, whoever went to that conference knows that they got way more out of the conference than they put into it. Like sponsors must have paid for the huge majority of that conference because they just gave so much. They took everyone out to Skyfall at the end of the conference and then after that, everybody went off for sushi. So it was pretty awesome.

CHUCK: Daaang.

[laughter]

MERRICK: It was amazing.

CHUCK: All right. Well, put a link to your talk in that chat and we’ll get it up on the show notes.

MERRICK: OK. Sure.

CHUCK: All right. I’m Charles Max Wood from devchat.tv and we are going to be talking about – I don’t really know what to call it, so I’m just going to kind of explain where it came from. So, my background with doing front-end JavaScript work has primarily been… well I started with prototype, went to jQuery, moved in to Backbone and my most recent project has been Ext.js — which is put up by the Sencha people.

The difference is that with Backbone — the way I’ve done it — is that you do most of your DOM manipulation with jQuery after you’ve just rendered an HTML page. And with Ext, it’s kind of, you know, this deep area of you call different things and it generates the HTML that provide you with the components you need and does a lot of magic on its end to make those components behave the way that it wants them to.

So I thought we could talk about kind of the spectrum between DOM management where you just put the HTML up and fight it with jQuery versus where you have full stacked framework that provides the DOM and manipulates it for you.

MERRICK: Yeah. One thing that is important to note is… I mean Backbone is awesome because it’s just this generic library right? Like, you can use it in so many different ways. In fact, a lot of people use it kind of like Ext, were you have this sort of object model to generate your UI on the client like these APIs etc. And that’s why you have an el property with Backbone because you can either set that el from manual HTML on the DOM, or you can create that element, set it like a template whether its Underscore templates or Handlebars templates or whatever. So you can use Backbone like you are using the Ext. It’s just Ext comes out of the box way more featured.

JOE: Yeah. Backbone of course so unopinionated, right? But then, like I felt like what Backbone wanted me to do was completely create a DOM from scratch and then completely recreate it every time I had any changes. That’s what I felt like Backbone pushed me into.

JAMISON: That’s the limitation of the templating library that you use — you don’t have to do it that way. There are templating libraries that just like we use one on ITV called Mold, that just uses… it just updates the DOM in place whenever elements in there change. So it doesn’t …. the element and recreate it.

JOE: Before we get that, what I’m just saying, I think that when you start out with Backbone, I think it pushes that–

MERRICK: Yeah. I think there’s very much truth to that because most people use Backbone with underscore templates of the box — which are great for a huge percentage of applications — but they do kind of have that attitude of re-rendering the entire DOM template for the particular view and just resetting it, rather than maybe listening for specific key change then updating a specific element within that template. In terms of Mold Jamison, like did you guys like rack things in span tags? Or like, how do you guys get that kind of seamless updating?

JAMISON: We just use the Handlebar thingies. I don’t know — I didn’t write it so I don’t know things about it, but it just walks the DOM tree and looks for changes in variables basically. So they look a lot like Handlebars templates, where you have double mustache brackets.

JOE: Wasn’t it written by a guy named “ninja”?

JAMISON: Yeah it was. Yeah so maybe it’s unknowable.

[laughter]

I’m trying to find stuff about it.

CHUCK: Right. So what are the trade-offs I guess between just rendering the DOM just by putting HTML up and then telling Backbone to go find the right elements and manipulate them vs. using something like the templates?

MERRICK: Well, for one, you get a better performance for initial page, at least like your perceived page load when it ships down with the HTML — because the users sees it immediately. It may not be completely functional because the JavaScript hasn’t been parsed and kind of done its work with the DOM yet, but the truth is that the initial reaction is much, much faster.

CHUCK: Right. Because essentially, what you are doing is pulling a blank layout from the server instead of having the server render things — which takes longer?

MERRICK: Well, I don’t know because it depends right? Because if you are using Backbone, the server renders… well, in the case that you are saying where you just assign an el, you are kind of doing a hybrid — where the server makes may send down some base HTML and then you are using Backbone views to assign to those elements and maybe know how to replace them.

CHUCK: Right.

MERRICK: And so the initial page load is faster because, well, the perceived load time is usually faster because it got some initial DOM to show the user before the JavaScript gets parsed and run.

JOE: On top of that, I think there is a big difference in how easy it is to work with it, right? I mean just shot gunning… well, again this is assuming you are following what I was saying — and that is every time you make a change, you completely destroy the DOM Node and you completely recreate it — that’s simpler than figuring out, “All right. One item change and you go update that one item.” So that’s another difference between just pointing at an existing HTML Node because if you don’t wanna keep destroying and recreating it, you are going to be able to find that piece that you want to update and I think that is more work, more coordination on your side.

To be fair though, there are a lot of the Backbone projects I guess you could say — Backbone plugins — that work with templating engines that like Derick Bailey, I know has one called I think backbone.syphon and it does like the subset updating for different pieces in a kind of declarative way. One of my favorite pieces like… I actually — in my development — tend to lean towards more like an Ext.js, where you just have these sort of components that you are then instantiating and working with like objects. And like that’s because it’s more easy for me to reason about and reuse components then having like the separate HTML thing that I’m working on.

CHUCK: Yeah. There is definitely that trade off that I’ve seen is that, you can think about the components in terms of objects and behavior as opposed to actually having to worry about, “OK. How do I serialize what I care about into HTML?” and then on top of that, worry about all the different eventing and things that are related to the DOM elements.

JAMISON: So I’m a little confused about what the difference between these two approaches that you are talking about. I just wanna make sure I understand so I’m not listening to a different conversation than what you are having. You are saying what you call the Ext.js approach is where you don’t deal directly with the DOM at all — you don’t write HTML at all — you just have some kind of abstraction that puts your data on to the page somehow? Is that correct?

CHUCK: Yeah pretty much. So essentially what you get is you have these different components; you can have like containers and then inside the containers you have different components like text fields or sliders or you know — they have all kinds of them — but those are just some examples. You basically just fill it up with these components and then those components know how to draw themselves into your HTML.

So then it says, “This div is the container div. And then we are going to put a label in here with a text field and it’s going to behave this way and we are going to attach these validations to it.” And so all you really care about is the behavior of the component as opposed to what the HTML looks like and all that stuff.

JAMISON: And when you are calling the Backbone approach is where you directly manipulate the DOM yourself?

MERRICK: Yeah pre-existing DOM. No reason you can’t use Backbone with this more like object layer, that’s how I use Backbone. And I think that’s how most – I shouldn’t say “most”—that’s how a lot of people use Backbone, is they like create these objects and then they extract the DOM manipulation behind methods for their views.

JOE: Isn’t that because of an issue with maintainability, right? If you start off this whole, “I’m going to have Backbone just use a pre-existing DOM”, then as your application reaches a certain critical threshold of complexity — which just makes a lot more sense where you these components that actually control their own DOM and sort of Ext.js does — isn’t that sort of the result of that? Doesn’t it end up with a lot more maintenance problems?

MERRICK: Well the interesting thing about Backbone is you can do both really easily because—

JOE: At the same time, sure.

MERRICK: Yeah. Because they just use the el property. I don’t know if you guys know, but the el key in a Backbone view, if you point that to like a selector, it will actually grab that off the DOM and you can represent that or it will make an element.

CHUCK: Yeah I’ve seen that.

JAMISON: So that’s a lot of how we use Backbone. We kind of lean more towards the abstract to DOM, but each individual view has a separate template. And when you instantiate a view, you also create this tree of DOM elements that the view needs. And then whoever is creating the view is responsible for putting it in to their DOM elements. So it’s like this tree of views.

It feels like kind of the best of both worlds, because if you need to go in and actually look at where these HTMLs are coming from, you can find the template file for whatever you are rendering. But you can also just ignore and say, “I need this layout that tile stuff in this certain way and then treat it from a more abstract perspective.”

MERRICK: Yeah we use it like that too. I prefer that it. It just seems to scale better and you can also kind of do things where you have like extending your components and it’s just a little bit more harder to reason when you are just working off some base DOM element. That’s kind of the older – I shouldn’t say the “older” – that’s kind of the jQuery-ish model where you have like a DOM element and then you progressively enhance it and this is not enough for a lot of these tech clients.

JOE: Not to be confused with progressive enhancements.

[laughter]

JAMISON: Not confused at all.

CHUCK: One other thing that I wanna point out though with the two different approach is if you are using a full stack framework, you’re usually more locked in to the way that they do things — their conventions. And so, if your problem or at least the way you’re thinking about your problem doesn’t completely line up with it, then you are going to wind up fighting your framework for a while until you figure out how to kind of merge the two ways of thinking.

Where with Backbone, it sounds like you guys are customizing it to the way that you’re approaching the problem — you are abstracting with the ugly bits and you know, with the DOM manipulation than anything else — but you kind of have control of that at all the different layers. And I really like that trade off — it just feels clean because I get control. I get to say, “This is how you render” and if I care about the niggly little pieces in the DOM manipulation, then I can build it in and abstract the way in a meaningful way. Where with these other frameworks, I have to work within what they provide me.

MERRICK: Yeah Backbone… I wouldn’t even say we are “customizing” it. I think Backbone lends itself really naturally to using it like that — but I agree with you in terms of the problem with Ext.js — it’s kind of an all-in right? Because your views are almost entirely declarative in a lot of ways. Like you are just declaring the way you want these components to behave. And say you wanted to abstract a component, it seems a little bit to difficult.

CHUCK: Well, it’s possible but you wind up… I mean you still have to play in their playground. So you do it in the ways that they have given you to do it. I mean, you can customize it — it’s just not always as simple as just changing the way that a function does something.

MERRICK: Well that’s Backbone too, right? Backbone is if like, you say you are customizing Backbone when you start working with particular way that don’t say you are customizing JavaScript when you write a program. Backbone isn’t anything — it doesn’t have an opinion. If you don’t give it an opinion, then you haven’t done anything to it.

CHUCK: Yeah.

JAMISON: AJ’s mic has been muted this whole time.

AJ: [laughs] I’m still here just in here – just haven’t butted in yet.

CHUCK: Yeah. So, I wanna talk a little bit about the templating engines that you guys have used — just because it’s interesting to me in the way that it generates HTML and how that affects the DOM. So, you guys just wanna sound off for the ones that you’ve tried and what you like and don’t like about them?

MERRICK: Yeah you know. I’ve used a lot of them; Dust and Handlebars and Mustache and Hogan and all of them. Underscore templates of course — which actually are quite elegant for how like little they cost.

JOE: I’ve done jQuery templates as well.

MERRICK: jQuery templates yeah I’ve done those. And I think Handlebars comes out as a big winner for me because I can be the pre-compilation and I can use them on Node. And a lot of people already have Mustache templates and so, it’s not like a far stretch to refactor something like Handlebars.

CHUCK: What is the difference between Mustache and Handlebars?

MERRICK: Well Handlebars… there is a few differences – there’s a few things that once you start using Mustache in my opinion that will commonly frustrate people. One of them is like, if you try and go down into an element, you can’t go back up. So say you have like a… you are iterating through a list of people and above people you have like a count of the total people — you can’t go up and get that count within that iteration. You are locked within the context.

Also, Mustache isn’t like extendable at all. It’s basically like, if else and then printing keys and then iteration – and the if syntax is the exact same syntax as the iteration. So if you wanna check if a collection exist, it will start iterating through it instead of checking if it exists — so you have to do a lot more pre-processing in your view models for Mustache. Whereas Handlebars is a little bit more flexible; they give you like a helper syntax to write your own helpers. They offer pre-compilation, so you can basically precompile your templates with NodeJS or Rhino or whatever and then just ship at runtime so that way you can get kind of a performance boost. There are precompilers though from Mustache now like Twitter has one called Hogan. But, Handlebars just ends up being a little bit more flexible and it seems little bit more useful because of that — for me.

CHUCK: What about some of these other ones? Jamison, you said that ITV has Mold.js. How does that that compare with these other ones?

JAMISON: So, the main issue that I’ve run into with using these other template engines is in cleaning up event handlers and avoiding re-rendering elements or destroying the whole because one little tiny element of something you’re trying to render changed — and maybe because I don’t know how they work very well. I don’t know, maybe you can also clear this up with me though but say you have a Backbone view and you bind a bunch of … with some DOM elements in the view and then you re-render the view because something changed, by default do you destroy the DOM element and make a new one?

MERRICK: So it doesn’t like destroy the total DOM element, but by default, it rips out kind of the internals and replaces the content, right?

JAMISON: Doesn’t that leave the event handlers dangling?

MERRICK: No because the Backbone views use event delegation. So since that parent element is what have the events that all the events are listened to by the parent element — which never gets destroyed unless you [inaudible]. So delegates the events. But you are right in that like, sometimes if you just update like one property, you only wanna like grab an element and just change the context rather than re-render this whole view, right? But that’s one necessarily a restriction of these templating engines like Handlebars — that’s more of a restriction of the way Backbone approaches the problem. Backbone kind of has this… like we said, Backbone is so un-opinionated, but this is how people naturally tend to use it. They say, “When my model changes, we call render” or instead of saying, “When my model fires a change event for this particular key, just re-update this little element” — you can do that with Backbone and you can do it declaratively with your templates with Handlebars, right?

Like, EmberJS offers first class data binding — like almost unparalleled. I don’t a framework — from my perspective – that does a better job of basically optimizing, when an event changes, computing how it should be rendered in the view and then updating just that specific view element — and they do it all with Handlebars helpers. Like saying how you can extend Handlebars, well Ember just uses Handlebars and they implement these Handlebars helpers that basically listens to these computer properties in these events from their run loop and then update just those sub sets of the DOMs by using — I think it’s called MetamorphJS — if you guys wanted to look at it, it’s a separate project but it lets you basically update just sub pieces. I think that’s what EmberJS uses to get that kind of MoldJS functionality that you are talking about.

JOE: Isn’t that kind of a strength with Knockout as well though? Is that to a binding?

MERRICK: Yeah Knockout does a great job other than… well, I shouldn’t bad mouth any libraries. One to the problems that I have with Knockout is just that it requires you to do a lot of sort of weird attributes and I guess you kind of do the same thing with Handlebars — which is more of a DSL. But yeah, that is a strength of Knockout.

AJ: So now there is a pause, I wanna bring up another one that I like is PureJS — and I think I’ve talked about this one before — but the nice thing about it is it’s not a Handlebars syntax. I think the Handlebars syntax is great for something that doesn’t have a data structure associated with it — like applying text file or something like that. But the DOM isn’t a plain text file; it has Nodes, it has stuff.

So, PureJS is nice because it uses your class names to determine how the template works. So if you don’t have class on something or you don’t have an element, then there is nothing to template. And it does precompiling and you know, all that like the other ones do. But instead of using the double bracket syntax, it’s something that is easy I feel to work with designers with too, because then they get to see like your dummy value and then the class name is kind of maybe hidden from them or they won’t touch it — doesn’t get in their way.

MERRICK: I have like a question for you on PureJS today. Do they work with like the DOM APIs or what?

AJ: So, the way that I believe it works is that you pass in your object — which is a mapping between CSS selectors and then data selectors — and then it runs over a bit of the HTML. You can run it like… you can do a compile step where you can just render it flat out but if you want the optimization, you do this compile step. And so I think that does some DOM manipulation stuff, but then creates a function that spits it out.

MERRICK: Yeah. Because that’s usually the criticism of that approach — like with this idea like CSS selectors being a way that you talk to the DOM I think is awesome but the problem is just the performance aspect of it, which working with strings tends to be a lot faster. And I don’t know — what are your thoughts on Plates.js?

AJ: So I haven’t used Plates.js — I think you mentioned that to me before and I really do wanna take a look at that — but, to answer the previous concern, so you can think of it like this: we can do the DOM manipulation on the CSS classes and then once you’ve done that, you can put Handlebars in there or some sort of token that allows the engine to know. So you run the compile step, it does a little bit of DOM manipulation, figures out where things are, can stringify it and then put in its token so that then its manipulating a string and actually outputting a string.

MERRICK: That’s pretty cool.

AJ: I mean, I would hope — in the brightest part of my heart — that people don’t use click handlers anymore. And I know that’s not true; like 97% of the people still do, but I never liked click handler. I always use the delegate method – always.

MERRICK: Yeah the delegate makes so much more sense. Like even if you are getting stuff in from Ajax and just replacing it — and from a performance aspect, delegation is just a better way to go. But one thing that is worth looking at — for those of you guys who haven’t heard of Plates — it’s from the Nodejitsu guys that’s part of the Flat Iron Framework, but what plates let you do is it lets you interact with… its kind of a DOM templating thing with CSS selectors except for because the DOM interaction is relatively slow, they did it all with strings. So you can basically map a CSS selector to a value — kind of like I guess PureJS. I haven’t looked at PureJS enough but it sounds like they have done some pretty cool things in PureJS to get the performance optimization. That’s awesome.

AJ: Well I’m not positive that that’s how it’s done. But that’s intuitively what I would think. And it says in the documentation that the compile step optimizes the function. So haven’t looked at exactly what it’s doing. However, I do wanna highlight that there is some negative to PureJS and that is that the directive mapping is sometimes a little hairy. I find that I commonly have to go back to the documentation to look at a few simple examples because for whatever reason, it just isn’t intuitive enough for me to be able to get it right every time. And that’s something that it looked like Plates when I was looking at their documentation, it seemed like it’s a little bit more intuitive the way that they use functions, where Pure doesn’t have any functions –its just a map object where you map… they have a special key that’s an arrow symbol. Like if you wanna iterate over an array, the key is the arrow symbol and that the value is a sub map.

MERRICK: Yeah Plates is pretty cool. And those Nodejitsu guys, they are awesome — if you need support and stuff.

CHUCK: So I have to ask, this my … question to the episode — in fact I might just count that as a term. My question with the episode is what is the difference between a click handler and the delegate function?

MERRICK: Do you wanna answer that AJ?

AJ: Yeah. So with the click handler, you are actually specifying that that particular element has the memory reference to the function that is handling it. So I have a button, I assign a click handler — either in the HTML itself of through JavaScript like a jQuery $selectButton.click type thing — and that function is memory referenced to that DOM element. Whereas if I wanna create a reusable widget, then I could have the widget id — so like sent email form or something. (That’s not really good example) — say photo gallery, like your Facebook friends type thing, right? So on the container for the widget that has all of the widget items is where I attach the actual listener. So it will be like jQuery will be $select widgetname.on and then sub-selector for the picture or whatever the item is.

CHUCK: So effectively, what you are saying is if any of these type of element that is the child of myself gets interacted with, then call the handler? I’m not sure… so what’s the difference between… I mean other than the layer and the DOM, what is the difference?

MERRICK: So, here is one of the biggest things Chuck. Say you are working in Backbone, have ever seen the events like hash you put in the events key and then you can put like a selector event, so that uses delegation and it binds in to your parent view. So whenever your parent view gets clicked, it delegates and then it figures out if that child was the target of that event—

CHUCK: Oh!

MERRICK: –callback. And so now, what is cool is: A. all of those event listeners are only a memory once. So for example, say you have a list of about a thousand users, rather than putting an in memory reference to each of those users, you can just put and in memory reference once to the ul and then use delegation to figure out which of the users is clicked. So that way, you have one event listener rather than however many thousands of users you have.

CHUCK: So the difference in how it figures out what was clicked and how to deal with it that the overall mechanism is mostly the same. It’s just that you are up a level and so you don’t have a million references to—

MERRICK: And also what’s cool is now you can replace your children right? Like, you can re-render your template a hundred times without having to re-bind your events.

JAMISON: So this is what I’m asking Merrick about earlier.

JOE: In that case Merrick what you are about – let me see if I’m clear on what you are saying – you’d still put the click in Backbone the hash you’d say, you know click and then the selector would be a li and if the Backbone views element, the el property pointed at the ul, the handler is actually on the ul, but its only firing if an li actually gets clicked.

MERRICK: Yeah and delegation has been in jQuery for a long time. It’s not even… I mean if you look at Backbone’s event hash, they really just parse that out and defer it to jQuery.delegate — I think its delegate.

AJ: Now its .on. Delegate still works, but the new syntax is .on.

MERRICK: Oh awesome. So yeah, because back in the day, when you are making Ajax request and getting mark up from a server, you had this awkward like, “Oh, I need to rebind all the events to this mark-up that I just got back.” So delegation also helps with like working with it because you could get mark up in your events — you didn’t have to rebind and unbind right?

CHUCK: Yeah. That makes total sense.

AJ: Cool.

CHUCK: All right. So, do you know if some of these other frameworks like Ember or Ext or are you know, some of the larger frameworks, that may or may not rely on jQuery use delegation. Is there are good way to know that?

MERRICK: I think almost all of them use delegation whenever they can.

CHUCK: So it’s just an assumption that most of these follow best practice of some kind and that will be–

MERRICK: Oh yeah. The whims with delegation are one of those that are just so obvious, that once you understand it, as a framework author, I’d be surprised if you didn’t use delegation every way you could.

AJ: Yeah. And there’s not really any downside, right? Because even in the smallest case, let’s say that you are only going to put one click handler on your entire page and you never even to replace that element, there’s no extra cost in doing it that way. So it’s kind of one of those discipline type things where if you only do it that way, you never have any disadvantage and you always get the advantage.

CHUCK: Makes sense to me. So the only other thing that I wonder then — because we talked a lot of how some of these frameworks and templating engines insert things into the DOM – do to most of them work through simply adding a string or text inside of whatever element? Or do they actually do some kind of DOM manipulation or replacement stuff in basic jQuery or edits for a level?

MERRICK: No. Most of them actually don’t even care are inserted. Most of them are like compatible with NodeJS, where at a box because they don’t necessarily care about the DOM, because I guess they made a design decision whether or it’s because the DOM is slow or not. But the truth is, most of them just basically take some sort of syntax, they come up with some sort of token tree and they parse that token tree into a function that then takes a data context and then just interpolates those data keys into that string. So for the most part, it’s almost like all string generation — from what I’ve seen with these templating engines. Maybe you guys have seen something else.

AJ: Pure definitely uses that DOM at least in the compile step and perhaps in the render step.

CHUCK: So one other thing that I kind of wanna dig into a little bit this — and this has been a trade-off I’ve seen between Ext and some of these others — is that if you are writing your own templates for your components or your views or whatever you wanna call them, it’s pretty easy to just know what is there. And the trade-off that I have seen with Ext.js is simply that you have to learn their API in order to get the components in it that you want — and so it’s a learning curve question more than anything else.

MERRICK: Yeah, but I tend to love that right? Because when people are interacting with your API, you have defense to change how it’s rendered.

CHUCK: Yeah.

MERRICK: And you can test it based on the API rather than the state — which is essentially the final state of the component ends up in being the DOM right?

CHUCK: Mh-hmm. And I think anybody who’s tried to test anything in the DOM knows how brittle that is. And so, if you have something that manages it at a higher level, there’s a definite pay off.

JOE: One thing I wanna just clarify from our previous discussion, in jQuery — if you are using the jQuery — if you use click… the $(selector).click, it actually does defer to … or in essence delegate — the same way that just calling just .on works. jQuery has been that way since I think 1.7 — so jQuery itself was actually internally fixing you from making mistakes there.

AJ: So is it attaching it just to the body at the highest level?

MERRICK: No, I mean truth is that it looks like it’s still pending it to the elements and just referring to on. Because I think it nulls the selector parameter — like a child selector parameter, right?

AJ: So you are not getting the benefit as if you have called–

MERRICK: I don’t think you are getting the delegate benefit if you look at it.

CHUCK: Yeah. So, two more things that I wanna point out with using Ext that we ran into: one is that we were writing selenium tests to run through thing. If you don’t know what selenium is, in essence it’s an acceptance testing framework that it basically attaches to DOM elements and then it will click on them or fill them or do whatever it’s supposed to do — you know, select something out of the list. So you can essentially drive… it fires up Firefox and it just drives Firefox. It also has an option with Chrome. And one thing that we ran into with Ext.js was that we actually had to open things up and inspect the DOM to find the elements that we wanted it