Front-End Developer Cast

Front-End Developer Cast
By Craig McKeachie
About this podcast
For those who see the value in JavaScript, HTML, CSS, and UX. For those who see the revolution happening around JavaScript and are compelled by browser-based single page-applications. For those who want to be part of the future of web applications. Keep up with the latest JavaScript, CSS, and HTML libraries, frameworks, and standards.
Latest episodes
Aug. 15, 2015
On this episode I discuss JavaScript error tracking with Todd Gardner. More specifically we talk about: The JavaScript Error Object The DOM Global Error Handler How errors bubble How errors bubble through callbacks Example of wrapping callbacks Tweet To subscribe to the podcast, please use the links below: Click Here to Subscribe via iTunes Click Here to Subscribe via RSS (non-iTunes feed) Show Notes: Resources Code from Todd’s Traces of Errors talk TrackJS Full Transcript Will be available soon. The post JavaScript Error Tracking with Todd Gardner | Episode 12 appeared first on Funny Ant.
July 15, 2015
On this episode Cameron Wardzala and I discuss the emergence of style guides and pattern libraries instead of Photoshop comps when building web application and site designs. We also dig into his experience outgrowing bootstrap on a project, new modular CSS frameworks like SMACSS and Atomic Design, and the ongoing debate of Less or SASS. Tweet To subscribe to the podcast, please use the links below: Click Here to Subscribe via iTunes Click Here to Subscribe via RSS (non-iTunes feed) Show Notes: Cameron’s Blog http://dangerisgo.com/blog/2013/02/14/how-we-grew-out-of-bootstrap/ https://github.com/cwardzala/styleguides/blob/master/styleguides.md Jekyll Middleman Atomic Design SMACSS SASS LESS http://www.findawayworld.com/ http://www.playaway.com/ http://www.cheezburger.com/ Full Transcript Craig McKeachie:  On this episode, Cameron Wardzala and I discussed the emergence of style guides and pattern libraries. [background music] Craig: Welcome to the “Front-End Developer Cast.” The podcast that helps developers be awesome at building ambitious Web applications, whether you’re a JavaScript Ninja or you’re just getting started. I’m your host, Craig McKeachie. Hi, everyone. My interview today is with Cameron Wardzala. We discussed the emergence of style guides and pattern libraries instead of Photoshop comps when building Web applications and site designs. We also dig into his experience outgrowing bootstrap on a project, new modular CSS ideas like SMACSS and Atomic Design, and the ongoing debate of Less versus SASS. Today, I’m lucky to have Cameron Wardzala with me. I’m at a conference and was lucky to meet up with him. I’m noticing this trend in front end style guides that people are creating. Some people are calling them…what’s the other word that you hear them called by other things? Cameron Wardzala: Style guides, pattern libraries. That’s pretty much the two that I hear the most. Craig: That’s the other one I hear a lot. Cameron, would you like to introduce yourself? Cameron: My name is Cameron Wardzala. I work for Findaway and I’m a front- end developer. Craig: Tell me more, what is a style guide? That seems like a pretty new concept. Cameron: The concept’s been around for quite a while. About 2011 is when they started being spoken about on a regular basis. A style guide is basically a living document of code, of the elements on your site, the style, the elements that you could have on your site. Craig: Do you see them more for like websites or more for like Web applications? Or is it just a different implementation but the human used for either? Cameron: In my personal opinion, I see them used for both. I’ve used them for both. Anytime you have a visual language, something like a style guide is a useful tool. Craig: When people use the term pattern library, do you think they’re talking about something a little bit different? Do they talk about more component type stuff? Is it the same thing or is it just an interchangeable term for you? Cameron: There are subtle differences. Roughly, they are the same thing. They are pretty interchangeable. But a lot of times when I hear pattern library, it invokes something a little bit more formulaic than a style guide. For me, a style guide is almost like a raw dump of all your style elements. With a pattern library, it almost invokes a feeling of much more purpose, much more thought put into it. Craig: What is the need that caused people to start creating this? What do you think happened in the world where we used to use Photoshop comps or just build an application without a style guide. Explain to me what’s been happening that people are realizing that they need these. Cameron: The need really arose when people, developers in particular, needed to start maintaining sites on a regular basis, and not just singular developers, but teams of developers. They needed some way of cataloging the styles, the visual treatment of the site so that when other developers walked up, they could easily pick up things that are already been created, or start with elements that had already been created. It really helped foster a mentality of maintainability. I think that’s really where it started was they needed this tool to help reduce redundancy and things like that. Craig: Do you feel like there’s a standard set of things that are in a style guide, or is it more like a per project, or per company type thing. Cameron: Yeah, for the most part there’s a standard set of information that you have, and then you get past that standard set of information. It becomes per application, per site, per company, per team. Craig: What is some of the standard stuff, just so people can get a more concrete feel? What does a style guide look like, and what are its contents — a lot of common things that are in it? Cameron: From a standard, basic standpoint, things like text treatment, typography, headers, paragraphs, body copy, things like that, and then typical elements, buttons, form fields, things like you would find on a site or may need to use on a site. Craig: Gives me a feel for it. As a developer, sometimes I think that stuff is all needed, but beyond the button, there starts to be lists, grids, date pickers, and stuff. Some of that might not be needed. Some style guides, but the more application and less of a website you have, you pull in that sort of thing, you give it the same treatments? Cameron: I try to tell people when they’re building a style guide to just be as verbose as possible. Put as much information in there as you can, because you may not need that button treatment right now, but somebody else later might need that. It’s going to make their life easier to be able to walk up and get the information that they need. Craig: Is this replacing Photoshop to some? Used to be these static mock- ups. Is there some sort of evolution I’ve been hearing about? Is this a better work flow? Can you talk about that a little bit? Cameron: It’s another piece in the evolution of the work flow that we already have, or that’s already going on, which is we’re moving much from this process of page-based design. “I’m designing a page, and here’s all the things on the page. Here’s the next page and all the things on that page,” to, “Here are the components that we’re building.” “Here are the modules that we’re building. Here are the pieces and the parts of the site, rather than the much larger picture of things.” Style guides really play well to that, because as you’re designing those, as they’re being built, the style guide can be updated and added to, but it can also be pulled from. Instead of saying, “Oh, the designer’s got to go and design this thing,” the designers may say, “Oh, let’s look at this style guide.” Pick out two or three things they want to use and build right from there rather than them taking time to design it, giving it to a developer, and then them developing it or that type of process that you see typically happen. Craig: What kind of tools do you use? Tell me about…you obviously built some style guides. What do you use? What are your tools of trade for this task? Cameron: It’s just stating with a blank page. There are a few generators and starting frameworks out there. Personally, most of the style guides that I build have been fairly specific to the site or application that I’m building them for. I typically like to start fresh and start small. Start putting in the little things, like I said, typography, body copy, buttons. They are really small stuff. Then work out from there to much larger pieces on site. Craig: What you’ve got is like a static-h at the end, where you’re using as a site generator? I’ve heard some people using Middleman or… Cameron: I’ve heard of people using Jekyll or things like that to help facilitate building of style guides. But at the end of the day, you’re generating static HTML so you could just as easily break some static HTML team out, get some content in there and write it. Craig: How much of this have to do with organizing and writing CSS and the approaches you take to that? Could you discuss that a little bit? Cameron: Style guide briefs off of things like Atomic Design and SMACSS, and these modular approaches to CSS. If you’re using some of those models to build your CSS, then the style guide is a natural thing to build. Craig: I’m not sure how familiar you are with these things but I’ve definitely heard of SMACSS at least five times in the last few months or something like that, and Atomic. Can you elaborate on what this movement is in terms of modular CSS without going too deep into it? What it is? Cameron: There are a few different variations to it. SMACSS is just focusing on modularity and making sure that things can be portable and styles can be portable around the site. Then we have things like Atomic Design which stresses the concept of breaking things down into the smallest parts, focusing it on the smallest parts and then working up from there. Craig: There are competing ideals about the right way to do this. Is it all about class-based versus ID-based or is it more like the things like what you’re just commenting on? Cameron: You’re always going to have people who want to do it a little bit differently than somebody else and that’s healthy. Like somebody who came from the world of none of this to picking up SMACSS and falling in love with that, and picking up Atomic Design and focusing on that. Finding where I fit in that whole thing. I don’t necessarily like to think I prescribe in one or the other. But it’s nice to have a really big pool of information to pool from. You have OCSS, you have SMACSS, you have Atomic, a few others out there. It’s really nice just to have somebody else coming up with great ideas and being able to figure it out for myself. Craig: That makes a lot of sense. The style guides you’re building, are they more for a company and they’re used through several applications or you’re building a one off for this particular application? I know the purpose is more across but what do you find in the real world? Cameron: My experience…there are two folds. When you’re dealing with a company or brand, you can almost have two separate style guides. You almost have a brand-base style guide which lays out that sort of thing that could be used across multiple applications or sites but then you also have style guides that are very focused to the applications and sites. That’s typically how I approach it. Is if Findaway we have three of four brands that we have styles for and we build a number of sites for each brand. We’re going to have a nice brand framework that we pull from. But in each site that built have their own smaller style guides that sets up the patterns and styles for that site specifically. Craig: Are you allowed to talk about which specific sites? I don’t know if it’s public information for… Cameron: I can talk about the two that we have out there. We have Playaway which is our preloaded device side of the business. We have quite a few sites for that, Playaway.com. We just launched Shop.playaway.com. Those sites hopefully, in the next year, will unify one brand framework and brand style guide. Each site individually has its own. You can go to shop.playaway.com/styleguide.php, and that’s our style guide for that site. You can see it. You can see all of our swatches, all of our patterns that we have on that site. We have Audioengine, which is a new brand that we just launched last year. Right away, I said, “We have to go out the door with the style guide. We have to go out the door with focusing on setting up this brand framework, setting up this brand style guide.” That was not public. For the two or three sites that we have for that brand, they all pull from the same set of styles. Each site has its own extended styles on top of that. Craig: When people pull those styles in, it’s more almost like documentation or examples of the right way to do the styles. I’ve heard people talk about this holy grail of styles or patterns, API, that sort of thing. This is more like a static documentation, and then you’re supposed to reuse these best practices, isn’t it? Cameron: It’s a little bit of that. We took a little bit different approach to it, something that I started with the Audioengine brand, which I call a brand’s framework. We treat that as a third party module. We install that with Bower. It lives in a GitHub repo completely separate of everything else. We have a few other brands in that repo, as well. Whenever we need to use one those brands, we just Bower install Findaway brands, and we have all the CSS for all of those brands. It’s all SASS. We pull in the SASS file for that brand, it includes all the other stuff it needs, and we’re off to the races with that CSS. Craig: I was just talking to a friend of mine on the way up. He’s more of a Less fan, but it seems like the world is moving towards the SASS side. Can you talk a little bit about the Less/SASS thing and why you maybe prefer SASS over Less? Cameron: I read a tweet earlier that said, “There’s been a lot of SASS talk at CodeMash but not a whole lot of talk about Less.” I was like, “You know what? Yeah, there hasn’t been that much talk.” For me, it was a personal thing. When I worked at Cheezburger, we built on Less. We started with Bootstrap, and we built on Less. That was the language that we chose. When I came to Findaway, they had already chosen, as a team, they chose SASS. I was already a pretty big fan of SASS because of the level of tools that it provided that Less didn’t. It was a really nice, natural thing for me to just pick up on. It’s become my styling language of choice, at this point. Craig: Are you an SCSS guy, or you’re more of a…? Cameron: Yeah, I’m a CSS purist, when it comes to that. I can’t get behind the SASS syntax. Craig: Explain that for people who don’t know. I just recently learned it myself. Cameron: The difference is you have SASS syntax, which is the original SASS syntax when SASS was created, and then you have what’s called the SCSS or “SASS-y” CSS, I think I’ve heard it referred to this week. The difference is SCSS follows the CSS patterns. You have curly braces. You have semicolons. You have things of that nature. The SASS is much more like Haml, because it was written by the same guy that wrote Haml, which is you omit all the extraneous things that you don’t need, curly braces and semicolons. You let the preprocessor figure that all out. It’s indentation-based and things like that. Craig: That’s helpful. I noticed you have a GitHub repo with lots of example style guides. I’ll definitely put a link in the show notes. Out to that, do you want to talk about…I know it’s hard on a podcast like this, but do you want to talk about maybe a few of those you like and some particular things you like about them? Or anything coop? Cameron: I started the repo just to gather all these things up and there are some really great ones out there. The ones that I always go to are things like Starbucks which was one of the very first big, popular style guides that came out. Just seeing what they do and how great their style guide is and how it really hasn’t changed that much over the last four years that’s been around. But that they continue to evolve it. You can see that it has a last updated date of sometime in the last month or two. It’s nice that they’re continuing to maintain it. That’s always a good one that I go to whenever I need inspiration. I’m trying to think if there’s any more that stand out. They’re all great. Somebody asked me Tuesday if I’ve ever seen a bad style guide. I had to say no, because the only time I’ve ever seen a bad style guide is when I haven’t seen a style guide. Anytime I see a style guide, it’s just great that people are doing that. Craig: Help me understand, just playing devil’s advocate here, particularly in bigger enterprises where they’ve never done this sort of thing before. I’m a developer and I say, “Why not just use bootstrap?” Isn’t the bootstrap documentation basically a style guide or foundation? Another CSS framework. Help me understand how you make that argument for the value of a style guide for an organization with all other things out there in the world. Cameron: I can speak this really well. Not to devalue bootstrap or foundation, I love both of those frameworks. Their documentation was one of the big inspirations for…at Cheezburger, we actually built — we did a redesigning in 2011 — off of bootstrap. That was one of the big things. They had great documentation. It was one of the very first responsive frameworks out there. We thought it was a natural thing to do. The problem we ran into is two years later we were outgrowing it. I wrote a blog article about this two years ago, two and a half ago probably. We started to hit the walls… [crosstalk] Craig: I’m trying to understand what was it like. What was the first thing where you were like, “This isn’t quite working.” What things were happening when you hit that wall?. Cameron: The big thing was when we chose Bootstrap we said, “Oh, we have this great documentation, so if you need to know how something works just go look at that.” Our developers…it was hard for them to wrap their head around that. It wasn’t our thing. For back in developers who weren’t in front of the CSS all the time it was easy for them to forget that “Oh, this is just Bootstrap so I’m going to look at the Bootstrap documentation.” That’s what really pushed us towards to…we need our own set of documentation. We need a style guide. We started to hit the wall with Bootstrap and overriding things, and changing things. We started coming up with our own model so it made sense to have our own documentation. Craig: Was it things that were missing that you needed to be more detailed in order to get developers enough information and then override, you spoke of. What kind of elements did you find were useful to guide your developers that were missing from the Bootstrap world? Certain components? That sort of thing. Cameron: At Cheezburger, it’s a pretty unique site, or set of sites. We have a lot of unique module, a lot of unique components that we’re building. That stuff wasn’t represented in the Bootstrap docs, because it was all custom. That was one area where we needed to have the documentation on this. But we also started to get to things like we wanted to use a different set of icons than what Bootstrap was using so we swap in our own icons. Now, we have to have documentation for that because that’s not the same as bootstrap. It got to this point where we’re starting to swap things out from Bootstrap and we really needed a way to get that information out to our developers who needed it. Craig: I totally get that you need your own set of documentation because you got to be able to add to it, override things and stuff like that. Where you were to start a new style guide today from scratch, would you start with one of those frameworks and then build around it? Since there is so much man hours put into worrying about all the browsers and stuff or is it not that complicated if you really have done it a few times? It’s easier to start from scratch. Cameron: It depends on the application and the site. If what you’re going for can be achieved within the limitations of those frameworks, I think those frameworks are a great place to start. They’re a great first iteration. Maybe two or three iterations down the road, you start to pull those out. You start to swap them in with your own thing. If out the gates, you’re going out. You already can identify on one hand things that you’re going to need to change or new things you’re going to need to introduce. Then I would almost say stay away from those. May be pull from them from a framework perspective. Maybe stay away from those. Go with something else like bourbon or meat that gives you those tools, but you’re not confined to a frame work. Craig: This is a little bit of topic, but I hear a lot of buzz about the Goggle material design lately. It seems like what they’re starting to put out there is something similar to a style guide. I’m trying to make sense of all this stuff in my head. Can you help it all in? Cameron: Yes. Goggle’s material design, especially their documentation, is probably one of the best. I should have mentioned this earlier, but probably one of the best style guides that I’ve seen. Just because of how thorough it is. How much information they give you. It also goes back to what you’re talking about before where you have one style guide for one too many relationship. One style guide for whole bunches of sites and whole bunches of applications. It’s centralized, and it’s very concise. I think that they’re doing a great job of applying that to all of their applications and all of their sites. They’re really unifying under one brand. Craig: That’s great. It seems like it’s still maybe…it’s infancy a little bit. Cameron: Yeah. We’re going to see the idea. Not just Goggle’s material design and what that looks like right now. The concept, the material design, is going to…We’re going to see that evolve and really take off in the next…I don’t know two to three years. Craig: It’s been a pleasure to have you on the show. Anything in particular you want to send people to your blog or things like that? Cameron: You can check out my blog at dangerisgo.com. I don’t update it very much, but hopefully maybe this year it will be a resolution of mine. If anybody is interested in style guides, check out my GitHub repo. Honestly, go check out styleguides.io. Debenham created this site. It is amazing. It has way more information than I could have ever imagined to gather, and it’s open sourced. If anybody has anything to add to it, feel free to do that. I don’t want to speak for her, but it’s a great site. I keep telling people about it. It’s amazing. Craig: Styleguides.io? Cameron: Yes. Styleguides.io. It’s amazing. It came out a month or two ago. It has completely changed how everybody looks at style guides because just so much information, so many different perspectives, articles, books, presentations, links to style guides, and things like that. If you want to know anything about style guides, that’s the place to start. Craig: Thanks again for coming on. Cameron: Not a problem. Thanks for having me. [background music] Craig: Thanks for listening to the Front-End Developer Podcast. Please subscribe to the podcast by going to the iTunes store on your phone or desktop then searching for Front End or via RSS by going to frontendcast.com where you also find show notes and a full transcript of each episode. You can also sign up for my free Angular JS Backbone and Ember Crash course. All of them solve the same problems. Why not learn them together? See you next time. [music] The post Style Guides and Pattern Libraries with Cameron Wardzala | Episode 11 appeared first on Funny Ant.
June 15, 2015
On this episode Nik Molnar and I discuss web performance with Nik Molnar.This isn’t just another YSlow talk, things have evolved and I learned quite a bit from this talk so hopefully you will as well. Tweet To subscribe to the podcast, please use the links below: Click Here to Subscribe via iTunes Click Here to Subscribe via RSS (non-iTunes feed) Show Notes: Nik Molnar’s Blog Great site for performance tools mentioned: http://perf-tooling.today/ Nik’s popular open source project for .NET web applications Glimpse. What CSS triggers the browser to paint: http://csstriggers.com/ Full Transcript Craig McKeachie: [0:00] On this episode, Nik Molnar and I discuss Web performance. [0:03] [music] Craig: [0:14] Welcome to the Front-End Developer Cast, the podcast that helps developers be awesome at building ambitious Web applications, whether you’re a JavaScript ninja or you’re just getting started. I’m your host, Craig McKeachie. [0:27] Hi, everyone. My interview today is with Web performance expert, Nik Molnar. Let’s get right to it. This isn’t just another YSlow talk, though. Things are getting more evolved in the space, and I learned quite a bit from this talk. Hopefully, you will as well. Here it is. [0:44] Hey, today, I’m lucky to have Nik Molnar with me. Hi, Nik. How are you doing? Nik Molnar:   [0:47] I’m doing all right, Craig. How are you? Craig: [0:48] Good. Thanks for coming on the show. Today, we’re going to talk about Web performance, but why don’t you tell everybody a little bit about yourself first? Nik: [0:55] You covered my name already, so that’s good. Craig: [laughs] [0:57] Nik: [0:57] We got the most fun thing out of the way. Craig: [0:58] Did I say it right? Nik: [0:59] You did. “Nik Molnar,” you got it. I live in New York City. I’ve been there for about eight years, now. I’ve been doing Web development for 18 years. [1:09] It’s really all I’ve ever done with my life. I work for Redgate Software, working on Web performance tooling. I work on an open source tool, called Glimpse. I travel around the conference circuit in America and abroad espousing the virtues of Web performance. Craig: [1:23] Awesome. That’s a great topic. When you give your talks, how do you like to talk about Web performance? Do you have a way you can break it down? It’s a big topic. Nik: [1:32] I do. It’s a big topic. I break it down in order of descending granularity, which I tell the people in my audience and the people that I work with when I consult, that you really want to focus on the biggest problems first. All too often, a developer might be comfortable in JavaScript or PHP, so that’s the thing that they dive into, when it’s not necessarily the thing that their users are having frustration with. [1:56] Descending granularity means figure out where the pain points the app and the user are having, and focus on those first. With that blanket statement usually, moving things across the network are the biggest problems for performance. That’s usually where I start. Then, I break it down into three other areas after that. [2:15] With Web applications, I like to think of the way we interact with the Web in two phases. The first time you type the URL into the location bar and you hit enter, you’re “installing an application.” [2:29] This is the installation phase. We think of that as the on- load thing. After that, the user is using the application. They’re not necessarily going back to the server to get any more data or resources. Performance for the install experience and the usage experience, you handle those two things differently. That’s how I break it up into those two areas with two subsets underneath each. Craig: [2:53] I like that. Let’s talk a little bit more about the network area. I read “High Performance Websites” by Steve Souders. I believe it is, years ago and used YSlow and stuff like that. I think I’m falling a little out of touch with that sort of thing. How do you recommend to clients take a look at network type issues now? Nik: [3:11] Steve two books are still seminal. He recognized this was the biggest area of challenge for users. That’s what he focused on. All his rules really still apply, the standard stuff. I mean if I combine files, reduce HTTP requests, et cetera, et cetera. Nowadays with the tooling that we have, we really starting to even think about more low level of stuff, for example, TCP Slow-Start and how you optimize the content you send down to the user, the size of it, and how many packets it’s taking up because TCP doesn’t run at full bandwidth to begin with. Craig: [3:46] OK. So what is TCP Slow-Start mean? You threw me a little on that one. That’s a new one for me. Nik: [3:50] When the user agent, when the browser makes the connection to the server and the server going to start sending content down, it has no clue what the connection conditions are between the server and the client. It basically makes an assumption that it’s in a really bad state and it will send out X number of packets, some low number of packets, maybe it’s one maybe it’s ten, but a lower number of packets. [4:10] It will send those out out, let’s just say it’s one to make the example easier on the air. It will send out that one packet and then wait. Even if it has more data ready to send, it doesn’t know if that packet made it to the client. It waits until the client receives it and sends back an acknowledgment and says, “OK. Hey, that worked out well. I’ll send out two.” [4:28] Then, it waits until it gets an acknowledgment, and so on and so forth to the four to eight and up. You can think of the bandwidth as being increased over time, so it’s really important to get basically the above-the-fold content, or as much of it as you can, into that first packet because you have to wait an additional round trip and all of the latency on that round trip to start getting more data. Craig: [4:51] Interesting. What are some tactics? I think you started to get into it there. I’ve even see some new plug-ins that people are taking the CSS that might be above the fold and pulling it — just that part of the CSS — into the page and the header, so that the rendering experience is good. What else do you see? Those kinds of things? Nik: [5:09] Those are the kinds of things that you see the most. I see people, who aren’t going to be able to get the full experience in. They have too much data. They’ll flush the HTTP response early. That does a lot of additional things that are really nice, but it is also warming up the TCP Slow-Start. [5:24] How many websites do you go to where the header of the website is basically the same from page to page? While the server is rendering the rest of the HTML or doing whatever work it needs to, it can send that stuff down and warm up the connection to get to a fatter bandwidth for when the rest of the content is ready. You can send that all down. [5:41] People do stuff like that, I mean GU CSS they have these grunt and gulp plug-ins that will analyze your page and tell you what CSS you should in-line. It’s funny because we learn these rules of thumb in general, in all of software development. This is the way things should be done. Normalize data in your database, but then, when you get to the extreme of performance, no, you throw those rules out the window. Nobody is serving up normalized data. They de-normalize it, so it can be accessed and served quickly. I feel like this is one of those things. Craig: [6:08] One of those things, yes. What are some plug-ins? You said UCSS, is that what is called? Nik: [6:11] Yes, there is one called UCSS that is popular. Craig: [6:15] It will analyze your CSS and pull just the portion that’s needed for the above-the-fold content into the header of the page? Nik: [6:22] Yeah. None of them work perfectly. [6:25] You can look at the results of it and see what it’s telling you to do, but you have to use some common sense. Maybe, you have some JavaScript that’s changing something that it doesn’t know. If you go to perf-tooling.today, they have a tool section. There’s a ton of tools, but there’s probably four or five similar things like UCSS that go through and identify these kinds of styles that are important. Craig: [6:47] What’s that your URL again? I’ll put it in the show notes. Nik: [6:48] Perf-tooling.today. One of these new TLDs. Craig: [6:53] OK. Let’s move on from the network stack then. What else do you see performance props happening in a Web application? What is our next lowest hanging fruit here? Nik: [7:04] If you are doing a public-facing app, there’s probably some server-side rendering of HTML happening. Because the browser doesn’t really know what to do until it receives the HTML, that becomes the bottleneck. When you hit the URL, the browser is installing that application for you. It needs a manifest of all of the assets, the JavaScript, the files, the CSS, the images and … . That manifest we call HTML. It’s just a bunch of instructions of “here’s all of the other things that you need to do.” [7:34] If we are waiting on the server to generate that, that is a problem. Typically, the reason why we wait on a server is because the CPU is busy. The biggest offenders of that are out of process calls, going to the database, going to the third-party services to gather that data. Those things are slow. What we want to do is to get them, when we have to and then cache them locally in memory as close to the server as possible, so we can serve it quickly. Craig: [7:59] That’s great. I really like that analogy of the HTML as a manifest, though. It is, when you think about it all, whatever the script tags you have in there and the page comes down. Then, it realizes, here’s what actually I need in order to do my job. Nik: [8:10] Yeah. It’s a honey-do list. It’s what my wife is going to hand me, when I get home from this conference. Craig: [8:13] Right. [8:13] [laughter] Nik: [8:15] Go all do the other things. Craig: [8:15] It’s probably the same case for me. All right, so you say, “out of process calls” are usually what? Is the bottleneck on the server? Is that the wording you’re using? Nik: [8:25] You know, if we are just doing CPU-bound work, it can be expensive and bad, but most of the apps that were built on the Web aren’t right there. They’re kind of crud apps for showing some data. That’s easy. It’s getting the data and going out of process to get that is hard. Craig: [8:38] Tactics people commonly use are to throw a caching layer in there and so maybe they are not going all the way back to the database. What else do you see? That maybe the big one. Nik: [8:47] Caching is definitely the big one. The other thing that I see is maybe they’ll write it to the file system, so maybe that’s closer. Then, they will read that file. Some config file, CSB file or batch file that you got from some customer or something. You’ll read that into memory, but you’ll thrash your memory space and a lot of Web services don’t like their memory space being thrashed. They’ll reset. You’ll lose all your cache. You’ll localize, so you have to restart. Streaming files end and reading them that way, so using streaming APIs are much better than reading it all into memory and then throwing it away, when you are done with it. [indecipherable 9:22] plus memory thrashing. Craig: [9:21] Interesting. You work on a back end tool though. You work in asp.net space for years in NBC and there’s a tool called Glimpse. Do you want to talk about that a little bit? That helps with this back end issues, I believe. Nik: [9:35] Yeah, exactly. You install Glimpse on an asp.net website and it keeps track of these out of process calls that are being made, as well as various aspects of the framework. Most asp.net developers are using an NBC framework. There’s a model of you and the controller. We increment how long it takes for the controller to execute, how long it takes the view to execute, how long does it take for every database query to execute. Then, when the page renders in the browser, we inject a little widget with JavasScript, right into the bottom of the page. [10:05] You can see for the request that you just made, that link that you just clicked on, the three database queries, it took this long to render the view, et cetera, et cetera. You can start to compare and contrast pages and see which ones are fast and slow and where that bottleneck is coming from. We’ll focus on that method and approve the code there. Craig: [10:22] OK. How could someone hook that up in any speed in an asp.net application? How do they get it installed and set up? Nik: [10:30] In .NET, we have a package management system very similar to NPM that we call NuGet. All you have to do is go into your project and NuGet installs Glimpse.mvc5 or whatever version of MVC you are using, four or three, and that’s it. It will make a change to your configuration file for you. It will drop down the assemblies that are necessary and when you deploy, you’re running. It’s that simple. Craig: [10:51] Is this an open source project? I know you work at Redgate. Is it an open source project? Nik: [10:57] Yup. Redgate sponsors Anthony and I to work. Anthony is my partner. Redgate sponsors us to work on Glimpse full-time, and it is open-source available at github.com/glimpse. It’s where the organization is. You can find all this information on our main website, including videos to see how it works and how to use it, at getglimpse.com. Craig: [11:15] Cool, cool. What’s our next level of things we should look at, when we’re talking about Web performance here? Nik: [11:21] When we talked about the manifest file and the installation experience of the website. Once it’s installed, then end-user needs to use the website. Now, we’re no longer are talking about what the CPU on the server is doing, but we think about what the CPU and the GPU on the client is doing. We think about JavaScript. We think about CSS, and how efficient we’re being with those things. [11:43] The truly interesting thing is the same kind of tooling that you would use on the server, a CPU profiler like the one that my company makes, and the CPU profiler that’s built into all the developer tools is basically the same thing. You open up the dev tools, you go to the profiler tab, you run that CPU profile, it will keep track of how taxed the CPU is at any given time, and then show you what the call stack was when the CPU was taxed. [12:07] You can see what methods are taking a lot of time and which ones are running rather quickly, and prioritize and fix the ones that are slowest first, obviously. Craig: [12:14] OK. There’s snapshots in there? Usually, I have to get used to that. Nik: [12:18] Yeah. Snapshots are for memory profiling. Craig: [12:21] I’ve got you. Nik: [12:22] Memory profiling and CPU profiling are generally two different concerns. You can have memory problems and be fast, and you can have memory problems and be slow, so it really depends on what your app is doing. I tend to work on a lot of business-y apps or e-commerce, things like that, we don’t really have long-lived pages, so we don’t really run into very many memory problems. [12:43] If you’re working on something like Gmail or a game or something maybe like the Slack client, that you expect to be in the browser for a long time, memory management becomes much more important. Craig: [12:53] I get what you’re saying. In my area of focus with these jobs with NEC frameworks, that’s why I’m always thinking about the memory profiling because it’s very easy for that single page to live for hours or days on end, and then, you might want to take snapshots of your memory. [13:08] But you’re saying it in the traditional server-side Web application, which I think the majority of people are still building here, is that the CPU rendering is really the thing you want to look at next. Nik: [13:18] Yeah, that’s going to be what’s really affecting the speed, how snappy the application feels to the user. They might have sufficient memory. I’m not saying that it doesn’t matter. Because what happens with memory is that you get memory pressure, and then the garbage collector starts to run, and that will cause CPU problems. [13:35] You don’t want that to happen, but you might be in a state, where the garbage collector is not running and so you need to look at your own code to see what’s slow. Craig: [13:42] What are some common things that you see or re-factorings, things that people might be able to improve on that they end up doing when they look at that CPU? It seems like it’s a pretty generic statement, “Well, you’ve got problems with JavaScript code.” What do you see people doing to fix those issues? Is that a tough one because it’s all kinds of things all over the board? Nik: [14:03] There are certain things that are just bad practice in general that you should avoid. Managing your scope appropriately, knowing when to use the VAR keyword and when not to, making sure that you’re only closing over the data that you need. Because with the way that scoping works in JavaScript, when you create a closure, you are adding another level of that scoping, so that can slow down accessing that memory. That’s obviously bad. [14:30] Just being diligent about those kinds of things, they’re just things you probably should never do. That in JavaScript is the “with” keyword. It’s just syntactic sugar, it makes it easier for me to type out and change a bunch of properties on an object. I can do a little more typing and not allocate a new scope the variables are stored in. The “with” keyword basically, in my opinion, should never be used, just throw it out. Craig: [14:53] Right. Really, we’re talking about, hey, look up JavaScript performance in general. Just pay attention to good JavaScript coding practices and a lot of these issues will go out the window. Look at what you’re doing versus what people are saying or go to JavaScript coding practice. Nik: [15:06] It will be that or it will be bust out your out your algorithms textbook or go watch the MIT course that’s for free online and understand the algorithms that you’re using. See if there’s a way that you can do what you’re trying to do more quickly. Maybe you’re looping over something and you’re getting nlogin and you could do login or whatever it would be to make that algorithm faster, but that’s super specific to your data structures and to your application. [15:35] The other thing that usually people have problems with is when they start reading or writing from the DOM. That’s really slow. Actually, it’s funny if you look at recommendations, in general, how to write faster JavaScript, they’ll tell you to avoid the DOM, which I think is pretty stupid. [15:51] The reason why I write JavaScript 90 percent of the time is to get input and to show output to the user and that’s all with the DOM. I think that that’s oversimplified advice. The reality is we need to understand how accessing and writing to the DOM affects performance and the ripple effect that that causes in all the different browser sub-engines like the layout engine and the rendering engine, and when we change the size of a div on a screen what it could do unto the whole kit and caboodle. Craig: [16:21] Can you talk a little bit more about that? I hear more and more, I think, when I first think heard about ReactJS that was the first time I heard people talking about how many frames per second we could render in. It was a new world to me at that time, but you hear about it more and more. [16:38] I think the famo.us framework is doing some sort of revolutionary things in the space. I think a lot of developers need to understand that better, how to read that stuff, how to look at it, make sense of it. Can you them give any advice there? Nik: [16:51] I’m on the same boat as you. I never really played video games growing up. In college, my roommate would be like, “Oh. I have the new Max Payne and I’m getting blah blah frames per second.” I don’t get that. Duck Hunt didn’t have frames a second. I didn’t worry about it. Craig: [laughs] [17:03] Nik: [17:04] The tooling and the browsers is now exposing this data to us, so it’s the first time that we can think about it. Basically, what it boils down to is the hardware and our screens. My laptop, your laptop, our phones, all of these things typically run at 60 hertz. [17:21] Of all that pixels on that screen are refreshed 60 times a second. If we take 60 times a second is a thousand milliseconds. We do the division and that comes out about 16.6 milliseconds in between screen refreshes. If we’re changing the screen and we’re animating something in JavaScript, CSS or resizing something, or whatever is that we’re doing, even if we’re just replacing text or it’s only an animation, we need to do that work, and all the ripple effects that I’m talking about, within that 16-ish millisecond buffer, otherwise the browser will drop a frame. [18:03] It will say, “You’re not ready for me to paint yet, I’m going to wait.” It can’t kind just pick up, when your work is done. This is v-synched hardware stuck. It’s going to run at that tempo of 16 milliseconds over and over again. [18:18] When we hear about dropped frames or my frame rate is low, it’s because our work is taking too long and the browsers is not ready to paint yet. Craig: [18:24] What happens the browser just chooses not to repaint and the user gets an unresponsive experience on that quick phone? Nik: [18:30] Exactly. We should probably be using the request animation frame API, which is an API that takes in a callback and essentially tells you, the Web developer, “I just finish painting a frame. Go do work.” We use that API to get the most amount of budget possible to get that as much of that 16 milliseconds as possible. [18:51] We could just wait around for a user to click on a button, but none of my users click on buttons in 16 milliseconds intervals. I click right in the middle and now I only have 8 milliseconds. I’m losing part of my budget. Request animation frame, let’s say that is giving us the full 16 milliseconds, but my work takes 18 milliseconds. [19:11] We come back around at the end of the first 16 milliseconds. I saw two milliseconds worth of work left to do. The browser says, “OK, I’ll wait.” My two milliseconds goes by, I finish. We have 14 milliseconds that we’re waiting with nothing happening. Our work is done, but the browser has to cycle back around to be able to do that paint. That doesn’t to sound too bad, when you are talking about maybe14 milliseconds. If you’re talking about dropping two or three frames, and now users can start to notice these things, it becomes very bad. [19:42] We get a phenomenon known as jank. I’ll call it “janky.” You can really see it on underpowered devices like your mobile phone. Particularly, you will notice it if you are scrolling, and you put your finger down on the screen, and you kind of scroll from the top to bottom, and the pixel right underneath your finger doesn’t stick to it. [19:59] You’re like, your finger get’s down to the bottom and then that pixel kind of catches up after it and it’s stutter-y. That’s jank. You are dropping frames, and that happens when you are scrolling and animating it, and things like that. Craig: [20:09] Interesting. That’s the best explanation I’ve heard of that. I’m glad you offered that. Anything else we should cover? Anything else that you want to talk about? Nik: [20:18] I’ll mention something with CSS. The dev tools now will allow you to go in to a time line mode. Where you can turn on the page and start scrolling the page, let some animation run or do whatever the work is that the page needs to do visually. It will show you all of the frames that it painted with a bar chart and how long each one of those frames took. [20:40] You can see if you’re hitting that 16 millisecond number and getting 60 frames a second or not. 60 frames a second, anything better than that, we don’t really perceive. That’s like smooth as butter. That’s the experience that everyone is shooting for. [20:53] Because I said there is this ripple effect, if I manipulate something on a dime, I am just going to do something simple, and change the size of a div, because I’ve done that, the layout engine in the browser, that calculates the geometry, calculates the skeleton of the page, figures out where all the boxes go, they have to recalculate the page. Because I moved that div, that might have wrapped something, a float might have been broken, or the whole page could change because I made something five pixels wider. It has to recalculate all of that, and once it’s recalculated everything, it has to repaint the whole page. [21:24] My simple little JavaScript change of making a div five pixels larger could take 40, 50, 60 milliseconds because of all this corresponding work. These browser tools that show you these bar charts, tell you where that time was spent, which is really handy. What it comes down to is, depending on what properties that you are changing — I mentioned width, that was my example — with this one, it is the box model properties. All of the box model properties will affect the layout engine. Anytime that you affect the layout engine, the paint engine has to clean up afterward. Layout is always followed by paint. [21:59] Some properties like, color, that doesn’t affect layout at all. You can skip that whole step there and go straight to painting and changing the color. That’s theoretically. It could be more performing. You have to test them, every site. Some jank-free properties like, opacity, and these are specifically handled by the GPU. They go straight to the compositing layer, which is a third and final layer. [22:23] I want to mention a website called csstriggers.com, which shows for every CSS property, which subcomponents of the browser will be affected. It’s like, I’m moving a lot of things around. I’m using widths or heights or whatever. You’ll see, “Oh yeah, I’m thrashing the layout.” Craig: [22:41] Interesting. csstriggers.com. Nik: [22:45] I know this is all hard to talk about and visualize on a podcast. I actually, do a presentation at conferences called, Full Sec Web Performance. It is a blitz of an hour where I cover all of this, and showing a lot of demos. It is very demo driven, and so that’s available online. I can provide that URL. [23:01] That’s on my blog at nikcodes.com, and that might be a place to watch and get started with all of this stuff. It’s also on that Perf-Tooling today, the video is there, as well. Craig: [23:09] OK, so, nikcodes.com is where we can find all this stuff. Nik: [23:12] Yeah, at N-I-K-codes.com Craig: [23:14] N-i-k, yes, now that’s right. No one will get that right the first time, now that you’ve said that. Nik: [23:18] No, no, they won’t. Craig: [23:19] Yeah, come check out the show notes, and you’ll get that URL, if you are in the car listening to this or something like that. Thanks for coming on the show today Nik. It was a great talk. Nik: [23:27] Thanks, for having me. I really appreciate it. [23:28] [music] Craig: [23:31] Thanks for listening to the Front-End Developer Podcast. Please subscribe to the Podcast by going to the iTunes store on your phone or desktop and then, searching for Front-End, or via RSS by going to frontendcast.com where you’ll also find show notes and a full transcript of each episode. [23:45] You can also sign up for my free AngularJS, Backbone and Ember crash course. All of them solve the same problems, so why not learn them together? See you next time. The post Web Application Performance with Nik Molnar | Episode 10 appeared first on Funny Ant.
May 15, 2015
On this episode Cory House and I discuss the exciting new Web Components standard including the Shadow DOM, templates, custom elements, and imports. Tweet To subscribe to the podcast, please use the links below: Click Here to Subscribe via iTunes Click Here to Subscribe via RSS (non-iTunes feed) Show Notes: Resources WebComponents.org a place to discuss and evolve web component best-practices HTML5 Web Component Fundamentals Pluralsight Course by Cory Polymer HTML5 Video tag Full Transcript Craig McKeachie: [0:00] On this episode Cory House and I discuss the exciting new Web Components standard including the Shadow DOM, templates, custom elements, and imports. [0:09] [music] [0:20] Welcome to the “The Front End Developer Cast,” the podcast that helps developers be awesome at building ambitious web applications. Whether you are a JavaScript Ninja or just getting started. I’m your host Craig McKeachie. [0:30] Hi everyone. My interview today is with Cory House, let’s get right into it. Hi, today I’m here at CodeMash, I’m lucky to have Cory House here with me. Cory is a Microsoft MVP, C# an ASP Insider, Outlier developer, expert, you may have been to his blog at bitnative.com. Cory, welcome to the show. Cory House: [0:52] Thanks for having me. Glad to be here. Craig: [0:55] Anything else I missed there about yourself? Cory: [0:56] Oh, no. That’s sounds like enough platitude, sir. I can live with that. Craig: [1:00] Great. You may have done some of Cory’s training on the Pluralsight, as well, if you have Pluralsight subscription. He has several courses out there. What are some of the courses about? I forget. Cory: [1:10] There’s a course on clean code, called “Writing Code for Humans.” I have one on “Real World Architecture and Dot Net,” which is about being more pragmatic and comparing really simple to more complex, and when each makes sense. [1:23] Then, I have an odd one called, “Becoming an Outlier,” which is about creating an exceptional career in software development, really setting yourself apart. Craig: [1:30] I’ve seen your talk on that, here at Cobasa, last year, a really good talk, a packed room. People were sitting all over the floor and everything like that. Cory: [1:38] It’s a great problem to have. That was a lot of fun. Craig: [1:41] Speaking of that, today, I have you on the show to talk about web components. I went to your web components talk, this year, and the same problem. The room was very crowded. We were talking about it’s a great future technology, but I didn’t think that many people would be ready for it. Cory: [1:58] Yeah, and frankly neither did I. It’s wonderful to see. I’m excited about it, and that’s why I’m speaking about it. I feel like, as a web developer, this is as big a story as anything that’s happened, probably since Ajax. [2:11] This could, fundamentally, change the way that we compose and build our applications, and, finally, take all this fragmentation that we’re seeing, and get us all on a nice standardized, more reusable path. It’d be wonderful to see this all play out as well as it appears like it might. Craig: [2:28] Exactly. Let’s backtrack a little bit, and talk about what are web components. For the people who’ve maybe seen an article or two online, let’s unpeel that a little bit. Cory: [2:39] The easiest way to think about web components is, you’re probably writing components today, somehow. Maybe you’re using jQuery UI, and using MIME as a starting point. Maybe you’re using Angular and their directives. [2:51] Maybe you’re using Knockout and their components, Ember and their components. I could go on. There are all these different ways to write these little reusable pieces that we slap into our web application. [3:01] Wouldn’t it will be nice if we had a standardized way to do so and that is what it should…Components are about and the standard defines 400 technologies that all work together. [3:12] To give us reusable components. We have templates we have HTML5 imports have the Shadow DOM and we have a fourth that I am forgetting. Offhand, which is… Craig: [3:27] The pieces of imports Shadow DOM, HTML5… Cory: [3:29] Of course custom elements. Craig: [3:30] Custom elements? Cory: [3:31] Yes, which is maybe the most important because Custom elements are something, that lot of people are already doing today… Craig: [3:40] Each one of those if you don’t mind, which one you want to tackle first… Cory: [3:42] Lets talk about Custom elements, because this is a story that lot of people are doing now, angular directives are interesting, at least in one piece. Because now we end up solving the DIV soup that we see in our code…Are reusable pieces of logic is that now when we look at our source code. [4:00] Its more semantic. It describes what inside a lot better than all these DIVs that we see every ware. All the source code…Source almost any web application, and all you see is DIV, DIV, DIV, DIV, DIV…It is clear that our current market is doing a great job of letting us describe what is inside. [4:22] DIV is a generic container and it’s useful but it’s, it should be used as a last resort, if we had something more descriptive, that would be preferable. That what custom elements are all about. Instead of waiting around for standards bodies to continue to add new semantic tags. [4:39] We can do that whenever we want to now, and not just that, we go well beyond because maybe for instance, I have some data structure that is really useful just for my app, just for me. Why don’t create a tag just for that? [4:54] Maybe, I’m creating a component for Pluralsight website site and I could create a Pluralsight-component tag and in time I put that on the page, then this component renders out the whole comment form, verything I need right there I can configure it. [5:09] It gives a lot of power and does not require anybody to write a lot of code once it is done you put on the page like any other HTML tag. Craig: [5:16] I could picture you while talking about so I can read what you are saying so instead of DIV soup may be a tab tag with the represent of DIV, possible to UL’s might have the real world. You might be able to throat tab tag on there with tab inside of it or something… Cory: [5:34] The contrast tabs in the New World could literally have a tab tag, although to back up a bit, you have to hyphen in it, that part of the rules for custom elements, they have to have a hyphen in the name, but you could call it whatever you like. [5:49] Maybe if we’re creating a tabbing structure for Pluralsight, it would be Pluralsight-tabs and then that would have its own mark- up inside. The beauty of that is now it’s really conveying what’s inside and makes your mark-up easier to read and you have this nice reasonable component. Craig: [6:05] Why do you think they put the hyphens in there? I can guess, but I was curious what you thought. Cory: [6:09] The hyphens are a really big deal because they are a message to the browser, that says hey this is a custom element, so treat it differently. Without a hyphen, then it is considered an unknown element, so the browser treats that differently. We probably won’t have time to get into the details here. [6:26] But there’s styling that goes on and some new selectors that end up paying attention to any tags that contain a hyphen in it. This is all part of the standard, so that hyphen tells the browser a lot of important things about how it should treat that tag. Craig: [6:41] That’s interesting that you explain it that way because I was thinking well they probably they did so they made sure people named things with a namespace and accordingly. This also gives the browser a big advantage, in terms of processing. Cory: [6:54] It does. It’s also a future proofing scenario because, as you know, no HTML tags today have hyphens in them and there’s no plans to do so in the future. This assures that as new HTML tags come out they’re not going to collide with any of your custom elements. Craig: [7:09] Not to belabor this too much more, but did you say you could have a tag that doesn’t have a hyphen that’s a base tag for other tags in your talk or is that not? Do they all need hyphens, like if you’re inheriting from something? Cory: [7:20] There we go, yeah. You can extend native elements. I create a super button, for instance the way that I would instantiate that once it is created would be to put in a regular button tag and then use the is attribute. [7:32] The value for that attribute could be super button, if that’s what I decided to call it, for instance. That’s a way to take the native behavior, native semantics of a button tag, for instance, and then add extra things to it. [7:44] Maybe, my super button would always alert the browser and do something really annoying. Who knows what you can do with it? The point is taking that basic behavior and extending it. Craig: [7:57] Which ones tackle on Shadow DOM, good candidate or is… Cory: [8:00] …I love the Shadow DOM. It sounds mysterious. I feel like we should hide it behind a little bit more, keep them in suspense. Craig: [8:06] I remember you talking about the light versus the dark DOM. I love that. Tell me people about that. Cory: [8:12] That’s hard because the DOM that we know today, now we need to refer to as the light DOM because we have this new concept called the Shadow DOM. When we’re working with custom elements and we’re working with HTML5 web components. [8:27] The Shadow DOM encapsulates a DOM subtree and that sounds pretty jargony. Effectively, it is this way to encapsulate and namespace a section of your DOM to keep the concerns separated from the rest of the page. What’s awesome about this is once you get this chunk of mark-up encapsulated. [8:51] Then you can do things like style it in a really simple way. For instance, if this web component had an h1 tag in it, I could style it and say this h1, I want it to have a size of X, size 14 point. Any other h1 tags on the page wouldn’t be impacted by that because it’s encapsulated within this Shadow DOM. [9:13] Each Shadow DOM has its own scope, so it’s not impacting others along the way. This is a beautiful thing because you think about all the places that you write really specific selectors trying to avoid colliding with someone else and now that we have this encapsulation, it’s beautiful. [9:30] Now, everything gets really simple because I need to write the selector to do what I want here and I don’t have to worry about the rest of the page and the implications. Craig: [9:38] If I take a component that someone’s written or web component someone’s written, I put it into a page. It could be in the middle of quite a mess of CSS and it won’t get stomped on, unless I’ve specifically gone to that level of specificity in my selector. [9:55] The new set of selectors I noticed you talked about and I was excited about that because a lot of people explain the allure of oh gosh this thing’s encapsulated. [10:05] That’s awesome, but I’m like wait I want to style that to be consistent with my website. I’m glad it’s encapsulated, but can I get in there? That’s what I’m wondering. Cory: [10:16] Yeah. That’s what surprised me because I looked at the Shadow DOM as this vault. There was no way. It was heavily protected and no one else would get to it. Then, I came to realize well that’s not the case. [10:28] The way the Shadow DOM works is you can always pierce the Shadow DOM using certain selectors and so there’s a new set of CSS selectors, which are hard to describe over audio. There is the deep selector, which lets you traverse any level of shadow roots and provide styles. [10:46] There’s another way that you can define a pseudo selector and then define styles for that first level of Shadow DOM. [10:54] What I am getting at is that you can nest Shadow DOMs and then decide whether you want to hit the first one or hit all of those nested Shadow DOMs. There is a lot of complexity here. Craig: [11:03] When you were talking about that, it reminded me of your demo that you said “If this demo doesn’t blow your mind, you might as well leave because this is the best I have got,” which got quite a response from the crowd Cory: [laughs] [11:14] Craig: [11:16] Talk about that demo. That is useful for people. Cory: [11:17] What was interesting is the Shadow DOM is there today. We are all using it and we don’t even know it. Browser vendors have been using this tactic for quite a while now. If you have used a video tag or you have used input with a type of date, those use a Shadow DOM behind the scenes. [11:33] What I showed in the session is if you instantiate a video tag and then you inspect it using Chrome developer tools, at first all you are going to see is the video tag. But you can go into Settings and you can tell Chrome “Hey, show the Shadow DOM to me.” [11:48] Once you do that all of a sudden you can expand and see all of the mark-up that creates that video tag. You can see all the DIVs that sit inside it. It is still… Craig: [laughs] [11:58] The DIVs are back. Cory: [11:59] Yeah, the DIVs are back. We are not losing the DIVs, it is we are encapsulating them. That is pretty cool because now the mark -up reads really clean and all that complexity is hidden away for the author of the component. That is powerful. [12:14] What you also see is within that video tag that the video tag references an input with a type of range which also has its own Shadow DOM inside. That is where we are nesting components and we are nesting shadow roots and they each have their own separate scoping. Craig: [12:31] Yeah, that is very insightful to know that components with a Shadow DOM can be nested inside of each other. I train on Angular a lot and people write directives. [12:41] It is interesting when people realize their directives can get a lot simpler if they use other Angular directives inside their directives. It is the same thing, position story. Cory: [12:50] Yeah. Craig: [12:51] That is great. Let’s talk about imports. How about that? Cory: [12:54] OK. Imports are awesome because they wrap this whole story up. They give us an easy way to deliver components. Remember when we are writing components they are HTML, JavaScript and CSS, same old tactic we have been using all along. We have some new APIs to define all of this. [13:09] What happens right now is, say you want to create a component and use bootstrap, you are going to end up using about five different things. You are going to need to reference JQuery, reference Bootstrap. You’ll need to reference your own CSS and your own JavaScript. [13:25] You’ll have to get those in the right order, too. Order does matter. Scripts are parsed from top to bottom. What happens today is that people are very specific about their documentation, saying “OK, here is how you use this ad hoc component that I created.” [13:42] This is often the case with, say, a JQuery plugin, for instance. The same thing often happens in a proprietary way with what…UI or JQuery UI, Ext JS, whatever it may be. The beauty of HTML5 imports is you say on a single line, “I want to import this HTML file.” [14:00] That HTML file contains all that complexity. That HTML file can have all the different script references that are necessary. It can have the different links to the style sheets that are required. All of that is in a nice little bundle. Craig: [14:13] That is awesome, to bring a component in, one import and then declare the tag, is your story. Cory: [14:19] Yeah, it is beautiful, nice and declarative and you can look at the top of your file and see what you are using. Craig: [14:26] I don’t know about you but in the past, when I have to bring in a JQuery UI component I am like “Well, how do I want to do the folder structure,” and spending a half an hour trying to decide where I want to put things and my file structure and stuff. This is nice. Cory: [14:37] Sure. Craig: [14:37] You put that one file somewhere and you are good to go. Cory: [14:40] Exactly. I am interested to see how many people embrace Bower when they are working with web components because Bower is really handy as a package manager for the web and pulling this stuff down. Bower helps make the process of getting the assets better. [14:57] But it still doesn’t answer that question of me adding the references in the page. That is where HTML5 imports will be really handy. Yes, use Bower to get it. But then when you reference it, the nice thing is it will be a single line in your HTML. Craig: [15:10] Right. Haven’t you heard? Bower is out now. [laughs] Cory: [laughs] [15:12] Oh no. It wouldn’t surprise me. Craig: [laughs] [15:15] Honestly, I have heard some people putting things in MPM. But we all know the downside to that. We could talk about it. I thought that was funny because… Cory: [15:23] We could now have a rabbit trail here in this conversation. I agree… Craig: [15:26] We should not go there. [laughs] What do we got left here, templates? Is that what I remember now? Cory: [15:32] Templates is the final piece. Templates are really interesting because today we get this done, but we get it done in, again, proprietary ways. That seems to be the theme with our conversation today. We are going “Yes, what we are doing today works. [15:45] But the standards-based way would be really nice to get in the future.” Templates are utilizing a new tag, which, not surprisingly, is the template tag. Anything you put within the template tag is inert. That means it doesn’t run at all. You don’t see anything there. [16:02] I could put some JavaScript inside and say alert, and you would not see that alert run. Nothing would happen. I could put mark-up inside, put images inside and you wouldn’t see anything on the page. It is sitting there waiting to be utilized, waiting to be… Craig: [16:16] It is like going back to high school chemistry here, it is inert. You used the word, I-N-E-R-T. Cory: [laughs] [16:20] Yes. Craig: [16:21] I am trying to clarify here. Cory: [16:21] That is correct. Craig: [16:22] That is awesome, that is awesome. That is a great way to describe it. Yeah, I saw that in your demo. You put a script tag in there, it doesn’t run. Cory: [16:29] Yeah. Craig: [16:30] Which is a security measure, I assume, right? Cory: [16:31] It is not just a security measure. To me, it is semantically what you would expect. If it is called a template then I wouldn’t want it to ever render to the page by default. I want to write some code that utilizes it as a resource. It is a resource sitting there. [16:49] Today we do this. We will slap some mark-up within a script tag. Or we will take a DIV and we will style it off the page or set its display to none and then we will strip that mark-up out at some point and put it on the page. [17:01] That works. In fact, a lot of the frameworks that are pretty popular today use some similar approaches, hiding things in comments, whatever it may be. It does work. But the nice thing about templates is the browser is finally giving us this standards based way to say “Hey, don’t display this.” Craig: [17:18] Right. Cory: [17:19] Semantically it makes a lot of sense, too. Now when I read the mark-up it is really clear. Craig: [17:23] Right. Of all the things people are debating about with JavaScript NEC frameworks, one thing they are not debating about is “We need templating and we need templates,” right? Cory: [17:31] Yes. Craig: [17:31] This is a clearly established thing. Cory: [17:34] For sure. Craig: [17:34] Like components. Talk about can we use these today, browser compatibility and so forth. Cory: [17:43] This is where things get serious. Craig: [laughs] [17:44] Cory: [17:46] If you are lucky enough to be supporting only Chrome and Opera then all of this that we have discussed you can use today. The standards are set and they are supported in those browsers. Firefox still has some issues. But it looks like it won’t be very long until it is on the bandwagon, too. Craig: [18:02] OK. Cory: [18:03] The sad story, drumroll please, is IE. It is going to take some time. IE, at the moment, it looks as though what we are discussing may not make IE 12. Craig: [18:14] That is surprising, isn’t it? Cory: [18:15] Yeah. Craig: [18:17] Shocking. Cory: [18:17] It is coming. It looks like, if you look out on IE’s site, they have more or less committed to adding these features. There has been a huge number of votes. Everybody is really excited about HTML5s web components based on the feedback that we are seeing out on forums. [18:31] And people voting for new features in IE. I would be very surprised if it is not added in, if not IE 12, perhaps there is some an update to it. That is my best guess at the moment. [18:43] That said, you don’t have to have native support. There are poly-fills out here that give you the goodness of a lot of what we have described. Webcomponents.js is the name of the poly-fill. I believe it rolls back to IE 10. Craig: [18:56] OK. Cory: [18:57] It gives you most of the goodness that we talk about here with some interesting quirks. If you’re familiar with “Polymer,” that’s a project from Google that was formerly the poly-filling library of choice but now. [19:12] They’ve taken the poly-fill piece and they’ve pulled it out and called it, “webcomponent.js.” It’s a separate project now. Anybody can use it. You don’t need to use Polymer to enjoy it. That is the story if you want to do so. [19:24] The real question is, “Given where we are right now, does it make sense to use that over all this other really popular options like Knockout, Ember, Angular and Backbone?” That’s a really tough call. [19:38] To me, even as somebody that’s really excited about this right now, I would probably lean toward one of those because they are great frameworks that work today across browser. [19:46] But if you’re somebody that’s fortunate about to be able to write against Chrome or maybe you’re doing some mobile development and you only work in modern versions of the mobile browsers, then you might find that this works pretty well. [20:01] I can say off the top of my head how all the mobile browser support is at the moment. I haven’t checked that. That’s revving pretty quickly. Now, mobile is ahead of the curve of these things, so we might find that that’s the story that helps move these standards forward first. Craig: [20:14] Yeah, and we’re soon be to a world of all “evergreen” browsers. You won’t be more than a few more years until…I’m probably exaggerating by that statement but soon, we’ll have all browsers that are auto-updating and then this stuff is going to come really fast at us. Cory: [20:30] I can’t wait. Yeah, I love that. Right now, things are revving very quickly but that’s going to be a whole new level of excitement when we get there. I’m also excited to see what happens with “Spartan.” [20:39] I’m a little unclear what Microsoft is doing there. It sounds like it’s using the same engine but if we see Spartan as the default browser in Windows 10, that could really start to change things. [20:50] That could really help move people over to the full evergreen browser stack because IE is at the moment, I believe the last hold out on the whole auto-updating movement. Craig: [21:01] That’s interesting. One thing I wanted to breakdown a little bit more that was confusing me and you started to explain it there is the whole, it used to be Polymer and then I know is “X- Tags,” which is a competing thing like a healthy competition to Polymer. [21:15] But Polymer had in it some amount of code that then got pulled out into the URL’s now web… Cory: [21:22] …Webcomponents.js is the name of the poly-fill. Craig: [21:25] OK. It’s literally on a separate site now like “webcomponents.com” or something like that. Cory: [21:30] It’s out on GitHub is the project. It’s an open source project but it is, as far as I can tell, still developed primarily by Google. I don’t know if they’ve taken many poor request on the outside. Craig: [21:41] Correct me if I’m wrong here, so Polymer and X-Tags are comparable things and one is by… Cory: [21:47] …Yeah, Polymer is from Google and then X-Tag is from Mozilla. Craig: [21:51] We know good ideas come from competitions so they’re trying to create a healthy ecosystem of components in two different worlds so that the different ideas can be brought to the world. Is the idea is that? Cory: [22:03] Yeah. I would say they have two core goals. One is to make writing Web Components easier, so they take the standard and then add some syntactic sugar on top of it so that you can do some things that the standard doesn’t currently allow you to do. Craig: [22:16] What’s an example of some syntactic sugar that you’ve seen and maybe I’m getting too deep here? Cory: [22:20] One thing you can do with Polymer is you could reference external style sheet within a template. That’s not part of the standard spec but that’s something that Polymer allows you to do. [22:33] They poly-fill in that. I shouldn’t say “poly-fill” but they give you that behavior even though it’s not part of the standard. Craig: [22:38] You can also declaratively create an element with Polymer, which you can’t do with the native HTML5 specification. This is where things get a little tricky and my… [22:48] [cross-talk] Cory: [22:49] …Code when you say “declaratively,” right? Craig: [22:50] Within mark-up. Yes, I could create a tag right there within mark-up using Polymer. Cory: [22:56] Oh, interesting. Craig: [22:57] Yeah, and this can get confusing. Order of operations is really important and I recommend first thing you should is learn the standards and understand those. Once you understand those standards. [23:09] Then it will be easier to see how Polymer and X-Tag take those standards and start to add some interesting things on top of it. But if you do it in the other order, you’ll probably going to find yourself confused in the same way as if you learned jQuery and then try to learn JavaScript. Cory: [23:23] Yes, which we all did, right? Craig: [23:24] Yeah. [23:25] [laughter] Craig: [23:26] Was it common story, yeah? Cory: [23:27] Indeed. Craig: [23:29] I feel like when I went to Polymer site though, beyond the making extending Web Components, there was maybe a start of a component library there. Is that something that’s happening? Cory: [23:41] Yeah, absolutely. There are component libraries for native HTML5 Web Components out there like “Component Kitchen” and the other site slips my mind. Craig: [23:50] That’s fine. I’ll put it on the “Show Notes.” [23:52] [cross-talk] Cory: [23:53] Thank you. Also, you see Google out there and Mozilla trying to create reusable components using their libraries. There are Polymer elements. There’s the paper elements that are really interesting that Google announced a while back at “Google I/O.” [24:06] There’s a lot of unique components also from Mozilla. That’s a nice way to really showcase what you can do. They’ve done a great job of really wowing people, where you can put a simple tag on a page and get really rich behavior. Craig: [24:20] These all sounds great. Besides the fact that maybe not quite ready to use today but we should be learning about it because it’s going to change the world of web development. [24:29] What are some downsides? What are some things about Web Components that you feel like they’re still trying to figure out? Cory: [24:35] The biggest problem to me right now is if I have a bunch of component on the page and they all have third-party dependencies, things get really hairy. If people are creating their components and they depend on third-party libraries like jQuery, for instance. [24:51] And I have three different components I want to use that require different versions of jQuery, I can’t use them together. For that matter, if I tried to, then we’d end up loading three different versions of jQuery at the same time which is going to cause issues. [25:04] For the same matter, even if they used the same version, there’s this other conversation of “I need to use the exact same reference at the exact same URL.” Because if I don’t, then it’s going to end up pulling down two versions because one was from this domain and one was from this domain. [25:21] This remains to be seen how we solve this. My opinion is if you’re writing a web component that you want other people to use, eliminate the third-party dependencies. [25:30] I feel like the need for jQuery when you’re working with Web Components should be pretty minimal. You’re already working with really modern browsers that have pretty consistent APIs already set up. They honor the specifications well, so that should greatly reduce your need for third-party libraries. [25:48] If you are given the option between two components that do more or less the same thing and one of them doesn’t bring along this heavy third-party dependency, which one should you pick? It’s a pretty easy choice, right? Craig: [26:00] Right. Cory: [26:01] Then you don’t have to worry about those conflicts. That’s the biggest concern right now. Craig: [26:05] One thing I really struggle with because I’m so much in this JavaScript framework world, the Angulars and the Embers and the Backbones of the world. [26:13] I’m trying to imagine particularly with Angular and Ember with the two-way data binding and who knows what things like react, whether that will stay around but how these components are going to play within a framework like that. [26:26] I’m guessing maybe it’s going to take a new version. I know Google is working on that but I wonder what you’re thoughts are around that. Cory: [26:33] It’s interesting because you’re already seeing these frameworks trying to move more toward the standard and do little things to honor it. [26:40] If you’re familiar with Knockout components, the most recent version, when they added components, they were careful to put dashes in the component names in their examples. Now, they didn’t have to do that because it really doesn’t matter. [26:53] But it was their way of helping move people toward the standard. You’re going to see increasingly, Ember isn’t a framework that I’m particularly familiar with, but I’m seeing a lot of interest there and I’m trying to take pieces of specification and use those in Ember components. [27:11] What’s going to likely happen at some point down the road is these popular frameworks wound up being really a layer over the top of the standards. They will all honor the standard underneath but they will add their own goodness on top of that. [27:28] That’s really to some degree, that’s exactly what Polymer is doing today. It so happens that Polymer isn’t solving all of the other interesting problems that Angular does, so Angular remains the real focus and probably the most practical option that Google is offering at the moment. [27:43] It is interesting that they have both sitting side by side and I speculate that probably Angular too will end up swallowing up most of what is currently happening in Polymer and somehow morphing them together. It’s hard to have a clear picture of what that would look like right now. Craig: [28:00] I’d see it’s very difficult for me as well to rationalize that but I do think, Web Components, they’re going to be part of the standard. It’s coming so they’re going to have to play in that world, which is great. [28:13] You’ve mentioned at the end of your talk that you’re obviously very knowledgeable about this. You finished a course on “Pluralsight” about it? Cory: [28:21] Just did. It’s supposed to publish any day now and it’s called “HTML5 Web Component Fundamentals.” Craig: [28:26] If you’ve got a Pluralsight subscription, go check out that course. I’m sure it’s going to be awesome if you’ve checked out Cory’s courses before. Thanks for coming on the show today. Cory: [28:34] Thanks for having me. This was fun. [28:36] [music] Craig: [28:38] Thanks for listening of the “Front-end Developer Podcast.” Please subscribe of the podcast by going to the iTunes Store on your phone or desktop then search in for “Front-end” or via RSS by going to “frontendcast.com,” where you also find Show Notes and a full transcript of each episode. [28:52] You can also signup for my free “Angular JS, Backbone and Ember” crash course. All of them solve the same problem, so why not learn them together. See you next time. [29:02] [music] The post Web Components with Cory House | Episode 9 appeared first on Funny Ant.
Sept. 30, 2014
Jarrod Drysdale and I discuss web design tips for developers so your applications can look professional even if you don’t have the budget to hire a designer. Topics include the 20% of tips that will get you 80% of the results including alignment, spacing, colors, fonts, graphics and navigation. Tweet To subscribe to the podcast, please use the links below: Click Here to Subscribe via iTunes Click Here to Subscribe via RSS (non-iTunes feed) Show Notes: Resources Jarrod Drysdale’s Blog Jarrod’s Book Bootstrapping Design (sign up for the newsletter) Tool for creating great designs without a designer Landing page in a day Noun Project Font Awesome Glyphish Full Transcript Will be available soon. The post Web Design Tips for Developers | Episode 8 appeared first on Funny Ant.
Sept. 1, 2014
Sean Fioritto and I discuss the AngularJS learning curve and why he thinks it’s so nasty and how he goes about making it easier to learn.  We also discuss “Angular in the Enterprise” and why he thinks AngularJS is great when you are dealing with large enterprise code bases. Tweet To subscribe to the podcast, please use the links below: Click Here to Subscribe via iTunes Click Here to Subscribe via RSS (non-iTunes feed) Show Notes: Resources Sean’s Intro AngularJS Training (Escape Plan) Sean Fioritto is the author of Sketching with CSS Sean Fioritto’s Blog Full Transcript Craig McKeachie: [0:00] On this episode, Sean Fioritto and I discuss the AngularJS learning curve, and why he thinks it's so nasty. [music] Craig: [0:16] Welcome to "The Front End Developer Cast," the podcast that helps developers be awesome at building ambitious web applications, whether you're a JavaScript ninja, or you're just getting started. I'm your host, Craig McKeachie. [0:30] Hi, everyone. My interview today is with Sean Fioritto, and we discuss the AngularJS learning curve, why he thinks it's so nasty, and how he goes about making it easier to learn. [0:39] We also discuss Angular in the enterprise, and why he thinks AngularJS is great when you're dealing with large enterprise code bases. [0:46] Let's get into the interview. [0:48] Hey, today I'm lucky enough to have Sean Fioritto with me. He's the author of "Sketching with CSS," which you may have heard about throughout the Internets, and he's more recently been focused on doing some AngularJS training. That's why I wanted to have him on The Front End podcast here. Welcome Sean. Sean Fioritto: [1:05] Thanks Craig. Thanks for having me. Craig: [1:07] I also heard that you perhaps may have been lacking some sleep recently. Is that true? Sean: [1:13] Yeah. If I randomly forget words or get words mixed up in the middle of this, it's definitely sleep deprivation. We just had a kid, Isaac. He's our first. He's four weeks old yesterday. Craig: [1:26] I do remember those times, so I will try to edit out any of those parts where you forget to tie your sentences or things like that. I feel for you. Congratulations. Sean: [1:37] It's hard to keep track of anything. It feels like one blurred day since we got back from the hospital. Craig: [1:42] Well, congratulations. Sean: [1:43] Thank you. Craig: [1:45] I wish you luck in getting out of this time. [laughter] Craig: [1:48] Surviving, that may be [indecipherable 1:50] . [crosstalk] Sean: [1:50] I heard six weeks is the magic. Everybody keeps telling me six weeks it gets a little bit better. I'm just crossing my fingers and don't tell me that that's not true. Craig: [1:57] You know what I wish people would've told me? [2:00] My sons are now five and eight. My one's going to kindergarten, but long story short, I wish people would've said it does get easier because it's pretty hard when they're young and I wish somebody would've said, "Yes it's going to get easier." They all just look at me like it'll be OK. You'll get through this, but they wouldn't say it's going to easier because that's what I really wanted to hear at the time. [laughter] Craig: [2:22] I'm telling you it's going to easier. Sean: [2:24] Good. Thank you. Craig: [2:26] Anyway, we're going to talk Angular today. One thing that was interesting when we were chatting back and forth was you talked about the Angular learning curve and I was definitely concurring and remembering the early days, which wasn't so long ago for me either of learning Angular. Tell me what your experience has been like with that. Sean: [2:42] Well, in addition for it being tough for me to pick up Angular...I'm an experienced developer. I've been doing this for a really long time, and I've been doing JavaScript for six years, and working with really big, gnarly enterprise JavaScript code bases. I'm comfortable picking up new frameworks, new technologies, but Angular was particularly tough. [3:03] It's tough for everybody, it's kind of the common denominator, which, quite frankly is why I'm doing Angular training. There's so many people that...The learning curve in Angular is particularly vicious. [3:18] It would be nice if somebody bundled up the hard bits, pulled it together, made some sense of it, and cut the time down to learn it. The thing about Angular that was tough, of course, it goes to their documentation, which is better now than it was in the past. [3:35] I evaluated Angular years ago, and one of the reasons I dismissed it was, A, it was a little weird, because there was all this code in the markup. I was at a Microsoft shop, and I really hated ASPX's, and all the problems we'd had with putting a bunch of code in views. [3:52] I was like, "That's just weird. I don't want to look at it." Plus, it looked really "Microsoft-y," and I was rebelling against the Microsoft-y stuff at the time. So I thought... Craig: [4:00] Right. Sean: [4:01] I get it. Craig: [4:02] I think a lot of people were burnt by the various tags that Microsoft created, data source tags... Sean: [4:08] Yup, exactly. Craig: [4:09] It was like, "Oh, this is a good idea to put your database code in your view!" We can say we've written zero lines of code. We've written a lot of lines of markup, but zero lines of code. I think people still were stung by that and remembering, this is not a good thing, necessarily, right? Sean: [4:25] Exactly, and there was so much magic behind some of those things. It would just do surprising things, and have surprising effects down the line. You'd get something working fast and you're like...oops. And we don't know what's happening. [4:39] Worse, a lot of shops have inexperienced developers working at them, and that was...our company was no different in that respect. There was a lot of code being written without oversight, and things are getting used incorrectly. [4:54] It's real tricky when you have that...that level of abstraction is scary to me, anymore. I've always recoiled when I see something like that, and Angular was no different. [5:03] You look at that first "Hello, World!" example, and it's like, "What is that! That looks iffy." [laughter] Sean: [5:10] It's not like that, it turns out, but the other problem was, when I was looking at it, way back then was that docs were just ridiculous. They were pointless. Craig: [5:20] When you said they've gotten better. I definitely think, not that the training such as my book and your training are still much needed in the space, because it's a complicated topic. [5:30] The funny thing about it is I remember they used to have comments at the bottom of documentation. It was like going back to before stack overflow or whatever where you'd have to read through seven people's comments to actually get the answer to the documentation. I know it was just hilarious. [5:47] They have seemed to have cleaned a lot of that up. It was sometimes infuriating, but sometimes it was really actually funny. Depending on your mood, you would actually think it was funny and then sometimes you just get mad and say, "This is ridiculous. I'm hanging up my boot." [laughter] Sean: [6:04] Totally true. The docs were truly terrible. They're infamous actually for being so bad, but they're better now. The problem is they're not, in my opinion, better in a useful way. Craig: [6:15] They're not pragmatic or practical. Sean: [6:17] For learning, they're not better for learning Angular. It's still a terrible place to start off when you're learning Angular. That's a big mistake to start at the docs if you're learning Angular. [6:29] They're really comprehensive now, which is great. They're still parts, I still even recently found myself looking at code to figure out what was actually happening, but they're good enough to investigate that built in directive to see what you can do with that thing and that's good. [6:44] The problem is they document really well what is happening, but not why they do anything. They're totally missing a lot of context. [6:55] When you're trying to learn something like Angular that has a lot of potentially, depending on your experience, background or whatever, a lot of strange new concepts like dependency injection for example. The first time you see dependency injection, which is what happened to me. [7:14] I looked at it and I kept reading through the basic hello world application and I kept seeing examples of all of a sudden they're including different parameters in these functions. I'm like, "Where did that even come from? How can you even do that? You can't change the API of a function like that arbitrarily and there is no explanation for it. " [7:35] Angular has a lot of gotchas like that. [7:38] The other thing they totally screw up, in my opinion, -- I shouldn't say it like that -- The purpose of the docs isn't to get you from A to B in learning, but even in their tutorials they have also failed to do, is they gloss over this what is the most important thing about Angular, that it's really a very modular framework and it's all designed around creating directives. [8:00] You have to know about directives, how to make them and how most of the basic built in directives work, otherwise you're going to be in trouble really fast. It's just going to be confusing really fast. [8:13] That's the pitfall, that a lot of people get stuck in Angular as you start off just using the built in directives without really knowing, like, how does ngBind work? How does those little " [indecipherable] " work? What's the digest loop, without any knowledge of how that works? [8:30] You can get pretty far with an Angular app that way without knowing what's going on, but pretty quickly you'll run into trying to think through, like, "Where should I put my code? How should I organize this Angular app?" [8:44] Then, you run into performance problems because you don't understand the digest loop and how many watches you have when you're using ngRepeat. [8:52] Most of the problems I see that people run into with Angular, the most common questions come from this failure, at least, of Angular to peel apart the more modular components that it's made of and explain the philosophy of Angular. Like, "How you should be able to use watches and how you should be able to use directives and create your own declarative language in your mark up and that's the power of it." [9:17] No tutorial that I know of, except for mine, actually starts there with those core components. That's, in my opinion, the Angular learning curve is right there because you can get so far with the built in directives without knowing what's going on and they encourage that. Craig: [9:32] Right. You take a more foundational approach, it sounds like, "What is a directive? How do you build one from scratch?" Then there's something that already is a directive that is built into the framework and now you have a better understanding from the core of how that works. That's a great approach. Sean: [9:49] Right. Exactly. You got to understand the digest loop. You have to understand watches. You have to understand injector. You have to understand how Angular pulls all these things together and how to create a directive. Those are the key things. [10:01] As soon as you get that, it's like all the problems that you see people running into you understand why and you can figure it out yourself. Craig: [10:09] How do you like to think about the digest loop? Can you elaborate on how you think about it and how you finally cracked that concept? Sean: [10:16] So, the first time you encounter Angular updating the page automatically, you're like, "Whoa, how's it doing that?" [laughs] Craig: [10:24] Right. Sean: [10:25] I've created frameworks like this in the past at my company. Little mini-frameworks that I've made for myself to create prototypes really quickly, and also to help push my managers into a modern approach for building our web applications to help us eventually solve some problems we were having with our large JavaScript code base. [10:46] I'd built a few things like this before. The way I'd done it was like, basically intervals, or I'd done it with like special models where you have to inherit from a model and then you have to special getters and senders "XX". I wasn't seeing anything like that with Angular, I was thinking that maybe there was an interval. [laughs] [11:01] Maybe they're like, continuous polling my data in the background, but I still have no idea how that's actually happening. It looks like I just have a regular JavaScript object. I was like... Craig: [11:13] How are they getting the data in your model to bind to the UI is what you're really getting at, like "How's this magic happening?" [crosstalk] Sean: [11:19] Yeah, exactly. The really simple way of doing it would be, if you were to implement it yourself, for example. If you would want to have this notion of "Whenever I update my data model, my view knows about it." How do you do that? [11:32] You can do that by having special setters on your model, on all of your model. So anytime you change it, you have to use the special setter and that way it actually updates the view. [11:41] In fact, this is how I explained it in my class as well. Like, "OK, Angular isn't doing that, so how are they doing it?" The way they do it is pretty cool. [laughs] [11:50] In my opinion, I would've never thought about this. It's the notion of dirty checking which, by the way, am I going to be explaining something that everybody knows here, or is this something like? [laughs] Craig: [12:02] I don't think so, I think this is a podcast for people that are new to the framework, or for you, know people who are deep in it. It just depends on which episode that you listen to. The kind of stuff you get. I think even people who have used Angular quite a bit. [12:17] In my opinion, it's always nice to hear from a different perspective, like, the digest cycle or watches described a different way, because when you understand, you know when you think back through your programming career, if you've been there a while, some of the best teachers that I've ever seen, or whatever, usually go to a very low level. [12:37] I can remember when ".Net" first came out. Someone taking a "Hello world" app that was just consoled at right line. It was Jeffery Richter, who's famous for writing very low-level books on C#. He spent the time on this user group I saw him at with IL [indecipherable12:56] , how it was rewriting the byte code and so forth. [12:59] I think, at some point, you don't really need to know that, but, it's like you need to understand it. Once you understand it, then a lot of things become easier to troubleshoot and so forth. So, I really love this kind of stuff. Sean: [13:11] I agree with that. Craig: [13:12] I agree with this kind of stuff. Sorry for the tangent, but I like this kind of stuff. Sean: [13:15] OK. I think you do absolutely need to know how the magic works, and that's the thing that I like about Angular is that there's a lot of magic. But, it's really straight forward in how it actually works. [13:27] It's like you're actually wasting your time if don't bother to figure it out. You know it's better just to figure it out, because it's not that complicated. That's the case with the digest loop, it's like this awesome idea that...You know when a JavaScript app...When nothing's happening. Nothing's happening. [13:43] You don't need to be checking if anything's updating. There are only like a couple times where you need to see if something changed, like when there's an event or like any synchronous callback, you know from an AJAX caller or like a set timeout or set interval. [13:56] Those are the only times where you need to actually see if there's anything in your model has changed and you need to update the view. And, then, of course, as the developer, you know the pieces of your model that are bound to the view. [14:08] What Angular does is give you, in an explicit way, to say, "OK, these are the things that could change and then every time that one of these events happen, where something could have changed, check to see if it's changed". [14:21] Basically you set these watches and you say, "Watch this value on this object," and say "Anytime where there's something could have changed, check to see if it changed." So, Angular remembers what the previous value was, and anytime it hits one of these events it goes through what's called the digest loop and it checks through all the watches that you've set up. That's really... That's it. [laughs] [14:42] That's what's happening with those built-in directives that you bind with the ngBind with the "[indecipherable]". That's all it is, they set up a watch. They're using that built-in functionality. [14:53] The reason that you need to know about the digest loop, if you're using Angular, is because, eventually your code is going to leave Angular. Then what's going to happen is your model will update, but the view won't, and if you don't know what's going on, you won't have any way to figure out how to fix that. [15:10] If you know that this digest loop has to run, and you have to trigger it yourself, then you know, I've got to wrap stuff that leaves Angular and then apply "call" or something like that. Craig: [15:20] Right. That's when you get into directives that you have to understand how to hook yourself properly into that into that digest loop. Sean: [15:28] Sure. Or you're talking to a third party, an API, or you're working with another service or something like that, and that leaves "Angular Land". All of a sudden that the code that was all neatly tucked away in your controller -- which always gets executed when it's first loaded inside of that boot strap function, that happens at the beginning of every Angular loading and whenever an Angular app loads -- as soon as you leave that you're not inside a digest loop so Angular has no idea that anything... [15:54] It doesn't even know to check to see if something's changed. You have to tell it to. Which takes away the magic a little bit, because it was like, "Whoa, Angular is super cool!!", and then I'm like, "Oh, that's all I have to do? Tell it that something changed, and then tell it to watch something?" [16:12] But, you use those built-in directives, and if you don't know how they work, you can get into trouble really fast. Craig: [16:20] No, that was good. That's great. That's a great explanation of that. [16:23] One other thing that we've been talking about is Angular and the enterprise. We were discussing things that you were saying, "Hey, this is a pretty good match up from my experience with these larger code bases", like the one you mentioned before as a JavaScript framework. [16:38] Can you explain some of the things that were missing in your code bases and these code bases, these larger JavaScript code bases that Angular was filling in and you wish you always had Angular's base code? Sean: [16:50] The start of when you're creating an MPC web application, that most of your stuff is happening server-side. You generate a template, you make a call and it returns, it renders the template, turns the markup to be somewhere inserted inside the page. [17:05] As long as you're willing to do a full page reload, that's fine. It starts to get weird when all of a sudden, when you want to do stuff without doing a full page reload, or without rewriting an entire section of the document. [17:17] What a lot of people do, what we did for the longest time was...We had, [laughs] I was going to say JQuery, but we didn't have JQuery at my company. They used YUI 2, which is hilarious, but...Anyways, we used their JavaScript framework or the library that they had. Craig: [17:35] It's funny that you said "You e". I don't know if I've ever heard somebody say "you e" before, but I'm sure that's what everybody calls it, but I've never heard it pronounced, I don't think. Sean: [17:43] Maybe not. [laughs] Maybe that's just how they said it there, because nobody uses it, so how are you supposed to know how other people will say it? [laughing] Craig: [17:52] It's not a name like JQuery so it's the YUI libraries right? The YUI guide right? That's what you're talking about? Sean: [17:58] Yes. Exactly. Sean: [17:59] Yes, exactly, Yahoo's JavaScript library, which way back in the day before jQuery was the de facto standard, was a contender, that's when they were picking libraries. [18:08] They were a little ahead of the curve with the JavaScript library stuff and client side stuff, but a little too far ahead of the curve because they picked the wrong...bet on the wrong horse in that case. Craig: [18:18] Right. Sean: [18:18] What you start doing is you start adding more complexity and more interactions on your page. I was the JavaScript guy at this company. I was the front-end guy, and they would go to me to get these interactions working that they wanted. [18:31] It was really tough working with the system the way they had it set up, because when I asked the server for stuff, I'd get back markup instead of data. [18:40] What I really wanted was I needed some data, I needed objects to work with. I found myself, a lot of times, writing code where I would dig through the document and look for the state of the document there. [18:52] Not only does the server return actual model data which is actually rendered, but there is also this extra state in an application, especially a single page application which is the, I don't want to call it view state because that's got some Microsoft connotation, but you know what I mean? There's like the user interface state, where it's like... Craig: [19:16] View model some people call it, scope and AngularJS... Sean: [19:19] ...what's showing, well, I mean at a more abstract level, like what's showing right now and why at that layer? [19:27] What I found was really frustrating for me was that sort of knowledge, of like, OK, should this menu be dropped down? Should this be highlighted? Should...? In this application that we had there was all kinds of code like that, where it's like...If they've done these four things then they should see these three things over here. [19:45] That's not your model state. That's not product specs. That's state that's happened and built up over time of the user interacting with the application. [19:52] Where does that live? In my case, that state lived, most of the time, in classes. CSS classes that were added into the markup. I ended up writing a lot of code where I'm scraping the DOM and finding what state certain elements were in. [20:10] Of course I hated that. I did not like that state living in the DOM, so I'd pull it out and I'd try and keep and maintain a little separate JavaScript object where then I would use that to do my application logic. [20:22] I started being like, "Why are we doing this? This is a waste of time. Why don't you just have the server return json, render the markup client-side based on the data I get back from the server plus what the user has been doing?" [20:35] "Then all I have to do, I've got this cleaner JavaScript code, where I'm just updating my pure JavaScript objects which are much easier to work with, there's no HTML scraping. There's no longer any data that I care about in the DOM." [20:49] Once we hit that point, in the complexity of the application, where it became a no-brainer for me. At least I always figured at that company that we should be rendering our markup client-side...I never actually managed to convince them to do anything of reasonable size using that approach, even though I had been pushing for that for like five years. [laughs] Craig: [21:11] Right, and if you half commit to something too, it's hard to get there. Right? If you would get some json calls back, but the whole app isn't structured, thinking, you know architected in that way. [21:24] Not that you couldn't take an app and slice it into three or four single page apps. If you're not at least committing, you stepping across the line and starting to commit that way you're fighting it quite a bit. Sean: [21:36] What pushed them over the edge, I think since I have left they actually have some AngularJS running there, which is funny, is that they had an iPad app and they wanted to reuse a bunch of the stuff that they wrote for the web application. [21:53] Of course the managers were like, "Well, we already wrote all that code on the server, you just use it on your iPad app.", but it's returning markup that is several steps away from the data that you need to actually get into your iPad app. [22:07] Obviously, you need something portable across both systems so they ended up writing a separate layer where they could return ask for json if they wanted instead of HTML. [22:19] This company was even crazier because they had an entire layout engine, server-side. Markup in the browser that was returned was actually...they would render it in multiple resolutions and formats to try and get the best fit for the screen, on the server, and then generate markup and CSS to spit back the view. [22:42] Imagine you are working on the iPad team and managers are telling you, "use this call..." which goes through our layout engine and builds up this HTML. Somehow you're supposed to use that insanely brutal code to get data out of. [22:58] It was the same problem I ran into with the JavaScript. It was just the iPad team was a lot more high profile than me trying to get little front-end stuff working. [laughs] Craig: [23:06] Right. Get the iPad app done. It needs to go out tomorrow. Sean: [23:09] Yeah, but it's the exact same problem. This is why I think AngularJS has taken off, and I don't know why AngularJS in particular, there are a lot of frameworks, but it's definitely AngularJS seems to be killing everybody right now. [23:22] Probably because of this, because they're saying "really, you're building apps", and if you have apps on multiple platforms, like iPad or mobile, then you've got also your web app that you need to build. Your server gradually...that's obviously going to start turning into something that returning simple json data. Craig: [23:39] Right. Cool. I think that was a good description of some of the problems. The one thing that you didn't mention but I'm sure you felt was the whole influence of the router and the back button and that sort of thing. Sean: [23:51] We implemented our own version of that at this company. Having the ability to do that in AngularJS that would've... [laughs] Sean: [24:04] Yes, the way that they ended up doing it there was truly terrible and was one of the buggiest things that we wrote, actually. The fact that AngularJS lets you do that, makes that much more organized is much better. Craig: [24:18] Sorry, I didn't mean to steal the thunder there. That's always been my big pain point, sometimes I'd write a page and return HTML to my jQuery or whatever and think I was saving all this time. [24:36] Somebody would be testing the app and hit the back button and it wouldn't work and then you are like kind of stuck. You're just like "Wait, what am I going to do now?" [24:44] This is the Front-End Developer cast, so maybe we should take a quick second or two to talk about "Sketching with CSS" in case it matches up with anyone's interest. Sean: [24:53] It may or may not. "Sketching with CSS", I wrote that for web designers who are coming from a Photoshop background. It's like, if you are trying to leapfrog from doing Photoshop design to designing in the browser -- Is what they call it? -- It's basically all the front-end tools that a front-end developer uses to create the designs that they were doing in Photoshop before. [25:18] How would you go about doing that in the browser? It's all the tools that you would need there. That's not going to be anything that an experienced front-end developer, there's not going to be a lot new in there. Basically, the less experience you have the more value you get out of the "Sketching with CSS" book. [25:34] My AngularJS training is for learning AngularJS and that's it. It's like, jumping the learning curve that we talked a little bit about at the beginning of the podcast. [25:46] My website is planningforaliens.com and the AngularJS training is at training.planningforaliens.com/AngularJS and that's where that is. Craig: [25:55] OK, well thanks again for taking time to come on the show. I wish you luck with the newborn... Sean: [26:00] Thank you Craig: [26:02] ...and, keep in touch. Sean: [26:03] Thanks Craig. Craig: [26:06] Thanks for listening to the Front-End Developer Podcast. Please subscribe to the Podcast by going to the iTunes store on your phone or desktop and searching for Front-End, or via RSS by going to frontendcast.com where you'll also find show notes and a full transcript of each episode. [26:21] If you haven't already, please take the time to check out my book "The JavaScript Framework Guide, AngularJS, Backbone, Ember | Confidently Choosing and Quickly Learning." by going to javascriptframeworkguide.com. [26:35] Thanks. We'll see you next time.   The post Learning AngularJS: The AngularJS learning curve | Episode 7 appeared first on Funny Ant.
Aug. 25, 2014
Chris Coyier and I discuss how to use custom fonts and @font-face to makeover your web application or site.  Chris and I also discuss “What is a front-end developer” and contrast his project codepen.io with jsfiddle.net and jsbin.com. Chris has worked for large scale web apps like SurveyMonkey and design focused startups like Wufoo. He co-founded CodePen, an online playground for HTML, CSS, and JavaScript. Chris also has a weekly podcast about all things web with Dave Rupert called ShopTalk. The man knows a few things about the web! Tweet To subscribe to the podcast, please use the links below: Click Here to Subscribe via iTunes Click Here to Subscribe via RSS (non-iTunes feed) Show Notes: Resources Chris’s CSS blog CSS Tricks Codepen Adobe TypeKit Font Squirrel Font Squirrel’s Font Generator Also mentioned Sifr Full Transcript Craig McKeachie: [0:00] On this episode, Chris Coyier discusses how to use custom fonts, and @font-face to makeover your web application. This is Front End Developer Cast, Episode 6. [0:09] [music] Craig: [0:20] Welcome to The Front End Developer Cast, the podcast that helps developers be awesome at building ambitious web applications, whether you’re a JavaScript ninja, or you’re just getting started. I’m your host, Craig McKeachie. [0:33] Hi, everyone. My interview today is with Chris Coyier of csstricks.com, and the creator of codepen.io. Let’s get right into the interview. [0:42] Hi, today, I’m really lucky to have Chris Coyier, of csstricks and codepen fame on the podcast. We can talk a little bit more about his background. It’s somewhat unclear to me, I’d be interested for Chris to fill in some of the details. I know you used to work at SurveyMonkey, and then SurveyMonkey was bought by Wufoo, if you wouldn’t mind, Chris, welcome to the podcast and give us a little history about yourself. Chris Coyier: [1:05] Thanks for having me. It’s awesome to be on. It actually worked in that reverse order. [1:10] It was Wufoo that got bought by SurveyMonkey. That’s the first time that’s happened. I feel like most people…I can grab somebody off the street usually that’s heard of SurveyMonkey, because I feel like they’ve been around forever, and they have market saturation, and teachers use it and stuff like that, whereas, Wufoo is a little more niched to the industry. Craig: [1:32] It makes sense that SurveyMonkey would be the acquirer, right? Yes, definitely. Chris: [1:36] Yes. My history is tremendously boring. I don’t know, there’s not much that can be gleaned out of it! I hate to start on a bummer note like that, but it’s like I’m just normal kid who went to normal college in the Midwest in the US, and became a font-end developer. Craig: [1:55] It’s CSS Tricks, I saw you’re listed as an author for that. Did that start as your blog and is now owned by Treehouse? Can you give me a little [inaudible 0:02:04] ? People are curious about that a little bit. Chris: [2:03] Sure. That’s probably what most people know me from in this industry, because it’s the thing I’ve been doing the longest. [2:11] It tends to be one of those sites that people tell me it shows up in search results a lot when you Google a CSS problem or something like that. Google has been good to me in that way. That’s a blog that I started in 2007, it’s a little over seven-years- old now. [2:30] There’s screencasts on it and a blog post, and a section I call Snippets, where I have little miniature chunks of code that have less explanation attached to them, and there’s a community forums there that’s pretty active, and stuff, it’s this whole site about all things front-end web design. It’s called CSS Tricks, which is a terribly hokey name, but it has brand power over the thing. [2:54] It’s not owned by Treehouse. Treehouse is a sponsor of mine and I have an interactive ad for them that loads in the header of the site, but that’s a paid sponsorship. Craig: [3:04] OK. Chris: [3:05] It’s just a business arrangement between us and I’m the big fan of Treehouse. [3:08] I think they’re the right people at the right time to having a company that does modern teaching of all the stuff that we talk about all the time. I think they do a good job. I’m happy to have them as a sponsor, but there’s no ownership. Craig: [3:22] So far, I’ve given away your blog to Treehouse and Wufoo being bought by SurveyMonkey, so I’m… [3:28] [crosstalk] Chris: [3:28] No trouble, I’m happy to talk about it. Craig: [laughs] [3:29] That’s pretty funny. I think it was just that I saw in a bio somewhere that you’re a writer for CSS Tricks instead of the owner of the blog, so it threw me off a little bit. Chris: [3:41] Oh yeah, it’s funny. CSS Tricks is just me. I have somebody who helps me do administrative stuff and sell t-shirts and stuff. [3:50] That’s Sarah in Ohio helps me with that, and Rob in the UK helps me moderate the forms and stuff, but theirs are very small part-time jobs, it’s just me, essentially. Craig: [3:59] Great, a big thanks to you from all the developers including myself over the years who’ve read the CSS Tricks articles, and been gotten out of some CSS hole, or learned something about CSS, I appreciate it. Chris: [4:12] Good, great. Craig: [4:13] One thing I want to talk about, we were talking before we started recording here, this question of, what is a front-end developer to you? [4:21] I started this podcast. I didn’t have a great name. I didn’t want to be yet another Java Script podcast. Most of my content is Java Script focused, but there’s this term front-end developer coming out. [4:32] I think it can mean a lot of different things. It can be this person who comes from an agency or an interactive media background who’s really, really a Googler with HTML and CSS and perhaps, Java Script that seems negotiable with some people’s skills sets who are really good at CSS and HTML, because that can be a career in itself as you know. [4:54] Then, there’s some people like myself who might have been more of an enterprise developer in asp.net or Java or Rails. I don’t want to call Rails Enterprise developers, I might get some hate mail for that, but who care about the CSS, HTML, Java Script part of their work and look at themselves as a craftsman in that area. [5:13] It’s this mixed crowd calling themselves front-end developers and all this interest in Java Script and so forth. What are your thoughts on that? Chris: [5:21] Yeah, especially, the last part of what you’re saying is interesting to me. I hadn’t put tons of thought in, but this is how I’ve thought about it, in attempted to define it in the past, and I don’t really care all that much. [5:34] It’s just a title, I don’t know. I think that does benefit the industry a little bit, if we can agree on these things. But I also think that, this is such a hotly debated thing, that I’m not sure, that we’ll ever get to any final agreement. But this how I’ve done it in the past. Front-end developer is HTML, CSS, and JavaScript to me, essentially. It explicitly means that you focus on those things, and not so much the server side things. [5:58] Of course, everybody had…it lives on a spectrum of what they know. But it means, you’re probably not writing a ton of back-end code. You’re focused on HTML, CSS, and JavaScript. Also, to the exclusion of much designed work either. Because I feel like, if what you do is design, is aesthetic things, and the beaux things, and you can write HTML on CSS, and maybe a very light JavaScript. Then, you’re a Web Designer. [6:25] Web designer meaning, I can do HTML and CSS. But I also am worrying about, what it looks and acts like. When you’re a front-end developer, then that’s to be exclusion of design. You’re not much of a designer, you’re just focused on the…with the technologies that make those things work on the front-end. Which means you’re heavier in JavaScript, and less so on the design thing. Craig: [6:47] But I’m sure you see all kinds of people hit your site, and send you emails. Meet up at conferences, and so forth on that continuum all over the spectrum right? Chris: [6:57] Absolutely, everybody is somewhere on the perspective. What I haven’t thought about what you are saying is that. There are people that probably like spend a good amount of Time and Rails, but aren’t really a back-end developer. [7:10] They just spend Time and Rails, because Rails is pretty easy, it’s pretty easy to throw out together a little view, and a little controller to give yourself some basic data and stuff. It’s like you’re a back-end developer, or you’re working on WordPress, or something, which is PHP based. You can make a theme like nobody’s business. But does that really make you a back-end developer? [7:31] I tend to think of server side backend people. People that work in that world, but they have this like programmer background. Like they know about data sanitization and databases. How they might structure data to be related to other data, and security concerns. They know just how they should store a password in a database, and that kind of thing. [7:52] That makes you more of a back-end developer. I think you can live on that spectrum, where you’re like, you write a good amount of code that happens to be in Ruby. But you’re not really a back-end developer. You’re more of a front-end developer still. Craig: [8:06] Interesting, particularly like the server side thing, I think is interesting view. Since that’s sort of where I come from, I think the interesting one to me is the designer with “Devs” Skills. [8:15] Which I’ve definitely met some designers over the years. Who you’re getting into, or getting better and better at HTML, and CSS. That’s another area that I didn’t mention, at first where the line starts to gray there a little bit. Thanks for that, that’s very helpful. The main reason I’m inviting you on the show, was not to get you in trouble by trying to define a front-end developer. But was to talk about the state of fonts on the web. [8:42] This comes from mostly my own personal curiosity. I’ve been a developer on the server side for years, took an interest in front-end development, and JavaScript in particular. But I’m still not real up to speed on…there’s been a lot of evolution in a last few years, on fonts on the web, and what’s happening with them. I wanted to see, if you could maybe take us through a little bit of history of what you’ve seen. [9:07] What you think people should, or could be doing out there today to improve the web fonts on their site. Chris: [9:13] That’s pretty interesting, because your site is funny and that comedy, you can tell by just looking at it right away, that there is a custom font in use. It’s a little unusual looking. I haven’t seen it before. [9:24] I can open up the web inspector, and just look at it quick, and look at the computed styles. That’s something called “Lato” I think. I’m like I’ve never heard of that. But I can tell that, that’s coming on to your site through technology, essentially, in the web called “App Fontface.” Because that’s pretty much the only way it’s done these days. [9:43] Back in the way early history, where there was some…there is some other way, as we could use custom fonts on the web. But these days, there’s a 99 percent chance, it is using CSS App Fontface to put that custom font in your site. I guess I’d be interested in, were you messing around with it? And try to figure it out, or is this a template that you downloaded and had it… Craig: [10:02] This is your WooTheme. This is a WooTheme from WordPress WooTheme, which is a very popular theme company in the WordPress space. [10:11] I looked through all their themes. I liked this one, in particular. It was pretty sparse and so forth, I picked it. I have no idea. For the sales page for my book, thejavascriptframeworkguide.com, also has some very nice fonts. [10:25] I, with permission, borrowed those from Nathan Berry. I was like, “Maybe I should tweak these a little bit, it doesn’t look so much like his page.” I got into, “Gosh, but I really don’t understand it at a low enough level now to make sure that it works in all the browsers.” Questions started coming up in my head, like how far back, browser-level-wise, will this work? [10:49] Why do I need these three different…I need an SVG file and a WOFF file and a TIF file. What’s going on here, basically? Chris: [10:59] You know that those are quite literally files. They’re resources, just like a CSS file or a JavaScript file or image file. They’re just font files. The frontrunner these days is WOFF, W-O-F-F. Thank God everybody has agreed on one format. [11:19] As you know, in the world of front-end, we need to support older browsers when we can, or we might be mandated to, or might just all agree that it’s a pretty good idea to serve as many people as we can. If they’re running older browsers, they may not be supporting WOFF. There might be some other formats that we need to serve those fonts in to get them to work. [11:37] I’m not sure if that’s already a little too far down the rabbit hole, if we should keep it higher level. Craig: [11:42] No, I like this rabbit hole. Maybe it’s only my personal rabbit hole. I think people wonder. [11:47] Let’s say I’m working on an internal app at an enterprise, but I just don’t want to use Arial for the thousandth time or some font stack that looks good on a PC, but doesn’t look good on the Mac, or for the person at home, that sort of thing. I really want a unique font to make the app stand out, look more professional, impress my end users. What would you suggest for someone in that? Chris: [12:10] That’s the idea behind this whole thing is that the web is a visual medium. [12:15] For so long, we were stuck with what were, I guess, generally, referred to as the web-safe fonts, which were Arial, and Lucida Grand, and Veranda, and Trebuchet, or whatever. There was a handful of them. That might be 75 percent of them, right there. [12:32] There were so few that just happened to be installed on cross-platform, Mac versus PC versus Linux, usually, and looked OK and worked on the web. If you picked something else, let’s say you really liked some cool, scripty font that happened to be installed on most Macs, in CSS, there’s a property called “font family” and you could make it happen. [12:54] You could make it look like it looks like if you happen to be on your Mac or whatever. Then, if you looked at that same website in another browser, it’s just wouldn’t work. And people would be like, “Why does your website look broken?” or whatever, we didn’t do that. We always picked ones that worked consistently, cross-browser. [13:11] That’s what @font-face brings to the web, then, is that you can load these font files as a resource, and then they do, for the most part, look consistent across all browsers. That’s the point of it, is we can now use these fancy fonts and do it in a consistent way. Craig: [13:26] I think you have a good article on CSS tricks on some of the more low-level details about it. [13:31] The point is, if you want to support back-level browsers, WOFF’s becoming the standard, but you probably have to throw an SVG file in there to support the older versions. Chris: [13:40] That one’s the first ones to go. That one’s an old iPad one, but there’s true-type or something… [13:46] [crosstalk] Chris: [13:48] You know what the beauty of it is? Most of us never even thought about it. [13:52] There was tools that came along to help us with the best practice there, because who wants to think about this stuff? It’s like prefixing things in JavaScript or prefixing things in CSS. It’s just a bummer. It’s just not a fun time. [14:08] There was tools like Font Squirrel that came along. I don’t know if you’ve heard of that one, but it was like, “Pick a font or upload your own font, if you happen to have it around, and it’s legal or whatever. Click a button, and we’re going to process it into all the different font formats that you’re going to need, and then give you a little chunk of CSS that is the best practice of how to use it.” [14:27] Very few people actually thought about it all that much. They just used some kind of best practice tool to get it to work. No doubt, even on your theme, someone did that, probably. Craig: [14:37] Right. It’s so interesting. I had heard podcasts on Font Squirrel and so forth. [14:42] I never quite put all the pieces together. What others sites? Is Font Squirrel the one that most people go to, if you have a Photoshop license and you want to keep…there’s this legal side of thing. Where can I go on the web? Let’s say, I want to pick my font for my thing. The Font Squirrel sounds like a good resource. Is there other places that… Chris: [15:02] That would be the one, if you wanted to host your own. I’d have to dig into your site, specifically, but if you’re going to perhaps sell a WordPress theme or sell a theme, you would probably use something like Font Squirrel. [15:15] You want to make it self-contained, probably. All those resources, you would want to come along with the theme. I think that’s becoming somewhat less and less common, as things like Google Fonts become more and more prevalent. I’m sure a lot of people have heard of that. If you haven’t, just Google “Google Fonts,” [laughs] and you’ll find their resource. It’s pretty darn nice, to be honest. [15:40] You can just browse through a collection of lots of different fonts, and then, click one to show you what it looks like and test it or whatever. Then, it just gives you a little chunk of CSS that you can put on your page. It’s either a piece of HTML that you can put in the head of your document or an import statement you can put in your CSS. [15:57] Then, that font becomes available for you to use, and Google handles the serving it in the correct formats and all that stuff that needs to happen. That’s a great resource, if you want to use a custom font on the web, just because they handle all the heavy lifting for you, and the font is ultimately on a CDN. You don’t have to worry about hosting it and that type of stuff. [16:20] If you’re like, “I want to pick out a cool font and use it,” that’s probably the easiest go-to place to start playing around with custom fonts, I would say. Craig: [16:28] At least, in my experience, designers are famous for “Myriad Pro this,” “Myriad Pro that.” Lately, I think that PCs are starting to come installed with Myriad Pro, but let’s say, I get a comp from a designer, and it’s got Myriad Pro on it, or I decide I want to use Myriad Pro. In that case, that’s a pretty well-known font, not an open font. Or, is it? [16:50] How do you handle situations like that, where it’s a more common font, but not one supported across the web? Chris: [16:56] That font, you won’t font it on Font Squirrel, just because there’s licensing restrictions for these fonts. [17:04] A designer created this font, and they decided that you can’t just do whatever you want with it. You have to pay for it in which to use it, which is a reasonable thing. But you want to use it, let’s say. [17:16] An illegal way to do that would be to take it, anyway, and send it through Font Squirrel and use it. I’m sure people do that, unwittingly, quite often, because the tool is so easy, and despite Font Squirrel doing a fairly good job of making sure that that doesn’t happen. They might even look at file names and block you from doing that, in some cases. [17:35] I’m not sure how it all works, exactly, but I’m assuming they try to stop you from doing it, but you could get it done. You could rename the file or try to get around it in some way. Or, maybe it just lets it through and whatever. That is a lot of time spent on something that you shouldn’t do. You’re breaking the law, essentially, if you do that. [17:52] There’s other services that you can sign up for, things like Typekit, that is probably the largest industry standard one, as far as I know, but what are the other ones. There’s Fontdeck and MyFonts. There’s a number of services that have came up to make this easier and legal. [18:13] Typekit is a paid service. If you want to use Myriad Pro, Myriad Pro is on Typekit, you sign up for Typekit which costs you a few bucks. I think they have some free plan for it. If it was just totally a low-traffic personal site you could probably get it for free. But then, most low-price plans you pay some monthly fee depending on how much usage you’re going to have. [18:35] Is it a large app or is just a medium-size site. Like any paid services in the world they have different plan levels. Then, they give you, in their case of Typekit, a little chunk of JavaScript that you put in the head. It just does some stuff in the background, loads the proper CSS and font files from Myriad Pro to work, and then you can use it. If you need and wanted to use it, Typekit is probably the way to go for you, for those particular fonts. [19:01] Goes hand in hand with this, it should be said that that’s a great font. It’s going to look really good. It costs money for a reason, because it was well constructed and there’s maybe a lot of weights, and there’s lot’s of characters. It’s a full robust collection of fonts. Care was taken to make sure that it renders across browser and across platform properly and stuff. [19:24] When you pay for a font like that there’s exceptions on either side, but chances are it’s going to be a higher quality font. Whereas, if you just snag something for free off Dafont or whatever, and sent it through Font Squirrel and use it, there’s going to be display problems. Craig: [19:40] Right. And so when you say…I don’t want to prolong the illegal way, but I want to understand the flow of how these things are used. [19:49] It’s not just this magic JavaScript. Let’s say, you had something legal that was legally an Open Source font or something like that and you wanted to run it through Font Squirrel, what would you be putting in? You’d be putting in the font file, basically. There’s a definition… Chris: [20:01] I think it takes whatever, yeah exactly. I think it will take just about anything. It will take the TrueType one or the WOFF one. I forget what the other formats are. I probably should have… Craig: [20:10] It turns it into all of them plus the snippet you need. I’ve got it. OK. Chris: [20:14] Exactly, yeah. Craig: [20:15] You could take it from anywhere but the problem is you want to be legal which is…and it doesn’t seem like these fonts are that expensive. [20:22] But I think, in some ways it’s been made such a dark art right now on the web, it’s easy to do something illegal unknowingly, basically. It’s what I thought. Chris: [20:30] I suspect that happens quite a bit. Although, credit to our industry, I don’t see it all that often. [20:36] Because I feel like if you are designer by trade, or there’s probably a designer by trade that works somewhere in your company, that if they see your company doing that they would speak up, I think, because they are trained in the industry that they know that that’s bad news. [20:51] It’s not just bad news just because it’s illegal, which is bad enough, but it’s really in…you’ll get called out for it. It’s in bad taste such that it’s just a really not-cool thing to do. These days people will be naming and shaming you on Twitter, all right and left. Craig: [21:08] Right. Is this like DRM where enforcement of it is really hard, as far as your understanding? Let’s say, I unknowingly do it, is there ever any point where my site stops working or there’s a license involved? [21:23] Like with the TrueType fonts, let’s say, someone went through the legitimate means of using a Typekit font, and I happen to borrow from the design, let’s say, and use it on my site but I don’t realize…unknowingly, I’m thinking, “Oh this just looks like Arial to me. I’m not a designer guy.” Will it stop working? Chris: [21:46] OK. Let’s say you’re self-hosting some fonts, because you want the Font Squirrel route and I looked around on your site, I could find that resource and download it, because it’s just a font file that lived somewhere. [22:00] I could open up my web inspector and find that resource it’s linked to. It has to be public for it to work on the web at all. I could steal that font from you, essentially. You can’t just View Source on a site that’s using Typekit, grab the JavaScript that they’re loading to make that font work, and put it on your site and expect it to work. It won’t work, because Typekit specifically locks that stuff down by URLs that you whitelist on their site. Craig: [22:29] Oh, by domains basically, I see. Chris: [22:31] By domain, right. Craig: [22:32] That’s why it’s very legitimate and that makes a lot of sense. OK. Chris: [22:37] But still, even though just the JavaScript and stuff is locked down by domain, if I’m viewing a site which is on that whitelist, you would suspect that it still needs to download some kind of public resource to work, right? [22:51] I should be able to dig in and find that resource, which does load, I can get a copy of it if I really tried to. But you can’t steal somehow, and I’m not totally up-to-date how that works, but they do some stuff to the fonts that still make that, perhaps not impossible, but nearly. I forget exactly how it works. I know, for example, Cloud.typography, the Hoefler Fonts thing, which I also use. It’s a Typekit competitor but just for a single font foundry that’s fairly popular. [23:29] They break the fonts into lots and lots of different little pieces and then they essentially…it’s not encryption but it’s like…you know how if you looked at the source of a jpeg it doesn’t make any sense? They just turn it into a chunk of a data URI. A jpeg, that’s still useful, because it’s still a jpeg. But it’s like imagine if you took a jpeg and then you broke it apart into independent parts, and then, you weren’t really sure how those parts fit back together. That jpeg becomes useless. [24:01] I’m not sure if I’m explaining this exactly right, but they take a font file, they turn it into a data URI and then they split it up into lots of different chunks, and then, something smooshed them back together before they’re used. Even if you wanted to steal one of their fonts, you’d have to be on a whitelisted domain, then, you’d have to download each individual one of these chunks… Craig: [24:22] Piece them together in the right order… Chris: [24:23] And then, figure out how…yeah, and then somehow, un-data URI it. I’m sure it’s possible somehow, but it’s so weird and so specific and stuff that people aren’t unwittingly stealing fonts from their website. Craig: [24:38] At that point, pay the $2, or the couple dollars. OK. I think I just want to stress, most of this questioning is not to give people this idea, hey, here’s the ways to get round it. [24:50] It’s more just to understand what’s going on and how to be legal. If people don’t understand things or it’s too difficult for them in approaching this, they’d either just won’t do it and they’ll stay with the standard Arial font or Times New Roman or whatever the case may be or they’ll unknowingly do something wrong. I think most developers in this… Chris: [25:11] It’s getting a little more rare because Google Fonts is so good and you can’t do anything wrong with Google Fonts. It’s all Open Source and legal. Just do whatever you want with them. That type of thing is proliferating it on the web a bit. Craig: [25:25] Thanks. I think we’ve beat that one to death. Thanks again. Chris: [25:28] I should say that, I think it’s worth mentioning that they’re really cool and it’s done great things for typography on the web, but you really do need to be really careful. [25:38] What my thinking is these days is, it’s really got to be worth it to use it. There’s plenty of sites that are going too heavy on it. My thinking on this is not complete yet, but it’s, I’m so tempted on most of my sites to get rid of them, because they’re very often the slowest and heaviest thing on the whole site. [26:04] If you load a one, big font, a good, robust font in a couple of different weights, maybe even two fonts, that’s so huge. If you dig into what are the heaviest, weightiest things at the site, often, I see that that’s the font. And it is the case on a couple of my sites. And I’m just, “I love these fonts, but they slow it down.” [26:26] In some cases, my attempts at speeding it up…for example, you could load it at the footer of your site instead of the header, but then, you get a flash of…it’s tricky to do correctly and even when you’re doing it correctly it’s such a huge weight that you really got to want it. [26:44] I don’t think the default for building a site with custom fonts on it is design a site, pick out the custom fonts you want to use and use those. It’s not a required part of the design process these days. I would definitely consider not using them as a default, unless you really need it. Craig: [27:00] That’s really interesting man. It makes a lot of sense to me. One public site I’ve worked on the last year or so, that we were accidentally loading the font file two times, or loading way more of the font than we actually needed. [27:15] I think it was a case of the famous Myriad Pro thing. It made a significant performance improvement, more than all the tweaks we could do to multiple HTP requests, the normal type of run-in tweaks you could do. [27:30] That one blew them all the way as you’re saying. I definitely can relate to that. What would you do in the stead of that? If you’re trying to stay away from that or not default to it if you will, what would you suggest as an alternative, and simply…or browser supporting more and more fonts natively on the web or just…? Chris: [27:48] That’s a good question. Is it just go back to the Sans Serif stack? I have about two options, make Verdana or the Helvetica Arial or the Lucida Grand thing work for you. Craig: [28:04] Clearly, it’s worked on iPhones for years and this sort of thing. It’s not… Chris: [28:11] I know. It’s a little sad. My thoughts are not complete on this subject, but that’s where I’m leaning towards…or in some cases, for example, a really popular font these days is Open Sans on Google Fonts. It’s tiny. Use it and use one weight of it or pick maybe just the bold and use it just for headlines or something. [28:32] If you’re worried that you’re going to look stodgy and not up-to-date and gross, A, I think there’s plenty of ways to look modern without using custom fonts. But if you absolutely need to use the custom font, maybe pick one based on performance. Craig: [28:49] OK. You know any good resources to find those? [28:51] Let’s say, you spend your time, like I do, getting deep into JavaScript so you don’t always see a single article, as designers do, on fonts and you don’t have the same knowledge and appreciation. What’s a quick tip…you mentioned Open Sans which is very useful to people. Chris: [29:09] Google does a good job when you’re using that anyway. I suspect there’s tons of people using Google Fonts. [29:13] When you pick one from Google Fonts there’s a little speedometer. For example, you just pick one weight and the speedometer will go up a little bit. Then, you’re like, “Well, this is body copy so I’m going to need bold and italic too.” And as you turn those things on the little speedometer fills up and I’ll tell you, it fills up really fast. [29:36] I know this is a weird abstract concept, but imagine a Serif font versus a Sans Serif, Serifs have little extenders on the ends of characters, terrible ad. Craig: [29:47] Most people have heard that one, I think you’re in good shape. Chris: [29:52] OK. You can imagine that fonts are made from vector artwork, they literally are. A font file, if you were to dig into it, there’s vector instructions and how to draw those shapes. [30:03] Now, image the vector instructions for drawing a lower case L in a Sans Serif font. It’s just a rectangle. There’s very little information there on how to draw that. But now, imagine that L in a Serif font. It’s not just a rectangle anymore. It has a little curve at the bottom that hangs out, and then, a little straight part, and then it goes over, and then, another little curvy part. [30:25] You can see the information to draw that L has gotten a lot more complicated. Now, imagine a Script font while little swirls and stuff all over the place. There’s quite literally a connection between the weight of a particular font and how complex the characters are. Craig: [30:41] Interesting, OK. Chris: [30:42] “Open Sans” is, I think drawn in such a way that it was intentionally simple. It looks good, but it’s so small because the shapes of it are so simple. [30:51] There’s other stuff involved as well. If you find that you’re accidentally loading tons of Arabic characters as well, and maybe that’s great because your site needs to support those languages, but maybe it doesn’t. Don’t load them. Maybe load a kind of subset, where you’re like, “hey, we’re only going to use this for titles, so we don’t even need numbers,” or something like that. There’s ways that you can reduce the size of them. Craig: [31:14] For years, like back when it was “sIFR” which was like a flash plugin, and “Cufon”, it seemed like people were only using these unique fonts for headers, and so forth. [31:25] You just mentioned, maybe a sort of medium ground might be to stick with a normal font like “Helvetica” or something for the body text, and use something a little more unique for your headers on your pages, or something like that. [31:41] I don’t know if that’s good advice, but curious what you think of that idea. Chris: [31:45] Sure, that’s pretty common I think. Just pick one, and use it for something prominent. Pick something that fits your brand. For body copy, stick with something more normal. [31:55] The advantage there being that, body copy you’re going to need more than one weight very likely. It’s very likely that you’re going to need bold or italic, if not both…and a bold italic. That is weighty. That’s an entirely different set of…like I was saying, there’s vector information to draw those characters. [32:16] There isn’t some cool, programmatic thing that happens where the browser knows how to fatten up a letter. It’s just using a completely different set of vector information to draw a bold version of a “p” instead of a regular version of a “p”. It literally doubles the size of the font, just by also needing the bold version. [32:36] If you’re like, “I’m just going to use it for headlines!” Maybe all your headlines are always bold, you only need the bold variant. It’s smaller, and that’s the idea. Maybe you just use it for the logo of your site. Then, don’t load a font at all for that, because you’re just using it in one place. [32:57] You would never load an entire font to use like one word. That would be like SVG territory. This is a vector word, so I’m going to use SVG to draw it, and not load this entire font. The less you use a font…I guess it’s a bell curve. [laughs] Craig: [33:14] Right, but I think you’ve brought up a good point. I was like, “Hey, let’s go nuts! We’ve got these, these fonts now and they seem to be more well supported, let’s just figure how to do this legal.” [33:24] And you’re like, “Let’s not throw caution to the wind here Craig.” Again, I think that’s a really good thing for the listeners to hear about, I think that’s great. [33:33] One last point about that, is I’ve heard from people, “Oh well, I’ve got a license to this font because, you know, I’ve got such and such Photoshop license, and so forth…you know, software, and it comes with these fonts.” Do you have any insight into…if you have a designer on your team, is there a set of fonts that are already available to you, that sort of thing? What’s your understanding? Chris: [33:52] Yes, that gets complicated, doesn’t it? You were saying “Myriad Pro.” I think if you buy a Mac these days, it just comes on there. Does that mean you can use it on your website? No. I don’t know why I know that, I just know that for some reason. [34:09] There’s probably somewhere on your computer a license file that explains what you can do, and it’s probably in terrible legalese that will make it very complicated to know if you can or not. God, I wish I had better advice for you. Just know that… Craig: [34:23] You don’t see that as a common route, where people just use some fonts that Adobe has released with the latest version of “Illustrator” or “Photoshop”? Chris: [34:33] It means that you can use it on your computer, and thus, it means that I think that if you’re designing a print brochure or something, you’re more than welcome to use that in a design of that. Craig: [34:42] But on the web… Chris: [34:44] It’s just different on the web, because the source file comes along with it. That’s what they’re trying to protect. [34:50] There’s so many weird gray areas, right? If you designed a logo in Photoshop with those fonts that came…and put it on the web as an image, I think that’s fine. I’m pretty darn sure that it is fine. It’s just when you put that source file up there somehow, to use it in that way. Craig: [35:05] Very, very helpful. Chris: [35:06] It’s tricky too. Let’s say you’re working with a designer, and they have a font, but you’re working with them as a developer. Can they like send you that font? Because they own it, you’re working together to build the thing. [35:18] I just don’t know where the gray area starts and ends with this stuff, but just use your mental alarm for things that seem sketchy and assume that they’re illegal I guess. Craig: [35:30] Right. That makes a lot of sense. We’ve talked about fonts more than I thought we could fill up time with, so I’m going to let you go here. I think you clarified a lot of things for me. [35:40] It was nice to have somebody to say, “Well, what about this,” and, “well what about Photoshop,” and that sort of thing. I hope the listeners get something out of this, and I definitely think they will. I appreciate your time. It’s css-tricks.com, right? Chris: [35:54] That’s right. That’s right. Craig: [35:56] CodePen.io. Maybe we could talk about that for a little bit? Chris: [36:00] Sure, that’s just a place for playing around with front-end technology. We spend lots of time here just talking about CSS, and how you can use fonts and JavaScript and stuff. [36:09] You can play with Google Fonts right on CodePen if you want. If you wanted to play around with some typography, you could go pick out a font from there, and then, you click the little “click to use” button, and it’ll give you a little app import chunk. [36:22] You can go right to CodePen, and CodePen has a little editor for HTML, CSS, and JavaScript right in the browser, and then, a preview of those things all smooshed together in a live preview. Craig: [36:34] Right, it’s really, really great. I love these sites. Most people do, right? [laughs] Chris: [36:38] Yeah, it’s neat. It’s just a neat kind of thing. The twist to CodePen is that you sign up, and you have this account. You have a profile there, and other developers can follow you, and you can follow them. [36:48] You’re hearting each other’s Pens, and it becomes this kind of social place to see what each other are working on, but because everything is kind of public and viewable there, you can also search for things. [37:00] You really like “Lato”? That’s a nice font. Maybe you could just search for Lato on CodePen and see how other developers have used that in the work that they’re doing. Search and browsing around CodePen becomes a big part of it, because there’s so much stuff there for kind of inspiration and learning. Craig: [37:17] I was kind of wondering for myself coming from the JavaScript side, what’s the difference between CodePen.io and JSFiddle, or JS Bin, or Plunker, or these other alternatives which are somewhat similar? [37:30] The one thing that I was just complaining to a friend of mine about the other day was, at least that I’ve found, I don’t find things very discoverable on some of these other services. I don’t know if that’s how you’re trying to sort of differentiate yourself, or if you’re trying to be a tool that’s more friendly to the CSS/HTML practitioner. [37:46] How would you compare and contrast CodePen to the JavaScript sort of focused alternatives? Chris: [37:53] I guess that’s the biggest deal, is that we’re kind of a community where those aren’t really…and they’re great tools too. We got the idea from JSFiddle, and Remy does a great job on JS Bin. They just released pro accounts there too, that they’re trying to make a business out of it. [38:08] Of course, we support that. It’s a good market I think. You can have an account on JS Bin too, but how do you look in the past and see things that you’ve created? It’s not like a very visual place, whereas, when you’re browsing around CodePen there are all these little miniature iframes showing you the things that you’ve built. [38:27] How do you go back two months ago and look for something? On CodePen that’s really easy. You can just paginate back in time through the things that you’ve created, or the things that you’ve hearted, or your friend’s work, or searches that you’re running. It’s just very easy to find things on CodePen. [38:43] For example, every single Pen that you create on CodePen has a comment thread attached to it, as well, you can go back and forth and discuss the things that you do. Craig: [38:51] That helps me clarify where one of these tools has strengths and where one of them doesn’t. That was a little confusing to me, so thanks a lot. Chris: [38:58] Yeah, no problem. We try to make it the best tool as well. We’re not like spending so much time on these other things that the editor itself sacrifices. I think it’s also the most powerful editor, if you ask me too, but you know… [laughter] Craig: [39:14] But you’re slightly biased, right? Chris: [39:16] Yes. Craig: [39:17] I think people are agreeing with you I think, out there, so… Chris: [39:19] I hope so, and we’re going to keep at it big time. It’s a business for us. [39:23] But just for example, you’re writing some SASS or something and you have an error. You screwed up, so it doesn’t compile. We’ll show you an error like right on the line that that error happened. I think it’s a nicer place than that…even when I’m writing in “Sublime Text”. Of course it’s not really meant to be an alternative to your desktop IDE, but still there’s little things that are nicer to use that I like, and I prefer to that. [39:48] We have new features in CodePen, like you can write a blog post. Just being a member of CodePen, you have a blog there as well. You don’t have to use it, you can do whatever you want with it. It’s just nice. It’s just a nice little place, where you can publish a post really quick. [40:02] You get for free syntax highlighting, and you can embed Pens really easily. You can write in Markdown, and you get a comment thread, and you have an RSS feed. You have all this stuff, for free in two seconds. That’s kind of the thing that… Craig: [40:16] It’s much more community oriented. I’m getting the differentiation there, and that’s not to say that some of the other sites aren’t trying to do the same thing, but it seems that you guys are leading the charge in that community area, with your communities. [40:30] Where can people go to find out more about you? Chris: [40:33] Those two sites are great. I mean I have a personal website, as well that’s just my name, chriscoyier.net, that kind of links off to these other things. I don’t write there a ton, although, I did just publish a post today. Craig: [40:46] Surprise, right? There’s content going up there. [40:49] Again, thanks for your time. I’ll put plenty of links to all the stuff we talked about in the show notes, including over to your personal blog, and css-tricks, and codepen.io. Again, thanks, Chris, and I appreciate you taking the time. Chris: [41:03] Yeah. Craig: [background music] [41:03] Thanks for listening to the “Front-end Developer Podcast.” Please subscribe to the podcast by going to the iTunes store on your phone or desktop, then searching for Front-end, or via RSS by going to frontendcast.com, where you’ll also find show notes and a full transcript of each episode. [41:21] If you haven’t already, please take the time to check out my book, “The JavaScript Framework Guide, Angular JS, Backbone, Ember | Confidently Choosing and Quickly Learning” by going to javascriptframeworkguide.com. [41:35] Thanks. We’ll see you next time.   The post Web Application Makeover: How to use custom fonts and @font-face | Episode 6 appeared first on Funny Ant.
July 28, 2014
On this episode Brian Woodward describes his experience building his first application with AngularJS.  This is front-end developer cast episode 5. Today’s interview is with Brian Woodward and was recorded a half a year ago now and focuses on his early experiences with AngularJS and is very valuable.  He also mentions his open source project Assemble which is a static site generator for Grunt.js, Yeomnan and Node.js that has rapidly gained a following in the last half year so you should also go check it out.  Here’s the interview. Tweet To subscribe to the podcast, please use the links below: Click Here to Subscribe via iTunes Click Here to Subscribe via RSS (non-iTunes feed) Show Notes: Resources Assemble (static site generator) Brian Woodward on twitter: @doowb Full Transcript [0:00] On this episode Brian Woodward describes his experience building his first application with AngularJS. This is Front-End Developer Cast Episode 5. [0:08] [background music] Craig McKeachie: [0:18] Welcome to the Front-End Developer Cast, the podcast that helps developers be awesome at building ambitious web applications whether you're JavaScript ninja or you're just getting started. I am your host Craig McKeachie. [0:30] Hi, everyone welcome to the fifth episode of podcast. I want to start by apologizing for not putting out at podcast for so long. What happened was I wasn't making the progress, I wanted onto my book, the "JavaScript Framework" guide, so I decided to focus on it for a few months, finish it and then get back to a more regular podcasting schedule. [0:46] The good news is it worked and I finished the book. It's about 270 pages and five hours of screencast and video interviews. So, if you haven't already, go to javascriptframeworkguide.com and get your free sample chapter. [1:00] The full title of the book is "JavaScript Framework Guide | AngularJS, Backbone, Ember, Confidently Choosing and Quickly Learning)." If you're interested in these JavaScript frameworks but haven't been able to keep up with the rapid pace of change, the book will help you quickly get up to speed with the whole bunch of the frameworks. I like to say, "You can read one book instead of five books." That's javascriptframeworkguide.com. [1:23] I'm planning on doing a lot more podcast episodes in the coming months now that the book is finished, and I've got some great guest signed up. If you haven't subscribed to the podcast, please do so by going to the iTunes store on your phone or desktop, then searching for Front-End or via RSS by going to frontendcast.com We are also available on Stitcher. [1:42] If you have already subscribed, then please take the time to leave a review on iTunes. This is the best way for people to find out about the show. Today's interview is with Brian Woodward and was recorded a half a year ago now and focuses on his early experiences with AngularJS and is very valuable. [1:57] He also mentions his open source project Assemble at Assemble.io, which is a static site generator for Grunt.js, Yeomnan and Node.js that has rapidly gained a following in the last half year so you should also go and check it out. Here's the interview. Craig: [2:15] Hi, Brian. Thanks for joining me today. Brian Woodward: [2:17] Hi. Thanks for having me. Craig: [2:18] Tell us a little bit about yourself, a little bit about your background before we get started. Brian: [2:21] I've been doing .NET development mostly for about 10 years. I recently left doing enterprise work to create a start-up called Cellside. My last year, I've been focusing a lot on open source software. I'm one of the main developers on a project called Assemble, which is a Node.js build tool basically. Craig: [2:43] The reason why I asked you to be on the podcast was I'm looking for people, some real world experience with some of the java scripts, MVC, MV* framework, the single page app stuff. It seemed like you had some good experience with the AngularJS. [2:56] Can you tell us a little bit more about that project? Just maybe describe what the app did to start there and dig in deeper? Brian: [3:03] The main goal of the app was to create a portal-type website for some of the clients that we had to expose some documents to them that they usually couldn't get to or that they had to call in and get to. [3:16] The application itself was built, the front end was AngularJS and the back end was ASP.net MVC. We used the web API to connect to the front end. Craig: [3:28] Tell me more. It's housing documents like a sharepoint type thing or like a smaller sharepoint or folder, structure, and stuff built into it. Tell me more about the interfacing, what it looked like. Brian: [3:40] In the previous solution, some documents that have been stored on sharepoint, but people would have to call into the company and sharepoint was only exposed internally. Other documents were just emails that would get sent out sometimes as memos or just PDF files, things like that that weren't really stored anywhere. [3:59] They were still sent to the customers or the clients. We just decided that we wanted to have a central place, a sharepoint was considered, but I think at the time there was security issues with it. Not security issues. It might have been licensing or just being it would have exposed it outside of our network. [4:18] We didn't want to do that. Then we opted to be able to create a different front end so we could have our own security mechanism. Craig: [4:23] That helps give me an appreciation for it. Do you remember which version of AngularJS you used for the project? Roughly, I mean. Brian: [4:30] I think it was 1.02. Something similar to that. It was before they released the animation directives. I remember that part. Craig: [4:41] How long ago did you start work on that application? Give me an idea of the timeline like how long you worked on it. That sort of thing. Brian: [4:47] This application started, I think about six months ago. It would have been about July 2013. Craig: [4:54] Worked like three months, six months on it? Brian: [4:56] Yeah, it was a few months. We had it in test pretty quickly. There was another application that was built that we used some of the same infrastructure pieces that was a knockout-based application. It helped us by reusing some of the server side code. [5:10] We were able to just put a new front end on with Angular instead of knockout. Craig: [5:15] How big was the team you were working on when you were working with Angular? Just you working most of the time or was there a couple other people or? Brian: [5:21] The actual team might have had four or five people on it. Two of us were dedicated to it. Two other people kind of floated around on it but they didn't spend too much time working on it. Craig: [5:32] Did you guys specialize service-side versus client-side stuff or did you do a little bit of both each and that sort of thing? Brian: [5:38] A little bit of both. The database stuff was mostly on me and one other guy that wasn't dedicated on it. That's why he's coming in to do some of the database parts, which was SQL Server database. Craig: [5:50] Can you talk about what are the dependencies and libraries you worked with on the project like jQuery, jQuery UI or whatever you might have to include with Bootstrap, that sort of thing? Any of that stuff that might...? Brian: [6:02] For the CSS, we started with Bootstrap. Then that was highly customized for our own look and feel. We customized it directly through CSS. We didn't use the raw less files or anything like that and [indecipherable 00:06:15] . We use jQuery in a few places but not for much. [6:19] We try to use the UI Bootstrap project from any UI team and to try to get that working, but most of the controls that we had were just basic Angular directives. We didn't need to pull in a lot of special functionality. [6:35] The one that we used mostly was the calendar control, which is an actual Bootstrap version that is a jQuery UI wrapped calendar. That one took some time to figure out and get working but it looked a lot nicer. It saved us a lot of dead time. Craig: [6:52] What about testing? Angular has a great testing story. They do a lot of testing. Some people though don't quite get to the testing because it's a lot to learn the new framework, deadlines and so forth. How did it go for you? Brian: [7:07] We didn't have any UI test. Any of the E2E test that they have, we actually didn't do any of those mainly -- it's a bad excuse, but it was the time frame that we're working in the server side. Craig: [7:21] Just to clarify for the listeners the E2E... Brian: [7:22] Oh, end-to-end testing. Craig: [7:23] It's sort of a functional test what you would normally use Selenium or something like that, but Angular has a built-in test runner for those end-to-end tests. [7:33] I think it's based on Jasmine style testing but I think they've changed it up a little bit and have their own type of binding so you can natively just run Angular controller or something like that, get the dependency injection that they provide on a regular app. Craig: [7:50] Not many E2E test but lots of unit tests. Is that what you're saying? Brian: [7:56] We had unit test on the server side for most of our stuff that we're doing. We didn't have a lot of business logic in the client-side of the app. We didn't really get in a lot of unit test because it was mostly just point data and displaying data. There was not much to... [8:12] [crosstalk] Craig: [8:12] A lot of business logic stayed up in the server actually. Talk to me about the process he used for choosing AngularJS over the other frameworks. You mentioned having done some work with Knockout on the project before. [8:25] Some work could have been done with Knockout. Tell me what kinds of things you read, looked at and what made you set on and go to JS? Brian: [8:31] There was a previous project that we used Knockout on. I like the way that Knockout does observables and bindings in that way. There wasn't a great way to do views, that was just a basic Knockout thing. Knockout was for binding. [8:51] We looked at Backbone. I like Backbone for getting data from the server and everything like that, but I didn't like the way they did binding or their view things. I know that there's a Backbone.Marionette project, which I tried out and used. [9:08] It made a lot easier for view management doing single page apps. I still didn't like how there's so much code that was involved for setting up basic bindings. Angular seemed to solve a lot of those problems for us because we could use the HTTP service, which is pretty much just jQuery.ajax wrapper and to be able to get to our rest end points and pool data in. [9:32] Then we could just take a plain old JavaScript object and stick it into the AngularJS scope. Then everything was just watched for observables. You didn't have to declare anything. You had the entire deep object being able to be watched. Craig: [9:49] In the app, were people uploading documents as well as viewing them in list as well as on an individual detail? Can you describe that a little more now that we're deep into this? Brian: [10:02] The app actually had two sides to it. The front-end that we kept calling it was the client-facing on the Internet side of it and that part they could only view and download documents. The admin side of it was on our internal Internet. On that we could upload documents. Some of the issues that we ran into was uploading through Angular to the MBC back end. [10:26] Initially, I tried doing it with asynchronous web API calls for, .NET. But we found out that the asynch calls run under a different app pool identity, or they run under the actual app pool identity instead of the intended user that we wanted to run under, so we were having a ton of permission issues. [10:45] We found out that it was all to do with multi-threading. I wasn't very good with that stuff. I was like, "I'm not doing any of this asynch stuff," and we finally got the uploading to work. We had to use another component, too, which I think was a jQuery-based UI component that had a Angular wrapper. [11:03] That was another one of those directives that helped save a lot of development time by going out and finding something instead of trying to build something yourself. Craig: [11:12] I definitely had some challenges building directives that wrapped controls myself, but it sounds like you found one that did what you needed it to out of the box and so forth. Brian: [11:21] Yeah. One of our biggest issues was we had to support Internet Explorer 8. A lot of the frameworks out there for uploading documents through Ajax did HTML 5. You didn't have that available to you. The other ones fell back onto Flash and things like that. I think that's the one that we picked, falls back to Flash, to the uploads. Craig: [11:45] Maybe we can throw the link to that component in the show notes or something like that. Brian: [11:48] Yeah. Craig: [11:49] I think that would be useful for people, probably save them looking all around. [laughs] One thing I wanted to touch back on was you mentioned Knockout didn't really do the views. Can you elaborate on your thinking around that? I know that has a really good data binding story but what was your concern with the views there? Brian: [12:07] I guess what I meant to say was mostly routing. Angular binds to the views that are HTML fine. In some cases, some of the issues that I did have though were when you tried to do nested type of binding scenarios. If you wanted to have one controller over a larger page, then you had to have another controller internally, or underneath, a child, I guess, of it. But your binding would complain sometimes, or things wouldn't bind properly. But then the routing, I didn't find a good solution for being able to swap views out, to be able to give it a single page app type view. Craig: [12:47] That makes sense. How did it go during development? What did you like the most about working with AngularJS? Talk about that first. Brian: [12:55] One of the things that we focused on was making sure that we had our code separated out of our views because with ASP.NET, it's really easy to just put all of your JavaScript into the CS-HTML page. We made sure that we didn't do that, we used Angular's module system to try to build out small modules for the different services and the factories and our controllers and everything, to be able to pull those in. [13:20] It just made everything feel clean and separated and easy to work on, especially with multiple people working on it. We could focus on one component of the site instead of everyone trying to put all the spaghetti code in the single file or something. Craig: [13:38] That was one of the more enjoyable parts of it, was how organized you felt like the modular things got? Brian: [13:42] Yeah. Craig: [13:43] Did you use RequireJS or any of those new technologies for the modularity or were you just kind of managing it yourself? Brian: [13:49] We did not use RequireJS. We used Angular's module system, which they have internally, which sometimes isn't as good as RequireJS. However, for pushing everything up and making sure that everything was available on the page we used ASP.NET's bundling API. [14:08] That was a lot easier to do by just pointing at a little [indecipherable 00:14:11] string for the controllers or the directors or whatever we had. Then they would just bundle up and we could just toggle the switch for production mode and they were modified and bundled. Craig: [14:23] What were some of the tough things, confusing and problematic things, that you ran into with AngularJS? Brian: [14:28] The biggest issue we had, again, was in Internet Explorer 8, using Angular with Bootstrap, because one of the regular Bootstrap controls is for drop-down menus and the way that it requires it to work is by putting the empty href tag in there to get your menu to drop down. With Angular routing, it was causing issues and causing Angular to go into a loop. One of my co-workers got his Internet Explorer instance up to about 2 gigs of memory usage, just because it had that hole in it. [15:02] But we were able to solve that, though, by finding a workaround by just in your anchor tag you can just put a "target equals self" and that just makes the problem go away. That was for Internet Explorer 8. Craig: [15:13] When you mentioned about the challenges you were having with the menu and having to put the "target equals self" on that, can you elaborate a little bit more on that, clarify it for the listeners? Brian: [15:21] Yeah, In Bootstrap, to define a navigation menu you use a UL, an Unalert List with the list items. You can create different sections in there at the different LI levels using hrefs tags. The hrefs don't link anywhere. They just have a hash-tag marker and Twitter's Bootstrap picks that up and is able to use the CSS to be able to create your drop-down menu and do the actions that it needs to do. [15:53] But Angular also uses that same convention to do its routing. When you hit the hash-tag, it tries to find the root route and redirect you there. But in Angular, if you do a "target equals self" on an href tag, Angular won't pick that up and won't compile it. When we did this, that was our solution. That was what we found and that's how we figured out how to solve it so we didn't have the issue and we could still use the Bootstrap menu. [16:21] However, after that, I found out about UI router, which is another project by the AngularUI team. I think that if I would have plugged that in, it might have solved our problem without us having to do the workaround. But I never got a chance to do it because we just finished the code and shipped it that way. We weren't trying to put in a whole new routing system after we already had the project done. Craig: [16:44] Right. I think that will be helpful to our listeners. That's like a little gotcha hanging out there to know about. What do you wish you would have known about AngularJS or read more about before you started the project? [16:56] Is there a part where you felt like you never knew it enough or you wished, that something kind of snuck up on you and gotcha that you weren't expecting? Brian: [17:03] Like I said the first time was that UI router. I wish I would have known a little bit more because our hierarchy for our routes were similar to what it wants to do instead of the basic every single page has its own URL type thing. [17:20] The other thing is I think is how to get interaction with jQuery, because there are so many people familiar with jQuery and how you can do DOM manipulation with it, where Angular kind of frowns upon doing DOM manipulation in your controllers and all that and would rather have you write directives to be able to do that. [17:40] It's not that big of a deal, but there are so many tools out there that jQuery has already built around that do your DOM changes or whatever, you just have to wrap them, pretty much. That's why it's good to find these other projects, like UI Bootstrap or whatever. I think there is a jQuery UI one, too. Craig: [18:00] That's helpful. Let's talk about architecture for a little bit. You mentioned on the server side you were using .NET and Web API. You kind of answered that bit of the question, so talk about syncing your model to the server and how you guys architected that with your solution. Brian: [18:19] When you mentioned syncing, I always think about Backbone and how sync works and how it seems like it's automatic because it basically, just any time you update your model on the client side it goes back. [18:30] Where Angular doesn't do that by default, so actually in this app, we didn't have any issues with having to poll to get data or anything, so we basically just, whenever you loaded up a page, we would go and pull the data from our Web API service and display the data there and then based on the user actions when we would send it back through to the back-end. [18:54] To be able to make this easier for us, we built a generic service that just wraps the HTTP AngularJS service and we would be able to just pass in our route that we were going to take and our data and then optionally give it a type, like a POST or GET or PUT or whatever, based on our security concerns, because this was for a financial company and we had a lot of auditing and things like that. Most of our default was POST, even when we were pulling data we would POST to the server to get the data back instead of doing a GET. [19:28] We wrapped it that way and then the generic HTTP service was wrapped in, I call them domain specific services, so for users, or for documents, memos, things like that, each one of them had their own Angular service and that way we could specify the routes for getting and putting or posting without having to specify those routes in our controller, so if the routes changed, then we could just change them in one place. [19:57] Then all the controllers used those domain specific services to be able to get whatever list of data that we needed to be able to show on the screen. [20:08] Then all the post or whatever were based on user action. In this app, we didn't do any kind of automatic syncing. In another app that we built that wasn't architected as nicely, we wrapped a lot of things with Angular's watch function to be able to detect if there are changes and based on some of the changes do polling and things like that to try get data to automatically sync up and change the UI for the user to notify, or something like that. Craig: [20:37] That just wasn't needed in this app? Or, you felt like you had finer grained control with the approach you on this that you described? Brian: [20:45] We didn't need it, because we were fine with the users having to either refresh a page or move to another page to view the data. There wasn't anything that changed frequently on the server side that we had to keep an eye on. Craig: [20:58] You talked about the database being SQL Server and Web API. Did you use Entity framework or LINQ to SQL or anything like that, or did you do custom ADO .NET code. How did you wire that side? Brian: [21:10] The company that had this art database was a very large database on SQL Server and we built a lot of small apps on top of it, mostly internal, this was only, I think, the second or third external facing app. We used our frameworks that we had already, so we had some custom built, mostly wrapped around ADO.NET type of data pool stuff, but that would get the information and then we used Web API to expose it. [21:37] On the client facing part of it, the external Internet part, that Web API was exposed to another server that was outside of the firewall, so we had custom authentication that was passing through that way, using the web client and Web API 4 or MVC 4. [21:57] Then the people using the front end of the site, we had just a regular membership provider type ASP.NET membership provider set up and created their passwords and user names and all that, just like a regular website that wasn't using the Windows Security to do. Just regular forms security. Craig: [22:17] Forms authentication, role stuff. Backbone apps tend to be a lot about the model and there's a lot in the framework about the model, whereas Angular focuses more on the declarative UI, the data-binding and the good testing story, and so forth, but they can't pride themselves on the plain old JavaScript objects. Did you find yourself sort of missing the kinds of things in that are in Backbone, like events, or the ability to extend from a base object, that sort of thing? You mentioned a lot of the business logic was on the server, so maybe that wasn't an issue. Brian: [22:50] Some of the patterns that we followed, we created some regular JavaScript files that weren't in an Angular module at all, and we put them into our known namespace on the window in the browser so that way if we were going to create a new memo object, we could just pull that from our namespace. Do it like a new app.models.memo, and then be able to pass in some stuff, or whatever, and we'd get our default structure so then that way we weren't sure we were passing that back to the REST service properly. [23:24] We didn't do any base class or anything like that to wrap anything or to inherit from, which usually you do with Backbone to get your listeners or events or things like that. I think Angular does have an eventing system, like an event emitter type thing that you can use. We didn't take advantage of that at all. Looking back, I probably would if we were doing more on the server side for setting notifications up to be able to say "A new document's ready for you to view" or something like that, but we never really had the need for that. Craig: [24:02] Just curious to dig into this a little bit more. You had your factories or your services that were returning entities. Did you say services before or did you guys use factories? Brian: [indecipherable 00:24:13] [24:13] staff for me. To me it's all the same. Factories, service or provider. Provider? We didn't use the providers at all because we didn't really have configurations that were different. That could have been something that would have been interesting to do, going back on it, because then we could have set up our URLs for the REST services that way. But I think we used either service or factory. Craig: [24:38] There's such a slight difference. Give me an example of what a service or factory would look like and what kind of methods were on it, and what it returned, and that sort of thing. Brian: [24:47] We usually had the basic CRUD methods on there, so we had a get and a save, or sometimes we had an additional methods for getting a list of information or a getting a single item. We had a lot of drop-down menus for different things that we call service's. Since those had to be used on almost every page to show whatever service you were looking at or to be able to select the service, that's why we build the services to be able to get that list for any page that we were on. [25:19] The service also allowed us to cache if we needed to. You load up the page. Since it's a single page app, your JavaScript code is all there already. You basically have a fat client on the browser. The first call, we would pull the list of services and those wouldn't change often. [25:37] The service would take care of caching that information on the browser just by storing it into a list and then the next call to that function would just return the previous list that was brought up. We reduced our network calls that way. Craig: [25:50] Was there a mapping between what the object coming back from the RESTful service looked like to your client side model and was that done inside the service? Brian: [26:01] Most of our mapping, we had models on the server side in C# and the Web API does a good job of mapping all the stuff to a JSON object. We basically just took advantage of that. We didn't really do anything else for that. Except, we also would create objects wherever we had to create a new object in JavaScript. That's when we basically create a schema, I guess you would say, just a skeleton of what the object would look like so that we'd ensure that we would have the same column names or property names and everything like that. Craig: [26:39] Except for on the creation of a new object name on the client, you really didn't have a mapping between what the server was sending back in terms of JSON and the client object model because it was just clean enough that you could use it as is... Brian: [26:52] We mostly handled everything in C# for that. I can see another pattern where you're doing different types of translations on objects or creating additional properties and things like that, it would be nice to pass a plain old object into a constructor for a JavaScript object and then you can get additional properties on that and pass that to Angular into the scope, but we didn't have a case for that. Craig: [27:19] Would you say your app was, this is going back more of a navigation thing or URL thing. There's a lot of conversation around, "Should an app be a strictly single page app and never reload", or "Should there be islands of functionality or silos of functionality." How did you guys end up with your applications? Brian: [27:37] On our admin side, it was a single page app completely. There is one main controller that returns an index view that just had the ng-view tag and that was it for our admin part. We had a template controller that would return any other CH.HTML pages, then this way we could use still use Razor syntax to do some findings on the server side if we needed to. That was a true single-page app. [28:04] On the client side, just because we wanted to take a little finer grained advantage of the request token, I'm blanking on the full name of it. It's the anti-forgery request token. We want to do that, so all of our account management type pages, log-in, log-out, password change type stuff, were all their own page, so it was rendered from the server and then brought up and then posted back to the server. Then the internal part of it was all single-paged app, other than that. Craig: [28:41] Do you touch a little on the deployment process and build tools and maybe talk about what IDE did you use, Visual Studio for most of the development or did you have a text editor. Talk about how that worked for you on the project. Brian: [28:54] We used all Visual Studio 2012. We never got into 2013 at the time, which I think has new tools that I haven't checked out yet for doing a lot of JavaScript stuff. We did all Visual Studio on our deployments because it was an enterprise and we already had the infrastructure for our other stuff. We used TFS and we'd check-in there and then there's a build server that builds everything. We would have different config files, web config so we could specify if it was a dev or production environment to be able to do the bundling and minification properly. [29:29] For the front end stuff that's really all that was different in the different environments was the bundling. Craig: [29:35] This was really helpful. I think the listeners will get a lot from this and from your experience with Angular and I really appreciate you being on the show today. Brian: [29:44] Thanks for having me on here. I like talking about this stuff. Any time I can find someone. Craig: [29:50] Thanks. [29:52] [background music] Craig: [29:55] Thanks for listening to the Front-End Developer Podcast. Please subscribe to the podcast by going to the iTunes store on your phone or desktop, then searching for "front end" or via RSS by going to frontendcast.com where you'll also find show notes and a full transcript of each episode. If you're interested in my book I mentioned earlier, go to javascriptframeworkguide.com and check it out. Thanks. We'll see you next time. The post Using AngularJS to build a Portal with Brian Woodward| Episode 5 appeared first on Funny Ant.
April 13, 2014
On this episode I interview Rhys Bret-Bowen, Google Engineer, about using AngularJS to build applications for Google.  This is front-end developer cast episode 4. This interview is with Rhys Bret-Bowen who is a Google Engineer currently using AngularJS to build applications for Google.  We discuss his experiences good and bad with AngularJS and talk about details of the Google technology stack for the project which I found fascinating.  In particular, they are using ProtoBuf (Protocol Buffers – Google’s data interchange format) and the Closure Compiler. Tweet To subscribe to the podcast, please use the links below: Click Here to Subscribe via iTunes Click Here to Subscribe via RSS (non-iTunes feed) Show Notes: Resources Closure Protocal Buffers Rhys’s blog Rhys’s GitHub Full Transcript Craig McKeachie: [0:01] On this episode I interview Rhys Brett-Bowen, Google Engineer, about using AnguarJS to build applications for Google. This is “Front-End Developer Cast, Episode 4.” [theme music] Craig: [0:19] Welcome to the Front-End Developer Cast, the podcast that helps developers be awesome at building ambitious web applications, whether you’re JavaScript ninja or you’re just getting started. I’m your host, Craig McKeachie. [0:31] Hi everyone. Welcome to the fourth episode of the podcast. I’m working today on getting my processes down for the podcast, as well as, hiring some help editing the podcast and getting it live on the site every two weeks. So I’ll be able to more easily keep bringing you more great interviews. [0:44] I’m also getting help designing and setting up a page to sell my book on mastering single-page applications. The book, right now, I’m finishing the last couple of chapters, editing and working through some ember.js code samples. I’m hoping to make the book available for pre-sale at a 20 percent discount in the next few weeks. [1:01] If you have any interest or you want some more great free content, go to my blog at “funnyant.com“. That’s funnyant.com. Sign up for my free seven day e-course, the “JavaScript MVC Comparison” and you’ll get notified when the book launches. [1:17] If you haven’t subscribed to the podcast, please do so by going to the iTunes Store on your phone or desktop, then searching for “Front-End” or via RSS by going to funnyant.com. We are also available on “Stitcher”. [1:29] If you’ve already subscribed then take the time to leave a review on iTunes. This is the best way for other people to find out about the show. [1:35] Today’s interviewee is Rhys Brett-Bowen, who is a Google Engineer currently using AngularJS to build applications for Google. We discuss his experiences good and bad with AngularJS, and talk about details of the Google technology stack for the project which I found fascinating. [1:50] In particular, they are using ProtoBuf, which is short for Protocol Buffers, Google’s data interchange format, and the Closure Compiler. [1:59] Here’s the interview. [2:00] Hi, I’ve got Rhys Brett-Bowen with me today. He is a Google Engineer at Google in their New York office and has been working with Angular on their most recent project. We’re going to talk through his experience with that, as well as, some of the other tools they use it Google, and the JavaScript, and front-end web development space. Welcome to the program. Rhys Brett-Bowen: [2:21] Thank you. Craig: [2:22] Tell me about the app you’re working on. Maybe not from a technical standpoint at first, but what does the app do? So the end-users have a feel of the UI and that sort of thing. Rhys: [2:33] I am working on a BitManager team. What we’re currently working on is the reporting page. It’s not exactly a quick app. It’s all done in Java and that gets compiled down into JavaScript. [2:45] What we’re doing now is, and in a lot of places in Google, we’re looking at trying to move things over to using Angular. We’re looking at changing just the recording section at first, to use Angular. That’s what we’re doing. It’s a list of reports that you can run. Different types of metrics, filters. and things that you can choose on the report to run. Craig: [3:06] Is this “Google AdWords” that you’d be working on? Rhys: [3:08] No, it’s something called BitManager. It does dynamic reading of prices when the apps go out. Craig: [3:22] That’s very interesting. Which version of Angular are you guys building this app with? Rhys: [3:27] The latest one, it’s 1.2. Craig: [3:32] Was there any browser considerations when you guys made that decision in terms of supporting versions of IE or not supporting that sort of thing? Rhys: [3:39] I feel like regressing, they’re dropping IE 8. [laughter] Rhys: [3:43] I don’t think you can really choose Angular 1.2 or 3, we’re going to get that back. Traditionally Google does like to encompass as many browsers because it’s not out there for the ready. Internet use is there for specific clients. [3:57] We don’t have to worry too much about which browser or IE 8 or all the browsers. Craig: [4:03] Version 1.2 does not support IE 8 back, is that correct? Rhys: [4:08] I don’t believe it does. They’re dropping it soon. Craig: [4:11] You’re dropping it soon. I definitely heard that. I was trying to remember if that’s 1.2 or the version after that, whatever they’re going after that. I’ll look that up and put it in the show notes for our listeners. Can you give me an idea of how long you’ve been working on the app and whether it’s in production or whether you’re still working on it? Rhys: [4:27] I’ve been there for a couple of months now. I’ve only been working on it for two months,taking it from nothing to where it is. It’s not in production. It’s getting close to a point where we can at least start putting it out to beta users. [4:42] A lot of the time we’ve spent on it is figuring out how to use Angular going forward for people. Whether or not for the other developers who are going to come in and, as we go on, what are the best practices to use, how we should set up the app, and all that stuff. Craig: [4:59] You’re setting up a framework for the framework, right? [laughs] Rhys: [5:01] Yeah. [laughs] Craig: [5:04] What other dependencies in libraries and so forth are you using on the project? Rhys: [5:08] We’re working with closure tools which has a compile. We have to make it so that it works with the compiler. The compiler does some things like renaming of variables so and so and places you have to make sure things like new quick keys and objects — they get their strings, if they’re going to be exported to the template. [5:28] Thing about an Angular application is that all your logic and all your code isn’t exactly in JS files. A lot of them can be in templates. If you want your template to be able to access a property that’s there, you have to be aware of whether or not that property name is still going to be there or is it going to be compiled away. [5:47] You have to figure out which of those properties you want to export so that you can keep that in line. Craig: [5:53] It compiles away templates as well. I didn’t realize that Closure… Rhys: [5:57] Oh, no. It doesn’t compile a template. That’s the problem. [laughs] Craig: [5:59] OK. Rhys: [6:00] It’s not that good yet. They’ve done a lot of things around the dependency-injection. Before, when you had dependency-injection — Angular does a thing where it looks at the function of two strings to find out what the class it should inject into the services and so on that they have. That name can get changed when you run it through a compiler. [6:24] Then that does not match to the string that you’ve got anymore. They’ve done things where, the compiler can look at things like annotations that you put on comments before functions. It looks for the special annotations, called nginject, and that just tells the compiler, “Wait a second, we actually want to inject this. [6:42] This is what Angular’s going to be injecting into, so don’t rename these certain properties.” Craig: [6:47] It’s mostly things, either properties or things, being passed in the constructor as dependencies, and you don’t want to rename them because then the code would break at that point. Rhys: [6:58] Any variables that you’re just using inside a function, that’s fine to rename. The problem is when you’re sharing things like objects of properties or anything across functions or across files. [7:09] If it gets renamed, you’re going to have a problem because they might get renamed in two different things or maybe one does not get compiled. So then it’s expecting the original name and it didn’t compile that. [7:20] Closure does a great job of renaming things even when they’re across files, but it only really works if it has all the code to look through. It parses all your JavaScript and figures out what things are being passed to where, so it knows to keep the names the same. [7:36] Fortunately, with things like Angular, it can’t parse the templates, so you can’t tell what things you’re going to be using in the template. It doesn’t know not to rename those, so you’ve got to tell it not to. Craig: [7:46] Interesting. Does that make for some noise in the code that, at least I personally wouldn’t appreciate, or you’re used to it and it’s not a big deal? Rhys: [7:54] I’ve been using Closure for a while now, so I’m used to it. Although, when I originally used it, it was just in one giant application so you didn’t have to worry about the renaming. Usually, it will all work. As long as you give it all the code, it will work. [8:07] The problem is — it’s not too bad. All it means is whenever you’re defining things that are going to be in the template, there’s a certain comment that you put on it saying, “Export.” Which is to say, “This is going to be an exporter probably. Don’t rename it.” Rhys: [8:21] There’s the nginject one. As long as you’ve got those two in there, it fixes everything. Craig: [8:25] OK. Rhys: [8:27] These annotations that are going in, if you’re doing things with Closure, you want them in there anyway, because the annotations, you can also put things like type information against. When you do your compile checks, it’ll check things like types across files and so on. [8:42] You know it can catch a lot of errors that way. While you’re doing it, you check on an export saying, “Oh, what’s a type, this, and I also want this to be available to the template.” Craig: [8:49] OK. That’s helpful. For some people, the concept of a JavaScript compiler is a new concept. I’m maybe oversimplifying what I think about it as minification and combining, but it’s not just that. It’s more complex. The Closure one is more complex than that, right? It is all about making the code small and tight, but it’s doing a lot more elaborate things, correct? Rhys: [9:14] Yeah. There’s that, and it can increase performance by figuring out where things go. It even knows a little bit about gzip, so it will not only try and make the code smaller, it’ll make it smaller for when you gzip it up. It does check types and so on. –information for you. If you’re working a team, you know what type of types are going into functions. [9:33] It’ll throw out errors saying, “You’ve created a new function. It doesn’t work with the type that you’ve given.” It does a lot of things. At first it seems a bit scary, [laughs] but once you get the hang of it, it helps speed up. A lot of the problems you come up against JavaScript, you only find at runtime. It’ll find those for you. [9:50] If you’re passing the wrong type, it’s not going to throw an error in JavaScript until you run it. Even then, it may not throw an error, because you can have type coercion and so on. If you try and say, console-log something or print something to a screen, you might be passing an object instead of a string. You wouldn’t know that. It’ll print an object happily enough for you. [10:07] It’s just going to have curly braces, and you’re going to think, “Why is that there?” These things can go into the program. They can be deep and they can be hard to find. Craig: [10:14] This is more about the linting part of the compiler, correct or am I overstating? Rhys: [10:19] Linting is more how the code looks. It’s not the types and the things you pass through. It gives you type checking which you get from a lot of stronger type languages like Java and so on. We define the types. It’s kind of like that. [10:32] It’s like typescript, where you can put types of things and it will throw errors if you put the wrong type in the wrong place. Craig: [10:39] Thanks, I think that helps. Any UI libraries or do you guys stay away from that stuff on the project? For the animations, you mentioned some reporting — D3 or anything like that? Rhys: [10:50] We haven’t…What we’re doing is we’re currently creating the report. You have another thing that displays reports. Most of the reports that come out of [inaudible 00:10:57] CSV format, so we can cut and send that straight to the boot. A lot of avatars — They like to work with Excel, so we give them that. [11:07] There will be something coming out with visualizations and so on. We’ll definitely be looking at get D3 to do that. Craig: [11:15] How much testing are you guys doing on the project so far? What testing stories — both end to end and unit? Rhys: [11:22] At the moment we’re putting everything under unit testing. Everything we’re creating we’re making tests around. End to end testing is something we haven’t started yet. We’re looking at hopefully trying to use Protractor for that, because it’s at Google. [11:36] There are also other Google technologies. It’s a bit strange how it’s run and how it’s built. We’ve got to find out exactly…a little bit more fiddly to get the set up there. Everything at Google, they try and do at scale. Everything’s a little bit more fiddly to set up, but once you do it will run for ever. We’ve got to do a bit more research into that and figure out how we’re going run it. Craig: [11:56] Why not — It’s Google. Why not Karma and formerly know as Testacular? Why? Rhys: [12:02] We do use those to run unit tests. End to end testing, integration tests is a different beast altogether. Craig: [12:12] What was the process for you? Were you on the project at a time when the technology was chosen and if so, what was the process for choosing Angular versus other beasts, C frameworks, or other frameworks? [12:26] Rhys, No, I don’t think I’ve ever been on a project which gets to choose a technology. I usually get called in at a time when people want to fix it up. [laughs] “That’s not working for us. Can you help me out?” That tends to be the time when I join teams for some reason. Craig: [12:41] Then there’s the obvious thing, that you are working Google. It’s a framework supported by Google. Rhys: [12:47] Yep. Craig: [12:48] That’s a pretty good choice. How’s it going so far? In terms of what comment on your experience with the features and so forth. What have you really liked when using Angular? Then we’ll move to the cons, I guess? Rhys: [13:07] Using Angular, it’s been a bit of fun really. There are some things to try and get your head around, but once you do it does starts to make a lot of sense, especially how things are built. The Angular code itself, if you go and read that, it’s not too bad to figure out how things are working and what things are doing. [13:25] Most people say background track because you can read it in a day. Angular might take you two days. You can still do it. There’s still parts of it you can go in and realize what’s happening and how things are working. That’s a lot of things I like about it, it works like magic in some places. Sometimes you can throw your hand and say, “Why isn’t this working?” [13:45] That’s only on the first couple of days if you start using it. Afterwards you realize what some of the best practices are for it and that’ll keep you away from a lot of errors. Even things like when you’re dealing with scope. Instead of trying to use a single property on the scope tree, you want to have an object on the scope, then deal with properties on that object. [14:06] Using that will keep you away from a lot of scope problems. Craig: [14:09] What kind of problems have you seen? By putting a property directly on scope as opposed to an object with a property? I’ve definitely heard this before. Rhys: [14:18] Probably a big example is when you use a directive it may create a new scope. When you try and deal with new…Scope in Angular works like prototypes inherent in JavaScript. [14:33] If you put a property on a prototype, and use this.something equals in JavaScript, you won’t overwrite…depending on the prototype, you’ll overwrite the thing on the instance. Scope’s the same way. If you get an inner scope and you try and overwrite the property, all you’re doing is changing the property of that inner scope. It’s not going to change the one on the outer scope. [14:54] You come across things like that with, probably, directives that you don’t expect to create new scopes. Things like the transclue — Anything you transclue, ngtransclue creates a new scope trial. If you’ve got anything within that, a lot of the time that you come across things like… Craig: [15:10] So, people get scared by the word transclue. Can you break that down for us? It’s rather simple, as I remember, when you learn it, but… Rhys: [15:16] Transclue is very easy. It means put whatever inside the element. When you have a transclued… Craig: [15:25] So, there’s no spacetime continuum happening there or anything? Rhys: [15:27] No, it’s just something not fancy, unfortunately. It would be cool if it did. Craig: [15:34] If you have an existing dom element and it has some content inside of it, it means leave that there as well as append to it, or it means…? Rhys: [15:41] It takes the child away. Put in a temporary variable for the moment. [15:47] Whatever the template is, it puts that template in its spot. Then it looks through that to find out the element that says ngtransclue. That’s just a little marker that says, “Put the content back in its spot.” That’s all it is. It just means that everything in that template you put in also has its own scope. [16:03] It’s called an isolate scope, because it doesn’t have anything to do with any other scope around. It has its own properties. Then everything within the ngtransclue that you put in, inherits the scope from before, so that everything you put in there works as you expect, except that it’s in a new scope, that’s inherited from the old one. [16:21] It just gives you another level down in the scopes. All your properties are there and you can get to them, but the thing is, if you try to apply to that, you’re trying to apply on the instance rather than the prototype from the example before. Craig: [16:38] That’s a good explanation. Thanks. What did you find confusing or problematic when you first started working? You touched on a few things already. Rhys: [16:49] A lot of people said the documentation isn’t the best. Craig: [16:54] Comical though, sometimes reading the comments underneath. Rhys: [16:58] I find that about 50 percent of the time I go looking for answer. The answer I’m looking for isn’t there. You try and figure it out for yourself. I guess if someone wrote the documentation as they were trying to build the Angular update, it would probably be better, because then they would say, “This is the kind of thing I want to know, maybe I can go and add that into the documentation.” [17:16] That was the hardest thing, trying to figure things out to begin with. Craig: [17:20] What are the things you really like? Data binding is a common feature that’s demoed. Does the gloss wear off on that after using it for a while or do you…? Rhys: [17:32] People talk about two-way in data binding. Date binding is extremely useful. — two-way data binding, not so much. Craig: [17:39] Let’s talk about the differences there. That’s an interesting conversation I recently had with someone. I’d like re-have it here. Rhys: [17:47] Two-way data binding means any changes you’re making on the view will go and populate itself automatically onto the model and then vice versa. Then any other model come back. Normal data bonding means that whenever you change the model, view update. If you update the view, it’s not going to update the model. [18:00] It’s not really that big a problem because then you can always put on another directory and say “Oh, when this changes in the view, go and update the model.” You can just pop that on. Two-way data binding isn’t a huge thing, especially done through ngmodel. It’s not done with inputs anyway. It’s not a big thing about it. Craig: [18:18] In other words, most of the one-way data binding — When people talk about one-way data binding, they usually talk about going from the model to the view. That’s the most useful thing that most people need when building an app. When there is an input, sometimes it’s useful to have it go from the view back to the model automatically. You’re saving one line of code or whatever. It’s not… Rhys: [18:36] It’s a bit of syntactic sugar. Two-way data binding isn’t as big a thing as people make it out to be. That’s all it is. It means that you’ve got an extra thing that will go back and tell the model to change. [18:47] Probably the only thing that I found that I still don’t like too much about Angular is that when you put things in the template it has a scope.doublewatch. There is something on scope that’s called “Watch.” Then you pass it a function or something and then it will act to see if there are any changes. [19:05] It uses an equality comparison unless you add in an optional parameter to that watch. If you are watching an array and you change that with another array object, — or even if you have an array,it’s got things in it, and you add things to it — It’s not going to say that’s changed because the object is still the same, unless you put that true in. [19:25] That’s fine. I don’t mind that in the code. The problem is when you try and do things in the template because there is no way to pass in that optional variable to watch. Everything is done on equality. This is a problem when you’re doing things like trying to — where if you have a function that filters an array because if you return a filtered array, it’s a different array. [19:45] Every time it goes through the watch thing or it goes to check if it’s different, it’s different every time because it’s a new array that you have got there. You might have filtered with the exact same elements, but it thinks it’s different. [19:55] That’s the worst thing that I have found, that you can’t really tell in the template the array is going to be different, but check the elements under the array, don’t just check the array to see if it’s the same array. Craig: [20:05] Right. Rhys: [20:06] That’s probably the worst thing that I keep coming against. Every time that comes up saying the watch statement has gone through too many cycles, I know it is one of those somewhere around there. Craig: [20:18] Right. Have you gotten into any of the browser plug-ins to use to help debug things? Rhys: [20:24] No, I know there’s better rankings but not really. I’ve found there has been hardly any problems with it. I haven’t found any big bugs I’ve had to go too far into to find out. Craig: [20:39] Let’s see, where are we here? Let’s talk about the architecture. Sometimes frameworks like Backbone provide a lot around the model, whereas Angular prides itself in plain old JavaScript objects. Tell me about how you’re organizing things in terms of services in factories and your actual model entities and how that’s working in your application. How you’re going to set that up. Rhys: [21:04] A lot of people who use something called Protobufs. It’s not JSON. They’re different. There are still objects that come through but you have to call, get something, and set something on it. We use a lot of those to do it. [21:18] We find that using those straight from the server, we can plug in whatever we need. Originally we used Protobuf because you’re using separate languages in Java and so on. Then all you have to do is run whatever the Protobuffer thing is and it will give you the class definitions for, and how it should be, the class definitions in JavaScript, in Java and everywhere else that you want to put it. [21:39] It’s very small over the wires, as well, because it’s all done in arrays. There are no keys put in because the keys are put in the class definitions that are generated for each language. Craig: [21:48] Is this a Google specific thing or an open source? Rhys: [21:50] It’s an open source thing. Google uses it a lot because it’s small and fast. It’s not as flexible as JSON because it has information on it, like types and so on. It works well with stuff like Closure tools because types are already there and you can use it. Craig: [22:04] Oh. OK. Rhys: [22:05] It’s an open source thing and we go and use it. The difference is it’s not as flexible because you’ve got all these type considerations and so on. The great thing is you can use it with a Java backend and it will be the same thing going between them. Craig: [22:17] Right, that’s interesting. Obviously, you guys are using Java on the backend, so that the database is…? Rhys: [22:24] I don’t know, [inaudible 00:22:23] . I think it’s a proprietary thing. What they’re doing with the database is, they’ve got — they use a big table, the Google thing they use to store it. They’ve got stuff on top of that to store it different ways and do everything it needs to. Craig: [22:40] OK. We’re here at Code Mash, I didn’t mention. We’ve got some people coming in and out of the area, so don’t mind that. That covers a lot. Maybe you could talk a little bit about what you’re using. Are you using an ID or are you using a text editor bin. What’s your world like there? Rhys: [22:57] You’re allowed to use anything you want there. I use the Sublime Text, personally. Craig: [23:04] OK. Sublime Text and they’re OK with it. In terms of building the client side stuff, are you guys using Yeoman, Grunt, or Bower, any of that? Rhys: [23:14] No, we’ve got a Google-built system. They’ve got their own stuff that they do to build things. Craig: [23:20] Yeah. That makes sense. Require JS or any AMD-type stuff going on for modularity? Rhys: [23:29] Closure tools has its own thing for that. Craig: [23:31] Yeah, sorry. Rhys: [23:33] It works on name spaces. All you have to do is set up your files and at the top of it you say , “Do dot” — What is it? I don’t have a word for it now. [laughter] [crosstalk] Rhys: [23:43] Do.provide, I think it is, yeah. You do do.provide, you say, ” What name space you’re exporting from that file,” anything you need unneeded you say, “do.require” and just put that name space in. Then what they have is a runner that goes through, looks at all the files, figures out the graph of how things are dependent, and then adds them in together. Craig: [24:01] OK. Rhys: [24:03] That’s all you need to get into your work. Craig: [24:05] Did you use Closure quite a bit before this on other projects and so forth, because it sounds like it’s a big part of the picture here? Rhys: [24:13] I did. There was a company I worked at called [inaudible 00:24:16] back in San Francisco. That’s where I got introduced to Closure. Yeah, they were using plain Closure to build their system. Craig: [24:26] Great. Anything else you think listeners or front-end developers would be interested in hearing about the project that I haven’t asked? We covered everything. What about authentication in your application? Rhys: [24:37] I think that is still dealt with by the quid section at the moment. We’re trying to replace the single pages within that application as we go. It all runs in route loops so all we have to do is say in the original applications, “For this route, now open up this Angular application’s page with Angular on it.” Angular is a library. [24:57] You can say “OK, add in the Angular thing.” It will run as it needs to. You don’t have to go in and throw away your old application. That’s the wrapper for it. Craig: [25:04] Yeah, successful. Thanks for being on the podcast today, Rhys. We really appreciate it and I think the listeners will get a lot from this. I like hearing about what’s happening in the real world, especially inside Google. I’m quite intrigued. Thanks. Announcer: [25:18] Thanks for listening to the Front-end Developer podcast. Please subscribe to the podcast by going to the iTunes Store on your phone or desktop, then searching for Front-end, or via RSS by going to frontendcast.com, where you’ll also find show notes and a full transcript of each episode. We’ll see you next time. The post Using AngularJS at Google with Rhys Bret Bowen | Front-End Developer Cast Episode 4 appeared first on Funny Ant.
March 28, 2014
On this episode I interview Tom Dale, who helped create Ember.js about how Ember differentiates itself from other frameworks with a robust router as well as what’s going on with Ember.Data. This is front-end developer cast episode 3. Tom Dale helped create Ember.js which has rapidly been gaining momentum in the ongoing JavaScript MVC debate since releasing version 1 in the fall of last year. For those who aren’t as familiar Ember it’s a JavaScript MVC or Model View Whatever framework similar to AngularJS but differentiates itself with a robust router that is a full state-machine as well as supporting nested routes and templates. Tweet To subscribe to the podcast, please use the links below: Click Here to Subscribe via iTunes Click Here to Subscribe via RSS (non-iTunes feed) Show Notes: Resources Ember.js Stop Breaking the Web: Tom Dale talk at JSConf EU 2013  (demo at end of talk) Ember Data Tom Dale’s Blog  Full Transcript Craig McKeachie: [0:00] On this episode, I interviewed Tom Dale who helped create Ember.js about how Ember differentiates itself from other frameworks with a robust router as well as what’s going on with Ember data. This is Front-End Developer Cast, Episode Three. [0:14] [background music] Craig: [0:24] Welcome to the Front-End Developer Cast, the podcast that helps developers be awesome at building ambitious web applications, whether you’re a JavaScript ninja or you’re just getting started. I’m your host, Craig McKeachie. [0:35] Hi everyone. Welcome to the third episode of the podcast. I’m really excited about the great response I’ve gotten so far. If you haven’t subscribed yet, please do this in iTunes, Stitcher, or via RSS by going to frontendcast.com. The podcast is still hosted on my blog at funnyant.com, but there’s now an easier way to find the podcast. Just go to frontendcast.com. [0:58] If you’ve already subscribed, then please leave a review in iTunes. This is the best way for other people to find out about the show. [1:05] Personally, I’m still adjusting to not having an office job lately, and working on my book, but really enjoying being around my family more. I was just the mystery reader in my son’s second grade class today and got to walk him home on a nice spring day. [1:18] The book I’m writing on “Choosing a Single-Page Application Framework for Your Project,” is coming along well. [1:24] I’ve written close to 30,000 words at this point. I have just a few more chapters and lots of editing to do, but I decided to make it available for pre-sale on my site at Funnyant.com in the next couple of weeks. I’ll keep you updated. [1:37] Let’s move on to today’s interview with Tom Dale, who helped create Ember.js, which has rapidly been gaining momentum in the ongoing JavaScript MVC debates since releasing version 1 in the fall of last year. [1:48] For those who aren’t familiar with Ember, it’s a JavaScript MVC or model view whatever framework, similar to Angular.js, but differentiates itself with a robust router that is a full-state machine as well as supporting nested routes and templates. [2:01] Here’s the interview. Craig: [2:02] Hi. I’m lucky today to have Tom Dale with me, one of the creators and founders of Ember.js. Real excited to have him on the program, needs not much of an introduction here [chuckles] . Tom Dale: [2:14] Thank you Craig, thank you very much for having me. Craig: [2:15] I don’t hear a lot of people talk about, “What do you do for a day job?” and “How does this all tie back to this Ember.js stuff?” Tom: [2:21] Sure, yeah. I think a lot of people think that people who go around and travel to conferences and work on open source probably have a big corporate sugar daddy, which is maybe even true. [2:30] I think for both Yehuda and I, being independent was really important. We also didn’t want to be on the venture capital treadmill, where it’s like, raise $10 million and burn through it, and then raise another $10 million and burn through it. [2:42] Yehuda and my other two co-founders, Lea and Carl, we founded Tilde just over two years ago, and initially we made our money doing consulting. That was a way for us to run the company without having to raise venture capital. [2:55] Since then, we’ve been mostly focused on a product called “Skylight,” which is a tool for measuring the performance and fixing the performance of Rails applications. It’s actually been very nice because working on a product Skylight; it’s an Ember app sitting on top of Rails and a pretty sophisticated job of back-end. [3:12] We’re very lucky in that we get to use our open source technology on a product which is really great and then, as for supplemental income, we occasionally do some training and screen-cast and stuff like that for Ember. Slowly we have been focusing more, and more on the product. Craig McKeachie: [3:27] Is the product live and out there? Is there any product development? How does that work in terms of eating and stuff like that? Tom: [3:36] It’s definitely tough. [laughs] We’re in private beta right now, so we have a sign up list. We launched it at last year’s Rails conf- and we’ve been on boarding people very slowly, but we do have paying customers, which is nice. More than you can say for a lot of VC companies. [laughs] [3:53] We are hoping to open up soon, but the interesting thing about what we are doing, the computation that we are doing on the performance data we are collecting out of this Rails applications, is so much more sophisticated than what any of our competitors our doing. [4:05] It requires a ton of number crunching and we give you much better, much more actual data because of the number crunching so we just did not want to build a system that would crash on day one. We’ve slowly ramping it up and we have got a big refactor coming out, it’s re-written using Storm and Trident. [4:20] Very big data, real time, Java, serious business enterprise stuff. Once we roll that out, I think we will start on boarding a lot more new people. Craig: [4:29] Sounds great. That gives me a good perspective on…That you have work with framework every day, you eat your own dog food and that sort of thing and that’s great. [4:37] When do you find time to work on the project? I noticed you have a lot of contributors to the project now. Tom: [4:42] We do, yeah, and actually that’s been really great. We actually were very lucky in the early phases of the company. Yehuda and I were both working for startup called “Strobe.” [4:50] Strobe paid for us to work on what was then called “Sprout Corp 2,” and then when we left, re-branded to Ember. Since then, we’ve had very generous support from several different companies. [5:01] Living social, Square, McGrawHill Education Labs. They basically paid us for our consulting time to work on Ember, which has been just really phenomenal. [5:10] We try to make time, everyday, to work on open source whether it’s on evenings or on the weekends. We also get to get for a few hours and hack, but I’ve been so thrilled. I think we just came in and I think we set a vision for the project. [5:26] The community around Ember, especially in the last year, has just exploded. The people doing the day to do work of managing photo requests, writing new features, it’s not Yehuda and I any more. [5:37] We’re around to answer any questions, but by and large the bulk of the work is done by people just using Ember at their companies, which I think is really phenomenal. I think the reason for that is, if you think back to 2011, two, three years ago. 2011 if you wanted to build those really ambitious apps in the browser, you were kind of a pariah. [5:57] If you think about that time, there was this micro library movement. Backbone was the hottest thing on the planet. You’d read comment threads on hacker news, and they would say, “Ember is this huge library. It does all this crap. Why not use Backbone? Backbone does the same thing, but it’s much more lightweight.” [6:13] Of course, Backbone had 900 lines of code; Ember at the time had something 20,000 lines of code. They obviously didn’t do the same thing, but there was just this attitude of, “You really didn’t need these abstractions.” I think it’s because a lot of people didn’t have any experience building a real 100 percent client side app. [6:28] I think at the time, we were really the only people who were like, “You guys are crazy. You need abstractions to help you manage a larger app. You just need abstractions. All of human progress is built on building up new abstractions.” I think that really drew people who believed in that cause; that cause of, “We’re going to build awesome tooling for the browser. It might take us a couple of years, but we’re going to do it.” [6:53] I think that in the JavaScript community, we attracted some of the best and the brightest. That strategy, while it was initially painful, not being able to hire people but just needing to attract them in open source, initially was very painful, but I really think it paid off for us. Craig: [7:07] That was a good sort of recap. I think we touched on it before we turned on the recording here, but can you dig a little deeper into how you viewed all the competing frameworks in this game and then you see the evolution? I’ve definitely heard other people say there’s some generations of them or this sort of thing. Tom: [7:24] Definitely. It was very loaded question. I should make sure I don’t get myself in trouble here. Craig: [laughs] [7:28] Tom: [7:29] The first thing I should say is that all of the JavaScript frameworks that are at all popular are written by very smart, very capable people, for whom I have nothing but the utmost respect. I am a big believer in picking the right tool for the job. I’ll be frank; there are jobs where Ember is not the correct tool. [7:47] If you were building a component, a third party widget that you’re embedding in some else’s site, you shouldn’t use Ember. It’s too big. It just does too much. If you’re building a page that doesn’t have to deal with URLs, if you’re just making interactive pieces of one page is traditionally server rendered, I don’t think you need Ember. [8:02] I think that you need Ember when you are building a 100 percent JavaScript client app that talks to an API, and you have multiple pages. You have any kind of sophisticated UI. We really want to help you map your application state onto the URL. By definition, that means that you are building larger apps that have complicated state. If you can reason about it and handle it, you don’t need Ember. [8:26] The thing that I’m glad about is that the landscape has really shaken out. There was a time where someone could piece together a 500, 600 line JavaScript library, MVC library, and post them on Hacker News. You would get people commenting very breathless. They’d go, “This is amazing, this is awesome.” I’m really glad that fetishization of micro libraries has finally passed us. [8:52] I think what’s left obvious to me, is Backbone, Angular and Ember. I think Knockout, too. Knockout’s very popular, but there’s a little bit less buzz about it. It doesn’t seem like it’s really evolving towards anything, but it’s definitely a very solid candidate right now. [9:07] I think you could say the same thing about Backbone. Backbone is relatively fixed. I don’t think there’s any plans from the Backbone team to try to expand it at all. Really I think what is left duking it out, is Angular and Ember. I’m hoping what happens is, in the same way [laughs] in 2011 and 2012, Backbone and Ember were really duking it out. People really thought of them as more or less doing the same thing, but no-one thinks that any more. [9:32] I think the same thing will happen with Angular. Amber will find its niche, and Angular will find its niche. People will have a much better mental model about which problems are appropriate to solve with each tool. I would be very happy in a world where it’s like Rails and Jango. You pick the tool that makes the most sense to you. You pick the tool that happens to be a little bit better for whatever particular problem you’re solving. [9:52] I’m just really glad it’s shaken out, because it was getting really irritating having to defend ourselves against the “flavour du jeur” on Hacker News every week. Craig: [9:59] That’s very helpful for our listeners and very politically correct there. Tom: [laughs] [10:02] Craig: [10:03] Sorry about the loaded question. How are you guys trying to differentiate yourself in your framework? Tom: [10:09] The biggest one, like I said, is rooting for big apps. I gave a talk today and one of the things I said in the talk is, people think of MVC as being an application architecture, but it’s not. MVC is a component architecture. Your app is made up of many of these little groups of MVC units. It’s not just one model, one view and one controller. [10:30] You’re going to have many models, many views, many controllers. Sometimes, all of them are on the page. Sometimes, none of them are on the page. There’s just so much flexibility here and so much variability in what you’re building. That’s part one. MVC is a component architecture, not an application architecture. [10:45] Second, URLs are extremely important. The web is a viral place. The notion that I can take what I’m seeing and I have this UI for taking that URL out of the address bar — I can command click to open it to floor off the process, essentially. I can share it on Twitter, I can send an email, I can bookmark it — that viral web is extremely important. That’s what makes the web, the web. [11:12] Historically, we were very lucky by accident. It was very accidental, but in order to build server rendered web applications, you have to have URLs because if the browser can’t hit the server by definition, you don’t have an app. Then people were like, “Well, server is fine, but wow, we can build really awesome UIs, really fast, really responsive, if we do it in JavaScript”. [11:33] They started doing that, but they completely forgot about the URL. There was like a whole generation of JavaScript apps that you would use them and the URL support was just terrible. People would notice, like, “Don’t click the black button.” You refresh the page, you just lose everything. It was terrible. [11:49] Our goal is to build a framework where if you just follow a couple of the rules of the framework. Just follow a couple of these rules about how you architect things, we can guarantee you that you’re going to get good URL support out of the box and that ties back to what I was saying a second ago, which is we want to build a framework where you architect things in terms of these groups, these components of MVC and then those get mapped back on to the URL. [12:15] That should be as seamless as possible. If you have to think about it as a developer, you’re going to screw it up. If the framework does it for you, if it’s automatic, then you’re just going to build apps that happen to have the URLs. You don’t have to put any extra load on it, and it’s not just a feature that you check off anymore. It’s something built-in from day one. Craig: [12:29] Let’s take a little bit more into the router for the audience. Can you maybe elaborate on the master detail example that I’ve seen in several of your online presentations? I think that sort of helps people understand where things start to break down with some of the other frameworks of URLs. Tom: [12:43] Absolutely, I think there’s a temptation where the notion of composing each page into these separate units. If that notion’s not built in, I think people treat the controller and the mauler. They treat it like a juncture. [12:57] I review open-source Backbone apps, I review open-source Angular apps whenever they come out and many of them, you have one dollar scope an Angular, for example. It was just a dumping ground. Your whole app is a controller just dumping stuff in here and it’s clearly not maintainable [13:13] The point of the demo that I gave is to show a master detail for you where you really want to be able to architect your application in such a way that you have these groups on screen. At any given time, you have, for example, the thing that you just said was the blogging example. [13:29] You may want a UI where you have a list of all the blog posts on the left and you may want a blog post on the right, like a particular one that you want to read right now and clicking that link shouldn’t replace everything. It should just replace the particular blog post. [13:42] Having a system that lets you very easily break that into two, so you have one template, one model, that’s a list. You have another template, another model, that’s a particular blog post, just makes working on these apps, especially on a team much nicer than let’s just turn this into a dumping ground. Craig: [14:02] Let’s talk what the URLs look like in that scenario even though it’s difficult here on a podcast, but you know. I think it would help and people would appreciate it more. What I saw was /blogs, gives you a list of… Tom: [14:13] That’s what we would call like an implicit model. You say /blogs, there’s no unique identifier. I think /blogs is identifying both the template and the model. In that case, if you come in to your app and say /posts and say come to /posts, that means show the post template and get all the post models that the app knows about. Craig: [14:33] Thanks for fixing my blog posting. Tom: [laughs] [14:34] Craig: [14:35] I’m sure I had all the listeners quite confused there from it. Tom: [14:38] /posts, yeah. Craig: [14:40] /posts, anyway, so continue please. Tom: [14:41] There’s that and then you have URLs like /posts/1 and that’s telling us, well, we want the posts template, but we want it to show the post with the ID of 1, for example. I think if you look at most URLs, URLs that are considered clean, the contents of MVC map on to the URLs very well. [15:04] There’s some basic routing support. Backbone has a very basic router. Angular has the router, but I think one thing that we have been working on for the next version of Ember, that should be going out — which I think is really cool and no one else really handles is…Everything that we talked about so far has been mapping templates and model information, but there’s a big of a question about, “OK well, there’s a lot of state also in the controller that you want to capture and you want to serialize into the URL. [15:31] Right now, in all these frameworks that’s being lost. We’ve got this future coming out member called [inaudible 15:36] and this makes it super simple, super declarative to basically annotate your controllers and say, this particular controller property should be saved into the URL. Now, that’s a little bit abstract, so let me give you a concrete example. Craig: [15:50] Before we go there, I think we may have missed the new ones that you know, from you doing this presentation a bunch of times. [15:55] Just to describe the page, we’ve got a list of items and then when you click on the list of items, both the list stays on the page and the detail of the post comes up, so then the URL become post/1 or 5 or whatever the case may be and the way you guys are achieving this is sort of through composability. [16:13] In other words, that you don’t have to rewrite the list control on the left side of the page or the list template — I guess that would be a better word — on the left side of the page or you get re-used out of that in that same composable template. I think that composable story is a great story there. Tom: [16:29] Yeah, I think it’s a good story and I think what’s also cool is that the Ember inspector makes visualizing what’s happening there, very easy. You can just take the Ember inspector, which is a Chrome or Firefox extension and you can go to any production Ember app, bustle.com, vine.co, any of these things. You log in into the production app and you can actually see how their templates and their models are composed. Visually, it just makes so much more sense than [inaudible 16:52] Craig: [16:53] I saw you trying to hack it, one during a presentation. We’re going to try to change somebody’s name. You mentioned that this is a good way to play a practical joke on someone. Tom: [16:59] Yeah, it is a good way of playing a practical joke. In inspector, you can open up, so you have these nested templates and each template has its own model and that maps on to the URL. You just open the inspector and you can see all those things, visually it’s laid out and so you can just click on one. It’s funny to play a joke on people because you get access to the raw underlying JavaScript model and so you can play jokes on people by changing any of the properties in that model. It’s all light bound. It’s [inaudible 17:24] . It’s pretty funny. Craig: [laughs] [17:25] There might be a whole site dedicated to this soon. Tom: [17:28] Emberpranks.com. Craig: [17:30] Embervinepranks.com, something like that. Get the URL before this podcast is over. I had to track you from an important point there. You were talking about the future coming. Tom: [17:39] Oh yeah, [inaudible 17:39] . I should say that this is available right now. Ember has a very Chrome-like release process. [17:46] Every six weeks, we cut a new version and we also cut a beta version and we call it canary version, similar to Chrome. All of the features that we’re working on are behind feature flags. If you are interested in a feature that we’re working on but maybe we haven’t quite finalized the API yet, you can download the canary build and there’s a feature flier that you can turn on and that will allow you to play around with the feature without having to worry about…You can start playing around with it without having to wait for the official release to come out. Craig: [18:16] You explained the release cycles, so in which one of those version is the [inaudible 18:21] right now? Tom: [18:22] You can go online right now and download the canary release which we do a new nightly every night and you turn on the [inaudible 18:28] feature. Let’s back up and talk about what kind of stuff controllers’ store. What stake controller store? In Embers point of view anyway. [18:36] In Embers point of view, controllers are responsible for controlling application state. There are things like filtering or sorting where that doesn’t really change the model. That’s just changing how the model is presented and that’s the kind of thing that a controller and an Ember app would be responsible for. [18:54] What [inaudible 18:55] allow you to do is say, OK there’s a controller property called let’s say filter and it contains a string that we’re using to filter all the models that are displayed to the user. [19:03] Literally one line of code, you say, “OK this filter property I think I want users to be able to save it from the sessions. I want that property to be shareable.” You just have one line that says, “OK this filter property is a [inaudible 19:17] ,” and that will automatically be persistent into the URL for you, and also vice versa. [19:22] When you come into the app, we will extract that from the URL and we’ll set it on your controller for you automatically. It keeps your controllers and the URL in sync and you don’t really have to worry about it. You just mark it as, “This is the thing I care about and now boom, it’s shareable, it’ put [inaudible 19:35] et cetera. Craig: [19:36] Great. I’ve heard the router being described as more of a close to a full state machine. Tom: [19:42] It’s actually…I think we do a good job of putting a lot of syntactic sugar around it. It’s under the hood and extremely powerful state machine. We’ve done some really novel work in state machine in terms of making it asynchronous. [19:55] I think that’s really the part that our competitors are going to have a hard time catching up with. This is like a state machine where from the ground up we thought, “OK, what does state machine look like. If you have transition that can be deferred, aborted or even if they just take a few seconds to happen for an animation for example.” [20:13] Let me give you an example where this is useful. Imagine that you’re building a form that the user can edit; editing their user profile or something. They’ve entered in some information, but they haven’t yet clicked the save button, and then they click a link or they click a button that’s going to take them out of that state, off that page. [20:28] To deal with this key, you obviously want to probably be like, “Hey, you’re about to lose data.” You don’t want to do that, but they just click the button to do the transition, so what do you do? [20:36] Well, you can put in these hooks that are called the four transition happens or after transition happens, and in that hook you can actually pause the transition and you get a transition object that you can hold onto and you can replay that transition at any point in the future. [20:51] Basically what you do is you say, the user clicks away, you pause the transition, you pop up some UI. It’s like, “Whoa, are you sure you want…You’re going to lose this data if you transition out.” Then based on what they clicked, you can either say transition got replayed or transition got cancelled and everything else continues to work as before. Craig: [21:07] When they click save, they might navigate to the place where they’re originally trying to go? Tom: [21:11] Yes correct. You just say transition that continue…I forget the exact API. It’s “transition.continue” or something like that and then it will just continue on as though they had clicked whatever they had clicked without the interruption. Craig: [21:23] That’s a great feature. Yes, I like that. I noticed in the presentation, our code match I didn’t mention that before. Tom just did a presentation on URL driven web apps I think it’s available online. Go check it out. A very good introduction to Ember. The router versus the route, I even heard you say in the presentation, “That’s the router. It’s kind of like a controller.” Tom: [21:44] The router. It’s like…I think that… Craig: [21:47] What about the naming though? I’m sure you did that intentionally, so… Tom: [21:50] Yeah definitely. Craig: [21:51] …I’m curious to try to clarify that. Tom: [21:52] Sure totally. The router is really just an object that defines all of the routes in your system, all of the URLs in your app. The router, the only interaction that a user is going to have with the router is that we have a DSL for defining all the routes. [22:06] Say this .resource post, this .resource post et cetera. That’s about it as far as what you need to understand as an member developer about the router. I’ll talk about routes now, route objects. Craig: [22:17] I’m sorry. I’m sure you said routes? Tom: [22:19] Yeah, so there’s route objects and these are kind of novel object that we introduced into the architecture for the traditional MVC architecture. If you’ve ever read a book on Cocoa or ever done EMAC or iOS programming, in Cocoa you have the notion of a coordinating controller…an intermediate controller I think is the name for it. [22:41] These are two roles that the controllers serve. The coordinating controller is responsible for doing all the setup of other objects responsible for rendering views; it’s responsible for gathering data. Then there’s the other type of controller which basically serves an intermediary between the view and the model. [22:58] It does more transforming of data. It basically gets the model ready to be prepared for the view. It gets the model ready to be in whatever format the viewer is expecting. [23:07] I think for us, routes take the role of coordinating controllers. There are essentially controllers that setup the state of the application, but we call them routes because everything that they are doing is driven by the URL. [23:23] It’s essentially an object whose responsibility is to translate the URL into application state and then similarly if application state changes, transform that back into a serialized form and put it into the address bar. I don’t think of them as controllers per se, not in the classic sense of a Backbone or an Angular, but if I think about the architecture of the application, I think it fits into MVC, that kind of layering, and I think the route objects fit into kind of the C layer. Craig: [23:53] I’ve always wondered about that when I see the framework. I know this was intentional, but yeah. Just to rehash that to make sure I’ve got it, so the router is the object where you’re doing what people traditionally think you’re doing a route which is map URLs to pass and… Tom: [24:12] Like the rails router. Craig: [24:12] Rails router. Tom: [24:13] Yeah rail router. Craig: [24:14] The route object is most easy for people who are familiar with service item C frame works to think of it as a controller, but there was some reasoning behind that which you’re interested in? Tom: [24:27] Yeah. Instead of just mashing everything together, instead of saying there’s one conflicting controller, the controller acts as an intermediary between the templates and the model and it also sets the application state. We broke those two concepts in two. I think it’s a little bit easier to reason about once you understand what’s the… Craig: [24:43] Let’s talk about Ember data a little bit. Tom: [24:45] Sure. Craig: [24:45] I wrote a post on funnyad.com. It was very popular. It got hundreds of comments and not to promote it, but one of the comments I got that was probably one of the most insightful was, “Gosh, do you know that discourse doesn’t even use the Ember Data and…This framework is unfinished this sort of thing.” I’m not sure that’s a fair comment, but I wanted to hear your response to that. Tom: [25:05] Well, I think that’s an extremely short sighted comment to be frank with you, because I don’t perceive it as a problem that discourse isn’t using Ember Data. Ember Data is a separate project and its goals I’d say are just as ambitious as Ember proper. It’s going to take as a little while to get there, but we’re very close releasing a 1.0 version of Ember Data. [25:25] The reason that I think that particular comment is either disingenuous or intellectually dishonest is, neither Backbone nor Angular actually have any data libraries that come even close to doing what Ember data is doing. [25:41] If you write a Backbone app or you write an Angular app you’re going to need to somehow marshal model data into that application anyway. The tools that…For example Angular gives you, it gives you like dollar HTP. We don’t need dollar HTP because just use jQuery. We don’t want you to make you [inaudible 25:56] tool. Just use jQquery, so you can use jQuery or they give you dollar resource which is like a very small implementation on top of dollar HTP and frankly it’s completely panned by the Angular community. [26:08] If you ask any serious Angular developer, they’ll tell you not to use dollar resource. I find that particular argument completely disingenuous. It’s not hard to write a model library. You don’t have to use Ember models. Just go grab a Jason pay load using Ajax, using jQuery, whatever library you want to use, give it to use in the model hook and we’ll put it in the template for you and it work just fine. [26:29] Ember without Ember Data works no different than Angular or Backbone, so why are we getting nailed for that? I’m still not sure. I think people just have a bad understanding about what’s happening. Craig: [26:38] What discourse is doing right now is jQuery isn’t [inaudible 26:41] of your library, so they’re simply using the built in things that everybody is familiar with HTP object. In Angular, for example, the HTP use the [inaudible 26:49] . Tom: [26:50] Well, jQuery doesn’t work with the digest process, the dirty checking. You need dollar HTP to know when to apply digest changes. Craig: [26:57] That’s the reason they wrapped it. They’re not adding a whole lot there… Tom: [26:59] Correct right yes. Craig: [27:02] People could argue that in the resource area, there are people I’ve seen who are OK with the resource model, but it’s not a ton on top of it let’s put it that way. It’s not doing a lot for you. Tom: [27:09] It’s not doing a lot for you that true. Craig: [27:10] Let’s talk about what are Ember Data’s more ambitious goals? As a community, a lot of people aren’t familiar with what’s coming. What is so cool about Ember Data? What’s so much better than just make an Ajax calls? Tom: [27:23] First only talk about the concept of an identity map, because I think an identity map is very important. For any listeners who are not familiar, an identity map is simply an object in memory that if you ask it for a model particular ID, it will always return let’s say in model back. [27:42] This is really important because what it means is that, if you have an application and your user is moving around the application, you are only fetching data that you haven’t previously fetched over the wire before. [27:57] If you think about a server rendered application, and if I click to a link to a certain blog post, it’s going to load an entire HTML representation of that whole app over the wire. If I click on a link to another blog post and I click back to that original one, it’s transferring a ton of HTML every time. You can reduce that pay load by using a JavaScript framework, but if you don’t have an identity map you’re still having to load at least the JSON representation of that resource every time the page changes. [28:21] What identity map does, it basically says, “Let’s keep in memory all the model data that we have loaded.” If we move around the application, if we’ve already loaded that over the network, we’ll just immediately hand you back the model that we had previously loaded. [28:36] This is also important because it means that any changes that happened to that model in different parts of your application, you don’t have to think about, “Is this model the same?” If you ask your database, your data library for a particular model, if it gives you back a different instance of that model each time, then two separate parts of your application making changes to it, they’re going to quickly go completely out of sync. Craig: [28:56] Right, and cause a lot headaches? Tom: [28:58] A lot of headaches, a lot of chaos, yeah. We do that and then, I think what we do is pretty cool is we just have…Ember Data has actually — in scope — gotten a little bit smaller in the sense that it is purely a wrapper around a asynchronous network request or not even network request. [29:14] It’s very easy to write and adapt to an Ember Data that will wrap things like index DB for example so you can have like a right through cash so that the app [snaps fingers] puts up like that without having to do a network request. Then because you have this identity map, it’s super easy to plug it into a socket. [29:29] You plug it into a socket [inaudible 29:30] for changes on the server or hosted server like fire base for example, and as those changes stream, because everywhere in your application from the web socket to the model in your templates, because they’re all pointing at the same instance of that object, because of the identity map, any changes made anywhere are reflected across the entire system. [29:49] That’s the important bit, that’s basically the core concept. There are a couple other libraries in different frame works ecosystems that are attempting to do the same thing, but the thing that they don’t do is relationships. It turns out doing the thing that I described is… Craig: [30:01] Media I’m sure you’re really referring to right? Tom: [30:04] Yeah. Well, media I think is kind of a no go because it ties you into Mongo and no one is seriously using Mongo in production. More importantly, doing the thing I described is…You can hack something out like a month, let’s say. Like a really robust thing that doesn’t [inaudible 30:18] anyone could do it probably in like a month or so. Adding relationships, oh my gosh, the complexity just explodes, but you need it. [30:26] In Computer Science, we need to model tricky relationships between objects and taking those tricky graph relationships and keeping them in sync across the network, you have a distributing computing problem now and that’s a really hard thing. That’s what’s taken us a really long time to figure out. Is, how do we solve that problem, how do we make an API that’s nice to use that you can adapt for JSON API’s that are totally not normalized, and then also sockets and xDB? [30:53] I think we’re very close. Craig: [30:54] That’s a lot of problems to solve. Tom: [30:56] There’s a lot of problems to solve. I think that we have a history of tackling really ambitious problems. [31:00] Sometimes it takes us longer to get there than we think we will, but in the end, I think that we’re committed to doing it in a quality way. Not just packing something out as soon as we can. Anyway, it should be pretty soon. We just have one last major refactor in terms of how our relationships are handled, which I’m hoping to land in the next couple of months. [31:15] After that, we’re going to try to keep Ember and Ember Data in blockstep, so that we basically synchronize their releases, and they’re guaranteed to work compatibly with each other. Craig: [31:24] Great. I’m excited to see what you guys come out with. One thing you mentioned in the presentation that I thought would be helpful for people to hear was, there’s string templates and there’s DOM-based templates, and you talked about some of the pros and cons. [31:36] I personally was having a hard time, besides the performance argument, ever really warming up to string templates, but you made some very good points. Can you talk about some of the things you guys think about and why you chose…? Tom: [31:46] Sure. Absolutely. Probably one of the most important ones is that you don’t need a DOM with string-based templates. [31:53] For example, if you want to take Handlebars templates and render them on the server, you can just do that, because the parser is just dealing with strings. String input for the template, string output which is all your HTML. [32:05] You compare that to both Knockout and Angular, they lean very heavily on the HTML parser in the browser to convert HTML into DOM, and then they rely on that DOM-API existing so you can traverse the DOM. [32:20] You need some kind of somewhat heavyweight solution on the server, whether it’s jsdom or spinning up a phantom JS. Instance for example is extremely memory heavy. It’s hard to do a lot of those in parallel without burning a lot of RAM. [32:33] There’s that aspect of it, where you just have a lot more freedom. Craig: [32:36] I hope people understand why you would need to render templates on the server and why people think about that. Tom: [32:42] I think the most important thing is SEO, obviously. At this point, there’s a lot of search engines. Google is doing limited JavaScript execution but they haven’t really been public about it, so it’s hard to reason about. [32:51] What Discourse does, for example, is they just render simplified templates on the server that they feed to Google. They have an API that you can do this so it’s not like shady, dark hard SEO stuff. Google realizes this a problem, they give you an API that you can use. [33:07] There’s that, and I think also, eventually all of the JavaScript framework is going to have to support some kind of system for sending down an initial render in HTML. Just because waiting for the entire Joust payload to load before you see anything is a little bit painful, especially on mobile devices. I think we’ll see that relatively soon. [33:25] I think also, we’re relying on the browser’s HTML parser, which you don’t have a lot of visibility into. For example, if you have a table in Angular, and you have two tr’s that you want to repeat for the model. If you watched the cage match with [inaudible 33:45] , this is one of the things that gets him. Because you want to repeat two tr’s for each item. [33:50] The way that you would normally do that, is you would have some kind of wrapping div or wrapping span, but the browser HTML parser’s going to just totally eat it. It’s not even going to show up in the DOM. It’s just going to discard it, because it’s an invalid note. [34:01] Now you have to put in all these hacks, you need “ng repeat start,” “ng repeat end,” put in a comment note or whatever, but now the parser in your brain has to know about all the edge cases. [34:12] If you are the one whose code is doing the parsing, you don’t have to worry about that. In Handlebars, you just have the pound each helper, and you can wrap that anywhere. Craig: [34:23] It’s outside of their bound, basically. It’s not in an element, right? Tom: [34:26] Right, we analyze that and we see it before the browser generates any DOM. We have complete control and we don’t have to basically use the semantics of the browser, which is very nice. [34:35] I think the last thing for me is, when I’m writing Angular apps, looking at a template, and quickly determining what parts are dynamic and which parts are static is quite tricky. If you have an HTML element that starts having a lot of different attributes in it, looking for the “ng-“, it just blends in. Having the double-curlies, whenever you have dynamic content, to me visually it just sticks out a lot better. It’s much easier for me to track down what’s dynamic and what’s not in an Ember template. Craig: [35:01] I think to wrap up, let’s talk about, after that cage match I heard you say, “Gosh, if there’s one thing we admire…” You each had to say something you admire in the other framework. [35:12] You mentioned the testability story, so you often get questions on the testability story, both unit and functional integration tests. How is that story developing? Tom: [35:21] Really well. We have a package now, since the cage match, called “Ember Testing.” [35:26] I think the trickiest part about testing JavaScript apps is dealing with asynchrony. The second you have to start testing asynchronous behavior, the reasoning about testing it essentially falls apart, in all of these libraries. [35:38] What we did, is we wrote a testing package that includes a bunch of helpers, and the whole API is promise driven. For us internally, using promises for dealing with asynchronous behavior has made it so much simpler to reason about what’s happening. [35:52] We expose these testing helpers that you say, “Visit this page, click on this button, fill in this form, wait for this value to become true,” and you just chain them all because they’re all just promises. [36:02] It also integrates with any other testing library that uses promises because you just chain the promises. That’s really nice. I think that the next step now that we have that in place, is to make it just really easy to use. [36:15] Unfortunately, right now, the landscape for build tools around building JavaScript apps is extremely fragmented. You have Brunch, you have Yeoman, some people are using Rails Asset Pipeline, some people are using Browserify, it’s so complicated. [36:32] We can’t just tell people that are Ember developers, “OK, use this one particular tool and boom, you just get testing for free.” What we’re working on for the next few months is we are working on a set of note-based build tools, and once we have that in place, it does a bunch of cool stuff. It lets you use ES6 modules. It’s very nice, but built into that will be testing infrastructure. [36:54] Once we have that, we can tell everyone who’s going onto our app, “Just use our build tools, and you’ll get testing for free.” Then using the new testing like that will just be extremely simple. Craig: [37:03] Does that encompass the unit testing side or is it more of a [inaudible 37:06] ? Tom: [37:07] Yeah, it does both. There’s the more integration testing, where you say, “Let’s verify that the app, all these pieces work together.” [37:13] I think because the architecture in Ember is rather strictly enforced, it’s hard to break through the layering, the firewalls that we put between each of these layers. [37:24] Unit testing is very simple. If you want a unit test a controller, you just instantiate it, you set some properties on it, and you see if whatever you’re expecting to happen happens. Similarly, with templates, you say, “OK, here’s my template, I’m going to give it this model. Do I get the HTML that I expected?” We have helpers to deal with all of those. [37:43] I think it’s really nice, and at that point you can use whatever mocking or stubbing library that you want. The framework — both Ember and Ember Data — are completely unit tested and integration tested internally. We use QUnit for that, but I know a lot of people who use Jasmine, I know a lot of people who use Mocha. [38:02] Like I said, the only problem is a lot of this testing infrastructure. In JavaScript in general, you have to set up by hand, and a lot of people just don’t do it. Hopefully we can fix that. Craig: [38:11] Well, thanks for coming on the show today. It was a really good conversation, I think we got some good information out there to people, and I wish you guys luck. Tom: [38:18] All right, thanks a lot, Craig. Thank you for having me. [38:20] [music] [38:23] Thanks for listening to the front-end developer podcast. [38:25] Please subscribe to the podcast by going to the iTunes store on your phone or desktop, then searching for “front-end,” or via RSS by going to frontendcast.com, where you’ll also find show notes and a full transcript of each episode. [38:38] We’ll see you next time. The post Ember interview with Tom Dale, a Robust Framework | Episode 003 appeared first on Funny Ant.