062 JSJ Dojo with Dylan Schiemann

00:00
Download MP3

Panel

Discussion

00:57 - Dylan Schiemann Introduction

Picks

Next Week

Burnout

Transcript

JAMISON:  This is my voice. CHUCK:  You keep it with you at all times, don’t you? JAMISON:  I do. Unless I go to a rock concert or something. Then I leave it there. [Hosting and bandwidth provided by the Blue Box Group. Check them out at Bluebox.net.]  [This episode is sponsored by Component One, makers of Wijmo. If you need stunning UI elements or awesome graphs and charts, then go to Wijmo.com and check them out.]  CHUCK**Hey everybody, and welcome to Episode 62 of the JavaScript Jabber Show. This week on our panel, we have Jamison Dance. JAMISON:  Hi, guys. CHUCK:  Joe Eames. JOE:  Hey there. CHUCK:  AJ O’Neal. AJ:  Not coming at you live. Not at all. CHUCK:   I’m Charles Max Wood from DevChat.tv and we have a special guest this week. That’s Dylan Schiemann. So, do you want to introduce yourself real quick, Dylan? DYLAN:  Sure. Thanks Charles. I’m Dylan. I’m one of the founders of an open source project called the Dojo Toolkit. I’m also the CEO at SitePen, a company that builds web apps and provides JavaScript training and support. CHUCK:  Awesome. Dojo’s been around for a long time, hasn’t it? DYLAN:  Nine years. CHUCK:  Nine years. DYLAN:  Oh, yeah. Three lifetimes in the Internet age, I guess. CHUCK:  Does that make it older than jQuery? DYLAN:  It does, yes. JQuery, I think, started about seven years ago, maybe. Six or seven years ago. CHUCK:  I remember seeing a couple of websites built in Dojo way back in the day. I don’t remember exactly which ones they were. For some reason, I got the impression that it was a framework, but it’s more of a toolkit. It’s much more like jQuery than it is like, say, Backbone or Ember or any of those. DYLAN:  It’s kind of everything. You can use it as a simple toolkit like jQuery. You have DOM manipulation, APIs and Ajax event handlers and promises and deferreds and other functional programming constructs. Then there’s a widget library on top of it that is very nice. It’s international but flexible and accessible. Each widget, in many ways, can be bound to a data object store giving it a little MVC-style interface. But there are application frameworks that build on top of that and native vector graphics, APIs. It’s really kind of this massive collection of 1500 or 1600 modules that come together and start as a very small toolkit that can be 3 or 4 kilobytes gzipped all the way up to the entire kitchen sink if you wanted it. CHUCK:  So, just to give us an idea, are there websites out there that are built on Dojo that you’re sort of proud of? DYLAN:  Yeah. It’s always frustrating to be, because of course, you see your work used in ways maybe you wouldn’t want to use it, but there are some popular consumer sites that use Dojo such as TDAmeritrade.com uses it for their stock brokerage platform or The Wall Street Journal uses it as their toolkit of choice for viewing financial news. A lot of banks have started to embrace Dojo like JPMorgan Chase or TD Bank up in Canada, things like that. Of course, SitePen and Dojo use their own toolkit. There’s a project called voro.com that uses Dojo in a pretty interesting way that is financial charting in the cloud. There are thousands of other sites. But a large majority of Dojo use lives inside applications that are more complex than a typical .com. They’re more along the lines of, “I need to build a financial trading system and I want to do that in a browser, but it’s behind a firewall or behind a login.” One of the more popular companies for building mapping technology is a company called Esri. They provide something competitive with Google Maps, but much more focused on people who typically work in governments or agencies that need to provide demographic information. They built their JavaScript API on top of Dojo. Almost any government agency that has a map-based project uses Dojo because they choose to use that API. So, there’s a lot of reach into a lot of different places that isn’t obvious at times. JAMISON:  So, I feel like there’s an elephant in the room right now and I want to make that elephant visible to everyone. That’s that Dojo seems like it has this connotation of old and uncool. Why should I care about it now? DYLAN:  Well, if you tried it nine years ago, it’s basically not at all like how it is today. What we’re seeing is that the JavaScript community has kind of grown up a lot. Six or seven years ago, people were like, “Look, yellow fade effect,” or, “Look, I can do an Ajax request.” But now, what we’re seeing is pretty much everyone out there is like, “Okay, we need modules. We need good application architecture. We need all of these different things.” Many of these things have sort of permeated from Dojo into other projects. In fact, I think Peter Higgins, either yesterday or today gave a talk at JSConf called ‘Dojo Already Did That’, which is kind of a joke about JSConf. Every year, people are like, “Oh, Dojo already did that.” We are a community that seems to love to reinvent the wheel, even if there’s something out there that’s great. We want to recreate it ourselves from scratch. That’s cool, but what it means is that a lot of the things that we’ve done with Dojo, you can easily use in other projects. It’s not really about, “Hey, use Dojo or jQuery or Backbone or whatever.” It’s more about, “These are tools you can mix and match modules as needed,” or you can decide, “Hey, I like this approach and I want to use it.” For example, the most popular module loading system today on the web is RequireJS. Well, RequireJS is a Dojo Foundation project that was started by the person who worked on the Dojo module loader. So, we’ve really tried to take the approach of, “If you don’t want to use Dojo, that’s fine.” We’d like to give you the tools that you could use inside other ecosystems rather than trying to lock you into a particular environment. The best thing I’ve seen Dojo do for the community is sort of create these things that other people are using without really knowing they’re using anything at all related to Dojo, which is fine. If they have that connotation, they can ignore that. But chances are, they’re probably using something that comes from Dojo and that’s what it’s all about really is making it easier to build applications and providing good projects. JAMISON:  Sure, that makes sense. CHUCK:  It was interesting. I was looking through the tutorials to get started. The first couple that I went through it was like, “Well, I do most of this with jQuery.” But there is still so much more there. There were a couple of things that really stuck out to me as things that get me a little bit excited about Dojo. The first one is that, like you said, it hooks into AMD and uses RequireJS for everything. At first, I didn’t get it. But once I started using it, it was like, “Oh, this makes things really, really nice.” Is there a reason why you decided to go with AMD and RequireJS? DYLAN:  Well, prior to that, we had a synchronous loading module system, which the syntax of it was a little less cryptic. But the problem, of course, is that you were loading modules synchronously, which gave the impression of every application being slow. The way we solved that early on was saying, “Well, just do a build.” And a build is basically, take all these HTTP resources and combine them into one or two files so that they can be optimized quickly. But of course, no one does that when they’re first trying out a project. So, the impression was, “Hey, this Dojo thing is slow.” Also, we had this concept of namespaces so that you could easily mix and match work across projects. But namespaces involve the creation of fairly large object structures in memory. Especially in older versions of IE, this made applications quickly sort of cycle into that constant garbage collection that we all love when dealing with IE 6 or 7. And so, AMD evolved from that as a new approach that would give us two benefits. One is being able to do all of our JavaScript loading asynchronously by doing script tag injection rather than by doing XHRs to pull in resources. Then the second benefit was that we could do all of our modules somewhat anonymously so that basically every reference to a module is just a local variable lookup. So, you don’t have these long namespace chains, but also you don’t have these large object structures in memory representing what you’re just trying to do to keep things separated and modular. So for us, it was sort of a syntax that we could retrofit into the language that covered all of our use cases for how we need to load modules. And it gave us these nice performance benefits without any other change. So for us, it was sort of a no-brainer. It evolved somewhat also out of the CommonJS module specification that’s popular for Node. The CommonJS syntax is a bit simpler, but when you’re running an application inside of Node, you don’t worry about loading resources asynchronously because they’re all already there in memory or on the same server. But when you’re running over the web, you want to be able to load things asynchronously and that syntax, unfortunately, doesn’t facilitate that. Hence, the AMD syntax and their approach make that easy for us to get the best of both worlds, which is something that can work over the web and that’s fairly terse and concise and modular. CHUCK:  I think you’ve outlined the benefits of AMD and RequireJS very, very well there. DYLAN:  Thanks. CHUCK:  Those are the problems that it solved for me. DYLAN:  Absolutely. If you don’t have a large project and you don’t have a lot of modules, I still think it’s a good idea because at the end of the day, your application is going to get bigger. It’s going to be used by other people. It just introduces a level of discipline that you don’t get if you try and sort of shove all of your application logic into a single file. CHUCK:  I have another question or another thing that I wanted to go into and that is, I was just muddling around your website and I noticed that you have a widgets framework. DYLAN:  Yes. CHUCK:  Can you talk about that really quickly because I really haven’t seen anything like that. I’ve done similar things with views in Backbone and stuff, but it’s not the same. It’d kind of be nice to have something that really is kind of focused on widgets. DYLAN:  Right. What Dijit is, is it’s a collection of user interface widgets as well as a framework for building user interface widgets. Basically, you can think of the widgets that are provided in Dijit as sort of reference implementation widgets. They are generally classified into three different categories. One is form controls, basically providing placements for most of the native controls where you can’t style them in old IE the way you would want to, as well as controls that don’t exist. Even in HTML5, sometimes you want a combo box and that hasn’t been around for a long time until now. The second class is layout widgets. The idea is basically, if you want to create a single-page application and you want to put things side-by-side and you want to introduce splitters and other user interface controls, to basically be able to say, “Oh, I want this to be next to this. And I want this to lay out here. I want this to be closeable.” Things like that. Then the third is other widgets, like grids and rich text editor controls and trees and things like that, that sort of don’t fall into those two other categories. But then more importantly, underneath that is a system that supports several things. One is, any widget can be instantiated either through an HTML markup with custom attributes, using the HTML5 data attributes, or it can be instantiated through JavaScript. Two, they’re all internationalizable and accessible. Basically, it’s really easy using resource bundles to provide translations for each of your widgets, as well as using ARIA roles and all of the good web content accessibility guidelines work to basically say, “Okay, this widget works in a colorblindness environment. It works through keyboard navigation. It works with screen readers,” things like that. The next thing is that each widget is an HTML file, a CSS file, and a JavaScript file. And so, the HTML is the underlying template that’s going to be rendered. And it has some nice convenient custom attributes that can provide hooks to your JavaScript. For example, when you want to put five widgets in a page, you don’t want to use any HTML IDs in them because of course, you can only have one on a page, so it defines these custom attach points that basically say, “Okay, in my markup, I’ve defined this attach point fooNode.” Then inside the scope of the instance of that widget, I can say this.fooNode and it gives me a reference to that node reference within that widget instance. So, that’s really quite handy and quite easy for creating reusable multi-use widgets within a page. Beyond that, it supports a lot of other features. For example, you can mix in the capability for a widget to contain other widgets, or for managing relationships between widgets. Most of the widgets use a pub/sub mechanism to be able to communicate changes. Then widgets that display data bind to our object store API, which basically allows us to provide different data services. But the widget itself is just aware of the ability to get and set data. For example, you can say, “I’ve got a grid widget. It’s bound to this data source that’s in memory. I want to get data updates.” Then basically, hook it up and then you grid that live-updates as your data source changes. So, it’s a pretty nice system for user interface controls. Whereas a lot of the Backbone views are sort of probably a level up from that, managing the entire layout of your page, but not necessarily low-level user interface controls. CHUCK:  Awesome. That’s awesome. I’m definitely going to have to look into this a little bit more. DYLAN:  In many ways, it’s interesting. Dijit is kind of the basis for where the original web component specification came from. If you’ll look, for example, at a project like Polymer, which is in very pre-alpha, it is in essence building Dijit over again on top of the web component spec and the shadow DOM API and a lot of these new APIs that are sort of based on the things that we’ve done with Dijit, that really should be easier to do in a browser. You can imagine Dijit 2 or Dijit 3 eventually moving in the same direction, building on top of whatever’s available on a browser. But we’re pretty pragmatic at Dojo. So, we really take what’s there today or what’s there very soon. Whereas a project like Polymer is sort of, “Here’s where the world is going to be in five years. Let’s start building for it now, because Chrome supports it.” AJ: **Does somebody use a different browser? [Laughter]DYLAN:  Remember, Dojo has a lot of enterprise users and a lot of them don’t have a choice, so they’re stuck with IE 8 or 9. Or a lot of people still do like Firefox, because… AJ:  They’re purists. DYLAN:  I actually prefer Firefox, for one reason. That’s the Awesome Bar. The Awesome Bar remembers more about what I’ve done conveniently than Chrome’s address bar does. And so, I find myself using Firefox for most of my non-development work, which is like reading articles. I know if I can remember a fraction of the title from like six months ago and I haven’t cleared my history, Firefox will remember it for me. Whereas Chrome, I kind of have to remember sort of the order in which the title was described. It doesn’t really do a good job of remembering sub-words that I’ve browsed in my history. AJ:   I have noticed with Chrome that it is a little bit inconsistent about how it remembers your history. DYLAN:  Yeah. And that alone is enough for me to still use Firefox. And Firefox has improved a lot in terms of performance. That said, choice is good. We’re all about choice. We want to support any browser that isn’t terrible. For example, Dojo 2 will support IE 9 and newer and other modern browsers, but it won’t support 6, 7, and 8. Whereas Dojo 1 still supports 6, 7, and 8 and it’s still going to be maintained for a while until no one cares about those browsers anymore. CHUCK:  How do you make a decision like that? DYLAN:  Well, it’s actually one we made recently. It’s not an easy decision because we do have a lot of enterprise customers who are using IE 8 and 7. One of the reasons they choose Dojo is because we do support those browsers pretty well. But they do contribute to this factor of, “Wow, there’s a lot of code in there that is old and kludgy to support those browsers that I’d love to get rid of.” Really, we’re looking at, “Okay, Microsoft is going to finally, hopefully, for real, end-of-life IE 8 and XP next year.” So, if Dojo 2 comes out next year at roughly the same time, we can safely assume that, “Alright, we can support browsers that are actively supported by their vendors today.” We still have the one .X line of code that we’re going to continue to support as long as people care so that we can still give them updates and crucial fixes. But that way we can focus most of our new efforts on something that’s a lot cleaner. CHUCK:  So, I’m just curious because I heard that with jQuery, when they made this decision, it allowed them to remove a ton of code from their codebase. How much code do you think that’s going to remove from the Dojo codebase? DYLAN:  In some modules, 10% or 20%. In other modules, 100%. We have some code that is strictly for 6, 7, and 8 support. Overall, I don’t know what total percentage. For example, our native vector graphics implementation GFX, it supports Canvas and SVG, of course, but it also supports Silverlight and VML. So, the Silverlight and VML code can be dropped immediately. There’s probably half the codebase for vector graphics. It’ll add in WebGL support, presumably and be able to support more features. There’s one module where it’s a huge benefit. Querying, to be honest, if you drop 6, 7, and 8, there’s not really much left to do for querying. IE 9 doesn’t quite have all the features you might want and of course, there are custom selectors that aren’t really part of any CSS3 spec that maybe you want to support, but you can probably shave 80% to 90% off of the size of your query engine if you don’t have to support 6, 7, or 8. Other features like aspect oriented programming, you really don’t save anything at all, except maybe the ability to do native getters and setters. Modern browsers get rid of some of the cruftiness you might need in your API. Though there’s still some work to be done in ECMAScript 6 before we really can drop some cruft there as well. They build it to basically watch for a change to a variable is something that’s kind of elusive and always supposed to live one release away and we’re never quite there to have a clean solution. So, we just have to re-implement the ability to bind or watch changes to properties or variables throughout an entire codebase, which means your entire API is built around that notion. That adds a lot of cruft and we’d love to get rid of that at some point in the future as well. JAMISON:  So, you mentioned Dojo 2. You mentioned part of it is dropping support for old browsers, but what’s cool there that’s coming besides that? DYLAN:  Well, that’s still early. We’re still a year out. We’re kind of deciding what is cool and what is not. To me, one of the things that’s kind of bugged me for a couple of years is we have Dijit and we have Dojo Mobile. And Dojo Mobile is a collection of user interface optimizations for mobile UI. It’s not quite the same as Dijit. Now, you can use Dijit on mobile or you can use Dojo Mobile on mobile if you want to match the look and feel of the device. One of the things we’ll do for Dojo 2 is basically say, “Alright. We’ve got one user interface library and maybe the term’s kind of silly, but we want responsive Dijits.” So basically, if you’ve got a widget and you change to a smaller form factor, you want to be able to change the capabilities of it quite easily. And that’s not really something you can do with responsive design with widgets because responsive design is basically about media queries and pulling in CSS. But if you rely only on that, you’re going to pull in all the JavaScript logic that you need for both the desktop and mobile browsers. That’s not necessarily the ideal, because of course, in the environment of a phone, you want to optimize for your resources being as tiny as possible. So then, you see people optimizing in ways that are not fun and not pleasant. We really want to streamline that process and really just making it easier to build applications. We’ve seen a lot of maturity from, you mentioned Ember and Backbone. And Dojo’s had a lot of app framework-y stuff, but I think we’ll see something come along that will be quite powerful and quite easy to use that really hasn’t been done before. There are so many different ways to go from local storage to really nice grid widgets to cleaner APIs. And it’s not really as sexy as saying, “Look, here’s this brand new thing that’s reinvented the wheel from scratch.” But you just see lots of different things that can be cleaned up and made possible that weren’t really doable when we started Dojo in 2004 or when 1.0 came out in 2007. So, if you think about it, 1.0 is a version of Dojo and we’re on 1.9 right now, which was just release earlier this month. You can pretty much write code in 1.0 that will work in 1.9. Through the course of Safari and Chrome being introduced to the world and being turned into real browsers and the iPhone coming out and all of the mobile browsers that have followed since then, we’ve managed to create a toolkit that can pretty much take old code and make it work with the new version. That said, of course, if you want to take advantage of newer features like AMD, you do have to rewrite a lot of your work. But still, it’s pretty impressive to think that something that was created six years ago can still work today. In fact, Apple was using Dojo 0.4 on their store until, I think, it was last year. So they were using code that was seven or eight years old to basically update your shopping cart with the pricing information based on the features you had selected for a very long time. So, we’re really into longevity of code, which is cool. So, 2.x is sort of the time where we say, “Okay. A lot’s changed in six years. It’s time to provide a better starting point that’s easier to work with, that takes advantage of browsers today and tomorrow without alienating our users, of course.” So, giving migration scripts and a path forward and not changing the API so much that people feel like it’s a completely new toolkit and might as well reevaluate the world. But something that keeps what they like but improves upon it rather than just burning it down and starting over. CHUCK:  It seems like it’s not the dominant tool, even though it’s been around for so long. I guess the question I have is how do you market an open source project? How do you help people figure out that Dojo is the tool that they need? DYLAN:  It’s interesting. It’s not a problem I worry about. Maybe that’s a bit naïve, but I worry about building good tools that people can use in a nice open source ecosystem. So, to me, if one tool wins, we’ve kind of failed in our mission. The goal isn’t to make Dojo win at the expense of jQuery. The goal is to provide stuff that people want to use. And if they don’t want to use it, they’ll use something else. No amount of marketing is really going to change that. That said, probably the best thing we did to market Dojo ever was create a collection of tutorials on the Dojo site that make Dojo more approachable to a wider audience of people. CHUCK:  I’m going to interject here because they are really good. I’ve been reading through them and they’re excellent. They’re superb. DYLAN:  Thank you. Basically, SitePen spent about a year of development time for a person, but spread across the team, to create most of those because we felt like people complained relentlessly about the documentation. Now, they complain there’s too much documentation. So, I’m okay with that complaint. What it means is we’ve got too many different versions of too many different things because we version our documentation by release. It’s easy to end up on the wrong version and all those good problems. But good documentation and good APIs are the best way you can market an open source project, followed quickly by nice demos that impress people and do that. Dojo is used extensively throughout large enterprises. The number of banks, insurance companies, large corporations, pharmaceutical companies, companies that you’re not going to find out because they’re not blogging about it, but then you find out they’ve got 3,000 developers that use Dojo for 100 web apps internally. That’s not sexy, but it’s awesome. What we find is we’ve got 1% of the public Internet and 25% to 50% of the private Internet use Dojo. So, it’s not the sexy thing that’s going to make people say, “Wow. Amazon.com used this.” They’re set in their projects. But we have a lot of users and obviously enough to support the project and support companies built on top of it and use it. My focus is if Dojo is not a project that I would use as my first choice, then I’ve lost my way. That’s where I start, 2.0 is about making sure that that continues. Otherwise, it doesn’t matter how much we market old stuff. No one will use it in two or three years. AJ:  I did want to throw out there for people in the Midwest, KSL used to use Dojo. JAMISON:  Also cool. DYLAN:  The other thing I was going to say was if you look at YUI, I noticed you posted a link there, YUI 3 made a huge mistake. That was they basically re-marketed themselves as all the cool features in jQuery and Dojo but as YUI. But then when they released, one of the reasons people really liked YUI 2 was it also had a number of nice user interface widgets done differently than Dojo but you could say it was somewhat comparable to Dojo’s widget set. And they released with four UI widgets. So, everyone said, “But where are the widgets? That’s what I like. That’s what I use.” When we release Dojo 2, we can’t just release the core and say, “Yeah, we’ll have another set of widgets in a year.” No one’s going to care until the UI components and convenient features are there. So, we won’t be making that mistake, hopefully. AJ:  Sounds kind of like how no one will care about the Wii U until Mario Kart is there. DYLAN:  Right. Exactly. CHUCK:  It’s kind of funny, though. Wii U really has not done super well. And yeah, I think that’s really it. All the stuff that people want to do with it, they can’t yet. DYLAN:  Yeah. Right. AJ:  So, the reason I posted the link to the YUI, because I just wanted to bring up this idea of graded support. It looks like they changed their page. With YUI 2 or 3 or whichever one it was they released, they had this graded support where basically they’d say… DYLAN:  A B C, yeah. AJ:  Yeah. With certain browsers, it would gracefully degrade. So, you wouldn’t be getting the shadows or something like that. I was just kind of wondering if you guys have a particular feeling about graded support versus just dropping it entirely and when is the right time. You touched on it a little bit and I just wanted to hear a little bit more. DYLAN:  So, Dojo today supports IE 6 but there are features you simply can’t get in that browser so we degrade reasonably well there. For something like Dojo 2, we’re really saying, “Yeah, this isn’t going to work in IE 6, 7, or 8.” It’s kind of fundamental. There are features that you simply don’t get in that browser that we need to build a toolkit for tomorrow. Otherwise, you’ll basically run into a bunch of new toolkits that don’t worry about those browsers that can do all these amazing things that you simply can’t do. That’s the point at which you say, “Look, we can’t continue to support this anymore,” is when it’s just inhibiting your ability to get anything done. For example, supporting all of the ugly CSS issues with 6, 7, and 8 are just not fun. If you look at this underlying structure of some of the widgets, you’re like, “What is this mess?” It’s because it’s the only way to get that particular widget to work in 6 or 7. We don’t want to do that anymore. Pretty much, 9 and newer, at least we have a better baseline starting point. If you look at jQuery, they’ve basically said, “The biggest disappointment is we still have to support old Android.” They still have a whole bunch of hacks for old Android browsers in their codebase. AJ:  If I remember correctly, jQuery 2.0 dropped support for the old Internet Explorer and for some functionality, they have a jQuery.backwardscompat or something like that. DYLAN:  Yeah. It sort of warns you of the features that you need to add. They’re doing an interesting thing, which is like you can use jQuery 1.10 or jQuery 2.1 and they match feature-wise. But I don’t think we’ll go that route because I don’t think it’s necessarily worth the effort. I think people that are on the 1.x code line aren’t going to want to make the jump until they’re ready. So, what we’ll do instead is just continue to maintain them differently. If you have to support older browsers, use the older APIs. If you’re ready to drop 6, 7, and 8, you use the newer work. It really fundamentally comes down to a few things in JavaScript and CSS that you simply can’t shim easily without introducing a lot of cruft throughout your API. We’re ready to move on. AJ:  So, I noticed that I feel like jQuery dropping support for Internet Explorer old crappy browser and using strict mode is really kind of paving and brightening the way for other toolkits and frameworks. Do you feel like your decision to finally move forward with Dojo was at all influenced by that broad opening? DYLAN:  It made it easy to convince people that doubted it was the right time because you have people who say, “Oh, we can’t drop IE 8. Everyone uses it.” And then, the same people will say, “Everyone uses jQuery.” So we can say, “You’re not really making a lot of sense here.” So, it’s certainly a data point that helps us believe that it is the right time. We did notice there is some backlash against their approach. People don’t read long enough to see, “Oh, I can continue to use 1.10 and it will still work.” Basically, you have to inform users and make it easy for them to understand the differences and why they would do that. But I do think waiting another year for us is a good thing because it coincides with that end-of-life for enterprises. AJ:  And the enterprise customers, yeah. DYLAN:  And because we have so many enterprise users, it makes sense for our group. CHUCK:  I really like the model of maintaining the old version and moving ahead with the new version, at least for a certain period of time because then, people can start preparing to make the transition. DYLAN:  Yeah, we have users who are just now upgrading from 1.0. CHUCK:   Wow! DYLAN:  So, they’ve been using that since 2007. They’re just now saying, “Oh, you know this 1.7 or 1.8 looks nice.” [Chuckles] It’s like, “Where have you been the past six years?” It’s honestly quite easier to sort of upgrade each release a little bit at a time rather than to say, “I haven’t touched this codebase in six years. I’m ready to change it.” But enterprises work differently than most of us who prefer the public-facing web. That’s our world. [Chuckles]**AJ:  So, are you guys going to follow suit and start using strict mode as well or are you guys still holding off on that? DYLAN:  The reason we haven’t used strict mode to date is because we have this module called dojo.declare and what it does is it allows you to sort of basically define superclasses, define mixins that are going to be combined into a class and then call up the inheritance chain using a this.inherited call. That breaks strict mode. So, we have some ways around that that we figure we’ll implement for 2.0. But to be honest, strict mode isn’t the most exciting thing to us. When we do run tests and compare the performance gains by stripping out features that you wouldn’t use in strict mode, it doesn’t save us a lot more than just using the normal closure compiler. Maybe it shaves a couple more percent off the size of our codebase. It’s not as big of a gain as we expected so it hasn’t been as high of a priority for us. I know why people like it, of course. Basically, the normal closure compiler gives us 90% of the gains we normally get and strict mode just adds a little bit more on top. So, it hasn’t been as high of a priority. AJ:  Okay. A lot of the other frameworks are starting to support Node so that it can use the DOM library that’s in Node. Are you guys doing any testing with that or are you just focusing on browsers? DYLAN:  Dojo has worked inside of Node for a couple of releases now. In 1.8, it was a little strange because basically, you would pull in Dojo and then to pull in Node, you would actually reference it through an AMD plugin back to Node, whereas 1.9 introduces sort of a more natural approach for working with Node inside of Dojo. But the biggest complaint people have is, “Well, I’m used to CommonJS. Why do I want to use this AMD thing?” And there’s a lot of debate around, “Should we move to UMD,” which to me is, “Okay, yet another hack on top of modules,” which is like another line of this really terse boiler plate that you insert inside of every file. Do you want to impose that on every single module that’s created or do you want to use a build step to add that for people? AJ:  And personally, for that, I just wish that Node would add the define syntax native. I don’t see where one is actually a clear win over the other. I think CommonJS, RequireJS really can do the same work. DYLAN: Exactly. And actually, there was a one month stretch where it was inside of Node and then it was removed. This was back in 0.4 or 0.2, sometime pretty early in the project. For example, Dojo provides a module that just adds that right into Node and then, you can use the require and define syntax that you’re used to with AMD which we like a lot, of course. You can run Node on Dojo, inside of Node, as you would, and things work pretty nicely. For example, we refactored our XHR module and it’s now called dojo/request in 1.8. Basically, when you require dojo/request, if you require it in a browser, you get XHR by default. If you require it inside of Node, you get just a normal HTTP request object. There are a lot of clever things inside of Dojo that work well that way that weren’t there before. JAMISON:  So, can I ask a little bit more about the Dojo Foundation? That seemed really interesting to me. I’ve heard of it, but I wasn’t super informed about it. So, how do projects get in there? Is it only things that spin out internally from Dojo or do you adopt external things kind of like Apache does sometime? DYLAN:  When we started the Dojo Foundation, we looked at Apache and we saw a lot of process and we said, “We don’t really want to become an incubated project.” So, we talked to the Python Software Foundation and the Eclipse Software Foundation and they said, “You know, it’s not that hard to set up a foundation.” And really, it wasn’t. But we wanted one that was incredibly focused on code, t-shirts, and servers, and keeping coop on illegal trouble and nothing else. So, it’s a very minimalistic foundation. We have a board, but we never meet. We occasionally send Emails. The process for approving projects is basically someone writes up a proposal, sends it to me and I give them feedback on it. It gets sent out to the list of all committers across all projects, everyone votes +1 or -1, and after two days it’s either in or they’re told to go back and refine their proposal if it got so many no votes. Then from there, a project pretty much just has to basically say, “I’m going to run this project in what Dion Almaer coined as a 100-point open source project, which means that basically, you run the project in the open, the decisions are made in the open, one single vendor doesn’t control the project, you abide by a license such as the BSD license or Apache license or MIT license, and you do your work in the open. That’s pretty much it. And so, we have a collection of projects like RequireJS and the Dojo Toolkit and the Jetty CometD implementation for server-side real-time web sockets and stuff. And then we have projects like lodash which is done by John-David Dalton that’s basically a rewrite of Underscore. Or we have animation projects. AJ:  Can I just say real quick? DYLAN:  Go ahead. AJ: **I love his terrible attitude. He is hilarious. I just love how anytime there’s an issue on Underscore, he fixes it in lodash first, and then post back an issue request and just crazy stuff like that. He’s a total jerk, but he’s so freaking awesome about it. [Chuckles]**DYLAN:  Yeah. He kind of walks this fine line between complete asshole and completely funny. It kind of depends where you’re sitting in that particular day, whether you find it funny or asshole-ish. But he’s very focused and passionate about what he believes and pushes it forward. He, alone, has pushed Underscore in a way that most projects don’t get that benefit from their critics. Most critics will just go and do something else. But he’s basically said, “Yeah, I’m going to do it better but I’m also going to help make you better.” That’s pretty cool and pretty rare. We released a few weeks ago, a new project called The Intern, which is a new testing tool that we can talk about in a bit. He basically posted some very arcane pull requests that frankly no one is ever going to run into these problems. But he’s right. They are bugs. But it’s sort of like if you’re dealing with 50,000 things, it’s probably not the three things that you would care to touch first. But he cares enough about certain things that he’ll do that. And that’s pretty cool and yet, can be frustrating at the same time. you’re like, “I want to focus on adding this shiny new thing,” not making sure that IE 6 testing works properly with The Intern, that sort of thing. Good stuff. So, Dojo Foundation is basically projects that have been voted in, in that manner. Beyond that, once you’re a project, you’re kind of on your own. We’ll offer support and help. If community issues come up, you’re kind of just left to your own devices. There’s really not a lot of governance other than giving people feedback when they ask questions and stuff. CHUCK:  Yeah, it makes sense. JAMISON:  Sounds cool. CHUCK:  So, going back to the toolkit for a minute. Is it pretty easy to test if I put it into my stuff? DYLAN: **Yeah. Dojo itself includes a testing framework called D.O.H., which is a completely contrived acronym for the sound Homer Simpson makes when things fail. D’oh, that sort of thing. In fact, there is actually an optional module where you can turn on and off sounds ‘”D’oh” and “Woohoo”, which is cute. [Laughter]**DYLAN:   But the same time, this tool was not actively maintained in a meaningful way for several years and many new testing tools have come out. One of the first things we said for Dojo 2 was, “Hey, okay great. We’ve got these 15,000 or 20,000 tests or maybe more inside of all of Dojo.” But we need a better tool that supports things like continuous integration and different styles for writing assertions and code coverage analysis and being able to test against the cloud and hooking into Travis CI. So, we wrote a new project called The Intern which uses Dojo for some basic features but works with any JavaScript tool. What’s cool is basically, each test suite is just an AMD module. So, you write these AMD modules that define your tests, your startup methods. You can write unit tests or you can write functional tests using the WebDriver wire protocol and all those good things. And then, you can run your tests in the browser, you can run them in command line against Node, or you can run them against Sauce Labs or any Selenium grid in the Cloud. And then, it just has a bunch of nice pluggable things. If you don’t like our assertion syntax, we chose to use the one from a project called Chai. You can write a little adapter to plug in the syntax that you like. Or if you don’t like the code coverage analysis tool and you find something else you like, just plug that out and plug something new in. Or if you don’t want to test against Sauce Labs but you want to test against some other service that’s come out, you just unplug that part of the module and plug something in its place. It’s really cool and really handy. It’s definitely what we’re replacing D.O.H. with. it’s like we have a tool today and we have a tool for tomorrow that’s usable with Dojo 1.8 as well as anything going forward, as well as people have written test examples using Backbone and using jQuery and using other projects. We’ve been getting random pull requests and patches from really cool people like the founder of Lifehacker. She submitted a patch one weekend. It was for a typo in the documentation, but it’s just cool to see people that you have no idea that they care and suddenly, they’re submitting pull requests on the weekend. It’s pretty neat. CHUCK:  Nice. So, the other question I have for you is regarding, you talked about vector graphics a little bit ago, and usually there are two things that I see vector graphics used for. One is for cool-looking animation, some kind of game or just something cool to look at. And then other thing I’ve seen it used for is charting or graphing. What support do you have for awesome art and what support do you have for charting and graphing? DYLAN:  Charting and graphing’s the easier one. We’ve had DojoX charting since 2005 or 2006. It’s a rich charting API. It supports financial graphs. It supports your standard 20 or 30 plot types. It supports themes. It supports multiple axes, multiple plots layered on top of each other. But the coolest feature is that it’s backed by the same object store API. You can basically say, “Hey, I’ve got this object store that provides all my data.” I’m binding it to my chart, to my form, and to my grid. And I make a change in the form and it updates the value in the chart updates the values in the grid. So, you have this convenient way to synchronize different views of the same data concisely. Then there’s the project that SitePen’s been working on called voro.com. It is basically a hosted Cloud version of financial charting built on top of Dojo’s charting API. Basically, for customers that don’t want to bother to figure out how to do charts, but they’re looking to move from Flex or Silverlight charts to web-based charts. It’s kind of the last thing holding financial institutions back completely from moving away from proprietary technology is a solid robust charting implementation. So, we’ve been working on that as well. And then lower level, we have a vector graphics API and it’s called GFX, for graphics. It supports 2D and 3D effects, animations, visualizations. It follows roughly the SVG semantics for shapes and lines and curves and drawing. You can draw bubbles or you can draw their classic tiger example and other animations. This is probably an area we’re not as good at marketing as D3 or Processing or the other one that I’m forgetting that’s also popular. CHUCK:  Raphael? DYLAN:  Yes. Raphael. Thank you. So, there are a lot of projects out there. We’ve been doing this quite a bit longer. We do have a wider feature set in terms of supporting more rendering engines than any of the other projects out there. But it’s competitive with those. It’s been around forever. The rewrite for 2.x will be to basically strip out some of those libraries that we don’t need anymore or technologies we don’t need anymore like VML, and add in WebGL. Basically, it’d be nice to be able to say, “Look, I’ve got one API to write vector graphics whether it’s Canvas, SVG, or WebGL.” CHUCK:  Nice. JAMISON:  It sounds really cool. CHUCK:  Yeah. DYLAN:  Then on top of that, there are implementations like gauges and other visualizations that people use in dashboards. IBM Portal ships with Dojo. So, anything you can imagine sticking into a portlet, they’ve wanted to be able to do with Dojo. Or there’s a DojoX drawing API that lives on top of it that creates sort of like a Visio-style diagramming tool inside of the browser, on top of GFX. There are really a lot of different ways that people have taken it. Some of it’s a little crufty and some of it’s really awesome. But it’s all there to hack on and use if you want. CHUCK:  Awesome. Alright. Well, I think we’re just about out of time. We haven’t heard a whole lot from Joe. Joe, do you have any questions? JOE:  You guys keep asking my questions before I get a chance. No, no, no. I’m good. CHUCK: **So, we asked all eight of Joe’s questions, too. [Chuckles]JOE:  You know, I did want to talk a little bit about the history of Dojo and this whole thing with adding things to the prototype. I think that’s a really interesting conversation in history, especially for people that aren’t familiar with that. DYLAN:  Sure. So, Dojo and PrototypeJS kind of became popular at the same time. Prototype extended native objects and we refused to do that. So, it kind of informed the decisions that were made. When jQuery came out, they kind of followed our way. When MooTools came out, they kind of followed the Prototype way. But everyone has pretty much moved away from extending the native prototypes. You just don’t know how your projects are going to be used. You don’t know how people are going to do it, how they’re going to mix with other things. Even though it can create a cleaner API, it’s just not generally safe. But at the same time, in some cases, it can create really nice, clean, elegant API structures. But you always run into a problem with them that you don’t expect. JOE:  Yeah. There’s a really cool feature in the C# language where you can extend a class as interface but only within a given scope. DYLAN:   Right. JOE:   That’s something that would be fantastic in JavaScript. But it was just very interesting, the directions that the different tools took and which tools back then, back when I think this is all on BBSs back nine years ago, right? DYLAN:  Oh yeah, absolutely. JOE:  [Chuckles]**DYLAN:  Awesome. CHUCK:  Alright. Well, let’s go ahead and get into the picks then. AJ, you want to start us off? AJ:  First off, I have to say that I am a ‘femininist’, which is not much like a feminist. So, my personal belief is that the differences between men and women should be celebrated and that women should be treated with respect and dignity, but not that they should be treated not like men, not that they should be expected to be like men or behave like men or perform like men. It really, really bugs me when it’s women putting down other women for doing so-called traditional roles. Well, traditional roles like homemaking, taking care of kids, being a nurturer. So, this week, I ran across two things that were just kind of interesting for me to think about. One was actually really gratifying. It was this woman, has a blog article about Grand Theft Auto and how she’s incredibly outraged that you can rape prostitutes in the game. That’s a feature of the game. I completely agree and I wonder where are all the other women that should be supporting that and making an outcry against that kind of thing being published by a company. And then, another one was I watched My Fair Lady, which is this old Audrey Hepburn 1964 movie. It was just kind of eye-opening to look at just the way that, it was kind of a progressive movie, I would imagine. I didn’t live in the 60’s. But it seemed like it was kind of poking at the issue of equality, just the way that the characters are portrayed. It just kind of made me think. I wouldn’t say that I necessarily liked it in the end. I don’t feel like there was enough progression. There wasn’t enough character growth. DYLAN:  Well, My Fair Lady is based on Pygmalion, which is a famous play from 50 or 60 years before that. It was exactly about inequality, not just gender but also class inequality that was really common in England at the time, like, “Sniff it,” or like looking down at the caste system that was in place. In many ways, there was like that Eddie Murphy movie ‘Trading Places’ that you could think of as the modern day reinterpretation of that in an alternate way, where Eddie Murphy is swapped with a broker and he’s a bum. They swap them. These two brokers have a bet that they can basically turn Eddie Murphy into this successful stockbroker and that it doesn’t really take much at all. They bet a dollar on his life, that they could do that. It’s one of those recurring themes. I posted a comment in the chat that was like, “This is like the debate between == and ===.” Equality doesn’t mean identity and that’s my belief on your original point. We’re not all equal, but we should be equally respectful and appreciative of people and their choices they want to make. That’s what a free society is really about is choice and respect. AJ:  Agreed. DYLAN: **That’s my attempt to take it from a scary area back to not getting Email complaints about the talk. [Laughter]JAMISON:  That == versus === thing, that was deep, man. I’m still thinking about that. That was great. CHUCK:  Yeah. DYLAN:  Thanks. CHUCK:  But it was very well put. Depending on what you believe, different lifestyles fit well or don’t fit well. You be respectful of what other people believe and think and want to do. DYLAN :  If people will just worry more about themselves than what everyone else is doing, they’d be a lot happier. JOE:  One, they don’t think that semicolons are optional. [Laughter]**DYLAN:   Right, because that would just be ridiculous. AJ:   Agreed. DYLAN:  Yes. That would just break your build all the time. CHUCK:  I can’t count on someone else to take care of that for me? DYLAN:  No. no. CHUCK: **Alright. [Chuckles] Jamison, what are your picks?JAMISON:  I have two. They’re less controversial. CHUCK: [Chuckles] Thank you.**JAMISON:  Well, less political. Let’s put it that way. One is an amazing movie called Moon. It came out in 2009, just saw it recently. It’s great. It’s a hard sci-fi movie that asks some interesting questions related to what we talked about, about identity and equality. It was done on a really low budget. So, it’s not like huge special effects, crazy action. But there are lots of things in it that made me think. So, it was great. One of the best movies I’ve seen in a long time. The other one is a band called Dr. Dog. I heard about them from somebody on Twitter. They’re like, if the Beatles and Johnny Cash were alive today, old country pop style but a little more modern. Not like that, I don’t know, plastic pop country that’s on the radio right now. But it’s great stuff. So, those are my picks. CHUCK:  Awesome. Joe, what are your picks? JAMISON: **Apologies if anyone liked plastic pop country. [Laughter]**DYLAN: **That’s not a real apology. [Laughter]**CHUCK:  That’s one of those, “I’m sorry you didn’t like that.” JAMISON:  I’m sorry you’re offended that I told you your music was awful. CHUCK:  Alright. Joe, what are your picks? JOE:  Alright. So, this week’s been an awesome week for iPad gaming. There are two games dropping this week for the iPad that are just going to be sweet. Warhammer Quest, which is out already. That’s a remake of a board game and apparently, they did a really good job adapting it for the iPad. Then the other one is Knights of the Old Republic 1 is coming out on the iPad, which everybody should be rejoicing, clapping, possibly crying as they hear this news that it’s coming out on the iPad. CHUCK:  I just muted a girlish squeal. JOE:  Good. Good to hear. Yes. So, I’m going to pick those two games. On top of that, I’m going to pick the book Ruins, which is the second novel in a series by Orson Scott Card whose fantastic novel Ender’s Game is coming out in movie form later on this year. Very excited for that. It’s the Pathfinder Series. Book 2 is out. It’s a great book, great novel. It’s very similar in spirit to Ender’s Game or Harry Potter, younger protagonist, but very interesting mix of sci-fi and fantasy. Really a great novel. Then the other thing, I picked this last week. I’m not really picking it so much as just making a note. My Pluralsight Course on AngularJS Fundamentals is number two out of 500 courses on Pluralsight, which I think speaks a lot more about the popularity of Angular than about necessarily anything about me. I don’t think people are watching it just because it was me, because nobody knows me except for you guys, and not very well. We never get together. What’s wrong with us? CHUCK:  Yeah. We should get together. JOE:  Yeah. Anyway, I just think it’s really interesting that it’s been the number two most popular course on Pluralsight for quite a while out of 500 different courses. It’s been the second most popular course, which I think is very cool and speaks a lot about Angular. So, that’s my picks. CHUCK:  Awesome. Alright, I’ll go ahead and go next with my picks. My first pick is an iPhone app that I’ve been using for the last week or so. I really, really like it. Of course, I say that whenever I talk about an iPhone app. This one’s called Commit. Basically, what it is, is it’s a way of tracking whether or not you did something that day. Anyway, basically the idea is you put in what you want to have done each day. The things in mine are work out every day, take my morning medication every day, not drink that caffeine every day, and take my evening medication every day. So then, you get in the habit of doing it. The thing that’s awesome about it is you check it off each day. On take morning meds, it’s seven days in a row that I’ve been doing it. Not drinking caffeine, I had three days in a row and then last night I forgot I was trying to not drink caffeine and I had some Diet Pepsi. But anyway, it gets you some momentum and then you just don’t want to break the streak. DYLAN:  So, you’re kind of gamifying your life. CHUCK: **Yeah, a little bit. But this is the only thing that’s worked so far for some of this stuff. [Laughter]**DYLAN:  That’s nice. That’s cool. CHUCK:  Anyway, my feeling is that these things, since they’re important, if I can make them a priority and gamify it like that, it’s really awesome. As long as it keeps working, I’ll keep using the app. I really did hate breaking that streak yesterday. So, I think it’s going to work just fine. I’m kind of adding new things to it every few days because there are a few other things that I have as goals to do every day that I don’t do unless I have it in here. Anyway, it’s awesome. I learned about it from a book called Authority, which is also by the same guy that made it. Authority is his book on marketing eBooks. If you have any product, really, that’s any kind of digital product, Authority is a great book. It’s by Nathan Barry. You can find all his stuff at NathanBarry.com. I’ll put a link in the show notes. Dylan, what are your picks? DYLAN: **I had a pile of them. Let’s see. Of course, The Intern, the testing tool I was talking about that you should check out. Because we were talking so much about AMD and you guys are talking about games, there’s a module called FrozenJS that if you’re interested in building 2D web games, you should check out. In college, I was a hammer thrower and the world record holder is Youri Sedykh and you have to watch this video of him throwing. It’s just the most ridiculous, cool thing ever. He throws it, I don’t know over how many meters, but it’s like almost 300ft. He’s the world record holder. This is from 1980’s. He’s a Russian. He’s on a lot of steroids. It’s really cool. [Laughter]**DYLAN:   One of the things that you’d mentioned in the Email was basically saying, “What are some of the things you do that makes your life easier?” I do a lot of Kundalini yoga and meditation. I learned that from my now wife. Basically, it’s a type of yoga that is not just about how bendy you are or how well you can stretch, but it combines mind, body, and breathing. It gives you a life hack for anything. If you’re feeling tired, they say there’s a kriya for that. Or if you’re feeling sore, there’s a way to get around that. Or if you’re feeling depressed, which isn’t something I’ve really had a problem with, but if you are, there’s a kriya for that. This guy who invented these thousands of yoga sets and taught them around the US from 1970 until about 2006 when he passed away. It’s just really powerful stuff. It’s also the first kind of meditation I’ve ever done where I’m actually able to do it. A lot of it is chanting-driven meditation rather than sitting there with your mind blank for 20 minutes, which just puts me to sleep. Arcosanti is this cool place in Arizona. We got married there. It was also the place we had our first date. What’s cool about it is it’s this place that’s an Arcology that was built by this architect who’s Italian. He wanted to come up with a community that could be self-sustaining and very environmentally-friendly. This has got these really cool architectural settings. What was really fascinating is he passed away the week we got married, so it was just a really powerful experience for us. Then we went on our honeymoon in Bali, with a layover on the way back in Seoul. Seoul is a very underrated place. It’s got a really cool art district called Insadong and it’s well worth a couple of days spending there. Then Bali is like Hawaii meets Thailand. It’s just a really cool awesome place to spend a few weeks and get away from it all and disconnect, yet still be connected enough that you can get really nice food and spend time on the beach or go hiking in the mountains, or go water rafting or snorkeling or scuba diving or all those good things. Those are my picks for the past month or week or whenever. CHUCK:  Awesome. Those are awesome picks. JOE :  Yeah. JAMISON:   I think I’m like, “They would make my life better.” I think you accomplished that goal. DYLAN: **Awesome. Thanks. And of course, Dojo would help with that, too, if you [inaudible]. [Laughter]**CHUCK: ** Good. Okay. Other than that, we’ll wrap this show up. We’ll catch you all next week.

Sign up for the Newsletter

Join our newsletter and get updates in your inbox. We won’t spam you and we respect your privacy.