Transcript

CHRIS: Hey, everybody!  Thanks for listening to Shop Talk Show.  We have two lovely sponsors for you at the top here.  Environments for Humans are promoting their RWD Summit, Responsive Web Design Summit.  That's RWDsummit.com.  Three days coming up March 11th through 12th.  If you'd like to go to that, use coupon code SHOPTALK for 20% off.  And lynda.com/shoptalk is a ten-day free trial.  They've just extended it a little bit.  It's a huge learning resource on the Web.  Check that out.  We're going to tell you more about both of those things later in the show.  For now, let's kick things off.  

[Banjo music - intro]

DAVE:   Hey, there, Shop-o-maniacs.  You're listening to another episode of the Shop Talk Show, a podcast all about front-end Web design and development, JorbaScrump, all those things that you use on a day-to-day basis.  I'm Dave Rupert.  With me is Chris Coyier.  

CHRIS:  Hey, everybody.  With us, we have Mr. Tom Dale.  Hey, Tom.

TOM:    Hey, guys.  I can't believe you got the rights to the Firefly theme song for your podcast.    

[Laughter]

[Ta-da orchestral fanfare sound effect]

DAVE:   No, the Firefly theme song has this cool acoustic guitar, and it's like, "Ain't nobody out in the West."

CHRIS:  Whoa!  I thought you had it for a minute--

DAVE:   It's really weird.

CHRIS:  --but then you went off the rails there.  "You can't take the sky from me."  Come on, with the little dun-dun banjo thing in it.  Yeah.  It's close though.  Tom Dale, man of a few letters.

DAVE:   Hey, Chris.  Can't take me off the rails?

[Badum-tsh sound effect]

CHRIS:  Hey.

DAVE:   Is that a segue?  

CHRIS:  That was okay.

DAVE:   Went off the rails.

CHRIS:  Tom, you are --

TOM:    The funny thing is, I never wrote any Rails apps, really.

DAVE:   [Laughter]

TOM:    Yeah, people think I'm a big Rails guy, but I just like the ideas, but I don't actually--

DAVE:   Okay.

TOM:    Yeah, I couldn't write Ruby to save my life.  That's not entirely true, but it's 98% true.

CHRIS:  That's interesting.  

DAVE:   Awesome.

TOM:    Yeah.

CHRIS:  You weren't a Rails core team member or anything like that?

TOM:    No.  No, I haven't really been programming for that long, to be honest with you.  I was actually programming long enough to have been an early Rails contributor.

CHRIS:  That's interesting.  But people associate that because you are associated with Yehuda, and Yehuda is a Rails contributor.

TOM:    Yeah.  Also, I just take all of DHH's good ideas, and I repeat them as though they're my own in a JavaScript context, so that's why people associate me with it.

CHRIS:  I see. 

DAVE:   Yeah.

TOM:    But, yeah.

CHRIS:  That's cool.  Yeah, and it's related to, I don't know, like if you go to Tilde.io, right?  

TOM:    Yes.  Yes, that is correct.  Thank you.

CHRIS:  Mm-hmm.  I need to go there because I want to look at it.  There are logos.  There's your beautiful team.

TOM:    Yeah.

CHRIS:  Tom in plaid, Yehuda, and Leah.

TOM:    Well, yeah, but the thing you have to keep in mind is that Yehuda has written half the Internet, so anything that he's touched, we're going to put on there for promotional….

CHRIS:  Did they put him in the middle on purpose then, in the shot?

TOM:    Yeah, absolutely.  Yeah.  If you think about it, I feel like, on a day-to-day basis, the majority of the world runs software that Yehuda wrote.  If you think about it, like if you think about jQuery, Rails, Ember.

CHRIS:  Huge.

TOM:    Especially if you take into account the standards work.  I'm a huge fan boy.  It's actually really cool to work with someone that you're a fan boy of.  

CHRIS:  Yeah, that's awesome.  What a nice thing to say.  The thing that you work the most on that's also a part of Tilde and probably what most people know you possibly from that are listening to this show is Ember, so I thought we would ask you Ember questions, talk about Ember a bunch, and talk about new things happening with Ember and stuff.  Do you have any kind of intro for us for that?

TOM:    Intro for Ember - well, I would say that obviously Ember is the best technology ever written.  If you're not using it, you're probably doing something wrong.  Literally any problems that you've having right now-- like, think about the code you're writing right now--probably all those problems and frustrations you're having right now would be solved if you used Ember.

CHRIS:  Can it do division?  

TOM:    It can do division, not by zero or inversion of three.  It can julienne fries, however.  

CHRIS:  Good.

DAVE:   This is great, so Ember is node bots for the cloud, website.

TOM:    Well, it is enterprise ready.  It actually is used in the enterprise; I have to say.  The thing I think about Ember is obviously a JavaScript framework.  Probably everyone listening knows Ember is a JavaScript framework, but the big difference between Ember and most other tools is that we're not really designed to be sprinkled on top of an existing server rendered app.  The whole point of Ember is to bring an architecture.

    Think about using native apps on a mobile device like on iOS or on android and how fast and how responsive they feel.  You can get that kind of responsiveness because all of the rendering and all of the decision-making is happening on the client, on your phone.  Then that phone is just talking to an API somewhere.  

    Ember is all about bringing that exact same architectural model to the Web where your website is literally just another client of the API, like your iOS app, like your android app, except it still feels webby.  It doesn't feel like a native app.  We're not going for, like, SproutCore or Cappuccino, the two major projects that tried to accomplish this native look and feel.  We don't care about native look and feel so much.  We care about this architecture, basically.

CHRIS:  It's architecture, and it's speed.  Yeah.

TOM:    The architecture buys you the speed, I think.  But more than that, I think the biggest thing that I want to kill is complexity.  Developers spend so much time just battling with complexity and solving the same problems over and over again.  Having this architecture -- you have to have an API anyway for your mobile apps.  Making your website just a client actually dramatically simplifies the architecture.

CHRIS:  Okay.  That's an interesting point because even me and Dave were talking about it last night and be like, oh, it's going to be fun tomorrow.  It's going to be another show where we're going to talk a lot about JavaScript architecture stuff.  We're kind of like, this would be interesting to get a super core person like you to kind of get us in and sell us on the idea because I don't think me and Dave, either of us, have really.  We've certainly never built a full Ember app or anything, or really used any of these in a big way.

TOM:    Yeah.

CHRIS:  As somebody who, like I work on apps that largely do server side rendering, and then we use jQuery and pull the bits that we need and stuff.  

TOM:    Yeah.

CHRIS:  Sell us on that idea, maybe.  It's kind of rewrite territory if we were to--

TOM:    Yeah.  Yeah, I think it is.

CHRIS:  Yeah.

TOM:    I don't know about if it's rewrite territory, but it's definitely greenfield territory.  You can start to migrate over page-by-page.  

CHRIS:  Mm-hmm.

TOM:    It's not like you have to drop everything that you have and start over, but you do have to kind of start, you know, like we're going to redo this page as an Ember app, let's say.

CHRIS:  Yeah.

TOM:    But I think the thing to keep in mind is everyone who has a mobile app has to have a json API, right?  Imagine using a native app where every transition where it slid from one side of the screen to the other, all of that was instructions coming from the server.  That would feel terrible, right?  But when it comes to writing websites, we're totally okay with that model.

    I think the analogy that Trek, a fellow core team member used, was basically, for the last couple years, with every interaction on the Web, there have been two super computers involved: a super computer sitting right in front of you and a super computer in a data center somewhere in West Virginia.  That super computer sitting in front of you, we have not begun to take advantage of.  

CHRIS:  Right, it's just capable of way more than what a browser is.

TOM:    Yeah, it's so much faster.  You can deliver interactions that you couldn't deliver if you have this minimum latency of, let's say, 50 to 100 milliseconds, probably more.  That 50 to 100 milliseconds is a best case scenario.  People have discovered that, and that's why you start to use jQuery, right?  What are the times when you would add jQuery to a server-rendered site?

CHRIS:  Yep.  When you would add to a rendered site?

TOM:    Yeah.  When do you feel like I should add jQuery to the site?  What are the types of things you use jQuery for?

CHRIS:  For classic things.

DAVE:   DOM manipulation.

CHRIS:  Right, DOM and Ajax.

TOM:    Right, because basically what you want to happen is that when the user clicks a button, boom, the page responds instantly, right?  You want to show a loading spinner, which is the classic case.

CHRIS:  Sure.

TOM:    But what if every single navigation, what if every single action on the page felt that fast and that good?  That's what you get when you move the entire logic of the application away from this super computer sitting in a data center.  By the way, an iPhone 6 is more powerful than whatever micro instance you have in AWS.  I'll just throw that in there for the record.  

You have this computer that's actually more powerful than your server sitting right there plugged into the glass that the user is looking at.  By moving the logic from the server there, you can make every aspect of the interaction that fast.  The quickness of the interaction that you get with jQuery, imagine if everything was that fast, including navigation.  

CHRIS:  Because it has the template.  It has everything but the data, right?

TOM:    It has everything but the data, but oftentimes it has the data too.  This is the thing that I think people maybe don't understand is that if I am viewing some data, like email, that email doesn't change.  It's immutable, right?  If I leave the page, but then I come back, that email was just in memory a few seconds ago.  Why shouldn't I keep it in memory and then just display it without having to fetch it across the network again?  

    If you think about your native apps like your email app on your phone, or if you think about the Twitter app on android or iOS, it works the exact same way.  It caches the data, and then it just confers with the server only to get updates.  

CHRIS:  And you maybe got to that email from a list of emails and, when you go back to that list of emails, that's already there in data as well, I suppose.

TOM:    Right.  Nine times out of ten, that list isn't changing so, when you go back, you can show the data that you had a second ago.  Then you can go say, "Hey, are there any new ones?"  Then, when they come in, you can insert it.  But you can have just a much, much better experience.

    I think the other thing too is just that it's a lot simpler.  Conceptually, the model is simpler.  Your servers, when you're building your website as just a client of an API, become dramatically simpler.  

Every good engineer that you talk to will say, "Of course you should separate concerns."  I don't think that's a controversial statement.  But, at the same time, people who advocate for server rendered Web apps are basically saying, "I want to conflate view rendering and data access and authorization into the same software stack."  

    To me, the UI and the data access are two totally separate things, and there's a lot of benefit in terms of reducing complexity and separating them.  Even having separate teams working on them if you're at a big enough company.

CHRIS:  That's what Ember does is that it might manage that--what is it hanging onto data-wise and what is it going to get rid of--because that's getting a little too much, right?  There are probably apps out there that there's just too much data to hold onto practically for memory reasons and stuff.  Is that the kind of thing?

TOM:    Yeah, and we let you manage that.  Basically, the data layer in Ember is very abstract, so the way that you start is you just do dollar dot Ajax ($.ajax) to go fetch data.  Then there are several different data persistence libraries that try to be more like an ORM.  

One that I work on is called Ember Data.  That's really nice if you have a very conventional API.  Let's say that you're using a backend like FireBase, Hoodie, or something like that.  You can just install our JavaScript library and not have to write any network code at all, which is really nice.  Yeah, there are considerations when you're getting into very large data sets, but, in practice, I think most people are just doing pretty simple CRUD apps.

CHRIS:  Yeah, I am attracted to that idea.  In a traditional setup, we might be like, okay, I know this is what the data looks like, so I have to write some backend stuff to make sure that it's coming at me just as I expect it.  Then I need to write front-end code that's dollar dot Ajax ($.ajax) that is going to go get it.  Then I need to write stuff that's like, okay, now that I got it, what am I going to do with it?  Am I going to template it, or do I not even need to because I can just drop it into stuff that's already on the page?  There's a lot of thinking about it.

    Then let's say it changes on the page.  I need to save it.  I need to write that stuff in reverse to get there.  That is attractive to know that it's just like, I can just kind of make this model of data, and it just kind of knows what to do on both sides.  

TOM:    Yeah, and I think the most important thing is that people who are used to a server rendered environment are used to extremely mature software stacks.  I know a lot of people who are Rails developers who heard the hype about JavaScript and client-side apps.  They were like, oh, let's go check this out and see what this is all about.  

    They go from this very mature stack to the JavaScript ecosystem, which, especially a year or two ago, was extremely immature.  There was no kind of off the shelf stack that you could download and install.  It was like here are 1,000 different modules.  Here are 1,000 different templating systems.  Here are 1,000 different data layers.  Go have fun putting them together.

    I think what Ember tries to do is be a little bit more opinionated and say, "Hey, we have a big team of people.  We have a big community of people using this in production.  These are the things that we think are the best way to build Web applications today.  We have an off the shelf stack that you can pull down.  You can replace bits if you don't like a particular decision that we made because it's all modular, but we have kind of a standard stack that people can pull down.  That level of opinion and basically providing the full picture so you don't spend weeks and weeks arguing over the minutia is, I think, one of the key advantages of Ember over other frameworks in the ecosystem.  

CHRIS:  Great.  Yeah, I think we'll spend a little bit more time on that in a minute.  That was a good intro too.  I think you're going to get more with Ember, right?  It's not a sprinkle in, as you said.  It provides more.

    Let's wait for a question to get up with that, but yeah.  Anything else we should know about Tom?  Portland?  Tilde?

TOM:    I'm loving it.  

CHRIS:  Are you really?

TOM:    Loving it.

CHRIS:  Are you newish to Portland?

TOM:    Yeah, I'm new.  I moved in January.  Yeah, so I've only been here just about a year.  It's great.  The weather is kind of not great right now, but honestly, you know, I grew up in California.  Really, do you want the weather to be so good 24 hours a day, 365 days per year?  Can you be happy when the weather is just perfect all the time?

CHRIS:  I have an answer to that.  No.

TOM:    The answer is yes, you absolutely can be.

[Laughter]

CHRIS:  It bothers me.  I was glad to leave it.  It's dreary and gross right now, and I live in Wisconsin.  I don't mind just because this is where I grew up, so I guess it kind of feels like what I'm used to.

TOM:    Like home, yeah.  

CHRIS:  Every day has its own flavor.

TOM:    Not … weather.

DAVE:   I lived in Los Angeles for two years and I didn't see a single cloud, and it messes with you, man.  

TOM:    [Laughter]

DAVE:   Didn't see a cloud for two years.  It was wild.

TOM:    Well, that's not the weather.  That's just the smog obscuring the sky.

DAVE:   Yeah, there was a haze.  

TOM:    Yeah.

DAVE:   There was haze, varying degrees of haze, but it was wild.  You never saw a thundercloud or anything.

TOM:    No, I love Portland, man.  The coffee is awesome here.  The beer is good.  The food is good.

CHRIS:  Which quadrant?

TOM:    Everyone is, like, mellow.  I'm in northwest, which is like a mini San Francisco.  Now, literally, I moved into my apartment building and, on the second day I was here, I saw a kid in a GitHub onzie.  

[Laughter]

TOM:    This is San Francisco mini up here.  

CHRIS:  Got a little techie.  Yeah, I used to live there for a couple years.  I miss it.  I was northeast though.  Let's see.  Let's get some questions.  How about that?  We have one from Andreas Nevin who says, "I'm not so experienced with JavaScript, so I really don't quite understand the potential benefits from using a JavaScript front-end framework.  Could you describe it with your own words and give some examples for real world use cases?"  

I thought we would just softball you.  This one would kind of be like, okay, Ember is a thing.  We've already kind of made the case for it, but maybe how about some real world examples?

TOM:    Sure.  Yeah.  Well, there's a ton.  This is what's been really awesome for me working on open source.  You toil away for a long time and, for a very long time, you don't really have any adopters.  You're kind of just doing it for yourself.  You wonder if you're just crazy.

    There are several big production users of Ember.  Square is one.  Actually, what I'll recommend to everyone listening at home is, if you go onto the Chrome store, or if you go to the Mozilla add-ons marketplace--whatever they call it--you can install the Ember Inspector, which is an extension for your browser that plugs into your browser's developer tools and lets you take a look at the structure of Ember apps.  What's really cool about this is that you can use it to see how production apps are architected.  For example, you know Vine, the website, the seven-second videos of you punking your friends.

CHRIS:  Mm-hmm.

TOM:    If you log onto Vine.co, and you open up the Ember Inspector, boom; you can see all of the routes.  You can see the models.  You can see how the whole thing is architected.  It's really cool.  

CHRIS:  That is really cool.

TOM:    Another one us Bustle, Bustle.com.  It's like a women's news website.  Just yesterday I was talking with one of the guys there, and he was giving me this demo that he'd built of their backend, their CMS.  Here's what's so cool about Bustle.  The whole thing is just an API.  It's just an API for reading stories and for posting stories.  

If you visit Bustle.com, it's just an Ember app talking to this API, read only.  Then their CMS for their editors and their writers to use is just an Ember app, totally separate code base so you're not conflating these two concerns, and it's just talking to the same API.  Of course, when they roll out an iOS app, it's like no problem.  We already have an API ready to go because that's the API we needed to build our website.  

CHRIS:  That's honestly….

DAVE:   If you navigate around Vine and Bustle, you feel how fast they are, again, because you're not conferring with the super computer half way across the planet to make a decision.  The super computer in front of you is making the decision, so everything feels snappy.  It's super interactive.  To me, that's the advantage of a JavaScript framework.  

It's like, because everything is running on the client, it makes things that are possible with server rendering just so much easier that you actually do them.  Everything on screen is powered by JavaScript, so you can do things like say, well, let's send an analytics event every time this component scrolls into view.  You could do it with jQuery, but you're not going to do it for every section of the website.  But you could, in your Ember app, say, okay, every component, every time it becomes visible, send an analytics event.  That kind of stuff becomes trivial.

CHRIS:  That's nice.  That's a benefit right there.  As it were, I totally am facing that kind of thing right now, like, I wish I had better analytics on usage of things.  It's kind of like an overwhelming idea to think that I have to kind of make a checklist, think of how every single thing works--  

TOM:    Go through.

CHRIS:  --to go through it.  Yeah.

TOM:    Yeah.

CHRIS:  That's interesting.  In the Bustle's case, they'll probably never regret that architecture, and it's not even that dependent on Ember really because it's really just how they did their data on the backend.

TOM:    Yeah, absolutely.

CHRIS:  At some point, if they wanted to redesign, they could just do something else.

TOM:    Yeah, there's nothing specific about Ember to this.  It's just that Ember, by far, delivers the most complete, nice experience, right?

CHRIS:  Right.

TOM:    We do consulting in addition to building our product, Skylight, and doing the open source stuff.  I can't tell you how many meetings I've seen where literally engineers, for two weeks, will argue about what build tools to use.  Then once they decide between Broccoli, Grunt, or Gulp, then you'll have another two weeks of arguing about which CSS preprocessor to use.  Then you'll have another week deciding whether to use dashes or underscores. 

    Engineers are so good at wasting time over the stupidest decisions.  Basically, you can--

[The Zing of the Day sound effect]

TOM:    That's good.  You can change those if you want, but I feel like if, as a community, you decide, okay, guys, these are what we call trivial decisions.  These don't matter.  Let's just all pick one and go with it.  It really, really, really doesn't matter in terms of productivity and delivering really great products to our users.  If you want to change them, you can, but you better have a darn good reason to change the conventions.

CHRIS:  Well said.

DAVE:   I agree.  I think that's what I like most about Rails and that whole culture and framework is just they're saying, hey, don't reinvent the wheel, like, ever.  You may kind of have a dependency hell if you get into some weird gems or something.  But it's more or less like, hey, let's not -- I don't know.  We know this whole suite of software.  These conventions all work together, so we're going to present that in a package.  If you don't like it, you can do your own thing.  But, like you said, everyone just -- the tendency of developers to just rethink things over and over and over and rebuild and rebuild is pretty high, for better or for worse.

CHRIS:  Speaking of weird developer behavior, I'm curious if you've run into, in consulting and stuff, if they don't like the fact that there's such a thing called Ember Inspector, which reveals their entire application architecture.  

TOM:    Not really.  I've had managers ask me about it on the Internet and express some concern.  Of course, there are ways of disabling it.  But I think, because Web developers grew up in this culture of view source--

CHRIS:  Yeah.

TOM:    --where everything is kind of open.  I pilfer CSS techniques from other websites all the time shamlessly.

CHRIS:  Sure.

TOM:    I'm like, oh, that was a cool effect.  Let me go see how they did it.  For whatever reason, this has just become part of the culture of the Web.  

CHRIS:  You can't -- just because you can see it doesn't mean you can do it.  I don't know.

TOM:    Yeah, exactly.  The code is all minified.  People have been shipping minified code for forever.

CHRIS:  Right.

TOM:    You can decompile binaries.  In practice, the kind of people who have the time to go reverse engineer your app are not the kind of people who are actually fielding a serious competitor, so it ends up not mattering.

CHRIS:  Yeah, never.  I've never heard of an example where somebody is like, oh, they stole everything from me and now they're way bigger and I'm out of business.  You know that never happens.

TOM:    Yeah, although I do remember one time when I was working on the iCloud team.  We accidentally did a deploy that deployed the non-minified version of the entire source code and [laughter] I don't think anyone ever noticed.

CHRIS:  Wow!

TOM:    Yeah, but it was big, man.  That's like several megabytes of JavaScript.

CHRIS:  Yeah, that's probably more of a performance concern.

TOM:    Yeah.  I think we ended up catching it right away, but it was still a moment of panic because that was still when Steve was around and people were a lot more scared for their jobs.

CHRIS:  Yeah, there's some -- it's easy to flip a switch and have something like that happen.  We did something at CodePen recently where we stopped G-zipping everything.  It took us a week to catch it.  Oh, my God.

TOM:    Yeah.

CHRIS:  There should be alerts for that kind of thing.  Let me do a sponsor really quick.  We have RWD Summit, that's Responsive Web Design Summit.  It's an online conference coming up March 10th through 12th from Environments for Humans.  

We asked you to send in a question and hashtag it RWDSummit.com.  Very few of you did that, which I get it.  Not everybody wants free tickets to free things, but I just feel like your chances of winning, people, are pretty decent if you just do it.  We're going to do this for one more week, and then the next show that we do, which will be the first one of the new year, we're going to pick the ticket.  #RWDSummit, and you don't have to do it on Twitter.  Just put that in the email when you send in a question from our form on our website so that I can search it and find your submission, essentially, about anything Web design related.  

If you want to make it about Responsive Web Design, that'd be nice because that's what this conference is all about.  It's one of their biggest summits.  It's three full days.  You can attend it from anywhere in the world.  You bring up a Web browser, and it shows you the speakers talking live from their house, and there's a chat room where you all chat and all kinds of stuff going on.  Both Dave and I will be speaking at it, so that's a pretty hot reason to attend it, I would say.  Use coupon code SHOPTALK for 20% off the ticket for it.

    Let's do another question.  What do you got, Dave?

DAVE:   Ezekiel Mangaloo writes in, "Hey, guys.  I've been thinking of learning a JavaScript framework.  So far I've been recommended to look into AngularJS and EmberJS.  What's the advantages of using Ember to Angular in terms of scalability, security, and ease of implementation and maintainability?"  Tom?

TOM:    Ooh.

DAVE:   Softball, or is this a hardball?

TOM:    Well, see, I don't know if that's a softball.  Let me explain the problem to you.  

DAVE:   Ah-ha.

TOM:    Let me explain the problem.  This is a question that we get a lot because Angular is obviously the 800-pound gorilla in the room.  They have a full-time team of 12 people at Google working on it.  It's just me and Yehuda in a shack in Portland.  That's not true.  We actually have an awesome, very widely distributed team.  

    The problem is that it's hard to give an answer to that without comparing the tradeoffs that both projects have made, and it's also hard to compare two things and their tradeoffs without partisans of one side or the other feeling like it's an attack.  

CHRIS:  Hmm.

TOM:    Let me preface whatever I'm about to say--

DAVE:   This is the EmberJS official attack, offensive position.

[Laughter]

TOM:    Let me preface this by saying that I think that Angular is a phenomenal project.  I know the people who write it.  I've met them personally.  I think they're very awesome.  I think they're very smart.  I think you could choose either one and probably be more or less within the same ballpark of -- well, you'll be within one or two orders of magnitude of happiness depending on which one you pick.

CHRIS:  This feels like the CSS preprocessor war kind of thing.

TOM:    Yeah, it's kind of silly.

CHRIS:  At least you're doing something.  But, yeah, go on.

TOM:    I'll talk about two things.  The first I'll talk about is technical, and then I'll talk about the social aspects also.  On a technical level, I think Angular is really great for sprinkling on top of server rendered apps.  If you have a server rendered app and you're writing a lot of jQuery, and you're like, oh, my gosh, this jQuery is turning into a big ball of spaghetti, I think Angular is a really great way of dealing with that.  

    I think Ember's strengths are if you like the idea of having client side routing.  You want that really snappy routing.  You basically want -- you have bought into the idea that separating your front end, your website being just a client of your API in the backend, I think is a great way to go.  

    Now, to be fair, you can also use Ember for the same case of basically starting to move your existing server rendered app over to this new architecture.  My buddy, Brandon Hays, actually gave a really great talk about this at Rails Conf.  I think the talk was called something like Untangling the Ball of Mud [Tame the Big Ball o'Mud], and it was about cleaning up your jQuery app to be an Ember app.

    I think the problem with Angular is that it is much more flexible than Ember.  It is dramatically, dramatically, dramatically less opinionated.  Of course, everything I say here is going to be extremely bias, so you should gut check everything I say with friends who have had experience.  

I spend a lot of time talking to other developers who are blunt with me, and they give me feedback about Ember where it's due.  The thing I've heard from them is that, for people who have built big apps in both Ember and Angular, Angular tends to become very unwieldy at scale.  Once you start adding more than a few developers, once you start adding a bunch of different pages, there's really no good routing solution in Angular, whereas everyone talks about Ember's router being basically the best in the industry.  I don't want to sound arrogant, but I think that's true.  

The people I've talked to have said that because Ember is a much more opinionated framework, you can kind of get your team to align on those opinions and those conventions, and so it tends to scale out much, much better and much easier, and it's a lot easier to onboard new developers.  Now, with Angular, because it's so flexible and it leaves so much of the wiring up to you and the naming conventions, everything is on you.  What I've been told by people who have written the big apps is it essentially becomes like big Backbone apps. 

Backbone is similarly un-opinionated where you have your particular, your team's dialect of Angular, right?  You can't just hire someone who knows Angular and have them come in and be productive right away because you have to decide on which router you're using and which data library you're using.  There are conventions around how you name things that aren't enforced by the framework.  They're enforced socially.  

My belief is that Ember is particularly well suited for larger teams, more than three or four people, or people who have to coordinate together.  That's the technical aspect.  There's a lot more to it, but I'll be here all day if I had to discuss all the technical tradeoffs.

I think probably the most important thing is, it's kind of like a social.  It's not a technical thing, anyway.  I don't know what the right word for it is, but my belief is that you should be using open source projects that align with your interests.  Let me explain what that means.

What I mean is, the people who are maintaining the project should be roughly aligned with the same goals, have the same goals as you do.  I learned this.  There was a really great blog post; one by DHH called Why There is No Rails Inc.  He expanded on his philosophy here.  There was another really great one--I forget who wrote it--but it was by one of the maintainers of Postgres, the database, around the time that mySQL was purchased by Oracle.  

He basically made the case on why Postgres was protected from -- I mean, I don't think Oracle has a really great reputation.  They have a reputation as being somewhat predatory, right, in their business interests.  He made the case of here is why Postgres will never be susceptible to a buyout by Oracle.  

The reason is Postgres is maintained by this coalition of companies.  There's no one company that dominates development.  There's no real full-time developer who is just like: my job is to make Postgres.  Everyone is working at companies trying to solve problems using this tool.  That ends up being an extremely powerful force.  

On the Ember core team, Yehuda and I, one of our very, very first goals was to rapidly diversify the team, which was, we don't want just out company to control the project.  Today, if Yehuda or I got hit by a bus, Ember would be completely fine because we have a team of people who are regularly making contributions.  Very few of them all work at the same company.  

They're spread across the globe.  We have people in Lebanon.  We have people in Australia.  We have people everywhere across the United States contributing code, and they're all working at different companies, and they all have different needs.  

The important thing here is there's a tension in any technology between moving forward, advancing the state of the art, and maintaining backwards compatibility.  If you have a successful product, you can't stop and take six months to rewrite your product using the latest, hottest JavaScript framework.  It's just not tenable.  I don't think anyone who is maintaining a JavaScript framework who had actual products themselves would be willing to say, okay, we're starting over with version 2, and we're going to break compatibility.  It's going to be a ground-up rewrite, and it'll be out some time in the next year.

CHRIS:  Which, it's a not so subtle dig at what's going on in Angular.

TOM:    That's basically what's happening with Angular.  It's an interesting strategy, and maybe it'll pay off.  It's a huge bet, and maybe it'll play off.  Maybe they will leapfrog us in terms of the feature set, but I feel like probably not because, while we have the tension of not being able to, or we have the constraint of not being able to, throw away our products and rewrite them when version 2 comes out, we also have the constraint that we have competitors.  Those competitors will be able to pick up Angular 2 in a year or two when it comes out.  They'll be able to take advantage of this hot, new technology.  

    We have to strike the balance between moving forward and advancing the state of the art without forcing everyone to rewrite everything that they've already built.  We call that stability without stagnation.  We have tried to put guards in place.  

    I kind of thing of open source projects as an organism, and an organism has an immune system.  The best thing that you can do for the immune system of your project is to diversify as fast as you can.  I think this also includes valuing contributors who are not just code writers.  It includes valuing people who write documentation, valuing people who work on infrastructure, valuing people who run events and who organize meet-ups in the real world.  

    We're a very small, grassroots project.  But I think, because of that, your interests tend to be better protected by using a project that it's not just a big group of people who are working full time.  How do we build the best framework because those interests aren't necessarily aligned with yours?

CHRIS:  Even if Angular 2 does -- I'm just going to jump back to something specific here, I guess.  There's some kind of loss of trust there, right?  Even if Angular 2 is great, and it does end up being rather successful, there's always some kind of fear that the same exact thing happens in Angular 3, right?  You're going to probably lose some--

TOM:    Well, you know what's so funny to me is I said this a year or two ago.  I basically said based on my experience at Apple where I was working on SproutCore full time, although I was kind of working on apps on the side, but basically full time working on SproutCore, I know what corporate open source is like.  I know what it's like when you have a big team just chugging away.  I've seen the pathologies that happen with big, corporate open source.  

    Everyone accused me of spreading fud.  Everyone is like, "Oh, this is really unbecoming of you.  You're just spreading fud.  You have no idea what's going to happen."  I just had to kind of laugh a little bit when the Angular 2 announcement was made.  I felt a little bit vindicated.  I know I shouldn't.  I know that's small of me, but I felt a little bit vindicated.

CHRIS:  This might be a correlation and not causation, but if you look at projects that really take backwards compatibility really seriously, they tend to be popular, as far as I can tell.  Something like WordPress has never deprecated an API, as far as I know.  They have tons of old code in there, but they're like, "Well, we're going to support it forever because we take backwards compatibility super, super seriously over a long period of time," and look at where they are now.  

TOM:    Yeah.

CHRIS:  You can make fun of them all you want, but they're absolutely not stagnant, and huge.  

TOM:    Yeah, and I think this is the strategy.  We've basically put in place processes to make sure that we cannot do a big bang rewrite.  For example, we adopted what we call a rapid release cycle.  Every six weeks, just like Chrome, we cut a new release.  At the same time, we have a beta channel, so every six weeks we cut a release and we cut a beta.  The previous beta becomes a release.  

    What that means is that we can only build features that can be built in six weeks at a time, right?  We can't actually do a big bang 2.0 release because we only have six weeks between the last 1.x series and the 2.0.  

    The way that we decided to build the 2.0 feature set is, we're actually taking all the features in 2.0.  We're adding them to 1.x.  Basically, features are going to start dripping out over the next six months.  Then you'll be able to take advantage of them right away.  Then you'll start getting deprecation warnings for older APIs, so you can start fixing them up.  We're adding a tap to the Ember Inspector that will just give you the file and line number of the deprecation, where it came from.  

    You can basically fix those in your own time.  You'll have months to clear up all the deprecation.  Then, at some point when we do release the 2.0, I don't know if this has ever happened before.  I don't know if this is novel or not, but our 2.0 will not have new features.  It will only remove old features that we've deprecated.  

CHRIS:  Hmm.

TOM:    It's not a big bang rewrite.  It's just, we're slowly migrating the 1.x branch to 2.

CHRIS:  It's Snow Ember.

TOM:    Snow Ember - yeah, there you go.

DAVE:   [Laughter]

TOM:    I think those are the processes that we've put in place to make sure that we stay aligned.  Our goal is, from talking to developers, we know that no one will ever get buy in from their manager to rewrite their app.  The only way that you can do an upgrade is if it's possible to do in a single sprint.  We've tried to make sure that all of the changes that we intend to land, anything that would break, you can take -- even the large apps, one or two engineers should be able to complete that upgrade in a sprint. 

CHRIS:  Pretty neat.  There are literally processes in place.  When you brought it up at first, I thought of, you know, that little social network that was all the rage for a week, Ello or whatever, and they had said--

TOM:    Oh, yeah.

CHRIS:  --we're not going to have any advertising ever.  People were like, "Yeah, right."  Right?  Then the next week they're like, "No, but really.  Look.  We did legal action to make sure that if we ever change our ways," I don't know what it does.  It screws up the company somehow or makes it impossible to do.  

TOM:    Yeah.  Yeah, I think it's important to put that in place so that people can have that trust.

CHRIS:  Yeah, real trust.  Yeah.  Cool.  

TOM:    I think we have a track record.  That's the other thing I'll say is I think we have a track record of delivering on the stability.  I talked to Ember developers who have migrated from 1.2 all the way up to 1.9.  They're like, yeah, it took 30 minutes.  That's our goal.

CHRIS:  Very nice.  I think we can't get out of here without talking about some of the newest stuff going on in Ember, which is that there was a post on your site about the progressive enhancement kind of thing.  That's where I'm going with this.  Clearly you have some opinions on it, but this is from now a couple of months ago when it was kind of like, I think you were a little not pleased with the site that basically had somebody who turned off JavaScript in browsers.

TOM:    Oh, yeah, yeah.  

CHRIS:  Then just took a bunch of screenshots of it and be like, "Look, these sites don't care about progressive enhancement."  

TOM:    Yeah.

CHRIS:  You kind of say, "Look.  You can't just chop the head off of a Web browser and say--

TOM:    Yeah, that whole argument, to me, is just total horse pucky.  

DAVE:   [Laughter] Thanks for keeping it….

TOM:    That really gets my blood boiling.  The fact that, okay, the Web is a platform, right?  The Web is a platform, and there are basically three major pillars that prop it up.  There's HTML, there's CSS, and there's JavaScript.  For some reason, people decide that they're just going to disable JavaScript and decide that that is some arbitrary hoop that people have to jump through, like we need to disable this part of the platform that, by the way, no one actually does in practice.  The vast, vast, vast majority of your users are not going around disabling JavaScript.  Almost no one uses a browser that doesn't support JavaScript anymore.

CHRIS:  There are these classic phrases that are like, "JavaScript is always disabled before it's loaded."

TOM:    You just don't get to say -- like, you can't -- no one is going around and being like, "Oh, look.  If I get rid of these CSS 3 selectors, the site breaks."  No one is actually doing that.  No one is like, "Ugh, CSS."  You know what I mean?  No one is going around and being like, "Oh, well, this website should work without the video tag also."  It's like you can't. 

    Pick a date or pick support matrix, but you don't just get to say this entire piece of technology that drives the entire fricking Web, we need to be able to rip it out and basically make your websites brain dead, and they should continue to operate fully functionally.  It doesn't make sense.  It doesn't make sense that you get to say we're going to take away this piece and no one is doing that for HTML and CSS.  It's just ridiculous.  Thanks for getting me fired up this morning.

CHRIS:  No, that's good.  That's what I was hoping for.  But it's true.  It's unfortunate that that's become the moniker for progressive enhancement when that's not really quite what progressive enhancement is.  

TOM:    And you know what really grinds my gears is that I feel like a lot of the people who are advocates of progressive enhancement, they're all very smart people and their hearts are absolutely in the right place, but I can't help but feel like there's a little bit of condescension coming, emanating from these arguments because developers aren't stupid.  It's really condescending to say that developers are picking these JavaScript frameworks because, oh, they're just following the hype train.  Oh, it's just the hype and they're doing it just because they want to play with the new shiny.  I've heard that argument before, and I think it's disgusting.  

    People are trying to build awesome products.  They have very limited time.  They work at a startup.  They have a few months of runway.  They need to get an awesome product out that's going to get users quickly.  They're going to do whatever they need to do to get the best possible experience.  Agree with it or disagree with it, people are making decisions that they think are best to build the best products for their company.  I have nothing but respect for that.

    Now, if you want to tell these people, "Well, actually, you shouldn't make your product as good as it can be because someone might disable JavaScript," I think that's just completely disconnected from reality.  Your heart is in the right place, but it's just not pragmatic.  I believe in more of a real politics style of technology adoption, which is, if you want people to do something, make it so easy that they're like, "Of course I would do that."  

    All of the arguments that people make, I totally agree with.  I agree that if someone happens to be using a browser without JavaScript, like Curl or some kind of SEO crawler, we should absolutely support that case.  If someone is on a mobile device with high latency, I absolutely agree that they should see content before the JavaScript loads - 100% agree.  But do all of those things trump the experiences that you can build with JavaScript?  The marketplace has spoken and it says no.  

    Now, this is the role, I think, of frameworks of like Ember.  Frameworks like Ember should be the ones pushing the envelope and making it so that people can deliver those really great experiences to a wider range of an audience as possible, including people without JavaScript, including people on slow connections on mobile devices.  That's what we're doing.  

    My argument against progressive enhancement has always been that it hinged on developers taking on so much complexity that it slowed them down and it became totally untenable.  But what if we could have the framework do it for you?  If the framework can do it for you, then I think progressive enhancement, at least in the sense of having the initial view be rendered on the server, to me that just makes a ton of sense.  

Actually, that's what I've been working on the last week is we really want the ability for you to take your Ember app, deploy it, and be able to serve up the HTML first.  Then, once the JavaScript downloads, then it can take over.  Then you still get all the advantages of the fast navigation and so on.

CHRIS:  I think is the alignment.  This is where everybody agrees, right?  Of course, like the things that you were saying, you should get content before the JavaScript is loaded.  It should be SEO friendly.  It should be accessible in that kind of way that it's not required; JavaScript isn't required for absolutely everything that the website can do or that I would get a blank page in those situations.

TOM:    Yeah.  It's funny you mention SEO friendly because as soon as I Tweeted about doing server rendering of Ember, a Google engineer DM'd me on Twitter and said, "You know that the Google bot crawls JavaScript now, right?"  Actually, it's true.  We tested it, I think, like, three or four months ago, whenever it was that Google announced this.  They have a website where you can go on, and you can plug in an app.  Ember apps work, and Angular apps and React apps, work totally, totally fine with the Google crawler.  

CHRIS:  Right.

TOM:    That's less of an issue now.  

CHRIS:  They can say that they do, and there can be some proof here and there that you can look at, but is it always going to work as well as just some frickin' HTML on a page?  

TOM:    You know, my experience--

CHRIS:  No one will never be able to know, so it's an impossible argument to have.

TOM:    In my experience it has, but there are other tangential benefits, like being able to curl it, for example, and see the output in the terminal is really nice and helpful.  And scraping; I think the Web is built on this notion of scraping and remixing.  Definitely it's a loss to not have that.  There are just a ton of good reasons to support it.  Probably the biggest one is just speed.  

    I remember sitting down for beers with Dan Webb, who is an engineer at Twitter.  Where were we?  We were in Austin.  I don't remember if it was South by Southwest or TXJS, but he had just given a talk about how Twitter had moved away from client side rendering back to server side rendering.  

I really just thought he was being a bonehead.  It's good that we sat down and had beers because, once he explained all the constraints they had, the decision made a huge amount of sense.  We argued for a couple hours over beers.

But at the end of the day, I basically described this architecture that we're building now.  He said, "I think that if you guys build that, you've really got something there."  Actually, we have been designing Ember's architecture around this long-term goal for a long time.  It's just I've never personally had a need for it.  Actually, Bustle is sponsoring us, Yehuda and I, to work on this feature.  I think, especially for content sites, it's really important.  

When we started Ember, if you'd ask me, "Should I use Ember for something like Bustle or Vine?" to be honest with you, I would have said no.  It wasn't until I saw Bustle as a content site, just really freaking fast, that I was like, "Oh, I think there might be something here."

CHRIS:   Mm-hmm.  Something that we've talked about on the show a number of times: Heck yeah.  Wouldn't that be nice if there was kind of like one router for both sides of an app?  

TOM:    Yep.

CHRIS:  And that it kind of worked on the server side.  It worked on the front-end.  It's exciting to know that we talked with Jed Schmidt last week, and he kind of works on a site where that's the case.  Now you guys are being sponsored to work on it and have kind of -- yeah.  Anyway, we can link up the issue where Ember is kind of moving towards this and stuff.  I thought it would be interesting to ask you how that comes apart, working on open source stuff that's sponsored.  That's kind of a neat idea, isn't it?

TOM:    Yeah.  Well, we were very lucky that Bustle was generous enough to do this.  We do consulting, and we also have a product, so those are our two primary forms of revenue that we use to kind of basically subsidize our open source work.  But, in this case, being able to really focus and spend a couple months just really laser focused on this one feature that I think, if we get this right, I think it's going to be pretty transformative.  I think it's going to change the space a little bit.

CHRIS:  It has that same kind of idea, right?  If the page is rendered with the server, all the links are just links, right?  Jed was explaining how they do it is kind of like hopefully the JavaScript will kind of catch up as the page loads, and then it will just become an Ember app or whatever.  But if it doesn't, you click it.  You go to the next page, and it has another opportunity to catch up and do the stuff.  Is that how it's going to go?

TOM:    Yeah, I think that's the idea.  I do want to make it clear.  I think, like any technical discussion, there's always ambiguity in the terminology.  Like, what does reactive mean anymore?  You say the word reactive.  No one has any idea what that means. 

    I think it's the same thing with server rendered apps.  Some people have referred to them as isomorphic apps, which that term really rubs me the wrong way, but I guess I should just get used to it.  

Anyway, I think a lot of people think of server rendered apps as this magic bullet or this panacea.  I don't know what the right word is, but people think I'm going to write one app.  It's going to be the client.  It's going to be the server.  It's going to be my toaster.  It's going to be everything. 

    It just doesn't make any sense.  This is kind of the Meteor model.  In Meteor it's like, hey, guys, guess what?  If you write your app in JavaScript, you can run it on the server and the client.  It's like, whoa, yeah.  

    But then the high fades, you put down the joint, and you realize that these two apps have two wildly, wildly, wildly different responsibilities.  The app running on the server is responsible for authorization, for authentication, for rendering, like a json API, let's say.  The client has a responsibility of consuming that API and rendering a beautiful interface.  The idea that you can just jam these all into a single app that does everything is just completely backwards.  

    If you look at any Meteor app, the Meteor app is basically like two apps wrapped in a conditional that says if Meteor.isServer, do this.  Otherwise, if Meteor.isClient, run this other app.  That idea, I think, is absurd, and I want to make sure people don't think that they're going to be writing their server apps in Ember.  

    The point is, you write your client, and then your server basically just takes over the process of booting up the session, doing the initial render, and then basically transferring the state of that client over to the browser.  It's still, at the end of the day, just a client app.  All that's happening is that instead of the process starting on the client, it's starting on the server and then being handed off.  

CHRIS:  Lovely.  I don't know why I keep getting hung up on this idea, but is there truly a routes file that can work in both places?  I think of how large and kind of complicated our routes file is at CodePen.  It's like: I don't know.  If the client has to know about all possible routes on this app and the backend does too, it seems like a nightmare to keep.

TOM:    But they're not the same.

CHRIS:  They're just--

TOM:    They're not the same, right?  I think, in the right architecture, the server is purely serving up models.  If I want to go to visit the top users, if I would want to go to CSS-Tricks/topusers, there's not a top users endpoint on the backend.  On the backend, there's just a users endpoint that I can query or filter, right?  In my experience--

CHRIS:  It doesn't unless you want the server to have this URL that it knows about so that it can serve a fully, you know, like this SEO work that you're doing.  It needs to know about that URL still.

TOM:    Ah, so that part would be handled by the Ember server side rendering, right, basically any URL that the client would hit.  Basically what happens is we have a node app running on the production server.  It detects this request for /topusers.  

CHRIS:  Right.

TOM:    Then what it does is it boots up the Ember app.  Well, it already has it running in memory, but it routes the Ember app to this URL.  That Ember app goes and hits your API server, but presumably in the same data center or on the same machine even.  It goes and gets the data extremely quickly, renders out the HTML, and then returns it to the client.  Even though basically you have the Ember app running on the server, you have your API server running on the server, and they're talking to each other.  Then it's the Ember app that serves the HTML to the browser.  

CHRIS:  Even in this JavaScript off situation.  

TOM:    Even in the JavaScript off situation, so the Ember app, like when you download an Ember app, it's running in your browser, but it's just running JavaScript.  What we can do is essentially have that JavaScript run on the server instead of on the browser, at least to get started.

CHRIS:  Okay.  I see.  I see.  

TOM:    Everything is just links, as you said.

CHRIS:  Okay.  Pretty cool.  Let me do a sponsor quick.  We have lynda.com as a sponsor.  Go to that, lynda.com/shoptalk.  That's the URL you want to go to if you want to sign up for the ten-day free trial.  Otherwise you can't.  Otherwise, you go to sign up, and you've just got to cough up bucks, which of course you should because they have a huge library of learning material.  

To get your ten free days, to go www.lynda.com/shoptalk.  When you sign up, there's just an incredible amount of courses in here, thousands and thousands of courses.  Each of those courses is, like, 20 videos long and stuff. 

I know because I did one and have a course on here about building with WordPress.  It's a couple years old now, but I knew when I was creating it that it was going to age, so I decided to make it kind of conceptual on how you build WordPress themes, so it's still relevant in there, kind of starting with a blank PhotoShop canvas and breaking it into parts and building a kind of theme out of it.  That's on there, but there's so much stuff.  

You can browse their popular courses.  That's kind of a fun time to just look at what are the big ones that people care about a bunch.  Of course, there's a bunch of WordPress stuff.  There's a new course on here about brainstorming, and there's stuff about running a business.  There's stuff about accounting and productivity.  There's all this tangential stuff for the stuff that we talk about too.  Of course there's tons of tech stuff, tons of design stuff, tons of software stuff.  

I wonder if there's an Ember course in here yet?  I should look.  If there's not, I bet there's one coming really soon.  Oh, there's a whole bunch of them.

TOM:    You should do it.  

CHRIS:  Yeah, well, anyway, there's eight courses or more on Ember.

TOM:    I didn't know that.  That's great.  

CHRIS:  Yeah, pretty cool.  Yeah, a ten-day free trial: www.lynda.com/shoptalk.

DAVE:   L-y-n-d-a dot com.

CHRIS:  We were talking about open source and contribution.  Actually, we should do this one.  We actually have one from--God, what's his name here?--Remy -- I-E -- Sup-meister writes in, "'Sup."  That's what he--

TOM:    That's my friend Remy, I think, Remy Sharp.  

CHRIS:  'Sup, he wants to know.

DAVE:   What'sup, was the question.  

TOM:    I have a request for Remy.  

DAVE:   Good answer.

TOM:    Can we put some pressure on Remy right now?  Is that okay?  Can we put some pressure on Remy, some social pressure?

DAVE:   Social pressure is welcome on Shop Talk Show.

TOM:    Listen.  Listen, Remy.  

[Law & Order - SVU sound effect]

TOM:    We've got to get some ESX module support for JS Bin.  Got to have it.  Got to have some module action in there.  I want to write my ESX modules on JS Bin.  Make it happen.  I know it was my fault because he sent me an email asking me about my thoughts, and I never replied to it.

CHRIS:  He has Tracer, right?  We have Tracer on CodePen.  He has Tracer in there, but that doesn't do modules?

TOM:    Here's the problem.  That's not the problem.  Here's the problem.  The problem is you need separate logical files.  JS Bin has CSS and then HTML.  How about this?  How about some friendly competition between CodePen and JS Bin to see who can get ESX modules first?  

CHRIS:  You need a little file system is the idea?

TOM:    Yeah, you just need a way to say, instead of having just a single JavaScript global scope where you have a single file that gets evaluated, you need some way to say I'm going to create a module named this, and I'm going to create a module named that.  Then have some way of importing them.

CHRIS:  Yeah, we're pretty close, and I'm sure he is too.  There's even some database work that has to happen because we're hoping to get to the point where a pen or, in his case, a bin, but our case a pen has arbitrary files attached to it.  It's not just these three things that get smooshed together kind of thing.  It's kind of like you get your own little file system, and you can do whatever you want in there.  I cannot promise when we're going to get to that, but it's totally on our early next year list.  

TOM:    That would be amazing.  

CHRIS:  Cool.  Let's see.  Speaking of working on open source, Nick Herr writes in, "One of the things that I really enjoy about Ember is the community behind it and the support for getting started as a contributor.  How did you get started in open source software, and what's the best advice you have for encouraging others to get started?"  

Particularly, I think what Nick is referring to is tangential people, maybe not a core Ember contributor, or a core contributor, but maybe not on the JavaScript side like designers and writers, documentation kind of people.  You know what I mean?  How did you get started, and then how would somebody else get started, particularly in a tangential way?

TOM:    I was extremely lucky, and I think it would be hard to try to reproduce.  I don't actually know how it happened to me.  It seems like a dream, but I was working in an Apple store at a Genius Bar.  

CHRIS:  Really?  Did you get hit on a lot?  Was that an attractive…?

TOM:    No.  No, unfortunately not.  I'm not as suave as you might thing - at least at the time.  

[Laughter]

TOM:    I barely knew how to code.  I barely.  I kind of dabbled in it as a kid.  I tried to get my degree in CS, but the abstract math classes were way too hard.  I was like: I'm getting a much easier degree than this.  

    There I was, post college, working at the Genius Bar, just swapping out iPods all day.  Anyway, long story short, I had a buddy who'd gone up to Cupertino to work for retail.  He knew that I half knew how to program.  This is a thing that people knew.  I kind of knew how to write shell scripts or whatever.  

    He was like, hey, we've got this project we're working on and we need a programmer.  Unfortunately, we don't have official support for this, so do you want to come up?  We'll still pay you what you're making at the Apple store--

[Laughter]

TOM:    --but you're going to be a programmer for us for however long it takes to ship this project.  I was like, you know, I'm so ready to get out of retail.  Man, whatever it takes; whatever it takes.  

    I got up there, and they're like, okay, we're building this SproutCore app.  We're building a SproutCore app, and it's got an API that it talks to.  The API is in Rails.  I had read the Rails book, and I had played around with it.  

I was like, oh, well; let me do that because I don't know.  The front end of SproutCore is JavaScript.  I'm like, well, I don't know JavaScript, and it doesn't seem like a language I want to learn.  

We finished the API portion.  This is the thing about client side JavaScript, by the way, is that your server becomes dramatically simpler, so much simpler and smaller.  The scope just reduces dramatically.  

We finished the Rails API in a week or two.  Then they're like, okay; well, the SproutCore app isn't even booting yet because no one knows JavaScript, so we're putting you on that.  I was like, well, I don't know JavaScript at all.  They were like: all right, well, figure it out.  

[Laughter]

TOM:    I remember walking to the Barnes & Noble there in Campbell, California, at the Prune Yard.  I remember walking to the Barnes & Noble and buying JavaScript: The Definitive Guide and The Good Parts by Crock.  I'm just holding up in my hotel room, just reading this book, and stepping through the JavaScript app line-by-line assuming at any moment I would be fired.  

CHRIS:  You're going to lose your $7.50 an hour, man.

TOM:    I was like that.  I was like: this is going to be a disaster.  I'm going to have to go back to fixing entitled people's iPhones.  But by the grace of deity, I survived, and I somehow kind of struggled through JavaScript. 

    The next thing I know -- this is the crazy thing.  The next thing I know, Mobile Me, now iCloud, was using SproutCore for all their front-end apps.  I got to know the people maintaining it, and here's the thing.  This was like 2009 or 2010.  At the time, there was no one-there was no one who knew how to write JavaScript like an app.  Right?  Everyone was in this mindset of JavaScript is something that you sprinkle on top of server rendered stuff.  It was like mind bending.  People just could not get in the mindset of client side JavaScript. 

Even today it's still hard, but 2010, man, no one could think that way.  They just were too enmeshed in it.  But because I was so new, and I had started writing JavaScript from this perspective, man, I was so lucky to be there at that time, and so they hired me to maintain SproutCore.  I just went, "Ha-ha-ha-ha."  I had just learned JavaScript, like, four months before, and now Apple was hiring me to help them maintain their JavaScript framework.  It was a trip, man.  It was a total trip.

CHRIS:  Hmm.  I don't even know anything about this SproutCore.  It's still a thing, apparently.

TOM:    Yeah - not really, but it hobbles along.  Then, by some miracle, Yehuda finished Rails 3, and he decided that he wanted to move onto the next thing.  He got this itch that he thought that the next big thing was going to be JavaScript on the client side because that's where you can deliver really great interactions.  I think he knew the set of interactions you can deliver with server rendered stuff that there's a finite limit.  

    He started getting involved in client side JavaScript, and he joined this company called Strobe with the guy who started SproutCore, Charles Jolley.  He basically recruited me.  He's like: I want you to--  We had worked together a little bit designing APIs for SproutCore, and so he basically poached me from Apple to go work on open source at this company.  That's how the two of us got started together.

    Here I was.  I had been programming for a year, maybe, if that.  I get hired into this job at Strobe.  Literally, for the next, well, basically until today, every day of my life I've gone in and pair programmed with Yehuda.

CHRIS:  That's pretty cool.

TOM:    Yeah, it's a trip, man.  That's how I got started.  

CHRIS:  Then what if somebody wanted to start now though?  I have similarly good things that have happened to me throughout my life.

TOM:    Yeah.

CHRIS:  You almost feel bad about it sometimes.

TOM:    Yeah.  Oh, I feel terrible.  Yeah, I feel like the luckiest guy in the world.  No doubt. 

CHRIS:  Yeah.  Around these parts, we often tell people just work on websites.  Just build websites because it's kind of like you'll get there.

TOM:    Yeah.

CHRIS:  Just doing the work is the kind of thing.

TOM:    Yeah.

CHRIS:  But I don't know.  Do we have any better advice?

TOM:    Let me say this for people that want to contribute is it can feel really demoralizing to work really hard on, like, a pull request.  You submit it, and it gets rejected, let's say.  Maybe it's rejected with a terse comment.  

    Now we try really hard not to do this, but in a big project, inevitably someone is having a bad day or they're running short on time.  Inevitably, you don't treat people with as much care as you really would like to in a perfect world.  The thing that would say to people who want to contribute to open source is that, by far, the most important metric for us is consistency.  

There are a lot of really talented people who will submit really awesome pull requests, but if we merge those pull requests, we are now responsible for that code that we didn't write.  We are very gun-shy about adding new features or getting things in.  There's just a lot of signal to noise.  There are a lot of bad pull requests.  There are a lot of people who act in bad faith.  They just want to leach your free time to suit their ends, and they don't want to contribute back.  

    Any open source maintainer, over time, becomes very protective of their time and their resources when the signal to noise ratio isn't great.  By far, the best thing that you can do to become a contributor is to be consistent.  It doesn't have to be code.  It can be, if you have a design bent and you want to contribute design stuff.  Documentation is so amazing, but the problem with documentation is, if there are 1,000 different people writing it at different levels of skill, that voice in the written documentation sounds really disjointed.   

If you have spare time, like, it's more important for us to have 5 hours of your time every week than 40 hours of your time for one week, or 80 for two weeks, right?  The consistency in the long-term is by far the most important thing.  We want to know that you're going to be around to help us maintain it, to help explain it to other people.  If you're writing documentation, that you'll be there to take the pull requests that are good, but maybe the person is not a native English speaker, and help them improve it.  That's by far the most important thing.  

Just the name recognition - if I see that you've been around for a long time, I'm going to trust you.  Yehuda and I are both extremely aggressive about delegating before we feel comfortable delegating.  We're like, okay, you add this new repo.  It's still kind of in the baby stages, but we're going to give you a commit bit on it because you've been around for a long time and we trust you.  That trust really requires consistently, I think.  That's the biggest thing - just be around.

CHRIS:  Yeah.

TOM:    Maybe that's obvious, but consistency is the most important thing.

CHRIS:  Pretty good.  

DAVE:   That's like my toughest problem managing open source.  Somebody has an idea.  They're like, "Oh, this doesn't do the thing I want it to do," so they spend all weekend rage coding on it.  They're like, "Here.  I fixed it for you."  You're like, whoa!  Hey!  What?  Okay.  Let's talk.

TOM:    Yep.

DAVE:   That's how it always feels to me.  It's like somebody just shows up at your house.  I mowed your lawn.  You're like, whoa!  Hey!  What?

TOM:    We actually have an RFC process, which you can check out: GitHub.com/Emberjs/rfcs.  That's kind of a process that we have for incorporating feedback just because we follow semantic versioning.  We're post 1.0.  We can't just be adding a ton of API willy-nilly.  We really do need to think about it, and so we introduced a more formalized process for that that we actually borrowed from the Rust programming language.

CHRIS:  I've got to say, Dave, you're very good at it.

DAVE:   That's nice, so like a full request.

CHRIS:  Committing.

DAVE:   Well, it's not my full-time job, so I'm attributing to the consistency issue as well.  It's like Thanksgiving and Christmas, I fix open source.  

CHRIS:  Yeah, but you leave the things open.  Everybody gets an answer.  You're good at being nice, but saying no a lot.  And you have an idea for what 2.0 is going to look like on a lot of your things, and so you're like, okay; maybe, but that's a 2.0 thing.  

TOM:    Yeah.

CHRIS:  That's good.  

TOM:    Another big thing that people can do that I think is maybe surprising is just writing blog posts helps so much.  The barrier to entry for your own personal blog is so much lower than getting it into the official documentation because the official documentation has to be maintained forever.  But it's so helpful and so gratifying as an open source maintainer to see people pumping out really great content about your open source library.  

It doesn't have to be maintained forever, but it's like, hey, I was trying to solve this problem and here's how I did it.  That is so valuable, and a lot of times actually more valuable than the official docs because, let's be honest, it takes a certain special kind of person to sit down and pour through the docs from front to back.  The vast majority of developers, and I'll include myself in this bucket, just Google the error messages that they're getting.

CHRIS:  Right, and there's no reason a link to that blog post can't be in the official docs with the right tone introducing the blog post.

TOM:    Right, exactly, yeah.  By far the best thing that you can do, and it also just helps to get a name for yourself.

CHRIS:  Alrighty then.  

DAVE:   Cool.  All right, well, hey, we should probably wrap it up.  Tom, thank you so much for coming on the show today.  We really appreciate it.  If people aren't following you or giving you money, how can they do that?  Then what's one big thing you'd like to plug before you go?

TOM:    Sure.  Follow me on Twitter.  I'm the big red phone booth: Tom Dale.  If you would like to give me money, first, be a Rails developer.  Second, be like, "Man, I wish my app was a little bit faster," because we have an app or a service called Skylight, Skylight.io, that will tell you how your Rails app is running and help you make it a lot faster.  

DAVE:   Cool.

CHRIS:  Yeah.  Don't kill me for this, but it's kind of like New Relic for Rails, right, or no?

TOM:    Well, yeah, kind of.  New Relic is just great for alerting.  It monitors a lot of platforms like Node, Java, PHP, Rails, the whole bit.  We are focused just on Rails, and so if you're a Rails developer, we give you a far, far better experience because we're focused on just that platform.

CHRIS:  Sweet.  

TOM:    Our UI is really freakin' killer.  You can sign up for a free 30-day trial.  You should try it out just to see how gorgeous the UI is.  I'm pretty proud of it.

CHRIS:  Nice.  I might just do that.  We have a Rails app, you know.

DAVE:   Yehuda is involved in this?

TOM:    Yes, Yehuda.

DAVE:   That guy knows nothing about Rails.

[Laughter]

TOM:    Yeah, it's actually pretty cool.  He built a product using all of these APIs that he and Carl, who is my other cofounder who worked on Rails, put in Rails 3.  It's like one of these long games where they put the APIs in, like, two or three years ago, and now we're building a product on top of them.

DAVE:   Ah, the old long con.

TOM:    Yep, the long con or the long troll.  Yeah, one thing that we just did is pretty amazing.  Not to get too much off on a tangent, but we wrote our agent in Rust, which is this really cool, new programming language coming out of Mozilla.  It's really powerful.  You should have someone on to talk about that.  

    Because of that, we can do really low level stuff, so we just rolled out a new feature that actually measures how many memory allocations are happening in production.  It's basically like having a memory profiler, but running in production 24 hours a day.  You can log in at any time and see what's allocating what amount of memory.  It's really awesome.

CHRIS:  It's priced right too.  You can be in the tens of millions of requests here for a couple hundred bucks. 

TOM:    Yeah.  The vast majority of our customers were significantly less expensive than New Relic.  

CHRIS:  Yeah.  Right on. 

DAVE:   Well, cool.

CHRIS:  Thanks for coming on, Tom.  

TOM:    Thank you, guys, so much.

DAVE:   Thanks, everyone, for coming out and listening and coming into the live chat.  We really appreciate it.  Thank you for tuning in live.  This is the last episode of Season 3 of the Shop Talk Show.  We will be back next year in January 2015 for Season 4 of the Shop Talk Show, which may feature a new website, but I don't know.  I may just get lazy over the holidays.  

CHRIS:  We've got to do it because there's the job board on it now.  It's kind of got to get done.  I'll help.

DAVE:   Yeah.  Yeah, you've got to go to ShopTalkShow.com/jobs.  We'll work on prettying it up, and we'll see how far we can get there.  Hopefully we'll have all that, and it should be good.  Thanks, everyone.  

    I'm going to give you fair warning.  We're going to have to migrate all of our feeds and everything, so we might be doing some really gutty underpinnings of the Shop Talk Show in how we do the feed and everything like that.  Yeah, basically Shop Talk is too big, and our MP3 host was like, hey, you have to move.  

Now we have to move, but thanks, everyone, for listening because that's an awesome problem to have.  We're going to be doing that, so if 900 new episodes show up in your podcatcher, I'm super sorry.  On that note, rate us up in your podcatcher of choice.  We really appreciate it.  

Chris, do you have anything else for us?

CHRIS:  Just - ShopTalkShop.com.