02:28 - Eric Schoffstall Introduction

02:59 - shasta

07:20 - Getting Started

08:20 - Solidifying on Best Practices

10:37 - Made to Work Together vs Made to be Neatly Modular

11:19 - shasta and redux

12:01 - shasta Ideals

15:07 - Making Choices

17:35 - redux-thunk, redux-saga

19:01 - Lessons Learned from gulp.js

23:55 - redux-router

25:20 - React-Specific vs Agnostic

27:35 - Experimentation with shasta

29:50 - Relay and GraphQL Conflict

31:31 - Swapability

35:30 - The Future of front-end development in JavaScript; Where shasta fits in

Picks

Victor Savkin: Managing State in Angular 2 Applications (Joe)
 Lazer Team (Joe)
Big Black Delta (Jamison)
Learning to Use Google Analytics More Effectively at CodePen (Jamison)
Thing Explainer: Complicated Stuff in Simple Words by Randall Munroe (Dave)
Soft Skills Engineering Podcast (Dave)
RevolutionConf 2016 (Aimee)
[Frontend Masters] Functional-Lite JavaScript (Aimee)
Lush Cosmetics (Aimee)
horizon (Eric)
Shannon and the Clams - Rip Van Winkle (Eric)
shasta (Eric)

Special Guest: Eric Schoffstall.

 
[This episode is sponsored by Frontend Masters. They have a terrific lineup of live courses you can attend either online or in person. They also have a terrific backlog of courses you can watch including JavaScript the Good Parts, Build Web Applications with Node.js, AngularJS In-Depth, and Advanced JavaScript. You can go check them out at FrontEndMasters.com.]

Hey everybody and welcome to episode 205 of the JavaScript Jabber Show. This week on our panel we have Aimee Knight.

Hello.

Dave Smith.

Hey, everyone.

Jamison Dance.

Hi, friends.

Joe Eames.

Hey everybody.

I'm Charles Max Wood from DevChat.tv. And this week we have a special guest this week and that is Eric, I know I'm going to say this wrong. Schoffstall.

There you go. Right, Schoffstall, yeah. What's up everybody?

Hey, Eric.

Hey, how's it going?

Do you want to introduce yourself?

Yeah. I'm Eric. I usually go by contra. Everybody calls me that. And yeah, I'm here to talk about some React and Redux stuff that I've been working on.

Before we jump into that, can I ask if contra is a throwback to the old 80s console game?

No. I get asked that all the time. [Chuckles] No.

It's not.

If I'm not mistaken, that was the original up/down/left/right yada-yada code, right?

Yeah, it was.

Yeah. Okay, well that's cool, too.

So, we brought you on to talk about Shasta which looks like it's still a work in progress.

Yeah, it's coming along. It's kind of a big undertaking. There are a lot of projects under that umbrella of Shasta. So, I had Dan Abramov over at my house probably like a month ago and I gave him a sneak peek. And then he totally went on Twitter and just told the whole [inaudible].

I was like, damn it. So, I had all these people going to the website and then [inaudible]…

Oh yeah, they're looking for docs. It's like basically right now it just says go away. [Chuckles]

It's like this is a work in progress. There are no docs. It's not published. Don't touch it. And yeah, it's because it's like, there are just so many pieces involved in it that it's taking a little bit to get everything documented and tested and make sure that everything was done the right way. But I'd say it's probably a week or two out from having a full release of everything.

So, there's a chance that [inaudible]

Well, that's good because our release cycle is a week or two. So…

Yeah, so there's a good chance that if you're listening to this, Shasta is ready.

Oh, [inaudible].

So, can you just say what it is though? I still don't know [inaudible].

No, that's not important. Let's just focus on the hype.

Well, yeah. If you don't know what it does, then you…

It's a brand of soda.

You don't know what it can't do also.

Shasta does, it's like Zombocom.

[Chuckles] Yeah.

Yes. So, I guess I'll start from the beginning. So, we were doing React stuff. Redux came out. Redux is awesome. So, we started building Redux applications at one of my companies. And we found it to be extremely painful to get started. There's a lot of plumbing up of different modules and making sure that data goes to the right place and you have to go research all the best practices. And the Redux community kind of has a set of opinions just in the community that you're supposed to follow. And it's mostly by going and looking at Dan Abramov's Twitter account or looking at the readmes of a bunch of different modules. So, what we decided to do was, hey, what if we just took all of these best practices that the community has already agreed on and kind of formulate it into a module that enforces those best practices? And then make it easy for people to wire everything together in a way that abides by those practices.

So, out of that this idea of Shasta was born. So, it consists of some frontend stuff, some backend stuff for creating APIs, and a bunch of stuff in between that ties it all together.

So, effectively what I'm understanding then is you take React and Redux and you put some opinions around it and say, “We're going to make it really easy for you to do these certain things if you meet the assumptions that we have.”

Yeah. We took Redux, React, RethinkDB, and some other stuff, wrapped it altogether into one thing, and then we have a whole ecosystem of other tools that you can plug into it really easy. The whole goal was let's take all of this cool shit and make it so that you can use everything together really easily without having to go read the docs on eight different modules and figure out how to wire everything up.

Were you responding in part at least to the concept of JavaScript tool fatigue when you conceived of this project?

That article came out a little bit after. I think there was like kind of a good point or two in that article. I disagree with it on a lot of levels. Yeah, I wouldn't say it's a response. But it definitely helped reinforce I guess what we felt like the community was saying.

Is what you're doing just you said, like extracting all the best practices, or is it actually abstracting over some of the things that you would have to implement by hand?

A little bit of both. So for example, one of the pieces in Shasta is called Tahoe. And it's like a complete data access layer for Redux. So, you don't have to use Tahoe with Shasta. You could use it in any Redux application. And it abstracts away the whole process of getting data from an external API, denormalizing it, storing it, caching, optimistic updates, and all of that stuff. So, there are a number of pieces that are all standalone. And then all of those together are what makes Shasta.

So, can you give us some idea of how somebody gets started using Shasta? Because I don't know, I'm having trouble conceptualizing exactly what you're talking about.

Yeah.

So, if I wanted to build apps the way you want me to build apps, what do I do? Do I npm install shasta and then roll that way? Or do I have to pull it in some other way and then run some other commands to get started? What does that look like? What is that process?

Yeah, so we're working on a command line tool that will be responsible for scaffolding out new applications and helping you manage existing applications. But for now I would say the easiest way to get started is GitHub.com/shastajs/boilerplate. And it's just like a stock Webpack, Rethink, realtime API with Rethink and Shasta on the frontend stack.

Is that using Express for the server, too?

Yeah, we're using Express right now. The server stuff is agnostic though. You could use it with anything.

Sure. So, I want to talk about this idea of solidifying on best practices. It seems like one thing in the React community that they have done a little differently is almost avoiding that. And to a fault that's something… it causes a lot of confusion like you said. And there are some other communities like Ember specifically where they really value just from the very beginning having one right way to do things that the whole framework is built around. Do you see this as kind of trying to move React a little bit more towards that philosophy where there are strong conventions and strong opinions? Or is this just like, “Hey, here's a cool way to build apps if you want to”?

I think it's definitely moving the needle a little farther towards Ember but not completely. I think that there's a nice middle ground between having to install a hundred modules to get a basic router working and having to buy into a full stack like Ember's system. So yeah, I would say we're trying to focus on being a set of good opinions in this ecosystem that seemingly has no opinions about anything. Because yeah, there is a lot of frustration of people who just want to, I don't know, build stuff. And right now it's a lot more difficult than I feel like it needs to be.

Sure.

So, you recently re-tweeted something like pretty much you pick too much magic or too much boilerplate. So, is that pretty much what you're doing, trying to find a happy medium there?

Yeah. I think we're trying to pick a point where you don't have to do the boilerplate if you don't want to but there are enough escape hatches where you can do your own thing if you need to. So, that was one of the things where it's like we didn't go and remake a whole thing from the ground up and do our own Redux or anything. So, it's all just normal Redux. If you want to use any piece of Shasta in a Redux application you can totally go do that. You can use Redux stuff in your Shasta application. So, it's not like you have to buy into it or anything. And then every piece is just wrappers around other modules. So, if you want to use those individually to do something a different way then you can do that as well.

One thing that I see a lot is some systems they work really well because all the parts of it are made to work together. But if you take any one of its parts it's hard to make it work on its own to do its job in an application that doesn't include the other pieces. How do you find the happy medium between made to work together and made to be neatly modular so that it can work nicely out in the real world without any support?

Yeah, that's a good question. So for our company, we do everything with Redux, React, and Shasta on top of it. But we have people who work at other companies who are doing stuff with Shasta that we're not. So that's like… for example we have people that are using it in Angular applications with Redux, taking different bits of Shasta and using it in those kinds of environments. So, I think that by encouraging people to do stuff like that and having people test it out, it's like if you break something or tightly couple it too much to a certain way of thinking then people will complain about it.

So, you just said something that surprised me which was Angular and Redux in the same sentence. And then on top of that, Shasta in and Angular/Redux application. So, why would anyone want to use Shasta to wrap Redux if you're not going all in? What's the benefit there for them?

Oh, so I said pieces of Shasta.

Sure, sure. Even still, like to me Redux is pretty standalone, seemingly standalone. Maybe it's not.

Can you explain how that goes down?

Yeah. So, the specific piece I was talking about was the server stuff and the frontend stuff that ties into that server stuff. So, all of the data access through that module called Tahoe that I mentioned earlier.

Ah, okay. They're using Tahoe with Redux and Angular.

Yeah.

Okay. That makes sense.

So, what are some of the opinions that you're pushing on people with Shasta? And what do they clarify with just a regular Redux app?

Yeah, so I think that the top three overarching ideals of the whole thing, and there's a lot of lowerlevel opinions and you can read all of them if you go to Shasta.tools there's a whole document just called 'Opinions' just to spell them out for people before you even dive into it. But the three main ones are everything should use Immutable.js, everything should work easily and be simple to understand, and you should spend time building applications rather than wiring a bunch of modules together.

Do you want to talk about those in a little more depth?

Sure. So yeah, the first one, the Immutable.js, all of these opinions came out of us building applications with Redux and React and just figuring out what the best practices were. So, we noticed a lot of people using Immutable.js in the reducer. So we were like, yeah, we'll give it a shot. And it's actually really nice. [Chuckles] So, when you're using ES 6 arrow functions for your reducers, you get the implicit returns which is the little one-liners. So, you can do these one-line reducers with Immutable.js because every state transformation you do an immutable returns the new object.

So, how people are doing reducers without immutable is either using the React immutable object update thing which is a lot more code than it needs to be or they're doing it by hand which is like, “Okay, I got in a state object. I'm cloning that object, I'm tacking some new stuff onto it, and then I'm returning the new object.” So, we felt that that was just kind of clunky. So, Immutable.js gives us that. They have a bunch of really nice iterator sugar for iterating over maps. And they have ordered lists and I don't know. They just provide a lot of really good data structures and we felt like it was a natural fit for Redux reducers.

So, I'm…

So…

I'm having a little bit of trouble again visualizing why you would want Immutable where if you make a state change you get a new object back. Why is that so important or so powerful with Redux?

With reducers?

Yeah, so in Redux you have to. Your state transformations have to be immutable. And this goes into, makes the whole time machine thing work that you can roll back changes to a…

Okay, gotcha.

Previous state of your application.

And so, Immutable.js just makes a lot of that work automatic?

Yeah. It makes it super easy. So yeah, in Shasta our main opinion is that your whole state object for your application should be Immutable.js, top to bottom.

Right. Although it is good to point out that time travel is just a side benefit, right? It's not the point of having immutable data.

Yeah. It's just one of the reasons why it's a good idea.

And plenty of applications exist out there that don't need time travel but still can benefit from using immutable data. Well, they have to use immutable data when they're doing Redux. But Redux is based on the principles of having immutable state changes.

Mmhmm.

So, my experience with setting up a Redux application is that you can start but really quickly you have to make a lot of choices. [Mostly], the sample applications don't even do Ajax, right? The just have actions and stores, or actions and reducers. And that's great. But then you're like, “Oh, what if I need to do an Ajax request?” And suddenly you have to now make a choice. Like okay, I have to bring in middleware. Well, which middleware? What middleware is hot this week? So, Shasta it looks like is actually making some of those choices for you. Can you walk through some of the choices and middleware and some of the plugins and other things? Actually, not the plugins, but the default stuff that Shasta is providing out of the box so that you don't have to make some of those choices.

Yeah, so a couple of the choices are reducer and action naming. So, we found it difficult in standard Redux applications. So, let's say I'm emitting an action 'create to do'. Where the code that's required for handling that is was kind of confusing. So, there wasn't really any opinion on how to structure your code in that way or how to name your reducers. It's like well, if you want to use hyphens that's cool. If you want to use underscores, camel case, do whatever you want. So, we made the opinion of using namespacing. So, in our case it would be instead of create to do in camel case it'd be to-dos dot create you would fire off as an action. And that's neatly mapped to a to-dos reducer file which has a create reducer. Or you would have a to-dos action file that has a create action. So, we felt like that mapping was a lot cleaner. So, that's one of the opinions. Let's see. So, we have some default middleware. The dev tools stuff, if you have the dev tools Chrome extension installed we just wire it up for you. So, that was one of the things I felt like was…

Nice.

Is one of the boilerplate things that never really made a lot of sense to me. It was like, oh well, if you want to have the dev tools Chrome extension that's cool. But also, here's a bunch of code if you want to include the dev tools extension in your app and here's how you detect what to wire up. And it's just one of those things in your store file that got really clunky. So, we just say if they have the dev tools extension, plug it into the store. Otherwise, don't. And then or async stuff we have the Thunk middleware included by default. And then we're looking into doing stuff with redux-saga and possibly including that. But I haven't done enough research on that to figure out if it's a good idea or not.

Can you briefly go into what those two are for people who haven't done a lot of Redux yet?

So, Redux Thunk is… so, you fire off an action and it goes to the store. And the store basically is responsible for orchestrating a bunch of stuff. Your reducer gets called. A state transformation happens. But if you need to do asynchronous stuff, you need a kind of middleware thing. So, Redux Thunk is a piece of middleware that is responsible for resolving asynchronous actions. So, if I say, “Hey, I need to call some API,” I emit an action that says, “Call this API,” the middleware says, “Oh, this is an asynchronous thing. Run this,” pass this callback basically into the action, and then when it calls that then we go to the reducer with the data that came back. So, we found that that was used so commonly that we just include that by default. So, supporting asynchronous action resolution was one of the things that is included in your store middleware by default.

Okay. That makes sense. What was the second one you mentioned? That was Redux Thunk.

What was the other one?

The other one was redux-saga which is kind of the same thing but with ES 6 async stuff like yield and…

Okay.

Yeah, I haven't… it has a couple of other things in it. I don't know enough about it to go about it with any confidence. But everybody seems to be pretty hyped on it so I probably should look into that.

That makes sense though. Thanks.

So, I have a wild change of subject. You're also the main authority of Gulp, right? Which is… it has some interesting parallels with this project where it was a space that… there were some existing solutions. There was some maybe frustration with those solutions and then you came in and built a tool that took off a lot. Can you talk about some things that you've learned from Gulp maybe in terms of just running an open source project or in terms of solving a problem like this and how you're using them in Shasta?

Yeah, that's a great question. So yeah, stuff I've learned from Gulp and I would say that the origin story of Gulp, the origin story of Shasta, and the origins of a lot of the stuff of I build mainly stems from being frustrated with other stuff. So yeah, I would say…

That's called frustration-driven development. That's cool.

Yeah, that's awesome.

FDD.

I just get frustrated and I'm like, “Well, too bad I don't know how to program [inaudible] about this.”

[Chuckles] I have frustration-driven depression. It's different, but you know.

Yeah. So, things I've learned in open source. So yeah, I think I did a JS Jabber about Gulp like, what was that? Like two years ago?

Yeah, it was a while ago.

That was a long time ago. Two years ago. Man, I was 20 years old.

It's like the value of a logo is what made [inaudible].

That's an awesome story.

That is really funny.

So, yeah I think when I gave the talk I had a graph. It was just flat and then there's a little arrow. It's like, logo made, and then it just…

So, I would honestly say in open source my number one learning is marketing.

Make a logo.

Make a logo. I think it's more about showing that you're willing to make an effort. Like if you just throw up code and you're like, “Ah, I don't have time to make this nice,” people are going to be like, “Well…” It's like a subconscious thing. Like if this person didn't have time to make a nice thing around this project, they're probably not going to maintain it.

Yeah.

They're not going to be [inaudible] at responding to issues. So, I think it's like giving a signal to people like, “Hey, I actually give a shit about this thing. I made a logo. I made a nice website for it. I'm serious about it,” versus, “This is just some code I'm not planning on maintaining.”

So, for Shasta did you try a new strategy where you have Dan Abromov leak your project before it's ready? [Laughter]

No. He, oh man I specifically told him, “Do not tell anyone about this.”

And he's like, “Okay.” And then he just totally goes and tweets about it. [Laughter]

Dan, I hope you're listening. [Laughs]

He can't help himself.

Yeah, it's okay.

Was that part of… it looked like TJ Hollo-, I can never pronounce his name, Holowaychuk. He was talking about trying to setup a Redux project and just being a little bit frustrated. Was that part of that conversation or something else?

Dan leaked it so it was a part of that conversation. And then there was a tweet a long time ago that was like, Dan just tweeted a link to the Shasta website and was like, “Everybody check this out.” And on the website at the time there was nothing. It was completely empty. There wasn't… so right now it's just a bunch of logos and it says coming soon. But back then it's just coming soon. There wasn't even anything on it. So yeah, it was kind of confusing [chuckles].

Because oddly enough I was trying to find information about it to prep for this week and when I was googling around that tweet came up. And…

Oh, that's [inaudible].

pretty much all I could find was what was on GitHub. And that tweet…

Yeah. Well, I got to say I got really excited when I heard about what Shasta is, because I feel like this is the piece that's missing in the React ecosystem right now. You have to bolt so much stuff together to build a React or a Redux app that someone to bring it all together and provide a uniform way to do it and abstract away some… actually, you mentioned the term boilerplate earlier but you're really helping reduce boilerplate code in our projects, right? That's the goal.

Yeah. So, using router for example, I don't know. Have any of you set up a router with redux-router? [Inaudible]

Yeah. I just did a couple of days ago. [Inaudible]

It's like three separate… three separate modules and all of this code. And you don't really know why you have to put the code there. It's just you look at the readme and it's like, yeah you just got to paste this code in and wire this up this way and do this and this. And if you don't, nothing works. So, it's like, “Okay well why are we pasting code from readmes with no explanation?” So, for Shasta we just wrapped all that code in shasta-router. And then you can drop it into your store with one line of code. So, you just require shasta-router and then you give it to your store. And then your store wires everything up.

So, one of the best ways to reduce boilerplate that Shasta offers is this notion of a plugin. But it's not like some custom fancy thing. It's like you can pass an object in that has any combination of actions, reducers, middleware, store enhancers, or store hooks, and it will wire everything up for you. So, all of these modules that are like shasta-router or shasta-logger or any other Redux application or Redux community module that exports in that pattern can be dropped in with one line of code versus manually having to go wire all that stuff up.

How many of the pieces of Shasta are React-specific and how many of them are agnostic?

Yeah. So, I think right now there are two things that are React-specific but those two things are super lightweight. So, there's the Shasta component and there's a Shasta data-view which is just a really simple way to handle asynchronous loading states. So, if you find yourself in your render function doing something, a ternary that's basically like if it's loading show a loader, if it's not loading show the data-view, if it error-ed then show an error view, so we just abstracted that into a little 10-line component that works with Redux really well. So, it's not even Shasta-specific. You could use it with Redux as well. And I think we're going to go ahead and rename a bunch of stuff to make that a little clearer so that it's Redux data-view instead of Shasta data-view.

Gotcha. So, how many of the pieces are Shasta-specific? [Chuckles]

All of the pieces.

[None of it,] really. It's all, like you can use every piece standalone if you want. I think of Shasta as more of an umbrella over an ecosystem. And it's like, “Hey, everything that has the Shasta name on it you know is going to work really well with every other thing that has the Shasta name on it.” And we give a shit about it.

I'm imagining this more like, have you seen the previews for the movie Lazer Team?

No.

You just [out-nerded] everyone on the show, Joe.

I just what?

[Out-nerded] everyone.

[Laughs] Don't nobody else watch those previews? Come on. It's this, I don't know when it's coming out. It looks like a total B movie but it looks hilarious. But there's this super suit that the government invents and the guy crashes or something and five different guys each end up wearing one piece of the suit somehow. And then they become the Lazer… so, one guy has the glove. [Laughs] And so, he can shoot the other guy's, like the helmet or something. I'm just imagining. It's like there are all these awesome pieces and you can use them however you want.

That's like a [inaudible] to a bad movie because maybe it's a great movie.

I guess you could say it's like the Lazer Team movie. [Laughter]

So, when are you going to rename your project? [Laughs]

The Lazer Team. [Oh god.]

So, you talked a little bit about people using Shasta potentially with Angular. I know that Redux is getting a lot of experimentation with Angular. Redux is getting experimentation with everybody else. Have you heard of anybody or any other of the projects, have you heard of any other projects experimenting with Shasta?

Right now just some people doing it with Angular. So, yeah you can use the Shasta, server stuff is really nice. You can use that. So, the Shasta server stuff is like dead simple APIs on top of RethinkDB. And then we're using event source for doing real-time push from the server. So, that's a piece that you can use with anything. That has no opinion about what your frontend stack looks like. And then yeah, there's Tahoe which works with anything that uses Redux. Any of the Shasta Redux modules will work with anything that uses Redux. But so far it's just Angular and React. If anybody wants to experiment with something else, I'm totally open to it because the goal isn't to lock anybody into React. If you want to use Shasta with Mercury or Angular or whatever else you're building stuff with like Vue.js, there's a bunch of stuff, definitely talk to me about it because I'm super interested in that.

It sounds like there are a few pieces that even aren't necessarily Redux-specific, right?

Yeah.

So, it's not even you have to be necessarily doing Redux. Although it would be awesome to see like Backbone, Redux, Shasta.

So yeah, there's a whole server-side piece of it with the APIs. And then there are pieces that wire that server-side part. So one of the things, my favorite thing probably, is the API stuff is something we've really put a focus on. And what we actually do, so on the server-side we go scaffold out all your REST endpoints from some modules that you defined. And we export that meta-information to the frontend using Webpack. And then we use that to programmatically generate actions on the frontend for accessing those APIs using Tahoe. So, we have that. There's an example of that in the boilerplate. But what it actually ends up looking like is you define an endpoint on the server and you now have a function for retrieving that data on the frontend that works whether you're just fetching a set of data or a real-time change feed of updates to that data.

That sounds really cool.

Mm. Now, I've heard rumors that Facebook is… for one thing, I think a lot of people look them as the leader in the React world. But that they're moving to standardize on… is it Falcor? Or…

GraphQL and Relay.

Yeah, there we go, GraphQL and Relay.

Yeah, that would be a [inaudible] if they're moving to Falcor

Sorry. [Laughter]

Yeah. I was close, just not quite there, was I?

They're moving to Angular.

Joe, you're experiencing a little bit of tool fatigue.

I am experiencing [some tool fatigue].

Oh my gosh. So, is the piece, the server-side pieces that you're putting together that you've talked about, would they conflict at all with using Relay and GraphQL or would they be synergistic or just agnostic?

Yeah, you wouldn't be able to use it with GraphQL. So, the server stuff that we made is like REST things. So, we're like… again, you can use whatever. If you want to use Relay with Shasta you totally can. You just don't use the backend stuff that we have. So, that's like with the escape hatches that I mentioned earlier, we don't try to lock you into any way of doing anything. We just make it extremely easy to do things that way.

I think we've definitely gotten… you've well-communicated that point that these pieces really work independently very well. And that sounds actually really cool. It seems like a great part of what you guys have put, what you put together. Is there more people working on it or just you?

It's pretty much just me right now. But we have some other people who are going to throw in some work pretty soon.

How many pieces total does Shasta have?

I would say there are four main projects and then there are probably 12 to… no, there are 14 or 16 total modules.

Wow. Crazy.

I want to ask a little bit about the 'swapability' of things. Can you use something other than RethinkDB?

Oh, for the backend stuff? Yeah. You can use anything you want. We just recommend Rethink because they have the real-time change feeds which are super awesome. So, we had the Rethink co-founder over here at the house the other day. And we were talking to them about some stuff.

They're working on their own server-side thing.

Horizon.

Yeah, Horizon. So, we were talking about potentially… I mean I'm open to just scrapping our server stuff if they have something better or if the GraphQL stuff matures a little more. I'd be open to doing that. But I think that from what we've seen so far it's not stable enough. So, we're just working on this piece as a stepping stone to those things versus, “this is this permanent thing that you should use forever. Don't use GraphQL. This is the thing.” I think what's going to end up happening is you might use this for a little bit and then Horizon on the backend and some kind of a GraphQL system with either Relay or Falcor would be a more long-term look on things.

Well, it's also important with pieces, with stuff like this, to remember that people want problems solved well but they also don't want problems solved with tools that don't work for them. And so, Relay and GraphQL, that could be the kind of thing that a lot of people go get into and just say, “Oh, this just isn't right for us and we want other options.” So, your whole thing is pushing React a little bit towards Ember, right? But on the other hand, Ember has to be very careful that when they say, “Here's a full solution,” that it's a full solution that is as widely applicable as possible. Is that something that you guys, or well I guess you, sorry. I keep saying 'you guys'. That you had in mind as to “How can I solve these problems in a way that doesn't cut out anybody?” basically choosing opinions but not necessarily cutting of options.

Yeah, it's difficult for sure. So, one of the things… just for example, the backend stuff we were just talking about. So, that module is called Sutro. So, I tried to name all of this stuff after physical landmarks this time around, because I thought that sounded kind of cool. So, this module Sutro when you define an endpoint you can define any asynchronous function. It can return a promise. It can do… you can do yielding in it. It doesn't really have any opinions about how you get the data. It just wants you to return it. But we do have some stuff in there where it's like if you do return a RethinkDB query we make things a lot easier for you but we don't force you into it.

So, it's those kinds of decisions that are really difficult to get right. Because the initial version of it was like, “Oh yeah, you're just going to use Rethink.” And then it's, okay some of these endpoints don't need Rethink. Some of these things are doing other stuff. It's like, “Okay, let's rethink this and make it so that everybody can use it for whatever purposes they want.” And I think that's how you end up with those kinds of solutions, is just when people hit a wall and are feeling locked in, then you can figure out a way to get out of that.

I'm wondering. You said you had Dan Abramov over to your house and you had the Rethink cofounder over to your house. I'm just wondering when you're going to round up the trifecta and have Jamison Dance over to your house. [Laughter]

Yeah. I don't know. I'm actually moving in two days. So, I don't know if that's going to happen.

Yeah, aren't you starting…

That's quite the deadline.

Aren't you starting a new startup too?

Yes. So, I'm doing my third company in New York in three days.

Is that related to Shasta at all? Or is it just a totally separate thing?

Separate thing. We're doing open data stuff for the government. So, totally different thing than what I'm currently doing which is a product incubator. And yeah, we'll be using Shasta though. So, we use Shasta at all of the companies that I'm a part of. So, it's like our thing.

It feels a little bit to me like Shasta is a step towards something. It's not the destination. It may become the destination but it's not there yet. Where do you see things going in the future as far as frontend development in JavaScript goes? And how do you think Shasta plays into that?

Yeah. So, I don't… Are you all familiar with the way that Mercury is doing state management and stuff?

No?

Okay, so I think right now I'm feeling like somewhere between Redux and Mercury. I think that… and just to explain what Mercury does it's very similar to Redux in some ways with obviously the different nouns because you have to have different nouns to explain the same concepts. But yeah, so I think there's… and right now is, I don't know. Right now is like a renaissance for frontend stuff. State management has always been one of the things nobody ever really put a serious amount of thought into. And right now there are 10 things out with completely different ways of doing state management. And they're all pretty good. So, I can't really predict the future of what I think it's going to be. But my gut feeling is somewhere between Redux and Mercury.

Have you seen Viktor Savkin's experimentation with observables in a Redux implementation?

No, I haven't.

That was a very interesting twist on Redux where using observables cut out a lot of, I don't know if boilerplate is the right word, but cut a lot of interesting pieces out and added a bunch of interesting pieces in.

Boilerplate is always the right word, Joe. [Laughter]

But I think it's probably somewhere closer to Cycle. What he did was similar, like halfway between Redux and Cycle as I understand Cycle.

Yeah. You should link me to that. That sounds interesting.

I will.

Yeah. It's definitely cool to look at. I don't know if I would recommend people build stuff with it. It's [chuckles].

They don't even have a logo. I wouldn't touch it with a 10-mile pole.

I know, right?

Yeah.

Yeah, but it has more than 20 stars.

Just kidding, [inaudible] team.

The other thing, logos are really easy to make. So, if anybody is doing open source stuff and they want to know how to make a good logo, I'll give you a secret.

Go to…

[Whispers] Fiverr. [Laughter] ERIC:

All of the logos that I make now are Squarespace logos.

That's amazing.

Yeah. So, it seems like it would be really cheesy but they actually come out looking nice. They have nice fonts and their logo… so it's, you type in a word then they give you little clip art things. And you click it and it goes in except all the clip art is really cool and all the fonts are nice.

I always go to Fiverr. That's all the investment I'm willing to make sometimes.

[Chuckles] Yeah.

This has changed my life.

Yeah.

Just [inaudible] logo maker and it's [inaudible].

[Inaudible] are interested in this right now.

Yeah, so…

We should chalk that up to a pick. Are we ready for picks?

I think so.

Sure.

It just seemed like we're winding down. Alright.

Aww.

Alright.

It's cool-looking.

Joe, what are your picks?

Well, I'm going to pick Viktor Savkin's post. It was actually written about managing state in an Angular application but he basically adapted the ideas of Redux but utilized RxJS which Angular is heavily into. And did some really cool stuff and I've heard a lot of good feedback about it from other people that are heavily into the React world and Redux world saying that these are some really good ideas. So, that'll be my first pick, is Victor Savkin's post. I'll be link-… I think the title of it is 'Managing State in Angular 2 Applications' if you want to google it and not find the show notes.

And then for my second pick I really wish I could pick 10 Cloverfield Lane. I wanted to see it this last weekend and didn't see it. So instead, I'm going to pick Lazer Team. [Laughs] I have no idea if it's going to be any good or not.

But it looks… it's kind of like a campy parody superhero movie. And I have no idea if it's going to be any good or not. But at least the previews seem entertaining. That'll be my other pick.

Alright. Jamison, what are your picks?

I have two picks. One is a band called Big Black Delta. I think it might just be one person, actually. It might be one of those just one guy who's the producer or something. It's gigantic techno synth rock. I really like it. It's been the soundtrack to my week.

And then my second pick is this blog post on CSS-Tricks. I just really like their writing style. It's very clear and they take things that I usually think I understand and then just very clearly lay out a good overview of it in a way that always teaches me stuff. This one is about using Google Analytics more effectively. And it's just all about how without paying any money, just using all the free stuff in Google Analytics, you can get a pretty impressive idea of what's going on in your website or your product. So, it was a good read. Those are my picks.

Alright. Dave, what are your picks?

Alright. I have two picks. I finally got my book from the library, 'The Thing Explainer' by Randall Munroe who is the creator of XKCD among other things. It is really good. It is so good. I was really glad that AJ picked it a couple of months ago. I'd been waiting in line at the library behind 75 other people to get it. But it is so fun. Anyway, he literally just uses the 1,000 most common words in the English language which he describes as the 10 hundred most common words because apparently 'thousand' is not in the top thousand most common words.

So, [that's] great.

And then my second pick is a brand new podcast that Jamison and I created called Soft Skills Engineering, the podcast about everything else. Not the technical stuff but everything else in software engineering. So, join us. You can find us on iTunes. You can find us on your podcasting app. Or you can search Twitter for SoftSkillsEng and we're there. We'd love to have you and it's surprisingly good. Wouldn't you say, Jamison?

Yeah, yeah. It's been really good. I've enjoyed. We've done a couple of episodes so far. I've been pleases with the stuff that's come out.

Yeah.

Your SEO rankings leave something to be desired.

Yeah. [Laughter]

It's called 'Soft Skills' Joe.

Yeah. SEO is not one of the skills. [Laughter]

Alright. Aimee, what are your picks?

I have three. And side note, I did listen to the first episode of that. I thought it was pretty good.

But my picks are, the first one is a conference May 13th in Virginia Beach called RevolutionConf.

So, if you are in the area you should attend. I'll be there speaking and there's a bunch of other people speaking. So, it's pretty good.

Second pick is, I haven't… so, disclaimer. I haven't actually done this course yet. I haven't had the time since it just came out on March 8th. But it looks awesome. It is very high on my list of things to do. But it's another frontend Masters course by Kyle Simpson. So, if this one is anything like the rest of his I'm sure it's pretty awesome. But it's called 'Functional-Lite JavaScript'. So, I'll add a link for that.

And then I have a third one which may be possibly the very first time we've ever picked a more feminine pick on the show [chuckles]. But it dawned on me that I really try to gear my picks all towards things that I think every single person listening would be interested in and I've never picked anything that's remotely feminine. So, I'm picking something today that could be slightly feminine. It's Lush Cosmetics. And the whole reason that I'm picking this is I've done a lot of traveling lately.

And they have these bars of shampoo or conditioner or lotion. But it's all in bar form. So, whenever I travel I don't have to check my bags. So, whatever kind of toiletries you need have to fit in that little quart size bag. But if you have bars you don't actually have to check them. So, I bought a bunch of these things for whenever I travel. So, I don't have to use… sometimes the stuff at the hotel isn't the greatest or whatever. So, that's Lush Cosmetics. They also have some stuff that's like toothpaste that are just these little tablets that dissolve in your mouth and you brush with them. I guess it could be for men, too. But it's probably a little more girly. But this stuff is pretty awesome.

So, that is my third pick and that's it for me.

They get well-supported by myself.

I got a lot of… my money gets spent over at Lush.

Okay, cool. So for you or your wife and daughters?

My wife and daughters. In fact, we were talking about traveling. I swear, every time we go anywhere there's a Lush there. Any time we leave town there's a Lush somewhere and they're always, they gotta stop in and go get stuff at Lush.

Alright. Instead of picks this week I'm just going to let folks know that I'm going to be doing some traveling. Some of these other folks here are going to be doing some traveling too. But anyway, I think it's just AJ and I that are on the docket to go out to Build. But AJ and I from this show will be at Build as well as the iPhreaks show hosts. So, if you listen to either of those shows we're going to be at the Build conference. I'm going to pull together a meetup. I think it's going to be on the 30th of March. So, if you want to get together it'll be somewhere close to the conference or the hotel that we're staying at.

And then right after that I'm actually flying to Las Vegas. So, I think on the 2nd or 3rd of April we'll

be doing another meetup in Las Vegas. There, it'll just be me and my friends from the Entreprogrammers podcast which is a mastermind group that I do every week but is also released as a podcast. So anyway, you can check that out. And then in May, the Adventures in Angular and JavaScript Jabber podcasts are going to be done during lunch, during the ng-conf conference.

Woohoo!

So, we're going to pull together a meetup there as well. It'll be the, I think we decided the 5th of May. So, if you're in Salt Lake City you can come and check that out. I know that several of us live in or around Salt Lake City. But you can meet some of the rest of the folks who you don't get to see as often because they're either in town or they're just not at the events that you're at.

So, anyway then in July on July 9th I'll also be holding a meetup in Chicago. I'm going to be in Chicago for Podcast Movement and I'm going to stay an extra day just so I can meet anyone who wants to come out and hang out. And this is all sort of a big pick for the audiences for the different shows, because you're all awesome and I love talking to people. So, please show up. I sent an email around to the mailing lists. I'll probably send another one around here in a week or two. And if you're in San Francisco or Las Vegas, this show should come out the day before the San Francisco meetup. So, just watch my Twitter account. That's cmaxw. And you can see where we're at and where we're going to meet. But it'll be somewhere close to the conference. So, we'll do what we can to make sure that you know about it. And those are my picks.

Eric, what are your picks?

Cool. So, my first pick is Horizon. And I haven't really seen that much of it but I know the RethinkDB team is just going to kill it with it. Everything that they touch is just, I don't know. They just do a really good job with everything. So, that would be my first pick.

My second one, surf punk is back as a genre. So, check out the band Shannon and the Clams as a good intro to that. They're a surf punk band out of Oakland.

And my third pick is going to be the Shasta website because there's basically no information available. So whenever this comes out please actually go check that out.

[Inaudible] more in-depth information because it's very difficult to explain 16 separate projects on a podcast. So, you'll get good info out of that if I was totally vague on this. So, definitely check that out.

And those are my picks.

Alright. If people want to follow you on Twitter or anything like that Eric, where do they go?

My Twitter is @contra, C-O-N-T-R-A hacks. I think you know how to spell hack. And my Instagram is Y-U-N-G-C-O-N-T-R-A if you want to watch me bounce all over the place.