The panelists discuss jQuery vs KendoUI with Burke Holland and TJ VanToll.

Special Guests: Burke Holland and TJ VanToll.

 

  Hey everybody and welcome to episode 116 of the JavaScript Jabber Show. This week on our panel, we have Jamison Dance.

  Hello friends.

  Joe Eames.

  Hey there.

  Aaron Frost.

  Hello.

  I’m Charles Max Wood from DevChat.TV. And this week we have two guests. TJ VanToll.

  Hello.

  And Burke Holland.

  Howdy. 

  Do you guys want to introduce yourselves?

  My name is Burke Holland. I live in Nashville, Tennessee and I work for Telerik as a developer advocate focusing on Kendo UI.

  And I’m TJ VanToll. I’m from Lansing, Michigan. I work with Burke. I’m also a developer advocate for Telerik. In addition to that, I’m also a member of the jQuery team. And they focus mostly on jQuery UI. I’ve been doing that for a few years now. 

  So, you guys work together. That’s pretty cool. We were hoping that this was a Sharks versus Jets. Right, Jamison?

  Yeah. 

  Yeah.

  I thought there was going to be some rap battles about which UI framework is better or something. 

  It’s kind of a letdown. I wanted to see some fights.

  We could still probably do the rap battle if you’re interested. 

  Yes, rap battle. Please. [Chuckles]

  Well, cool. Well, since it’s jQuery UI versus Kendo…

  We should probably get a definition of what each of those are first and how they’re different.

  So, what’s the diff between those two, guys?

  Sure. I’ll handle [jQuery] UI.

  Alright. So, Kendo UI is a UI framework. It’s built in JavaScript and it’s all of the standard components that you would expect to find in a UI framework like sliders and tabs and things like that. And then it also contains a mobile framework for building mobile apps. Not per se responsive apps, but mobile apps specifically, like jQuery UI Mobile or Ionic framework. And then it has a data visualization suite as well, some charts and graphs. And I should note that Kendo UI actually comes in two flavors. So, there’s a commercial version which contains some of these crazy widgets like the scheduler which is the calendar portion of the app just in your web browser. And then there’s the core framework, which is a ton of the UI widgets from the web side and then all of the mobile widgets as well. 

  You say it’s a framework. Does it have a routing solution and a localization solution and all that stuff involved, too?

  Yeah, that’s a great question. It does. So, it’s a full frontend stack, if you will. It has routing, views, layouts, the whole [inaudible] framework. It has validation, globalization, all of the things that you would need to build a real frontend application, not just UI components. 

  Awesome. That’s cool. 

  Yeah. And then to contrast that, jQuery UI is one subset of what Kendo UI does. And the majority of jQuery UI is just a series of widgets. There are 12 widgets in the library right now. So, things you think of like autocomplete, dialog, menus, tabs, things like that. And then there are some other utilities in the library as well, like a series of effects. There’s the widget factory which is used to build all the jQuery UI widgets. But I think when people think of jQuery UI they are primarily thinking of those core set of widgets. 

  It seems like some of these components in Kendo and in jQuery UI have a lot to do with the backend. With autocomplete, you need to talk to a server to grab the stuff to complete it with. And that scheduling widget you were talking about, that seems like that’s pretty heavily tied to your data model. How opinionated are these widgets on what the data looks like and how it gets it from the server?

  In the case of Kendo UI, there’s a data abstraction that you generally call the data source. And what it is, is it’s an abstraction around, it’s the $.ajax at the very bottom, right? If you follow the turtles all the way down. What it does is it allows you to define what your endpoint is. And then it allows you to specify the structure or model of your data, because yeah, things like the scheduler, they are very opinionated on the way that they need the data. And so, Kendo UI provides you a way to either send it from the server in that form or once you get it with the data source then you can transform it so that it looks right for presentation. 

  Yeah. I think actually, the autocomplete is a nice widget to talk about the difference between the two libraries, because whereas Kendo UI gives you this data source, this tooling to interact with your backend, jQuery UI really isn’t that opinionated in that sense. The autocomplete widget for jQuery UI has a source option and you can configure to do any number of things that talk to your backend. But jQuery UI doesn’t go as far as providing any sort of backend for you whatsoever. We’ll show you, say sample code of how you could implement it and how we’ll format requests for you. But for the most part, we’re hands off, trying to stick with just the core autocomplete functionality and leave the backend up to you. 

  So, they both have ways to hook into whatever backend you’re using, it sounds like. 

  Yeah. I think that in the case of Kendo UI, while you can always use a straight jQuery APEX call to get your data and then put it into your widget. The data source abstraction is, the idea there is that it provides that layer for you so that you just give it an endpoint and then the data source knows how to talk to the widget. And once it gets the data, you don’t have to do anything after that. Whereas, and TJ could speak more to this, in my experience the jQuery UI, they leave that up to you. TJ, are there actually abstractions for jQuery UI that do that on the data side?

  Not really. Basically, what the autocomplete widget will do is it will just formulate up and Ajax request. So, you’ll hit the same $.ajax API for you. But Kendo UI will go even a step further. Kendo UI actually has server-side wrappers, so code that you can actually put in your Java codebase, your .NET codebase, in your PHP codebase, that will interact even directly with your database. Whereas jQuery UI really tries to stay hands off with that and just format up a request for you. And that’s about it.

  Cool. So, I’d like to get you guys into talking about the strengths of your projects. So, we’ve had I’d say a good number of framework people on recently. And they tell us, “This is when you would use our framework.” So, when you guys are out hitting the pavement, talking to people about, “Use our stuff,” what’s the strength? When you say you should use Kendo and jQuery UI, what’s the scenario? What are your strengths?

  I can start with jQuery UI and then I can let Burke talk about Kendo UI a little more. I think jQuery UI makes a lot of sense, or its best use case is when you just need a couple or handful of widgets. So, you’re developing a site and you need an autocomplete widget. And you need an autocomplete widget that you don’t have to think about what browsers it’s going to work in. You don’t have to worry about that autocomplete being accessible. You just want something that you can drop in, has a nice clean API that you can work with. 

The jQuery UI comes packaged with a number of themes. But even the default theme is this grayish hue. And that was even specifically designed so that you could drop it into any design. So, if you have a website that’s bright red, orange, whatever, you can just drop it in and get an autocomplete that just works. And even though jQuery UI does more than that, there’s a series of widgets that they work really well together, I think jQuery works best in that use case that you just need these handful of widgets that you can drop in and just work out of the box.

  Okay. If I’m doing a Backbone app or another framework app, I would use jQuery UI inside of that. Is that what you’re saying?

  Yeah.

  Okay. 

  Kendo UI actually has a full MVVM data binding solution. But jQuery UI doesn’t have anything like that. And I think both of these libraries complement those MVC libraries very well. So, if you’re using Backbone, Ember, or [inaudible], none of those projects ship you widgets you can use. They’re not giving you the dialogs, menus, things like that. So, chances are you have to roll some of that behavior yourself, assuming you want to use it in the app. And these libraries just give you a straight out of the box thing that you can drop in and know that it’s going to work, know that it’s going to be accessible, and things like that.

  Cool. 

  So, to speak from the Kendo UI side, historically speaking Kendo UI hasn’t always been a fully open source project like jQuery UI has always been. So, in the beginning, there was a GPL License for Kendo UI which is a copyleft. And it’s pretty restrictive. So, we actually created a site. I think it’s, yeah, jQuery UI vs. Kendo UI.com where we try to compare the two, because that was the question people were asking, is why would I use a commercial framework when there’s an open source framework? Now fortunately, we’ve been able to open source under Apache2 which is extremely permissive, a ton of the widgets. So right now, there’s strong overlap between Kendo UI and jQuery UI. 

But Kendo UI was really always designed for people who maybe got started with jQuery UI and got to a point where they were like, “I need some pretty wild functionality in this app,” right? Like, “I need a tree view with drag and drop and I can’t code it myself,” and so to be able to extend beyond that and provide some of these crazy widgets. The other thing that Kendo UI tries to do is it really focuses on being compatible all the way back to IE7 still. So, there’s a lot of polyfilling and fallback that happens under the covers in Kendo UI. TJ can talk more about what they do in jQuery UI as I’m not familiar. But that was always the goal of the project, was to really allow, when HTML 5 was the buzzword and we would say it’s ‘HTML 5 for everyone’, so give everybody these really nice animations and take care of all of the nasty plumbing that goes under the covers with polyfills. 

  Yeah. And just to chime in with jQuery UI, it’s the same thing with jQuery UI on a lesser scope just because jQuery UI does less. But jQuery UI, we actually just dropped IE7, just with the most recent release. So, we still work back to IE8 and we have a version that supports IE7. But we still go back, I think further back support-wise than a lot of projects do.

  So, when you guys dumped IE7, this is just me being curious and I have a mic so I’m going to ask, did you guys, were you able to delete a lot of code? How did that affect your overall performance and what were all the things you were able to do when you jettisoned that support?

  There’s actually not a ton of stuff in the library. There’s a series of [inaudible] but we’re talking about a small percentage of the codebase. Most of the IE7 problems were actually with CSS because IE7 was the last IE with the hasLayout craziness in CSS world. And so, there were some ugly hacks to work around that. And we had some really cryptic IE7 bugs that were actually, it’s a couple that we weren’t even actually able to solve. And that was the majority of what went away.

There are very few, just a handful of fixes that were actually in the JavaScript for IE7.

  TJ, just out of curiosity, what do you think, what about if they dropped IE8. Would that make a significant dent in the codebase?

  It would mean that we would be able to switch to jQuery 2.0, which would just by its very nature mean we could drop some code by just bumping that version up. But I think it’s the same thing. There’s a handful of fixes, but we’re not talking some drastic thing where we work around all of this, because building on top of jQuery, jQuery actually takes most of those concerns away from jQuery UI. But just switching to 2.0 would mean dropping, I don’t know. I don’t remember the exact numbers. But it’s like 5K of gzipped JavaScript, which is a good chunk.

  Yeah.

  Wait a second. I’m not sure if you guys have heard this, but Internet Explorer’s evergreen now.

  Yes.

  Whatever. 

  Problem solved.

  You can say that, but… people could trot that line out but there are still plenty of people that’ll be on IE7 or IE8 forever. 

  So, I know…

  Yeah, but it’s a bit…

  I’ve got a question about the browser compatibility. I heard someone say at some point, and this may have been an exaggeration, that they were having to do more code for differences between Safari, Chrome, and Firefox, than for the newer versions of IE. Is that true?

  Well, I can tell you that the biggest source of workaround in the jQuery codebase right now is for Android 2.3.

  [Chuckles] Yeah.

  And that’s actually the thing. And because Android 2.3 is still distributed on a whole lot of devices, it can’t really leave jQuery core. They’re selling new phones with Android 2.3 on it.

  Oh, you can buy new with 2.3 ones?

  Yes.

  Yeah, cheap ones like free ones, right?

  Yeah, exactly.

  Like the [inaudible] smartphones?

  But the cutoff for jQuery 2.0 was going to be ECMAScript 5 support. Basically if you have it, if you have ECMAScript 5 you would be supported by jQuery 2.0. But Android 2.3 actually doesn’t. So, we had to make an exception for that. 

  [Chuckles] That’s interesting.

  So, is Android 2.3 the new Internet Explorer?

  Totally.

  Yes. It’s the new IE 6. 

  Yeah.

  [Chuckles]

  Yeah. You know, I was actually, I took one of the kids to scout camp this last week and on the way we stopped at a Dollar General to pick up some beef jerky and stuff , because you can’t camp without beef jerky.

  Totally, yeah.

  Yeah. And then we were walking past the end of this aisle and there was, in Dollar General, there’s this huge wrap of feature phones essentially, but they’re all running Android and it’s all 2.3.

And there are nine of them that you could choose from. 

  Wow.

  So, this is still a major, major problem.

  Dude, I buy all my phones at the General gas station. So, don’t talk trash. [Chuckles]

  Part of the problem, Aaron. 

  I know. I’m sorry.

  When you need beef jerky and a phone real quick.

  For those times, right? [Chuckles]

  Absolutely, man. And sometimes, you’re just in a hurry and you need a cellphone that nobody can track and a bag of beef jerky, and you’re out.

  That’s true. That’s the survivalist combination. 

  A cellphone that you can side-load all of your nefarious apps onto for your throwaway purposes.

  Yeah.

  So, with some of the other framework folks we’ve talked to, when you talk to them about their framework they’re in love with it and they could talk about it all day. But they don’t actually use it. They don’t write apps with it. So, do you two write apps with jQuery UI and with Kendo? Or are you guys evangelists that don’t write app with it?

  They have to say yes now. [Chuckles]

  No, no. I want them to be honest. This is the podcast where we get to talk about a lot of stuff. So, yeah.

  Let me start this one. I’ll be completely transparent. I use Kendo UI because I know it very well and I’m comfortable with it. Kendo UI also has Angular integrations that I talk about a lot. I do not use Angular. And this is me just being forthright. I’m a big proponent of letting people use what they want. So, while I like to use Kendo in just its raw flavor because that’s what I know so I’m comfortable with it, even though I talk about Angular a lot, I don’t actually use Angular. 

  Okay.

  Yeah, and I can say that the nature of our job, we work as developer advocates which means I don’t work on any production applications anymore so I don’t write a whole lot of stuff that the public world sees. I make a lot of demos and such. And I do use both jQuery UI and Kendo UI in the demos and the stuff that I produce. But I’m not really out building big software apps anymore. So, while I could tell you I would probably use these frameworks, I just don’t build that sort of thing currently.

  Cool. TJ, where do you get ideas for the next version of jQuery UI? Where do your guys’ ideas come from? What’s your best source of, “This is the next feature we’re going to put in”?

  It depends. So, things that the community wants from the project, things that we want to do internally. It all depends. I can tell you the next version of jQuery UI, we’re working on rewriting a couple of the existing widgets, the button widget and also the datepicker widget. The datepicker widget is actually an interesting story. It’s telling of the project as a whole, because jQuery UI started as this basically a quiet group of plugins that were from the community at large. Because when jQuery got big, there was this massive plugins that hit the market. You could still find plenty of Google posts of the top 100 jQuery plugins and such. And jQuery UI started as this goal of bringing together these plugins, giving them a common API, giving them a common way of working. And it’s something that the project has tried to bring some consistency to this plugin throughout its existence. 

And the last big holdout plugin is actually datepicker. Datepicker being, it hurt by its own success because it’s easily the most common widget in the library. We know from download statistics, people love the datepicker. People use it a lot. But from a maintenance standpoint, it’s also just crazy. It doesn’t use any of the conventions that the library has come up with recently. So, that’s the next things we’re working on, is bringing some sanity to datepicker and to make it more extensible and make some of the other widgets work together. And that’s one thing that we’re working on right now. So, some of it is internal organization. Some of it is community feedback, but it all depends.

  Okay.

  I know in the case of Kendo UI, since I serve as interim product manager for them for a while, that Kendo UI is a lot different than jQuery UI in that there are 22 people total that do nothing but work on Kendo UI. So, this includes support resources, people doing documentation, technical writing, and engineers. There is this very specific product roadmap. And the way that we get that is a lot of different ways, but it’s primarily feedback from the people that currently use Kendo UI. And then what we observe as being very popular in the community. 

And so, an example of this is the Kendo UI is used heavily by a lot of really large enterprises. And so, we will go out and talk to them and do actual interviews and say, “What are you looking for?” and 85% this last time around, “We’re standardizing on Angular. We need Kendo UI to just work with Angular.” And I don’t know if you guys have seen this phenomenon pop up as well. And so, at that point, whether or not we think Angular is a good thing is irrelevant when the customers and everybody is saying, “We’re doing this. Where does Kendo UI fall? We want to use your scheduler, but we can’t currently with Angular.”

  Right.

  And so, we then prioritize and we make it important. And we say, “We’re going to add Angular support in for Kendo UI,” which we’re going to add with this next release and officially support not just Kendo UI but also Angular. So that when people submit support tickets that include Angular code, we can support that as well.

  Gotcha.

  But that’s how we do our roadmaps and features. It’s really based on feedback from the community and from people that use Kendo UI.

  It sounds challenging.

  Yeah.

  It really is. It’s hard to really figure out what stuff is important and what the vocal minority is versus what the actual need is. And there are a lot of times where people are suggesting, somebody will suggest something really, really good and you’re like, “Oh man. I can’t believe I don’t have that.” But then you can’t find anybody else who has that problem. And so, you have a really hard time justifying putting it on the roadmap as something to do. 

  So, you touched on this just now when you talked about the Angular support. But it seems like Kendo UI and jQuery UI are different branches of the tree of life of JavaScript frameworks versus the Angular and Ember and the more traditional full app frameworks. So obviously, they’re trying to use Kendo UI together with Angular. Is this a trend that you see continuing or are people just sprinkling these into server side pages or something like that? Does that make sense?

  Yeah, it does. 

  Yeah.

  And I can say that from both jQuery UI and Kendo UI, that we absolutely do see that. I know from just working on jQuery UI that we get requests from people using any of those MVC* frameworks. So, your Backbones, your Embers, your Angulars, things like that. I think it’s a fairly common use case, just because like I mentioned earlier, these frameworks, Ember is really not about giving you datepickers or building calendars. It’s a slightly different focus. And so, from jQuery UI’s perspective, what we try to do is we don’t directly integrate with any of these frameworks directly. But what we do try to do is we try to make the integrations possible. So, that might mean structuring our code so that it’s easily extensible or so that you can bridge it, but not necessarily directly integrate with those frameworks.

  That makes sense. 

  Yeah. And Kendo UI on the other hand started out as just UI and then all of these other pieces were added in to allow it to be a complete framework. So, everything that Angular does, Kendo UI also does. However, it wasn’t until Angular came around that I saw people really starting to go whole [hog] on a frontend environment. Before that, it really was pretty much piecemeal. And so, that’s another one of the phenomena of Angular really, is that people now feel like they have a frame of reference in which to work entirely on the client side.

  Aww, that sucks. I wanted to hear some more of Jamison’s stuff. Joe, you got any questions?

  Yeah. So, earlier on you talked about some crazy components people turn to Kendo UI for. I was just curious to see what that list of really awesome crazy full-featured components might be that Kendo UI has.

  Yeah so, the most popular component in Kendo UI hands down, without a doubt, no questions asked, is the grid. And grids, we actually just wrote an article about this, grids are used by people to do things as simple as repeat data all the way up to your entire application is just a page with a grid. And I see that a lot and there’s nothing wrong with that. Grids are ubiquitous definitely, especially on the web side and in forms over data apps. And they’re really the fastest way to get an interface out to people. And plus, it’s an interface people already understand. They’re like, “That kind of looks like Excel. I know what that does.”

  Right.

  And then some of the other ones are the editor, which is like an ACE Editor, if you’re familiar with that. But it allows you to format and copy/paste from Word and do things like that. It formats the HTML. We talked about the scheduler. Another one is the tree view, which is a tree view but has drag and drop added in. The upload is quite popular. And then there are some crazy components in the DataViz suite. There’s a diagramming tool which is like Visio but in your browser. And then there’s, we just released a beta but there’s a Gantt chart now as well.

  Oh, really?

  Yeah. We’re talking about some pretty crazy interactive stuff happening in the browser, especially on the charting and diagramming side. And you can imagine how difficult that is to make that work back to IE7. In Chrome, everything’s all awesome. But when you talk about IE7, the stuff that you have to do to make things work in IE7 is just…

  Yeah, it sounds ridiculous. That’s awesome. 

  Crazy.

  Yeah.

  Yeah, especially the charting stuff, because the Kendo UI database, it’ll do Canvas. What are the other ones? It’ll do Canvas, SVG, but then it’ll also fall back to VML, which is this proprietary thing that IE dreamed up but actually serves as a decent fallback for that. 

  [Chuckles]

  Yes. So, crazily enough you can be using your pie charts, bar charts, all these charts, and they still work back in old IE because somehow they can be mapped to this proprietary language and still work. 

  So, you’re telling me, the sick people at your companies made some poor developer learn VML? [Laughter]

  Yes.

  I feel so sad for that developer.

  We should give props to [inaudible] because he did a lot of that stuff in the beginning. Him and one other dude were doing all of the VML stuff and SVG as well. VML was a total black box. You just throw it in and you’re like, “Please dear god, come out the other side working.” [Chuckles]

  Yeah. Wow. Well, your companies are sick but good job on that guy. Seriously, that’s awesome.

  Yeah. So, do you actually see a lot of customer implementations then, in the course of your work?

  Yeah, we do. We have a lot of customers that we talk to on a day-to-day basis. And I don’t if I should throw out any names. I will say FutureTax is online this year with a prominent tax site. You were using Kendo UI. [Chuckles]

  But a lot of times, you see it but you don’t know that’s what it is until you look under the covers because the developers have done a fantastic job of styling it so that it looks like their product and not like Kendo UI. I’m constantly blown away by what people can do with our widgets to customize it. So, they take the functionality but they go in and do some serious CSS hacking and it just looks gorgeous. It’s really impressive. 

  Alright. So, that makes me think I want to ask a couple of other things. So, first off, you were talking about the grid and people building their entire interfaces with grids. I imagine that in the course of your work then you’ve seen a few that just really made you shudder and a few that you just couldn’t believe that they could get that to work, make that work, and do it so well, right?

  [Chuckles] Right, absolutely man. The one that I see a lot is I’ll talk to somebody and they’ll say, “The grid is really slow.” And one of the things that we advertised, because it’s a commercial product, is that, “Hey, our grid’s fast.” And we have some perf benchmark tests that we do. And so, we’ll go in and look at it and we’ll say, “Okay. What are you doing?” and they’re like, “Well, I’m loading the data in and then displaying it, but I’m paging through ten rows at a time.” But what they’re actually doing is they’re throwing the entire 10,000 rows into the DOM and then paging through records in the DOM. And the browser is not a database. [Chuckles]

  So, it doesn’t like you to treat it like that with [inaudible], even though you can.

  Wasn’t the DOM a database initially? No, I’m just kidding. [Chuckles]

  Oh, I was like, “That would be more [inaudible].” [Laughter]

  It’s so slow.

  So, I’m just kidding.

  [Inaudible] history.

  Yeah, I’m sorry bro.

  Somebody needs to tweet that right now. The browser is not a database. [Chuckles]

  Yeah. But the thing about jQuery is that jQuery really lets you use the browser like it is a database, right? You could throw stuff in the DOM and just manipulate it all day long. But the problem is we see with the frameworks like React, any time that you are updating the DOM like that, it just cannot keep up. And the slowdowns in browsers are not JavaScript based. It’s almost entirely DOM and CSS. And so, we’ve also seen people though, I had a guy once show me, he had a grid that was paging several million rows. But he was doing all the paging server side and they had some crazy Scala backend that was doing their services and it was crazy fast, how you could move through millions of records and sort them and group them and do aggregations on the frontend while on the backend, which is where all that stuff should be happening, it was taking care of all the heavy lifting. 

  That’s awesome.

  Yeah, and to give one more example, Kendo UI also has a mobile framework as well. And one of the widgets, components in the framework is a scroller, with the idea you perform a more performant scroll on mobile devices. And so, you get the pull to refresh Twitter type behavior.

  Right, right.

  And it’s the same thing, that sometimes people use those sorts of things to build these endless scroll lists with it and they don’t really manage the DOM or really think about it. And I think you see this online, or at least I see it online quite a bit where people don’t do a good enough job cleaning up after themselves. For instance, you just keep building onto this DOM and then at some point the browser just can’t handle it and just either slows to a crawl or even crashes in some extreme cases, if you’re really showing a lot of stuff.

  Right.

  I was curious Burke, because you talked about some amazing implementation where people have styled the components really well and just done a great job. Is there anybody you want to call out?

  Ooh, that’s a good one. You know, the University of Wisconsin did a mobile app using Kendo UI Mobile and did a really fine job of styling it and using the iOS look and feel but bringing the badger red in and making it look like it was part of their app and not so much part of Kendo UI. I was really impressed by that.

One of the tedious things about working with Kendo UI is we work with a lot of customers that are large enterprises. And so, I don’t know if I can necessarily say off the top of my head without looking and making sure that it’s okay for me to do it. 

  I’m curious about roadmaps and what’s ahead for the few different products. TJ, could you talk maybe a little bit about what’s ahead for jQuery UI?

  So yeah, jQuery UI. To talk a little bit about the roadmap, I mentioned earlier that the datepicker widget is undergoing a rewrite. And the idea behind the rewrite is to make the datepicker more extensible so you can build things on top of it easier, because the current datepicker is a mess to build on top of. You’re stuck with what you get. The other thing we’re doing with the datepicker rewrite is using, I guess to take a step back, at the moment we use this project known as Globalize, which is also a project maintained by the jQuery Foundation. And we have embedded in the projects different locales from around the world. So, if you want a datepicker that works with Chinese or Japanese locales, and there are hundreds of them. But the problem with that is that we’ve been stuck maintaining that locale data ourselves. And so, we’re switching over to use a project known as CLDR, which is this community managed locale data to provide a global calendar that people can use across cultures. We’re working on that. 

The other thing we’re working on is we’re working with the Google team and some others to bring a pointer events polyfill to the project. A lot of people, jQuery UI is notorious for not working without a shim on browsers that use touch events. So, there’s a shim you can drop in to make it work. But out of the box, jQuery UI doesn’t work on, its interactions don’t work on Android and iOS devices. And there’s a long story behind that. But we have a really big problem with the touch event model, so we want to work towards writing a pointer event, writing two pointer events in the code and then using a polyfill so that it works everywhere. And that’s some of the things that we’re working on at the moment. 

  So, I just found out about CLDR yesterday as I was trying to do some conversions for, really I just want to go between the JavaScript date string and an actual time zone ID. It turns out to be insanely difficult. 

  Yes.

  In ways that I would not have imagined. And I happened to come across that both Chrome and Firefox have of course not completely the same implementations of an INTL object. Is that a future help for that kind of localization? Or do you know anything about that?

  I actually don’t know anything about an INTL object or any sort of thing that the browser provides for this sort of thing. So, I’m not sure.

  Okay. Well, I don’t know much about it. I just read the Mozilla page on it yesterday.

  I can say on the Kendo UI side, I have no idea what happens. I just use Kendo date and I hope to god that everything formats just write.

  Please work.

Right, yeah exactly. [Chuckles]

  I trust that somebody on the engineer team has already figured this out for me.

  Hold your breath, refresh. It worked.

  So, one of the things I think would be interesting to talk about, since you guys are both working on basically widget frameworks, to oversimplify matters. A while ago there was an article called ‘No More JS Frameworks’. It was a topic of discussion around here and hit the intarwebs. And I’m pretty sure even Anne Coulter has recently said that the population of JS frameworks is an indication of the moral decay in America. [Laughter]

  But one of the points that he makes in this article is the fact that we have to keep rewriting the components that we build every time a new JS framework comes out and we swap, switch over to it. So, we were starting using jQuery, using all these jQuery components, then people started Backbone and Knockout, and now we’ve flipped over to Angular. And now, they got to rewrite everything. So, as library builders, what is your guys’ opinion on that and dealing with that and how to handle that and how the industry is going to move forward with constantly new JS frameworks coming out?

  Yeah, I can take this. I have some pretty strong feelings about this. So, to me it comes down to developer productivity, because sure, you don’t need a JavaScript framework to build anything. You can use the tools the browser has and you can build a web app with that, certainly. Under the hood, all of the frameworks are doing something that you can just do manually. What these libraries are providing for you is out of the box solutions that you can just use. So, you don’t have to worry about when I build that autocomplete, how am I going to implement the keyboard controls? How am I going to style the thing? How am I going to write the event so as I type something completes? All of the different options associated for this, for all of these things. 

And that’s even for an autocomplete, much less something like a grid where you have to worry about, well how do I sort based off the columns? How do I group and aggregate these things? The libraries are about providing value in terms of these abstractions to make your life easier as a developer. So, if you’re the type of person that likes to spend the time to roll your own solutions to this and you want to take the time to do it, then absolutely, that’s fine and more power to you. But these libraries, if you take just even the simple widgets to even the more complex solutions, it’s just going to save you time and hassle. 

The other thing you get is accessibility support for free. So, to take autocomplete example, you don’t have to worry about those keyboard shortcuts working or whether the options for your autocomplete are going to be read for screen readers. You just get a component you can drop in and just feel confident that it’s going to work. And browser support as well. You can feel confident that it’s going to work in basically all the browsers you would care to support. 

  I can speak to this from a Kendo UI side and what I typically see. But I think that the idea of rolling your own framework or not needing one, we often call it ‘hasn’t been invented here’ syndrome sometimes, is that, and Hanselman said this best, is that it’s a good idea. But at the end of the day, you sit down and you’re like, “Okay. Build me a datepicker in two hours or I’m just going to go use this one here, which is already done.” So, it just comes down to productivity. 

In Telerik’s case, with Kendo UI, it’s not like they just sat down and said, “Hey. Let’s build a UI framework because it’s easy.” They had a decade of UI experience. It’s what Telerik does, is user interface. And so, there are ten years of really, really rough, hard lessons that are sitting behind these widgets. And the only way to really learn those lessons is just to be burned. So, a lot of times people, our customers, are partnering us and they’re looking to standardize on things. And that’s exactly what they don’t want to do, is they don’t want to have to rewrite code and maintain. They want us to partner with them and help them do that. And so, they decide we’re going to use Angular now, but they were using the datepicker before and they need that datepicker to continue to work in Angular. And we need to be able to provide that for them.

  So, do you guys feel like the explosion of JS frameworks is a good thing or a bad thing? And as component builders are we getting better at dealing with not having to rewrite the same components as new frameworks come out? Or is that not getting any better?

  I think that in terms of the new frameworks, that rising tides float all boats. And all the things that we’re learning in new frameworks like React really affect everybody. And we can all learn from these things and implement some of them in our project or provide integrations in our projects. So, every time we learn something new, it elevates everybody’s game just a little bit.

  Yeah. And there are specific examples of that, especially if you look at Kendo UI. Just a few years ago, when you wanted to build HTML in your JavaScript you would concatenate strings together to do it. And then we had these templating libraries, things like Underscore and such come out. And now Kendo UI directly supports templating. It has its own templating engine. So, we’ve learned from things like that. And as these good ideas come forward, other libraries can learn from it. So, even though there’s this explosion of libraries, explosion of choices, I think developers tend to find the things that work. And those things get elevated and get pushed out. So, we get the best of the ideas that come out of these things.

  And let me do add here that I think the thing that’s most important that we can all do as developers and anybody who’s working on a framework is to try to be very careful not to lock in to any certain area. So that when somebody comes along and says, “I want to use Angular,” you don’t have to look them in the eye and say, “You can’t.” Right?

  Right.

  And that’s always the tradeoff. Can I provide this functionality without locking you into doing something a specific way? Which really then takes away your freedom to be innovative and actually build applications the way that you need to build apps.

  Right.

  Yeah. And both projects try to these in different ways. JQuery UI for instance, we really strive. One of the important goals is to make it extensible. So, we get people that have absolutely crazy requests for widgets. They want to integrate it into whatever. They want such and such options. So, our general approach is to just make these things extensible and pluggable so that you can drop them in and you can make them work.

  So, I think Joe, talking about what your question was, I think that another reason that we rewrite widgets every time a new framework comes out, every time Ember’s here or Angular’s here or now React is here, I think the reason that we do that is because we don’t, some people don’t mind this, some people do, some people are like build Nazis and they hate having extra dependencies. So, if they can get away with just having Angular as an example, just having their widgets built in Angular, they don’t have to add the jQuery and jQuery UI dependencies to their app, then they would rather do that. So, I think it comes down to preference, because some people don’t care and some people want to just, like you guys quoted Hanselman, “I want it done in two hours and if it’s not, I want whatever the industry uses.” So, I think it just depends.

  Yeah. And I think the one thing about that is the mobile explosion has made people care a lot more about bandwidth and the amount of JavaScript and code that they’re sending to users. And I’d say if I had one complaint that people have of adding these libraries, or really any UI framework in general, is that they’re too big or too bloated or do too much. And I think that claim, I hear it a lot, but I think it’s a little bit crazy. Because both of these projects, if you look at Kendo UI, jQuery, or even any of these other UI frameworks, they’re very modularly written. So, if you want to use Kendo UI’s autocomplete or even jQuery UI’s autocomplete, that’s a very isolated piece of functionality. You can just grab that. You can grab it with AMD. You can use that. And you don’t have to ship everything Kendo UI does. 

People freak out to learn that Kendo UI in its entirety is a meg of JavaScript. And people hear that and go, “Oh my god. A meg of JavaScript? What in the world?” But what you don’t realize is well yeah, Kendo UI does an enormous amount of stuff. There are over 40 widgets. There’s all this localization. There’s data visualization. There’s a full mobile framework. And if bandwidth is a consideration for your app, it’s really irresponsible in a way to just ship that entire thing to your users. You can use, Kendo UI and jQuery UI both have download builders. They both have AMD support. It’s very easy to pluck out the pieces of functionality that you need so that you’re not shipping this monolithic thing to your users in your production apps.

  Paul Irish had a good point on this as well. He’s like, if you feel like your JavaScript is too big, remove an image. [Chuckles]

  Exactly, right? One image later, you’re good.

  Right.

  Well, the average website now as of last month, now contains over one meg of images. [Chuckles]

  Wow.

  And that’s the average site. So, usually there’s some other, and it’s not just images. There’s also making sure you’re caching your assets appropriately, making sure you’re reducing HTTP requests, you’re minifying your JavaScript, you’re concatenating your JavaScript together. Same thing with CSS. Often things like that give you far bigger bang for your buck than trying to microoptimize your JS framework or your choices of plugins or widgets or whatever the case may be.

  TI…

  Do you guys remember, Jake Archibald wrote that article about the async tag, the HTML 5 async tag?

  Uh-uh.

  Async attribute. Essentially, he was talking about what’s the fastest way to load scripts and get your app to run. And it goes through this whole thing. And he talks about async and at the very end, the conclusion is concatenate, identify your scripts, and then put them all in one include at the bottom of your page. Still the fastest way to do it. 

  So, I talked to Jake and he had said sometimes people are zipping up so much even when it’s all in one file that sometimes putting it in one can slow it down for mobile. He says maybe a couple is okay.

  It really depends on your app and how much you’re throwing in there. For instance, maybe you have one script that you share across multiple pages, so it would behoove you to put all of that shared stuff in one file so that can be cached. So, when you visit other part of your app or other pages on your site, that’s already in the cache. The other thing is that mobile browsers have notoriously low cache sizes. There’s some limit that depends on the browser itself. 

But I’ve seen at one point, and I don’t know if this is still the case, but on iOS Safari, it just would not cache any file that was greater than 16K. And it would just completely ignore any cache headers if it was bigger than that. And I think it’s a little larger than that, but it’s still to the point where you might not necessarily want to ship a mega-file, an extreme-sized file. But I think the general stance is still two or three scripts, sure. But not this 15 or 20 script tags. That tends to be very common in websites. I think according to the last data I saw, the average site is now including, the average site in the top 10,000 sites is now including 19 JavaScript resources on the page. 

  So, I’m going to say this dude’s name wrong but he’s awesome so I feel bad doing this. Ilya Grigorik, one of the Chrome Dev guys, he gave a talk last year at the Chrome Dev Summit and he talked about breaking out your JavaScript into two pieces, one which is, I can’t remember the exact idioms he used but they were money. When he was giving the talk, I was like, “Wow. This is perfect. And some of it was, you need it to, if it doesn’t start painting the page until all the JavaScript is loaded, it’s going to look really bad, especially on mobile. So, you need to have a part that bootstraps your app and that needs to download fast and first. And then the rest of your app can load subsequently. 

  Yeah.

  So, I thought that was a really interesting way to look at what pieces of your JavaScript should run quick to give the illusion that it’s working as opposed to just waiting for it to block until it downloads this huge JavaScript file. 

  It’s actually a really good recommendation. And the same applies to CSS, that you should try to put your critical CSS in the head. And some optimizations even talk about not even serving a script tag but just tossing your JavaScript and tossing your CSS inline just in script and style blocks for that first paint to be instantaneous. You don’t even have to do an HTTP request to get your resource for those critical assets. But I think for the majority of developers, that’s an ultraoptimization. I think most people aren’t dealing with the point that their blocker is getting to that fast paint in the first handful of milliseconds that they’re still including a whole ton of script tags. And there’s I think more practical optimizations that your average developer can do before you have to get to that.

  True. I agree. 

  You know, speaking of crazy optimizations, somebody from the Gmail team may listen to this and correct me, but I believe that the way Gmail handles this is they do, Aaron what you were talking about. They bootstrap the thing and then they send all the other JavaScript down commented out, so it’s just text and it doesn’t get parsed. And then when they need it, they uncomment that section of the JavaScript and they execute it.

  Wow. 

  Yeah.

  That’s pretty legit. 

  Yeah, it’s pretty awesome.

  I don’t even know how you do that, but that’s cool.

  Yeah, I could be wrong on that. But I swear, I read an article somewhere there talking about how Gmail optimizes to be so fast.

  If you can do that, I want to learn how to. That’s crazy.

  Yeah. They used to do that. And I don’t know if it’s still the case anymore. But they just send it down as text so the JavaScript interpreter doesn’t get it. And then basically, you take the contents of that and then you just inject it into a script tag. And you can still cache, because you can still cache that file, that text resource that you’re getting. But then you just basically take the text contents of that, remove the first and last characters to uncomment the thing, and then just toss is it in a script tag.

  I love it a lot. 

  Well, we’ve been going for quite a while so maybe it’s time to start wrapping it up. Are there any final questions before we do picks?

  Not from me. Does anybody have the number for the guy who’s in charge of Skype? That’s my only outstanding questions.

  Yeah.

  I was going to make Skype one of my picks. So… [Laughter]

  You should totally do that. 

  Skype. [Laughs]

  Disrupting communication everywhere. 

  But the one last thing I want to talk about is, so if you actually want to contribute to either jQuery UI or Kendo UI, there’s a number of ways that you can actually do that. A lot of people when they say, “I want to contribute to open source,” their first instinct is to just jump into the bug tracker and, “Let’s find the hardest bug,” and just go ahead and tackle it. But I want to tell people that that’s usually not the greatest idea because the bug tracker is the bugs that are actually open. Usually there’s some reason that bug is open and hasn’t been fixed. Either it’s a really hard technical challenge or there’s some logistical reason that it can’t be tackled. 

So, if you want to get involved, one of the great ways to do it is just to help out support-wise. Things like Stack Overflow questions, assisting others using the library, writing about the library, writing blog posts, helping others in any way you can. I think that’s a great way to get to know what people are trying to do with the project, get a sense for how the project gets maintained. And then over time, you can just get more familiar with the project and start to work on the actual code and submitting fixes and documentation and things like that.

  Cool. 

  Yeah. And let me just also point out if I could, I totally agree with what TJ said. As far as Kendo UI goes, you can find it via Google easy enough. Kendo UI core is the Apache 2 open source version. So, if you just google Kendo UI core, you’ll get to the download page. And if you want to search, I can give you the GitHub URL. We’ll put it in the show notes. But straight to the GitHub repo as well. And we’re also [inaudible]. Open an issue, submit a pull request. And we have people do that all the time. Somebody sent something the other day and was like, “Hey. This doesn’t look great with Handlebars. Here’s how you fix it.” We were like, “Awesome.” Helps everybody. 

  Should we do our picks?

  Yeah. Let’s do picks. AJ, do you want to go first?

  Yes. Yes, I do. [Chuckles]

  So today, I’m going to pick something a little unusual for me. I’m going to do some style picks. So, like many of you, our listeners, I am a humble man who occasionally gets a haircut. And I like to go to hair schools to get my hair cut because, so I don’t gamble, but I like the idea of it, the thrill of it. So, what I do is when I get my haircut, I go to the hair schools. And that’s an honest gamble, because you’re either going to get a pretty good cut or a pretty bad one. And I like not knowing what it’s going to be and then just dealing with the consequences for the next week and a half. That’s it. Fills out the rest [inaudible]. 

But as part of this, I always get a different hair product pretty much every time I get my hair cut. So, they’ll give me the different paste or the [pomade] or the gel or whatever it is. And I found that the one that I like the best is called Control Paste by Aveda. And it just, for me, it’s the right hold, the right shine, the right everything, smells good too. I have really thick and fairly coarse hair. So, if you’re that kind of person then you might like it too. And I’ll include a link to that.

And also, in case you didn’t get the memo five years ago, people started wearing colored argyle socks and mismatched and all that stuff. And now, for those of you that are a little bit more conservative like myself, now is the appropriate time now that everybody else has been doing it for five years, that you can safely do it without looking like a hipster. And on Amazon, there are these really cheap socks that have a couple of different argyle blends and whatnot. You can get, I think it’s a 12 pack for 24 bucks, so pretty screaming deal, because on all the hipster sites if you want to get colored argyle socks you have to pay $20 per pair. So, I’m going to pick that as well. And I’ll have links to both of those.

  Awesome. Okay.

  Can I go next?

  Yeah Aaron, please. 

  Alright. I got four picks. And the first one’s totally self-serving. Again, I’m going to do it anyway. I’m finishing up a course on Egghead.io about Grunt builds for Angular projects. So if you’re, like what Burke was talking about or what TJ was talking about, if you’re one of those people that ships a hundred script tags on your project and you want to learn how to build it, this course will walk you through doing an Angular Grunt build to get it all into one file for your CSS and your JavaScript. 

And anyway, the next two picks are both books. One is called the ‘Masters of Doom’. Has anyone read this? 

  No.

  No, okay.

  No. 

  So, the ‘Masters of Doom’, it’s about John Romero and John Carmack, the guys who did Doom and Quake and currently Carmack’s doing Oculus Rift. So, it just walks you through these, it starts with these 16-year-old kids and this insane ability to understand code back when you were teetering between the Atari, the Commodore, and this new thing that IBM was thinking about putting out. And so, it takes you through their story. And I couldn’t put it down. It was a very, very intriguing and inspiring book. It’s called ‘Masters of Doom’ if anyone’s looking at it. Part of the reason that it is so good, it’s such a good read, is on Audible Wil Wheaton is the narrator. So, anytime he’s narrating a book, it’s going to be epic. 

I’m going to skip the next one because I realize I did it in the past. It’s a book called ‘The Martian’, another really good book. 

And then I’m going to come up to a new build plugin. So, I work at a company called Domo. We have a huge app, over 125,000 lines of JavaScript. And we have a huge Grunt build. And we took out, one of the developers here named Kent C. Dodds, he took out, we use ng-min on our Angular. And our build went, he replaced ng-min with a new plugin called ng-annotate which does the same stuff. It took our build from four minutes to one and a half minute. And so, we didn’t even realize that ng-min was taking so long. So, ng-annotate, anyone doing a Grunt Angular build using ng-min, look at ng-annotate because it was amazing for our build process. So yeah, those are my picks.

  Awesome. Okay, I’ll go next and then we’ll have our guests go last. As I have said many times in the past, I’m a huge soccer fan. So, I’m obviously going to be picking the U.S. soccer team and Tim Howard even though they lost yesterday against Belgium. They played their hearts out and Tim Howard was a monster setting the World Cup record for most saves in the finals game, or a nongroup game. So, props to the U.S. Soccer team, even though it does indicate the moral decay of the United States. [Chuckles]

  I’ve also been playing a game that I had installed a long time ago and haven’t played for a while and just got back into it. It’s really fun and it’s free. So, that’s even better. It’s Path of Exile. It’s like what Diablo 3 should have been without the $60 charge. So, I really enjoy that game, having a lot of fun with it. 

And the last pick is a card game called Council of Verona. I played this at a board gaming convention a few months ago and just barely got my copy, picked it up from Amazon. It’s a really fun card game for two to five people, plays fairly quickly. But it’s based on the setting of Romeo and Juliet with the Montagues and the Capulets and they’re fighting and you’re manipulating the groups. You’re laying down cards and trying to manipulate the groups so that you win. It’s a really fun game. Cool strategy, but easy to learn. Have a lot of fun with it. It’s pretty cheap on Amazon.

So, those are my picks. Let’s go to Burke. What are your picks?

  Okay. I’ve got two. The first one is I clicked on an ad in Gmail for the first time two days ago, ever.

  Wow.

  And it was for mint pants that are made out of sweatpants material but they look like dress pants, like pajama jeans.

  Oh. [Laughter]

  I don’t even wear dress pants. But it was compelling enough to have a look. So, it's called BetaBrand. I don’t know.

  Bro, are they in the mail? You already bought a couple?

  I didn’t. But it was only because it was cost prohibitive. They’re $110.

  Whoa, aww.

  Which is a lot for a pair of sweatpants.

  What?

  Never mind. 

  They look good. I’m telling you, you got to check it out. 

My other one is a little bit more useful. It’s a Mac app that I use constantly. It’s called Sip, S-I-P. You guys know this? It’s free but it wasn’t always free because I know I paid for it one point in time. But it’s a color picking app for Mac. And all it does is it gives you a dropper essentially and it magnifies the area underneath the dropper so that you can select your color. And then it’ll copy it to your clipboard in any one of nine billion different color modes, most of which I don’t even recognize.

They must be used by people that use Photoshop. But I use it constantly. And it is a fantastic app. 

  I can go last then. I have a couple of picks, all books. The first one is by, we talked about him earlier, but Ilya Grigorik and hopefully I didn’t murder his name either. But he has a book called ‘High Performance Browser Networking’ which is actually really good. It digs into the network stack and what web developers need to know about the network stack, which is something I don’t think a whole lot of these people coming from a web background know too much about. I didn’t. It’s a pretty good introduction to that. 

Ordinary Live in North Korea’ which was actually a fascinating book because it didn’t approach North Korea like a lot of history books. They tend to approach these situations from a political standpoint. But it talked about just ordinary people, ordinary lives. So, what do people eat in North Korea? What do they do? What’s the propaganda like on a day-to-day basis? And I just thought it was a fascinating discussion of the country and the background of those people. 

My last pick is ‘Divergent’ which just had a movie that came out about it a few months ago. The movie I did not think was very good, but the book series behind it, it’s a trilogy, is actually really good. If you like the hunger games at all, it’s a similar post-apocalyptic type story that’s very good.

So, even if you saw the movie and you didn’t like it, it’s worth checking out the book series.

  Cool. 

  Awesome.

  That’s called ‘Divergent’?

  Yeah, ‘Divergent’. 

  Alright. I’m going to go get it, because I’m looking for another good book. 

  I just started reading it. 

  And?

  I’m only one chapter in.

  And?

  Well, I think it’s going to be good. I choose to read books based on whether or not I like the movie. I read ‘Hunger Games’ and ‘The Host’ because I thought the movie was compelling. And I was like, “I bet that the book’s even better.” So, my guess on ‘Divergent’ is that the book is even better than the movie. The only thing that I’m mad about is the way that the society is divided up is just a little, doesn’t follow any of the normal divisions that you get in… it’s hard to explain.

  Ah, yeah.

  Spoiler alert.

  Yeah. I was going to say it does get explained. But I can’t reveal anything. 

  Spoiler alert. 

  It’s not really explained in the movie.

  Stop the podcast if you don’t want a spoiler.

  Right. It’s a trilogy though, so it doesn’t get to it for a while. 

  Oh, okay, okay, alright.

  Thanks very much guys, for being on. It was a great episode. We’re really happy to have you on.

  Yup, thanks guys.

  Yeah, thanks so much for having us.

  Thanks for having us. 

  See you guys next time. 

  Does Chuck usually say something in the end…

  Awesome.

  That I’m supposed to say? [Chuckles]

  I think Chuck says, “Stay classy, San Diego.” [Chuckles]

  Yeah.

  [Inaudible] that’s what he says. [Laughter]

  Don’t just have a good night. Have an American night.

  Yeah. [Laughter]

  But Merrick’s not here.

  Oh, I get it. I get it, AJ.

  Ah.

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