077 JSJ Monocle with Alex MacCaw

Download MP3



01:13 - Going Rogue Video02:12 - Alex MacCaw Introduction


Next Week

Working From Home


ALEX:  The rain in Spain falls mainly on the plain. [Hosting and bandwidth provided by the Blue Box Group. Check them out at BlueBox.net.]  [This episode is sponsored by Component One, makers of Wijmo. If you need stunning UI elements or awesome graphs and charts, then go to Wijmo.com and check them out.]  [This podcast is sponsored by JetBrains, makers of WebStorm. Whether you’re working with Node.js or building the frontend of your web application, WebStorm is the tool for you. It has great code quality and code exploration tools and works with HTML5, Node, TypeScript, CoffeeScript, Harmony, LESS, Sass, Jade, JSLint, JSHint, and the Google Closure Compiler. Check it out at JetBrains.com/WebStorm.] CHUCK:  Hey everybody and welcome to episode 77 of the JavaScript Jabber show. This week on our panel, we have Joe Eames. JOE:  Hey there. CHUCK:  Jamison Dance. JAMISON:  Hey friends. CHUCK:  AJ O’Neal. AJ:  It'sa mia, it'sa AJ. CHUCK:   I’m Charles Max Wood from DevChat.TV. And before I introduce our guest, I just want to make a quick announcement. Tomorrow as we’re recording this, so when you get this episode it will be last Friday, is my Freedom Day. It’s the day I got laid off from my last full-time job and went freelance. So in honor of that, I’m putting together a video. I’ve called it ‘Going Rogue’. Yes, I know that there’s a political thing around that, whatever. Anyway, I called it ‘Going Rogue’. You can get it at GoingRogueVideo.com. It’s basically the first year of me going freelance. I’ve just talked through how it all went. The mistakes I made, the things I learned, the things I did right, and just gave general advice to anyone who’s looking to go freelance. Or if you’re interested in some of the challenges that come with that, it’s a video that I’m putting together to kind of explain that. Like I said, it’s free. You can get it at GoingRogueVideo.com. Yeah, I’m pretty excited about it. I’m also excited about Freedom Day. Anyway, we also have a special guest today, and that’s Alex MacCaw. ALEX:  How do you do? Thank you for having me. CHUCK:  You’ve been on the show before, but it’s been almost a year. Do you want to introduce yourself again? ALEX:  Well, I’m mostly a JavaScript programmer. I’ve written a few O’Reilly books, one on JavaScript web apps, one on CoffeeScript. It’s called ‘The Little Book on CoffeeScript’. I used to work at Twitter, I worked at Stripe, and I'm now freelance. CHUCK:  Oh, cool. ALEX:  So today is my Freedom Day, too. [Laughter] CHUCK:  Awesome. So, we brought you on today to talk about Monocle. ALEX:  Yeah, that’s right. It’s basically a Hacker News alternative. But from a technical perspective, it’s kind of interesting as well. CHUCK:  How is that? ALEX:  Well, it’s a custom JavaScript web app, a custom JavaScript MVC, rather. And I do a bunch of preloading and caching optimizations to try and make it as fast as possible. So if you check it out, Monocle.io, you should see it should load pretty much instantaneously, especially the next hit it receives, everything will be cached. CHUCK:  That’s really cool. JAMISON:  I know you’ve written a fair amount about how you made it fast and some strategies to that too. That’s a huge point of debate between client-side and server-side rendering, is how to make the first load fast. Do you want to talk a little bit about what you did to do that? ALEX:  Yeah, sure thing. I’ll elaborate on my blog post. So, my blog post is called ‘Time to first tweet’ because at Twitter, the key metric was the time taking between someone hitting enter when they go into Twitter.com and actually seeing the first tweet on the page. So, that was the key metric and that’s basically what we optimized for. We actually rewrote the entire stack to try and optimize for that metric. But there’s a lot of fun around JavaScript web apps, because JavaScript web apps can be extremely fast on the initial page load as well, not just when you’re using them. Historically, everyone thinks, “Oh, it’s going to take a few seconds to load but once it’s loaded then everything’s rendered client-side. It’s going to be quite fast.” But actually, you can make the initial load pretty fast as well. And I basically go through all the bottlenecks like database drivers. That’s actually one of the biggest bottlenecks on the server side. Also, the database, you’ve got to do as little as possible in the first request. Then I go through all the networking stack, how you basically make sure everything is cached, everything is optimized. Then lastly, I look at the client processing speed which actually is one of the most important things. You can actually do the most tuning on the clients to try and keep the render and repaint time to as low as possible. JAMISON:  So, what would you say is the biggest speed up? Does it depend on your site or is there one thing you can really look at that will probably take up most of the time? ALEX:  Well for me, it’s kind of embarrassing, but I just added a Rack deflator which adds gzipping to every request. That just had the biggest impact of all. That was two or three times impact. Everything else was kind of incremental impact. CHUCK:  Did you just say Rack? Are you using Rails on the backend? ALEX:  No. I’m using Sinatra. CHUCK:  Sinatra? Okay. ALEX:  So basically, I build everything now in Sinatra and CoffeeScript and this MVC framework. I’m trying to, rather in this release, another MVC framework, I’m trying to push back some of the things I really like about it to Spine and Backbone and that kind of thing. JAMISON:  That’s a really interesting idea. I feel like there is some fatigue, framework fatigue maybe. I swear, every week there’s a new framework coming out and my fulltime job is not to learn each new framework. So I just can’t care anymore. I don’t know. So, that’s a really interesting approach. If you have some really good ideas to try and get them adopted by something people are using. I guess that’s like trying to shoot the moon, right? You’re going for the big gamble that if you release your whole framework, everyone will switch to it, which is probably less likely than people using something with your ideas added into it that they already use. ALEX:  Yeah, absolutely. And they’ve already got a big brand and a following. It makes more sense for the open source ecosystem. Having said that, I’m definitely a hypocrite. I love reinventing the wheel and I love tinkering about with MVC framework, which is why I don’t use anyone else’s. [Chuckles] CHUCK:  So, which MVC framework are you using on this? You mentioned Spine. Is it Spine? ALEX:  No. It’s just a custom one that basically takes the best bits of Spine, best bits of Backbone, and it does some interesting things in the client. So you can basically, let’s say you have a record, that record can be resolved later. You don’t need to worry about the asynchronous nature of the client-server relationship. You can just assume everything is synchronous. Then it will basically figure stuff out for you down the road. So, there’s a bunch of nice little techniques that it uses. And it’s also one of the reasons that Monocle is pretty nifty. It’s pretty fast. CHUCK:  I don’t completely understand. You said that you could just assume that everything is synchronous. ALEX:  Yeah. Let’s say you ask for a person with ID 123. A person instance will be immediately returned but that instance will actually be a decorated promise. Now that promise, if that person has already been fetched before, then that promise will be resolved immediately because the data’s already cached on the client. But if it’s not been fetched, it’s not cached in the client, then it’ll be fetched from the server and resolved when that network request finishes. So, you only really need to finish the revolution of an instance when you want to retrieve data from it, which is usually when you’re rendering it. So, I just delay rendering until the instance has been resolved basically when that promise has been resolved. CHUCK:  Well, I’m thinking about all the different pieces that go into this and your post, ‘Time to first tweet’, I just scanned it real quick while we were talking because I didn’t know that that would be on the quiz, I guess. But anyway, it’s really interesting. I don’t want to get too deep into the backend because that’s not what the focus of this show is, but is the data really coming back that fast then? Or does that promise just put a placeholder in place that makes it appear to load quickly? ALEX:  You’re definitely limited by the speeds of the network connection and also the time and the server response, and there are things you can do to speed that up. But for example with Monocle, almost everything here is preloaded. Then when you scroll, you’ve got infinite scroll. But basically the whole sidebar is preloaded and then when you click on an item, the comments are loaded in asynchronously. CHUCK:  So, preloaded in the sense that when it sends back HTML, it’s sending back some cached version with that information in it? ALEX:  No. Preloaded as in when you first access the site. If you ever look at the source of the app, it’s basically calling the setup.js file and that’s kind of key that you keep the preloading of the data in a separate JavaScript file rather than if you just insert it in JSON in the page because you basically want the initial index.html file to load as fast as possible, because then the browser can go through and call all those other resources in there. And it can call your setup.js file and you can add the defer attribute on to that, so that will basically block any of the other resource loading. So basically, you’re trying to get all these resources loading in parallel and you’re preloading the data on the first page load. The other thing I added to this was SEO. So, there’s always this FUD that JavaScript web apps can’t have good SEO and it’s complete rubbish. You can add SEO in ten minutes to most JavaScript web apps. And there’s a blog post about that as well. But basically, you take advantage of a spec that Google added called the AJAX fragments spec. And this is kind of geared towards the hash fragment in the URL, but you can basically kind of coerce it into a pushState world. JAMISON:  So, this is the thing that allows Google to parse client-side rendered sites, right? I’ve heard of it. I don’t know a ton about it. Do you want to explain a little bit more about how that works? ALEX:  Sure. You can check it out. If you go to Google and you type site Monocle.io, you’ll see everything in there is straight from the site. Basically, it’s been indexed properly. And the way it does that is on the pages, there’s meta tag. And this meta tag is a name of fragment and a content of this apostrophe. It basically tells Google that this is to use the AJAX crawling specification instead of their normal crawling specification and append this escape fragment parameter to the page URL and call it again. Basically, I try to detect if there’s been an escape fragment parameter, and if there is, then I serve up content specifically for the spider. That content is just pure HTML and it’s basically the same data that you see when you’re looking at the JavaScript web app but it’s just specifically for a robot. JAMISON:  That’s super cool. Yeah, I did what you said and put it into Google and there are plenty of results. JOE:  So your server has to provide data HTML then? ALEX:  Yeah, that’s right. If you type in, go to a Monocle URL and then put the parameter _escaped_fragment_ and refresh the page, then it’ll serve up data that’s specifically for the bot. AJ:  So, I was watching a Google SEO talk on one of the Google tech talk channels on YouTube and the guy was saying that you don’t necessarily even need to do that because the Google bot, at least, if you have some sort of pushState or a fragment or something like that, it’ll wait a second for JavaScript to execute before it indexes. ALEX:  Yeah, so this is what I thought as well. It may be the case. But I did a bunch of tests around this to try and see what was going to be picked up, what wasn’t being picked up. And I just found that just a pure JavaScript web app wasn’t being picked up very well. CHUCK:  Is there a blog post or anything that explains how you’re doing that SEO stuff? ALEX:  Yeah, there is. Again on my blog, if you go blog.AlexMacCaw.com, there is a post called ‘SEO in JS Web Apps’. JAMISON:  I have a different question and it’s more about the content of the site than the tech of it. What led you to want to make a Hacker News clone or replacement? ALEX:  Well, it’s an interesting technical problem, but also it’s kind of just sick of the community in Hacker News. [Laughter] CHUCK:  I’m laughing because I feel the same way. Anyway, go ahead. AJ:  Yeah, totally. ALEX:  And I’m just kind of being the fairly pretentious chap I am, I just thought, “Well, why not make my own community?” [Chuckles] And so, I don’t know if I’ve bitten off more than I can chew. But there’s some great content on there and the community is slowly gathering together. I don’t know if it’ll ever be as big as Hacker News is, but at least it’s nice. JAMISON:  That’s a social problem, right? Partially from the growth, but I don’t know. Yeah, I don’t know exactly what causes it, but it’s definitely not a technical problem, or at least to me. ALEX:  That’s right, yeah. JAMISON:  So, are you doing anything to solve the social problems or are you just trying to make a new group and hopefully the toxic people in the old group don’t come over? ALEX:  Yes, I am doing some stuff to solve social problems. One of the things is you connect with your Twitter or your GitHub account and that’s the only way to sign in. And you have to be invited to join, so it’s invite only. And the people you invite, their contributions reflect on yourself. And if someone’s banned, then that’s it. They’re banned. They can’t sign up under another account because it’s invite only and it’s connected to their Twitter. So, those are kind of the steps that I made to try and ensure that the community remains a really, really friendly and positive one. But also, there’s no doubt about it that it does affect how many users on the site. It affects the growth rate. There’s no doubt about that. So, it’s just going to grow really slowly. And we’ll see, I guess, if it takes off one day. CHUCK:  So, you basically get two shots. You can sign in with a GitHub account then with a Twitter account, and then you’re done? ALEX:  Yeah. Well, you sign in with your Twitter account and then you have to get an invite from someone, basically. JAMISON:  So, you can sign in but you can’t post or vote until you get invited, is how it works? ALEX:  Yeah, pretty much. Any changes, any comments, any new posts, that is all invite only. CHUCK:  That’s awesome. I have to say that I really have some issues with the community on Hacker News. Most of it just centers around there are a handful, maybe more than a handful of jerks on there that just anything that means anything on there. There’s some constructive discussion about it and then there are the handful of people that just ruin it. So anyway, I’m really excited about that. I do want to kind of get back to the technology on this, though. Everything comes up so quickly. Are there any other tricks other than just the delayed, deferred promise, decorated promise that you did and things like that? ALEX:  Well, for logged out users, everything is cached. So, nothing has to be dynamic for logged out users. For logged in users, obviously, there’s some dynamic stuff. If you upvoted a post, then that is information that’s specific to you. It can’t be cached. So, there’s that. And there’s this other tool that I’ve been using. It’s called Google Website Optimizer. Again, it’s linked to in that blog post. This is something that, actually Chrome is going to deprecate the tab in Google Chrome, in the Chrome inspector, called audits. They’re going to deprecate that and they’ve just got this web service now. It’s actually really good. You just put your web app in there and you just hit enter and it’ll tell you everything that’s wrong about your web app and how to make it faster, basically. I’ll post a link and we could put it in the show notes. JAMISON:  That’d be sweet. CHUCK:  So, how much of the work to make it responsive and things did you have to do on the frontend versus the backend? ALEX:  It’s about half and half. It’s definitely tuning both for another app I’m doing. I’m actually putting everything in Redis and holding everything in memory. So, its server responds incredibly quickly. And if you need that kind of responsiveness, then I’d recommend that. CHUCK:  That’s really interesting. So basically, nothing’s hitting your, say you have a SQL-based backend, PostgreSQL, SQLite, MySQL, something else, on the backend, it’s essentially cached in Redis and then just pulled out and served up? ALEX:  That’s right. There’s this other, if you don’t mind, I’ll talk about it a little. It’s called Sourcing.io. It’s an app for sourcing engineers. Again, it’s built with this new JavaScript web app framework. There are two million engineers in there and I hold everything in memory.  So basically, the server responds extremely quickly. You don’t have to worry about that kind of latency. Most of the optimization actually occurs on the client side. AJ:  Crazy. JAMISON:  So when you’re talking about holding everything in memory, that’s eliminating the need to go out to a database, right? So, that’s a large source to your server I/O? Or do you mean in memory like in Redis? ALEX:  I mean both, yeah. You’re right. You have the network latency to contact the Redis server, but it responds a lot quicker. The other problem I had was most traditional databases are really bad at managing large offsets. For example, there’s a big table in this app and you’re scrolling this table and the offsets may be two million. So, your traditional PostgreSQL database has to scan through all these records one by one to find the offset that you specified, and that takes ages. Whereas Redis, you have some awesome utilities where you can store an array in Redis and then you can basically ask for specific offsets. And it doesn’t matter how big the offset is, it’s always returning in 01 time. CHUCK:  Oh, wow! JAMISON:  So there’s a broader theme that’s happening right now that I wanted to talk about. This is JavaScript Jabber and we’re talking about how to make, specifically JavaScript-heavy client-side rendering apps fast. But still, we’re spending lots of time talking about the server. And it seems like that’s a huge part, even if you’re doing client-side rendering. That’s not just magic sauce you sprinkle on your app to make everything super-fast automatically. Do you feel like there’s room for just strictly client-side only developers? Or do you feel like they need to be aware of server-side things like this, too? ALEX:  I personally think developers should be full stack. I can’t imagine just knowing JavaScript and not being clued up on the server. If you want to have a really fast first experience, like the initial page load will involve some server tuning. From then on, you can fake it. You can client-side render and preload stuff and have an optimistic UI. But if you’re going to speed up the initial page load, then you need to get your hands dirty on the server-side. AJ:  So, I want to throw in a comment to that as well. I feel like the web, in all of its moving forwards, is in a sense taking a step backwards where it seems like you have to know more and more and more to do basic things well. So, if you write JavaScript, just considering JavaScript itself, and you do the naïve approach of things, it’s actually going to run really well. Because the compiler figures out what optimizations you need to do. And if you put in weird things like ++1 or if you do 1++ or whatever it is that you do, the naïve approach is going to be the fastest according to what Google’s trying to do. They’re trying to get the naïve approach to be the one that works best. And if you do weird stuff, maybe it’ll make it faster but it probably won’t. But I feel like web development as a whole is more like Assembly where you’ve got to understand HTTP, you’ve got to understand the server, you’ve got to understand CSS. You’ve got to understand so many things. Just like with Assembly, you have to understand pointers and hardware and the naïve approach doesn’t just work. Does that make sense? ALEX:  It does. Things have definitely gotten better and if you are just not looking to get that involved, then you can use, there’s a bunch of extremely friendly frameworks out there. Imagine what it was like before Ruby on Rails came along. That was a big turning point for a lot of programmers. And imagine what it was like when you couldn’t specify border radius and you had to use images for every corner of the border. So, I think things are a lot better than they used to be. But I agree, you have to have a lot of memory states when you’re programming. And I think the best programmers I find, can hold a lot of state in their head, or at least enough lookup so they know, “I need to Google XYZ to do that.” That I think is the greatest skill to programming actually. AJ:  Amen to Google. ALEX:  [Laughter] By the way, I want to say that the tool that Google used is actually not called Webspeed Optimizer, it’s called PageSpeed, developers.google.com/speed/pagespeed/insights. You can just enter any URL in there and it will tell you what it looks like on mobile. It’ll tell you what it looks like on different browsers and it’ll tell you the kind of things that you should be improving, like server response time or compressing or caching, that you can use to basically make that initial page load extremely fast. CHUCK:  Yeah, I’ve been playing with it and it’s pretty cool actually. One thing that I’m wondering about is you got your JavaScript to be very, very performant and responsive. I keep saying responsive. I don’t mean responsive design. Anyway, and we may talk about that in a minute if you’ve done stuff with responsive design on Monocle. But how do you test it for performance? ALEX:  I mostly use that tool. I refresh it a lot. And I just try and tweak it and try and basically look in Google at the network tab and see how, I’m sorry, in Chrome at the network tab and see how long each resource takes to load, what are the bottlenecks, and then I take it from there. JOE:  That seems pretty unscientific. CHUCK:  [Laughter] ALEX:  Yes. Yeah, pretty much, yeah. CHUCK:  So, there’s no benchmarking or whatever to try and save a few milliseconds here or there? You’re actually looking at the response over the network and things? ALEX:  Yes. That’s right, yeah. But basically, follow best practices so you get relatively fast. Then go back in and figure out where the bottlenecks are. Now, I usually find the bottlenecks are something weird happening on the server or just some really un-optimized, un-indexed database query. Or I find that you’re doing way too much rendering on the client. The key to make client fast is try and do as little rendering as possible. And when you do that render, make it all at once. So, you want to do as little painting as possible. AJ:  So, with the PageSpeed tool, they’ve got a lot of breakdowns into milliseconds and it seems like a lot of that stuff is really helpful, let you know if you have a particular resource that isn’t being compressed that should be compressed, that kind of stuff. So, in terms of science, have you found that to be particularly useful? Or is it more the doing by hand, like you were just saying? ALEX:  Oh, I use that tool, absolutely. I use a bunch of tools. That tool, the Google Chrome console, and also just try and optimize just plain server response time. So, I’ve got a bunch of tests that basically record the API response time from the server and I’ll try and optimize that. And what you can do is when you test run, every time you deploy it, you can see if you’ve added something that’s caused a significant increase in latency. CHUCK:  The thing that really strikes me is that a lot of this stuff really seems like it’s not terribly hard to do. And so, I wonder a little bit why it’s not more common knowledge. ALEX:  Well, there aren’t that many resources out there which is why I wrote a post on it. Paul Irish has a ton on it. There’s a few out there. I’ll try and find some for the show notes. But you’re right, there’s not much information on that out there even though it’s a fairly straightforward kind of information. JAMISON:  It seems like another thing is you can find parts of it in different places. ALEX:  Yeah, maybe this is another book idea for O’Reilly. [Laughter] CHUCK:  Probably wouldn’t hurt their feelings. So, I’m wondering if you could just walk us through the process of designing a website like this, where you started and how you got to where you are. ALEX:  Basically, I start off with a Sinatra app. I have a few libraries that I pretty much include in every Sinatra app that I make and I would design the models first, write a series of migrations. I use Sequel. It’s an awesome ORM for Ruby. I write those migrations, write the models. Then I will write the API. Then I will jump into the client side. I do all the designing for my apps on the client side. I don’t use Photoshop or anything. I just tweak the CSS until I like it. Then basically, I would try and split the app in my head into separate components. So you see, for Monocle, you have the sidebar and then you have the main post panel. And then the main post panel is separated as well. So, you have comments there and then you have a description at the top of the post. So, I try and separate that all out in my mind and then I will write controllers with that in mind. Or I think in Backbone, they’re called views rather than controllers. But basically, everything is split up. So, you have the sidebar here in Monocle. That actually doesn’t know anything about the rest of the app. That’s purely functional by itself. All it needs to know about really is the models. Then the main page as well. You have the comments section. That only knows about comments. It doesn’t know about posts or anything else. Then there’s a tiny bit of high-level glue that ties everything together. JOE:  That’s very interesting. So, how are you getting the pieces to coordinate and communicate? The main part on the right and the panel on the left, how are they coordinating with each other? ALEX:  I do have a global state model and that has a bunch of things in it. It has the currently selected post and it also has the currently logged in user. So, if anything wants to access global state, it can basically add an event listener onto those properties then basically re-render itself whenever those properties change. JOE:  Gotcha. So, you built the MVC framework for this. Is this the only place you’ve used that MVC framework? ALEX:  This place and Sourcing.io, which I just put a link to in the show notes. Those are basically the only two places. Then I’m trying to separate, like I said, trying to separate out some of the nice things about it and push them back to Backbone. CHUCK:  So, what is Sourcing.io? You brought it up, so I may as well ask, right? ALEX:  It’s a platform to source engineers. So, if you’re trying to hire engineers, then you can use it and it will basically allow you to search engineers pretty easily. And you can specify, “I want Ruby engineers. I want Python engineers. I want Engineers located in San Francisco with a score better than this. I want engineers that follow me on Twitter. I want engineers that have changed jobs in the last -- sorry, been at their jobs for about a year,” that kind of thing. So basically, it’ll give you this information and it’ll let you contact the engineers and try and hire them. And then basically with this, I’m trying to raise the bar with hiring. I’m sure all of you have received those emails which are just painful, from recruiters, where they start off with, “Hey Alex,” and then they have the rest of this boiler plate text about this job. They haven’t looked at your profile or anything. The last sentence usually ends with, “If you’re not interested, please send on this job offer to all your friends.” [Laughter] CHUCK:   Yeah. ALEX:  Like one of those crazy chain letters. And so, I just want to try and raise the bar a little bit with recruiting. So, this is a new startup that I’m working on. CHUCK:  That’s really cool. I love getting those emails. In fact, I’ve been working on a blog post for a while that’s basically, “Dear recruiter, here’s why I’m not responding or responding the way that I am.” Yeah, anyway, it does kind of hark to some of the issues there with those. But it’s really interesting. This is also fairly responsive. If you scroll down on the endless scrolling, it does take a second to load more records. ALEX:  Yeah, unfortunately, there’s only so much you can preload because there are a few million developers in there. And what I’m actually doing is when you’re scrolling, I’m cleaning up some of the other records for the view to the apps that you can’t currently see. Because otherwise, you’re just putting so many DOM nodes in the browser that it eventually crashes. CHUCK:  And how are you sourcing these developers? ALEX:  Oh, just public information out there; their work, open source work, their profiles in Stack Overflow, that kind of thing. CHUCK:  That’s really interesting. JOE:  Yeah. So, where do you get the inspiration for these ideas? It’s always kind of ‘I hate this, so I’m going to do it better’. Is that pretty much? ALEX:  Yeah, it’s mostly being really frustrated with the world and being naïve enough to thing that you can improve things. JOE:  And it also seems like Monocle was almost, obviously what you’re trying to do by replacing Hacker News with something with a more positive environment is great, but it almost is like you made up that idea just so you could have this study in performance. ALEX:  Yeah, that’s right. Like I say, I love reinventing the wheel. So, this is how I’ve ever learned anything new, is basically setting myself a project and basically coming up against walls and trying to overcome those obstacles. JOE:  So, what would you say are the major things you didn’t know that you learned while building Monocle? ALEX:  Oh, well it’s definitely the performance is one of them. I actually developed this new framework building it as well. Then there’s the sidebar. Building a working sidebar with keyboard shortcuts is actually kind of tricky. Because the sidebar needs to scroll but if the main area needs to have focus, then when you press up and down arrows, that needs to scroll as well. So, you’ve got to have active areas in mind. Then you’ve also got to, when you scroll the sidebar with the arrow keys, you’ve got to keep the currently selected post in view. Again, that is fairly tricky to do. So, those kinds of little techniques that are pretty useful, whatever is just useful pattern, whatever web app you’re building. Those are the kinds of things that I learned building Monocle. JOE:  Interesting. But it seemed like you already knew, I don’t know. I got the impression based on how performant Monocle was, you already knew a ton about performance. But you kind of said performance was the thing that I learned, indicating that that wasn’t already an area of expertise for you. ALEX:  Yeah, that’s right. I knew a bit about it because I wrote a chapter on it for the O’Reilly book. But there’s always more stuff to learn. JOE:  Well, that’s certainly true. So, of the things that you learned about performance, is there anything that you found particularly surprising while building Monocle? ALEX:  Well, that you can solve SEO so easily. I never really knew about that. And when it comes to performance, most of the things, like you say, are fairly straightforward. For me, most of the optimizations that I didn’t know about resided in the Ruby stack and using a Ruby server that was multi-processed because Ruby has a global interpreter log and it’ll lock up whenever you access the interpreter. So basically, nothing can happen in parallel even if you have threads. So, it was to do with little optimizations about choosing Unicorn instead of Thin, choosing a really good database driver, trying to optimize the backend. For me specifically, was what I most learned on Monocle. JOE:  Gotcha. CHUCK:  I’m not sure I have any more questions for you. I am going to go and dig into some of this stuff and see what’s there and I would love to see what you’re doing with Sinatra and Redis to load all that up and make it all work. There isn’t any chance you’re going to open source Monocle, is there? ALEX:  Actually, yeah. I’m thinking of open sourcing it. I think that’ll happen next week. CHUCK:  Oh, nice. JOE:  Very cool. CHUCK:  Then I can go read it and feel smarter. ALEX:   [Chuckles] CHUCK:   So, is there anything else we should know about making websites performant or Monocle or Sourcing.io or anything else that we’ve talked about today? ALEX:  Not specifically that I can think of. I just want to thank you guys for having me on. It’s always a lot of fun. CHUCK:  Well, this has kind of got me fired up. [Chuckles] CHUCK:  I’m really excited. ALEX:  Good. I’m glad. That’s exactly why I come on this kind of things. CHUCK:  Yeah. And I’ve been playing with this PageSpeed thing for the last 20 minutes while we’re talking. And there’s a lot of good stuff in here. Holy cow! I pulled up a website that I’ve been working on for a while and it says, “Leverage browser caching,” then it tells me all the files that are not cached, that don’t have the expiration headers in them and, “Eliminate render blocking.” You know, if you drill down into it, it tells you what to do to fix it. It’s just really cool. ALEX:  It really is. And it’s great that Google is investing so heavily in speed. It even affects your page ranking. They really, really think it’s crucial. And it really, really hurts conversion if you have a slow website. It’s basically one of the biggest performance gains you can get in conversion, is just trying and make things fast. CHUCK:  Conversion, you mean as far as being able to sell whatever you’re selling on your website? ALEX:  Yeah, that’s right. Google found out that if they just had an extra 100 milliseconds of latency on every search result, that they had significantly less click-throughs. CHUCK:  A hundred milliseconds, is what you said? ALEX:  Yeah. CHUCK:  So, if the page comes up in more than 100 milliseconds? ALEX:  If the page takes 100 milliseconds more than it would originally. Basically, they had a bunch of tests, some of which slowed down the page to try and detect the impact of page speed on conversion. AJ:  So if that’s true, then why is it that when I click on Google search results, it redirects me to their analytics thing that takes for-freaking-ever before it redirects me to the actual site? [Chuckles] ALEX:  Yeah, I actually completely agree. Unfortunately, that’s basically the only way of detecting a click-through because if you try and detect it by the usual methods like say, put an image, one by one pixel image on the page, or however you usually detect it, that image probably won’t load because the page is redirecting. So, the only way you can really detect if someone has clicked on an external link is either to delay them a few hundred milliseconds while your analytics image is loading or to do the redirect. AJ:  Yeah, I understand why they do it. I think they’ve probably searched every opportunity and found that that’s the best one and that’s why they do it that way. But it really does annoy me that sometimes it’s just quicker to just highlight the URL that comes up and paste it in than it is to click on it because their analytics has certain, probably, peak times of day where it just takes full seconds for it to do the redirects. It’s not even the fault of the page on the other end. ALEX:  Oh yeah, that’s true, absolutely true. It’s super annoying. One of the things actually I do with Monocle that I forgot ‘til now is I actually pre-render the article. So, if you have an external article in there and you look at it for more than three seconds, I add this tag to the page which tells Google Chrome to go and fetch that external article, pre-render it, and get it ready. So when you click on the link, the article shows up immediately. AJ:  Huzzah! Yeah, and it seems like since Google controls Chrome and Chrome is maybe the primary browser these days, aside from the pirated copies in China and the ones that are in the bank where they only have two sites they can visit anyway where they’ve got Internet Explorer, but it seems like they could probably do that analytics tracking in Chrome just like Chrome extensions do without having to slow you down. ALEX:  That’s true. And they probably do that anyway, to be honest. [Chuckles] AJ:  Interesting. CHUCK:  Awesome. Well, let’s go ahead and wrap up the show. Thanks for coming, Alex. Really appreciate it. We’ll get to the picks and then we’ll be done. AJ, do you want to start us off with picks? AJ:  Sure. So, there is just some cool stuff. We were talking about Insights and some of those other tools. I posted a bunch of links in the chat, so hopefully those make it up. But Google does have a lot of cool tools, including MicroFormats, which is you’ll notice sometimes when you do Google search, you’ll see a picture and you might see the tabs broken down into different links underneath the item’s name. So anyway, there are things that you can do with your HTML to put little special classes in there or whatnot to let Google and other search engines know that this data has meaning. It’s not just for a wireframe or for presentation. So, check out those links. Then I ordered an OUYA back when they were on Kickstarter and I finally actually got it because it actually shipped to my old work because I didn’t have time to update the address information and everything. Then it went to my friend at work and then eventually, it made it back to me. So, I got that set up last week. And I have to sadly say that the console in and of itself is pretty unimpressive. I bought four controllers for it and there’s only about two multiplayer games that I could find that were of interest. But I do have to say that TowerFall is really fun. It’s basically like Nintendo-style graphics. Super Smash Brothers is what the game is. And that’s really fun. Also, you can run emulators on it. So, you can play your Super Nintendo games and everything off of an SD card. And it’s pretty easy to, I guess it’s called side load which is basically where you put the Android APK on the SD card and then load it that way instead of getting it from the store. So, they’ve got that built in. There’s a little function that lets you do that. So, my second pick here would be the OUYA. But then that leads me to my third pick which is Final Fantasy 7. Because when I was younger, I’m like talking elementary school here, I had this friend who had the game but every time that some girl that he liked that he brought over would flirt with me, which was every time because he was always super aggressive and I was always like, “Whatever, I don’t care,” he would erase the memory card and I would lose my game save. So, I’m finally beating Final Fantasy 7 for the first time ever, that I’m going to make it all the way to the finish and I’m super excited about that. It’s such a great game and a great story. JOE:  That’s the saddest story I’ve ever heard, but not for the reason you think. [Laughter] AJ:  Well, why is it the saddest story? JOE:  It’s just kind of a pitiful story about you and being a teenager. AJ:  No, I was not a teenager yet. JOE:  Oh, pre-teen? AJ:  Yeah. This was literally probably like third or fourth grade. I don’t remember. 1997 I think is when that game came out. So I was young, young, young back then. But I’m finally, thanks to the OUYA emulator, FPse is the one I’m using. I’ve got a couple of tweaks on it so it re-renders the graphics so they don’t look like absolutely wretchedly pixelated. Anyway, that would be it for me. CHUCK:  [Laughter] Alright. Joe, what are your picks? JOE:  Right. So, I’ve got two picks. The first one is a musician. The band name, I guess, is Sunlounger. It’s just kind of this quiet relaxed mix of music. One of their playlists on Spotify is called the ‘Chill Out Mix’. So, I’ve just been really enjoying that, listening to Sunlounger while I program. It’s been perfect music. Not too boring that it puts me to sleep, but not too exciting that it distracts me from work. So, I’m going to pick that one. I also want to pick, on my second to last day at Domo, I won a Pebble Watch from a programming competition or hack night. And I’ve hooked it up to my phone and it notifies me every time I get an email or a text or when I get a phone call and I have absolutely loved it. Although I’ve learned that I am now way too connected. So, I take it off while I work so that I don’t get disrupted nearly as easily as I was when I was wearing it. But it’s been an awesome, awesome watch. And I would also like to put out a reminder about ng-conf. We had our early bird sale on Monday and tickets sold out in about ten seconds, which was absolutely crazy. So, by the time this podcast gets put out, the second round of slightly discounted tickets will have gone on sale. And based on the interests, will probably also sell out in ten seconds. So, I’m excited for ng-conf and I’m excited to be part of that. CHUCK:  Didn’t you also open up your call for proposals? JOE:  Yeah. We did. We opened up a call for proposals. It should be open until the end of September. So, by the time this gets published, there’ll be a little bit of time left to submit papers for the calls for proposals. I think we’re really looking for somebody that can talk about Angular and Node and somebody who can talk about Angular with Rails. So, those are two talks that we’re having trouble finding people that can present on. CHUCK:  Good to know. Alright. Well, I’ve got just one pick, the book ‘Book Yourself Solid’ by Michael Port. If you’re a freelancer or a service provider, it is an excellent book about marketing and sales. I’ve really, really been enjoying it. We’re actually going to be interviewing Michael next week on The Freelancers’ Show about the book, doing a book club. So, if you’re interested in that, if you’re a freelancer, then keep an eye out for that on The Freelancers’ Show and that’s at FreelancersShow.com. And that’s all I got. So Alex, what are your picks? ALEX:  I have two picks. The first is this project by Google called Coder. It’s googlecreativelab.github.io/coder. And it’s pretty awesome. It basically is some firmware for the Raspberry Pi. And it lets you code in JavaScript and HTML and straight on this Raspberry Pi. So, you can have this Arduino-like device. And you can code it easily with JavaScript. So, that’s a pretty awesome little project. The other one I have which is kind of just for fun is something called the Ig Nobel Prizes. These are basically like the Nobel prizes but they’re the ones that didn’t make the take. They’re kind of the funny ones. You can find them, the prize winners are on the Wikipedia, but there’s some amazing, amazing awards here given. Some of the hilarious ones are like the prize in 2012 for Physics was to Robin Bohr for calculating the forces that shape and move the hair in a human pony tail. And there is one in Psychology, the study for why leaning to the left makes the Eiffel Tower seem smaller. These things go on and on. They’re all hilarious. CHUCK:  Awesome. Alright. Well, let’s go ahead and wrap up the show. Thanks for coming, Alex. It’s been a really, really interesting discussion. JOE:  Yeah. ALEX:  Thank you so much for having me. CHUCK:  Alright. Well, we’ll wrap up the show. We’ll catch you all next week.

Sign up for the Newsletter

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