The full video and many others like it are all available as part of our Frontend Masters subscription.

Kyle Simpson

Kyle Simpson is an Open Web Evangelist from Austin, TX, who's passionate about all things JavaScript. He's an author, workshop trainer, tech speaker, and OSS contributor/leader.

Kyle Simpson

You Don't Know JS

Kyle Simpson is back with his second Frontend Masters workshop. He starts with a little background about himself including links to his website, open source projects, and contact information.

- http://getify.me
- http://labjs.com

Get Unlimited Access Now

Kyle Simpson: Thank you all for having me. I appreciate everyone here in person and also all of you online from all parts over the world. Thank you for being here. It is an honor to be back. I always joke that, because I travel speaking and teaching for a living, so I always joke that I can judge a city based upon the weather that they provide to me when I visit.

So I showed up last night to the cold and rain, but I appreciate Minneapolis hosting me a second time. Marc's right, I was here about a year and a half ago for a web performance workshop. So I'm well familiar with this space and glad to be back. Marc runs a fantastic workshop series.

Like I said, I go all over the world and I hear just random people at a conference somewhere in a different part of the world talking about a video they saw from this. So, you guys are incredibly lucky to be part of that. I encourage you to continue to do so, continue to spread the word.

I'm very pleased to be also helping with that. As a slight side not on that particular web performance workshop, I'm slightly embarrassed by it, although I think there's lot's of great content. But that actually happened to be the very first workshop that I ever taught, long form workshop, I had done plenty of speaking before.

But Marc kind of gave me my start in teaching and I didn't even really know at the time. He kind of contacted me out of the blue and said I've seen you speak, what would you think about teaching? I had kind of a bent toward teaching but I'd never really done it in this industry and so I was excited to kind of try it out and see, and I was insanely nervous the night before, not knowing if I had too much content or not enough content.

I had no idea really what I was doing, but he gave me a shot. Kind of an unknown in terms of speaking and teaching. And, I didn't know at the time, but that launched the career that I now have. I now do this full time and I appreciate Marc for giving me my start.

So, it's good to be back here. I'm Kyle Simpson known as getify online. If you're into that online stalking thing, you can check out all kinds of links to where to find me, and provide feedback, whether that be questions, whether it be telling me that I said something that you completely disagree with.

That's totally okay. But getify.me has links to all kinds of things about me. As I mentioned before what I spend my full time doing, and I say full time kind of with some air quotes, because I don't actually work full time at it but it is the only thing that I do that I pay my bills with so I call it my full time job, and that's teaching.

And that involves corporate teaching. So the number of big companies that I travel all over to do teaching for the intels and things like that. I also do public workshops at a lot of places when I go and do, when I'm in some city for a conference. I just did a public workshop a few weeks ago while in London.

I know some of you that are online who are part of that process as well, so welcome to you there in London. So, I teach for a living now, and just as a little plug for that, if anything that I say is interesting, if you find this stuff interesting and useful, I encourage you to go back and talk with your companies, talk with your meetup groups, things like that, anybody.

And, if you're, I'm available for hire, so I can travel anywhere to teach. So I'd love to do that if that would be helpful to you for your company or your group. The other part of my time that I spend, so I spend about maybe 50 to 75% of my time doing that, but the other part of my time I spend on what I call community building, and this involves a variety of open source activities.

Open source development. Writing on the books, which we'll get to in just a moment. Speaking at conferences. Running meetups and things like that. So, my goal is, it's an all boats rise with the tide. My goal is to build awareness about the web platform and about its technologies so that more people are aware of it, more people appreciate it.

And by the way, the word appreciate doesn't necessarily mean like it just means to respect, to understand, to realize the usefulness of. So my goal, I'm an independent, but I'm sort of an open web evangelist. My goal is to go everywhere and try to evangelize what the open web platform can do and try to help people learn that better.

And I feel like the more people that appreciate that technology the more opportunities that'll give me to teach. So to that end, some of the time that I spend I do quite a bit of open source development on a whole variety of things if you check out my GitHub.

Just mention a couple of real quick projects that I work on, so LABjs is probably the one I'm probably most known for. LABjs is a dynamic script loader, it's coming up on five years old now, so it's actually getting to be rather ancient in terms of open source technology.

But probably its most important feature is its stability, because it's almost three years since the last time it had to be changed. Now, I know many of you know about open source projects that every couple of weeks they're releasing another patch and adding a new feature and things like that, but I consider stability to be its most important feature, because it has been battle-tested, it's been hardened, it does exactly what it's supposed to do, no more no less and it continues.

Now I maintain the project in terms of if there are bugs or things like that, I get people posting issues from time to time and we track them down and it turns out it's not actually a bug. But if there was one we would certainly do that. It's been in use by big companies like the Zappos and Twitters and Vimeos of the world.

So you can trust that it has been put to the wringer. It's just a really low-level simple script loader. It's not at a higher level in terms of dependency management, things like require, that have lots of complicated configuration. It's nothing of that nature. It's just, load some scripts, get them done as fast as possible, and ensure the execution orders or dependencies are met.

Now why would I even bring up a script loader these days? Because A, we have these dependency managers, and that's what everybody in the world seems to be using. And B, we all know that the simplest and easiest way to get all your scripts loaded is to just concatenate everything in the build process.

Right? So why would I even talk about a script loader? Why would LABjs even matter? I have a prediction. I don't know if it'll be true, but I have a prediction that we're going to see a renaissance in script loader technology. It's kind of fallen by the wayside. It doesn't get a lot of attention these days, but we're seeing a switch in our platform technology and that is the advent of HTTP 2.0, or HTTP 2.

And that's not quite like IPV 6, where people have been talking about it for a decade and yeah, yeah, yeah, maybe someday we'll actually get IPV 6. HTTP 2 is a reality. It's already happened in all of the browsers that you're using, probably already you're supporting it. A number of the big web services out on the web, they're already serving up over HTTP 2 if your browser's capable of it in the right circumstances.

And why would I bring that up, what's the big difference about it? Well, it turns out that with HTTP2 everything that we learned about optimizing our web page load performance to reduce the number of files, combining everything, combining all our Java Script into one file, all our CSS, all our images into sprites, everything that we learned there, turns out that's the worst possible thing you can do in HTTP 2.

Because the HTTP 2 protocol is a persistent socket protocol, much like Web Sockets. It establishes one handshake and then it interleaves bits and bytes and interleaves the files and downloads everything in parallel. So if you have one giant file you can't really do that, and you want to have as many small chunks and small files as you can.

So, we've all spent the better part of the last five years building out hundreds of tiny little AMD files and we've got these build processes that are putting them all into one big file and shipping that out to the browser. I predict over the next year or two we're going to see, people are going to still have hundreds of little files and how are they going to load these things when they have to switch to loading them all at separate resources, rather than as one and I predict that we'll see a renaissance of script loading technology, we will try to figure that out.

And I also predict that LABjs will just be patiently waiting in the corner if anybody wants to check that out. So you can take a look at LABjs if you want to look at performance script loading. Grips is a templating engine that I wrote couple of years ago. I've been kind of tinkering on it for a while.

Now, it's not because there's not 1000 other templating engines out there. There certainly are. But there are some problems that I've seen in the front end templating world. So I kind of group templating engines into two extremes. On one end of the spectrum we have templating engines which are extremely, what they called logic-less.

Extremely stripped-down, as little logic or no logic as possible. Many of you are probably familiar with Mustache and variants thereof. They call themselves logic-less templates or sort of zero-logic templates. And the idea behind that is, we don't want to put business logic inside of our templates, so let's make a templating engine that has no logic.

Ergo we've solved our problem because you can't put logic inside of the template. And the spirit of that is great, obviously I totally agree with the idea of keeping the separation of concerns, keeping our business logic out of the templates. In practice, however, I've tried using those in production systems.

And in practice what I find out, what I find is that there's an an awful lot of tinkering with the data, massaging it to just be just right inside of our controllers, because there's very little flexibility in the front end layer, so we have to massage the data to be just right.

Sometimes we have to pollute our data model with what we call presentational data, so if you want to loop over the months of the year to put in a drop down, we have to stick that data along side of your data model and ship that off into your template.

Because the expressiveness of the templating engine restricts you from doing that sort of thing. So unfortunately, while we were trying to create a separation of concerns between our controller and our view we ended up creating this really brittle tie between the two. And you have to really understand your view to write your controller, and you have to really understand your controller while you're writing your view and vice versa.

So the theory is great, but the practice somewhat lacks. And that's a common theme in a lot of things in web technology world. On the other end of the spectrum, from logicless templates, we have this idea that says well, I do need to do some logic, so why don't we just use a standard language that everybody knows.

Let's just throw a whole programming language inside of the templating engine. As a base example of that, PHP is a templating engine with the PHP programming language embedded inside of it. Other examples that you may be more familiar with, dust, and handlebars and other things like that. They have the full JavaScript language or the full Ruby language or something like that as your expressiveness inside of your templates.

And I liken that to me handing you pile a rope, and I can say I can either teach you, with this pile of rope, to build a rope bridge, which is quite helpful, or I can teach you to build a noose and that's not quite so helpful, at least in some circumstances.

And the problem is that under the pressure that says your boss is breathing down you neck and says, hey you've got ten minutes to get this thing in there. We need some logic around this thing so that it hides under certain circumstances. When you have the ability to put an IF statement inside of your templating engine, and your boss says you've got to get this done, and that's the expedient way to do it, we put an IF statement there.

And then maybe we make ourselves a comment that says come back, our famous to do fix this kind of comment, come back and fix this, which we know we're never actually going to come back and do, but the spirit of it is great, we want to fix it. And then six months later, it's not even you, it's someone else on your team, the boss is breathing down their neck saying, hey, there's another condition now that needs to be wrapped, so then they go in and put in and some other condition, and they call out to some other controller method.

And before long, you see that you have business logic leaked into your templates. And the pressure behind the expediency says, just do what's quick and then theoretically we'll come back. I have this book that I want to write someday called The Myth of the Refactor. We all like to think that we're going to refactor things in practice.

There's millions of lines of code being written every day, and most of those lines of code will never be seen again by another human being. And that's kind of a sobering fact to think about, but it's kind of a reality that we deal with. So, there's this tension between no logic, too much logic, and where is the middle.

It's kind of like the Goldie Locks. Could there be somewhere in the middle that satisfies the needs, but doesn't give us too much? And my experiment in that is the grips templating engine. It's a restrained templating engine syntax that gives you the power to do what you should be doing, and it restricts you from doing the things that I think you shouldn't be doing, like making method calls and doing arithmetic and other sorts of business combinatorial logic.

So, you can check out that, if that's at all interesting in terms of the pain points that you've looked at. One other little note about grips is that another experiment that I am working on right now is a CSS templating engine built on top of grips. Now, many of you are familiar with CSS pre-processors like LESS and SASS and things like that.

And with CSS pre-processors we get the ability to sort of pre-process our CSS files, use variables and includes and other things like that, but it's like it got halfway and then it just sort of stopped in terms of the evolution of the technology. We got pre-processors and then we just said, well the only thing that we need to innovate on is coming up with new, inventive syntax to stuff inside of our style sheets.

And I think we missed the boat because I think CSS templating, which treats it as a separate process that you're compiling a template from when you're rending it, and it externalizes your data in the exact same way in which we think about our HTML templates, we can think about our CSS as templates, so I'm experimenting with CSS templating.

I think it's a lot more powerful than just CSS preprocessing and I've built that as a module on top of grips. So if any of that's interesting, you can check out grips. And finally I won't spend any time talking about this because at the end of today we'll talk about this, but Asynquence is a promises like a asynchronous flow control library, that are really tiny, less than 2k, to give you the power to express sort of promises like syntax for asynchronicity.

Ready to take your code to the next level?

Intense courses with world-class teachers and unlimited access to our growing library of videos for the great price of $39 per month.

Get Unlimited Access Now