02:43 - Amit Kaufman Introduction

03:07 - Avi Marcus Introduction

04:35 - Why Move Your Rendering Engine to React?

07:25 - Using JavaScript

09:57 - Business Process and Progression (Getting Managerial Approval)

12:46 - Manipulation

15:11 - Layout and Performance

20:21 - Building Client-Side Applications in General

26:00 - Events 

29:30 - Storage

31:31 - Immutability

34:36 - Flux and Keeping Code Maintainable

38:19 - Two-way Data Binding

Picks

Notes on the book "Art & Fear" by David Bayles & Ted Orland (Jamison)
Papers (Jamison)
Dynamo: Amazon’s Highly Available Key-value Store (Jamison)
LDS Conference Talks (AJ)
Stephen Young: Why your code is so hard to understand (Aimee)
Kombucha (Aimee)
Pascal Precht: Integrating Web Components with AngularJS (Pascal)
Template Syntax Constraints and Reasoning (Design Doc) (Pascal)
RUNNING WITH RIFLES (Joe)
[Pluralsight Webinar] AngularJS 2.0: What you need to know with Joe (Joe)
Whiplash (Amit)
Dan Ariely: What makes us feel good about our work? (Amit)
React Templates (Amit)
Esprima (Avi)
Big Hero 6 (Avi)

 

Check out and sign up to get new on React Rally: A community React conference on August 24th and 25th in Salt Lake City, Utah!

Special Guests: Amit Kaufman and Avi Marcus.

 

Hello, hello, hello, hello.

This is Pascal, Pascal, Pascal. This is not an echo, echo, echo.

Hello everybody and welcome to JavaScript Jabber episode number 157. Today we’re going to be talking about moving your rendering engine to React. And today we have on our panel the amazing Jamison Dance.

Hello, friends.

The fantastic AJ O’Neal.

Yo, yo, yo, coming at you from a live tornado.

The ever-entertaining Aimee Knight.

Hello.

And the new but every so fantastic Pascal Precht.

Hello there.

And my name’s Joe Eames. I’m going to be your host today. As our special guests we have today Amit Kaufman.

Hi to you all.

And Avi Marcus.

Hi everyone.

Could you guys give us a brief introduction of who you are and your backgrounds maybe starting with Amit?

Okay. So, my name is Amit. I live in Tel Aviv. I’ve been developing for 15 years now doing a lot of startups with short gap for product management and my own company. And today I’m managing the editor group in Wix.

Very cool.

Avi?

Yeah, hi. [My name is] Marcus. I’ve been developing for 30 years, give or take. Just about anything under the sun. I programmed in anything from machine learning to mobile to, I don’t know, cryptography. And right now I’m the architect of the Wix editor.

Awesome.

So, did it sound to you a little bit weird that he says 30 years and he’s 35? [Laughter]

I was going to say, he doesn’t sound [that old].

Is that right? That’s how old you are?

Oh, 36, yeah.

Wow.

I started on a singular spectrum when I was six. I think the first thing…

Yeah, and you did university when you were 13.

Wow.

No, the teachers got mostly tired of me so they just dumped me into the university and said, “Let them take care of it.”

I’m 28 and I still haven’t finished school.

Oh, that’s alright. I haven’t finished either.

Oh, great. Right on.

I think the question on everybody’s mind is: Have you ever programmed in Pascal?

Yeah, of course. I think 20, 25 years ago, something like that.

Perfect. I just turned 25, or 24.

Actually, Skype is written in Delphi.

Which is like the descendant.

Yeah. Bonus points to anybody listening in who knows what Turbo Pascal is. [Laughter]

Pascal, that should be your new online handle, turbopascal.

It actually was for quite a while. [Chuckles]

Was it really?

No, no. Just joking, just joking. [Laughter]

Aw. That would have been awesome. Alright, so we’re talking about moving your rendering engine to React. We have you guys on. Tell us why this is something that you guys are interested in and have some experience with. Talk to us about that.

So, maybe I should give a little bit of background to explain what we do and how we came to know React. So, at Wix we’re doing a website builder, a WYSIWYG website builder. And basically we’re doing two products. One is you take the data and the site definition and you turn it into an actual website. And the other one is actually editing that. And it’s all online. We just [do it] in JavaScript, no native stuff. And about a year ago we had our product that worked for a couple of years and we started noticing that it’s becoming very clunky. And the performance got down and it became too much code and it was really hard to handle.

So, me and Avi we started fantasizing about something different. And we’ve noticed that when we write our own components that work on web, they actually are very hard to write because you need to handle all the DOM manipulations all the time. And you need to care about the state, whether you’re rendering for the first time or something changed or you want to change the way it looks like, because we have the site and we can skin our components and stuff like that. And we started thinking about, “What if we had a system of components where we would write an initial code and then we will have a template. And then it doesn’t matter which state you have if we just go on a single flow. And we also thought that would be very fast. And we fantasized about that for a little bit.

But we thought that comparing the HTML for making the changes would be so very hard to do. And we kind of abandoned it for a few months. And then Avi came to me and said, “You know what? I want to do something and there’s this new thing called React.” And I said, I looked at the site and I

saw all these XML inside the JavaScript and I said, “You know what? It doesn’t light. But you know I trust you. You’re coding for 30 years now.” So, we sat for two weeks and we proved to everybody in the company that it’s going to be a big win. So, this is how we came to it. Once we came to know we had the problem of taking all of our legacy code and 60 million site definitions that we had that were all JSON, and we wanted to create something that would be compatible with what we had but only would work faster and would be easier to maintain afterwards.

And we just started and did all that with React. And we actually found that it’s exactly the thing that we hoped for. And we also found a lot of other stuff that we didn’t think about. And I think this is the thing that we came today to share a little bit.

So, I have a couple of questions. Maybe you covered them already and I didn’t pick up the answers. But why did you use vanilla JavaScript to build this out in the first place? Is it just because there weren’t a lot of frontend frameworks around when you first started it?

Oh, actually the requirements of Wix are quite different from most websites. Most websites know what’s in the website when you build it. You’re not surprised by anything that’s going to be in there. And in Wix, the combinations are infinite. We’re generating CSS on the fly because we can’t have all the CSS of all the users somewhere where they can download. We just generate it from the JSON.

So, that’s something for example. I don’t think any framework really supports natively… React actually does, which surprised us. Because it’s just saying, “Okay, this is a [new] HTML. Inner HTML it and it’ll work.” But most stuff doesn’t think about things like that. They assume you load your CSS and you’re done. Because we reuse a lot of code from the editor in the viewer and vice versa, a lot of our stuff needs to support all the changes from each possible mutation to each other possible mutation. And that really, it’s a requirement that most frameworks don’t support. At least they didn’t when the project was started two and a half, three years ago, the original codebase.

A lot of times company’s histories going to the game. And at Wix three years ago, we moved from being the best Flash website builder which today sounds like a joke… [Laughter]

Into HTML. And a lot of people, they wanted to have very object-oriented programming. So, there was a lot of emphasis on doing object-oriented in JavaScript and good componentization. So, everything that has to do with a component is inside. And Angular was just something that people heard of. And most of the debates were using jQuery or MooTools or stuff like that. So, we’re talking about in JavaScript, it sounds like ancient history. We started with it and we’re a team of 40 developers. So, it became huge very fast. And two years afterwards it is a really challenging decision for a company to go and take the [milking cow] and rewrite it. It’s usually what most companies do, just how they go to die. And it was a very bold decision to stop everything and do a complete rewrite of the thing which is in the core of the company and do it in a technology that was relatively new.

So, I guess one question I had, the company I’m at, they did a big rewrite a couple of years ago before I was here. And getting buy in from the CEO or people above I guess was a little bit difficult. So, did you have to go through a process like that? And if so, was it difficult because React is a very different technology than a lot of stuff out there?

We started as a skunkworks project. I was doing it alone for a few weeks, just seeing how far I can take it and how fast. And we started adding people slowly and seeing the progression, how far it goes. And by the time we showed it to management it was so impressive that it was a really easy yes.

I can tell you a little bit about what it actually gives us. So, first of all we wanted to be faster. So, I kept having those conversations with my manager. And he would say, “You know I want you to take a couple of guys and they can sit on performance for a couple of months. And let’s try to improve by 10, 15% and bring us to the good point.” And I keep telling him, “Don’t bother me with 10, 15%. If I’m not improving it by 100% I don’t want to write a single line of code.” And we actually really, really wanted to be faster. We also wanted the ability to go into server-side rendering. Because today the website, they’re client-side rendered. We have a different SEO renderer that renders the same stuff, or the equivalent stuff for search engines. But we wanted to have one single point.

And we also know that with the changing landscape of devices and all that, if you want to get to the cutting edge performance you have to get the HTML coming from the server. So, this is another thing that we understood that we want to get from any framework that we will get. And it was very appealing for us, that I can render the stuff through virtual DOM or I can render it just to string. And also, the model when you start, I think a lot of people develop small stuff. But when you develop something huge, and Facebook is talking about that all the time with React, and we see it as well, you need to have simple models and consistent models. And you have to get very, very good abstraction between your code and the bits that make the site work.

And I think that the one-way flow of React makes it much, much easier. And the fact that a lot of your coding can become declarative based on the template and you can see the HTML that goes out and you say hello and goodbye for all the jQuery-style manipulation, this is something that can really help in creating a stable environment and coding [inaudible] that can actually work. So, do you want me to tell you a little bit about the special things that we found out about React and the things that we had to manipulate that were different than what most people do with that?

Sure. That sounds great.

Something that Avi mentioned before. When we write components we need them to work in every site. And when we think about CSS in most cases, we find the cascading nature of CSS to be very appealing because it helps us as developers to write less CSS rules and make sure that they’re all applied. When you’re actually writing something that would run as a website of somebody else that doesn’t know how to code and doesn’t care about CSS and doesn’t write it, you actually need to do CSS isolation.

So, it’s a little bit about what is being talked about with Web Components and [inaudible] inside the component. But we had to create it. So basically, when we write components what we do is that we have our HTML code and the JavaScript code and we create SASS file. And then the SASS file thinks that he is alone in the world. And what we do is that we transpile those rules into some JSON. And then when we render the site we actually namespace all the styles to make sure that there are no conflicts inside.

And the nice thing that we saw and I think this is one of the things we love about React, it’s very consistent across all. So we said, okay, we need to render style tags and the content of them, let’s do it just the React way. So, we have a component that renders the style tags. And whenever we change for example from the editor, we change a style or a theme of the site, it just re-renders that style node and not anything else. And make sure that the changes are very fast and you can see all the style of the site changing.

That’s really interesting.

A weird thing about it is most of the cases, if you mess up the keys in React then the reconciliation does a bit more work. It’s not a big deal. But if it yanks our a font link from your stylesheet, everything will get this crazy jump between no font and back with a font when the browser reloads the font. So, it’s really important to keep notice of those small things when you’re touching your stylesheet live.

Another thing that was interesting is that because we, people are just dragging and dropping components on the website, where to create our own custom layout that is based on our own internal rules that are more applied to our editor than to HTML. So, all the really, really cool tricks that you do with CSS for layout which is one of the most difficult things when developing really pretty applications, we just cannot do it. We can do it but only inside the components, on all the stuff that users drag and drop, we cannot do that.

And one of the problems we had with the rendering, and I think it’s not just for us, it’s when people develop let’s say galleries, let’s say masonry galleries, they need to measure and change stuff. In all those places, what we found when we look at the stack traces, we get… a component gets a change and reads something and calculates it, and then changes its size and issues an event. And somebody else which is totally unrelated catches that event and says, “Okay, now I need to calculate my size and to change it.” And every time that you do that, the animation frame’s clock is ticking. And we found that this is one of the things that were blocking our performance.

And of course what React does really helps with that. But what do you do when you want to do your own measurement? Because React is one-way and you cannot measure it. Our solution was to say component has, we extended React for ourselves and said each component will not only have its render cycle where it’s being the one-way flow. It will also have something called the measurement patcher, which means that it can request to measure its own DOM. So, it would get measurements of the DOM. And then it can patch the DOM. And what we do in order to not get into those cycles is that once we finish rendering with React, we get the callback. And then we do one cycle where we measure the whole document because measuring one div or a hundred divs would cost you almost the same. And as long as you’re not writing to the DOM.

So, we measure everything that any component has. And then we keep that in memory and then we do another loop where we patch everything up. And when the components get into the patching, they get the information from memory and not reading directly from the DOM. So, a lot of places our cycle is get some event, set state, cause a rendering cycle, and then after that do a one pass of measure and then one pass of patching. And this becomes really fast even if you’re doing your own layout mechanisms for specific components, stuff that you just cannot do with CSS.

React has this componentDidMount or didUpdate lifecycle hooks for doing things that are DOMbased, because that’s basically the first point in the lifecycle where you actually get a DOM node. And if you start adding random reads and writes into those, your performance degrades really fast. It’s really important not to interleave your reads and writes. And that’s what we basically did. It’s just a global read pass and a global write pass. And it really helps keep the performance crisp.

Is this measurement mode you’re talking about, is that something that you’re configuring on a component level that you can say, “So this particular component should be in measurement mode”? Or, how does it work then?

Yeah, basically we have every component can say I need this or I need that. And it executes the specific code for the specific component. But always in the lifecycle of the single pass of reads and the single pass of writes.

And one of the other things that we did and we thought we’re going into server-side rendering and we cannot do those stages in the lifecycle. And also, when we do the server-side rendering we want to have the webpage showing as fast as possible. So, we don’t want to actually bring all the code that we would later need in order to have all the components live and working and doing animations and all that other stuff. So, we moved those measurement patching code outside to a specific, we split all our code into what we call packages, which is something also that we did that would enable us to split the loading. And we have all those in a single package. So, it can render server-side and then bring a very, very lean part of the code that would only do the measurement patch. And only then bring all the other React code and the code for all our components and logic. And only then do the late binding of React into the DOM, so we can get the best perception of speed for a site and have it working, most of it working as fast as possible.

I have a question on a different level. We talked a little bit about some of the unique things you’re doing with the internals of React. I think there are a lot of people listening that don’t use React, who don’t know React. And I wondered if you had any more general lessons for people just building client-side applications or applications in general, from this big rewrite, either from the vanilla JavaScript side or from switching to React. Why do people care about this if they don’t use React, is maybe another way to put that question.

So actually, there’s a lot of stuff we learned on many levels, on the levels of how to do such a big project, on a lot of stuff. I can say that the way that we worked with React, we found out about some stuff that we really care about. And it helped us pinpoint the stuff that we care about.

So, one of them is abstraction and having a good abstraction. There are all kinds of frameworks and all kinds of code and libraries that you use. And we see that good abstraction is something really important. And I can say that good abstraction is somewhere where it’s easy to do something. You get something from some framework or library and it does what it needs to do. So, it saves you a lot of time. But you don’t need to really care about how it works. It should just work. And it should be flexible enough so that changes that you do would be easy. But if you want to do something outside of the box, it wouldn’t be hard. You wouldn’t need to change the abstraction. And I think working with React, we actually found that for the first time.

So, we’ve been coding and playing with all kinds of frameworks. And for example, half the company works with Angular. And they love it and we love it as well. But we found for example that the abstraction there is not as good as it is in React. So, in order to really be able to use Angular well you need to really understand it. And I remember we were reading a lot of the source code of Angular. And one of the things that surprised us when we started with React is that we could use it without looking at the source code. And that was really important. So, getting the simplicity and getting to be able to use other stuff without caring about that is something important and really helps the team. So, that’s one thing.

Another thing is that you need to have, to know what you’re doing. So, make your code to be something that is very predictable and clear and that you understand about the flows. And I think a lot of people out there working with JavaScript are using and abusing the event systems way, way too much. And the problem with event systems is that at the first moment it looks like a really good idea because you write something and you just push an event out. And you’re done and you don’t need to care about whoever is consuming that. But one of the things we saw is that when the application starts growing, you end up with stack traces that you just can’t understand. And you don’t understand why you see this and that on the same stack trace. And the reason is that some event was triggered. And when you try to tune that and to make good performance and less code, it just becomes impossible because you cannot trace the relations. And I think the change in the model that we did was also, really opened our eyes to that.

One last thing that is not React related would be understand really well what you’re planning to do. So, in that project it was changing code that was written by 40 people in two years. And we wanted to do it in two months. And we actually managed. And the reason why we managed to do that is that it was very clear that we’re not going to add any features. We’re going to take all the site definitions that we had with JSON and we’re going to keep it the same. And we want to have the output to be the same, not the same HTML but it should look exactly the same. And this is something that really guided us and helped us complete that task on time. And we used all kinds of software to do image comparison. And this was really helping us, guiding us to know, are we there yet or not? How many of our sites or the sample sites, they look the same.

We encounter all kinds of funny stuff, like we found out that there were bugs that we had in the system that we’ve had for a long time. And nobody actually understood the bug. And when you’re rewriting, then you need to think, are you going to fix it and then break all the image comparison, or just do an extra effort to code the bug inside the system again just so that it would look the same? But having a very clear goal once you’re executing was also something that we learned from that which is not React related.

For me it’s functional programming. Because the core concept in React is that your render function is functional. It’s declarative. And you have state and props and you generate the way you think the world should look like. And the more code you transform into functional, the easier it is to test your code and the less bugs it has as it changes or you add feature and stuff like that. Because it makes the codebase interact less with other pieces of code. And that’s really important when you’re writing a big project.

Yeah, I would agree with that. So, I have a question about the events. So, you were mentioning that a lot of people use events too much and that can cause weird results in your stack trace. So, we were talking about elements, as in pure elements, DOM elements. Their APIs are just properties, methods and events. So, when you say that people should be careful with using events, what kind of advice do you have there? Is there anything else we can use? Or is just using less events the better way?

It’s events that are logical, is what we were talking about. Events that are DOM-based, you have to work with them. That’s the world you live in. But the minute you start writing your internal code, your logic, in an event-driven way, it becomes really hard to reason about. And you have all those small pieces of state all over your codebase where something remembers that this event fired and something remembers that that event fired. And that makes the bugs really nasty and the debugging really hard.

So, I’ll give an example. Let’s say you are building the e-commerce component, a cart component. And you say I’m starting with that. And of course I have the button that says ‘checkout’. And I want to add something to the cart. And you want to do something with it. So, of course you have to use [inaudible] to get what the user captured. And it’s fine. And at any given time you have one event that has been triggered by the user.

But then in a lot of places you would say, “Okay, so I wrote the component and I want it to work with other stuff.” So, that component can now understand that this event is being translated through a logical event. It’s saying something was added to the cart. Because maybe you have a different component which is like a cart widget that says on the top of your site how many stuff you have in the cart, and you want that to be listening to the add cart or the product component. So, the product component exposes the ability to register events. And then when it adds something to the cart, it triggers an event that says added to cart.

And it’s really easy to compose, because other components, they can be something that shows how many stuff you have in the cart. But it can also show, give notifications about some other stuff. You don’t care about that. So, they register to the event and when that event happens they do something. And it’s really easy to write and we saw that a lot of people are writing client code like that. And this is what becomes tricky, because then you click on something and you look at the stack trace and you see that something completely unrelated has changed due to that.

And we find that having something which is controlled, I have an event, it goes all the way up, I change a state, and then everything that should be rendered again or changed just changes. And nobody cares about the state. Once the renderer, they just take what they have, and they push the HTML out. And somebody else takes care of reconciliation in the DOM. It becomes a lot easier and a lot less state and different cases. You’d have only one case, which is going down and rendering according to the parameters that you get which are the props and the state.

Okay, thank you.

Makes sense?

Yeah.

Also we tried to, this was a little bit before Facebook told about [query QL] and all that. But we did something similar in the rendering engine where some components would need external information. So, we store most of the information of the site in one place. But what if we want to get a dynamic list or want to read something from a store or a blog or something that we would like to update the database on the site without updating the site?

So, some of our components would say, so before we would start rendering we would go over the components and would ask them, does anybody have some data requirements? And then all the components that would have that would give the URLs and where they want their responses to be stored when we get them back. And we would sometimes delay the rendering of everything for I don’t know, 50 or 100 milliseconds. It depends on what we believe should happen and should take [inaudible] to this information to come back. And then when we would get it back, we would just render and we would have all the information.

But you want to have graceful degradation when the database is slow or there’s some network problem or something like that. So, we’ve created something we called lazy components. And those are components that you put them in someplace and if they don’t have the data or they didn’t load their own code, it would just render an empty div or loading or something like that. When the data comes in, they will actually go and render. So, you can get the classic client-side rendering where you show some parts and some widgets or stuff like that are filled later. And we found that it’s really easy with React because when we have more information we just re-flush the whole rendering of the site. And it would just fill in all those boxes that you didn’t have the information before.

We’re talking about things that we learned. So, there’s a lot of hype about immutability lately in the JavaScript community. And we understand it and love it. And everything that we do is based on immutable JS inside. And…

Can I stop you for a second? Can you talk a little bit about what immutability is? There might be some people listening that don’t know what that means.

Sure. So, I would give an example of why immutability is important and what it is. So, let’s say if you have an object like a normal JavaScript object which has properties and you passed it to somebody. And let’s say it’s a person. And it has name, first name, last name and all that. The call that you’re calling that gets this object can change for example the last name. And then when you get it back, it just changed under your feet. And we can see that there are places where we don’t like that. And everybody has it. It’s very common for everybody to think about string like that, because string in JavaScript is immutable, right? When you say I want to get the substring, it doesn’t change the string itself but you get a new object. And that really helps the one that has the pointer to the original string not to be affected, get the side effect of other places that touch that.

And when you talk about real immutability then it’s about wrapping all of your data structures in a way that you cannot actually change it. But only, if you want to change it you get a new reference to the object. And this really helps also in optimizing, especially in React. When you render the tree, it’s really easy to see if the information that you had changed or not, because you can just compare references if all the data is immutable. And I think this is what’s causing all the hype. And it’s also very [pervasive] in Scala and other languages. Does that make sense?

Yeah, it does.

So, there are all kinds of emerging libraries about immutability. And the thing that we learned is that it’s very good and it gives us all kinds of stuff. For example, it gives us the ability to do undo on changes. So, we have websites that people edit. And every time they edit, they change the definition of the site. And if we keep that definition of the site as an immutable object, we can just have all those objects that represent the different stages of editing. And we can jump through each one and just re-render the site. And it would just do undo and redo and stuff like that.

But also, we found that with all the good parts it also has impact on performance, because everything is wrapped. And also, it becomes a little bit harder to work with objects, because there are wrappers around the objects. So, you cannot just go and change them. And everybody that thinks about using immutability should think that it can bring amazing benefits. But today there’s a little bit of overhead to be working with that.

So, one question I have, I’m not horribly familiar with React, but I was curious if you guys were using Flux or something else. In general, what is your approach for keeping the code maintainable? And I think you mentioned there were 40 people that had worked on it in the past. So, with it being a less opinionated framework library, whatever you want to call it, what is your approach for keeping things maintainable over time?

One of the interesting things we did is we separated our code into packages. And the idea there is that every team has its packages which are little chunks of code that they’re responsible for. And so long as they keep their public APIs constant and stable, they can play with the internals as much as they want. And that really helps solidify the boundaries between the groups and between the teams. And it really helps reason about things.

So, are you using Flux? Or are you using something else?

So, I think Flux is an idea, right? And the idea says that don’t do minor changes in a subtree of what you’re presenting in your application. But instead, take the events and the things that happen while the user’s interacting, take them all the way to the top and then change the store. Do everything that you need, and then change the state. And then re-render everything. And in that respect, this is exactly what we do with the rendering, because we keep the whole site as a JSON definition, which is our store. And whenever something changes, we actually change the site definition and then re-render everything. So, this is kind of the Flux way. And there are all kinds of libraries today that formalize it. But we do believe in the concept.

And we found it, it’s very helpful. And of course, once you start doing it and you present a lot of DOM in your site and a lot of components, then you need to think about your performance again, and think about how do you make parts of the code or parts of the components and the stuff that is not related with changes, not being re-rendered. And if you don’t do anything, React will just go over everything and then reconcile the VDOM. And all this process is really very fast. But when you have a lot of information, you can start to feel that. And that’s where you, all the immutability and all that kick in. Because in React, in the component you have lifecycle events like asking it…

Should Component Update.

Yeah. And each component can look at the new properties that are injected in and say, “Do I like to render or not?” And if you pass objects that are really easy to compare, you can decide that you don’t want to re-render it. So, in a way you have two ways to optimize your performance with React. One of them is say, I will just do everything and React will see what is changed and will change only that. And the second is if you create a lot of DOM that would need to be compared and you don’t want that to happen because you know you’ve got something that is really easy to compare on the data side, then just compare the data side instead and say, “No, there’s no change for me. Just keep me.” And then the Flux works because everything that needs to be updated on the application is updated. And the things they don’t care, they either skipped or just not being rendered to the DOM. Makes sense?

Yes.

Also, I think for the ones that do know React or other frameworks, I think one of the nicest things is that in places like Angular you get two-way binding. And this is something that is really easy and nice for developers. But in React, you get something that looks similar but is not similar. So, you’re able to say, to give one method for each input. And to say, “I’m giving you the value for that input but also giving you the callback for when something changes in the input.” And when you get notified on the change, if you just do setting the state and just render again, it looks like you have two-way binding.

But the nice thing about that is that you can have any method that would do that. So, you can actually bind your model to stuff that is outside [inaudible]. You can bind it to server, you can bind it to remote code, and other stuff. So, it gives you a lot of flexibility when binding your model to something.

Awesome. I think we’re about wrapped up. We’ve hit the time limit. Before we move into picks, Jamison, do we have any conference announcements?

Oh my gosh. I’m so bad at this. Yeah. Yeah, we do. [Chuckles] Matt Zabriskie and I, my friend and I are organizing a conference in Salt Lake City in August called React Rally. We are probably a couple of weeks away from putting up the call for proposals and the schedule and ticket sales and all that stuff. But if you go to ReactRally.com right now, you can give us your email address and we will either sell it to spammers or only send you information about the conference, one of those two.

Yeah, you should come. It’ll be really good.

I think we should rename Salt Lake City to Conf Lake City.

[Chuckles] Yeah, yeah, ng-conf, there’s a bunch of stuff going on there.

So, who made that awesome website, Jamison.

It was the designer at the company I work for. His name is Gary Wilkerson and he’s pretty great.

It’s a pretty great design. I really like that.

Yeah, he’s got skills.

Alright. Let’s do picks. Jamison, since you’ve already got your mouth moving, how about you throw up some picks for us?

I will just say them instead of throw them up, because [chuckles] that sounds gross.

I have three picks. One is blogpost called ‘Notes on Art & Fear’. Someone who read this book about the creation of art, but they read it through the eyes of a developer. And it’s probably a book I’ll never read, I’ll be honest. But the lessons that they pulled out of it are pretty interesting. There’s a story about these two groups of people who created pots for a class. And one group was judged solely on the weight of the pots. So, if they created 50 pounds of pots they got an A. the other group only had to create one pot and they were just graded based on the quality of it. And all of the group who just were judged on the quantity of their work produced better work than the people judged only on the quality of one piece. So, there are some cool things in there.

The other two picks are, one is an app called Papers. I started reading a bunch of academic papers again lately. And I haven’t found a great way to synchronize them across devices and annotate them and tag them and stuff like that. And this is a pretty good one. It’s kind of expensive. But it’s the best one that I’ve tried so far. It only works on iOS and Apple devices though. So, if you don’t have those then [chuckles] don’t use this.

And the last one related is a paper I read recently. It’s not a recent paper though. It’s the Amazon Dynamo paper. And it’s just a great read, if you are interested in distributed systems. It’s kind of one of the foundational recent case studies on a big distributed database. And it lays out some of the problems they’re trying to solve and some of the cool things that they to solve them. It’s very clear and easy to read as a beginner in the field. Those are my picks.

Awesome. Alright, AJ.

Okay. So, I once did yoga for a little bit. And it was pretty cool. I had this friend who is into yoga and she invited me to come and do yoga with her in the mornings. So, for a couple of weeks before it got too cold that fall, I did yoga with her and some other people. It was a good experience and I felt better. And I think everybody that has a routine of some sort whether it’s yoga or it’s not hitting the snooze button, if you have some sort of something, it’s good. So, I would pick yoga but that’s not what I actually want to pick.

The purpose of saying that is because I’ve done yoga but I’m not a yogi, right? And so, I want to pick the general conference of the church of Jesus Christ of latter day saints. And you don’t necessarily have to be a Christian or believe in all the things that they believe in. But there are a lot of good messages. And all of these talks that are by people that are pretty fairly conservative, just to be warned. But fairly conservative but fairly family-oriented, all about promoting good values. It’s like a spiritual TED talk kind of thing. So, I’m going to pick that. And if it sounds like something you’d be interested in, I definitely say check it out. There’s a hundred different, well not really a hundred, but there’s dozens of talks that are all about improving your life and everything from marriage to finances to whatever, addiction problems. So, it’s really cool. And I pick that.

Awesome. Aimee, you’re up.

Okay. So, I have two. The first one is an article that was posted in our Slack channel. It’s about just forming mental models for your code. It’s about making your code more readable. So, it’s short but I got a lot of value out of it.

And then the second one, not code related, I have heard in the past on this show and then I also listen to Ruby Rogues, people pick beer a lot. So, this is not beer. But I’m going to pick a drink called Kombucha. I don’t know if anybody’s ever heard of that.

[Laughs] I was afraid of that.

Rotten carbonated mushrooms.

[Laughs] No, no. Okay, so it’s fermented tea. And so, a lot of people turn their nose up, especially here. A lot of my friends or a lot of people in programming are like, “What in the world are you drinking?” But I’ve actually had some people convert. So, I thought it was worth mentioning. I think you should try Kombucha. It will make you feel like a million bucks. So, those are my picks.

Awesome. Pascal, how about you?

Sure. So, if you’re into Angular, I’m a bit into Angular, and I’m learning Angular 2 right now. And so, in Angular 2 there’s this new templating syntax. And a lot of people are asking why it’s like that, why it looks so weird, and what is that thing? And it turns out that there’s actually a lot of reasoning behind it. Basically the main reasons why the syntax is as it is, is because of the Element APIs, the DOM Element APIs that you have in the browser. So, in order to make Angular 2 work with any kind of element, so native elements and custom elements and web components or whatever, Angular needs to understand or Angular needs to define an API or syntax that work with any kind of element. And so, for me personally, it really helped to understand the reasoning behind it. If you learn about the Element APIs that you have in the DOM. So, if you want to understand the templating syntax and why it is as it is, and if you want to understand the reasoning behind it, go and learn the APIs of a DOM element. And also check out the design documents from the Angular 2 project.

Awesome. I’ll go next then we’ll have our guests bring up the rear. So, I’m going to have two picks today. The first one is a video game I recently purchased which is called RUNNING WITH RIFLES.

Yay. [Chuckles]

That doesn’t sound safe.

Did you play, Joe? [Chuckles]

What’s that, Jamison?

Did you play? I would play this game with you.

Keep your finger off the trigger while running. Always point at a safe direction.

[Chuckles] It’s a crazy, very cartoonish top-down. One thing that I said, it’s Call of Duty meets, not Sunset Overdrive. I can’t remember the name of the other game, some cartoony game. Anyway, it’s interesting. It’s essentially a top-down shooter. And it’s actually quite difficult. I played for a while and I was like, “Man, this is a real pain in the butt. I’m going to stop and go play something easier.” [Chuckles] But it was addictive. And I actually said that for about 45 minutes over and over again. So, just to give you an indication of how addictive it is. It’s actually quite a fun game. So, that’ll be my first pick.

What you need to know’. So, this is on May 14th at 10am Pacific Time. It’s a free webinar. You can just get on. It’s about an hour. And I’m going to be going over Angular 2 and the state of it, where it’s going and how to learn it and play around with it today, and the basics of it. And that’s my final pick. Amit, how about you?

So, I recently saw Whiplash. You know that? That’s a movie about drumming. And it’s actually amazing. It talks about creativity. I think it was really great.

The second thing is a talk by Dan Ariely in TED about what makes us feel good about our work. And I think everybody can see that first. It’s enjoyable but also it talks about what happens when you do things over and over again and they’re not being published or being recognized. And it’s really interesting, thinking about management and about the stuff that we make our employees pass as we change from one project to the other.

And the last one, I didn’t intend to do as a pick because it’s a self-pick. But we didn’t have the chance to talk about it. And I’m really passionate about it. We created an open source project called React Templates. And this is a project that helps you write templates in HTML with some very, very basic control flows like for and if that would be then transpiled into JavaScript code. Very readable, that is pure React code. And it helps you write all the stuff that is un-reusable components. So, whenever you want to reuse, I don’t know. You can do whatever you like. But let’s say you want to write something that has a lot of content and not a lot of logic and you cannot reuse it in many places. You want to be closer to the HTML. And this small project really helps with that. And it’s really nice. I’ll post the link and everybody can play with it. That’s it.

Okay. My first pick will be Esprima, which is basically a Node module that lets you transform your JavaScript code into JSON. And the thing is, the second you have your code as JSON you can start playing with it. You can do refactoring using Lodash or reason about it and convert it to other stuff. So, play with it. It’s worth it. It’ll make you rethink JavaScript and maybe find a new way to do the horrible boring stuff that we sometimes need to do.

And my second pick will be Big Hero 6, which is just a fun movie I saw a few days ago. And it’s a Disney cartoon. And just watch it.

Awesome. That is a great movie. Were you watching it with your kids or were you just watching it for fun because you like animated movies?

No, I don’t have any kids yet. Maybe in a week or two. But…

Oh really? [Chuckles]

Hopefully, not [inaudible].

He’s serious.

Wow.

So, you’re just flipping a coin or what?

Yeah. [Laughs]

I’m going to pick your soon to be arrived child

Aww.

That sounds [inaudible].

Yeah, congratulations. That’s awesome.

Thanks.

Alright. Well, thanks everybody for coming. We really appreciate Amit and Avi coming on and Pascal for stepping in last minute for us. And we’ll see everybody next week.