Cover image of The Frontside Podcast

The Frontside Podcast

Updated 1 day ago

Read more

It's like hanging out at our software studio in Austin, Texas with Charles Lowell and the Frontside Team. We talk to smart people about how to make the world of software better for the people who make and use it. Managed and produced by @therubyrep.

Read more

It's like hanging out at our software studio in Austin, Texas with Charles Lowell and the Frontside Team. We talk to smart people about how to make the world of software better for the people who make and use it. Managed and produced by @therubyrep.

iTunes Ratings

7 Ratings
Average Ratings

Great show for web developers

By Aaron Dowd - Mar 07 2014
Read more
I’m really enjoying listening to these guys talk about their experiences building web applications. Keep em coming, guys!

iTunes Ratings

7 Ratings
Average Ratings

Great show for web developers

By Aaron Dowd - Mar 07 2014
Read more
I’m really enjoying listening to these guys talk about their experiences building web applications. Keep em coming, guys!

The Best Episodes of:

Cover image of The Frontside Podcast

The Frontside Podcast

Updated 1 day ago

Read more

It's like hanging out at our software studio in Austin, Texas with Charles Lowell and the Frontside Team. We talk to smart people about how to make the world of software better for the people who make and use it. Managed and produced by @therubyrep.

Rank #1: 106: Microstates

Podcast cover
Read more

In part I of The Frontside's microstates series, Charles Lowell, Taras Mankovski, and David Keathley talk about state management that’s easy and fun and transactionality.

This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC.

Upcoming Conference Talks:


CHARLES: Hello, everybody and welcome to The Frontside Podcast, Episode 106. My name is Charles Lowell, a developer here at Frontside and I'm going to be hosting today's episode and we're going to be talking about microstates with fellow Frontside developers, David Keathley and Taras Mankovski. Welcome you all.

DAVID: Hello.

TARAS: Hello, hello.

CHARLES: I'm really, really excited that we finally get to talk about this but before we jump into this, just wanted to let everybody know that last week, we published our roadmap for Big Test, which is a JavaScript acceptance testing framework that we've been building right here, in-house at Frontside, which can work with both Ember applications and React applications, Vue applications. It's in alpha phase and we're looking for feedback but we're really excited about it, so we're going to leave a link to that in the show notes and please go check it out.

All right. Finally, the moment has come that we actually get to talk about this publicly. We've been publishing things about microstates for a while now but we feel that it's ready to share with the world and that's really, really exciting. We should probably like wind the clock back a few years because that's about how long we've been working on this and talk about, kind of the why and the what of what microstates are. It's kind of a weird word. What are we doing here?

TARAS: Yes. That's interesting question because we were working for so long and after all this time, what is this specifically we're working on. I can speak personally from my personal motivations because we have conversations over the last two years to why we were doing this and I think for me personally, it's always been that I've been mentoring building complex applications for almost five years now and one of the things that I find consistently is that there are patterns for how to build complex stateful UIs that the required solutions, that are fairly reliably consistent.

I can teach people certain patterns and then they can use patterns to build complex applications and those patterns scale really well, the challenge is that, there's not an easy way to express them and it's different for every framework. The way that I would teach somebody how to do it, for example in Ember versus how they would do it in React, even though the pattern itself is the same but the implementation of the pattern is different but it's different in such a way that it's very difficult to see where the consistency is, what is the same about these two patterns.

It shows me that there is room for improvement. In the same way that if there is an opportunity that in the future, components will get unified under one umbrella or what component spec. The fact that we do states differently across every implementation, across every opinion, it suggests that what we might be missing is something that would unify across frameworks, how we actually do statement management.

CHARLES: Yeah, that makes sense because as much as people try to buck the trend of MVC, it can't keep coming back in the rear view. Hopefully, not like a horror villain but like a caring friend, like a reliable pattern. I remember when I was in writing Java applications back in the day, the most important thing when you were writing a swing application was making sure that you had your models right. If you were modeling either a form or a dialogue or a set of pages, the most important thing was to have those models.

Back in the day, we modeled those things with event listeners, very similar to where the way like a Backbone application used to work or if you're familiar with Ember Object, the way that it worked basically, adding observers to some model so that when that model change, you were able to react to that. Your representation was able to be 100% dependent on this model. That was like a Java Swing Application, which was then inherited from this pattern from Smalltalk but we keep on seeing this again and again and again. There is this piece, this state, that if you're going to be representing something, then you need to be able to get at the meat of it. That's ultimately what the model is in the MVC pattern.

I remember when React first came out, everybody was like, "Oh, MVC is dead," but now in terms of state management and all of the state management solutions that we see, what that really is, is the model trying to reassert itself. Because it's such an important piece of your application, it's going to rear its head and you cannot escape it. I make it sound like a problem. I guess, it is a problem but there's a proliferation of solutions out there that are attacking the problem in order to represent something you have to know what that something is.

DAVID: I think when you only work with the one framework, your perspective might be very much shaded by your experience. If you're really good at building React applications and you have subscribed to POJO is king and you don't need anything beyond that, then you're going to get good at handling POJOs and you might not realize that there is actually limitations to what you're doing. I think the same applies to people who use Ember and they're using Ember Object and they have computer properties and now, in Angular, there is observables and subscribing to streams.

What was really interesting with the work that we've been doing with microstates is that and one of things that have notice with other state management solutions is that a lot of them emerge as, "Oh, I had this insight. I spend a couple of days working on it. Here's my proposal, in a way, for managing state." I think that's great because insight and understanding is really important but sometimes, taking the time to design something can be really helpful. I think that one of the things that are really interesting with microstates is that because we've been iterating on it for so long, they've been testing it for so long, we've been able to do something in microstates that's really difficult to do when you have a production application that you're like, "I want something different. Something is not enough but I don't have the time to really make it better," or, "I have an idea. I want to release this thing but I don't have any other collaborators that I can talk to and really flush out these ideas," so what you get is a solution but it doesn't always touch on a lot of the angles that you want to touch on.

It's really interesting when you think about --

CHARLES: I'd say, we should talk about those angles, like what are some of those angles?

DAVID: Yes. You could think about this from a few different perspectives. I would say, from Ember perspective because that's been my personal starting point. For anyone who was listening. Ember and Vue, for all intents and purposes, in this scenario are very similar because they have the same primitive, which is the computer property. The computer property in Ember, the computer property in Vue is almost identical from the way that you actually consume.

In Ember, you would use computer properties and in Vue, it's just computer properties to create derived state from data that's passed into the component and then, you would use is derived state to basically, decorate information that comes with the props, so you could present it in your component. This pattern is very nice. This pattern is being used to build LinkedIn, to build applications at Apple. There are huge implications being built by Ember community using this patterns and I'm sure something similar has happening now with Vue but this pattern doesn't really exist in React in the same way.

You might opt in to start using this pattern if you start using [inaudible] but it's not quite the same. Writing computer properties in Ember and in Vue is essentially free because it's so effortless, where in React, if you're using [inaudible] to create cache computer properties and memorize computer properties, you are really opting into doing a particular way of computing this properties and writing selectors that's not trivial. I think that's one thing that is available in Vue and Ember and it's a really effective pattern and you can do it in React but it's actually not possible in Angular, unless you're using, I'm guessing something like ngrx, where you can do similar things to what you would do if with redux in React.

Creating derived state that you can consume in your component is one of the things that is possible but it's not possible consistently across all frameworks. That's just one of the things.

CHARLES: I agree. I think that was one of the things that drew me to Ember at first coming from Backbone as I did and honestly, from the models in Java was that, in order to compute anything, you had to install a listener and then eagerly make that computation and store it somewhere, where as those frameworks, it made you feel effortless where you can just decorate some state and derive it and the information is there, the computation is there when you need to reach for it but you don't have to do expend any extra effort aside from say, "This state is derived off this other state."

I think another case that I came across was immutability. Immutability is a means but the end is to have consistency inside your application. I first really started running up against this when I was working with forms and since then, I've realized that actually, a lot of the pain that I was feeling was because things were not being immutable but this is where the fact that things weren't immutable ended up causing me a lot of pain and headaches and I was having the code into being a lot more complex.

Essentially, when I wanted to make something transactional if you're editing a form or something like that, then you need to essentially store off a copy of your current state. If you're editing some object, I want to say, open up a dialogue and I'm going to edit it and then I'm going to commit the changes back to that dialogue. What I'm modeling there is a transaction so I kind of need to shave off a copy or make a Xerox copy of the object and then make the changes inside to that object and then somehow, try and merge those changes upstream and then, get them back into the main lines. Really, like a very Git-like operation.

It wasn't just at the object level. When you're doing things like dirty checking, you need to make what is the original value of a field versus what does the input currently have. I might be doing any number of transformations in between the actual physical representation of the field, maybe it's a date but the user interacts with it in as a string, so there has to be this kind of parsing serialize thing sitting in between that value and you need to basically, keep a copy of that field as a mini transaction within your macro transaction because you want to say like, "Is it dirty? is it really the same object?" because if you can just do an object comparison, you have to get into all that hairy like equality checking and it gets really complex really fast but it turns out that a very clean solution to this is if you just never actually make the changes in place and whenever you are making changes, you're generating new information without destroying the old information because when a form is the case where we really come up against this, where we're modeling the same object over time, so a form explicitly models the change of an object.

Change is part of what it is and so, the definition of change is being able to compare something in its prior state to be able to compare it to its current state. If you're making that change by destroying the prior state, then you're going to run into a lot of trouble. It just turns out that when you're working with forms and it turns out there are a lot of use cases like this but this was the one where I first really just couldn't even... Without immutability, you want to model your change as always rolling forward and not ever destroying prior states but being able to pick and choose and can always be able to look back to where you were and compare where you are now to where you were.

That's where immutability comes when you're modeling change. It's actually much easier to model change when you have explicit states that represents what was and what is. But when you start doing that, then things get a little bit messy. You have to do the compromise. There's a tradeoff, like when I say, "Set this property on this object," that is easy and that's something that I think that we can all understand. We're not idiots. That's why immutable models are very conceptually easy to grasp, to wrap your head around.

If I'm modeling myself and I'm saying, "Set hand position two feet up in the air and now I'm raising my hand." That's easy to understand and it turns out that when you're changing a data structure immutably, then you have to, for example model a simple set operation as duplicate and swap. Or if say like you're swapping out one property in an array, you actually model that as a map, where you swap out the one element at that index, rather than just saying, "Just set the thing at that index," or if I'm changing a property of an object, I want to copy over all the fields except for that one which I'm going to change. If you start to do that then, you realize the benefit of always being able to look backwards but you've now introduced overhead and complexity in your code, so you've made a tradeoff. I think that's a lot of people look at saying, "I want this to be immutable," then they actually have to come to the grips with the complexity that's going to introduce.

There are libraries like Immutable.js that do make that a lot better but even they have the problems. I can talk about those but one of the cases is like being able to reason about a series of states for your object, rather than just only having one copy of it ever and being stuck with having to deal with it as it is.

DAVID: Yeah and I think that really important too is being able to mentally track where you've been because in my experience on other large Ember applications, I've run into so many different bugs that I could really track down to people or rather, places in the code where things are just reaching in and mutating your model, where it wouldn't make sense, so as you're writing your code, you're in a completely different state than you might have expected.

CHARLES: Yes and it's easy, right? But essentially, when you have some model, you've basically got a global object. There's a lot of recomputations that needs to happen when those things change. As a result, if you look at the actual code that supports computer properties in Ember and I'm sure other frameworks as well, some of the most hairy and complex. If you look at the chain watchers and the chain nodes and all the stuff that's required to support things like computer properties, it's amazing that it works as well as it does. I've tried to actually open that up and understand that code on a number of occasions and every single time, I had to walk away in defeat.

TARAS: This problem exists in React applications and Angular applications because if you think of the challenges of working with set state, I think one of the problems with working with set state in React is that your complexity increases very quickly. It starts off kind of simple when you're using immutability with set state in React. They're kind of very light and then, as you start to add features, your complexity starts to grow very quickly in a way that you really start to run into limitations. You start to confront your personal limitations of your abilities to work with immutability, so you're limited to doing immutable structures that only a few levels deep because your ability to use destructuring to create new immutable object is limited by expressiveness of JavaScript. It's gotten a lot better with the destructuring but if you do it a few levels deep, I think everybody's familiar with what happens. It starts to get really hairy. You kind of loose track of where you are.

CHARLES: Yeah. The signal-to-noise ratio increases because after probably, two or three levels, the majority of your code has to do with destructuring and restructuring and very little of the actual change that you want to make.

TARAS: And this is kind of interesting because people talk about declarativeness versus imperativeness but at certain point when you have a complex immutable state change, if you're doing with destructuring your code, even though it looks declarative but there is so much processing that you're doing, it's actually kind of losing the benefit of its declarativeness. It's actually starts to look more like imperative code than it does what you would expect a declarative system to look like.

I think this touches on the other aspect. It kind of compromise that when you work immutably, when it compromises, you make a serialization. Your ability to represent your state as a POJO becomes restricted by the fact that you have this complex system that's wired together and you have systems like zones in Angular and in Ember Object that are able to keep track of changes in these objects but you don't have a way to restore those objects. You don't have a way to do more sophisticated things that you might want to do, especially in situations where if a service feeding you, what do UIs going to look like. In that situation, it's really helpful to be able to say, "Here's a POJO that I got from the server. I'm going to use this POJO to build this component tree that the user is going to interact with and then, as the user interacts with it, I'm going to then, capture that state, serialize it and put it back in the server."

When you're using something like Ember Object or if you're doing this kind of stuff in Angular or even if you're doing this stuff with React but without using something like redux, you essentially end up doing so much wiring to accomplish that. By the time you finished writing your application, you've written a ton of code just to handle this particular use case and if you have to do this again in another application, you just rewritten that kind of code in a new application as well.

CHARLES: It reminds me of the concept of a Smalltalk image, like there's no way to really get at the state of a Smalltalk thing. It's almost like you're dealing in docker containers and not actually being able to write that state down into JSON or something like that.

I'm trying to casting about for an appropriate analogy. Maybe that's not a good one but what's actually happening cannot be made orthogonal. It can only exist in that one run time that you're currently running. If something wrong manifests itself, reproducing it can be extraordinarily difficult, right?

TARAS: Yeah.

CHARLES: Imagine if there's some render cycle that's making a bunch of mutations and there's this process that you stood up and it runs in completion, some signal comes in and those effects are like ripple through the system, there's no way at any point to have any other representation of that system than the running system itself.

TARAS: There's another element to this, which I find really interesting. When you're thinking about how to architect complex UIs, it's actually helpful to get really clear about what kind of changes are happening. A lot of times when I want to see beginners are writing, especially if you task someone who is a fairly junior at building a single page applications, a lot of times what will happen is because they don't have a clear mental model of what is going on in regards to state. They end up setting a lot of properties. Every operation, every time you have an event handler because they don't have a clear model of what's going on, they end up setting like five or six or seven properties.

That kind of signals that they don't have a clear picture but what that also does is a lot of times, they usually comes together with cascading state changes. Usually they're not representing a single operation as a single state change because there might actually be a bunch of things that are happening because what they're doing is they're massaging the system into submission. Not like they're not in control of the state transitions, so they use, essentially time and their dedication to kind of sort it out and make it work and eventually, would that ends up looking like that if it works for most of the cases that they are able to test for or that they able to manually see. But then they AR, not accounting for problems that they're not able to understand right now, they become discovered by users when users start to interact with the system and with the components or with that application and the application is there to get into some funky states.

The tools that we have, they don't prevent that from happening. They just --

CHARLES: Right. They don't force you. I think what you're saying is that ideally, you want to model your UI as a set of transactions on your state, that you want transactionality to your state so that I basically am saying, "I'm not going around and setting seven properties in reaction to this one event." I'm saying, "This event triggers this transaction and that transaction clearly bundles up every single operation that needs to happen and the tools don't enforce that." Is that a fair --?

TARAS: Yeah and then, the problem is we're working with component trees. You start off with having a set of requirements and over time, the requirements change. As the business unit understands your application better, they give you more direction of how accounting should work and then you find out that there's more interconnect at stake but then what's happening now is that the cost of refactoring those state that spread throughout the components, whether that be with set state, whether that be with the actions in Ember or even in Angular.

What you end up doing is you start to change the system but change is not trivial because the actual process of changing where that state lives is not linear. It depends on the complexity of the code that you wrote and it just gets really hairy very quickly. That's where companies end up losing a lot of time. A developer could start off with a requirement, you build something and then a new requirement comes in and instead of it being a simple change, it turns into a week or two weeks refactor because you now understand the state ownership should be different. The state that you have should be in a different place. You have to manually make that change. You have no obstruction to help you express that in an easy way.

CHARLES: Another thing, because we are doing a kind of a roundup of all the things that you need to account for when you actually embark on managing your state. Another is actually constraining the amount of computation that happens. If your system is based on listeners and large chain reactions of things where it's like, "This property changes so I need to notify these other 10 dependent properties that change." You can do a lot of unnecessary computation, especially if nobody is going to render.

That's kind of the thing that you have to do if you're going to be immutable. You have to eagerly walk those change to see which objects are affected so that you can then invalidate those caches. A system like Ember Object, I don't know exactly how Vue works, it mitigates this somewhat by the fact that the computer properties are lazy but you still have to walk all of those chains. That can actually get out of hand. They're eager, not lazy.

Then the other concern that you have, where you normally have to make a trade off around is around composability. One of the things that's really nice about immutable systems is they're very composable. If I've got some object that does one thing, I can then just set that object onto another object just by mutating one of its properties and I've effectively composed them.

I can then install listeners onto that thing or I can compute properties off of that property and they can post pretty well. That's something that you get but then of course, you're losing all of the benefits of immutability, so things like Immutable.js don't really compose very well or redux doesn’t really compose very well. The concept of taking a redux store and embedding it into another redux store, you just don't see that. I would never distribute and I think ultimately, the litmus test there is would I be able to share it on something like npm. Nobody shares an npm package that's just a redux store that you can dispatch actions to and observe and use it with your other redux stores.

When it comes to a system like Immutable.js, that does make transitions a little bit easier over lists and arrays and maps but you still run into the exact same set of problems that you have when you have lists of maps of records and you don't really get any help there, so you have to make this tradeoff between immutability and composability, whereas a system like MobX or Ember object actually quite composable.

Before we start talking about microstates, I want to say that you just throw those in there because there is just a lot of concerns out there, a lot of edge cases that actually build up but through the course of a real application, you will encounter them all. You might be making tradeoffs at the beginning that you're not realizing that you're going to need or are going to get you into trouble later on.

DAVID: This actually happens in the Angular community as well because there's something really great that's happening with observables in the Angular community. I think everyone's embracing them wholeheartedly and I think that's really been pretty great to see but observable streams of composable, but objects that have on them observable stream providers of some kind, like if you have something that you can subscribe to and that is part of a property in a class, composing multiple classes together and consuming properties from those classes, there is no mechanism for composing that. That kind of composition has to be done manually.

Again, you're kind of manually wiring together a bunch of objects and the big challenge is that you are manually subscribing to all those streams and unlike what you have with components. Components have lifecycle hooks. When your components is being torn down, you know you can perform some operations. If you need to remove an event listener, you have a hook where you can do that when you have a class instances like JavaScript class instances that have on them properties that have observables that you subscribe to. There are no tear down hooks for class instances, so there are no obstructions from managing unsubscribing from those streams.

You essentially end up having the foundation that you can use to build complex reactive systems and you can subscribe in there really fast but wiring those things together at a bigger scale is simply not there. It's something that you have to create and enforce yourself.

CHARLES: Right and I think that's probably a perfect segue into talking about microstates, which is the project that we've been alluding to for the past 30 minutes, that is I think in attempts to solve these problems and make sure that you don't actually have to compromise on those things, so you can reason about things locally but have those things be composed into a greater state. But also have them be immutable so that you can look at past states and reason over a data structure over time as opposed to just in one instance.

Also, have an intuitive interface that when you're making these changes, doesn't look like half of your code is unpacking some data structure, flipping some bit in it and then repackaging it back up again. That's the context. Should we start talking about what microstates is and how it addresses those?

TARAS: That's a good next step and when I start working in the ReadMe, I end up actually, I think I wrote about 40 pages. One thing that's interesting about microstates is that and this was part of the design of microstates from the work that we've done is that we intentionally wanted to make the number of ideas that you haven't microstates very little, so when you use microstates, the number of concepts that you need to remember in your mind is very few.

It is a conceptually a different way of thinking about organizing your state in the same way that shifting from managing DOM elements directly to having an obstruction like component that declaratively applies changes to your DOM tree. In a same way, microstates is kind of an abstraction that allows you to declaratively describe how your state will change and it will manage the transitions for you and allows you to give the state transitions names and it allows you to give your states names as well, so you can actually name things. You don't get a POJO that has a shape but has no name. You actually get to give things names.

CHARLES: So, why don't we start? I have a list in my mind. I should probably write it down of the things that we just talked about but I think the things that we talked about are ease of representation, like conceptually easy, transactional, basically serializable and immutable, lazy and composable. Those are like five or six things. But I think there are kind of aligning principle around which we gathers that the state management should feel easy. It should feel fun.

One of the things that is awesome about working with components, whether you're using web components or React components or Ember components is when you get it right, you're just snapping these things to feel together and it feels great. It's like I'm just passing properties and render blocks down the tree and the framework is just doing all of the grunt work for me and I'm just operating at a very high level. That's what organizing principle with microstates as it needs to feel easy. Maybe we should start there and just say, how does that easy and fun line up with each one of those kind of unique problems around which we typically have to make tradeoffs? We could start with the interface of making a change.

TARAS: I'll go back to the starting point. I remember what got me first interested in microstates is Charles, when you said that, when you have a number, there are certain operations that a number can do. We really don't need to be writing an increment operation for every... Like if you a have a number, you can increment it and decrement it.

CHARLES: Honestly, every time I see state management tutorial and they tell you how to increment and decrement a number with it and you write the increment code and you track the thing and you store it back into the store, at this point I'm still annoyed with those tutorials because I'm like, "It's a number. We know we can increment it. Just show me where to plug in the code. I should not have to be writing an increment method."

TARAS: Yes. And that's the kind of starting point. There are certain operations that you can perform with the primitive types. If you need to add a number or if you increment a number, we already know how to increment the number. It's part of microstates. But that in itself is nice but that's not that important. I think what's really important is that when you need to put a number into another data structure, let's say you have a nap and you're like, "I need to..." I don't know --

CHARLES: Let's say, like a click tracker that has a number of clicks.

TARAS: Right. By itself, you can increment the click tracker but if you need to put a quick tracker into another app, essentially you can compose it in and you don't need to figure out how to wire the actual mechanism of how to make sure that you can update the property, like it's part of another class, for example, you don't need the way you would increment the number. When it's a part of another class versus how you would do it when you're working with it by itself is an approximately the same. The amount of work that you need to do to actually perform that operation is the same. Your complexity doesn't increase as you compose one data structure into another.

CHARLES: Right. You can just say, "This is an app. It's got a click tracker and this property is a click tracker and I have to do nothing else. I can register clicks on that thing. It doesn't increase the complexity of application at all."

TARAS: There's no wiring. Now, you added some new state, that state is very explicit and it's really clear that it is not impacting other parts of the state. You can operate with this thing. If you change it, it's going to work properly with all the other things that are in the type that you are adding this counter to. Those things are just going to fit well together and it's not going to break if you need to transition one more thing. All of the other transitions will work the same way. I think that kind of consistency is really meaningful, over time especially when you start to increase the amount of state that you manage in your application.

CHARLES: Just the ability to work with types and just have kind of those implicit operations and have those things compose, kind of indefinitely. Moving down, we talked about easy and the other thing I would put on that is that the way in which you express those transitions, for example if microstates comes bundled with numbers and Booleans and strings and arrays and objects and kind of the stable of types that you would expect in any JavaScript application but those types are expressed using this way for expressing types, essentially.

When you actually do make a transition, it feels very object-oriented, I would say, even though it's not. It feels like you're mutating but you're actually doing a transition. Does that make sense?

TARAS: I think for anyone who is familiar with what it's like to write queries for GraphQL, if you're not familiar with it, it's fine. You can get a sense of that from microstates but if you're familiar with the ease of just writing a query and if your backend knows how to retrieve the data, then your queries will just give you the data that you want. That feeling is really powerful and just being able to write the query and just gives you what you want. Microstates is kind of like that. Actually, the inspiration came from experiences with GraphQL, which is that sense of ease is what we wanted to have in microstates and so you get that seems sense of like, "I can just do what I want and it just going to work and with this other thing and it just going to work," and you're just like flying through, like adding states to your application and it's just working for you and working for you and working for you and you don't have to do monkey work like gluing things together. It'll change how you are working before because you have a way of opt working with these things at a higher level.

CHARLES: Right. Let’s talk about transactionally or should we talk about immutability? How does this make immutability easy and fun?

TARAS: I think one thing is that you don't have to write reducers and you don't have to do destructuring by hand. I think you have a way of expressing. Thinking about this, if you have a component tree and let's say you have redux and then a bunch of components like your parent component, your root component has some state using sets date and then components further down the tree also have state. You could actually express that as a microstate.

What you would do is, essentially the parent component state would be the root and then the children's component states would be composed into it. The nice things about doing that is that at the root level, you have access to transition state of the children declaratively. You know where the states for those children is on the route type and you can write transitions that are going to declaratively perform multiple operations on the children state and I suppose it'll restructure to what happens with components but if you don't use this, you might have multiple sets date operations.

The process of wiring data from the root down to the children is kind of complicated, where here, you have a way to represent that and perform a lot of transitions in the way that is going to be just easy at whatever level you need to operate at.

CHARLES: Right. I think, for people familiar with redux, in redux you act globally and then you react locally, if that makes sense, so you dispatch an action to the entire store and every single reducer can see that action. There's ways to manage that but effectively, you have this one atom and then you have the reducers that kind of act on local state, whereas with microstates, you're basically acting locally. You're reacting locally but the effect is global.

TARAS: You're participating globally.

CHARLES: Yeah, participating globally but you never have to consider the context that is above your own, so you never have to be mindful or cognizant of the context in which you're enclosed because from your perspective, it just doesn't exist.

DAVID: Every microstate has a set transition which is the basic transition that you can invoke, essentially in any type, so what's interesting is that it's amazing how powerful --

CHARLES: So, we should break it down really simple. Basically, when you create a microstate, with a type, you say like, "I want to create a number with the value five," and then I can just say, "That returns a microstate," and I can say, "microstate.set 10," and that will return a new microstate who's also a number but the value is 10 and that's available on all microstates.

DAVID: Yes. If you have a tree of components and your state is presented by a microstate at the root level, then what you can do is you can invoke the transitions on any part of the microstate and it will just know how to properly create the next microstate for you. The example that Charles you gave of one number so that number can be inside of a class that represents state for a particular component and then that can be a part of another class or represents a state for another component but then, when you invoke a transition on one of the leaf nodes, an equal sets state on one of the leaf nodes or equal set on one leaf nodes, it will respond locally but it will actually reflect the changes globally. At the root level you're going to get a new object that causes the components to update.

CHARLES: You know what? I have another concern that actually just popped into my head, which is something that I've certainly struggled with in every single application of notable complexity is stability of value. We should put that on the list. We're almost out of time to talk about this. We spend too much time... Well, not too much time, of the issues of state management, which I think you can't spend enough time talking about but I did want to pile one more on there is when you're making that transition, where you're acting locally but you're participating globally.

For things that are unaffected by your action, remain unchanged. That is a super power. It's actually very hard to do with a lot of state management, especially when you're cloning a bunch of stuff, being very judicious about what you don't want to clone. Where this really comes into play is if I want to re-render something. A lot of times you have to jump through a bunch of hoops to tell, did my model really change or did only referentially change? With microstates, when you make that local change, if you're embedded in a very large graph of objects, obviously all of the objects above you are going to be changed but what about things that are off to the side of your siblings. They're outside of that scope of that change. They shouldn't be cloned. They shouldn't be copied over. They should remain the same.

If you're doing a re-rendering based on the changes that are happening, that's going to be a key feature because you're not going to have to write, basically any hooks to say, should I have to re-render my component. You can always rely on triple equals.

DAVID: This quality is going to describe the structural sharing and some of the other tools that are available but I think that's how it's accomplished. I think one thing that's a little bit different with microstates is that when it comes to structural sharing, it's not that difficult to do if you just do structural sharing and value. Meaning that you can do structural sharing on a value using something like lenses and not a lot of people are familiar with lenses in JavaScript but it's actually only three functions that you can use and it can give structural sharing on complex POJOs. It's pretty easy to use relative to how little people know about it but what that doesn't do is it doesn't allow you to graph of objects that have their own operation that you can invoke and that will perform structural sharing. That part, I know that is not available in any solution, I think at the level of completeness and luxury that microstate provides when you write things.

CHARLES: Right because every piece of the tree kind of comes bundled with its own things that you can do with it.

DAVID: I don't think you should jam everything into this podcast because there's a lot to talk about it. I think one of the things and we've talked about this a lot, which what we want to do is create an implementation for an idea of what it would look like. What would it be like if we had a composable state primitive that we could use to describe state and share state solutions in the same way that we share components like react-virtualized or whatever your particular frameworks or popular component may be. What it would look like if we had solutions to state problems that we could share and we could --

CHARLES: I think the litmus test of an awesome solution is like you look at this current crop of MVC frameworks and what's so awesome about it is they're sharing. That can happen, right? If I'm writing a React component, I can publish it on npm and other people can use it. If I have an Ember add-on, I can publish it and people can use it. They can consume those components. That's awesome and I think it's the hallmark of a great system.

What would it look like if I wrote just the state piece of a file upload and I could publish it npm and then anybody, in any framework, could actually use it with their framework without paying any penalty. What would it look like if there was some transactional data store that could be built and shared and the hooks into any framework were minimal. The possibilities are really exciting around that idea, whether it is realizes microstates or not. But clearly, we feel this is something you should be able to do.

DAVID: I'll add one more use kind of use case that I personally find really motivating is that there's a lot of companies that are investing into building single page applications and a lot of times, what you see happening is they're building a very similar application to what they had before because their business hasn't changed. The technology has moved on so solutions have improved. The demands for better user experience have increased but the actual business and how the things that people have to do on day to day within their company hasn't changed.

What we're seeing right now is we're seeing the same, like whatever was written before in jQuery or an AngularJS is now being rewritten in React or Angular or whatever you might Choose. But whatever you like to see is it has a situation where the domain specific logic of your business is represented as a data structure that knows how to, potentially, in the future talk to the server and retrieve data from the API because that's likely not going to change.

But you can use that like that's been tested and published as an npm module within your enterprise and then you can then consumed that in any framework and it's actually easier to do it this way, than to implement it in a framework-specific version of their state management. That's the part that I find the most exciting.

I think one of the things, just to connect to the goal is that, we would like to keep this conversation going. If you're interested and I think this is a kind of a call to our audience that if you're interested in this, we would love to have in our podcast to talk about these things because I think there's a lot of things that microstates really is a beginning of a conversation. It's not meant to be a statement. It's meant to be a proposal that we can just talk about this.

CHARLES: I agree and that's one of the reasons we're keeping it very small at this point. The core library of microstates is not setting out to accomplish too much. In the core library, there aren't even any side effects. It's actually impossible to have side effects. It means that it cannot be used for anything except for the model but that's very liberating and it let us focus on what would a system like this actually look like.

DAVID: It's really exciting because this has been the biggest metric but we have microstates in the JavaScript weekly and that was great and then it got circled around when people know and it's like 800 stars now, which is not a really big deal. It's funny because somebody commented like, "How can you put something in production that only had 100 stars?"

CHARLES: I think it's just important to realize that this really is the beginning of a conversation. There's a really exciting set of things to come. We haven't even talked about how we're going to model side effects, although we're going to use microstates to do it. We haven't even talked about what the various framework integrations will look like and what are the best practices for using this to organize state in your application. We've had some lively discussions internally about what that looks like. There's still a lot of questions but it's going to be a really, really exciting and edifying experience to get to answer them.

DAVID: Yeah, it's pretty exciting. I'm excited too. There's been a lot of interest from people in microstates, so it's going to really great. I'm looking forward to meeting people and having conversations about how we can use microstates because I'd love to have someone create a really great solution that I could just take off the shelf and just use and not have to implement them myself.

CHARLES: All right. Well, I think we could talk about microstates for at least the next three hours but we have to give everybody an opportunity to, at least like go to the bathroom or something. Microstates will return but if you're interested in learning more about microstates and you happen to be in one of the many places on which we’re going to be presenting on microstates in the future, who knows? Maybe you can come in and join the conversation in person.

Taras is going to be speaking at Toronto.js on July 30th. He's also going to be presenting at Manhattan.js on August 8th and then, yours truly will be presenting on microstates at React.js Austin on the 6th of August. Come out and see us. We'll drop those in the show notes and it's guaranteed to be a good time and we'll have that conversation.

Until then, we are the Frontside. We lead with the why, the how and then the what, if you're interested in working with us and that helps us that we guarantee the lowest total cost of ownership for your application. We're always looking for feedback. If you have news items that you'd like to see at the head of the show or just any feedback or questions, we would be happy to answer them.

Thanks today to Mandy Moore for producing our show and next time, we'll be talking with Kristian Freeman about what it's like to run an online conference with Twitch, so I'll be looking forward to that. Bye David. Bye Taras.

DAVID: Yeah, thanks for having us.


CHARLES: Yup, and bye everybody. See you next time.

Next Time:

Running An Online-Only, Free Conference on Twitch with Kristian Freeman

Jul 20 2018



Rank #2: 103: React Components with Michael Jackson

Podcast cover
Read more

In this episode, Michael Jackson of React Training and Rob DeLuca and Taras Mankovski of The Frontside talk about what is a component, and what a component is specifically in the context of React.

They also discuss when it stops being a component and becomes something larger, how it has changed the way we develop UI, and thoughts on container and presentational components being synonyms for controller and view.


Do you have opinions on this show? Want to hear about a specific topic in the future? Reach out to us at or on Twitter at @thefrontside.

This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC.


ROBERT: Hello, everyone. Welcome to Episode 103 of The Frontside Podcast. I'm Robert DeLuca, a developer here at the Frontside and I'll be today's episode host. We're going to be discussing what is a React component or what is a component with Michael Jackson. I'm pretty excited about this topic, a sort of off from a tweet that I sent out after a long workday, when it is something being called "component" because it was built with React components but it was more like a mini application? Then Michael replied to my tweet, as they're happening and he said, "What is your definition of a component?" which is exactly what we're going to be discussing today. I thought that was a really great question.

With me, as a co-host is Taras Mankovski.

TARAS: Hello, hello. I'm also a developer at Frontside.

ROBERT: Before we get into the discussion, I would like to make a little announcement. We've been working on building a suite of testing tools to make acceptance testing JavaScript apps like React or Vue or Ember or anything else kind of JavaScript, fast and easy to maintain over the past few months. We call it BigTest. If you follow me on Twitter, I'm kind of loud about it. I love this project that we were working and one of my coworkers just published a blog post, giving an introduction to acceptance testing on React applications with BigTest. If that sounds interesting to you, you should check it out. We'll leave a link in the show notes. Now, let's jump right into it.

Hi, Michael. How are you doing?

MICHAEL: Hi Robert, I'm doing well. Thank you for inviting me to be on the podcast.

ROBERT: Oh, no. Thank you for joining. I feel like this going to be really fun conversation. We went back and forth on Twitter a little bit and I was like, "You know what? This serves really well like a free flowing conversation."

MICHAEL: Yeah, it's something I really like to talk about, specifically, when we're talking about components or when we're talking about React components. I think there's a lot stuff there to discuss and I think that React, specifically has really, at least defined that word for me. When you were talking about your mini application, I was like, "Oh, yeah. That's cool," and to me, that's kind of what these components have the potential to be, what these React components have the potential to be. It's kind of like almost these miniature applications that you stitched together to make a bigger one.

ROBERT: Yeah, that's really cool. I was frustrated at the end of that day, just because that had so much logic crammed into it and you can kind of see that come through in the tweet but I'm not going to lie. After I sent that tweet, I was a little disappointed with myself because it came off a little bit like flangy but I guess we could just kind of jump right into defining what is a component.

MICHAEL: When I saw your tweet, I was like, "Oh, you know like --" and of course, I don't know the component that you're looking at. It could have been terrible. Totally, it could have been terrible. I'm totally willing to believe that it was not a good component. But writing React is hard, especially writing good React is actually hard. At first, I thought it was easy but I think it's easy to solve your immediate problems but to write React to that is generic enough to solve lots of different problems, I think it's actually very, very hard and it's something that I've spent the last couple years learning. Anyway, that's kind of a tangent.

But regardless of the component that you were looking at, the way that I've tend to think about these components is we used to have a model for thinking about how to build frontend applications --


MICHAEL: MVC, that's the one. That's the one that talking about. You have, here's your model, here's your view, here's your controller. You know, there are separate logical entities and lots of times, those even live in separate files on the file system and we keep them sort of separate and spaced out. As far as I can tell, that's a sort of paradigm. I learned it in school. By the time universities catch up with industry is at least, like twenty years, so it's probably something that was invented back in the 60s or 70s.

ROBERT: I think it was like the 80s because Charles talks about it a lot and sort of Taras, actually because we're building something that's like a composable model, just like the Vue of React is a composable view, its components. I think it's interesting because I was listening to the Changelog Podcast and it sounds like you worked with Ember for a while.

MICHAEL: I did, yeah.

ROBERT: I forget, which podcast that was but we can find it and we'll link it to the show notes but I thought that was really interesting that you also came... Oh, maybe not came from Ember. You had experience with for, at least a couple years and that's where I came from. That's kind of where that tweet came from and was like, "Man, I don't like what happened to the word component," because when I think of component, it's like something that is encapsulated in a small piece of UI. But I'm okay with letting go of that.

MICHAEL: Well, yes. Ember came out of something called SproutCore, which actually originated at Apple. Tom Dale used to be a developer at Apple. I'm sure you all know all of this but just for some sort of back story for others who might not. Apple was a place where MVC was really, really big. The whole Cocoa frameworks. They're all very much like, here's your controller, here's your view, core data has all of your models, that kind of thing.

It's a software development philosophy that goes back a long time and has deep roots and I'm not here to suggest that because it's old it's bad, because lots of old things are actually very, very nice and good, especially in programming. We're starting to see a resurgence of functional programming ideas, for example, which have been around forever, since at least, the 60s or even earlier than that. It's not necessarily that I think that because it's old, that it's bad. I don't.

ROBERT: Right, right.

MICHAEL: But the thing that I do see in these React components is they kind of go very much against the grain. If you had, for example your model, your view and your controller as these vertical silos, just imagine turning that whole thing on its side and then cutting a slices of that, so that each of your React components has elements of MVC in it. They're all sort of mixed together.

I run a training company called React Training and whenever I'm doing one of my training workshops, the way that I talk about it is a component is able to encapsulate three things: markup, which is the view essentially; state, which is essentially your data or your model; and behavior, which is essentially the controller, so what happens when the user is interacting with the view and clicking on the buttons? What do we do in response to the user input? You’ve got all three of those MVC elements in the React component.

In fact, I've been meaning to kind of coin the term for a while. Instead of MVC, I call it MSB -- markup, state and behavior.

ROBERT: You heard it here first.

MICHAEL: That's right, here on The Frontside Podcast, we're coining new terms.

ROBERT: That's pretty great. I guess coining off of that, is it fair to say that MVC kind of still lives on, except it's now in React? Or it's kind of more sliced up into smaller, more digestible pieces? We can always come back to this composability element, right? Would you say like really React would made it possible to compose many little MVC apps?

MICHAEL: Yeah, exactly. The thing that people really, really love about MVC, I think you still have it in React. MVC, the thing that people always come back to is the separation of concerns. Let's just say, "I don't want everything sort of mingled together. I want it to be very clear. What is my model? What is my controller? And what is my view?"

The cool thing about a React component is if you look at it, you still have very clear separation within the single component. You have a very clear separation of all three of those concerns: your state lives in an object called 'this.state,' then your view is whatever you return from your render method. That's in a completely separate spot, since still in the same component and then your behavior or your controller usually has its own method, so you can inline those in your render method or you can pull them out if this is how you'd like to do it. You can pull them out into instance methods. You can still have kind of that separation of the concerns within a single component.

I think to your point, the React component model is all about composition, so this is kind of a term that we've actually adopted in other areas in technology. It's sort of just coming to frontend. The idea is you've probably heard of a service-oriented architecture for design in backend systems. These servers over here are application servers, these are database servers, here's our caching tier, here's our Ingress or LoadBalancer and maybe, you stitch them all together on the backend into one coherent system. You know, here's our storage and our image-resizing services. You stitch them all together on the backend into one coherent system but it benefits you to not build them all as one part of sort of monolith.

We've got a lot of benefits from the decoupling. For one, if one piece of the system fails, the whole thing doesn't go down, so you can like swap it out or upgrade it and replace it with something else. I feel like that is kind of a similar idea to what is going on the frontend with these React components.

ROBERT: Oh, microservice components.

MICHAEL: Yeah, exactly. Each component is kind of like you said. It could be like a miniature application and it could be totally self-sufficient and I could drop it onto a page and it could just do its own thing or what I could do is I could take that app, that component and I could drop it into a larger app that can speak to it and can communicate state to it via the props that it sees and then can get state back out of it via these callbacks. I kind of view it as like all of these miniature systems that they can either be completely encapsulated and self-governing on their own or you can take them and compose them with a larger app.

ROBERT: That's really interesting. I guess what is a component specifically in the context of a React. I guess, we kind of just answered that, that you can bundle all these things together, right? Does that make sense?

MICHAEL: Yeah. The beautiful thing about this composition model is you can have all three of those things in the same component: markup, state and behavior. You can have all three of them right there, encapsulated in one component or once you discover more advanced patterns with React, you can actually make it so that a component only has two of the three or one of the three.

ROBERT: And then it kind of like passes callbacks or props or state around?

MICHAEL: Exactly. It can essentially delegate the responsibilities for handling the other pieces that it misses to other components around it. There's a pattern that I kind of coined last year called render props.

ROBERT: Oh, yes. I remember hearing this on Changelog Podcast. I was actually one of the people that at first thought it literally was a prop name render.

MICHAEL: Well, I mean it's not a bad way to think about it. It could be a prop name render.

ROBERT: But then I found out it actually is a prop that you send JSX too and render whatever is there.

MICHAEL: Yeah, exactly, a prop that you used to render stuff. It's the way that I describe it. When you think about it, any component, for example that accepts a render prop is really just delegating it's rendering to some other function. It can contain the two pieces: the state and the behavior, but then it can sort of delegate this third piece, which is the markup and say, "You know what? I don't really care about, specifically what I have to render." I don't have an opinion about that. You just give me a function and I'll give you my state and possibly, some behavior callbacks and then you can tell me what to render. I'm like a component that I have two of those three pieces. I don't have the markup, you just give me a function, that I will call when I need the markup.

ROBERT: That's really powerful.

MICHAEL: Yeah, exactly. I can have all three in one place or I can also with this component model, just delegate one piece or even two pieces, using these kinds of patterns to other components, so it's really nice.

ROBERT: I'm always have to come back to this because this is where I kind of cut my teeth in the frontend world. I feel like render props are very similar to the yield pattern in Ember, where you can yield out a component and place it anywhere inside that template block. I think it's really similar. Because we have a large base of Ember developers that listen and they needed a draw like a parallel, I would say that's almost a parallel. I might be off on that. Taras, would you agree with that?

TARAS: Yeah, it's very similar. There is one little 'gotcha' with render props in React, which I think Ember deals with a little bit more gracefully. I do use React all the time now. I use it much more often than I use Ember but --


TARAS: Yeah and I'm kind of curious, Michael if you would think about this. Because there are certain things that, for example, JSX does, like one of the attributes of using render prop is that you want to pass stable functions, like something that is actually defined in init hook, so you're not necessarily recreating a new identity for this function every time that you pass into the render prop. Is that right?

I think for someone who is might not be familiar with this, it's a little bit counterintuitive because it just kind of like, you just pass something and then you later realize, "Actually, I can't really do that because now your components were rendering over and over again." I'm curious like where can we kind of innovate in that? Because in Ember world, for example, it's really safe to use render props. If you're delegating to the context to do the rendering, you can very easily pass a block of template into the component and then the component will know how to render that in a performant way.

My experience with render props in React was that the pattern in Ember is it's a very common behavior to delegate to the context of how the children of a component are rendered. This is the primary purpose of the yield in Ember and this is used by a lot of the components to provide APIs, so essentially, you're yielding, you're sending into the children function behavior that you want the developer to use while consuming your component.

The parallel with React is that you would have, essentially a function, like you have a children render prop, which is a function that receives so that when a component is rendering the children render prop, it's passing some data into that function and it's invoking the children function and it's passing to it some data and then that data is being used inside of the children render function.

Now, this mechanism works really well in Ember because Ember is using its own templating engine, so it manages every placeholder in the entire template as being passed into the component. It knows exactly what has changed in the function. Looking at that, the value just passing through component as a whole thing. It's actually managing each individual spot where the dynamic elements needs to be rendered. What that does is it allows it to manage the entire children function so you don't need to worry about stabilizing the render props. You don't need to assign them.

Because there's also other challenges that kind of arise when you have to move the actual function that you pass into children. You have to move into the body of the actual component. Your ability to compose the state that is within the render function is kind of limit because you now have kind of broken up into different places. I'm a little bit curious what are your thoughts about this? And if there's any innovation that's going to require or improvements that will require in the way that React handles render props.

ROBERT: I definitely remember seeing some tweets from you, Michael about this, like very recently.

MICHAEL: Yeah, just yesterday in fact, I was talking about this on my Twitter. First of all, thanks for the question, Taras. I appreciate it. I think you kind of nailed it with the difference between Ember and for example, just JSX -- Handlebars, really and JSX is that Handlebars is not JavaScript. Handlebars is a language of its own, really. As the implementers of that language, the Ember team or the Handlebars team has complete control over how things work.

For example, when functions are allocated. If they have a yield block, for example, that yield block does not have access to things like JavaScript Scope. It really is just a block within the templating language and so, they can decide when they're implementing that language. They can say, "We're only going to ever allocate one function for this yield block."

JSX on the other hand, it really is just sort of some syntax sugar over JavaScript, which is nice lots of times because you can use things like JavaScript functions scope. You can do things like refactor it, like you would any other piece of JavaScript and pull that function out into its own variable or something like that.

In a lot of ways, it's more flexible but with that flexibility comes this extra concern of what happens with the prop passing and it's a real concern but I don't think it's as big of a problem as most people have heard or might think it is. The real problem, the root of the problem is that if you have a pure component in React, the pure component is optimization tool in React, if you find that your component really is a pure component of just a pure function of its props and state, and that it will never render anything different, if it receives the exact same props and state, you can declare that that component is a pure component. Instead of just a regular component, it's now a pure component and so, it will actually opt out of the render cycle if it receives the exact same props and state on subsequent render. By exact same, what I mean is like identity triple --


MICHAEL: -- Same. That's an optimization tool that you can use in React to say for example, maybe I've got a component and for some reason, it's always receiving the exact same props and it's rendering a lot. I can say, "You know what, React? Don’t even waste your time re-rendering this component and doing the reconciliation around it and everything like that. If it receives the exact same props, don't even waste your time. This is a pure component. It received the same props. It's going to render the exact same stuff as it rendered last time, so it will completely opt out of the render cycle," so React won't even call the render method, won't even bother doing the reconciliation for that component or its descendants. It's actually a really, really nice way to get a little performance boost in that situation.

ROBERT: Interesting. Does that mean, rather than passing some JSX that returns out an anonymous function, you would rather have like a pure component over that?

MICHAEL: All it really means is that when you identify a place in your app where this is happening, instead of extending React component, you can extend React.PureComponent and now you component opts out of the render cycle.

ROBERT: Gotcha. Because I see a lot in React applications, it will just return some JSX out of anonymous function, kind of think, Taras was getting at, when each re-render happens, it's recreating a new function and all of it were done inside of it, from the JSX because it's just a new function that's being bound each time.

I think my takeaway from that and correct me if I'm wrong, is don't pass JSX and an anonymous function or I guess, from your tweets yesterday, that's kind of a premature optimization. Maybe, not pass as anonymous function but pass as pure component.

MICHAEL: I hadn't yet gotten to directly addressing Taras's concern but the idea is --

ROBERT: -- Jumping the gun.

MICHAEL: Yeah, it's fine. If you do have a pure component, that is when you're going to have a problem with this render prop pattern because you can't pass a render prop to a pure component. They just don't go together. Well, sorry. I should actually qualify that. You can pass around a prop to pure component but you need to make sure that it is always the exact same function, otherwise why are you making this thing a pure component, so there's a little bit of a problem there.

I actually wrote the documentation on React's website on render props and there's a little caveat section where I discuss how you could get around this, you could convert it into an instance method or something else but then the concern at this point and this is why I said it's not such a huge problem because we're getting very, very specific now. Let's assume that we've got a pure component that is the child that we want to render and it accepts a render prop and that render prop depends on state and/or some sort of scope that it needs in the render method.

Now, we've got a problem because we need to generate a new function in the render method and the fact that we're generating a new function and passing it to a pure component means that we are essentially negating all the benefits of extending pure component in the first place. First of all, in order to experience the problem, you have to get very, very specific and it's not easy to actually get into a point where the problem manifests itself.

But then for the second part, fixing the problem is actually not tricky, so the way that you would fix this issue, there's a couple of ways to fix it. The most common way, I think to fix it would be to just say that pure component, let's just move that down one level and we'll put it inside the render method of the component that takes the render prop. The component that takes the render prop is no longer pure but the pure component has dropped down one level and we can still get all of the benefits of a pure component and again, its whole descendant tree lives underneath it.

ROBERT: That make sense.

MICHAEL: So, we can still get all the benefits of having a pure component, while still being able to use the pattern. But again, just getting back to what we were saying at the beginning. The render props is just one example of an advanced pattern that actually lets you delegate one of these three pieces to somewhere else. It's just one pattern. It's not like there are others as well.

ROBERT: Yeah, so getting back to what is a component, is there ever a line that's drawn, like when does it stop becoming a component and it becomes something larger.

MICHAEL: It's actually interesting because for a long time, we didn't have a component model on the web and I think --

ROBERT: It's very true.

MICHAEL: -- still, like we mix to all three things together in our jQuery code. It was just like there was some state mixed in with some markup, mixed in with some behavior. It was all kind of mixed into one place.

ROBERT: Nice plate of spaghetti.

MICHAEL: Yeah, exactly. As soon React came along and actually gave us a real component model that really worked where we could actually identify these pieces, then all of a sudden, everything is a component and you really can make if you want, like if you really wanted to, you could make your entire application out of components. It could just even behavior stuff like, "I want to fetch some data," that could be a component or, "I want to listen to the window scroll or the window size," that could be another component. "I want to render an image or a bit of text or do some measuring or I want to do some parsing of some data or something like that," all of this stuff could be represented as components if you wanted it to.

Of course, you can still extract those functions out into their own bag of utility methods and lots of times when I write a React Apple, I have a little bag of utils and I'll go and reach in there and grab those as I need them. But for the most part, most of my React apps are just components all the way down, so there's not much that I can't do with a component. The cool thing about that is what do you get when you have components, where you get reusability and sharability. I can make a component and I can just share it with you, Robert. I could say, "You want a component for listening to the windows size? Here you go. Here's the components. Got to render --"

ROBERT: Drop it in.

MICHAEL: "-- It will give you the size when you need it," so that ability to share code is, I think super important.

ROBERT: Yeah, I think so too and it really helps you build applications rapidly because you can just start dropping these little components that are contained in composable throughout your entire app.

I guess, I'm still clinging onto like there is maybe a line that is drawn and I think from the React community, there were a couple of terms coined called the container component and the presentational component, in which I immensely mapped those to basically being synonyms for controller and view. It's like the container components is kind of like a controller, like it delegates the view... Or decorates the view, not delegates. And the presentational component is just like we're talking earlier -- pure component. It's just taking props and rendering that. Is that fair to say?

MICHAEL: Yeah. As far as I can tell, that's a pattern that was first talked about by the redux community, specifically I think Dan is the first to discuss that that pattern and it's a pattern that I think can work well. I haven't ever found it to be especially useful in my code but I can see how other people could like it for their code. I really just think it has to do with how your brain works. If you prefer structuring things like that, if you prefer like the vast majority of your components to just be these little view layers and then your main container components to hold all of the logic, I want fault you for that. I'd say, that's fine you can build your app like that.

But I do think that when you're thinking about components like that, you are thinking about the much less like these miniature applications. Basically, in my opinion it's kind of a false separation. It's a separation that doesn't really need to exist because essentially, the thing that I really love about these components is you have encapsulation. You encapsulate everything. As soon as you adopt this pattern of containers and essentially, just these presentational leaf nodes, they're not as useful on their own. They just encapsulate some of the rendering logic.

ROBERT: That's very true and they're not reusable. I mean, it's very, very hard to make those reusable.

MICHAEL: Well, yeah. Most of the time, they're designed to be used with a very specific container. It is like, "Why couldn't we just put that in a container." Like I said, I really don't fault anybody for using them. It's just not how my brain works. I tend to think more about components as if they were these miniature applications and they're going to be useful on their own for the most part.

One place where I have started to do that, the fourth thing that your components can encapsulate is style information, which is really just kind of the markup but it's the fourth thing and I think that I've really started to employ that kind of pattern when styling comes in. But it's not for this separation of containers and leaf nodes. It's just because I would like to encapsulate some of the styles down at a lower level or be able to reuse some of the styles down at a lower level, so that's when I'll typically start breaking up one of my components into multiple kind of tightly-coupled components but it's just for the sake of the styling, not really in any of the control flow or the logic.

ROBERT: Right. When I first got into doing React, I was first like a little befuddled and then, I fell in love. I was like head over heels. When I hear about separation of concerns, it's always talked about like we need to separate HTML, JavaScript and CSS. They're all different things. They just need to be separate. I understand that. I kind of come from there but for me, my personal opinion is coming from the context of single-page apps, there is no feature that you can ship without the three. I don't think there is a complete feature that exists.

Sure, there's edge cases that's like a blanket statement but I think those lines of separation is way more blurred these days and I think that's what React just unlocked. That's kind of where all of this is sort of rolling downhill and it's not a train. It's really powerful to be able to encapsulate all of those things together and then just think of your UI as these components. That's why we call them components. They componentized.

Like when I have a butt-in and I drop it on the page, I don't want to have to go and make sure that I have the right class that's wired up in some other file. I can just drop the button in there and it's going to do its thing. I can pass the props, it'll change it, that's fine. It lives within itself.

MICHAEL: Yeah, I would say you're absolutely right. You can't ship anything meaningful without having, at least some styling in there, unless you're shipping very, very basic behavioral style components. It's kind of one piece, I think like the React components are able to encapsulate their own styles but there's no, I guess officially recommended way to do it, which is where I think React get some of the critique, like some people come in and say like, "There are a million different ways to do styling in React and therefore, React is supposed to something like --" I guess, yeah, some of the other frontend frameworks have like, "This is how you do styling in our framework."

ROBERT: Right, like the lack of convention.

MICHAEL: Yeah, exactly. It's a blessing and a curse, though. If there's a lack of convention, it's harder for newcomers to know exactly what to do.

ROBERT: Yeah, or like what's best for their use case.

MICHAEL: Yeah, exactly but then on the other side, it's kind of a blessing because people are free to experiment and they don't have to feel like if they're experimenting, they're going sort of against the grain of what the community has already accepted to be the answer. I think that freedom to get out there and experiment is really valuable as well.

ROBERT: You can see but I'm nodding.

TARAS: I'm just curious what your thoughts were. This Suspense API is something that's... React kind of lead the way with components and now, the changes that are coming in with Suspense API coming in and it'd be great, if you can, are you able to explain a little bit about what it does for people that are not familiar and I'm curious what your thoughts about it.

MICHAEL: Yeah, for sure. The Suspense API, I think is actually, with regards to what we've been talking about, with the encapsulation of markup, state and behavior and possibly styles, I think the Suspense API is kind of the React teams attempt to sort of encapsulate or generalize, at least one more thing, which is asynchronous behavior.

The truth is, the most common async behavior that we know of, that most people are familiar with is a fetch, a data fetch -- you go and fetch some data. But there are others, there are things like loading of images and animations and navigation and things like that, where you have some time that passes in between when you initiate an operation and when you're actually able to render as a result of completing that operation.

How do we manage or how do we generalize that and how do we think about it? The Suspense API is basically a way to declaratively say, "I need this async operation to be done." Let's just use the example of a fetch. I need this fetch. I need to have fetched this data in order to render this view and don't even attempt to render this view, unless the data has been fetched. Before the async API or Suspense, as they're calling it, you would basically have to manage this asynchronous behavior yourself. You would basically have to say, "Go and do the fetch," and while we're doing the fetch, maybe I'll set a loading flag in my state and say, "Loading is true," and then when the fetch gets back, I'll say, "Loading is false," and then I'll render. Maybe, while loading is true, I'll show like a spinner or some loading dots or something.

What the Suspense API allows us to do or what they're hoping to do, again it's all very like... I don't know if I made this clear. It's still very, very, very, very early days for this API and I don't actually know when it'll be ready. But anyway, the idea is to be able to say --

ROBERT: Would you say the Suspense is killing the community?

MICHAEL: The suspense around suspense.

ROBERT: A terrible pun.

MICHAEL: Anyway, the API is basically just a more declarative way to indicate where this asynchronous stuff is happening and give React sort of clues, if you will, to say, "There's some asynchronous stuff happening here, just so you know." That has many applications in the real world.

Let's say for example, you were navigating in a master detail view and you're tapping down the master view and loading these detail views, if you tap a master view and you haven't yet loaded the information for the detail view, instead of sliding to the detail and showing the data still loading there in the detail view, you might want to show some sort of loading indicator while you're still in the master view. Then, if it's taking a while to load, they can actually select something else from the master view and in that case, you would cancel the old fetch and start another fetch. It's just supposed to make things like that, kind of feel a little bit more fluid and a little bit more intuitive to the programmer, so you don't have to think so hard about managing a lot of that complexity in your own head.

ROBERT: Yeah. By the way, I love the mobile first language that you used. You tapped here, you tapped here, that slides in.

MICHAEL: Yeah, for sure. It's all we're building these days.

ROBERT: Yeah, it's very true.

TARAS: It's interesting because the Suspense API, you wouldn't really imagine it to be within the scope of a view in a traditional sense, to [inaudible] but considering the scope of a component in React, it makes sense but I think people might not imagine as being something that would become part of core, potentially in React. I'm curious like what do you think other areas of React and I'm glad that the scope of components in React is so broad because it kind of opens up this question to be pretty much anything in React ecosystem. But is there an area of React building or the aspects of applications that you would like to see an improvement in or some kind of a change or something that hasn't seen the right amount of innovation in the same way that we've seen in other areas?

MICHAEL: Basically, is there a place where I would like to see the React ecosystem improve?


MICHAEL: I know this goes kind of contrary to what I just said but I would like to see a little bit more cohesiveness. I feel like in some ways, the freedom is good but I also feel like in some ways, for the last couple of years, we've been just sort of like rehashing the exact same old problems again and again because React really made everything else so easy, like a lot of the stuff that was hard about building web apps, just got really easy when React came along.

I'm not saying that because I have React training company. Of course, my livelihood right now depends on React but honestly, if it wasn't for React, I think I probably would have quit and done something else because it was actually getting really, really difficult for me. I was trying to build an app in Ember before I started with React and I just couldn't do it, you know? I just couldn't get the level of polish that I wanted in my app and get all the bugs out and get it working exactly how I want it to. It frustrated me, actually that I've spent a lot of time.

I spent about 18 months, about $100,000 of my own money, just down the drain trying to build this app, trying to get it out the door and I wasn't able to finish it off. At the end of the day, I really started to question like, "Was it me? Do I just suck? Am I not a great developer? Is that the problem?" You really have to start asking ourselves hard questions like that when you put everything you have into something and it doesn't work out and then React came along and I was like, "I was just using the wrong tools." The tools were the problem. It wasn't me. There is a different way to think about this about building stuff.

I thought the way that I was doing it was the only way that existed to build things but it turns out, it's not. I used to not understand what were people talking about when they were talking about functional programming or what do they talk about when they're talking about composition, solving problems with composition, instead of inheritance. I didn't even understand what that meant. But all I knew is really smart people would say stuff like that and I was like, "What are you talking about?" Now I feel like, because of React, I've gotten it.

Again, to get back to your question, Taras, React made a lot of the stuff that we used to worry about, that we used to think about. It made it easy and so, we could build amazing things now a lot more easily. But now, for the last couple of years, I feel like we've just been sort of rehashing a lot of the same stuff.

I would really like to see us, as a community sort of tackle the next level problems. I think the React Suspense stuff is definitely getting there. That's a problem that I really don't see anybody else sort of address, which is how do I make it easy to deal with the fact that applications by their nature -- these networked applications -- are asynchronous. How do I deal with that in a declarative way? That's why I'm encouraged by that work because I do think that it's kind of one of the more forward thinking things right now that's going on in the React community but I would like to see us in general, sort of like get past talking about styling and get past talking about service and rendering and move on.

ROBERT: Right and I'm going to assume you have this really unique experience since you do a lot of trainings. I follow you on Twitter and it's just always talking about where you're flying to and who you're training, so the things have to come up there where you see these things in pattern over pattern over pattern.

MICHAEL: Yeah, exactly. I see like a lot of and this again, gets back to Taras's question. I train a lot of people who are very new to React and I see people who are new to React, they really don't have a ton to go on besides just like blog posts and Medium pieces and podcast like this one and who am I? A lot of people in their React community don't even know or care who I am. It's like, "There's a guy out here who are saying stuff about React. Maybe I should listen to him. Maybe I should listen to somebody else," and it's confusing. It's confusing, I feel like, for people who are just getting into React. It's confusing. Like I said, experimentation is good but I guess, I wish the experience of coming to React was a little bit more like the experience of coming to Vue because --

ROBERT: Oh, like it was a beaten path.

MICHAEL: Exactly. I don't actually think there's not a whole lot about the Vue technology that is compelling to me and let's not dig on it. It's just --

ROBERT: A personal preference?

MICHAEL: Yeah, exactly, just preference but I do think the thing that is very compelling about the Vue experience is just the cohesiveness of it all. You go to Vue and there's like a way to do server-side rendering with data fetching and styling and --

ROBERT: They have a CLI and --

MICHAEL: And a CLI and a component and all these stuff. Yeah, and a router built right in. Anyway, I think that's a way that the React community could improve. I don't know if that'll ever happen because the React community at heart is artists and hackers and those people are traditionally very reluctant to be corralled and like I said, it's a blessing but I think from the perspective of people who are new to the community, it does tend to cause some confusion.

TARAS: I want to add to what Michael is saying. What's interesting and I'm sure Michael sees this in his training but the kind of people that use React is very diverse. There's this kind of original group or there's kind of mentality that prompted the early adopters of React and now, we're seeing these companies that are traditionally enterprise-y with MSE backgrounds and coming into React. It's really interesting to see all this kind of worlds collide and then see what's happening as a result. It's definitely interesting on what's going on now.

ROBERT: This is an excellent stopping point. I really agree. I come from Ember background so I would like to see a little bit more convention but I think it's okay. It would be nice to see that.

Thank you, Michael for coming on. Is there anything that you would like to give a quick plug for and where people can reach you?

MICHAEL: If you want to support the work we're doing, you can sign up for one of our upcoming workshops. We've got one right now on We've got a workshop coming up, actually in my hometown of Carlsbad. You can come out here in July and hang out with us and do some React training. We got a really awesome host here who's right here in town. We're doing some React training workshops on July 25th through 27th, I think and then, other ways that you can support what we're doing is publish in all my open source code at or you can follow us on Twitter at or at my personal account at @MJackson -- Michael Jackson.

ROBERT: Awesome. I really appreciate you taking the time to come on.

MICHAEL: Yeah, thank you so much. It's been a pleasure.

ROBERT: This is a great talk. Cool.

Thank you everybody for listening. We are The Frontside and we build UI that you can stick your feature on. If you would like to give us feedback, you can always reach out to us on Twitter at @TheFrontside or you could email us at We're always looking for any new topics or things you would like to talk about or things that are interesting to you.

As always, thank you Mandy for producing our podcast. It's @therubyrep on Twitter and on June 28th, we're going to have Chris Martin on to discuss blockchain development.

Jun 14 2018



Rank #3: What’s in a UI platform?

Podcast cover
Read more

Here it is, folks! The first episode of our newly rebranded "Frontside Platform Podcast". In this episode, we talk about why platform? What is going to come out of these conversations over time? Our goal is to get people thinking on the platform level which includes tooling, internalization, state management, routing, upgrade, and the data layer.

We also want to get people thinking categorically, rather than in the moment:

  • Planning strategically
  • Recognizing and knowing obstacles - matching
  • Don't want the framework, but still have the problems
  • Virtue is a weakness in different contexts
  • Laziness is a virtue but also a weakness
  • Not a question of can
  • Shared problem

Please join us in these conversations! If you or someone you know would be a perfect guest, please get in touch with us at

This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC.

Jan 24 2019



Rank #4: 070: Kubernetes with Joe Beda

Podcast cover
Read more


Joe Beda @jbeda | Heptio |

Show Notes:

  • 00:51 - What is Kubernetes? Why does it exist?
  • 07:32 - Kubernetes Cluster; Cluster Autoscaling
  • 11:43 - Application Abstraction
  • 14:44 - Services That Implement Kubernetes
  • 16:08 - Starting Heptio
  • 17:58 - Kubernetes vs Services Like Cloud Foundry and OpenShift
  • 22:39 - Getting Started with Kubernetes
  • 27:37 - Working on the Original Internet Explorer Team


Open Source Bridge: Enter the coupon code PODCAST to get $50 off a ticket! The conference will be held June 20-23, 2017 at The Eliot Center in downtown Portland, Oregon.


CHARLES: Hello everybody and welcome to The Frontside Podcast, Episode 70. With me is
Elrick Ryan.

ELRICK: Hey, what's going on?

CHARLES: We're going to get started with our guest here who many of you may have heard of before. You probably heard of the technology that he created or was a key part of creating, a self-described medium deal.


JOE: Thanks for having me on. I really appreciate it.

CHARLES: Joe, here at The Frontside most of what we do is UI-related, completely frontend but obviously, the frontend is built on backend technology and we need to be running things that serve our clients. Kubernetes is something that I think I started hearing about, I don't know maybe a year ago. All of a sudden, it just started popping up in my Twitter feed and I was like, "Hmm, that's a weird word," and then people started talking more and more about it and move from something that was behind me into something that was to the side and now it's edging into our peripheral vision more and more as I think more and more people adopt it, to build things on top of it.

I'm really excited to have you here on the show to just talk about it. I guess we should start by saying what is the reason for its existence? What are the unique set of problems that you were encountering or noticed that everybody was encountering that caused you to want to create this?

JOE: That's a really good set up, I think just for way of context, I spent about 10 years at Google. I learned how to do software on the server at Google. Before that, I was at Microsoft working on Internet Explorer and Windows Presentation Foundation, which maybe some of your listeners had to actually go ahead and use that. I learned how to write software for the server at Google so my experience in terms of what it takes to build and deploy software was really warped by that. It really doesn't much what pretty much anybody else in the industry does or at least did.

As my career progressed, I ended up starting this project called Google Compute Engine which is Google's virtual machine as a service, analogous to say, EC2. Then as that became more and more of a priority for the company. There was this idea that we wanted internal Google developers to have a shared experience with external users. Internally, Google didn't do anything with virtual machines hardly. Everything was with containers and Google had built up some really sophisticated systems to be able to manage containers across very large clusters of computers.

For Google developers, the interface to the world of production and how you actually launched off and monitor and maintain it was through this toolset, Borg and all these fellow travelers that come along with it inside of Google. Nobody really actually managed machines using traditional configuration management tools like Puppet or Chef or anything like that. It’s a completely different experience.

We built a compute engine, GCE and then I had a new boss because of executive shuffle and he spun up a VM and he'd been at Google for a while. His reaction to the thing was like, "Now, what?" I was like I'm sitting there at the root prompt go and like, "I don't know what to do now." It turns out that inside of Google that was actually a common thing. It just felt incredibly primitive to actually have a raw VM that you could have SSH into because there's so much to be done above that to get to something that you're comfortable with building a production grade service on top of.

The choice as Google got more and more serious about cloud was to either have everybody inside of Google start using raw VMs and live the life that everybody outside of Google's living or try and bring the experience around Borg and this idea of very dynamic, container-centric, scheduled-cluster thinking bring that outside of Google. Borg was entangled enough with the rest of Google systems that sort of porting that directly and externalizing that directly wasn't super practical. Me and couple of other folks, Brendan Burns and Craig McLuckie pitched this crazy idea of starting a new open source project that borrowed from a lot of the ideas from Borg but really melded it with a lot of the needs for folks outside of Google because again, Google is a bit of a special case in so many ways.

The core problem that we're solving here is how do you move the idea of deploying software from being something that's based on these physical concepts like virtual machines, where the amount of problems that you have to solve, to actually get that thing up and running is actually pretty great. How do we move that such that you have a higher, more logical set of abstractions that you're dealing with? Instead of worrying about what kernel you're running on, instead of worrying about individual nodes and what happens if a node goes down, you can instead just say, "Make sure this thing is running," and the system will just do its best to make sure that things are running and then you can also do interesting things like make sure 10 of these things are running, which is at Google scale that ends up being important.

CHARLES: When you say like a thing, you're talking about like a database server or API server or --?

JOE: Yeah, any process that you could want to be running. Exactly. The abstraction that you think about when you're deploying stuff into the cloud moves from a virtual machine to a process. When I say process, I mean like a process plus all the things that it needs so that ends up being a container or a Docker image or something along those lines. Now the way that Google does it internally slightly different than how it's done with Docker but you can squint at these things and you can see a lot of parallels there.

When Docker first came out, it was really good. I think at Docker and containers people look for three things out of it. The first one is that they want a packaged artifact, something that I can create, run on my laptop, run in a data center and it's mostly the same thing running in both places and that's an incredibly useful thing, like on your Mac you have a .app and it's really a directory but the finder treats it as you can just drag it around and the thing runs. Containers are that for the server. They just have this thing that you can just say, run this thing on the server and you're pretty sure that it's going to run.

That’s a huge step forward and I think that's what most folks really see in the value with respect to Docker. Other things that folks look at with containerized technology is a level of efficiency of being able to pack a lot of stuff onto a little bit of hardware. That was the main driver for Google. Google has so many computers that if you improve utilization by 1%, that ends up being real money. Then the last thing is, I think a lot of folks look at this as a security boundary and I think there's some real nuance conversations to have around that.

The goal is to take that logical infrastructure and make it such that, instead of talking about raw VMs, you're actually talking about containers and processes and how these things relate to each other. Yet, you still have the flexibility of a tool box that you get with an infrastructure level system versus if you look at something like Heroku or App Engine or these other platform as a service. Those things are relatively fixed function in terms of their architectures that you can build. I think the container cluster stuff that you see with things like Kubernetes is a nice middle ground between raw VMs and a very, very opinionated platform as a service type of thing. It ends up being a building block for building their more specialized experiences. There's a lot to digest there so I apologize.

CHARLES: Yeah, there's a lot to digest there but we can jump right into digesting it. You were talking about the different abstractions where you have your hardware, your virtual machine and the containers that are running on top of that virtual machine and then you mentioned, I think I'm all the way up there but then you said Kubernetes cluster. What is the anatomy of a Kubernetes cluster and what does that entail? And what can you do with it?

JOE: When folks talk about Kubernetes, I think there's two different audiences and it's important to talk about the experience from each audience. There’s the audience from the point of view of what it takes to actually run a cluster -- this is a cluster operator audience -- then there's the audience in terms of what it takes to use a cluster. Assuming that somebody else is running a cluster for me, what does it look like for me to go ahead and use this thing? This is really different from a lot of different dev app tools which really makes these things together. We’ve tried to create a clean split here.

I'm going to skip past what it means to launch and run a Kubernetes cluster because it turns out that over time, this is going to be something that you can just have somebody else do for you. It’s like running your own MySQL database versus using RDS in Amazon. At some point, you're going to be like, "You know what, that's a pain in the butt. I want to make that somebody else's problem."

When it comes to using the cluster, pretty much what it comes down to is that you can tell a cluster. There’s an API to a cluster and that API is sort of a spiritual cousin to something like the EC2 API. You can talk to this API -- it's a RESTful API -- and you can say, "Make sure that you have 10 of these container images running," and then Kubernetes will make sure that ten of those things are running. If a node goes down, it'll start another one up and it will maintain that. That’s the first piece of the puzzle. That creates a very dynamic environment where you can actually program these things coming and going, scaling up and down.

The next piece of the puzzle that really, really starts to be necessary then is that if you have things moving around, you need a way to find them. There is built in ideas of defining what a service is and then doing service discovery. Service discovery is a fancy name for naming. It’s like I have a name for something, I want to look that up to an IP address so that I can talk to it. Traditionally we use DNS. DNS is problematic in the super dynamic environments so a lot of folks, as they build backend systems within the data center, they really start moving past DNS to something that's a lot more dynamic and purpose-built for that. But you can think about it in your mind as a fancy super-fast DNS.

CHARLES: The customer is itself something that's abstract so I can change it state and configure it and say, "I want 10 instances of Postgres running," or, "I want between five and 15 and it will handle all of that for you." How do you then make it smart so that you can react to load, for example like all of the sudden, this thing is handling more load so I need to say... What's the word I'm looking for, I need to handle --

JOE: Autoscale?

CHARLES: Yeah, autoscale. Are there primitives for that?

JOE: Exactly. Kubernetes itself was meant to be a tool box that you can build on top of. There are some common community-built primitives for doing it's called -- excuse the nomenclature here because there's a lot of it in Kubernetes and I can define it -- Horizontal Pod Autoscaling. It's this idea that you can have a set of pods and you want to tune the number of replicas to that pod based on load. That's something that's built in. But now maybe you're cluster, you don't have enough nodes in your cluster as you go up and down so there's this idea of cluster autoscaling where I want to add more capacity that I'm actually launching these things into.

Fundamentally, Kubernetes is built on top of virtual machines so at the base, there's a bunch of virtual or physical machines hardware that's running and then it's the idea of how do I schedule stuff into that and then I can pack things into that cluster. There's this idea of scaling the cluster but then also scaling workloads running on top of the cluster. If you find that some of these algorithms or methods for how you want to scale things when you want to launch things, how you want to hook them up, if those things don't work for you, the Kubernetes system itself is programmable so you can build your own algorithms for how you want to launch and control things. It's really built from the get go to be an extensible system.

CHARLES: One question that's keeps coming up is as I hear you describing these things is the Kubernetes cluster then, it's not application-oriented so you could have multiple applications running on a single cluster?

JOE: Very much so.

CHARLES: How do you then layer on your application abstraction on top of this cluster abstraction?

JOE: An application is made up of a bunch of running bits, whether it'd be a database. I think as we move towards microservices, it's not just going to be one set of code. It can be a bunch of sets of codes that are working together or bunch of servers that are working together. There are these ideas are like I want to run 10 of these things, I want to run five of these things, I want to run three of these things and then I want them to be able to find each other and then I want to take this thing and I want to expose it out to the internet through a load balancer on Amazon, for example. Kubernetes can help to set up all those pieces.

It turns out that Kubernetes doesn't have an idea of an application. There is no actually object inside a Kubernetes called application. There is this idea of running services and exposing services and if you bring a bunch of services together, that ends up being an application. But in a modern world, you actually have services that can play double duty across applications. One of the things that I think is exciting about Kubernetes is that it can grow with you as you move from a single application to something that really becomes a service mesh, as your application, your company grows.

Imagine that you have some sort of app and then you have your customer service portal for your internal employees. You can have those both being frontend applications, both running on a Kubernetes cluster, talking to a common backend with a hidden API that you don't expose to customers but it's something that's exposed to both of those frontends and then that API may talk to a database. Then as you understand your problems, you can actually spawn off different microservices that can be managed separately by different teams. Kubernetes becomes a platform where you can actually start with something relatively simple and then grow with that and have it stretch from single application to multiple service microservice-base application to a larger cluster that can actually stretch across multiple teams and there's a bunch of facilities for folks not stepping on each other's toes as they do this stuff.

Just to be clear, this is what Kubernetes is as it's based. I think one of the powerful things that you can do is that there's a whole host to folks that are building more platform as a service like abstractions on top of Kubernetes. I'm not going to say it's a trivial thing but it's a relatively straightforward thing to build a Heroku-like experience on top of Kubernetes. But the great thing is that if you find that that Heroku experience, if some of the opinions that were made as part of that don't work for you, you can actually drop down to a level that's more useful than going all the way down to raw VM because right now, if you're running on Heroku and something doesn't work for you, it's like, "Here's a raw VM. Good luck with that." There's a huge cliff as you actually want to start coloring outside the lines for, as I mix my metaphors here for these platform services.

ELRICK: What services that are out there that you can use that would implement Kubernetes?

JOE: That's a great question. There are a whole host there. One of the folks in the community has pulled together a spreadsheet of all the different ways to install and run Kubernetes and I think there were something like 60 entries on it. It's an open source system. It's credibly adaptable in terms of running in all sorts of different mechanisms for places and there are really active startups that are helping folks to run that stuff.

In terms of the easiest turnkey things, I would probably start with Google Container Engine, which is honestly one click. It fits within a Free Tier. It can get you up and running so that you can actually play with Kubernetes super easy. There's this thing from the folks at CoreOS called minikube that lets you run it on your laptop as a development environment. That's a great way to kick the tires. If you're on Amazon, my company Heptio has a quick start that we did with some of the Amazon community folks. It's a cloud formation template that launches a Kubernetes stack that you can get up and running and really understand what's happening.

I think as users, understand what value it brings at the user level then they'll figure out whether they want to invest in terms of figuring out what the best place to run and the best way to run it for them is. I think my advice to folks would be find some way to start getting familiar with it and then decide if you have to go deep in terms of how to be a cluster operator and how to run the thing.

ELRICK: Yup. That was going to be my next question. You just brought up your company, Heptio. What was the reason for starting that startup?

JOE: Heptio was founded by Craig McLuckie, one of the other Kubernetes founders and me. We started about six months or seven months ago now. The goal here is to bring Kubernetes to enterprises and how do we bridge the gap of bringing some of this technology forward company thinking to think about companies like Google and Twitter and Facebook. They have a certain way of thinking about building a deployment software. How do we bring those ideas into more mainstream enterprise? How do we bridge that gap and we're really using doing Kubernetes as the tool to do that?

We’re doing a bunch of things to make that happen. The first being that we're offering training, support and services so right now, if companies want to get started today, they can engage with us and we can help them understand what makes sense there. Over time, we want to make that be more self-service, easier to do so that you actually don't have to hire someone like us to get started and to be successful there. We want to invest in the community in terms of making Kubernetes easier to approach, easier to run and then more applicable to a more diverse set of audiences.

This conversation that we're having here, I'm hoping that at some point, we won't have to have this because Kubernetes will be easy enough and self-describing enough that folks won't feel like they have to dig deep to get started. Then the last thing that we're going to be doing is offering commercial services and software that really helps teach Kubernetes into the fabric of how large companies work. I think there's a set of tools that you need as you move from being a startup or a small team to actually dealing within the structure of a large enterprise and that's really where we're going to be looking to create and sell product.

ELRICK: Gotcha.

CHARLES: How does Kubernetes then compare in contrast to other technologies that we hear when we talk about integrating with the enterprise and having enterprise clients managing their own infrastructure things like Cloud Foundry, for example. From someone who's kind of ignorant of both, how do you discriminate between the two?

JOE: Cloud Foundry is a more of a traditional platform as a service. There's a lot to like there and there are some places where the Kubernetes community and the Cloud Foundry community are starting to cooperate. There is a common way for provisioning and creating external services so you can say, "I want MySQL database." We're trying to make that idea of, "Give me MySQL database. I don't care who and where it's running." We're trying to make those mechanisms common across Cloud Foundry and Kubernetes so there is some effort going in there.

But Cloud Foundry is more of a traditional platform as a service. It's opinionated in terms of the right way to create, launch, roll out, hooks services together. Whereas, Kubernetes is more of a building block type of thing. Kubernetes is, at least raw Kubernetes in some ways a more of a lower levels building block technology than something like Cloud Foundry. The most applicable competitor in this world to Cloud Foundry, I would say would be OpenShift from Red Hat.

Open Shift is a set of extensions built on top of it. Right now, it's a little bit of a modified version of Kubernetes but over time that teams working to make it be a set of pure extensions on top of Kubernetes that adds a platform as a service layer on top of the container cluster layer. The experience for Open Shift will be comparable to the experience for Cloud Foundry. There's other folks like Microsoft just bought the small company called Deis. They offer a thing called Workflow which gives you a little bit of the flavor of a platform as a service also. There's multiple flavors of platforms built on top of Kubernetes that would be more apples to apples comparable to something like Cloud Foundry.

Now the interesting thing with thing Deis' Workflow or Open Shift or some of the other platforms built on top of Kubernetes is that, again if you find yourself where that platform doesn't work for you for some reason, you don't have to throw out everything. You can actually start picking and choosing what primitives you want to drop down to in the Kubernetes world without having to go down to raw VMs. Whereas, Cloud Foundry really doesn't have a widely supported, sort of more raw interface to run in containers and services. It's kind of subtle.

CHARLES: Yeah, it's kind of subtle. This is an analogy that just popped into my head while I was listening to you and I don't know if this is way off base. But when you were describing having... What was the word you used? You said a container clast --? It was a container clustered...

JOE: Container orchestrator, container cluster. These are all --

CHARLES: Right and then kind of hearkening back to the beginning of our conversation where you were talking about being able to specify, "I want 10 of these processes," or an elastic amount of these processes that reminded me of Erlang VM and how kind of baked into that thing is the concept of these lightweight processes and be able to manage communication between these lightweight processes and also supervise these processes and have layers of supervisors supervising other supervisors to be able to declare a configuration for a set of processes to always be running. Then also propagate failure of those processes and escalate and stuff like that. Would you say that there is an analogy there? I know there are completely separate beast but is there a co-evolution there?

JOE: I've never used Erlang in Anger so it's hard for me to speak super knowledgeably about it. For what I understand, I think there is a lot in common there. I think Erlang was originally built by Nokia for telecoms switches, I believe which you have these strong availability guarantees so any time when you're aiming for high availability, you need to decouple things with outside control loops and ways to actually coordinate across pieces of hardware and software so that when things fail, you can isolate that and have a blast radius for a failure and then have higher level mechanisms that can help recover. That's very much what happens with something like Kubernetes and container orchestrator. I think there's a ton of parallels there.

CHARLES: I'm just trying to grasp at analogies of things that might be --

ELRICK: I think they call that the OTP, Open Telecom Platform or something like that in Erlang.

CHARLES: Yeah, but it just got a lot of these things --

ELRICK: Very similar.

CHARLES: Yeah, it seems very similar.

ELRICK: Interestingly enough, for someone that's starting from the bottom, an initiated person to Kubernetes containers, Docker images, Docker, where would they start to ramp up themselves? I know you mentioned that you are writing a book --?

JOE: Yes.

ELRICK: -- 'Kubernetes: Up and Running'. Would that be a good place to start when it comes out or is there like another place they should start before they get there. What is your thoughts on that?

JOE: Definitely, check out the book. This is a book that I'm writing with Kelsey Hightower who's one of the developer evangelists for Google. He is the most dynamic speaker I've ever seen so if you ever have a chance to see him live, it's pretty great. But Kelsey started this and he's a busy guy so he brought in Brendan Burns, one of the other Kubernetes co-founders and me to help finish that book off and that should be coming out soon. It's Kubernetes: Up and Running. Definitely check that out.

There’s a bunch of good tutorials out there also that start introducing you to a lot of the concepts in Kubernetes. I'm not going to go through all of those concepts right now. There's probably like half a dozen different concepts and terminology, things that you have to learn to really get going with it and I think that's a problem right now. There's a lot to import before you can get started. I gave a talk at the Kubernetes Conference in Berlin, a month or two ago and it was essentially like, yeah we got our work cut out for us to actually make the stuff applicable to wider audience.

But if you want to see the power, I think one of the things that you can do is there's the system built on top of Kubernetes called Helm, H-E-L-M, like a ship's helm because we love our nautical analogies here. Helm is a package manager for Kubernetes and just like you can login to say, in Ubuntu machine and do apps get install MySQL and you have a database up and running. With Helm you can say, create and install 'WordPress install' on my Kubernetes cluster and it'll just make that happen.

It takes this idea of package management of describing applications up to the next level. When you're doing regular sysadmin stuff, you can actually go through and do the system to [Inaudible] files or to [Inaudible] files and copy stuff out and use Puppet and Chef to orchestrate all of that stuff. Or you can take the stuff that sort of package maintainers for the operating system have done and actually just go ahead and say, "Get that installed." We want to be able to offer a similar experience at the cluster level. I think that's a great way to start seeing the power. After you understand all these concepts here is how easy you can make it to bring up and run these distributed systems that are real applications.

The Weaveworks folks, there are company that do container networking and introspection stuff based out of London. They have this example application called Sock Shop. It's like the pet shop example but distributed and built to show off how you can build an application on top of Kubernetes that pulls a lot of moving pieces together. Then there's some other applications out there like that that give you a little bit of an idea of what things look like as you start using this stuff to its fullest extent.

I would say start with something that feels concrete where you can start poking around and seeing how things work before you commit. I know some people are sort of depth first learners and some are breadth first learners. If you're depth first, go and read the book, go to Kubernetes documentation site. If you're breadth first, just start with an application and go from there.


CHARLES: I think I definitely fall into that breadth first. I want to build something with it first before trying to manage my own cluster.

ELRICK: Yeah. True. I think I watched your talk and I did watch one of Kelsey's talks: container management. There was stuff about replicators and schedulers and I was like, "The ocean just getting deeper and deeper," as I listened to his talk.

JOE: Actually, I think this is one of the cultural gaps to bridge between frontend and backend thinking. I think a lot of backend folks end up being these depths first types of folks, where when they want to use a technology, they want to read all the source code before they first apply it. I'm sure everybody has met those type of developers. Then I think there's folks that are breadth first where they really just want to understand enough to be effective, they want to get something up and running, they want to like if they hit a problem, then they'll go ahead and fix that problem but other than that, they're very goal-oriented towards, I want to get this thing running. Kubernetes right now is kind of built by systems engineers for systems engineers and it shows so we have our work cut out for us, I think to bridge that gap. It's going to be an ongoing thing.

ELRICK: Yeah, I'm like a depth first but I have to keep myself in check because I have to get work done as a developer.


JOE: That sounds about right, yeah. Yeah, so you're held accountable for writing code.

CHARLES: Yeah. That's where real learning happens when you're depth first but you've got deadlines.


CHARLES: I think that's a very effective combination. Before we go, I wanted to switch topic away from Kubernetes for just a little bit because you mentioned something when we were emailing that, I guess in a different lifetime you were actually on the original IE team or at the very beginning of the Internet Explorer team at Microsoft?

JOE: Yes, that's where I started my career. Back in '97, I've done a couple of internships at Microsoft and then went to join full time, moved up here to Seattle and I had a choice between joining the NT kernel team or the Internet Explorer team. This was after IE3 before IE4. I don't know if this whole internet thing is going to pan out but it looks like that gives you a lot of interesting stuff. You got to understand the internet, it wasn't an assumed thing back then, right?

ELRICK: Yeah, that's true.

JOE: I don't know, this internet thing.

CHARLES: I know. I was there and I know that like old school IE sometimes gets a bad rap. It does get a bad rap for being a little bit of an albatross but if you were there for the early days of IE, it really was the thing that blew it wide open like people do not give credit. It was extraordinarily ahead of its time. That was [Inaudible] team that coin DHTML back to when it was called DHTML. I remember, actually using it for the first time, I think about '97 is about what I was writing raw HTML for everything. CSS wasn't even a thing hardly. When I realized, all these static things when we render them, they're etched in stone. The idea that every one of these properties which I already knew is now dynamic and completely reflected, just moment to moment. It was just eye-opening. It was mind blowing and it was kind of the beginning of the next 20 years. I want to just talk a little bit about that, about where those ideas came from and what was the impetus for that?

JOE: Oh, man. There's so much history here. First of all, thank you for calling out. I think we did a lot of really interesting groundbreaking work then. I think the sin was not in IE6 as it was but in [inaudible]. I think the fact that --

CHARLES: IE6 was actually an amazing browser. Absolutely an amazing browser.

JOE: And then the world moved past it, right? It didn't catch up. That was the problem. For its time when it was released, I was proud of that release. But four years on, things get a little bit long in the tooth. I think IE3 was based on rendering engine that was very static, very similar to Netscape at the time. The thing to keep in mind is that Netscape at that time, it would download a webpage, parse it and display it. There was no idea of a DOM at Netscape at that point so it would throw away a lot of the information and actually only store stuff that was very specific to the display context.

Literally, when you resize the window for Netscape back then, it would actually reparse the original HTML to regenerate things. It wasn't even able to actually resize the window without going through and reparsing. What we did with IE4 -- and I joined sort of close to the tail on IE4 so I can't claim too much credit here -- is bringing some of the ideas from something like Visual Basic and merge those into the idea of the browser where you actually have this programming model which became the DOM of where your controls are, how they fit together, being able to live modify these things. This was all part and parcel of how people built Windows applications.

It turns out that IE4 was the combination of the old IE3 rendering engine, sort of stealing stuff from there but then this project that was built as a bunch of Active X controls for Office called [inaudible]. As you smash that stuff together and turn it into a browser rendering engine, that browser rendering engine ended up being called Trident. That's the thing that got a nautical theme. I don't think it's connected and that's the thing that that I joined and started working on at the time.

This whole idea that you have actually have this DOM, that you can modify a programmable representation of DHTML and have it be live updated on screen, that was only with IE4. I don't think anybody had done it at that point. The competing scheme from Netscape was this thing called layers where it was essentially multiple HTML documents where you could replace one of the HTML documents and they would be rendered on top of each other. It was awful and it lost to the mist of time.

CHARLES: I remember marketing material about layers and hearing how layers was just going to be this wonderful thing but I don't ever remember actually, did they ever even ship it?

JOE: I don't know if they did or not. The thing that you got to understand is that anybody who spent any significant amount of time at Microsoft, you just really internalize the idea of a platform like no place else. Microsoft lives and breathes platforms. I think sometimes it does them a disservice. I've been out of Microsoft for like 13 years now so maybe some of my knowledge is a little outdated here but I still have friends over there.

But Microsoft is like the poor schmuck that goes to Vegas and pulls the slot machine and wins the jackpot on the first pull. I'm not saying that there wasn't a lot of hard work that went behind Windows but like they hit the goldmine with that from a platform point of view and then they essentially did it again with Office. You have these two incredibly powerful platforms that ended up being an enormous growth engine for the company over time so that fundamentally changed the world view of Microsoft where they really viewed everything as a platform.

I think there were some forward thinking people at Netscape and other companies but I think, Microsoft early on really understood what it meant to be a platform and we saw back then what the web could be. One of the original IE team members, I'm going to give a shout out to him, Chris Wilson who's now on the Chrome team, I think. I don't know where he is these days. Chris was on the original IE team. He’s still heavily involved in web standards. None of this stuff is a surprise to us.

I look at some of the original so after we finished IE6, a lot of the IE team rolled off to doing Avalon which became Windows Presentation Foundation, which was really looking to sort of reinvent Windows UI, importing a bunch of the ideas from web and modern programming there. That's where we came up with XAML and eventually begat Silverlight for good or ill. But some of our original demos for Avalon, if you go back in time and look at that, that was probably... I don't know, 2000 or something like that. They're exactly the type of stuff that people are building with the web platform today.

Back then, they'll flex with the thing. We're reinventing this stuff over and over again. I like where it's going. I think we're in a good spot right now but we see things like the Shadow DOM come up and I look at that and I'm like, "We had HTC controls which did a lot of Shadow DOM stuff like stuff in IE early on." These things get reinvented and refined over time and I think it's great but it's fascinating to be in the industry long enough that you can see these patterns repeat.

CHARLES: It is actually interesting. I remember doing UI in C++ and in Java. We did a lot of Java and it was a long time. I felt like I was wandering in the wilderness of the web where I was like, "Oh, man. I just wish we had these capabilities of things that we could do in swing, 10 or 15 years ago," but the happy ending is that I really actually do feel we are in a place now, finally where you have options for it really is truly competitive as a developer experience to the way it was, these many years ago and it's also a testament just how compelling the deployment model of the web is, that people were willing to forgo all of that so they could distribute their applications really easily.

JOE: Never underestimate the power of view source.



ELRICK: I think that's why this sort of conversations are very powerful, like going back in time and looking at the development up until now because like they say that people that don't know their history, they're doomed to repeat it. I think this is a beautiful conversation.

JOE: Yeah. Because I've done that developer focused frontend type of stuff. I've done the backend stuff. One of the things that I noticed is that you see patterns repeat over and over again. Let's be honest, it probably more like a week, I was going to say a weekend and learn the React the other day and the way that it encapsulate state up and down, model view, it's like these things are like there's different twists on them that you see in different places but you see the same patterns repeat again and again.

I look at the way that we do scheduling in Kubernetes. Scheduling is this idea that you have a bunch of workloads that have a certain amount of CPU and RAM that they require like you want to play this Tetris game of being able to fit these things in, you look at scheduling like that and there are echoes for how layout happens in a browser. There is a deeper game coming on here and as you go through your career and if you're like me and you always are interested in trying new things, you never leave it all behind. You always see things that influence your thinking moving forward.

CHARLES: Absolutely. I kind of did the opposite. I started out on the backend and then moved over into the frontend but there's never been any concept that I was familiar with working on server side code that did not come to my aid at some point working on the frontend. I can appreciate that fully.

ELRICK: Yup. I can agree with the same thing. I jump all around the board, learning things that I have no use currently but somehow, they come back to help me.

CHARLES: That will come back to help you. You thread them together at some point.


CHARLES: As they said in one of my favorite video games in high school, Mortal Kombat there is no knowledge that is not power.

JOE: I was all Street Fighter.

CHARLES: Really?


JOE: I cut class in high school and went to play Street Fighter at the mall.

CHARLES: There is no knowledge that isn't power except for... I'm not sure that the knowledge of all these little mashy key buttons combinations, really, I don't think there's much power in that.

JOE: Well, the Konami code still shows up all the time, right?


CHARLES: I'm surprised how that's been passed down from generation to generation.

JOE: You still see it show up in places that you wouldn't expect. One of the sad things that early on in IE, we had all these Internet Explorer Easter eggs where if you type this right combination into the address bar, do this thing and you clicked and turn around three times and face west, you actually got this cool DHTML thing and those things are largely disappearing. People don't make Easter eggs like they used to. I think there's probably legal reasons for making sure that every feature is as spec. But I kind of missed those old Easter eggs that we used to find.

CHARLES: Yeah, me too. I guess everybody save their Easter eggs for April 1st but --

JOE: For the release notes, [inaudible].

CHARLES: All right. Well, thank you so much for coming by JOE. I know I'm personally excited. I'm going to go find one of those Kubernetes as a services that you mentioned and try and do a little breadth first learning but whether you're depth first or breadth first, I say go to it and thank you so much for coming on the show.

JOE: Well, thank you so much for having me on. It's been great.

CHARLES: Before we go, there is actually one other special item that I wanted to mention. This is the Open Source Bridge which is a conference being held in Portland, Oregon on the 20th to 23rd of June this year. The tracks are activism, culture hacks, practice and theory and podcast listeners may be offered a discount code for $50 off of the ticket by entering in the code 'podcast' on the Event Brite page, which we will link to in the show notes. Thank you, Elrick. Thank you, Joe. Thank you everybody and we will see you next week.

May 18 2017



Rank #5: 072: Single Page Apps with Accessibility in Mind with Kris Van Houten

Podcast cover
Read more

Kris Van Houten: @krivaten | | Q2

Show Notes:

  • 00:55 - Kris’ Interest and Passion for Accessibility
  • 06:07 - Using Ember for Accessibility: Pattern Adoption
  • 10:13 - Context Switch Awareness and Managing Focus
  • 12:08 - Asynchrony and Desired Interaction
  • 14:04 - Building a Form Input Component
  • 19:05 - Things That Are Hard to Catch
  • 22:41 - Assistive Browsers?
  • 28:17 - Making Things Accessible From the Start


Kris’ Blog Post Series on Accessibility:


CHARLES: Hello, everybody and welcome to The Frontside Podcast, Episode 72. My name is Charles Lowell, a developer here at The Frontside and podcast host-in-training. With me today is Wil.

WIL: Hello.

CHARLES: Hey, Wil. Today, we're going to be talking about accessibility in single page applications with Kris Van Houten who is a developer at Q2. Hey, Kris. Thank you for coming on the show. Today, we're going to talk about something that I know a lot of people's minds here and probably elsewhere on the internet, it's a topic that's getting a lot more attention, which is a good thing and that's accessibility. We’re going to explore the niche of accessibility as it applies to single page applications. Now, you're a frontend developer at Q2, what initially got you interested in and passionate about accessibility in general?

KRIS: I honestly feel my path to passion in this area has been a little bit unorthodox in a number of ways. I basically started out in total apathy of this topic and over the last year, it has turned into a genuine interest of mine. About three years ago, I remember listening to an episode of ShopTalk Show with Dave Rupert and Chris Coyier and they kind of went on this large rant about accessibility and why more developers need to be concerned and compassion about it.

Dave Rupert was talking about his contributions to the accessibility project and I'm sitting back and thinking to myself and this is back then, obviously, "Why would anyone who is blind want to use anything that I'm working on." I basically balked at the idea and disregarded it entirely. At that time, I was just getting my feet wet with Ember working on an application with a company here in Cincinnati and we had these conversations about, "I notice that we put this action or a clickable event on a div element, should we not be doing that? Is it that not something that we should be doing?"

I remember sitting back and having this conversation and saying, "The ads been crawled by SEO and Ember isn't yelling at us for doing it. It still works fine so what the heck? Let’s just go with it." Basically, every single app that come into since then has basically adopted that same mindset even before I joined the team so I know it's not just me who is thinking this. A lot of developers that have been exercising the same way of doing their code.

CHARLES: Right, it's the path of least resistance. Everybody’s got a job to do. Everybody’s got features to deliver so that practice can be very easily self-perpetuating, right?

KRIS: Exactly and I think a lot of developers just don't understand the semantic difference between a div or a label or a button or a link and how browsers can actually treat these difference HTML attributes or HTML tags differently because of how assistive technology can utilize them for per person's benefit. That’s where I was a little over a year ago basically.

When I first started at Q2, that first week, I got pulled into a discussion about design patterns which is another passion of mine and somehow, that turned into me joining a group that was to establish to figure out how to tackle the task of making our large app accessible. Basically, we had a company come in, audit our application and we got a big fat F for accessibility so it's something that we said, "We need to start tackling this problem." Being that, I just started at the company that week, I was going to tell them no but internally, I was panicking and saying, "I got to figure out what is this whole accessibility thing is and why it's important."

I started looking for books, articles on the topic and trying to basically flood myself with information. Two things that really transformed my way of thinking was actually a talk given by Nathan Hammond at that Wicked Good Ember in 2015, where he shows an example of building an application without accessibility in mind so basically, doing what I was doing before which is we're adding actions to div tags, we're not really caring about semantic HTML, we're just making the feature or the application work.

But then what he does, which I think is super powerful is he pulled up a colleague of his who is blind and had him try to use the application. He just goes through and you can see the struggle and he's actually vocalizing and talking about where he's [inaudible] with this application. Long story short, Nathan comes back up and makes a few adjustments. DHTML has [inaudible] up again and it's night and day difference just by changing the markup and by dropping in the Ember A11y add-on which helps with focusing the browser in certain areas of the content. He’s able to totally transform how's individuals able to use the app.

For me, that was a super powerful to come in and see that and see someone actually struggle with a website that they were trying to use. I think, [inaudible] where I always saw accessibility was it will only affects people who can't see and I think that's the other area where I've really started to have that paradigm shift was when I realized that this isn't just people who can't see. It’s for people who have motor difficulties, who can't use a mouse and how to use a keyboard instead. People who have various vision issues, whether that's cataracts, colorblindness, glaucoma, dyslexia, some in these effects, not just DHTML but also affects color contrast, the fonts that we're using that impacts every area of application design and development and that's where I started to realize that that was where the paradigm shift happened in my mind where I started thinking to myself we really need to start talking about this more and getting other developers on board in general on this.

CHARLES: It can be intimidating, especially when it feels like on a single page application, your divs have to do more, so to speak in the sense that it feels that your HTML is fatter. It’s not just a thin layer but your HTML is actually part of the UI.

KRIS: Exactly, yeah.

CHARLES: When it comes to having this paradigmatic shift that you're describing, when you're looking at your single page applications, are there any insights into the general structure of the application that you feel like you've gained that are foundational, they kind of transcend accessibility? I guess, what I'm saying is, is there any way that you become like a better developer or been able to recognize foundational patterns because of having these insights surrounding accessibility?

KRIS: I've been working with Ember for about three or four years now, basically since it was still in beta. Over the last several years, I have started to accumulate a lot of knowledge as to how we can utilize Ember to do a lot of the heavy lifting for us. When I started getting more passionate about the area of accessibility, first question that came into my mind are how can we use Ember to do some of the heavy lifting for us. For example, some of the things that I had done was go through and start working on developing a couple of components that basically cover a lot of things that I find ourselves doing [inaudible] a lot. Whether that might be a component to just plain icon on a page or a component to display input on a page.

What we're able to do is using Ember, we can say, "Here's the icon I want to display but if I don't happen to pass in an aria-label attribute, for example. The component will add the 'aria-hidden=true' for me. Being able to really utilize the power of Ember to do some of that stuff for us on the back side of things, I guess you could say it magically.

CHARLES: Let me stop you there for a second and unpack that example. What you're saying is, if I'm going to put an input on the page, if I actually don't assign an ARIA role, it's going to hide it from me?

KRIS: No. I was thinking of an icon components, say if I'm using Font Awesome, for example and I want this with the trash icon so I wrote a component for our specific icon library that we're using. We pass in the icon that we want to display, again that could be the trash icon and we can also pass in an aria-label attribute to add a label to that span that will be read to the user. But if we don't pass that attribute in, the component will automatically add the 'aria-hidden=true' attribute for us so basically it skips over it.

CHARLES: Yes so it won't be just garbage for a screen reader or someone navigating with a keyboard.

WIL: Yeah, otherwise the screen reader tries to read the content of the icon CSS which is just the Unicode.


KRIS: Yeah. What we really is trying to figure out and what I've spent a lot of my time, especially in writing my blog series on this was while we are using React or Vue or Angular or Ember or whatever, how can we utilize the power of the single page application frameworks to do some of that heavy lifting for us in the background without us needing to explicitly define everything. I'd say, especially when you work on a large team like what I work on currently, we can't expect everybody to be extremely well-versed in the area of accessibility so if we can do some of the work for them and just encourage them to adopt these components in their daily workflow, it does some of the work for us. That’s what we're working on and talking a lot about at Q2 is basically this pattern adoption.

CHARLES: Right so it sounds like to kind of paraphrase, whether you're working in any framework most of them have this concept of components so really leaning hard on that idea to make components at the very granular level aware of their own accessibility. Is that fair to say?

KRIS: Yeah, obviously there's more I'm sure as we go for the conversation about some of the things that I've tackled in this area but long story short, being able to utilize and recognize, you have this extremely powerful JavaScript framework at your disposal to do some of work for you so why not equip to do just that.

CHARLES: Yeah. I guess that falls into my next question, which is there are component level concerns and if there are other component level concerns, I definitely want to hear about them but what immediately leaps to mind is there are also cross-cutting concerns of any single page application, what's the state of your URL and if you're using a router. Some of the content on the page is going to be changing and others isn't like how do you cope with that? What are the cross-cutting concerns of an application that span components and then how do you cope with them?

KRIS: I think one thing that comes to mind as you're talking is the whole area of context switch awareness. If I click a link, if I go from the home page of an application to my profile page, how does a screen reader know that that content has now changed to present this new information to the user? I know what we were able to do was we were able to drop in the focusing out with component that's put out by the Ember accessibility team, which basically whenever we render to an outlet, that's utilizing this focusing outlet component, it will focus the browser to that main area and start presenting that information back to the users.

One area that was at the top of our list as we start tackling accessibility was we need to figure out this whole context switch awareness thing because -- this is back then obviously when we first got started -- back then there was no way for a user to know when the page changed so they would basically be sitting there, waiting for any kind of feedback or whatsoever to be presented back to them and it just wasn't happening.

I would say, managing focus is probably one of the top level concerns when it comes to single page applications because it's a single page application so if you click a link, the page isn't completely refreshing, prompting the screen reader to present the information back to user. That’s one of the key areas that I think of.

CHARLES: What about things like asynchrony because a lot of times, these context switches are not boom-boom, one-two. The content on which you want to focus isn't available yet. Usually, the analog from a visual UI would be a loading spinner or a progress bar. How do you deal with those to say, "Your content is not quite ready. If you're made to wait it's because we want your content to be of the highest quality."

KRIS: Sure, yeah. We were able to drop in the focusing outlet components in our application and it took care of a good chunk of the work but it seems like in our application, we're doing something that might not be as conventional as the rest of the Ember community would like them to be so we might not use the model hook as we should. It’s hard for the page to know when the contents actually ready, when it's been rendered to the DOM to present back to the user. One thing that I'm currently trying to tackle right now, to figure out how we can remedy that problem. I probably say, honestly that's the challenge I'm working on right now. I don't have a solid answer to that one at the moment.

CHARLES: Irrespective of how it plugs into the tool that you're using, what would just be the desired interaction there, regardless of how you make it work?

KRIS: I guess, conceptually what I'd be thinking about is how can we notify the user we're loading content right now and whether that we have an alert box that has the ARIA alerts, basically attributes set on it, that we could pass in new, basically notifications to it to let the user know, "Loading content. Please wait," and then once that content resolves, focus them on that main outlet where the content has been displayed to read that content back to the user. That's how we're trying to think about tackling this issue but we haven't have a time to implement it to see how it's going to work across all the different avenues of application.

CHARLES: I did want to come back at the component level. are there any other ways that you can lean on Ember or lean on React or lean on Vue, if you're using a component or in framework, just talk a little bit more about how you use those to unlock your application and make it more accessible.

KRIS: One thing I can think of is a way that we can enforce better usage of the framework that we're using is one that comes to mind is a component that I worked out in the blog series that I wrote was building a form input component. Especially, when you're trying to write an accessible app, I think about how can we enforce certain patterns when other developers come in later on and want to add a field to a form or use this component somewhere else in the application. What are some ways that we can enforce that they're doing everything, using the component correctly so that way it renders accessible mark up?

What I tinkered around with and we actually just landed in our application is basically a form group component to where we pass in, obviously the value that the input is bound to. But we also pass in a label that is tied to the input and whenever you hit save and the app goes to refresh, if you don't pass the label, there's an assert statement that basically fires up an error into the console and lets you know, "You're trying to use this component, you need to pass into label attribute for the purposes of accessibility and here's the instructions on how to do it."

We've been kind of toying around with this idea of enforcing patterns because again, we have several dozen developers at Q2 that are working on this stuff and they're not all wizards when it comes to accessibility but how can we gradually start getting them to the place where they're adopting these patterns and best practices. I'd say, doing things like that, we are enforcing patterns in the usage of the components as well is really a key. One thing that we implement it in our testing framework is the use of a Deque Labs' aXe engine to basically go through, we can pass it a chunk of HTML and it will give us any suggestions that it has to make that content more accessible. We're using that in our test library right now, in our test build and encouraging developers as they write new components, as they go in and modify components to throw new snippets in to make sure that the content that's being spit out here is accessible and then submit your PR again. Just trying to be more hands on in that way.

CHARLES: So you actually running a GitHub agent or something that's actually in the same vein as your test suite or if you're taking like snapshotting with Percy for doing visual diff so you're actually running a third check, which is an accessibility check?

KRIS: Right now, we were able to land the aXe engine into our test build a couple months back so we're just slowly incrementing that over time. We have a couple challenges in the way of getting Percy implemented but that is in our list of goals to have that running as well. But one thing that I really like about aXe engine in particular is that if your check fails, it refines improvements that you should be making. The nice thing about it is also spits out a link to a page on Deque Labs website. They give an explanation of what have found and basically educates your developers for you.

To me, I think that's huge because again, we can't educate every single developer and expect them to be pros at this but we can utilize tooling like the aXe engine or the [inaudible] Chrome extensions or stuff like that to do some education for us. As we work towards automating this further and further by using the aXe engine in our development side of things or using Percy on the test build as well. See, there's all kinds of stuff you can do but that's where we are right now.

CHARLES: I really like that idea because in comparison with what we talked about at the top of the show, about how there's this path of least resistance that developers will follow quite naturally and quite rationally, which can lead to not accessible applications. It sounds to me like what you're doing is a establishing the same path of least resistance but having that path guide you towards accessible applications and saying, "This path of least resistance thing, it can be an asset or a liability so we might as well make it an asset."

KRIS: Yeah, for sure. We sit down once a week and we talk about whatever challenges we're trying to work through in terms of accessibility. We have a weekly meeting where we sit down and talk about it. I thought one of the key topics to those conversations is how do we get the other developers that are not in these meetings more aware, more informed and more up to speed with this that they care about it, that they're working on it and it's part of their inner dialogue as they're writing out new features that are going to be deployed out to our clients. Lots of challenges there.

CHARLES: Yeah. We’ve talked about some of these problems that you catch, you're actually writing some assertions there on the test build so you'll actually fail if there's certain requirements that aren't met but what are the things that are more intangible? How do those come up in terms of accessibility? What are the things that you can't catch through automated testing?

KRIS: Right now, some of things that we're having a hard time testing which Percy will help once we get that implemented is contrast ratios and stuff like that. That’s one of the key things that comes to mind for me when I think of the things that are a little hard to catch. I think another thing that's hard to catch, especially at the aXe engine and stuff like that, won't necessarily catch is the flow of your dialogue. When I turn on a screen reader and it starts reading back this page and content to me, sure we can make it so that it doesn't read out the icons character code and a lot of stuff. It presents the information we want back to us but I think, having that information presented back to the user in a way that's legible, that makes sense to them is probably one of the bigger challenges that I've been working on a little bit.

One that comes to my mind is like the reading of currencies or numbers. One thing that I found way helpful was Deque put out a very thorough article on how the different screen reader like JAWS, NVDA, Apple's VoiceOver, how they read different types of punctuation, different types of graphics symbols, how they read [inaudible], $123.50, what does a screen reader actually read back to you. That's where I've actually been spending so much of time lately is building on some components that instead of reading back what the streaming will read back by default, which should be, "Dollar sign, one-two-three-five-zero," having actually read back, "One hundred twenty-three dollars and fifty cents," so basically, writing a series of components, I would do some of that, again heavy-lifting force, in that way, our developers don't have to go in and manually add-ons aria-labels obviously.

That's been a nice little challenge where something that's we are working on just testing right now and making sure it works right if there is any downsides to doing this but I want a person using a screen reader or other types of assistive technology to hear the information as I'm thinking about it. When I see $123.50, I'm thinking in my head that's, "One hundred twenty-three dollars and fifty cents," not in single digits one right after the other. Those are things that a lot of the automated software isn't catching. It’s not catching like, "Your grammar is bad," or, "This isn't making any sense to me." It is catching like are you passing in or applying the attributes to HTML elements that you should be. Are you using semantic structure in your headings and stuff like that?" I think that's one of the areas where developer is need to get their hand dirty, turn on the a screen reader or use any array of different voice-over tools to actually listen to the content being present back to them to see how it's presented.

CHARLES: Yeah, it's almost a difference between a syntax error versus a runtime error like we've got a lot tools that can catch the syntax errors and you can put those in and catch where you have something that's malformed but some sentences can be perfectly formed but make no sense and it takes a human set of eyes to make sure if that content is coherent. One of the things that if you're going to ship applications to people, you need to be able to try and measure as closely as possible the environments in which the people will be using your software so you can actually have an accurate measure of whether it works or not.

For example, in the Ember world lately in the stuff that we've been doing with acceptance testing in React, we admit people are going to be using a multiplicity of browsers to access this application so it's very typical to use Testem or use Karma to fire up five different browsers, which if you're using BrowserStack, you can do fifty. You know, people are going to be using IE8.1 on Edge or on a Surface. They’re going to be using Safari. They’re going to be using Chrome and those often surface those issues but I feel like there's no access to the actual screen reader and assistive technologies to be able to make real assertions against those things.

I imagine that it would be cool if there was some way that in Testem or in Karma, you could have one of your browsers be like an assistive browser that you could actually assert, I want to assert that it read it as, "One hundred fifty-three dollars and twenty-five cents," and is that on the horizon? Is that even possible? But it seems like something that we have to shoot for if we actually want to measure that these things are working if we actually want to capture data points.

KRIS: Yeah, I totally agree. If you look at the documentation on W3 for how these different HTML attributes should be treated by the browser or by the assistive technology, long story short is this is not how -- in several cases -- certain screen readers are presenting the information back to you. It’s not how it's treating the content. That’s again, one of the areas I thought was way interesting about that. Deque article on punctuation and typographic symbols, which is like we should expect that this software is operating at this level to present this information back to user in such a way where it understands what the dollar symbol in front of a series of numbers means but it just isn't there yet. There’s still work to be done. I'm hopeful for the day where our screen readers are a lot more powerful in that capacity.

One that makes me a lot more hopeful about that is I don't know if it's just because I've been more interested about this over the last year but it does seem like I'm seeing a lot more people talk about accessibility. I'm seeing Apple putting out videos, talking about the efforts that they're making to make their software more accessible. It does give me hope that there's a lot more visibility on this now. There’s a lot more people fighting for this cause to cause these companies to come back and say, "We're going to put more effort into this. We not just going to make a standard screen reader and ship it and just leave it there for five years and no one was going to touch it," but, "We're going to start making improvements."

One thing that I did notice just over the last couple months even was that out of nowhere, we use Apple VoiceOver in Chrome, which isn't typically how people use it. They typically use it with Safari. But if you use in Chrome, it will actually read back to you as, "One hundred twenty-three dollars and fifty cents." When I came across that, I was kind of dumbfounded but then I was thinking to myself, the vast majority of people who are using screen readers aren't using this browser but that's really interesting that they're doing this now. I dream of that day where we can basically run a series of mark up through in a test or into a function and basically have to spit back, here's how screen readers going to present this back to you. I'm hopeful for that day.

CHARLES: I'm wondering now like why don't major browser vendors, why is this not just a piece of a puzzle that comes when I download Firefox. Firefox has access to my speakers, why isn't there a web standard for how screen readers will treat content? Maybe there's an effort under way.

KRIS: I sure hope so. Looking through documentation, we know how things are supposed to work, how we've agreed that they should work and now basically, we're just waiting for the different browser vendors and Microsoft and Apple to make the updates to their streaming technology as well as JAWS and NVDA. I'm hopeful that these changes come soon. These are improvements to the interface.

CHARLES: Yeah. Any time there's a gap, you can see that's an opportunity for someone --

KRIS: For sure.

CHARLES: -- To write some software that has some real impact. I know certainly, I would love to see some way to roll these things into our automated test suites.

KRIS: Yeah. I searched for it but with no avail and it's a little bit beyond my knowledge of how to build something of that caliber. I hope someone else does it because I don't know how.


CHARLES: Well, maybe in a year, maybe in two years, maybe in 10, although hopefully a lot sooner than that.

KRIS: Yeah. I would judge that at the speed of things were going right now, I'm optimistic that we're going to have some much better solutions within the next year or two on this field. Especially of how much I'm seeing people talk about it now, how much it's becoming a part of the regular conversation of web development, application development. I'm really optimistic that we're going to see some strides in this area over the next couple years.

CHARLES: Okay. With the time that we have left, I'm going to ask one more question. Kris, there is something that I wanted to ask you, which is let's say that I am a developer who is working on a team that is maybe it's big, maybe it's small. I've got an application or I'm starting an application and I have a desire to make it accessible. How do I establish that path of least resistance? What advice do you have for someone who's just about to take the first step on that journey to make sure that they have the outcome that they're looking for which is the most accessible single page app that they can have?

KRIS: I think it's a great question. I would start out that answer by simply saying to encourage you to be somebody who cares enough to speak up and become an evangelist, become an educator and become an enforcer in your workplace for this work. You don't have to be the most knowledgeable person in the world on the topic. God knows I'm not and I still there were people come to me, asking me, "How do I make this feature, make the guidelines, make it accessible to screen readers," but I'm passionate about this topic and I'm interested in learning as much as I can about those.

Step one, just being an evangelists for it. Be interested in it, care about it. I'd say, the next thing is just learn more about semantic HTML. I would say from a lot of the things that I've been trying to tackle with the application that I'm working on, just simply writing semantic markup takes care about 80% of my challenges. In just understanding what are the different elements, what are the different tags are for and how screen readers and other assistive technology see those things.

To get started, I would say there's beginner, intermediate and advance stuff. I would say go to the accessibility project, which is just and read through the content there. It’s very entry-level. You can probably read through most of the content within an hour or two and really start to get a grasp as to what level of effort you're looking at in terms of your application. Once you get through that, if you still want to learn more, I'd say go over to Mozilla's developer network -- MDN -- and read through their documentation.

On the topic, there is a little bit more exhaustive but it's still really easy to read and really easy to grasp. Based on a content they have shared there, I'd say more of an advance level is actually go through all the documentation on the W3. It’s a lot more verbose, it covers a lot more of use cases, it has a lot more suggestions and just stuff ready to go over. I'm still working through that information. There's so much of it but I would say that's as a good place to get started with understanding the different attributes, what they're for and just the importance of writing semantic HTML.

I would say some definitely good things to start tinkering with to find some of the low-hanging fruit in your application would be to use some of the assessment tools that are already out there. You have the [inaudible] little JavaScript snippet that you can put in your Chrome favorite's bar or you can use the aXe engine or if you even have an aXe Chrome extension that you could pop up in your application to basically give you report on some of the areas that you should be looking to make some improvements.

I think it's important to view accessibility kind of like how a lot of bloggers view SEO, is that there's always more work to be done, there's always improvements you can make but the key is to take those first steps and start making those improvements. One of the nice things about the accessibility project and there's a couple other websites out there that have some of the lists, they basically have a checklist for you to go down. If you're just getting started with accessibility, they have a checklist of all the first things that you should be covering to get your app started in that realm, to start making those improvements. I know you guys do links in the show notes. I can definitely send you those things to those items to get people started.

Another thing I find myself doing a lot is while we're talking about something in our chat at work in or just go off in the code pin and mock something out in HTML and then see how the screen reader reads our content back to me and then kind of tinker with it and do a little bit of self-discovery in how this all works together. There’s a lot of options out there. I know just threw a lot at your listeners but I'd say, it all starts with being someone who cares about the topic and cares enough to start asking others to care as well.

CHARLES: I think that's a fantastic answer and a great note to end on. But before we go, obviously we will include those things in the show notes but also the other thing that we're going to include is a link that you actually, I understand, have a series of blog posts related to all of the things that you've been talking about, which we'll also include.

KRIS: Awesome. Thanks.

CHARLES: Everybody, go read it. Thank you so much Kris for coming and talking with us about accessibility. I think you're right. It is a topic that's gaining a lot more traction and a lot more mind share in the mainstream that can only be a good thing.

Jun 08 2017



Rank #6: 101: Fullstack / Backend / Frontend: What’s the Difference?

Podcast cover
Read more

In this episode of The Frontside Podcast, panelists Charles Lowell, Rob DeLuca, and Sam Keathley, discuss how much the distinction between frontend, backend, and fullstack developers matter in both personal and professional senses.

The differences in mindset between these categories are also discussed, for example, how does a fullstack developer solve a problem vs how a backend or frontend developer? And also, how clear (or fuzzy) is the line that separates them? What are the skills a frontend or backend developer needs to consider themselves fully fullstack? And finally, is there any sort of tribal separation between the factions?

Do you have opinions on this show? Want to hear about a specific topic in the future? Reach out to us at or on Twitter at @thefrontside.

This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC.


CHARLES: Hello everybody and welcome to The Frontside Podcast Episode 101. My name is Charles Lowell. I’m a developer here at The Frontside and I’ll be hosting today’s episode. Today we’re going to be talking about the different developer profiles that are out there. You might have heard mention of them on Stack Overflow, on job boards, on the Twitterverse. Things like frontend, backend, full stack, half stack, short stack. [Chuckles] Things like that. With me to talk about these are Rob and Sam. Rob is our director of open source here at Frontside and Sam is a software engineer here at Frontside. So, hey y’all.

SAM: Hey.

ROB: Hey yo.

CHARLES: Alright. So, before we get into the meat of the topic, there are a few announcements that we wanted to make. First and foremost, this is some really exciting news. This week, Taras Mankovski officially joined the team at The Frontside. And we are really, really excited about that. [Cheers]

ROB: That’s exciting.

CHARLES: Yeah. It’s super exciting. Not only is Taras an exceptional engineer, he’s got amazing code skills. He’s extremely empathetic and a great person to work with. He’s great working with clients and he’s also fantastic at really working with developers who are climbing that ladder and helping them level up. So, he’s been involved in mentorship literally since I’ve known him. I think that was the first time that we ever came into contact with him was through his mentorship work in the Ember community. And we’ve been collaborating with him for years on several open source projects. And so, we just are so excited and know that he’s going to come on and do some amazing things by helping us be better developers, helping us be better community emissaries. And so, lots of good stuff coming out of that.

ROB: Absolutely.

CHARLES: Yeah, yeah. No, that’s really exciting. So, definitely wanted to throw that out there.

ROB: Too bad he didn’t join a little bit earlier. We would have had a good time with him on this podcast.

CHARLES: I know. Well he’s actually, I think he’s been on the podcast twice.

ROB: [Laughs] That’s true.

CHARLES: But yeah, there’s definitely a couple of topics where his input would have been absolutely critical. I think it would have been great to have him along when we were trying to run our own apprenticeship programs. Those would have worked out I think a lot better. Well, not to say that the outcomes haven’t been stellar in some cases. But I think having his expertise would have made it a lot smoother. That said, before we jump in then, just wanted to let everyone know that as always, if you want to work with us you can get to us at or send a shout-out on Twitter @TheFrontside. Okay. Y’all, let’s jump into it. Like what is even a stack?

ROB: [Laughs] So, do you want to kind of set up where this came from, Charles? I think it came from you and I going back and forth on Twitter. And I was like, “You know what? We need to talk about this on the podcast.”

CHARLES: Yeah. I think I was actually on vacation.

ROB: [Laughs] That’s right. You were trying to ski.

CHARLES: [Laughs] I was on the ski lift. And I saw you tweeting and I was like, “No, no, no. I got to respond to that.” Probably because there was maybe a little bit of disagreement but also because I just needed something to do. Looking out the majestic scenery of the Rocky Mountains wasn’t enough. So yeah, what’s the backstory there?

ROB: So, I can’t remember what I was actually tweeting about. But I kind of feel like there is a distinction between a frontend developer, a backend developer, and at this point I don’t know if a full stack developer truly exists. I mean, it does. But it’s used more often than it really implies what they’re doing. Usually when you hear of a full stack developer, it’s like, “Man, I can sling some code on the backend and I can do a little bit of architecture stuff on the frontend. But CSS, keep that away from me.” And in my opinion, if you’re a full stack developer, you need to sling CSS, too.

CHARLES: Really?

ROB: Yeah.

CHARLES: No, no. I certainly agree. Because I was going to ask, is it fair to say that full stack developer is code for like, startup developer?

ROB: Yeah. That’s a good – like a utilitarian, like a jack of all trades but not a master of any?

CHARLES: Right, exactly.

ROB: I can take that. So, I guess the way we can start to dig into this one is like, how much distinction is there between a frontend, a backend, and a full stack developer? And does that matter in a professional sense?

CHARLES: Right. And so, I think my take was that the skillsets that you need in both places are actually much more convergent than you think, than people might think. In other words, the skills that you utilize on the backend actually translate very well to the frontend. I think my stance is that what makes a frontend developer and a backend developer is more the problem sets that you gravitate towards naturally, the things that interest you. I actually was a backend developer. And now I consider myself to be primarily a frontend developer. But the skills that I had developed writing backend systems in Java translated shockingly well into frontend development with JavaScript. But it was working on the portion of the program that interfaced with the human was, that was the thing that fascinated me. And so, it’s what I gravitated towards. And so, I guess in my [6:15 inaudible] or the way that I have been thinking about it is that what makes a frontend developer and a backend developer is more what gravitational pulls you respond to, rather than one particular skillset.

But I know that you’ve got a perhaps more refined take on that, or a different take.

ROB: Yeah. Before I do, I want to know what Sam’s thoughts are on this. This would be a good one.

SAM: Where I come from in the understanding of frontend, backend, and full stack is I – background on me: I did a bootcamp before working here. So, I did a development bootcamp where they were really excited to tell you at the end of it that, “Oh, you’re a full stack developer because we’ve introduced you to everything. Like, touched on every sort of little topic. You’re full stack. Tell everyone you’re full stack.” And it’s like, “Well, you’re not really a specialist in any of the sense.” So, what makes a difference to me, I’m going to specifically talk about full stack, but it’s like before you can say you’re full stack, having knowledge of frontend and at backend, you need to have expertise in at least one of them first, or understanding of that mindset first. Like if I say that I like frontend work more then I need to understand frontend work more before I can say that I understand backend work, you know?

ROB: Yeah.

CHARLES: So, do you feel like the bootcamp was doing you a disservice? Or do you think they got…

SAM: I don’t think they did a disservice at all. So, they did a really good job. So, bootcamps are really for introducing you to everything. And then whatever you take from that is your own. So, they introduce you to all the little things like database working and then JavaScript, Ruby, whatever it is. And then it’s your job to figure out in those introductions, what you resonate most with. So, I think they did a really good job in that. I think that they shouldn't tell you what you are, like tell you that because they touched on whatever it was, that you’re full stack.


SAM: So, I don’t think they did a disservice at all. I learned a lot. But I wouldn't say I’m full stack at all.

CHARLES: So, if you feel as though you’re not full stack, what do you feel that you are?

SAM: Definitely frontend.

CHARLES: Definitely frontend.

SAM: I gravitate more towards frontend.

ROB: Why would you feel that way? Is it because you’re more pulled towards the UI of things? Or is that where you feel like you’ve gotten most of your experience now?

SAM: Actually a little bit of both. I tend to like the UI of things a little bit more. It’s interesting. Whenever I was going to the bootcamp, I thought I was going to be more backend because I thought I really like working with the behind the scenes sort of. You don’t see this work but you know it’s there. But I definitely like the UI of frontend a lot more. Just personal.

ROB: I see that.

SAM: And it’s where my skillset is, because this is all frontend work that I’m doing here at The Frontside. So, it’s what I know most at this point.

CHARLES: Yeah. I’m curious too. Isn’t it true that there’s also a conception in the wider tech world that frontend is limited to CSS and HTML?

ROB: Ooh. Yeah, that could be.

CHARLES: Like when you see job posting for frontend developers, typically it’s like, we want someone…

ROB: Yeah. It’s kind of morphed from – JavaScript developer is now a single-page app developer instead of frontend. Yeah. Yeah, I see what you're saying. It’s now, it could be considered as HTML and CSS and not JavaScript anymore. [Chuckles]

CHARLES: Which is so bizarre to me.

SAM: [9:42 inaudible] a lot of places when a frontend developer who is also a UX designer. Someone who has the knowledge of designing things from the ground up and then only working in things that look good, rather than logic.

ROB: Yeah. This can be probably an entirely other topic. But that’s like the frontend of the frontend and the backend of the frontend, is like [10:03 inaudible] call it. Because there are [10:06 inaudible] developers. And single-page apps have gotten so complex these days, between your data layer and your testing and managing state on the frontend. There is a backend, an architecture, that you need to consider when you’re developing a single-page app. And I’ve worked on teams where there are developers that are working on the frontend but they still don’t like CSS. They don’t do CSS things and they don’t consider layout or any design. They just take the ticket and they get the data going. Get the data from the server, request it, display it on the page. And then another person would come through and style it up to the spec or the mock. But yeah, that’s interesting.

So for my take on this, and where this actually really came from, is we were going through some hiring. And we were trying to figure out how we can place somebody or hire someone that can be effective in the role that we immediately needed. And all of our immediate needs were in frontend-specific things. And we can actually talk about if they’re frontend-frontend or frontend of the backend. But where this kind of came from or was born was: if we’re hiring somebody that needs to fill a frontend role and they’re primarily a backend developer, there are gotchas and things you have to know to be an effective frontend developer. Like quirky browser things that happen or like how to set up a Babel transpilation setup. And what are the gotchas here? Kind of the history of the frontend web, because there’s a lot of things that are there that can cause a lot of headache if you don’t know the backstory.

And I know from your perspective Charles, you think – and this is isn’t wrong – but you think that if somebody has a really talented backend developer, it’s really just concepts that you can apply to the frontend. And I agree with that.

CHARLES: Right. But you have to want to do it. [Laughs]

ROB: Yes. That is also a key.

CHARLES: You have to be gripped by the problem set of the frontend. You want it to inspire you to leverage those solutions.

ROB: Yeah. So, would you say there’s a different mindset between a frontend, backend developer, and full stack? Does a full stack developer solve a problem that’s different from how a backend developer or a frontend developer would?

CHARLES: That’s a subtle question and probably one that might offend people, my answer to it. So, I’ll go ahead and answer it. [Chuckles]

ROB: Hashtag [12:23 inaudible]

CHARLES: Actually, maybe not. Just in my experience historically – I want to underline the fact historically – I think that it is people who gravitate towards the outside-in mindset, in other words the very first thing they’re thinking of is, “How is this going to feel to a person who’s going to use this?” If that’s your first question that you ask, then you probably are going to gravitate towards the frontend. Then in terms of the backend, I’d say historically – and like I said, I want to underline that, and I’ll get to that later – I think it’s people who are more drawn to: I want to attack the most complex problem that exists. Like distributing state over 10,000 nodes, managing huge deployment infrastructures that drive these massive websites that happen at this mind-boggling scale. And so, there you really are thinking computer to computer and, “What’s the ideal interface for doing that?” And then on the frontend you’re thinking more like human to computer, because that’s where the interface lies. Now the reason I say…

ROB: I feel so let down. Where’s the controversy?

CHARLES: Well, okay. Well, because I think that basically – I think the controversy is saying like people who are more naturally empathetic. I don’t know. That would be the controversy thing. But I want to say historical.

ROB: Yeah. I can see that. [Laughs]

CHARLES: So, I want to say historical too, because I feel like one of the things that’s been magical about the last two decades of software development is the dawning realization that no software you write exists in a vacuum and that it’s all interconnected. And so, I think that I for example feel very strongly while I try to think about the user experience first. And the developer, I’m also thinking about developer experience first. The way that you want a system to feel is going to inform the design of the UX workflow and that’s going to affect the architecture of your frontend. And if you’re interfacing with it through different media, like websites, phone, I don’t know, even text messages, Slack, what have you – that’s going to inform then the next level of how your APIs are shaped, your public-facing APIs. Which then inform the structure of your internal deployments.

So, recognizing that the decisions you make in one end of the stack and ripple through completely and that they’re not what we hold as dear these concepts of separation of concerns and complete and total isolation of layers. That really is false. But what it does is it enables us to change the individual layers to more – ironically the reason you want to have separation of the layers is so that it more easily lets you change them provide a more integrated experience. So, I think that’s a long way of saying that I think frontend developers are more aware of what’s going on in the backend and that they might be drawn into the backend. And the same thing goes for backend developers, realizing that the decisions they make are affected by the frontend and affect the frontend. And so, I think there’s been a dawning more of a collective responsibility for design, for operations, for developer experience. And I think it’s great.

ROB: Yeah. And to [think back off] that. So, I was kind of wondering where the controversy was, because that’s kind of my exact answer, too. Where do you gravitate towards on? The difference of mindset is like, if you’ve got a problem and let’s say you’re a full stack developer, so whatever that manes, but if you’re given a task where you have to implement the frontend and the backend, where you gravitate towards first I would say is how you would attack solving a problem.

For me, I would immediately go to the frontend and see how a user would immediately interact with it and then work out that way. Mostly also because I like having a tight feedback loop. And the frontend provides that nicely. I can change something and immediately see the difference there. And in the backend you can spend a little bit of time, unless you’re TDD which you should be – you can spend a little bit of time piecing together things and figuring out the architecture. And then you’ll have something that you could show for. It’s just nice to see UI get thrown on the page. And it’s real and you click a button and something happens. That’s a really nice feeling. And that’s kind of where I gravitate towards. And if yeah, if I had to attack the problem, I’m going there first. I get the endorphins from it. [Chuckles]

CHARLES: Right. So, if we want to add controversy to the other side, because you got to always be controversial, right? So, we said the really blunt horrible oversimplification is that people who are more naturally empathetic gravitate towards the frontend. You could also say that from the other perspective, people who are more internally validated will gravitate to the backend. Because if you need to get those endorphins from working on the frontend, basically what you’re saying is, “I want to put it in front of people and get the feedback from those people and know whether it’s good or bad.” Whereas you could say, “Actually, I don’t need validation from other people. I’ve got this concept of this architecture that is going to be the ideal thing. I know it. I’ve got this vision and I’m going to chase it, regardless of what’s going on.” I think you can more readily do that on the backend because you’re not as open to the feedback of a whole bunch of different users. And like I said, I think those are gross oversimplifications.

ROB: Yeah. I agree. And so, as a devil’s advocate towards the backend developer that is less empathetic, I think actually some of the best backend developers I’ve ever worked with were the most empathetic people ever. Because they know that software is for humans. And humans are going to be consuming the API that they build. And they take that into consideration.

CHARLES: Absolutely. And I actually think that empathy pervades good software development just wherever you find it. Because yeah, someone’s going to be using your APIs whether it’s software as a service or it’s a library. If it’s software as a service, it’s got to be easy to work with. It’s got to be performant. It’s got to have a nice command line. And so, you have to be thinking at all times, “What is it like to use this software? What is it like to consume it? What is it like to link it into my library? What is it like to call it from a web client?” So yeah, I think you’re absolutely right. I think it’s actually one of the great virtues of great software developers.

SAM: Yeah. So, something that I’ve always kind fo had a question with, especially coming from that bootcamp setting: is there any sort of tribal separation between what you would consider a frontend or a backend developer or even full stack? Like, “I’m better because I understand data layers than I understand how a button fits on a page,” that sort of thing.

CHARLES: I would say absolutely yes. If you at the, just do a quick poll of the Twitterverse, it seems like people tend to hang out in little circles of similar interest. So, there’s definitely a bunch of people that I follow that are always tweeting about backend stuff.

ROB: Yeah. Twitter is ‘build your own echo chamber’.

CHARLES: Yeah. And there are people who I follow that are tweeting nothing but mostly frontend – when I say frontend, I mean frontend of the frontend. Well basically, from CSS down to nothing deeper than React components. And then there’s people who are talking primarily about the backend of the frontend. So yeah, I do think that people – there are clearly, there are different areas of the stack and I think that people do tribalize around them. So, the question is: Who are the border agents? Because always cross-border trade. Any time you have borders, there’s an exchange of ideas and information and things that happen at those layers. And actually, one of the things I’m really curious about is: How does that happen?

ROB: Yeah. You might have the best perspective on this because you did – you were using Java Swing back in the early 2000s building UI. And that’s like backend things. And then you had a lot of experience with Rails and you’ve moved into the JavaScript world. And the thing that I’ve noticed with frontend is, we’re applying a lot of concepts that existed on the backend. And we’re moving all that complexity into the frontend. And that’s kind of where that fuzzy line of, “Are you the frontend of the frontend? Are you the backend of the frontend?” comes from. And it’s interesting that – like this is going to be another podcast. We’ll end up talking about this – but we have – MVC lives on the frontend. Like in React, your C is a container component. The controller is a container component. The model is probably your Redux layer if you have it or if you’re using micro-states. And the view is your components, your view layer components that you're rendering down. So, these concepts are moving from the backend to the frontend. We’re just kind of renaming them and making them our own concept. But they’re there. So, how does that knowledge sharing happen? Is it really just a mass exodus of backend developers interested in frontend developers now?

CHARLES: I don’t know. I think it goes both ways. So, I can only speak to my own experience. And that was when I first started doing frontend development was back in 2003 I think. So almost 15 years ago. We were building a touchscreen interface for an electronics vendor in the UK. And it was just so much fun, because we were getting to build these interfaces that literally looked like nothing else. And you could touch them and you had support for rudimentary gestures and there was no keyboard. And basically the only interface was your fingers and like a price scanning gun. And everything, all the entire UI had to be developed out of that. And so, it was such a novel system and it was so fun to implement that I just gravitated towards it. I think the thing that was particularly compelling was it was very interactive UI. It was high-touch, literally. This is a clerk who’s sitting there using this thing as rapidly as they can to sell stuff and move people through the line. So, it was like a unique problem.

But the thing that was cool about it was I realized so many – we kind of already touched on this in this conversation – so many things that I had learned on the backend applied there. And there was in order to provide that experience, there had to be a pretty complex machine behind it. And that was fascinating, that machine. And so, we were able to apply a lot of the concepts. And so, in that time on the backend I’d just come off working off a backend that had basically an event bus – we would probably call them microservices now, although we didn’t call them that then – were coordinating based on all these events. And that translated over into the frontend really, really well. And I remember using a lot of the techniques for exception handling – doing it on the frontend and doing a lot of the multithreaded stuff that we were doing on the backend, trying to reconcile that with the frontend and really understanding. So, there were all these analogous concepts.

And it could be – so, there was an original exodus of backend development, for me personally. And so for me, it was like I felt like I moved onto the web pretty much exclusively in 2006. And it was a good – I would say 2013 maybe is when web UI development finally caught up with Java Swing. Like it was like, that whole time I was like, “I’m using the web because it’s an awesome deployment platform. And it’s got all this great stuff,” but man, the developer experience is not as good as like a stateful fat GUI was back then. And now, I would say it’s actually surpassed quite significantly. But now, I think there are a lot of people maybe who either – I think there’s a casting back of people who are in frontend development and casting back to the web.

So right now, my love affair with immutability and functional programming started by using a Clojure web framework which borrowed a lot of the ideas from Clojure. So, I guess there was an exodus there – people from Clojure wanting to develop apps, wanted to have their goodies. But then I found that and I was like, “Whoa, that’s awesome.” But then that really set the hook for me. And so now, I try and go back to the well, the backend well or the shared computational well, as much as I can. So, all of that stuff of basically discovering all this functional programming stuff, this highly formalized functional programming, all came from saying, “Wow. I got a taste of that. Let me get more.” So, it’s very much like trying to run through the village of the backend and ransack the stores and take as much as I can and bring it back, because I know that it’s good.

ROB: So earlier in the podcast, you said that you were a frontend developer. You described yourself as a frontend developer. And that’s funny, because I actually consider you a full stack developer. It’s because you can jump in on the backend and sling any kind of code as well as anybody could, and then you can also do the same thing on the frontend. So, the question I have here is: Do you think actually someone that truly is a full stack developer – and we can define that in a second – but do you think they’re at an advantage here, because they have all that experience? You can answer yes. But why? Why do you think they have an advantage?

CHARLES: I think they have an advantage in the same way that a person who’s bilingual has an advantage. So, if you are living in North America, it behooves you to speak Spanish because you are now open to an entire set of markets that were previously closed to you. Well, not entirely closed but like you can trade with Mexico and you can trade with South America. You can buy and sell goods. You have access to yeah, emerging technologies that might – something special might be happening in Mexico City, or in Medellín, Colombia, and you’re going to have first access to that. And so, if you don’t, if you’re not bilingual, then you’re going to have to go through an intermediary who is.

And so, there’s a premium: you get to be the middle man so to speak. Or you get to be, maybe that has kind of a negative connotation, but you get to be the broker of new ideas and new technologies. If you can, if you are fluent in backend so to speak, then you can go into backend-landia and you can talk with the developers there and see what kind of cool stuff they’re doing. And then you can take it across the border into frontend-land and sell it. And so, that’s – I think we’re very much first to the gun on – not first to the gun but we’re ahead of the pack in terms of functional programming. Because we’ve seen that. We’ve seen it proved out and we’ve now actually started to integrate it into your day-to-day routines. And we’re ahead of the pack on that, right? And so, I think that’s kind of a keystone analogy for me that I think really, really captures what is the advantage in being a full stack engineer.

ROB: So, well how do you define a full stack engineer or developer? What things do you have to possess to actually claim that title? In order to be a full stack developer I personally believe you have to know, you have to be comfortable with CSS. You can hate it. You can yell at it. But I think you have to be able to put together a layout if a designer gives you a comp in order to claim full stack. And in the same token, if you’re a full stack developer and you mainly came from the frontend, you should be able to implement backend features. I don’t actually have – so, I’m strong in the frontend, not so strong in the backend. What would be the analogous of CSS in the backend? Would it be like mocking your controller actions? [Chuckles]

CHARLES: I would say you should have a familiarity with HTTP and REST, would probably be the equivalent. Kind of like a foundational technology that just every single technology is oriented around it, or most. Regardless of the protocol you’re using – there are things like GraphQL which are not really RESTful, although it’s a blurry line there – but they’re still delivered over HTTP. And so, understanding things like CORS, understanding the things that are going to be universal to APIs.

ROB: I think a lot of people try to claim full stack. I try to claim it. And I know I’m not. I can put together a pretty crummy Rails API on my own for personal projects. But I’m not going to be the one that’s setting up indexes on a database to optimize a database or anything. I think that does come in time, but you have – borrowing from Brandon Haye’s talks about career development – if you’re a full stack developer, I think you end up having to be in the industry for a long time. Longer than what we consider a senior developer these days, I think. Because you could be a senior developer and be specialized. And we see that all the time, and that’s okay. But in order to amass that knowledge and experience, I think you have to be in the industry for a long time and done those things a couple of times to really know.

CHARLES: Yeah. I agree. So, can I add something there? To continue the analogy of being full stack is like being bilingual or multilingual. I go back to those analogies a lot because that’s what I – linguistics is what I studied in school. But when I was studying linguistics, one of the things that was going on there was they were kind of redefining what…

ROB: That makes so much more sense of your vocabulary. [Laughs]

CHARLES: What it means to be bilingual. There was kind of a reorientation of that definition that was going on while I was in school. And that was being bilingual doesn’t necessarily mean you’re able to converse about poetry or like deep technology or give speeches in another language. It really is, it’s as spectrum of…

ROB: Ooh, that’s quite interesting.

CHARLES: The definition of bilingual is like: Do you use another language in your life? So, if you are let’s say someone who is a recent immigrant to a country and let’s say you’ve got less than 1,000 words but you’re using them to buy groceries, to pay bills, to do things like that, then you are bilingual. Bilinguility is not an exclusive club. It’s really, are you actually using a language? So, if…

ROB: Ooh, so that actually gets my wheels turning. Does that mean that you can have a junior full stack developer? Because like, if you just merely speak the both languages, technically by that definition, I jive with that. You can speak two languages. You are bilingual. You can write in two different languages. You might be full stack. But does that mean in the software industry you are a junior full stack developer and then as you go on and get tasks that are full-stack-like, you get better on both sides? Or is it as an industry, we really have to specialize?

CHARLES: To start on the first point, I think that if you – let’s just restrict it to one language – if you’re doing JavaScript on the frontend and using Node.js on the backend, if you're writing Node code you are I would say by definition, and certainly by the definition of bilingual that I just proffered, you would be considered full stack, a junior full stack developer like I was saying. And I think that it’s just been my experience that as you go on in your career, you will cross multiple layers of the stack just because you can’t keep your hands off. If you have an ownership mentality of, “Here’s this thing that needs fixed,” and it’s on the backend, you know what? I’m going to go ahead and learn a little bit of how to do this, because I need it to work with the thing that I’m working on.

ROB: Yeah, that makes sense.

CHARLES: You will just naturally be drawn over borders throughout your career just because someone's got to do it, to do the thing that…

ROB: You got to solve a problem.

CHARLES: Right, when you’ve got to solve a problem. So, I think that people become more and more full stack over the course of their careers. But that said, I do think that there are clearly areas where functional specialization is absolutely a requirement. Like if you say, “You know what? We’ve got this API and we need to support 600 queries per second and we’ve got this huge, crazy deployment…”

ROB: I will not be your person to do that.

CHARLES: Yeah, exactly. That’s something you’re very much – that is something that you’re very much hiring for. And you want to be hiring for like you said, someone who has the skill and someone who, that’s what they want to do.

ROB: Yeah. If you need better state management and rendering performance and testability on the frontend, I’m your person. [Chuckles] If you need me to scale your API, to handle hundreds of thousands of requests a second, nope. [Laughs] So yeah, I agree with the specialization. So Sam, I want to know. Has this conversation swayed you any way? Are you more interested in being full stack or are you leaning to a side more? [Chuckles]

SAM: So, I think full stack is, it’s as much about skillset as it is about personality. So, like you were talking a little bit earlier on how someone who’s frontend might have more empathy towards the user. And someone who’s backend might have more empathy towards the computer and the developer, rather than the end user. I think someone who’s full stack has to have a wider range or empathy so they can empathize with all rather than just one or the other sets. I think personality-wise, I’d be a fine full stack developer. But I think professional-wise, I do gravitate towards the frontend because that’s just how I am. As a person, I like to see the visual rather than the concept. I do a lot of painting. I do a lot of drawings. So, I’m a very visual person. So, it’s really helpful to me, especially for someone who’s junior and who’s still learning and who came from that bootcamp experience, to be able to see what I’m changing. So, I think it does kind of go a little bit into experience as well. So, I think over time when I start touching on maybe some more backend work and I see some stuff that interests me, definitely I’ll gravitate towards it, just because I want to learn. But I don’t know that it’s like an intrinsic quality, you would want to be full stack or be backend or be frontend, you know?

ROB: That’s interesting. Yeah, I agree with that.

CHARLES: Yeah. That is actually a really interesting point. Because I think what I heard you say there is that when you have – software is a hidden world in many ways. You talked about it in the beginning of the conversation, the areas of the site unseen. Like you know it’s there but it’s hidden from view. So, there’s a certain amount of vision that needs to develop. So, you kind of internalize what software, like this hidden software, looks like. So what does a deployment of some load-balanced microservice clustered thing look like? Most people would not be able to answer that question. But the more time you’re exposed to it, the more it becomes burned into your inner vision.

ROB: Mental model?

CHARLES: Yeah. You develop a mental model. Your brain literally wraps around that. It takes time. But on the frontend, especially if you’re a visual person – but I would say even if you’re not – I think the same would apply to someone who’s using assistive technology. It’s still something that you can feel with your sense and you don’t have to develop a sixth sense to perceive it. So, there’s literally a problem of perception there. And so, maybe frontend work is a great on-ramp for everybody, because it’s so perceptual.

ROB: That’s exactly why I picked it. I was trying to do iOS dev before. And I could not do it for those reasons. I didn’t have that nice tight feedback loop of even though it was UI, in Objective-C you had to construct your UI and buttons out of Objective-C. Unless you wanted to use Apple’s Interface Builder and that was, meh. Everybody built it procedurally. And what I loved about HTML and CSS, was I could instantly throw something on the page, attach some CSS to it, and see it change immediately. And that felt so good. [Chuckles]

CHARLES: Yeah, yeah, no. And it’s important to get those really tight feedback loops, especially when you’re starting out.

ROB: So, if we had to tie this back together, did we decide that there is a distinction between frontend, backend, and full stack? And if there is, or isn’t, why?

SAM: I think there’s like…

CHARLES: I don’t know if we’ve… go ahead.

SAM: Kind of a distinction. But it’s also really fuzzy, I would say. So, if I’m going to explain what the difference is between frontend and backend to someone who maybe isn’t a developer, I would always go back to a video game. So, when you see your guy…

ROB: Ooh, this is interesting.

SAM: Yeah. [Chuckles] When you see your guy running around and you’re like, “Oh, this game looks really good. I’m really into these graphics,” but do you ever think about what it takes to save the game or what is actually being saved when you go to save it? So, if you’re more interested in making the guy run and making the guy and the environment look good, you might gravitate more towards frontend. But if you’re really interested in saving the data, like well what is being saved when I hit ‘save to this slot’ or whatever? Then you might gravitate more towards backend.

ROB: Or like the network layer of the online multiplayer?

SAM: Yeah, yeah.

ROB: [Laughs] That’s interesting. I’ve never used video games as an analogy. I always go like, you know, if you’re a frontend developer, you know that button that you click? That’s the button I create. And then the action that happens is usually what the backend developer does. I think I like the game analogy better. [Laughs]

SAM: I think the game analogy is something that most people can grasp. And most people can grasp. Like I’ll tell people the difference between frontend and backend if I’m talking about Facebook. Like what I do for a job is I’ll show you everything that’s on your Facebook page. And when somebody, or the backend is somebody who makes all of that come into play, kind of, you know? But I think video games are easier to conceptualize that abstraction of data being saved rather than trying to explain the intricacies of Facebook to somebody.

ROB: [Chuckles]

CHARLES: Yeah. No, I like that. I like that. So, I guess if we achieved consensus, would we say that these do exist as broad functional categories? And a full stack developer is someone who will move in between those functional categories through the course of their career. And that generally, the trend is that the longer the career goes, the more you will do that.

ROB: Yeah. I can get on board with that. I’m going to use your career as like the guiding post of that. The way you just explained it, it kind of made something click for me. You describe yourself as a frontend developer. And I think in our industry with software development and the way teams work, I think you end up specializing no matter if you call yourself a full stack developer or not. Because I do think you’re a full stack developer. But you’ve mainly been working on frontend for the past what, three years, four years? So, I think it’s okay to call yourself a frontend developer. But you are a full stack developer. But as you specialize around and amass that knowledge, that’s where you become that full stack developer, right? And so, at one point in your career, you were a backend developer. And then now at this point in your career, you’re a frontend developer. But now you have those experiences and you can draw on both of them and apply them across the fields, right? That’s super interesting to me.

So, maybe it is that you have to specialize in order to achieve the full stack. And you’re never truly a full stack developer in your role. But it’s possible, depending on the team and the team dynamics. It’s just interesting that you can be a full stack developer, also at the same time be specializing as a frontend developer at that current time, right? Yeah, that’s interesting.

CHARLES: Alright, so it sounds like consensus achieved. Let’s all virtually hug. [Chuckles]

ROB: Send the hug emoji.

CHARLES: Alright everybody. That is our show for today. We are The Frontside and we build software that you can stake your future on. We would love to hear from you, especially if you have an idea for a future podcast topic. Any news that you think is something that we should discuss, even if it’s not the theme of the whole episode. And we will see you next time. As always, you can give us a shout on Twitter at @TheFrontside or just drop us an email at If you enjoyed today’s podcast, it was produced by Mandy Moore, the inimitable @TheRubyRep. So thank you, Mandy. And see you all next time.

May 24 2018



Rank #7: 114: The Business Case for Experimentation with Elm with Dillon Kearns

Podcast cover
Read more


Dillon Kearns: @dillontkearns | GitHub | Incremental Elm

In this episode, Dillon Kearns joins the show to talk about techniques for experimentation with Elm, making those experiments safe, the concept of mob programming, why you would want to experiment with Elm in the first place, and how you too can begin to experiment with Elm.


This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC.


CHARLES: Hello, everybody and welcome to The Frontside Podcast, Episode 114. My name is Charles Lowell. I'm a developer here at the Frontside. With me today as co-host on the show is David. Hello, David.

DAVID: Hey, guys.

CHARLES: David is also a developer here at Frontside and we are going to be talking about something that we've been talking, I guess a lot about recently and we're talking about Elm. I think we first started talking about this several years ago and then it kind of simmer down a little bit but recently, it's been top of tongue. With us to talk about Elm today is Dillon Kearns. Welcome Dillon.

DILLON: Thank you so much for having me.

CHARLES: I understand that you are a full time Elm consultant. You have a background as a Lean and Agile coach but have recently transitioned to doing Elm consulting full time. Now, what exactly does that mean in 2018 to be an Elm consultant.

DILLON: Actually a lot of my motivation for getting into Elm consulting in the first place is I kind of realize that Elm to me is just an extension of the things that I was passionate about with Agile and software craftsmanship. I'm trying to help teams have a better experience with their code, make it more maintainable, make it easier to change, make it easier to drive things based on customer feedback and I really believe that Elm helps people do that. I used a lot of the background and experiences that I've had with Agile and Lean coaching and a lot of those same skills, in order to help organizations adopt Elm.

One thing I've seen a lot of teams struggling with is trying out a lot of different frameworks. I've encountered teams that have spent months, very painfully trying out different frontend frameworks and having trouble coming to consensus about that. One of the things that I think really helps address that is having an experimental and iterative approach, that you can really use the scientific method to focus on learning, rather than getting it right the first time. I think that there's really a need to help teams through that process of introducing a new frontend framework like Elm, so that that's why I've gone into full time Elm consulting.

CHARLES: That's an interesting process. It sounds like you really need to be constantly sending out spikes, doing research on whether it's Elm or some other technology to help you kind of bridge the chasm to the next generation. How do you actually do that as an organization? My guess, this kind of a question independent of Elm but maybe we can talk about how you see that play out in the context of Elm.

DILLON: Right and actually, for any listeners interested in that question, I would really highly recommend Grant Maki's ElmConf talk from this year. He spoke about exactly that topic and it was at ElmConf that it's relevant whether your team is considering Elm or looking at other frameworks. I think that the key is you need to get good at experimenting in a way that's low risk and in a way that you can be constantly learning and seeing how these different technologies fit in your codebase and fit for your team.

There's a quote that I really like from Woody Zuill. Have you guys heard of mob programming before?

CHARLES: I heard of mob programming from a paper by Richard Garfield a long, long time ago, almost 20... I don't know if it's the same concept.

DILLON: Yes. It gained a lot of momentum these days. Mob programming is essentially pair programming but with more people involved. I've really enjoyed that process actually. I think it's actually a great way to experiment with different technologies because you get all of the minds together and it's a very good way to kind of transfer knowledge and explore things together but Woody Zuill talks about mob programming and he likes to ask the question, "Why did we begin doing mob programming for the team at Hunter Industries that originally started mob programming?"

People would give answers like, "Because it cuts out code review from the process because you have lots of eyeballs on it in real time," or, "Because it reduces bugs," or, "Because it gives you better quality code. It gives all the best ideas into the product in real time," and all those things are valid points that are really good benefits of mob programming. But he says those things may be true but actually, they're not why we tried mob programming. The reason we tried mob programming was because the team wanted to try it. That's a really important point.

The team needs to be experimenting with things that they're passionate about and they need to be exploring things on their own terms. But with that said, another lesson from that story of kind of his team at Hunter Industries discovering mob programming is that the team didn't discover mob programming in a vacuum. Really, the team discovered mob programming because the team became really excellent at experimenting and evaluating those experiments and then, they like to talk about this phrase that Kent Beck coined, 'turn up the good.' When something is working well, we often focus on the negative things and trying to eliminate those things but what happens if we take the things that are working well and 'turn that dial up to 11.'

CHARLES: Yeah, I love that. I remember in the kind of the original layout of extreme programming, talking about how I really just wanted to turn up all the things that were working for 11 or to 11, so testing, refactoring, incremental releases and things like that.

DILLON: Exactly.

CHARLES: I actually had one question that's maybe a little bit of a diversion. This is actually the first time I've heard of mob programming. It's definitely not the same sort of mob programming I learned about in Richard Garfield's paper. I think it was more referring to massively distributed open source in the form which is really kind of commonplace now that happens on GitHub. I think it's maybe, an obsolete definition of mob programming but how many people would be in a mob like two, three, four, five, six, seven, 10?

DILLON: That's a great question. Really, the answer is of course, it depends. That's a consultant's favorite answer but it really does. My rule of thumb is I find it usually three people is a very nice size for a mob. I find that mobs tend towards around three or four people but that being said, it's important to note that mob programming is all about this idea that what is the true cost of programming.

I think that often we look at programming as the act of writing code, initially and that's a very limited way of looking at coding. Because of course, 90% of our effort is spent maintaining code, making decisions around code, reproducing bugs, fixing bugs, communicating with customers about bugs -- bugs are extremely expensive -- the farther out they get, until eventually they get to the point of a customer discovering them, bugs are in extremely expensive part of software. If we can minimize bugs, that's very valuable.

When you look at programming on this bigger scale and look at the bigger picture of programming, then you realize that you may be able to get one person to write the code faster but then, that person needs to code review it. That person needs to go and ask somebody question down the line when they don't have context because they weren't involved in the decision making.

For example, maybe there's a UX person who doesn't have context on certain choices that were made, so there's a lot of churn, so you can kind of eliminate that churn by getting all the relevant people involved right away and that's the idea. In my experience with mob programming, it works really well to keep kind of a core of around three people. Sometimes, somebody goes up to have a conversation with somebody, take a break or answer somebody's question, maybe somebody from another team has a question that type of thing and so, the team can keep coding as a pair or whatever. But ultimately, the idea is that you get faster because you're building up this shared context and you're not spending as much time down the line answering questions, doing code reviews and things like that.

CHARLES: Right. I see.

DAVID: That kind of matches with my experience. Mob programming on previous teams, the way we had it set up is there was a regular mob programming chat session that the whole team was invited to but it was optional. You can just show up if you wanted to and really, that sort of made it so that there was a set of people who regularly attend -- three to five people in a session -- and they were the core group, essentially.

DILLON: Right. That's another great point. Invitation is a powerful technique. If you're kind of mandating the people try an experiment or work in a certain way, ultimately it's much more powerful to let the team experiment on their own and follow their passion and they'll discover great things. It's about experimenting, rather than choosing specific experiments.

While we're on this topic of kind of the real cost of coding, I think this is a good point to talk about this quality in Elm because, I think that this is one of the things that really motivates me to use Elm myself and introduce it to others is that, I think that Elm really get something about programming where there's a sort of superficial ease of certain techniques that Elm kind of goes beyond and says, "Actually, let's optimize for a different set of things that we think make code more maintainable and more delightful to work with in the long run."

CHARLES: I wanted to also transition between, we were on a little diversions on mob programming but do you use mob programming as explicit technique for introducing Elm when a team is considering adopting it?

DILLON: That's a fantastic question. I absolutely do. Of course, I honor the ways of working in a particular organization or team. I think that's important to do but I do strongly encourage using mobbing as a technique for knowledge sharing and when I'm on-site with a client, I find it extremely powerful as a technique for knowledge sharing and also, let's say you do an experiment, somebody is off in a corner and they're trying out Vue.js or they're trying out Elm or they're trying a particular coding technique. Then they come back to their team and they say, "Hey everybody, I tried this great thing," and now they have to spend this time convincing everybody and saying like, "Wait a minute. You didn't try this, you didn't try it that way. It wouldn't actually work in our context because of this." I think that it's very powerful to have everybody kind of involved in that process so that you can evaluate it together as a team.

CHARLES: Because the thing is like, when you experience win or you experience fail, it's a very visceral feeling and that's the thing that sells you or turns you away. You can argue until you're blue in the face but words have a very limited capacity to convince, especially when compared with like physical and emotional feeling. It sounds like you can get everybody to have that shared experience, whether for the good or for the bad, you're going to arrive at a decision, orders of magnitude more quickly. They have to rely in conviction of that decision spread around the team.

DILLON: Exactly. I think that hits the nail on the head and you say that we have this sort of skepticism of arguments from theoretical conversations, rather than 'show me the money,' but it's actually, try solving a real problem in this and that's exactly as it should be. I think that's one of the big antidote from this problem that I've seen in a lot of environments, where there's this analysis paralysis, especially with the state of the JavaScript ecosystem these days. I think that one of the keys to improving that situation is to get good at trying things, rather than theorizing about things.

We have a tendency to want to theorize and when we do that, then we say, "Can it solve this problem? Can it solve this problem? Can it solve that problem?" You can talk about that until the cows come home but it doesn't get you anywhere and it doesn't really convince anybody of anything. The key is to find very small experiments and what I really recommend and what I'm dead focused on when I'm initially working with a client is getting something into production.

Now, that doesn't mean that you need to have a road map for turning your entire application into Elm. In fact that's the whole point, is that you're not trying to do that. The point is you're trying to get as realistic of an experience as possible for what problems might occur if we do this? Will the team enjoy working with this language? Will it work well with our built pipeline? Will there be any unforeseen issues? You don't know until you actually try it, so you've got to try it and you've got to try it in tiny, tiny steps and low risk experiments.

CHARLES: Right but you've got to try it for real. You don't want to try it with a TodoMVC.

DILLON: Exactly. It needs to be meaningful, to really have a good understanding of what it's going to be like.

CHARLES: I would say that I tend to agree but I've definitely encountered the counterargument and I also think this counterargument makes sense or perhaps where the pushback lies is if I'm constantly experimenting, then what I'm doing is I'm internally fragmenting my ecosystem and there is power in similarity. Any time you introduce something different, any time you introduce one fragment, you're introducing complexity -- a mental complexity -- like maybe I have to maintain my Elm app and I also have to have my Legacy... Or not Legacy, I've got my other JavaScript tool kit that does it in one way. Maybe I've got a couple of more because I've run these other experiments. I'm not saying that there is one way but there is power in uniformity. There is power in diversity. Where do you find the balance?

DILLON: Those are all excellent points. To me, I think really the key is it's about the scientific method, you could say. The thing with the scientific method is that we often forget the last part. We get really good at hypothesizing about things. Sometimes people leave it at that, which we kind of just discussed. Sometimes, people go past the hypothesizing stage and they actually run the experiment and that's great. But then, the majority of people, if they get to that point, will forget to do the last step which is to evaluate the results.

I think the key here is you need to be experimenting and this is what it means for it to be a low risk experiment. It means that you're not setting yourself off in a direction where you can't turn back. You want to set it up in such a way that you can turn away from it with minimal cost. One of the things that is really helpful for that is if you build a tiny, independent, little widget in your application, try building that in Elm. Some people will do that with a little sort of login badge in the corner of their application.

One of the teams where I've introduced Elm at a Fortune 10 company, actually where we introduced Elm, we started out with just a tiny little table in one page and if we wanted to back that out, it would have been trivially easy but we decided that we wanted to go in further and invest more.

CHARLES: That makes a lot of sense. Effectively, you need to have a Plan B. Don't sync all of the available time that you have to invest in an experiment. Make sure that you have a Plan B and if you need to do this widget or this table in Angular or React or Ember or whatever, you are thinking about that -- how would that work.

DILLON: Exactly and the thing with experiments is the purpose of an experiment is not to build something. It's to learn. I really like this kind of ethos of lean startup, which I think is really getting much more into the mainstream in the software industry, which is a wonderful thing. The idea of lean startup, the kind of core concept is this idea of validated learning. Basically, in an environment where there's uncertainty, which is pretty much most of the things you're doing in software, the main goal is you're not shipping a product like you would be if you're trying to manufacture cars as quickly as possible. The main thing that you're producing is what they call 'validated learning' and so, you want to minimize the amount of time it takes to validate or invalidate your assumptions about something and then, you want to make it as cheap as possible to move on from that.

CHARLES: I like that. So if you're going to organize your development process around this principle or maybe not organize it but integrate it into development process, how do you know that you're conducting a healthy number of experiments, versus I may be conducting too many experiments? Is there a metric that you can look at? We need to have this many experiments running at all times or this is just too many or something else.

DILLON: That's a really interesting question. I think I would tend to think about that more again, as looking at the way the experiments are run, rather than 'are there too many experiments?' That's just not a problem that I've seen there being too many experiments. The pain that we tend to really see in environments where experiments are hurting teams is the way the experiments are being done. It's hard to backtrack from those experiments and as you were saying before, you kind of put yourself down this path where you can't walk it back and you create this sort of rift in the way the code is being written, which makes it more difficult to work in that codebase.

The thing with experiments is they can have really big payoff. Now, you want to make sure that you're not just going in and picking up every shiny object that you see. One thing that can keep you honest with that is if you're kind of coming up with a hypothesis before you start. If you're saying, "This is the value to our business and to our team if we attempt this thing and this is what will prove that it seems to have that value and this is what will tell us, 'Actually, it doesn't have that value and we should drop it and cut our losses.'"

CHARLES: That's a great heuristic. As you're saying and imagining how that might have saved my bacon in the past because I've definitely made the mistake of playing with too many shiny objects and picking things because I didn't fully evaluate what I thought the value. I was explicit with myself about what is the value that is going to bring to this project or this business. I have a theory about it but I am not thinking what is my hypothesis and how am I going to validate or invalidate? I'm thinking, I've got a short term pain that I'm experiencing and I'm grasping for this thing, which I think will solve it and I'm not properly evaluating how it's going to affect me long term.

DILLON: Right and that could be a great team practice to play around with is often, teams will kind of come up with action items out of retrospectives. One thing that I think can be really beneficial for teams is to kind of flip that notion of doing action items which again, it's really just doing the middle part of the experiment where you're conducting the test but you cut out the hypothesis part and the evaluation part. Try to bring that into your team's retrospective and try to have explicit hypotheses in the retrospectives and then, in the next retrospective, evaluate the results.

CHARLES: All right. I will definitely keep that in mind but this feels like a fresh take on kind of how you manage software development that I haven't encountered too much, being more scientific about it. It sounds like science-oriented development.

DILLON: Right.

DAVID: I like that.

DILLON: There are a lot of buzzwords these days in software development, in general and it's really becoming a problem, I think in the Agile community but really, what it boils down to is these basic elements and basing decisions on feedback is one of those fundamental unit. You can call the scientific method, you can call it lean startup and validated learning, you can call it agile, you can call it whatever you want but ultimately, you need to be basing things on feedback.

I think of it almost like our nerves. There's actually a disorder that some people have, which can be fatal, which is that their nerves don't tell them when they're feeling pain. I think this is a great analogy for software because that can happen to companies too. They don't feel the pain of certain decisions not landing well. Because they're not getting feedback from users, they're not getting feedback from metrics and recording, they're not getting feedback from doing that final evaluation step of their experiments, so when you fall on the ground, a small cut could be extremely harmful because you don't know the damage it's doing to you.

CHARLES: I think that is a good analogy. One of the things that I'm curious about is we've been discussing a lot of techniques for experimentation and how you can integrate that into your process and how you can make your experiments safe, so let's talk a little bit about -- first of all, two things -- why would I want to experiment with Elm in the first place? Because ultimately, that's why we're here and why we're having this conversation. What's compelling about it that would make me want to experiment? And then how can I begin to experiment with Elm?

DILLON: I actually just published a blog post yesterday. It's called 'How Elm Code Tends Towards Simplicity.' To your question of why would a team consider Elm, I kind of talk a little bit in this blog post about a case study at a Fortune 10 company where I introduced Elm to a few of the teams there. One of the teams there, we had actually seen an Angular project that they had worked on and often, in an enterprise environment, you have projects moving from one team to another.

I actually had my hands on this Angular project. It kind of moved over to another team and we were experiencing some major pain trying to make changes in this codebase. Even making the simplest change, we were finding that there were a lot of bugs that would be introduced because there's some global variable. There's some implicit state. Sometimes, it was even reaching in and tweaking the DOM and really, the topic of conversation at our team lunches was how afraid we were to touch this codebase.

Fast forward a few months and this team was asking my advice on picking a new frontend framework and I introduced them to Elm. They took a run with it and it was pretty remarkable to see this same team that had really struggled with AngularJS and they didn't really have a strong sense of what were the best practices. They weren't getting any guidance from the framework itself and the tooling around it and they actually loved the experience of working with Elm because they were saying, "This is amazing. Maybe it takes a little time to figure out how to solve a particular problem on Elm but once we do, we know that we've done it in a solid way."

One of the things that I think is most powerful about Elm is that it keeps you from shooting yourself in the foot. I think that's a really good headline kind of summary of what I love about Elm. For example, tweaking the DOM. Now, it might seem like a pretty obvious thing that we just won't tweak the DOM and that's fair enough. That might not be a problem for a lot of teams. People wouldn't even reach for that technique because they're disciplined about it. But at a certain point, you start taking on enough things and then go from kind of those basic things that are going to make your code more unreliable and unsafe like tweaking the DOM and you start getting into the realm of best practices.

There's so much discussion these days in the JavaScript community about best practices, which is great. It's great to discuss that but my concern is that there's a new best practice each week and the team has to agree on it, you have to find techniques for enforcing it, people have to make sure that these best practices are being followed in code reviews. Then when you look at a given piece of code, you have to trust that those best practices are being followed, so it requires a lot of work to make sure, in your reducers, in redux that you are not mutating anything. With Elm, data is just immutable. That's just how it is.

There are a lot of these kind of things that are baked into the language and the expressivity of the type system allows you to bake in your own constraints. One of the things that I find really compelling about Elm is its design really prevents you from shooting yourself in the foot and it gives you tools for making sure that you take it even a step further and it helps you enforce these best practices at a compiler level.

CHARLES: Now what's interesting here is it's almost like the opposite tension of experimentation is a work, right? like here, we have an example of uniformity being the more powerful track but then inside the actual macroscopic process, you want a lot of experimentation and diversity. But at the microscopic level, inside your application, it sounds like you want less experimentation and you derive a lot of strength from that but --

DILLON: That's a great point.

CHARLES: -- Experiments that are possible, yeah.

DILLON: I think that there is a lot of pain these days in the JavaScript community. We hear people talking often about JavaScript fatigue and it's a real thing. It takes a lot of work to stay on top of the latest best practices and frameworks and that can be a lot of fun. I love learning about the latest new frameworks and tooling but ultimately as you're saying, we don't want that experimentation so much about the fundamentals. We want some dependable, solid fundamentals and then we want the experimentation to happen within there. I think that's exactly what we see in the Elm ecosystem.

We have a single kind of data store or way of managing state in Elm. It's called the Elm Architecture. In fact, it's what Redux is based on and it worked extremely well and you don't have to experiment with different data stores in Elm because that's just what Elm code looks like. Now, if you want to experiment in Elm, then there is a lot of innovation happening. One of my favorite things about Elm is that the compiler and its expressiveness has sparked a lot of creativity. One of my favorite things about Elm is the library called Elm UI.

Actually, a client that I'm working with right now, it's a really interesting case study. They are kind of a very small startup. They just kind of branched off of a larger startup. They're building some tooling for this ecosystem. They were engineers at a company called Procore that does cloud document management for construction companies. They wanted to get a product-ready for a big conference for their potential clients. The reason they brought me in to help them was because they wanted to reach this ambitious target of being able to do a demo of this brand new product at this conference and they wanted to iterate very quickly. One of the things that really drew them into Elm in the first place is this library Elm UI.

Elm UI essentially, Richard Feldman gives a talk on it, where he uses the analogy of it being treating CSS and HTML as bytecode for your views. I think that's a really apt way to put it. If you break down this idea of CSS -- Cascading Style Sheets, it removes the cascading part of CSS and it removes the sheets part of CSS. What you're left with is a way of expressing style and it's a way of expressing style that is able to part ways with all of the baggage of the entire history of backwards compatible decisions that CSS has ever made.

If you want to vertically aligned something, then you just say, "Align vertically," you know, center vertically. If you want to center something horizontally, you say center X. It creates a high level language for expressing views. My experience with Elm UI, this may not be the right choice for every team but I love it. I use it on all of the projects that I maintain personally. I love using it because it gives you that same sense of invincibility refactoring that you get with Elm, which is remarkable that you could have that feeling with managing views.

CHARLES: It's definitely something that feels like a dark art and it can't be called science. It's an art. It's a science for some people but it's historically been a dark art and something fiddly to work with. In terms of being able to make the experiment with Elm, when we talked a little bit about why you might want to experiment with it in the first place, what the business case is, I guess my next question is or a question that immediately comes to mind is supposing that we have decided to experiment with this, how do you mitigate that experiment?

We talked about lowering the cost, having a way to turn away from it, having a way to make it inexpensive. For example, one of the things that I think of when evaluating a new technology is how well can I use it with old technologies. I have a lot about best practices in my tool bag. We all do. We got our all favorite libraries and pathways that are just familiar to us. One of the things that I've noticed is when adopting a new technology, one of the things that makes it easy to experiment with is how well it works with the existing technologies. I know that, we talked about Elm UI, kind of rethinking style in CSS and your views and Elm itself as a completely different language within JavaScript, that can be both liberating but it can also be limiting in the sense that I can't reach back for my existing tool if no tool exists in this new space.

The kind of experience that I've had where this is really worked is systems like JRuby or Clojure, where there's a very clear pathway to be able to use Java libraries from those environments, so you always have kind of an escape hatch. What's that like in Elm?

DILLON: This is a really interesting conversation because it highlights, in some ways some of the most defining features of Elm. In terms of how do you kind of pull Elm into an existing application, there are a lot of different techniques for that. It's pretty straightforward to create a little Elm app. We usually don't call them components for reasons that we can get into if we want to but that's a whole can of worms.

But if you've got a little Elm application that you want to use to render a widget on your page, then it's as simple as just calling Elm.yourmodule.init and rendering it onto the page there. That's quite straightforward and if you want to interface with your existing code there are several ways to do that. There's something called port in Elm, which is how you kind of communicate by sending these messages and data back and forth between your Elm app and JavaScript.

Now, this is one of the decisions, I think that defines Elm as the language and the reason this is important is because Elm decided not to make the choice that a lot of other compile to JS languages do. For example, if you look at ReasonML or PureScript or a more extreme example, TypeScript. TypeScript is a superset of JavaScript, so it's trying to allow you to gradually introduce this to get some incremental improvements for your JavaScript code, so it's extremely easy to experiment with it, which we've talked about the importance of experimentation.

Now, the challenge with this technique, the tradeoff here is it's great, that it then becomes very easy to transition into it and that's an excellent strategy for the goals of TypeScript. Elm has a different set of goals, so the things that elm is focused on giving you is a truly type-safe experience. When you're working with Elm, if your Elm code says that this data is a float, then it is a float. Either, it is a float or that code is not being run and so, that's very different than the experience in TypeScript where you have these escape hatches.

This is an inevitable choice for any compiled to JS language. Are you going to have escape hatches or not? Elm is really the only language out there, I think that chooses not to have escape hatches and that is actually the thing that that I love about the language because that's the only way you can truly have guarantees, rather than, "Yeah, I'm pretty sure that these type guarantees hold."

DAVID: Yeah, wishes and dreams.


CHARLES: What does it mean to have no escape hatches? because you talked about ports. Does it mean like it's impossible to use an external JavaScript library?

DILLON: That's an excellent question. You absolutely can use JavaScript libraries. It means that it's being explicit and upfront about the fact that there's uncertainty in these areas. That's what it comes down to. Take for example dealing with JSON. In a JavaScript application, what we get when we're dealing with JSON is you make a request up to the server, you have some callback that passes in the data you get back and then you start pulling bits and pieces off of it and you say 'response.users subzero.firstname' and you hope that none of those things are null, none of those types are different than what you expected.

In a way, it's kind of letting you pretend that you have certainty there when in fact, you don't and with Elm, the approach is quite different. You have to explicitly say, "I expect my response to have this shape. I expect it to be a list of things, which have a first name and last name which are strings," and then Elm says, "Okay, great. I'm going to check your assumptions," and if you're right, then here you go and you're in a well typed-space where you know exactly what the types are and if you're wrong, then that's just another type of data, so it's just a case statement where you say, "If my assumptions were correct, then do something and if my assumptions were incorrect, then you decide what to do from there."

CHARLES: Right. For me, it sounds like there is some way because ultimately, I'm going to be getting unstructured but I'm going to be getting JSON back from the server and maybe, I have some library that's going to be doing that for me and enhancing it and adding value to that JSON in some way. But then at some point, I can present it to Elm but what you just saying is I need to be complete in making sure that I handle each case. I need to do or handle the case. Explicit about saying if the assumptions that Elm wants to make, turn out to not be true, Elm is going to make me handle the case where those assumptions were not true.

DILLON: Exactly. I think that TypeScript of any type is the perfect illustration of the difference. TypeScript of any type is sort of allowing you to say, "Don't type check this. Trust me here," and Elm's approach is more kind of just be explicit about what you want me to do if your assumptions are incorrect. It doesn't let you kind of come in and say, "No, I know I'm going to be right here."

CHARLES: Right but there is a way to pass data structures back and forth.

DILLON: There absolutely is and actually, there's a technique that's starting to gain some traction now, which I'm really excited about, which is rather than using this sort of JavaScript interrupt technique we talked about, which is again, it's very much like communicating with a server where you're kind of sending messages and getting data back -- getting these messages with data back. But there's an alternative to that which is using web components. Actually, there's quite good support for assuming that you don't need to be compatible with Internet Explorer.

Basically in a nutshell, if you can wrap a sort of declarative web component around anything, it could be a Google Maps API, it could be a syntax highlighting JavaScript library, something that you don't have an Elm library for but you want to use this JavaScript library, it's actually quite a nice experience. You just render that custom element using your Elm code just as you would any other HTML in Elm.

CHARLES: Yeah I like that, so the HTML becomes the canvas or composition with other JavaScript and the semantics are very well-defined and that interface is actually pretty thin.

DILLON: Exactly and the key again is that you wanted to find a declarative interface, rather than an imperative one where you're kind of just doing a series of statements where you say, "Do this and then set this value and then call this and then set this call back." Instead, you're saying, "Render this Google Maps custom element," which is centered around these coordinates and has this zoom level on. You declaratively give it the bit of information that it needs to render a particular view.

CHARLES: Okay. Then I guess the final question that I have around this area is about being able to integrate existing tools and functions inside of an Elm application. Because it sounds like you could theoretically develop large parts of your application, is there a way that you can actually have other areas of your application that are not currently invested in Elm still benefit from it, in the sense for kind of need of JavaScript APIs that Elm can make available.

DILLON: Right, so you're kind of talking about the reverse of that Elm reaching out to JavaScript. You're asking about, can JavaScript reach out to Elm and benefit from some of its ecosystem?

CHARLES: Exactly. I say that is that another potential vector for experimentation.

DILLON: It's a really interesting thought. I haven't given it too much thought, to be honest but I actually have heard it come up before and my gut feeling is that it's probably more fruitful to explore the inverse, reaching out to JavaScript from Elm and the reason is kind of the main appeal of Elm is that when you're operating within Elm, you have this sense that if it compiles, it works. Because again, this central decision to not allow escape hatches is what allows you to have that sort of robustness, so you have this feeling of bullet proof refactorings and adding new features seamlessly where you change your data modeling to say, "Here's this other case that can be represented," and then suddenly, the Elm compiler says, "Tell me what to do here, tell me what to do here and tell me what to do there," and you do it and your app is working. That's the real appeal of Elm, I think and you don't really get much of that by just calling out to an Elm library from within JavaScript. That's my gut feeling on it.

CHARLES: Okay, that's fair enough. On the subject of interrupt and using tools like JSON, you actually maintain a GraphQL library for Elm. You probably have a lot of experience on this. Maybe we can talk about that as a concrete case that highlights the examples.

DILLON: Yeah. I think to me this is one of the things that really highlights the power of Elm, to give you a really amazing refactoring and kind of feature creating experience. A lot of Elm libraries are prefaced by the author name, so it's still DillonKearns/ElmGraphQL. I spoke about it this year at ElmConf.

In a nutshell, what it does is it actually generates code based on your GraphQL schema. For anyone who doesn't know, GraphQL is just kind of a language for expressing the shape of your API and what types of data can return. What DillonKearns on GraphQL does is it looks at your GraphQL schema and it generates an API that allows you to query that API. using this library, you can actually guarantee that you're making a valid query to your server. Again, you get this bulletproof experience of refactoring in Elm where you can do something like make a change in your API and recompile your Elm code and see whether you've made a backwards incompatible change.

All of this effort of doing sort of this JSON decoding I was talking about earlier where you kind of have to explicitly say, "These are my assumptions about the shape of the JSON that I'm getting back." When you're using this library, you no longer need to make any assumptions because you're able to rely on this sort of schema of your API and so you know when you're requesting this data, you don't have to run it, see if it works and then tweak it and run it again -- this sort of cycle of checking your assumptions at runtime.

It moves those assumptions that you're making from runtime to compile time and it can tell you when you compile your application, it can say, "Actually, this data you're requesting, it doesn't exist," or, "It's actually called this," or, "This is actually the type of the data."

CHARLES: Right. I love that. How do you do that? Because it seems like you've got a little bit of a chicken and the egg problem because the schema is defined outside of Elm, so you have to be able to parse and understand the schema in order to generate the Elm types to be able to compile Elm code against them. Maybe I'm not --

DILLON: That's exactly right. That's exactly what it does. Now, the nice thing is that GraphQL is really designed for these types of use cases. It supports them in a first class way. If you have a GraphQL API, that means you have built into it whether you know about it or not, a way to introspect the schema. All of the queries for kind of interrogating that GraphQL server and asking what types of data does this return, what are all your queries that I can run, it's built into it by the framework, so that comes for free. Getting up and running with this package I built is as simple as running a little npm CLI, pointing it to either your URL for your server or the JSON form of your schema, if you prefer and then, it generates the code for you.

CHARLES: Wow, that sounds fantastic. This is the exact kind of thing that feels like it would be cool if I could just start using this library to manage the GraphQL of my application but I'm consuming that GraphQL from other JavaScript but it's the Elm code that's managing it. Do you see what I mean?

DILLON: I hadn't considered that. I guess you could. You're right. Maybe I’m so smitten with Elm that it's hard to see an in-between but I guess, you could get some benefits from that approach.

CHARLES: Right and as an experiment of course.

DILLON: There you go. There you go.

CHARLES: All right. With that, I think we'll wrap it up. Thank you so much, Dillon for coming on and talking with us on the podcast.

DILLON: My pleasure. I really enjoyed the conversation.

CHARLES: I actually got so many great tidbits from so many different areas of software development in Elm but also, just in kind of other things that I'm interested in trying. It was a really great conversation.

DILLON: I had a lot of fun and I love discussing these things. For any listeners who are interested in this stuff, feel free to reach out to me on the Elm Slack or on Twitter. I'm at @DillonTKearns. I'm also offering a free intro Elm talk for any companies that are kind of entertaining the idea of doing an experiment with Elm. If you go to, you can find out about some of the talks that I'm offering.

CHARLES: All right. Well, thank you very much and we, as always are the Frontside. We build software that you can stake your future on and you can get in touch with us at @TheFrontside on Twitter or on email. Please send us any questions you might have, any topics that you'd like to hear about and we look forward to hearing from you and we will see you next week.

Nov 08 2018



Rank #8: 116: Styled Components and Functional CSS with Kris Van Houten

Podcast cover
Read more

Special Guest:

Kris Van Houten: @krivaten |

In this episode, we are joined by Kris Van Houten to chat about Functional CSS and Styled Components: pros and cons, the problems that they are trying to solve, and how to choose between one or the other.

This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC.


DAVID: Hello, everyone. Welcome to Episode 116 of The Frontside Podcast. I'm David Keathley, a software developer here at Frontside and I'll be your host for today's episode. Joining me as a co-host is Jeffrey Cherewaty.

JEFFREY:: Hey, there.

DAVID: And we've got an amazing guest with us today, Kris Van Houten. Kris is the author of a very interesting functional CSS library called Elassus, a good friend of mine and today, we're going to be talking about how that compares with another new pattern I've been seeing everywhere recently: styled-components. Hi Kris.

KRIS: Hey, how's it going?

DAVID: Doing great. Let's just go ahead and jump into things. Kris, you want to give us a little introduction to your functional CSS library?

KRIS: Yeah, for sure. I guess, first of all about me. I've been primarily a frontend developer for about seven or eight years now. I don't know, at some point you start losing count but over the years, I worked largely within the Ember framework but I've also worked within React and Vue. Like most of developers over the years, you tend to require an affinity towards certain areas of software development and for me, those areas tend to lean towards accessibility but also, learning how to write CSS with what I call like the future in mind.

To try to keep the story as short as possible but a couple of years ago, I was working on a project and started to realize that our CSS is one of those things that just continues to grow over time along with the rest of our application but I also noticed that we tend to have a lot of areas of repetition within our CSS, like how many times are we setting text align to center, how many times are we setting the text color to the primary color or to gray or something of that nature and maybe we could create a utility library that just does all the stuff for us, similar to if you've ever worked with Bootstrap that they had utility classes that allow you to do some things like set the text alignment or the text color or font size and things of that nature.

I started thinking around it but eventually, I changed jobs and that idea kind of just went to the side but then, I'd say about a year and a half or two years ago, I came across a blog post called '15kb of CSS is all you’ll ever need' and so, immediately I was intrigued. It was actually a blog post on Medium that was talking about the benefits of using something like Tachyons or base CSS, which are two different functional CSS libraries. To explain what I mean by functional CSS, it's just a whole library, a whole arsenal of these utility classes that just do one or two things that allow you to basically take any design and implement it by composing all these classes together throughout your HTML.

I was looking at Tachyons, looking at base CSS and thinking, there's a couple of things I like to customize about this but at the time, when I was looking at it, I couldn't really figure out how to customize those values very easily and so, I did every developer does and just decided to make my own and that's where Elassus came into play, where it's a CSS library that is entirely made up of functions that generate your CSS based off of the value of variables in Sass. Everything is customizable, all the way down to how the class names look and the syntax that you use. If you hate what I'm doing, you can customize it very easily.

A lot of people might wonder why would you want to use functional CSS, what are the benefits that you get out of it and really, one of the first two things that comes to mind for me that really attracted me to it was that your CSS files start small and they stay small. For the most part, depending on the configuration and the particular library that you're using, your entire CSS payload can be anywhere from 10 to 20 kilobytes, minified and gzipped, which is in stark contrast to some other projects I've worked on, where just one of the many CSS files you're downloading are 745 kilobytes. Dramatic improvements there, so that's why it was instantly appealing to me.

But one of the other nice things you kind of get for free by default is a consistent design pattern, right out of the box. Because if you're working on a large team that has maybe multiple designers and many developers, one designer might implement something with the spacing system that's maybe based on five pixels: your padding, your margins, your widths, might be five, 10, 15, 30 pixels, 45 pixels but then maybe, another designer is implementing something based off of more material design, which is base-4 pixels, so it's like four pixels, eight pixels, 16 and so on.

Over time, little differences like this can really show up as you navigate between pages of your application and with functional CSS, you're given a limited number of options to choose from. As a result, it actually makes your application feel like it's one cohesive consistent piece of software between pages and between the features that you're navigating through. Those are really two areas that have really attracted me to functional CSS and I guess, is a tl;dr -- if that was a tl;dr in fact -- of what functional CSS is and why I like it.

DAVID: One of the things we've got here was the problem that functional CSS and styled-components are both trying to solve.

KRIS: Like I said earlier, a lot of the applications that many of us might be working on, they tend to grow at time by either adding features or rewriting and improving existing feature. In JavaScript, over the years, we have made tremendous improvements in our tooling with things like code splitting and tree shaking to really limit and minimize the amount of payload that we're sending to our users at the end of the day. But really, it's only up until recently we hadn't really been talking about how we do that for CSS and typically, as developers, we had deadlines, we're working with them in sprints, we had a real strict time constraints on what we can work on and for how long and so, we tend to focus on making sure the features look right, they work right, and that our test passed.

In CSS cleanup is just one of those things that often doesn't get cleaned up as often as you would like. Sometimes, that's also because we assume that a particular set of styles is probably getting used by another team, working on a completely different part of the application. As a result of just not being able to work on this problem or this issue, we likely have many, many kilobytes of orphan styles being shipped to our users at the end of day and our style sheets tend to grow over time. If there's one thing that's kind of become a mantra within software development over the last few years, it's that every kilobyte matters.

One of the main reasons I wanted to come and talk to guys today was about some things that I've been tinkering with on the side, just to figure out how we solve this problem and so, their approach of using functional CSS is one of those things but using something like styled-components, which is mostly used in React library of the solution of writing your CSS in your JavaScript and that's another approach to how to tackle this problem.

DAVID: That's an interesting thing you said there. I remember, whenever I started off in software development, one of the big no-nos for styling is don't put your styles in your JavaScript. It's interesting to see that that has kind of changed.

KRIS: Yeah, indeed. I remember listening to a podcast about two, maybe three years ago and they had a panel on and they were talking about there's a new thing called CSS and JS and I was like screaming in my car like, "This is the most horrible thing in the world you could possibly do. Why would someone want to do this?" and obviously over the last couple few years, the technology has definitely matured and they definitely hardened it, to where when I was working on updating my personal blog, working on moving over to Gatsby, I didn't want to have to pull an entire functional CSS library because I kind of thought that would be overkill for just a couple small pages and so I was like, "Let me try this whole styled-component thing. That way if I'm going to hate it, I can hate it from the experience point of view."

I actually found that the developer experience of working with styled-components was really nice and so, I kind of became converted over to that way of thinking about, "I'm not a hater. It's actually a really nice way to write your CSS for your blog or your applications."

JEFFREY:: I count myself still as a skeptic about this whole idea, so I'm excited that we're going to talk about it now and then, you have the opportunity to sell me on it, which should be fun. Some of the work I've been doing on lately, we've been doubling down on the idea of CSS modules, that at least fix some of the encapsulation and problems around CSS where everything is sending up in a global scope. How do these ideas of functional CSS kind of take that even farther? What advantages are there over using, just simply using say, CSS modules where we're fixing the global namespace.

KRIS: I'd say with functional CSS, again the things that kind of mine for me are you keep the file size small, you have your design patterns that you can get for free right out of the box. Your styles are pretty low specificity, meaning that if you ever have a need to where you get a really customized something because you just can't do a functional CSS, which I found to be very, very few and far between as far as the number and instances I've come across, it's very easy to overwrite if you need to go back into, I guess old fashioned way of actually writing some CSS yourself.

But then you also have the benefit of not having to come up with clever class names to describe the different states or different use cases of your component that you're working on or the future that you're trying to implement and so, I'd say those are definitely some of the pros of why I like using functional CSS at the end of the day. I will say that there are some cons -- I'll be completely honest -- and say that one of the areas where functional CSS tends to have a weak spot is in the area of browser specific issues.

In my experience, I tend to have a lot of issues with iOS Safari and it's like the bane in my system sometimes. Sometimes, worse than i11 but if you have to really target something that's exclusively for a specific browser, that's really not doable from what I've seen in functional CSS. That's where we should have to go back in and handwrite some CSS for that kind of situation.

But also, one of the cons is that sometimes, depending on the element or the component you're trying to style, I think the example is if you have a nav bar that can toggle between being a sidebar but also a top nav bar, that's a completely different set of styles and to achieve those few layouts at the end the day, you have to have a completely different collection of class names that you have to toggle between based off of the state of that component or that feature that you're working on. While that's doable, especially with something like a frontend framework like Vue, React or Ember, it's just a little pain point that sometimes you have to work around but I say, those are the pros and admittedly some of the cons of using something like functional CSS to tackle your styling needs.

JEFFREY:: My favorite thing that you mentioned there was how hard naming is. I think everyone can agree, very strong of it, just naming things is the hardest thing. What has been your experience in learning these? They're almost new domain languages for like we want to padding of this amount. Have you found that pretty easy to get up to speed and get fluent in or have you run into some blocks in kind of learning these new languages that some of these CSS tools have presented.

KRIS: That's a really good question. When I first started digging into Tachyons -- that was the first functional CSS library I started working with -- there is definitely, I'd say a small learning curve of maybe, I was trying to implement it just to see how it worked and it took me, maybe a couple of hours, if that, to kind of get a feel for how they write their classes and how the classes are put together to do certain things. But once you kind of get through that little initial pain point, it's pretty easy.

In one of the things that when I was working on my own implementation of it, I wanted to make sure that no matter what you're doing, all the class names are consistent, that the patterns that you use to your class naming is consistent and I guess, because I wrote it, then it wasn't so hard for me but I also understand that that's not the case for everybody. When I wrote Elassus, one of the things I did is I actually was able to create a compiled JSON version of all the CSS and actually, use that to create like a little React search tool. If you're looking for padding or margin, you can just enter that in a search bar and it'll tell you all the options in the classes that are associated with that and that's one thing I did to kind of help with that barrier but it definitely can be a bit of a learning curve but like I said, it's maybe an hour or two of your time to really get familiar with it.

JEFFREY:: That is not bad.

KRIS: No, not at all. I was actually really surprised at how fast I got up and running with it.

DAVID: That actually ties into something that I was kind of curious about myself. Whenever I went through the coding bootcamp that I did a couple years ago, after we finished going over raw CSS and how that works and the basics of that, they introduced us to Bootstrap as our first real CSS library to play with. That was fairly achievable for someone brand new to frontend work in general. What I was curious about is would you see these functional CSS libraries as equally accessible or maybe, more advanced than something like Bootstrap or Foundation.

KRIS: I never thought about that before. I think I kind of see it like as the next step. I've worked on several products over the years where Bootstrap was what they started with. As we went on to build out the feature set of the product, we started to find ourselves battling with the various styles that we get at from Bootstrap for free. I think one of the things about working on a website, where actually using Bootstrap is that sometimes you can just kind of tell that it's a Bootstrap based website. I don't know if I'm making any sense to you guys --

DAVID: Oh, yeah. Definitely.

KRIS: That was another reason why I wanted to have something... That had basically forced me to decide how my navigation bar looked. It forced me to think more about how my sidebar is looked or what my spacing scale -- it's the term I like to use -- based on what you're using for your pure margins, your paddings or what's your heights, things like that. It make me think about what those values should be and that's how you kind of break out of the box of having everything look like it was built in the same framework.

I would say it's more of a next step if you're talking about your experience as a developer. Yeah, learn CSS. I think it's still incredibly valuable to know CSS and for me, like you David, I kind of got started and learned about this thing called Bootstrap and you can quote me. Back in the day, I said, "This is like the jQuery for CSS. It's amazing," but quickly, I kind of ran into some of those issues that I mentioned earlier and kind of force me think about, "Maybe, I don't want to use Bootstrap. Maybe, I want to handle my own thing," and so, I say functional CSS, as far as like again your education level, it's more or less that step of if you think about how do you want to solve certain problems in our design.

DAVID: Okay. We've gone over functional CSS with some and styled-components, how would you choose between the two?

KRIS: This is actually really hard because I actually like both approaches. I'm not one of those guys that's like, "That one sucks. I don't want to use it." I actually think both have their place and so, I know I kind of sound like the typical 'this versus that' blog post in technology right now but I will say that there's a few questions you should ask yourself and ask your team if you're considering changing up your approach to CSS. One of those is what is the preferred developer experience of your team. That's something we've been talking about a lot at the company.

What we mean by that is how enjoyable is it to work in a particular codebase? Do your developers mind writing their CSS, instead of a JavaScript file? Or would they prefer to have something where they can actually read the HTML and build a C, just by looking at the elements in the classes that are being applied there? What this layout looks like or what's being applied to this layout? You know, questions like that can definitely help determine what direction you should go.

Again like I said, one thing I love is that both approaches remove the developer's burden from having to come up with clever class names for all the different use cases or states of your components. I think you're going to get a win-win either way there. However, if you're using React, we already have a ton going on in our JSX and so, if adding a series of class names to determine your design tips is overwhelming for you, then maybe give styled-component a try because it can definitely simplify your JSX output a little bit.

If the idea of having JS to handle your CSS seems a little fishy, I think one of the cons of using styled-components is that we're asking JavaScript to do yet another thing for us. If you're one of those people who has a problem with that, then give functional CSS a try. There's definitely more than one flavor out there and I've tried out almost all of them and like them. They all have their nice tidbits inside of them. I'll say, if you prefer to have easy theming, if you're working on a project that has to have a lot of theming involved, then I might be more toward styled-components. If design consistency and design patterns is a priority, then maybe functional CSS is an option for you.

With both of those scenarios, easy theming in patterns is possible in both. It's just one is harder in one than the other. With styled-components, there are implementations of it in Vue and Ember but they don't seem to be very widely used yet, so I'd say use at your own risk or contribute to open source to make them better. I'd say for right now, if you don't mind being locked into using React, then styled-components is pretty cool. It also allows you to transfer your styled-components from one project to another without having to worry about. [inaudible] all the CSS because that's a big deal but I would ask myself those kind of questions to determine what solution I would choose.

JEFFREY:: I am interested in the performance implications of these tools. You touch earlier on by using tools like this, you can definitely shrink your CSS payload by a lot, so what is the actual output of using these tools? What will it look like? Do you end up with still an external CSS file or is it a scenario where you're kind of getting some CSS injected into your markup?

KRIS: Yes with one and no on the other. With functional CSS, you typically have a CSS file that is compiled and maybe, you're using Sass to do the operation for you or post-CSS, so you get an output CSS file that you help you fetch on the frontend of your application. Like I said, [inaudible] if these files are between 10 to 20 kilobytes, which is remarkably small. With styled-components, it's a totally different approach. It's a totally different implementation as well, unless you have a normalize or perhaps a reset CSS that you're fetching on the frontend, all the styles are actually -- I guess, I should start with earlier. What happens is you define your styles in your JavaScripts and at runtime, the component will read the styles that you set and then create a unique class for that instance into the head of your document. It's basically a single class use for that component and so, all in all, it gets compiled at runtime. There's no additional CSS files being injected. It's actually being created dynamically in your actual HTML document.

One of the things I was first concerned about was what are the performance implications of having JavaScript do this for us and over the last couple of years, as the technology has been maturing, performance has been an issue but I think it was with V4 -- version 4 styled-components that just released, I want to say, in September or October, they have tremendous performance improvements. It's rapidly fast now, so it's not really something you need to be concerned about.

I'd say again, it's one of those things: Can you get over the mental hurdle of having JavaScript do one more thing for you? And can you get used to the developer's ergonomic practice of writing CSS inside a JavaScript file? I know it kind of takes a little bit of getting over that because it just seems so strange but you also get a lot of perks by doing that with having easy access to theming, you get to use some of the power of JavaScript to help build out your CSS, which can be nice as well even if it kind of feels weird.

JEFFREY:: Yeah, I agree with the ergonomics do feel weird but you'll get some benefits out of doing that. In the styled-components where it'd bring on the fly, I'm happy to kind of figured out the performance like runtime implications with that but it seems to me that now you no longer have a cache CSS and that you're having to get that all the time on the fly. Maybe for some systems, that is okay but that's definitely something that I would miss having -- the idea that CSS actually can be a little heavier because it will always be cached.

KRIS: That is totally a valid point. I think one thing I do kind of like about the styled-component approach is that when you delete a component, all the styles go with it, so you no longer have orphaned styles just hanging out there that are getting shipped down to your user. I agree that the caching is definitely a concern but I just kind of start to weigh the pros and cons and again, you have to decide for your product, for your team what works best for you. Also, one of the pros that I would bring up is that you don't have any orphan CSS hanging out in your application anymore, which is definitely one of the key contributors to growing bloat in your files over time.

JEFFREY:: That is very nice.

KRIS: Yeah.

DAVID: That ties into a question that I was kind of wondering. As your projects get larger and larger and more complex, your style sheets tend to grow along with that and one of the issues that you might have as time goes along is visual regressions like styling bugs. How does using functional CSS or styled-components sort of deal with that or prevent that?

KRIS: With functional CSS, like I said, you have those patterns kind of built in out of the box. As long as you don't change the value of what a particular class renders out of, maybe someone goes in and without thinking of it, they change the second value of your spacing scale to a lot of pixels just because they felt they needed to. You're not going to have visual regression that happen over time because the whole premise of functional CSS, those values don't change. Those are basically meant to be seen as immutable values, immutable classes. You shouldn't have style regressions that pop up over time as people continue to work on your application.

With styled-components you still have that risk unless you are setting all those same values and your theme properties that you can use within styled-components. Unless you're setting all your different spacing values, you have a tendency to potentially run the same issue. But actually, now that I think about it, maybe not because with styled-components, every component is unique. Every components styles are completely unique, so again, unless you're changing those core values of your themes, you should not have visual regression that happen in a totally separate part of your application when you're working on say, the home page. I would say both handle that pretty well, now that I'm thinking of it.

DAVID: That's cool.

KRIS: This reminds me, I'm working on a particular piece of software at a particular feature of my work and we don't use functional CSS or styled-components yet. I'm trying to get them to move over so again, this is all stuff I do on my free time but I'm working on editing a component and I had to make some pretty drastic changes to it and I was like, "How is this going to break on some other page that I'm not aware of yet," and so, this requires a lot more going back and checking all the various uses of this particular component. We used it in 10 or 11 different places on different pages and so, we have to go back to each and every single one of those use cases to make sure I didn't break something. Whereas if I was using one of these two approaches, it wouldn't be something that I would have to be concerned about. This is what I'm trying to push through on my own job as well.

DAVID: Yeah, it really eat up your time.

KRIS: Yeah.

JEFFREY:: I want to talk for a few minutes about media queries because, I think that the situation is kind of handled. It's definitely something I've run into: CSS variables and with post-CSS tooling. I'm interested in kind of how does the media query story is handled with the setup.

KRIS: With functional CSS, you tend to have, basically say, I have a class that sets a margin on the top of 16 pixels, for example. Let's say that that class name is MT-3... I don't know, meaning for like the third position in your spacing scale, 'MT' stands for margin top. If you wanted to only use that style for perhaps, like your medium break point, then different libraries have a different way to approach this, basically, you're 'MT-3--medium' or '--desktop.' It's the additional characters that you append to the class name to target that specific media query.

Also, depending on the framework that you're using, you can also target pseudo states, whether or not this element is focused or on hover, maybe you want the background code to change. There's variations of those classes that allow you to target those specific states, which is really nice in functional CSS. Again, just by looking at the classes that you're adding to your DOM, you don't have to scroll through your style sidebar to figure out like what styles are associated with this class name and why it's being overwritten by these 10 other things that we have going on. Again, you can just look at the HTML and see what's happening and what should happen if you hover over an element.

With styled-components, you can still use media queries and all that stuff right out of the box. In order to keep your media queries consistent, that way not everybody is having a handroll, at least by every single time that you need to use them. You can actually store your media queries in a separate JS files and it's kind of import them as you need them, which again, kind of feels like a weird developer ergonomic for your CSS but definitely, it comes in handy and definitely keeps your styling consistent the more you break out the various pieces into small pieces or small components like that. That's how to handle things like media queries and things like that.

JEFFREY:: It's interesting how these approaches are kind of pushing the web towards, I'm feeling a lot more like native development, where you build your style and your visual look in conjunction with your component code and those things are not really ever separate. I think, there's some interesting influences coming in there from some made up things.

KRIS: One thing I think about a lot, especially when I'm thinking about functional CSS is I'm reminded of this image I saw kind of posted on Twitter somewhere in the interwebs. It was a picture of the Super Mario Brothers start screen and the entire Super Mario Brothers video game was something like 23 kilobytes. This screen that you're looking at, which was like the start screen was like 345 kilobytes or something. My numbers are probably off but it was something drastic like that and this makes me think about, if you were to go back through, there's a couple of documentaries about how the loops that developers had to jump through in order to make old video games for Nintendo Entertainment System back in the late-80s -- I'm probably dating myself right now -- but the things they had to go through and to think about in order to make those games work the way they did is insane and I kind of feel like over the last... I don't know, maybe 10 or 15 years, because we've gotten such fast computers and such fast mobile devices and so on and so forth, we've kind of gotten crazy.

I look at video games now and they're 100 gigabytes sometimes and I kind of feel like they didn't need to be 100 gigabyte video game and I think --

DAVID: But it's so much cooler because it is.

KRIS: I'm not saying it's not cool but I'm think like if they really took the time to pay attention to some of these details, we probably could automate this a little better. Maybe, I'm just being biased but I think about we're kind of starting to do the same thing and talk about the same kind of problems in web development. Again, just because we can have a 745 kilobytes of CSS file and thought the world falling over, it doesn't mean we should, so maybe, let's take into consideration that not everybody is using a cinema display on a super-fast MacBook to view your application, what about the person who's using an outdated Android device that hasn't been updated in three or four years? How's your product going to work on their device?

I'm really glad that people actually started to take that kind of thing into consideration and it even reminds me a little bit of another area that I think a lot about is the area of accessibility: how do people with various impairments or disabilities use your software and how can they use your software but also, outside of that, how do people, who maybe don't have the money to have a fancy mobile device like you have, use your product along those same veins. It kind of dips into the same vein of accessibility when we're talking about how do we optimize our products to make them usable by everyone despite their income level or their ability to have a fancy, nice desktop or a latest iPhone.

JEFFREY:: Awesome.

DAVID: Yeah. Definitely, you think about who are the majority of users on the internet these days and really, it's an emerging market with underpowered devices and the internet is becoming much more and more accessible for people to get on and browse, so you really got to keep those people in mind.

KRIS: Definitely, especially if you're creating software that you want people across around the world to be using, a lot of people don't have access to crazy high speed internet like we do here in the States, so we should probably be taking more time to consider what it looks like for those people to use our product. At my company, what we've been talking about is like we should be testing and basically, starting mobile first with all of our development to see how does this work on our mobile device.

I'm a remote developer so we're trying to figure out how to get me mobile devices that I can actually test on our VPN but it's something that we're trying to move towards at my company as well.

DAVID: Okay, that about wraps up Episode 116, our final episode of 2018. Man, the year has gone by fast. We are the Frontside. We're the frontend specialists who make your largescale application projects run smoothly by helping your team assemble the right tools and implement the right automated processes. We can ensure your projects can move forward on time and without regressions while preserving quality and long term maintainability.

If that's something you're interested in, please get in touch with us at @TheFrontside on Twitter or via email. Do send us any questions you might have, any topics you'd like to hear about in the future. We look forward to hearing from you. Thanks again to the wonderful Mandy Moore for producing today's podcast. You can find her on Twitter at @RubyRep and that's it.

Dec 20 2018



Rank #9: 105: Automating GitHub with Probot

Podcast cover
Read more

Special Guests: Brian Douglas and Bex Warner of GitHub.

In this episode, the panelists talk about automating GitHub with Probot. The origins of Probot are discussed, as well as making GitHub apps with the GitHub API, automating workflows with Probot, must-have Probots for every repo, and GitHub’s V4 GraphQL API.


This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC.


ROBERT: Hello everyone and welcome to Episode 105 of The Frontside Podcast. I'm Robert DeLuca, the director of open source here at the Frontside and I'll be your episode host. Today, we're going to be discussing automating GitHub with Probot with Brian Douglas and Bex Warner. I'm really excited about this topic. The idea of automating GitHub workflows with bots is amazing. This is something that I've been wishing the GitHub have the platform support for since I even started using GitHub for open source. Just being able to have a bot to take care of certain things like somebody doesn't leave enough of a PR description and they open up a PR, you can have a bot that just responds to it and saying, "Can you provide more information?" It's pretty awesome.

With me as co-host today is Charles Lowell, who is also a developer here at the Frontside. Hey, Charles.

CHARLES: Hey, Robert.

ROBERT: Before we get into the discussion, I like to make a tiny little announcement. We've been building a composable and an immutable state container called Microstates. I'm sure Charles can talk about this more at length, then we will in the next podcast episode -- 106, but I would like to make a small announcement that Taras who is an awesome developer here just wrapped up a month's worth of work, creating a new ReadMe to describe the vision of Microstates and what you can do with them and everything about Microstates. If you're interested in that, I highly recommend checking out the ReadMe. I'll drop a link in the show notes for you that are interested.

CHARLES: If I can add, it really is [inaudible] because it isn't like any other state management solution out there.

ROBERT: No, absolutely not. I've been building something with it in React Native over the weekend of the 4th of July and it's amazing. But enough about that, you'll hear about that next episode. For this episode, I want to talk about Probot with Brian and Bex. Hi are you two doing?

BRIAN: I'm well.

BEX: I'm good. Thanks for having us.

ROBERT: No, thank you for joining. This is really exciting. Like I said in the intro, I've been really excited about this project. I do a good amount of open source, I would say and this has been really helpful in all of our repos. We have, I think like 78 open source repos on the Frontside. We have Microstates, like we just talked about and Big Test and all of those repos use some combination of Probots that people have built and it's really nice, especially with the new Checks API that has just come out. You can integrate Probot into that, right?

BEX: Yes. I, actually am currently working on shifting one of our bots from using the commits Statuses API to the Checks API.

ROBERT: That's awesome. Before we go too deep into it because I want to come back to that because that sounds really cool and what the integration of that is like and what changes because I'm not even really that familiar with it. I just know it was released. I kind of want to go from the beginning here. Where did Probot come from and can we get a little bit of a history for everybody that might not know what Probot is?

BEX: Sure. Probot originally started out as this simple idea to make GitHub scriptable. The original idea was you have a single file in your repository that would be like a JavaScript file and it would essentially spell out how the bot would act on your repository and the goal was to make GitHub apps accessible to people because if you ever look through our GitHub apps documentation, I think it can be a little tough to get started. There's, honestly, a lot of nonsense that you have to go through in order to get set up.

For one thing, the way our GitHub app authentication works is it requires a JSON web token followed by using that JSON web token to request an installation access token and that process would be really tough for new people to get started.

ROBERT: Yeah, it sounds like it.

BEX: Yeah, so Probot was created to abstract all of that away and handle all of that authentication automatically and simply leave you with the payload that you get from listening on web token events and in authenticated GitHub client to make authenticated API requests while authenticating as an app.

ROBERT: Cool, so that's where it started like a flat JavaScript file in the root but today, you use like EMO files and a .GitHub folder. How do that kind of progress?

BEX: Originally, their use case was much simpler and it quickly became clear that a single JavaScript file in the GitHub repo was not scriptable enough and not easy enough to understand. The goal was to make like an API that could make that JavaScript file really, really easy to customize for every API of GitHub and it quickly became clear that that was not really a feasible thing to do.

as time went on, it turned into this way to build Node JS applications and essentially, what the configuration files you're referring to are the way in which we make it customizable because right now, there's no way to be officially supported GitHub apps channels to pass secrets because it means you're a [inaudible] and the owners of GitHub apps, so that was just a way to kind of stop that problem.

ROBERT: Gotcha, okay.

BEX: The actual code for GitHub apps still lives in a Node JS module basically and the configuration file just specifies how that module runs.

ROBERT: Right, so they're deployed like Heroku instances, if you want, like anywhere you can host a node app.

BEX: Yup. Heroku, Now, yeah.

ROBERT: Interesting.

BRIAN: As a reason to that, some explorations of doing serverless deployments for Probot, I think there's a couple of issues of them. I'm not sure if anybody's shipped anything like the way they at but it's pretty much it's possible to.

BEX: Just a week ago, we even released a new version in which we update our core from Node JS to TypeScript and now that things are typed, we have big plans for serverless.

ROBERT: Nice. That's awesome, so then you'll be able to deploy to a Lambda and off to [inaudible].

BEX: Exactly.

CHARLES: Can I actually interject here, as kind of a person who doesn't really know the relationship between GitHub apps and the GitHub marketplace and what exactly a Probot is before we hear the origin story. I would love to hear a very high level view of how this ecosystem fits together.

BRIAN: I think a lot of people are pretty familiar with interacting with the GitHub API and OAuth integrations. I think I've just spent a lot of time at different companies previously to GitHub, just like making calls, either to cURL or through Node JS or more recently, [inaudible]. GitHub apps itself are a way to take all the things that you had to do to make an integration to GitHub much easier. It has a lot of cool things like OAuth, scopings, so you no longer have ask for all your repos ask access whenever someone logs in with GitHub and the connection between like, "Now have gone from OAuth to Now to GitHub apps," there was a lot of, as Bex mentioned earlier, ceremony that happens to getting set up with GitHub apps and integrations that Probot is like this tool to speed up the process of getting to the point where you just want to script some automation or some sort of workflow and it gives you all that bullet play for you. I don't know if that was a good high level for you Charles.

CHARLES: Yeah. I've kind of witnessed this second hand with Robert installing a bunch of things here, so let's use an example, like you did some sort of automation on our repos, Robert, where when someone files a ticket, there's this workflow that automatically adds a triage label, so that we know that this thing hasn't even been dealt with, so we really need to address that issue. It doesn't need to be as a high priority. It doesn't need to be closed as a duplicate of something. One of the different aspects that you described there, how do they fit in terms of serving this workflow onto the end user? Or was that a good example, even?

BRIAN: One of the cool thing about GitHub apps and what Probot does for you is that normally, if you want to add a label to an issue, either you Charles or Robert, would have to be admin or maintainer on the team for the Frontside and you could add labels. But somebody who opens up an issue, doesn't have that ability to have write access to your content, which is adding a label. What a GitHub app does, it actually takes a spot as if you would have another user on your platform, instead of creating a dummy account or a dummy user. Probot is basically building a bot for you to then, give you the ability to add that issue. That's sort of workflow that normally would have to happen through an actual real human could not happen through a bot without taking up a spot of like, "I guess, I probably shouldn't speak so ignorant about our platform and what we actually pay for nowadays for GitHub," but I know we used to have like a limited amount of seats for organization, like that seat no longer has now taken up and now, it could be just be used a bot can do something that normally us would take.

ROBERT: Right. You no longer have to create a user to do these things.

BRIAN: Correct.

BEX: [inaudible] within GitHub. It's sort of built in a way that apps can take a lot of power in your repositories.

CHARLES: So then, what is the relationship between Probot and an app?

BEX: Probot is essentially the framework for building an app. You can definitely make the equivalent of any Probot app outside of Probot. It abstracts away all of, basically, the horrible parts and leave the easy part.

CHARLES: Now, I think I'm ready to participate in this discussion.

ROBERT: That was perfect, though. That's a great intro because I actually didn't have a total grasp or understanding of the relationship between GitHub apps and Probots. That's really good.

BEX: Yeah. Additionally, going back a second. You mentioned the marketplace before. One thing to note that is that there actually are several Probot apps on the marketplace right now. The marketplace is essentially the home for any larger, usually third-party companies that have made apps and Probot is essentially supporting some of those.

ROBERT: Interesting, so then my question would then be, do you know anybody selling their Probots. Does the marketplace charge? I'm going to assume it does.

BEX: Yes.

ROBERT: Okay. Is there anybody charging for their Probot?

BEX: Yes. There is a quite a few, in-fact, charging for it. Recently, a pretty popular example is the GitHub Slack integration, which is if you open new issues, you can have them appear in your Slack channel. That whole application was recently rewritten by GitHub. It was previously owned by Slack and that was built on top of Probot.

CHARLES: And I actually remember, we upgraded to that version. It's actually way, way, way better.

BEX: I'm glad you feel that way.

CHARLES: I didn't know the story behind there. I was like, "Oh, I just got a lot of... Awesome," you know? Although I don't know what's the costing.

BEX: Yeah, I think that integration is actually free, so that wasn't the best example. I think it's for open source projects, at the very least.

BRIAN: Brandon, one of the maintainers for the Slack integration and work at GitHub, also did a really cool talk at the SlackDev Conference a couple of weeks ago, so if you're interested what were the behind the scenes. That integration is all open source as well, so if you have request or you have features that you would like to add to the Slack integration, you can pop into the repo that hopefully will show up on the show notes because I'm not sure if it's like GitHub/Slack, but I guess we'll find that out in the show notes later on.

BEX: It's Integration/Slack.

BRIAN: But for an example of a paid app of a non-third party, we're not talking like Travis or Circle or another one with the big names but rather, a solo dev created. It's Pull Reminders, which is on the marketplace as of today and essentially, this gives you reminders of your pull quest, so you can actually ping inside the comments and tell Pull Reminders to say, "Tell me about the pull request like next week because it's Friday and I don't have time to look at this."

ROBERT: That's awesome. I've also seen the one that's kind of related, that is like you can set your out of office at GitHub, which is actually kind of a neat concept.

BEX: Was that the one where we are already changing that profile photos to have the overlay or the one where is just auto-replying to messages because I've seen a couple of --

ROBERT: I think, it's just auto-replies.

BEX: Okay.

CHARLES: So, it can change like your profile pictures and really, not just related to repo and history related activities but everything?

BEX: Anything that you can access via the GitHub API, you can almost access via GitHub apps. There's a list of end points that I specifically enable for GitHub apps because there's something such as delete a repository that there's basically, a very few circumstances under which you want to give that permission to an app. Also, to things very specific like your profile or your personal page.

About a year ago, there was an official internal audit of all of the API endpoints because there are lots of inconsistencies over what was and what wasn't enabled for GitHub apps, so they went there and kind of decided, what endpoints should be enabled and what endpoints actually get enabled. Now, that list is much longer than it was a year ago. Now, it's much more comprehensive.

ROBERT: That's awesome and is this for the Rest API and the GraphQL API?

BEX: Yes. Probot does support both. The Rest API is the one that specifically had all of these endpoints audited. The GraphQL, since it's a bit newer, we sort of built those and more.

ROBERT: Cool. I really like working with the GraphQL API with GitHub. It makes it easier than trying to do a bunch of Rest calls.

BRIAN: Yeah, there's a community form, it's like a discourse form that the API team actually manages and sort of pipes in there. Again, going back to like, if there's not something in the Slack integration that you would like to have, the form, that community is actually in there, if there's something not in the GraphQL API, that you would like to see. No promises on shipping it within an x amount of time but if enough people are requesting it obviously, there's going to be some resources [inaudible] at.

ROBERT: What do you mean? We’re doing open source. It has to be done yesterday.

BRIAN: Yeah, exactly. And that form is at Platform.GitHub.Community, just a URL to get there.

ROBERT: Awesome, that will be helpful to look through and get some recommendations in there. One of my favorite things I was going to say about the new integration for Slack and GitHub is the fact that I can highlight line numbers, paste that linked in and then it just expands it and the chat in Slack. That is so nice and I use it all the time.

BEX: Yeah, I love that they built that feature. Actually, the original feature that was built on GitHub to allow those line expansions in the first place, like on GitHub itself, was actually built last summer by some folks who were also a part of my intern class at GitHub last year.

ROBERT: Hey, intern power. That's awesome.

BEX: Yeah.

ROBERT: Everyone there is doing amazing work. I'm also following along with somebody that is also an intern and it's building a weekly digest program.

BEX: Oh, yeah. That's actually a Google Summer of Code student.

ROBERT: Oh, interesting.

BEX: So, being sponsored through Google Summer of Code by Probot as an open source support.

ROBERT: Is there anything more to unpack there? That sounds really interesting.

BEX: Essentially, we submitted an application for Google Summer of Code because we thought it'd be a cool way to get more people, more students, a mentorship opportunity for the maintainers, basically and we were honestly overwhelmed. We got like almost 100 applications and it ended up being a huge of a deal but we're --

ROBERT: That's a great problem.

BEX: Yeah, definitely a good problem but we were really happy. We, initially wanted to accept more students but Google limited us to only two students, so we have two Google Summer of Code students working on projects and one team of women from Rails Girls Summer of Code working on Probot.

ROBERT: That would be awesome. What do they working on?

BEX: I'm not sure yet. They actually just started a couple of days ago but the other Google Summer of Code student is working on a background checks API to eventually do sentiment analysis of comment history of someone new to your repository.

ROBERT: That's interesting. That sounds like there will be some machine learning in there. I might just throwing out buzzwords?

BEX: Most likely, I think they're just using some sentiment analysis API, like the perspective API. I don't think they're actually doing that themselves.


CHARLES: Actually, I have a couple questions. Back on the subject of Probot. How does this square with the classic mode of integration because there was a lot out there? I think the first one that I remember that stuck in my mind was like Travis and I don't know if there had to be like a special relationship between the Travis developers and the GitHub developers, that's like, they was able to make that integration happen so many years ago. I don't know how that happened. I just remember it popped up and I was like, "Woah. This is incredible," and we see kind of the integrations gets more and more rich.

For someone who's got, like you mentioned a couple of the big names, is the idea that eventually those would be able to be completely supported is GitHub apps or is it they're always going to be kind of a separate track for kind of the really deep integrations?

BRIAN: I wasn't around when Travis first integrated with Lyft GitHub and I think that's a really cool integration and I know they have a very nice sized team that's able to do that. I think if we zoom back out like Probot, the way to get started with Probot is that we have the CLI command, which is to create Probot app. I believe it was intentionally copied off of create React app and the cool thing about create React app and create Probot app is that they abstract all the ceremony and boilerplate to get started really quickly. It was like, what developers or smaller teams can get started with integrating with GitHub apps. I highly doubt that Travis is going to rewrite their entire application with something like create Probot app but they're definitely going to be moving towards the new API calls, which would have been like GitHub apps.

Part of the Checks API that we had launched at the end of May, Travis had blog post on how their integration with the Checks API works. They're making, though they have a lot of what Legacy endpoints and a lot of Legacy integrations in the way they integrate with GitHub, they are actively moving towards a GitHub app. I don't know if I could actually comment on their status of where they are today, to be honest but actively, we want all new apps and new integrations to follow the model of being a GitHub app, so that way, out of the box, you have access to all the newer features. You have all the access to all the newer GraphQL endpoints, if you want to use GraphQL and that way, we can serve one market, as opposed to everybody who had a GitHub integration from five or six years ago, that was all piecemeal together and sort of duct tape, like we run move away from duct tape everything together.


BEX: I definitely agree that I don't think Travis is going to switch to using Probot anytime soon and I don't think most of the large companies will be doing that but I do think, there will be shift towards GitHub apps in general. For those companies that don't already have the buildings of the GitHub app started, I think that Probot could be, in time to free some of them.

BRIAN: In addition to that too, Travis and Circle and all the CI integrations, they're doing a really good job. I think the cool thing about GitHub apps is what you take away all that ceremony of getting your checks to work, now we can start opening up the door of like what's the next sort of CICD thing like? There’s another term or another, I guess category of applications that can now be built to improve GitHub.

CHARLES: The most amazing thing about having a great platform is the apps that you don't foresee, like it just come completely out of left field and you're like, "Woah. I can't believe that's actually a possibility now." When you have started to see some of those, some Probot or GitHub apps, you're like, "Man, I didn't see that coming. That's awesome."

BEX: A hundred percent. I think it's the most exciting part of Probot because I think GitHub as a platform, we all know GitHub is the largest developer platform in the world and I think the idea that developers can build on top of this platform is the most exciting idea right now. I have honestly already seen apps that really excites me.

The other day, I saw this app that was definitely not near completion but it was essentially updating and issue a comment box over and over and taking response through like checking a box and then listening on that common edit, in order to specify your coffee order.


BEX: I was like, "Do you want an ice coffee or regular? Do you want milk or sugar and cream?" and it was going one at a time. It didn't actually order you your coffee at the end but it was super exciting to watch that. You're just editing the comment. I had never seen that before.

ROBERT: That's pretty slick and that's taking the API pretty far. I'm sure there were some parsing in there and each Webhook response are like, "Was this box edited or not." That interesting.

CHARLES: Yeah. Actually, now that we're having this discussion is kind of like changing my mind a little bit. Robert and I were actually talking yesterday about trying to standardize on our release management and our plan was basically to have some software that was going to run inside of our CI provider and have kind of a shared library, just a little ntm package that was shared by all of our repos but I'm thinking now, man, we should really explore doing this as a GitHub app.

ROBERT: Yes, please. I've had three ideas that I really want to build out as a Probot. I'm just going to list them off and then we can build them all together and take equity and you know. I'm kidding. But the two that really excite me, that I kind of want to do is one concept that we work on this open source project for our clients and if somebody from the outside that doesn't have commit bits to be able to push to master, it would be really cool if we had a Probot that after it had an approved on the PR, from the maintainer, that the person that open the PR could then tell a Probot say, "This is approved by somebody that manages this project. Can we merge?" and then the Probot would then actually merge. I don't know if that's possible. That's something that I definitely wanted to explore.

Then the other one, which is less cool, would just be like if we have a couple branches on some of our projects that we want to continue and we're not ready to put it back into master but we want to continuously run the test suite against it, so the idea there would be to have a Probot that would watch for changes on master and rebase as needed and continue to run the test suite and see where you're at. Those are the two things that I'm really excited about to do with Probot but I just want to automate everything with GitHub now.


BEX: Yeah, definitely, that first idea was actually pretty viable. I'm curious to know like how you actually get those commit links -- is that what you called it?

ROBERT: Commit bits are more like commit permissions, I guess.

BEX: Oh, I see.

ROBERT: An outside contributor.

CHARLES: Yeah, we want to push responsibility to the person who is the maintainer who can approve it but actually, the way we do it at Frontside is the person who actually is making the change is responsible for merging it. Once you get approval, you still have to hit the go button and that's just going to make sure that you're taking responsibility for saying it's done but that doesn't work for open source because people coming off the internet are going to have the right to push but we would like to give it to them, maybe via an app, if there is a maintainer who's approved it.

BEX: Yeah. That's definitely something you can do. I've seen quite a few apps that, essentially add outside collaborators to the repo. Are you familiar with the... I forgot what it is called, like the all contributor section, where you cite everyone in your repo and everything and who's worked on it. There was a GitHub app that would add someone automatically after they merge their first change.

CHARLES: That's awesome.

ROBERT: I may have seen that on React State Museum but I'm not sure. It's a repo that we've contributed to and it has all the contributors at the bottom. It seemingly just kind of popped up there.

BRIAN: There's an app that, I would like to mention too that I'm pretty excited about, that it sounds trivial too and it's almost similar... Not similar but it's sort of related to what you were talking about, Rob, with your first app, which is the WIP bot, which is the work-in-progress bot. This is a pattern of whenever I open a PR and I might not ready for a merge but I want to share my code so I can get feedback earlier on, I'll type in WIP so that append to my title of my PR.

What this engineer did was every time you do WIP, it's going to go into the GitHub API and actually block the PR for merging, which is a feature available to GitHub. It's nested in your settings but the cool thing about this it actually blocks the PR for merging, so you don't have to worry about getting your, sort of like show and tell code merging the master without being ready.

ROBERT: That's one of the first bots that I installed on all of our repos and then you can correct me if I'm wrong, it didn't always have the ability to block the PR from being merged but with the new Checks API, is that something that was introduced?

BEX: Not exactly. The way that blocking of merging works is if you set it as the required status, so you can install any sort of CI on your account and have it not being required and ignore it whenever you feel like it, so it's really up to you to make it required. Otherwise, it just isn't checked and that's true for anyone who uses the Statuses or the Checks API.

ROBERT: Okay, so that's a Statuses API. Okay, sorry.

BEX: Yes.

ROBERT: Also, the cool thing about that that I noticed when that was rolled out was I was now able to pick and choose and use workflows on Circle CI and each workflow is broken out as a different status check. I am now required like linting and the build and the test have to pass for these browsers before it can merge, which is really cool to be able to pick and choose.

BEX: Yeah. It's awesome. I know personally on some of my repos, I have a few checks that I just don't require because I know I have to make them pass.

ROBERT: Yeah. Speaking specifically about the work-in-progress bot, do you know how that works? It’s open source, so I am sure I can go look. I think we want to go make a PR. We had some back and forth about this, Charles.

CHARLES: I actually just [inaudible] we disagree.

ROBERT: Yes. Charles opened a PR and one of his first commits in the PR had work in progress and the title had work in progress and we have this this Probot on our website and it was a blog post. You know, you make a couple more commits and you're further down, you move the work in progress in the title but the PR were still blocked because the first commit on a PR have work in progress in it.

I think if it's the most recent commit or if it's in your PR title with work in progress, it should block but otherwise, it should not and Charles feels differently.

CHARLES: I have about six commits and the very first one have WIP in the title or in the commit message and it blocked the whole thing but I kind of felt like it actually made me go back and I had to squash it down to two commits because I actually feel that your commit history should tell the story of the development, not like it should an absolute one-to-one journal of what happens but what you are intending.

I actually felt that it could help me out because there's six commits that we're kind of all over the place and just kind of slapdash together have made me kind of go back, rethink it and tell a coherent story. I think it did me a service but it was not obvious. I definitely agree with that but I was like, "Why? Why were you still blocking?"

ROBERT: Do I really [inaudible] admin privileges?

BEX: I would say, I am friends with the creator of the web app. His name is Gregory Mantis and he is actually got a huge work in progress PR shifting work in progress over to using the Checks API and one of the features that he's using with the Checks API is essentially this mark as now work in progress button that will add the special line, like feel free to merge or something like that into your original PR description at the bottom. If that is there, the work in progress app will no longer be blocking. It's essentially like a hard override and honestly, that's the power at the Checks API versus the Statuses API. That's really exciting.

ROBERT: Because I have seen the work in progress bot to get into a weird state, where I did remove the work in progress from the title but it didn't quite update and I'm still blocked. It's okay for me because I have admin privileges but other people on the team maybe not and they might be blocked from something that's actually work in progress. It's a lot like that hard override will be probably pretty helpful.

BEX: Yeah, definitely. I think sometimes, there's some confusion with that just because of the way what perks work on GitHub and the way our pages are rendered, that you may need to refresh the page before you actually see it take effect.

ROBERT: Right, yeah. Overall though, I love that bot. I go weekly, probably to the Probot apps listing and just go shopping.

BEX: Wow. I'm actually the person who approves all the Probot apps to the listings so that's pretty motivating there.

ROBERT: It's really nice. I am not even joking when I say shopping, I go through and I open up a bunch of tabs, I read through them, "Oh, this could be useful," that kind of thing.

BEX: The first app you mentioned, which was like the one that requests more info is actually one that I built, so that was kind of funny. I guess you got that from the Probot apps too.

ROBERT: Yup. That one, we definitely use on a couple of our organizations and repos. It has yelled at me a couple of times because of a blank PR.

BEX: It yells at me all the time. I think I get yelled at more than people who are actually doing it wrong.

ROBERT: I'm a little embarrassed like, "I should do better. I need to set an example."

BEX: Definitely.

ROBERT: Cool. I'm curious what both of your favorite Probot app is. This ought to be interesting.

BRIAN: The app that I'm really impressed with so far, that I actually only use on a junk project at the moment, is the weekly digest one and it's mainly because I built something for this in my previous role at the company but then we shift it, which is basically go through every single repo.

I worked at a company called Netlify previously and we had way too many repos to maintain... Oh, sorry, to keep track of and I was moving further and further away from the backend at the time so I was unable to keep up to date with all that was changing. I built a Lambda to watch Webhooks and then give me a digest of what was shipped like issues and PRs closed. It was way over-engineered and I never actually shipped that to actually make it work.

But then the weekly digesting came out maybe a couple of weeks ago and it blew me away because I was like, "This is exactly what I needed," and I was trying to make it overly complicated through like a Lambda and like a bunch of Webhooks and this person, with only a few weeks, has the scaffolding of what I needed. That's the one thing I'm pretty excited about. It was already mentioned earlier too, as well.

BEX: I guess, I would say one of my favorite ones is the unfurl a link app. I think that one it so simple but so nice. I don't know. I think having that unfurl link preview is just beautiful. Essentially what it does is it listens on issue comment creation or pull request comment creation or issues your pull request or whatever and read through the text or whatever was that issue or pull request and looks for links and then, essentially unfurls them so you can get a really nice preview of what you're going to. I think that's really beautiful and just so simple.

ROBERT: Yeah. I love that one too. I have that added to all of our repos.

BEX: It's so much nicer. Why would you not unfurl your links when you could unfurl your links?

ROBERT: Exactly.

CHARLES: I actually have a question. I think it's been touched on, probably at least twice throughout the conversation. I want to actually create a Probot, how do I actually go about deploying it? What does that look like? What does it look like to deploy and maintain it?

BEX: We have a page on our docs about deployment and essentially the TL;DR is you can deploy it on any normal cloud hosting service that you wanted to deploy it. There are a few things you need to specify. For example, GitHub gives you a private key that you need to create your JWT and that private key means to be passed into your hosting service however you do that and then, there's a few bits of information that need to be pass in. We have pretty intense docs about it. Honestly, I'm not a deployment person. I usually try to let other people do that and I have never had a problem going through our docs and just getting it working immediately.

BRIAN: It's also mentioned that there are examples like Heroku and Now and a couple of other ones. If you have a service that you already like, it's possible it's already in the docs, like steps to how to get that deployed.

BEX: Yup and any other services are more than welcome to be added to the docs. Pull request are welcome.

ROBERT: Sweet. It sounds like we need to set up a hack date to create a Probot, Charles.

CHARLES: Seriously, my mind is brewing.

ROBERT: I guess it's not directly related to GraphQL but there's something that I've always wanted to build. For prior history to everybody [inaudible], then the podcast, Brian and I used to work at a company called IZEA and one of the things that we built and I worked on a lot was we would create a collect metrics on people's social accounts that they're connected and do that and graph it over time. This idea came from when I was building up that feature all the way back in 2013, I want to graph the change in GitHub stars. Is there an API available for me to see like weekly GitHub stars or is that something that I still have to manually store and track?

BEX: There's definitely an API endpoint to get the amount of stars and I don't see why you couldn't just do that on weekly basis and compare but I don't think there's any track that change API.

ROBERT: Gotcha, like a history of it. I could do this by just stealing and looking at what the weekly digest Probot is doing because there is a change in stars section in there. I was just curious if there was now an API that was available.

BRIAN: Yeah, that's more unlikely. I'm going to say no without looking at all the reference documentation. I think as far as that database, it's something you'd probably have to collect on your own but it's also a good candidate for a GitHub app, where you build a service that you can actually track stars once you've installed it and then if you want to monetize it, you can actually pay for private repo or whatever stuff like that, if you wanted to. But it sounds like a great opportunity to see this in the GitHub/Probot listings.

BEX: I actually just look this app really quick in our docs because I was curious but apparently, you can receive the star creation timestamps. That could be doable through timestamp usage.

ROBERT: Oh, and then I just kind of loop through back and build your graph in there.

BEX: Yeah.

ROBERT: Interesting. All right. Well, [inaudible] I was going to do today.

BEX: Yeah. But I think it's exciting to bot the weekly digest and then what you could extract from that into stargazing is that Probot scheduler, which is essentially this all Probot extension we made that triggers a Webhook on a scheduled time period because right now, the way GitHub apps works are so centered around Webhooks. It can be difficult to find a way to trigger an action on something outside of a Webhook, like on a schedule basis.

ROBERT: Yeah, that would be really helpful. I can definitely see how that would be a problem, if it's very, very central to reacting to Webhooks and events that happen on the system.

BEX: Exactly.

ROBERT: You're just hoping that somebody comes through and creates an event at a specific time.

CHARLES: Can I ask you a question about, it's definitely on topic of extending GitHub but currently, just a question about, where the line is between what you can and cannot extend? You mentioned, for example in the rewrite of the WIP bot, being able to throw out a big button that says override this merge. Are there any plans to be able to actually extend the UI in novel ways? Everything there right now is happening with API calls, with I assume, UI elements that are related but the UI elements are static. If someone wants to put a novel piece of the UI, that button is going to require an extension of the GitHub UI by GitHub itself. Are there any plans to be able to, I know it's a dangerous waters, perhaps at a limited fashion at first but maybe more so, add different interactions and the actual application.

BEX: I think this is actually the most exciting future of GitHub as a platform. In the past, GitHub APIs have only specifically supporting things that you can do through the command line or you can do through GitHub's UI itself. The Checks API introduced the very first non-integration specific UI element essentially and the merge button that I was referring to in WIP is exactly that. It's essentially this button that you can change the text of it to be whatever you want and you can listen on that action and then you can do as an integration or an app, anything that you want based on that. I think that's the most exciting direction for GitHub.

Because if you look at Slack, Slack is a platform that has sort of really impressive integrations in that response. Your apps on Slack can really do all of these things, use custom UI elements, so I think the most exciting features for GitHub as a platform is all of this customization and giving the power to the apps.

ROBERT: Yeah, that sounds an awesome way to be able to extend GitHub without having to try and throw the feature on to GitHub developers.

BEX: Exactly. I feel that a lot of the struggle right now is that there aren't these nice ways of communicating via apps because I feel lot of the apps and bots end up just commenting on issues and pull requests and taking up a ton of screen real estate as a result and I just think that that's not the way that bot should ideally interact with the GitHub platform. They should have their own space to exist and that's the feature I'm most excited for.

CHARLES: Yeah. I can think of having like progress bars for CI checks and your various appointments. It's too exciting. I'm glad. That's definitely the response I was hoping to hear.

BEX: Yeah. We're excited for it too.

ROBERT: Basically, you all have a massive community of a bunch of developers that would want to do this and are willing to get their hands dirty on it. Enabling that community is probably the root of all Probot is about. That's super awesome.

BEX: Yup.

CHARLES: That's a good place to end, because gosh, it's going to be so exciting to have the millions of developers on the planet, just like surgeon to the APIs that you're developing.

BRIAN: One thing to add to that too, about the whole million developers, there's a number that's been thrown out from Stack Overflow and also, some other people who are saying like there's 50 million developers, there's 24 million developers. As far as GitHub, our public user number is 28 million, the cool thing about Probot and GitHub apps is that there's a good chance that all those people that are using GitHub today are not actually developers. They're like PMs or designers and what's really cool about this, like having interactions with that kind of platform in this way is that you can now enable all the non-developers to be able to interact with your GitHub repos and start bringing more designers and PMs onto to the GitHub platform to interact with the developers.

ROBERT: That is an interesting point. That is awesome and something that I'm always looking for is a different ways to collaborate with non-developers on my team because... I don't know, developers tend to think everything is always centered around code but it's not. The shifting at work that are awesome, needs a lot of collaboration from non-devs and non-dev skills. That would be really interesting to see. I'm excited for that to play out.

BRIAN: Yeah. There's a blog post that was published a month ago, I think about where the design team, design system teams rather, built the integration to Figma to update their icons effectively. I just posted that in the chat to look into but they also built this as a Probot app as well.

ROBERT: That is awesome.

BEX: Yeah, that one is super exciting. You would have the app comment, the diff between what the old icon versus what the new icon look like and it's just such a beautiful design change to be able to see that shift.

ROBERT: Man, I'm happy that this is happening. The future seems super bright. Where can we direct people to get resources to contribute, to get involved and start really going at this?

BEX: Basically, has all the Probot stuff, /app has all the listings for apps you can install today, /docs is where the docs are, if you want to get started and hopefully from there, we link up to the necessary things that you need to do.

BRIAN: Also, what I mentioned too via Probot Slack channel, there's a Slack channel as well and they do a weekly call. I think, it's weekly or bi-weekly call to actually chat with the Probot community. If you have questions, you can actually bring your questions to the team.

BEX: Yeah, we call it 'Office Hours' and it's once a week and it's under our community page, where we also have a link to our Slack. We have a link to another podcast we run and basically, how to get involved in the Probot community.

ROBERT: Those are really helpful resources. I do remember seeing that Office Hours. It's on Thursdays, right?

BEX: Yes.

ROBERT: I was going to drop in for one and then, I actually forgot. Actually, it might be going on as we talk right now in this podcast.

BEX: It starts in half an hour, I think.

ROBERT: That's awesome. Cool. Well, thank you Brian and Bex for having a conversation about Probot. This is really awesome. Is there anything that you would like to plug for yourselves? How people can get in contact with you?

BRIAN: Yeah, I am BdougieYO on Twitter. Everything you need to know about me is there and I am happy to say hello. I'm also helping with the GitHub developer program, which is sort of getting a soon-to-be announced rebranding. If you go to and you want to have more conversation about the API and GitHub apps on the GitHub side, you can go there to sign up.

BEX: And I am HiImBexo on Twitter. You can ping me in any Probot stuff. I'd be happy to look at any Probot code. I've been looking at it for a while now so I'm happy to do that.

ROBERT: That's awesome. Thank you all for having a conversation with us. This was really fun. I'm so excited about everything you can do with Probot. This is a really fun project. I'm happy that this is happening and I will make a Probot in the future.

CHARLES: I'm looking forward too. Robert has been excited for quite some time and he definitely talks a lot about it and now, I have some insight as to what --

ROBERT: It's happening, I'm telling you. Well. Thank you for being here and we are the Frontside. We build UI that you can stake your future on. We are specializing in JavaScript. We can build anything that you want throw at us. We do functional programming, React testing, Vue, anything in JavaScript, we specialize in.

As always if you want to suggest anything for us to have on the podcast or talk about, you can reach out to us at and like I teased earlier in the podcast, next episode is going to be all about Microstates, the immutable and functional state container, composable model system that we've been building, it's controls as a brainchild for the past two years. That is next episode and I'm really excited about that. It's a really fun API and expressive to build models with.

Thank you, Mandy for producing our podcast and we'll see you next episode.

Jul 05 2018



Rank #10: 020: Best of EmberConf 2015 (part 1)

Podcast cover
Read more

Charles and Brandon share their foodie weekend experiences, and discuss EmberConf 2015; highlights and what they learned.

Show Links:

Mar 16 2015



Rank #11: 019: Origin Stories with Tom Dale and Alex Matchneer

Podcast cover
Read more

This week, Charles, Brandon and Stanley were joined by Tom Dale and Alex Matchneer.

They took a trip in the way-back machine to discuss how they got started in programming and web development.

Show Links:

Feb 28 2015



Rank #12: 107: Microstates Part II

Podcast cover
Read more

In the last episode, we spoke a lot about the "why?" behind microstates. This time we wanted to cover how ideas in Microstates map to different patterns used to build JavaScript applications using frameworks like React, Ember, Vue and Angular. We discussed what you need to know about Microstates if you prefer component state architecture or global store architecture like Redux, as well as how setState in React can be refactored to use Microstates. We closed off with the comments about the trade offs that component heavy frameworks make by overemphasizing the view layer at expense of other aspects of the MVC pattern.

This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC.

Upcoming Conference Talks:


CHARLES: Hello everybody and welcome to The Frontside Podcast, Episode #107. My name is Charles Lowell and we are going to be following up with our Episode 106 with the exciting conclusion of 'Microstates, the Podcast.' With me today to wrap this subject up, at least for the near term, obviously we're going to be talking about it a lot in the days and months to come, are David and Taras, also co-developers here at Frontside. Hello guys.

TARAS: Hello, hello.

DAVID: Hi everyone.

CHARLES: Before we get into that, we'll just make a few quick announcements. First off is here at Frontside, we are going to be having some availability at the end of August. If you or anyone on your team is looking to level up in the area of testing, especially testing single page applications, acceptance testing single page applications or if you need React or general JavaScript consulting, please get in touch. We would love to work with you and love to do some of the great things together.

Second, we finally released this and this is germane to the topic at hand. We released a major version of microstates this week that's based on a new and simpler architecture. That's really exciting. It doesn't really change the content of the conversation because the API hasn't changed that much. It just means that the library, which was already very small is even smaller. I think we shaved almost 40% of the size off and it's just much simpler and it's much more harmonious with the underlying JavaScript runtime. It's even more just simple JavaScript objects.

Unless there's any other news that you want to cover, we'll jump right into it.

TARAS: All right. Let’s do it then. Let’s do microstates.

CHARLES: I Love to talk about microstates. This is obviously the second podcast that we're doing on microstates, just because we ended up, I think it was two weeks ago and we'd been speaking for almost an hour and really, we're just laying out the problems that microstates solve -- the problems of state management and why you often run up against complexity when you have a single state management tool that doesn't account for a bunch of different use cases.

We got into microstates a little bit but we left it as kind of a cliffhanger. We talked about transactionality and laziness and immutability, ease of composition, simplicity of API, performance, memory footprint, things like this. Those were all the problems and then we're like, "Yeah, microstates. It's awesome." We're going to talk a little bit more about actual microstates proper and what is involved like the adjustments in mindset that you need to make or don't need to make when adopting a tool like microstates.

TARAS: Actually, it's been really interesting for me because I just gave a talk at Toronto JS on microstates and it was pretty cool to see. There was a panel at the end. I think the people that are representing just using component state as a way of architect implication. It was managing state and application and it's representing redux. It's really interesting to see, first of all, like how curious people were. Most of questions were directed to the discussion around microstate, simply because it is a new tool but it was also just interesting to see how curious people who really loves redux, he was like, "I really love redux but I really like that fact that you guys have types," so I was like, "Oh, that's cool."

Even though you really liked your solution, you actually found something in microstates interesting but at the same time, I think he was kind of missing that what aspects of Microstates overlap with redux. I think one of the things that we can do today is talk about what microstates has and what API does microstates provides and how similar they are to what people already know. I think that's one of the things that I was thinking about this conversation is that there are some things around microstates API like how to use microstates but the architectural concepts that power a microstates, they are already part of the development process and development architectures for most people that building single page applications.

I think we can do is try to map these ideas not what people really know and patterns that they use to ideas in microstates, just to show how close we actually are. I think that's a good way for us to go.

CHARLES: I guess we can start with, maybe one particular mode of managing state and then, how that maps to uses with microstates.

TARAS: Let's start with components state because that was kind of our starting point. One of the original starting points for microstates because so much of our work was in Ember and component state is where most of Ember development happens. I think that's a good place to start. If you're someone who uses components state, if you're using Ember or Vue without something that is redux-ish which is pretty common these days, if you use components state, then one of the features of --

CHARLES: And also, if you're using React, right? Ember, Vue and React pretty much are all the same in this regard.

TARAS: Yeah. Well, Ember and Vue are a little bit different in that behalf. Their particular pattern is you have data coming into the component, then you're doing some work with the data so that in Ember and Vue, you might use computed properties to derive state on that and then you might pass that state further down into other components. In React, you would do something a little bit different because there is no memorized computed properties by default, so you, a lot of times, write your computations that you pass into other computers that are written as expressions in JSX.

If you're using this pattern, then one of the challenges around using this pattern is the process of lifting state becomes quite complicated. Because if you have like a bunch of state that lives in the component, it's attached to your derivation of state and the properties that you can invoke are attached to a component object. In React world, it's called lifting state. In Ember world, it'd be essential refactoring it into the parent component and passing that state in.

in microstates, you're essentially moving this state into the microstate and now, what you have is this object that instead of having the state live on the component, the state now lives on the microstate object and in all frameworks, when you do that in microstates, you can use the getters to get the memorized computed properties behavior on the microstate. If you use your computed properties, computed properties are available for you on the microstate. You can do it the same way.

CHARLES: It's kind of like a wrap up of that idea, not a wrap up but a summary of that idea is that the microstate essentially is a substitute for your component properties. If you're working with a component, a component has state associated with it, so you're setting properties on a component and then using the computed properties of that component. Microstates is you have all those benefits where you can set properties directly. You can define methods that like set properties as part of a transaction and you can then have simple JavaScript getters, which are just like computed properties except there's no enumeration of dependent keys. It's just, that's all they do for you.

TARAS: Then the next question that arises is like, "Do I make like one huge microstate or a bunch of smaller microstates?" I think the question is really depends on the role of your component and what's nice thing about microstate is in microstates, there's two things that are kind of cool. One is when you represent your status in microstate, it makes it very easy. If you need to lift that state from the component up into the parent, you can lift that type. You can take that type and you can compose that type into the parent's microstate, if you have to and in that case, you would pass this new object that's created from that type. You'd pass the state for that component to the component that would otherwise have its own state. Essentially now, the parent has the state that would otherwise be in a child component and now, the parent is passing a state from the parent to the child.

There's two kind of benefits to that. One is it gives a parent a way to control the state of the child and it also gives you a really easy way to serialize and deserialize state. You start off with having ability to serialize state for a particular component and all of his children, now you can represent that serialized state as part of the components state, so you have an easy way to restore the state of the component tree at the parent component.

CHARLES: Right and that's possible because a microstate is really just encapsulating a value within a type but the value is just a simple serializable plain old JavaScript object, right?

TARAS: Yeah.

CHARLES: I'm just not trying to say like this is the feature that microstate provide, so when you're creating a microstate, you just pass it a POJO and it off to the races with that POJO and you can access that POJO at any single point.

TARAS: Yeah. This is part of the architecture that I think are helpful for people that are using components. Is there anything else for people who are using components state that we think would be helpful?

CHARLES: I think we're just realizing that you get the benefit of the laziness and immutability and the transactionality and all kind of things that we talked about last time but actually, the mental model is very similar. I think the thing to realize is that if that's the way that you used to working with state, the bridge is not too far. It's actually quite a short one.

TARAS: Yeah, that's good.

CHARLES: It feels very natural. It's not a huge mental shift. It's just more about a very small mental shift, a very small shift in mechanics for a very large payoff.

DAVID: For instance, say you're in an Ember application using component state, what I'm used to is you're going to be passing actions around between components. Whenever you're trading that out for microstates, is it more that these actions are just bundle in with the microstate as the transition?

TARAS: Yeah. One nice thing with the microstate, because the transitions that you can perform on any data type are intrinsic to the actual data type, the part of the data type, when you instantiate a microstate, you get these transitions for free. When you pass the object into a component, you can now invoke transitions on that object, that are part of that object's type. It's hard to imagine how awesome that really is because the closest pattern that you would see for that would be like, for example, if you're using Ember, you have Ember object or Ember model that you pass into a component and then, you can work a transition and because it goes through the Ember data store, your component is going to update.

With microstates, there's no observation of any kind but what you're doing is when you are invoking the transition, transitions going up to the top of the root and gives you the next microstate, which updates your component tree. You get that functionality of 'data-down, actions-up'' built into the entire system of the microstates and all of that is hooked into these transitions that you can invoke on the objects that you pass into your components.

CHARLES: Right, maybe David and Taras, you all could provide a concrete example of what that looks like. Because I think it is something that when I was giving talks on microstates at Ember meetups, one of the first things I like to show is you've got all these actions that you're writing either on your router or your controller but they're really actions manipulating the same type of data. It really comes down to like you're pushing and popping things off of arrays, you're toggling Booleans, you're incrementing counters, you're setting this property on this object. These are actions that we're writing and in the kind of microstates world, that's boilerplate. Because the transitions are intrinsic to the data type of the microstate that you're working with, maybe we could provide an example, like what's an action that you describe that you would pass around.

TARAS: I think an easier one would be like if you have a model for example, you're composing a model into your application state or you're compose a model into your components state, so you have this model type that gets instantiated and you pass it into component that represents a model. Off that model, you might have open status like is it open or not that gets consumed by the model component, to know whether the model should be visible. Then along with that is model is open state, there is a toggle transition that you can find inside your component that is going to automatically flip the visibility of open.

What will happen when you bind that transition to some kind of action handler that you invoke inside your component, when you invoke that action, it will then trigger transition at the top of that microstates and then, it will create the next state, push it through which will cause your model to change the visibility. David, that does answer the question?

DAVID: Yeah, it does and that's actually the example that I have come up with whenever asked. A very simple sort of Boolean toggle.

CHARLES: In a couple of my earlier demos, I should dust off that talk that I gave to the Austin Ember meetup where I was able to create an input with a dropdown menu with basically, some pretty advanced mouse behavior, all without having any component state or like storing it all in microstates and a lot of pushback was, "Aren't you putting logic in the template?" and the answer is, "Absolutely not."

The logic is in the models but what I'm doing is I'm composing the actions that operate on those models inside the templates but at the template level, the action is data. If you're thinking about, we always want to have, we always want to lift state and then push that state down to the application, what this is really saying is that the actions are part of the data. It is implicit to the value that you've got.

TARAS: I think that's really powerful because we do think about actions as being something that you can invoke. Like with closures, it's an action that you can invoke but considering that operation, that piece of data that invokes a transition in microstates and is derived from the type of the data, I think it's a cool concept. That's probably, one of the things that is kind of new for microstates but how you use it in your application should feel pretty much the same as you would if you were creating action handlers on your components.

CHARLES: Yeah, just like kind of bundled action handlers for free.

TARAS: Right.

CHARLES: Maybe the way that you wrap up on this one when talking about kind of what microstates has to offer for the Ember developer, the Vue developer is really, I would say someone who's used to working with like MobX. Would be another good example is when I first started using Ember back in 2012, Ember Object solved a whole lot of issues in a really profound fundamental way and I really, really was drawn to that as the best API to be working with state. What kind of became apparent was perhaps not the best implementation.

This is not like bag on Ember Object. I think it was actually amazing technology for seven years ago when most of it was written and probably, even came from before like SproutCore. It's almost 10 years old, which is incredible but it's still under heavy use in 2018 and it speaks well of how well it was constructed. I actually don't have much of a problem with Ember Object API. I just think that the way in which it's implemented that API means that there are some problems that require a different paradigm, so very much I kind of see microstates as heavily inspired by those types of APIs but with, I want to say a modern implementation but an implementation that is designed to solve the problems that have come to light over the last five years of developing single page JavaScript application.

TARAS: I want to add that, when you describe with Ember Object, it exists in every framework that uses immutability. In MobX, the observation introduces the necessity to wait for a bunch of things to resolve. In Angular zones, I saw a similar purpose to ensure that if there are kind of cascading or streams or all of that stuff gets settled in into kind of restful state before you can start to assert on what's going on and with Vue, their computed properties has something similar.

I think because of the complexity of having to track lots of objects and then recomputing things based on the result, that complexity in microstates is simplified by the fact that you describe you transitions. When you write them, you describe exactly what changes, so we don't need to wait for things to settle down. When you invoke a transition, that transition is explicit and based on the path of where that transition is invoked, we know exactly what needs to change, so we need to only perform one operation to compute the next state.

There is no other things that we need to wait. There's no other side effects that we need to resolve before we know what the final status. I think that simplicity can be applied to all the frameworks that are using immutable APIs and derived computations from those immutable APIs.

CHARLES: Uhm-mm [affirmative].

TARAS: Should we jump into talking about what microstates has to offer for people familiar with redux?

CHARLES: Yeah, okay. Let's jump right into it. For folks who are familiar with immutable APIs like Ember, like Vue, like other ecosystem using MobX, a shift to microstates might feel like what you can expect. What about people who are just using often React-land and they're just using like set state.

TARAS: Set state is a little bit tricky because it does get complicated over time and then you get this kind of funky things going on after a while where you start seeing things like, "I'm going to set state on this component and then once the change happens, I'm going to change some states some other state," so this kind of cascading state changes.

The other part that I find particularly more challenging in set state world than it is in, I think in regular components state, like what you have with Vue and Ember. I feel like the way that the transitions, the state change handlers become part of the component, I find that part particularly kind of fragile. When you start doing refactoring, when you need to lift up state, it's like --

CHARLES: What's an example of this?

TARAS: When you start off and your component owned old state and now, you need to have that state being controlled by the parent, we get into a situation where like, "What am I going to do? Am I going to do something with props as they're coming into the component or I should probably just flip that state from the child to the parent?" and now, you're refactoring the internals of a component to lift up that state so you can then combined those operation with the parent's state transitions. But then, you have this kind of added complexity of the fact that you're working with immutable data in that place.

You’ve got these three things going on: you’re refactoring your child component, you are moving these things into the parent components, you modify a parent component and now, you're also managing the complexity of forming immutable objects. I think the fact that people make it work is kind of a testament to human resilience. The people are able to solve such challenging problems and this is not a super hard one but when a component is complex enough and when stakes are high enough, these changes can become fragile.

This is what I think microstates simplifies is that by taking care of the model, it makes components much simpler and makes it possible for you to just render a lot of components that are functional components without their own state.

CHARLES: It actually reminds me and like I said, we're talking about what it's like to use them, not so much the implementation but that's the exact same sentiment that the author expressed in his book that was very helpful in writing microstates, which is Brian Marick. He has this book called 'Lenses for Mere Mortals' and he's talking about the practical use cases of using lenses, which microstates leans very heavily on. What he says right in the introduction is it gives you by abstracting the location and compose it the way in which your data structures are composed, it makes them very refactorable.

You can say, "I want to change where the state lives. I want to change the structure of this object and I want to move it somewhere else," and it's sounds weird to say this, because the structure of the object is not coupled to the structure of the object, it means that it's very malleable, so you can move and you can say, "You know what? I don't want this address to be embedded in this person. I want this address to be inside this address book and then my person has an address book entry." Being able to make those refactors make those changes is very easy because your method of accessing the data is abstracted.

It’s something that applies beyond even user interface as a component state but it's something that this is a problem that's very salient when you are authoring complex UIs and compose components. It's something that you can benefit very greatly from.

DAVID: Taras, you were telling us earlier about a friend of yours who is learning React for the first time over the past few months and he's mainly been using set state as you would just starting out in this world. You said that he didn't really get why you might have to go and learn some other way to manage your state and I think Charles said it, whenever your application starts to get more complex and you've got a lot of different moving parts, that's really where microstates will come out and shine for you.

TARAS: Yeah. My friend kind of feel bad because he's spent the last three months learning how to work with React and how to use set state, "And now, you're telling me, I need to learn something else? Like I'm going to start from scratch?" I kind of reassured him that especially when you're a beginner, when you're learning, you learn how to address very specific challenges but you don't know how complicated these things can get when your UI gets really intricate.

In those intricate scenarios is when you have to leverage your experience and you'll be able to solve these problems but if you're learning, you encounter these challenges head on and your tool does not really, like set state. Although it can be used to build really complex UIs very effectively but the complexity that over time increases as you start to manage the state, increases much more later on than does early in the beginning.

Basically, with microstates, even if you have some basic proficiency with set state, when you start working with microstate, the things that you can do with microstates, you will be able to do more sophisticated things easier when you need to use them than you might realize when you start. Because microstates API is so consistent, there are a very few concepts to actually learn and they cover a broader range of use cases so when you actually starts using it, you'll encounter these challenges. What you already know it will just work for you and always just continue to work for you. That was part of kind of fundamental design on what Charles and I have spent, a lot of time putting into place from a point when we started two years ago.

CHARLES: I think, and you touched on this and this is kind of what I was speaking to earlier is that when you're working with a simple system, it's simple, it's easy to work with and then the complexity starts to grow, it's never a good thing when you have to reach for a more complex tool to manage the complexity. It's a hallmark of a good system and that it can scale with you from a very simple and easy use cases to actually being able to handle very large and complex use cases but your API doesn't have to change and your usage doesn't have to change.

If you have a tool that can actually scale with you from a one liner to a hundred thousand liner, that reflects very well on the design of the tool. I think you see that with things like Ruby, you see it with things like Clojure. You see it with, I would say there's even people writing like Haskell, shell scripts now but not so much with like C++. I think the analogy is very similar with microstates in the sense that when I'm looking for evaluating a language, it's not the only thing I look for but I really am looking like how is this going to work for me as a one liner? How's it going to work for me as a hundred thousand liner? If the answer is pretty consistently, then that's something that is going to get a lot of bang for your buck, so to speak. If I invest the time in learning it, I'm actually able to reap the reward of having a tool that's got my back on a whole bunch of different use cases.

We talked about, in React, if I'm using set state and that's kind of a sub case of component state because I would say that in the previous systems we talked about -- Ember, Vue -- they have components state but the component state is a little bit more rich in the sense that you've got computed properties and what have you. But if we look at a system that externalize a state like redux, where you have a global state atom in your application, at least that's the way most of the redux applications that I've encountered behave, what does it look like for you?

TARAS: I think it's a little bit challenging when talking about redux is redux conflate a few different things together. I think it's helpful to split those things up, so we can talk about them separately. One of the parts is how the state is delivered to components. The way that redux does is the instance is this created so every time you use connect, you essentially wired together. You can connect through the context or... I'm not sure. I think they have an observation mechanism that's internal to redux as well but they essentially connect components to the store and then they view that to deliver the state.

It’s kind of worth pointing out that for that like microstates bindings for React actually give you something similar out of the box through context. For those who really like the ergonomics of connect, I think it would be pretty easy to make that available for microstates. Usually, we don't even know why they wouldn't be available.

CHARLES: But I do think that connect can be problematic like you can encourage you to not make components that are reusable and have isolated state. It's very easy to hitch yourself to the redux store and now, you don't have components that are shareable.

TARAS: I think I would personally prefer to pass microstates instances through props because of the stability that's built into microstates and structural sharing, you can get some free optimizations and allow it to use functional components in more cases like out of the box but some people who are really like redux, they really like connect. Although it might be my personal preference, there's no reason why that wouldn't work if somebody wants me to connect function and make it available for people.

CHARLES: Right and I think, there's a happy medium there too, right?

TARAS: Yeah, I think --

CHARLES: -- You can connect components and then fan out that state to a set of functional components that are not connected.

TARAS: There are some places where microstates and redux are very similar. When you're using in redux, you have this dispatch mechanism, where you essential saying, "I'm going to dispatch this action and your action creator is going to create an action for you with the payload," and then you're going to match that action to a reducer.

One of the things that I kind of hear redux people really enjoy about redux is the one with data flow that dispatch the action and then, it reduces this next state and pushes that through and you have this kind of ingress point where everything is going through this one point. I think what's really interesting with microstates is you essentially get that. That's exactly how microstates works, in a way. The only difference is that the API is different. Any action that you invoke is going to go through a single entry point, which is going for you. Because we know the structure of the data, we know how to transition that state for you, so you don't need to reducers, so you're just defining your transitions or use the built-in transitions and then when you invoke them, we know the path.

We’re essentially forming for you. The path where you invoke the transition, conceptually, it kind of forms the name of the action that you are invoking. The path refers to a place where the state is going to be transitioned, then you have your transition, which is the actual reducer for that part but it's contextualize, so you don't have to think about how you need to transition that state in a great, global redux state.

CHARLES: There's no matching. The matching is automatic.

TARAS: Yeah, the matching is automatic, so you get that same single ingress and one directional dataflow. You get those mechanics except the APIs that you use, instead of writing the actions yourself. Instead of writing, we just use yourself. You get to use microstate types.

I've heard some people who use redux who are like, "I really love the fact that microstates has types," but other people don't like types for whatever reason. Microstates comes with 'from,' which allows you to take a POJO and from that POJO, it creates a microstate and then you can invoke transitions the same way as if you had a type microstate. The only thing you don't get is you don't get to create your own transitions. You have to use the transitions that are provided for the primitive types.

CHARLES: I think that there's a couple of benefits that you'll realize for free. There's laziness, reducers by default, or eager. When you dispatch an action, it will run against every reducer in the store. If the reducer matches, you're going to run the computation that's associated with that reducer.

Microstates by contrast is lazy. Basically, until you try and read the property that is affected by that reducer, the reducer won't run. There's some ways that you can get around this. When you're using redux and first of all, you can actually have your reducers return objects that have getters on them. You can realize some of that laziness but again, it's work that you have to explicitly put in.

I think, didn't you actually say that there is a package of plugins? There are plugins. There's basically a set of libraries that you could bundle together, which would give us an experience similar to using microstates.

TARAS: Yeah. If you wanted to combine redux and reselect and immutable JS together, you can get some of the benefits, except this benefits are not integrated that well because they're still separate systems that you are essentially using together. Also, like microstates, it's four times smaller than redux and reselect and immutable JS combined together. If size matters to you and ergonomics matter to you, you actually can get a lot of ease out of using microstates while still maintaining the benefits of having redux.

CHARLES: But if those things, those packages, like reselect and immutable JS, are things that are familiar and you naturally gravitate for it, then you'll probably absolutely love microstates. Because honestly, one of the ways that I think about microstates is like, what if you could have immutable JS, if there was no cost for composing the types like list and record. Immutable JS has come a long way since I've last used it or it's evolved since I've last used it but I think there's still only about four or five basic types and actually, making your own new immutable structure, your own custom type with its own custom methods that still get the benefits of structural sharing and laziness that you have on immutable JS is not something that you can do. But you could think one way to think about microstates is an immutable JS where you can make any type that you want. You're not just constrained to the record types and to their list types and set types or map types.

TARAS: It's worth pointing out that at the moment, microstates doesn't map perfectly to immutable JS simply because immutable JS has certain optimizations for managing lists that kind of a great value of immutable JS and microstates doesn't have some of those pieces but --

CHARLES: They're definitely on the road map.

TARAS: Yeah. Because microstates is abstracted high enough, that we can actually change internals and some people who are using microstates now, they will get benefits of ergonomics and there's already performance benefits from the stability that microstates offers but there will be a time when by upgrading to newer versions, you will not basically, need to change anything in your op but you will get the benefit of improvements to performance that we will introduce over time. Some of those improvements might come from what we will learn from immutable JS.

CHARLES: Right. I have a couple of thoughts before we wrap up. What are the ramifications no matter who you are? What kind of development background, some of the benefits that you'll experience with microstates that might be a pain point or something you hadn't thought about where you are currently? A couple of things that I have jotted down is first, and this is what brought it to mind is talking about stability. Something that you see in a bunch of frameworks is having to manually track the keys that are associated with data. If I've got a list or I've got an object, being able to say, if that object changes, then I need to actually have some sort of key object, which effectively amounts to a hashing function to say, "Did it really change?" Because no matter what system you're in, you need to know how you're going to re-render. If the reference to this object changes, then the default thing needs to be, "I need to re-render it," right?

You see this in Ember, in Vue. In React, there's this ability to pass a key or ask the question, "Should this component actually update?" and with microstates, that's much less of an issue because basically, it keeps the key tracking instability for you. If you are using a model with microstates, if you think of an object as a graph of nodes, no node in the graph will change unless it absolutely has to, at least that's the goal. We still actually have some work to do when you're running queries against the state of a microstate. We can cover that later but that's most largely the way it is now and definitely, the way it's going to be going forward is you don't have to do any extra work as a programmer to figure out what has actually changed.

TARAS: That opens up some interesting opportunities. Imagine if you had a rendering engine that did not expect side effects to be significant and you could just say, "If I know whence they'd changes, I will then re-render that." That will be really interesting exercise, seeing like what would that look like for a performance perspective, if you have a very clear picture of what has actually changed and what part of the DOM as a result, need to be updated without having to do diffing. The [inaudible] you could actually do a diffing at much higher up. Actually, [inaudible] to diffing because you know what's changed but you can push a lot of assumptions higher up on the architecture stack.

CHARLES: Right. That's actually one of my favorite thing about microstates and one of the unwritten values is like triple equals used to work everywhere and by and large, it does. It's usually simplifying but when you don't have to manually tell the computer what equivalence looks like, you can just say, "Look, are they the same object? They’re not the same. If not, then they're not," and keeping that consistent is huge.

TARAS: I think this is a good segue for us to kind of bring this conversation to a close and also, kind of set up potentially a third full-on conversation, which we could talk about actual architecture of microstates and design decisions because for people who just want to use microstates, they don't need to know all these details but for people who are curious, they might actually want to understand what are the considerations that remain when we were designing microstates, so maybe in a next conversation about microstates, it could be about architecture and the pieces in microstates today and then where we are going with microstates and what it could give us long term.

CHARLES: Yeah, I like that idea. It is a plannable subject that we've been talking about internally for the past two years, so it makes sense that there would be plenty to speak about on the podcast. There is one other thing that I did want to bring up and that is, I think enabling to have a state solution that is composable because it allows you to think about your state first. Because really, if you do have a functional UI, where your view is a pure function of the model, that your view follows the model and so, if the view follows the model, then really, the thing that you should be thinking about first is the model that's going to be required to drive your view. I shouldn't drive. I should say derive your view because that's the primary artifact of which the view is nothing more than a function. It's a reflection onto a surface.

I don't think that we have a state management solution yet, that enables that mode of thought, where I'm thinking about my prime artifact first and working forward rather than thinking about my secondary artifact and trying to kind of wishy-washy way, work backwards and reconstruct the primary artifact. I think that we've talked about all the development ergonomics and I think there's a mechanic of thought there that's enabled by this that I hope to see in more and more applications.

TARAS: I think that's a really well put. I think that's something that I've been thinking about as well, as how do you convey this shift that microstates allows in terms of how we're thinking about architects and the application. For some people that value, the model, like they'll find that shift easier but regardless, I think that making that shift has a potential of simplifying your view dramatically and I'm very excited about exploring this further and having more conversations about this.

CHARLES: Yeah, that's where we really kind of open up the conversation about state machines, which is also central to the conceit of microstates and using state machines as an incredible design tool but anyway, we can all get into that later. You heard it here folks, Episode 3 is coming out, although probably not for a while. We're going to be mixing up and we will be talking about microstates at least for a while. I understand that next time, we actually teased it but we based on how much material there was on microstates, we ended up packing in a second episode. We teased it last time, we're going to be talking next time about running an online conference with Twitch, so definitely look for that.

Thank you, Taras. Thank you, David.

TARAS: Thank you.

DAVID: Yeah, it's been great.

CHARLES: This is a wonderful conversation and as always, we are Frontside. As I mentioned at the top of the show, we have availability coming in August, so if working with us is something that you would like to do, we have a range of services, please get in touch. You can get in touch with us at @TheFrontside on Twitter or

That's it for now. I guess we should also mention that Taras that you are going to be giving a talk on microstates at ManhattanJS. When is that?

TARAS: On August 8th.

CHARLES: I will be giving a talk on microstates at ReactJS Austin on Monday, the 6th, so that is right around the corner. I'm excited about both of those talks, especially following so closely on the heels of the TorontoJS meetup talk, which I understand is... Is that posted online yet?

TARAS: It's recorded but it should be coming out soon. We'll definitely tweet it out.

CHARLES: Okay. All right. Look for that and we will see you next time.

Aug 02 2018



Rank #13: 018: Back-End Devs and Bridging the Stack with Toran Billups

Podcast cover
Read more

Toran Billups joins us for this week's Frontside podcast.

We had a great conversation about test driven development, code rot, the challenges of bringing back-end programmers into front-end testing, why Toran loves pair programming, and more.

Show Links:

Feb 05 2015



Rank #14: Team Collaboration with Jacob Stoebel

Podcast cover
Read more

Jacob joins the panelists to talk about team collaboration based on his RubyConf 2017 talk, Code Reviews: Honesty, Kindness, Inspiration: Pick Three.

Jacob Stoebel is a software developer living in Berea, KY. He spends his days writing web applications in Ruby, JavaScript, and Python, working with data, and leveling up as a software engineer. He works and studies at Berea College. You can find out more about Jacob at

Please join us in these conversations! If you or someone you know would be a perfect guest, please get in touch with us at Our goal is to get people thinking on the platform level which includes tooling, internalization, state management, routing, upgrade, and the data layer.

This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC.


CHARLES: Hello and welcome to The Frontside Podcast, the place where we talk about user interfaces and everything that you need to know to build it right. My name is Charles Lowell, a developer at the Frontside. With me today from Frontside also, is Taras Mankovski.

TARAS: Hello, hello.

CHARLES: Hello, Taras and today, we're going to be talking like we do every time about a piece of the platform that you used to develop user interfaces frontside at your company or organization or wherever it is that you build software. Today we're going to be talking about a piece of the platform that's very, very critical that often gets short shrift or is excluded entirely from what people think of when they think about their tech stack and that's how we as teams collaborate to build and maintain and produce the quality software that we can.

With us today is Jacob Stoebel. Welcome, Jacob.

JACOB: Hello.

CHARLES: Now, what is it that you do, in your day-to-day?

JACOB: I'm a full-stack developer for a little company called ePublishing and I mostly work in Rails and React.

CHARLES: Rails and React and so, when we were searching for people to talk about how we collaborate these teams, Mandy suggested you because of a talk that you've given at a RubyConf, specifically about code reviews, which I think are actually a huge piece of the collaboration process because it's a major forum where team members get to interact with each other and it's the gateway for making sure code quality is maintained but more than that, I think it's a learning -- a place where we learn. I learned so much both as a reviewer and as someone who is submitting my work and so, it's actually a very important part of the software development process. You have a lot of great examples of how to not do code reviews.

JACOB: Yeah, I think I may have been a little bit too indulgent in that talk. I had a lot of fun. I did some research from other people, mainly from anecdotes. I had research from talking to people about really, all the anti-patterns that come out of code reviews. It seems like every few weeks, I'll see a tweet that says something along the lines about how code reviews are broken.

I don't really know about that and I have to say, I think I'm kind of lucky at my job that I think they're done in a way that really leaves me feeling pretty positive and that's certainly a good thing but I think what it comes down to -- I'm going to sort of talk about where these ideas come from in a minute -- is that we often have code reviews that for one -- and you can tell me how this is for you too -- often the code review is happening at a point so late in the process, where the feedback that you get may not be actionable. Have you experienced that?

JACOB: Before I answer that question, just to kind of echo the sentiment and maybe I'm being presumptuous, I feel like the code reviews that we do are actually very positive, so I haven't got to experience firsthand. Although I have seen conversations on GitHub where it looks kind of like a Celebrity Chef, where you have someone doing the code reviews like Gordon Ramsay up there just screaming and someone has put this plate of food in front of them and kind of picking it apart. That one is extreme but this is actually something that I struggle with, what you were talking about, what is the appropriate point at which to get feedback.

I agree that you want to get feedback as soon as possible and sometimes, when you've invested weeks and weeks into something or you're like at Mile 100 and they're like, "You know, at Mile 2, you were supposed to turn right," and now, you're off in the forest and you've been tracking 98 miles in the wrong direction.

JACOB: Yeah and the work is due, right? This needs to get ships tomorrow.

CHARLES: Right, so you've got massive pressure. This is something that I struggle with myself is when is an appropriate time to really try and be public about what it is that you're doing.

JACOB: Yeah. I think that is a really good question and I think what you're getting at and I would agree is that, the sooner, the better and when you can tighten the intervals between feedback is probably better.

I'll just take a step back and I'm going to take a longer route to go and get to my point. I am a career changer and before I was in this career, I was a high school theater teacher, so it was really different and I won't give answer why I changed other than this is the greatest [inaudible]. But one thing that I really struggled with is I was working with teenagers and I really wanted to see them grow and improve but at the same time, these were kids and they have fragile egos and I don't want to tear them down, so I came across this really interesting framework for feedback. It is called the Liz Lerman's Critical Response Process and I give credit to her in the talk.

This comes out of the dance world. Liz Lerman is a pretty accomplished dancer and choreographer and what she found is that in the dance world and I think it's not too dissimilar from our industry is that the feedback received was often given in a way that was leaving people feel really torn down and mostly, not feeling inspired to go back to their work and make it better. It really felt like feedback is about giving you a grade. It's like, "I'm going to tell you how good of a job you do," and there's certainly a time and place for that but the inspiring question -- I guess the rhetorical question -- that she made is, "Shouldn't the big point about feedback be that it makes you so excited about the work you're doing that you just can't wait to go back to your keyboard and keep working on it," and she found or in the case, back to the dance studio, it really sort of structures this framework for how people can give feedback to a creator and that could be a creator of anything.

You mentioned cooking. This could be about food as well that sort of set some guardrails for how we can give feedback that is useful, it's inspiring and it's kind. I'm going to really distinguish between kind and nice. Nice would be, here I'm going to say things that are only pleasant about your work but what I mean by kind is feedback that is really taking care of your team and making them feel like they are respected and cared for as human beings so they don't go home every Friday afternoon and cry on their couch and just drag and coming back on a Monday. That's kind of the basic idea of why we need, maybe a kind of a framework for getting feedback.

CHARLES: I agree totally. It's almost like you need to conceive of your feedback is not a gate to quality but a gift to embolden somebody. It's like they've just been doing battle with this code, with this problem, they've been grappling with it and it needs someone to wipe their brow and maybe give them a stiff drink, so that they can get back into the ring and be invigorated.

JACOB: Yeah.

TARAS: What I'm hearing in this conversation so far is it's kind of like a tone or way of communicating to the person receiving the feedback but sometimes, no matter what your tone is, depending on how your team is set up, depending on the context of your actual code review, it can still kind of land in the wrong place? Have you experienced that where the team conditions impact your ability to actually provide feedback?

JACOB: I think I know what you mean. I think what you're talking about is this sort of the organizational structures that are set up are sort of lend themselves to certain modes of feedback and discourage others. I will give this example that I've heard from numerous people and I think this is what you're getting at is feedback that's given at the end. Just like I said, feedback that is given the day before, it has to be shared. Or feedback that it's almost like if we work in an environment where sort of like the hair on fire environment where it's like everything was due yesterday, that's not an environment that's going to be conducive to slowing down, taking a step back and saying like, "Let's point out what we think this work is doing? What questions we have about it? Who has opinions about the direction that's being taken on it?" And really zoom out a little bit more.

CHARLES: Do you have any concrete examples of how that early stage feedback has taken place at your work? Is it just over Slack? Maybe, the whole people need to step back from the idea that working on one-week iterations or two-week iterations and at the end of the iteration, everything is due and everything will get merged at that point. How do you kind of break up that structure to say, "No, we're going to try and have checkpoints and milestones?" What are deliverables that you can decompose the work into that fit inside the framework, that are inside the big deliverables, which is sensibly, the feature that you're working on?

JACOB: I think first of all, it's the way this thing goes about. I don't think this framework works over Slack. I think it has to be immediate, I think it has to be either in personal or on Skype or Hangouts or something.

One of the points of this type of feedback is really about checking in with each other as a team and I think what's great about Slack is that it lets you leave a message and walk away and the unfortunate thing about Slack is it's not meant for sort of attaching how people feel about things or what people's reactions were to them. I think you all have to be in the same space, hopefully with your camera on, if possible and really, just sort of checking in with each other as a team.

I can point to times with my team that I think that's really worked out. I think you made a good point when it comes to really getting started with a project because there are times where I made the mistake of not trying to get feedback from my team early on when I was going to start a project and as you can imagine, did that really cost me? It's really getting feedback from my team and my supervisor about the direction this is going to want to go and I'll say from experience, I work on legacy codebases and as you can probably imagine, it's easy to paint yourself into a corner and what the thing about legacy code is that you don't know what pitfalls you're working into. You can get started and you can sort of find into the process, there is some reality about this code that you didn't know and it is really getting in the way of your work that had you known about it, it would have saved you a lot of trouble because you could have planned your way around it.

Then the fortunate thing is drawing on the wisdom from people who they know about it because they struggled with it already if they've been around longer than I have. I think that's a really good point. This is a good thing to do. As you're getting started and you can be sharing this is my just initial idea of how I'm going to go about this. What my tech stack is or my understanding of the problem space, all of the above and to really sort of check your assumptions and see if they really check out.

CHARLES: I want to circle back a little bit to something you'd mentioned before and that is you want to be kind in a code review and I would say, you probably want to be kind anytime you're giving feedback or interacting with your teammates but what's the process that you can go through if you find yourself struggling? How can I deliver this message that I want to deliver and have it come across this kind? What's a process or checklist that I can go so that I don't open my mouth up and say something that I can't take back or that is going to land wrong?

JACOB: I'm glad you asked that and I think that this is a great way to introduce the guidelines for the critical response process. There's basically four steps to it and the way it's structured is you have the person who has created the thing. It could be the person or the team that has created the feature. You have other people who are responders to it. They could be people within your team or they could be others in the organization who are invested in your success. They're not here to tear you down or give you a grade. They're here because they want to see the project do well and then, there's going to be someone who is a facilitator.

The way it works and I think this is directly addressing your question is there are guardrails that are going to help you not steer into territory that is going to leave someone feeling torn down. The first step to this process is all the responders are going to say statements of meaning about the work and what I mean by that is you're going to make things that stand out to you that are not attached with an opinion. You could say, for example, "This project is using React hooks. That's something I noticed." You're not going to say, "I think that's a good idea or a bad idea," but you're going to say, "This is what I'm noticing," and that is something that can get jotted down because that's going to be fodder for discussion later on like, "Let's talk about this new feature in React," and let's talk about it later. We can talk about if we think that's a good thing or not or what the implications are for that.

The next step after that is that the person who has made the work of the team, they get a chance to ask questions of everybody else about what they thought. You've probably noticed that in a lot of pull requests, someone puts their work out there and then, the next thing that happens is everybody starts commenting on the work and saying what they think about it. This flips it. At first, you as the creator, start asking questions or you can say, "This thing over here, I think it's maybe a little wonky or it's a little hacky but I couldn't think of a better way to do it. What do you think? Do you think it's right? Do you think it's a bad idea?" Or this bit over here, "I'm pulling in the third party library. I think maybe, it's worth it but what do you think? Is it not worth it?"

CHARLES: I like that because ultimately, the people who have created the thing are the most familiar with the problem space. They've spent a lot of time thinking about it and so, they can actually direct the conversation to the parts of the implementation that really are the most iffy and the most unknown because everybody is going to feel this need to comment but it's the classic case of bikeshedding really, the true experts or the people who've just been spent all this time implementing and so, people will comment up to their greatest point of familiarity with the problem, which could actually be not that great. Can you say like, "Can you really focus your mental energy on this?" I like that a lot.

JACOB: Yeah and really, it sets a good tone. The assumption behind all of this is that the creator, like you said knows the work best and really ought to be in the driver seat when it comes to feedback, so it really sets the tone there and say like, "The creator knows what's most important. Let's give them the first opportunity to frame that," and I know plenty of times like if I'm asked to review a PR and I'm not given any kind of prompt or direction, I will probably scroll to the file. Maybe I'll find the file in that PR that I'm actually familiar with or I'll look for some pattern that's something that's like, "I understand what's going on here. I can give feedback," and if it's all that other thing over there, I'm completely confused, I'm going to ignore it.

But the creator could illuminate me a little bit, then I would understand a little bit more and then, I'm in a position to comment on that thing that I otherwise wouldn't have understood. That's the second step. The third step is now the responders get a chance to ask their questions but the important thing about that is that there are neutral questions. The assumption here is that the responders need to better understand the context from which this code was written in order to be able to give their opinion.

Here's an example coming from the Rails world. I could say, "Tell me your thought process for using Factory Bot," in this example. If anyone doesn't know that is somewhat of a contentious issue in the Rails community, rather than just coming out guns blazing and say like, "I think this was a bad idea." It's like, "Tell me your process because I want to understand the context you came from and then we can together evaluate if coming from that context makes sense or if it doesn't," so neutral question. They have to be neutral questions.

By the way and we've probably all heard this before, this is not a neutral question, "What were you thinking when you decided to do blah-blah-blah-blah-blah." Everyone knows what that means.

CHARLES: Right. I was going to say, you can be very, very passive-aggressive with questions.

JACOB: Yeah, exactly and this is a place where having a facilitator can really help -- facilitator who is not one of the creators. Someone can just say, "Let's back up. Can you rephrase that without the opinion embedded? Can you just say that again?" and with that again, those are some of the guardrails that keep us on track.

After the responders have been able to ask their questions how hopefully everyone has a better understanding of the context from which the code was written, then it's time for opinions with consent of the creators. The way it works is the responders can say, "I have an opinion about using React hooks in this codebase. Would you like to hear it?" The responders can say, "Yes, please. Let me know," or they can say, "No, thank you," because the responders, having the best knowledge of the context, might know that that feedback is not useful. Maybe, they have a really good reason for using React hooks or maybe, they know what's coming in the future or maybe, they know if there's no time to fix it now or it's not worth fixing now. They know the tradeoffs best and so again, those are guardrails and it puts the creator in the place of saying, "That's actually not useful feedback right now. Let's just not use it." They can say, "Yes, please tell me," or they can say, "No, thank you. Let's not talk about that."

CHARLES: In the context of a pull request, the process you're describing could be played out in any number of media but in the context of a pull request, the creator is the person actually submitting the code, how do you handle the issue of who pushes the merge button if there's still some opinions that haven't been voiced? For example, a creator says, "No, I don't think that's helpful feedback," is the assumption of then the creator can go ahead and just push the merge button? Or is it basically saying, "I don't want to hear your opinion," relatively rare?

JACOB: That is a great question. I think I tried to get at this in the talk. Before one thing, I am probably, like most people don't have the option to just say to my manager, "No, I don't want to hear your opinion." I get that. There is a contrast between the pure version of the feedback process and then reality. They have to balance. But teams can sort of work out the way they give feedback.

I have example of an anecdote that someone shared with me once, when I was doing research for this talk. There was this sort of agreement with the manager that their manager wouldn't give feedback on Friday afternoon. They just wouldn't. Everyone preferred that. Everyone sort of wanted, say on Friday afternoons, I'm really going to be just focusing on winding down for the week and I don't want to get dumped on a bunch of feedback. The point being, even though you can't just blanket-ignore feedback, you can work out circumstances with your team for the best way that feedback can be given and circumstances under which, it can be politely declined.


TARAS: I'm curious about a different part of this because a lot of this is how to give feedback but I'm really curious about the why part. I think many of us take it for granted that good code reviews are very valuable because a lot of teams that I've encountered that are taking on really big challenges but didn't have a code review process and so, one of things I'm kind of curious is for people or for teams that don't have it in place, what kind of symptoms can they observe in their daily operations that would suggest that maybe code review is something that they need to put in place.

CHARLES: Taras, you're talking about kind of the places where we've seen where the culture is just push everything to a branch, there's a 1000 commits there, open up a pull request and no description, no name. It's like, "Here's this thing. I'm taking comments for the next three hours and if everything goes well, let just merge." Are you talking about those kind of situations where really a big culture of pull request or just feedback around change is very, very nascent.?

TARAS: Yeah, a lot of times, it's the 'ship it' culture, like this is getting in the way of shipping it.

CHARLES: So you're saying like how you sell the entire idea?

TARAS: Yeah and if someone is listening who is noticing that, a lot of people would know that we're not really doing code reviews but what are the symptoms that they could be observing that could say like really, this is we need to change, like this can't continue.

JACOB: Yeah. One thing that occurs to me as if there's all high level of surprise when you read it, when pull requests are read, it's like, "Oh, you went in that direction." I think that could be an indication that maybe, we could have checked in at the halfway point or even sooner because there seems to be differences of perspective on where this is going or where it should end up that's why [inaudible].

TARAS: At what point do you think people would see this? Is this something that would happen kind of way down the road? Like actually, "How did this end up in the codebase?"

CHARLES: That's surprising except deferred even further, right?

JACOB: Yeah, who wrote this last few. In having that kind of feedback process, let's sort of take a look at where this project has come in the last few months and see if we can sort of learn from what went well and what didn't.

CHARLES: This is related to the concept of surprise, if you see a proliferation of many different patterns to accomplish the same thing, that means the communication is not there. People are not learning from each other and not kind of creating their own code culture together. If that's missing and that manifests itself in all kinds of ways, in bugs, in weird development set up that takes me two hours to get this local environment set up and things like that, if you're seeing those things, chances are you need some way to come together in a code review culture is really, really good for that.

JACOB: Yeah and I think in the ideal code review culture, everyone that's sort of brought on board is saying, "I am going to share responsibility in this patch, doing what it's supposed to do and not breaking anything or not burning down the world." You mentioned the 'ship it' culture, I could imagine toxic cultures where the person who shipped it, if it broke everything, it's on them to fix it and they have to get woken up or whatever and the idea about feedback is now we're sort of forming a community around what was done, so it's like the person that push the merge button isn't the only person involved. It's like if we have a culture where we say everyone that participated in the PR is collectively sharing the consequences and that will happen eventually and say like, everyone who's on this thread, it's on all of us if something goes wrong to fix it. I think that is certainly something that one would hope you'd see.

TARAS: I'm curious, where do you see this kind of observations usually come from because sometimes, I can imagine there, being a developer, coming on the team and they're like, "Why wouldn't I do code reviews?" and they're like, "Well, we have always not done code reviews," but then there could be someone like a product manager or somebody who's like, "Why wouldn't I do code reviews? We should start code reviews." Have you seen ways of introducing these ideas to teams that have worked out well?

JACOB: Yeah and I should probably say that, I'm not a manager, I'm certainly not an expert in how this works so I actually don't have a really great example, personally. I can churn example from working in a previous team, where everyone secretly wanted to be more collaborative but didn't know how to do it because if I'm the first person that puts myself out there and no one knows else knows how to collaborate with me, how to reciprocate, then what was the point? For the top 5% of teams that are just really have great energy together, they don't need a framework to do this sort of thing. They're just doing it naturally.

I think for everybody else, we need some kind of guidelines to do this because for better or worse, this is the industry that we're in right now. It isn't built around us. We don't know how to function this way and it's no one's fault. It's just sort of that's the way we've all sort of learn to work in this industry and I suspect we're not the only industry like this but we need some kind of guidelines to do it.

TARAS: Maybe it's a difficult question to answer. It varies probably from team-to-team.

JACOB: Yeah.

CHARLES: Yeah and maybe, we can kind of shift the question just a little bit because I have one that sits alongside not quite the same question but I think related and can bridge it and maybe we can find the answer there. We've talked about a little bit and there's definitely more to unpack there, how to give feedback that's kind and honest and I think to... What was the third?

JACOB: Inspiring.

CHARLES: Inspiring, that's right. What about from the flip side? This is something that actually comes up with us as consultants but I think it's something that other people will encounter in their jobs too, is what do you do when you are the creator and you're trying to present or share and ultimately solicit feedback from a stakeholder, the CEO of your company, one of your clients, one of your customers and you see them engaging in kind of a mode of feedback that's less than constructive. They're nitpicking on things that aren't really important and maybe, this could be completely and totally inadvertent. Their intention could be that they're trying to help you out but it's really not being helping at all and it's kind of like either tearing you down or just not being productive and it makes you feel... What's the word I'm looking for? Just brings an air of contention to the conversation that's not really helpful to producing the best result for everybody involved. How do you, as the creator actually engage with those people in a positive way and kind of help establish the guardrails and be that agent of change when those guardrails don't exist in their minds yet?

JACOB: Yeah, how do you do it, right? It's probably rare that there's going to be an environment where someone's going to say, "We're going to do this framework for feedback," and everyone are onboard from Day 1.

I think one of the things that you're probably getting at is the frustration that happens when people start giving feedback. You have this perception that they're giving you feedback that's unuseful and they're only giving it because that's the only thing they can think of or --

CHARLES: Exactly. They got to say something, they need to contribute their two cents to the conversation and some people are trying to be helpful and just aren't. Some people are just trying to appear smart.

JACOB: Yeah and it's like, "Oh, boy. They're just really off."

CHARLES: But you can derail the main narrative that you're trying to establish and get off in the weeds, kind of skirmishing with these people and after that happens, you're like, "Wait, no. I don't want to end up over there. I was trying to tell a story."

JACOB: When I gave this talk once, one idea that someone threw out was when you make a PR, mark up your own code first with everything that you want to draw people's attention to. I think you were getting at this as like, "One frustrating thing is when people getting feedback seem to have less invested than you do." They sort of just flying by and dumping on you and they probably, actually couldn't care less and that can be frustrating.

When you're engaging with people that maybe don't know how to get deeply involved in it yet or maybe don't have the time to, you can sort of gently nudge them to sort of like, "I want to talk about this part of it." It's almost like you're giving the answers to the test, which was like, "If you want to be part of the smart conversation, comment over here," and I think from the responders perspective, just speaking personally, I would appreciate that. It gives me an opportunity to feel like I'm actually being useful. We can all probably point to times where all the code review we have to do feels like homework that isn't the best use for our time. It's like, maybe the responder can make us feel like our opinions matter and they will be put to good use when you tell them, "If you comment here, it will probably be put to good use."

I think the sort of the way to get started is the responder can just say, "I would really like feedback over here," and I can't speak for everybody but I would suspect that more people than you think would be more than happy to be gently guided in what feedback they should get.

CHARLES: Right. I'm thinking how you would do this, for example in the context of a demo that you're giving to stakeholders because there's maybe the inkling of the idea to do that but it's often presented as an apology like, "This screen doesn't work," or, "Your handling isn't quite right. Sorry we're going to fix that." Look at the stuff that's over here and maybe, the way to frame that is a really hard problem based on the legacy architecture that we have for displaying errors and I'm not quite sure how to do it in a robust way and I could really use some feedback there. It's an area of exploration or something that we really need to focus on. You put that out there as I'm demoing this main functionality right now.

JACOB: Yes. You sort of say like, "Here's something to watch out for and please, let us know what you think," and then after you could say like, "As a team, we thought up these three possible solutions but we didn't want to move on them because we wanted to get your feedback first, so please impart on us what is the right way to do it." You know, flattery goes a long way.

TARAS: I have this imagery coming up in my mind as I'm hearing you guys talk about this that I keep seeing this kind of difference between a line and a triangle, where a line is kind of a tug and pull between, "Did I do this right? No, I didn't do this right." I think those are kind of a bad code review because it's very personal. It's not really where you kind of want to go and then the other way is like a triangle where the end goal that you're trying to get to is somewhere that is beyond both places where you let two people: the recipient of the code review and the giver of the feedback, the end goal that you want to get to is actually someplace else.

When we deliver the code and we say, "My code is done," then it invites this kind of linear feedback where it's like, "No, you didn't do it right," but in the other way, "This is where I got to so far. Tell me where you think we could take it next. If you don't think we need to change anything, then we're done. We can merge this."

JACOB: Yes. The very intelligent Jessica Kerr said recently on another podcast, there's no such thing as done but you can always make it better. I think you're getting at that point. That's a great question, by the way to ask of your responders -- where should we go next? Where do you see this going next? What will make it better? What would make it more robust? What would make us happier six months down the line when we're looking back on this? But I think of it as the firing range. That's the analogy I gave where it was like, "You put a pull request out and you assert that it is done and if no one can find fault with it, then it's done," and I just don't think that that makes sense. I don't think, really most people actually want to work that way. It's maybe not necessarily even healthy but I think everyone can find, at least I hope, a process that invites them to come into the process and share the way they see things. It can hopefully be enriching and just make everyone feel better along the way.

TARAS: This sounds to me like the inspiration part of this conversation because one thing I really like about working at Frontside, I'm an to experienced developer but I know that Frontside is dedicated to doing something much greater than I can do as an individual. When I ask, "What do you think about this?" then I know the feedback is going to be because there something always that is just beyond the reach that could be a little bit better than what we have right now and it's not until I can actually get the feedback from Charles, from Jeffrey and hear, "What do you guys think? Is this it?" and they're like, "What about this?" and I know that the next step is going to be a little bit or maybe even a lot better than what I have right now. I think that's the part that inspires me. I know I have actually gone a little bit further beyond my personal ability to get us to that vision of like this being much better than we could do as individuals.

JACOB: Yes and as opposed, "Oh, I screw it up and now, I have to fix it." The framework of find all the errors that I made, even though there may be errors. Let's be honest, there could be things that would be really bad, that would be a security problem but for a growth mindset, to think about it, it's like, "This is a way to make it better."

CHARLES: One of the things that you can do to help that is try and find inside every change, try and see the potential that hasn't yet been realized but is enabled by this change, like what exciting paths does this change unlock in your mind, right? And then you can share that. That's a great way to 'inspiration is infectious,' so if you can find inspiration to change, then you might be able to share that with the creators. If something is very personally exciting to you when you see something, maybe spend a little time searching for what you find to be exciting about it.

JACOB: Yeah, nice. That's great.

CHARLES: Yeah, we might have touched on that. I just bring that up because so often, I'll see the changes that people on my team are submitting and sometimes, it can feel like a cloud burst of like, "We could do this or we could do this or we could do this," and it's great to get excited.

JACOB: Yeah. I can share -- recently, there was an example. My coworker opened a pull request and it unlocked something for me where I said like, "You know what? This is making me think about this other thing that I've always hated doing with our legacy codebase. We should do that thing you're doing more because boy, would it make life easier?" and I wonder if it would be worth the time in refactoring X, Y, Z because then I would never ask you A, B, C again and I would be so much happier.

TARAS: It makes me think that we need to revisit our pull request template like what would that like? What would be the sections on a pull request template that would facilitate this kind of way?

CHARLES: I don't know. I know we're almost a time but before we even get into that, this is a question I have because we talk about pull requests templates, how do you match the amount of process with the scope of the change? Because it's probably a little bit heavy weight if I want to fix a typo and say, "Now we're going to have the creators lay out their case that they're going to ask questions of the reviewers and then the reviewers are going to ask questions and once everybody's been able to write down things that they observe the questions that they have, completely and totally divorced from opinion, now we can talk about opinion that is welcomed." If you're capitalizing one letter, that's probably a little bit heavy weight but on the flip side, it's probably absolutely warranted if it's a major feature that's going to be affecting a huge portions of your revenue stream and so, this is one of the problems I have with pull requests templates is they are one-size, fits-all.

Sometimes, a pull request template feels like it's supporting you and sometimes, it feels like the epitome of busy work and I have to spend all this time deleting the sections for the pull requests template. I wish there were ways you could choose different pull requests templates. Maybe, there are.

JACOB: So do I.

CHARLES: That's a little bit of a quibble that I have is the amount of ritual and ceremony that you have to go through is fixed with a pull request template but it seems like you want to match the amount of process to the scope of the change.

JACOB: Yeah, you do and the flipside is also joy. You don't want to give someone too little homework when you really needed the same work. Maybe there's a way to say, when a pull request is opened, the person who opened it or the manager or maybe someone else, has the option to sort of tag the pull request as saying, "This is going to be a bigger conversation. We cannot merge it until we have a face-to-face conversation first with these various stakeholders." Maybe, one of the questions, the first form that everyone gets for every PR gets is what level of PR is this? Is this a quick change? And what people that you just need some quick feedback on? Or is this the long form that you need where there needs to be a sit down with these people?

TARAS: Actually, I was thinking what's the adjustment that could be made for pull request is to say, "Here's what a complete pull request looks like. You can opt into whatever section you want," so you decide based on your pull request, what the actual sections of this template are appropriate but then someone can, on the flip side say, "Look, I would really like to learn about the motivations of this pull request. Can you add motivation section?" and understand that from your pull requests.

JACOB: Absolutely. You filled out Section A, please answer Section B and C. Yeah, cool.

TARAS: Yeah. Because I think what part of the challenge is that we have people look to us, especially people who have a lot of experience, or developers look to us to know what is the right thing to do sometimes or often and I think it's helpful to be a little bit more gentle and saying, "You can decide what is the right amount of detail to set the right conditions for this code review but I will give you some directions for what are things you can consider in including.

JACOB: Absolutely.

CHARLES: All right. We're a little bit over time, so we should probably go ahead and wrap it up. You are absolutely right, Jacob. This is a topic that keeps on giving. We didn't really move much beyond the pull request and feedback and stuff but we moved a lot around within that topic because it's a big one. Jacob, is there anything that we should mention? Any upcoming talks, meetups?

JACOB: No, I have a one-year old and it's all about work and family in this part of the life, so I have nothing to speak of at this point. You can come find me on Twitter as JStoebel.

CHARLES: Okay, awesome. Well, thank you so much, Jacob for coming and talking to us. This is a very rich topic. We only really scratched the surface. That's it for our episode today and we'll see you next time.

Thank you for listening. If you or someone you know has something to say about building user interfaces that simply must be heard, please get in touch with us. We can be found on Twitter at @TheFrontside or over just plain old email at Thanks and see you next time.

Mar 14 2019



Rank #15: 109: What Do You Need in a JavaScript Framework?

Podcast cover
Read more


In this episode, former Fronsiders, Brandon Hays and Chris Freeman join Charles and Taras to talk about the difference between a framework and a library, whether or not React + Redux a framework in itself, red flags to signal that you’re actually building a framework, attributes of a good framework, how can you tell if you created a bad framework, and how you can make a bad framework better.


This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC.


CHARLES: Hello everybody and welcome to The Frontside Podcast. My name is Charles. I'm a developer here at Frontside and today, we're going to be talking about the things that go into making a JavaScript framework. Because, hey, there's not enough of those in the world today, so we're going to talk about that and with me is Taras.

TARAS: Hello, hello.

CHARLES: And we've got two very special guests, who have a lot of experience with this topic. Mr Chris Freeman and Brandon Hays. Hey, guys.

CHRIS: Hi, there.

BRANDON: Hi, there. We're talking about the poofberry framework, right?

CHARLES: What's a poofberry?

BRANDON: There's a tweet that's going around right now that one of them says, "I don't know what I should be doing," and the next person says, "Oh, just use poofberry." What is that? It's like fluffnuts but the [inaudible]. Hey, dot, dot, dot. Then, it integrates with log bungler.

CHARLES: There's a reason that I'm dying laughing.

BRANDON: It's so true.

CHARLES: It's so true, laugh, cry, laugh, cry. Let's start with kind of a very basic assessment here. Because there's a lot of different things that you can use to compose the applications that you build but for some reason, some of these things are grouped and considered as libraries and some of them are considered frameworks. I don't know that the boundary is very clear like I'll know it when I see it type thing. Maybe, we can start with what is the difference between a framework and a library?

CHRIS: I have some thoughts of these. I feel like this is one of those questions that could easily just turn into an infinite bike-shed but I remember reading something a while ago that stuck with me for a long time. I'm pretty sure it's related to Java but that makes sense because if anyone is going to talking about frameworks, it's Java developers. But it was saying that the difference between a library and a framework is inversion of control and the idea is a thing that's a library is a thing where you are in control. You bring the library code into your code and it's up to you what you do with it.

In a framework, the framework code calls you as I think what it said. It's like, you call the library code, the framework code calls you and --

CHARLES: In Soviet framework.

CHRIS: Yeah, exactly. A framework says, "Here are a bunch of open spaces for you to put your code in and I will take care of the rest," versus a library is just like... I don't know, "Here's some things that you can use. It's up to you. What do you want to do with them?"

CHARLES: Right, so in kind of like [inaudible], that would be basically, a framework would be the thing that's got the main method. I think the same thing in JavaScript and when you call it, does it actually implement the main method. In JavaScript, it'll probably like in node. Under that definition, it would be like, "Are you the main scripts when you invoke node? Do you control the main script?"

If you were doing your own command line parsing, for example, you're looking at the process.rb and pulling off the command lines and doing all the things but even if you're using something like Yargs or option parser in Ruby, that's more of like a framework. I guess Yargs is a library because you're still implementing the script. You're instantiating the Yargs thing.

TARAS: React calls render to figure out what to convert to DOM. Does that make React the framework?

CHARLES: I think React as a library. That's a good question. What's the equivalent of the main method on the web?

CHRIS: I think there's a very clear distinction, especially if you look at React versus something like Ember and I'm sure Angular does this as well. In React, by default, to build a React thing, you're going to pull in React, you may write some components, you may import them elsewhere but the main method is that you have an index.html with some div in it and you are the one that has to call ReactDOM.render and you pass it like document.query selector or whatever and then, your top level component and that can be as simple as complicated as you like or you can have a webpack plugin do it or whatever else. But the onus is on you to actually take that React app and get it starting up on the page versus Ember, it's like, "There's an index.html. It's fully wired up." There is one point where you sit down and say, "Start my program here," like Ember abstracted all that away. To me, that's the main method for a frontend application.

CHARLES: Right and if you actually look at something that Ember generates, then look at index.html, they generate a script tag for you that instantiate your application and mounts it on an element. If you want to change that element, that's actually a configuration option that you can change but it still a configuration option that's consumed by the framework. In that sense, there is that inversion of control. I see what you mean like in React, you're the one who flicks off the first domino, like who's the prime mover. Is it you or is it the framework that knocks over the first domino?

BRANDON: I like Chris's explanation and I think it's elegant to say because I was thinking in terms of structure. If it imposes a structure on you but really, the structure is there, it's like one of those Ikea shelf systems for you to put stuff into. If you're trying to solve a problem, here's a shelving system for you to put stuff into, whereas a library is just the tool that you might get out to put something together. Something that's multi-purpose but doesn't impose any structure on you or a ton of structure on you. My question is what's the usefulness of distinguishing between the two?

TARAS: I think what's interesting and I had experienced this in a last couple of projects is that people, especially React when they kind of assume, because a lot of people entering to React not understanding the context within which React emerged and so, they're getting into React assuming that it has everything you need to build application that you need to build. A lot of them haven't necessarily built a single page application from scratch before and so, the jump into building something with React and then, it takes about a year for them to realize the full scope of all of the features that their application actually has and then, they kind of take a retroactive look and look like, "Okay, what do I have now?" and what emerges is that they've actually over the last year, they may be creating a framework without realizing that this is actually happening.

CHARLES: They've imposed the structure of saying, "Here's the shelving system. Books about geography go here. Books on English literature go there and so on and so forth."

BRANDON: But when you rolled your own framework, that's not how it goes. It's like, "You have to launch this balloon into the stratosphere to put a book on the shelf from geology." Taras, to your point, it sounds like the importance is setting expectations properly for people, so that they know what they're in for because kind of calling back to Ryan Florence's post a few years ago, you can't not have a framework. At some point, you will have a framework in order to ship something.

I would actually take it one step further. My friend, Kyle talks about this that library is the smallest unit that you're working within a framework but that still doesn't take your code to production and put it in a debugable state. You need a platform. It's arguable, if you're handling deployment tasks and debugging tasks and operating software in production, you now have a platform and it's fair to say that Rails crossed that threshold at one point. It's fair to say that Ember has probably crossed that threshold, if you combine Ember with CLI deploy and the CLI tooling and all of that stuff. This almost like acts as a platform if you're owning and maintaining the software in production.

CHARLES: Now, can I play devil's advocate here and say, the platform, is that necessarily predicated on a framework? Is there a pyramid where it goes library, framework, platform and one is built on top of the other? Why couldn't I have a library? Because what I'm hearing is the scope of concerns is just rendering HTML based on a state is a very small chunk. The actual scope of things that you need to do to get that code in production and have it be reliable and do all of the features that you want to do is just massive but why is that predicated on a framework?

For example, one thing you have is a bunch of libraries out there, like routing for managing the title tag, managing all these things that you have to do for managing deployment, for building your application, for compressing it. There's all these different libraries out there. What if there was one massive library that just picked a bunch of other libraries but I was still in control?

TARAS: I've actually seen this happen in the last of the projects. When people jump into building, they will eventually realize that they're building a platform but what happens before that is that they take user's requirements and they break those up by sections and then they assign them to a bunch of development teams who go and actually start to build. On one platform, they end up building five or six or 10 of siloed, packaged applications that have, in some cases, have their own dependencies, they have similar architecture, might not have similar architecture.

Each team kind of implements thing differently and there's an expectation that once you package these things as npm and then you install them into one package, to one application when you run build, it's just going to work together. That's where I think, with the framework, it does create a foundation for these verticals to be implemented using kind of common foundation. This is what a lot of times that as if you don't realize that what you're trying to set out to build, the way that the projects get managed quite often, especially for big applications, for big platforms is that, it creates this period of about two years, where there's a lot of confusion and there's a lot of duplication and then, you end up seeing code that it's hard to put in production.

CHARLES: Yeah, I agree. I'm curious then, because we'd started out talking about library and framework and talked about it takes two years to recognize that you're building a framework or you're building not a framework but a platform. Brandon, you said something very interesting. Rails for example, crossed the threshold of being more than a framework and actually, being a platform. What are the concerns of a platform that are beyond a framework? We talked about and using the kind of loose definition of a framework as being something where the framework create spaces for your code, to run your code so you can just take little dollops of code and they have one concern but the framework manages the coordination of the concerns but what's the next level?

BRANDON: For the purposes of this conversation, I may have muddied the waters a little bit because I think it's more interesting to talk about the transition and the level of which you've crossed the threshold from being a library or using libraries or collecting libraries, into maintaining a framework because it's where you're going to experience more pain more than likely, than to me, the idea from works on my machine, to deployed and supported across a lot of users, it sounds like it's more interesting but it's not where we experience most of our pain actually. From my experience, maintaining frontend single page applications most of the pain is actually getting the damn thing to work on your machine and getting the libraries to collectively work together and then, getting that to production, it kind of enters back into an area of more known unknowns.

I think that's a surprisingly a more mature ecosystem, still getting from this thing works on my machine to getting it out the door. That wasn't true when Rails was invented and so, Rails had to invent a lot of its own ecosystem around this stuff. Like I said, I don't want to muddy the waters too much.

I think to me, the interesting question is how do you know you've crossed this threshold? What pain points are exposed when you start crossing that threshold or when you're pushing the boundaries of that threshold? Because you should not be using a framework if you're using React to do a select dropdown. I think of it as, if you're using it the way to replace something you might do with a jQuery plugin five or 10 years ago, you're using React like it's a library. One of the questions that you brought up was is the combination of React and Redux is a framework and I would argue that it is but I kind of want to throw that out --

CHRIS: Oh, interesting.

CHARLES: I would say, it's two libraries stuck together to make a bigger library. It's like a monolithic library.

BRANDON: But by the time you're actually using that to do anything, maybe the third thing in there is like transitioning states when you transition routes. At what point is that threshold crossed? I didn't build most of the software that led me to some of the opinions that I have about this. This was actually Chris Freeman's, though. I may defer to you on this.

CHRIS: I think React + Redux constitutes if you look at what it does. You have like this view layer and this state layer. There's a set of opinions on there that is useful and there is the foundation for doing quite a bit but in my experience, you've already kind of alluded to this a little bit. I don't think it's a framework because as soon as you start using those two things, suddenly the next thing you hit is, "Wait. How do I handle asynchronous things?" There's a lot of different options for that. "Oh, now, I need to do routing. How do I incorporate routing into my React app but also in a way, that is amenable to state transitions in Redux but also, that is aware of the async stuff that I'm doing, that is going to possibly be triggered by my routes and by my Redux actions or by some other side of things?"

Suddenly, you are very quickly pulling out a bunch of other libraries but also, probably starting to build abstractions on top of them because you're already finding a lot of common patterns that you're repeating over and over as you incorporate more and more pieces of the stack and then, you're writing a lot of glue code. I think that's the point where suddenly, you look back and behind you is the footsteps of this framework that's been walking alongside you the whole time.

BRANDON: That is where I carried you, then dropped you, then sort of drowned you.

CHRIS: Yeah.

CHARLES: And then, kicked your core.

TARAS: I'd like to suggest a way to think about this. As you guys are talking about, it kind of occurred to me is that it seems to me that libraries concentrate on how and frameworks focus on the 'what.'

CHRIS: Oh, I love that.

TARAS: Because if you think about for example, React is how geostack efficiently update DOM, then Redux is how do you wire together state across multiple components that might be in different parts of state tree and if you look at, for example, a React router or a kind of a routing component is how do you choose which components you want to render when you navigates specific URL. Because those things by themselves are not a complete solution but when you combine them together, what you get is you have a way of saying, "When I navigate to specific URL, I'm going to load specific data, provide that data to components and then, I would have a way to navigate through a different URL when you click on a link."

From that, I think what happens when you get to the framework level is you actually have a kind of a bigger umbrella and under that umbrella, you have ways to address problems that you did not have previously. I think that's what framework does it is over time, it's a way of addressing concerns that cannot be addressed with a solution. They have to address with a collection of solutions and then, they provide a specific solution. I don't know if that's --

CHARLES: That actually sparked off a train of thought in my mind that perhaps what you really want to do is say, "I'm going to go a little bit like Lisp on you all," in the sense of every code at some point is data, that maybe every library, at some point is a framework. It's just that you can look and say, "What is the scope of the 'what' that I'm tackling." For some point, you can say like React is a framework. It creates this space where I can put my JSx, AKA the render function and I'm basically inverting control and so, what it is, it is a framework for efficiently rendering HTML or efficiently mapping an object to a fragment of DOM and then the DOM that gets generated from your render function, patching that into the HTML. You don't have to worry about that. There's that inversion of control. It creates that space but that's the only space that it creates.

From that perspective, React is a framework for generating HTML but that's all it is but it is a library for constructing applications. Does that make any sense? I think as you layer on concerns, your framework create spaces for you. You use your library code to put stuff in and so, in the same way, I think one of the key realizations, I'm going to call up like BigTest and I'm not going to take credit for this, which is actually a blog post that I read at Google. I can't remember what it is but we'll link to it in the show notes where he said, "There are no such thing as unit tests. There are no such thing as acceptance tests. There are just tests of varying scope." They're all acceptance tests. To use that one thing, they're all experiments. It's just what is the scope of the test that you're trying to accomplish and his argument was we want to make that scope as big as possible by default and then, where appropriate, you narrow down. Maybe, the framework library distinction is a little bit constructed, kind of a construction of our own minds and what really is there, there's just frameworks of varying scope.

BRANDON: Agreeing on a shared scope is actually probably the most important part of this conversation. We're referring to building end-to-end an application from data access to rendering to testing --

CHARLES: To deployment to routing.


CHARLES: To one day accessibility.

BRANDON: Yeah. Adding that into the discussion is like a baseline of what constitutes an application. It's the percentage of people that are able to actually use it, the people that are locked out from using it by ability. That's a very useful frame for the discussion. Let's agree on the scope of what an application is and then, coming back to what Taras was saying is basically, when you're talking about the 'how,' that's a decision point.

You hear a lot of people talk about decision fatigue in JavaScript and it's almost a played out trope at this point but it hasn't gone away as a problem, so what frameworks are doing is they're making a series of decisions for you that allow you to basically connect the pieces from end to end. Basically, somebody threw a rope bridge across the canyon and it doesn't have to be the best solution to get end to end but we have to solve the problem end to end.

If we agree on the places end to end and the problem is when you're building your own series of libraries, you're like, "I'm going to choose best in class of A, best in class of B, best in class of C," and that sounds really good but if you're trying to build a bridge across a canyon and you're building in 10 best of class sections, for the type of connection we're trying to make here in the middle, we're going to use the best in class here. The weak point is in the connections, so you had better be the world's foremost engineer if you're going to be the person connecting all these disparate pieces that are each best in class, in order to bridge this canyon.

That's the thing that's interesting to me and it's not even agreed in our industry that JavaScript-based web applications are a good thing or that the browser is web application runtime, those are things that are up for debate. But I think if we make that assumption, this is sort of the founding principle of where Ember came from and it executed to the best of its ability at the time and that philosophy is, I think you can prove it out in terms of results based on if you have two different applications, one of them is built by somebody trying to jam together best in class components and the other person is starting with an end to end solution with a community of people rallied around that solution. It's been interesting to watch those approaches play out over time. I know Chris has a very specific hands-on experience of having done both of these. I'm curious to get your hot take.

CHRIS: There's actually a concept that I think about a lot in relation to this question. It's something that I actually heard come up again recently so the timing was great but it's called hypocognition. The idea is hypocognition is when you either just like can't see or can't understand some kind of cognitive representation of something because you don't have the words for it. An example is in Western cultures, especially like in English speaking cultures, there are not that many words for the color blue but in a lot of other cultures, they have many, many words for the color blue. After doing a big study they found that these English speakers actually have a harder time recognizing different shades of blue, like more of them just look the same versus other cultures where their brains are actually wired to see all this variety because they actually have the linguistic representations for these ideas already.

When you were talking about maybe a library is a framework at some point, I think that's right on. I think one of the things that I think about a lot when talking about frameworks and seeing these debates happen on the internet about, "What is a framework?" but also like, "Do you even need a framework?" is obviously, there's a lot of people who absolutely... Like Ryan Florence. Ryan Florence clearly knows what a framework is. He knows what it takes to build a web application and he does not lack the words to define a framework versus a library. He's just made that choice and it's a very informed choice but I wonder if there's also a lot of people who are getting into web development for the first time and they look at something like a framework and it seems just absurd to anyone would want all of the things that like in Ember or in Angular is talking about, when they can make a basic UI with React and it's easy and fun and really cool.

But then this two-year path happens and they look back and they've learned a whole bunch and now it's like, "Ooh, you couldn't even have explained this to me before," because all of the words would have fallen on deaf ears but now suddenly, it makes a staggering amount of sense.

CHARLES: Right. I love that.

BRANDON: You have to make a bad one.

CHARLES: Just so that you can inherit the vocabulary to understand why you made a bad one. Now, you guys actually have some experience with this. Brandon, you gave a talk about it, which I think you should give more widely because it's fantastic but for those folks who may or may not be aware that they are walking this to your path, I want to talk first about what are the signs that you're walking along this path and then two, what are the consequences in terms of the cost you're paying for walking this path. Let's start with that first thing. What are the signs? How can you tell that I am building a framework?

CHRIS: I think one of the telltale signs and one of the biggest red flags that caused me and Brandon to have a very serious heart to heart about our own personal framework was when we hit the point where you could look at a set of tickets for features and all you saw was 'framework features' that you needed to write before you could build the feature itself. You know like, "Oh, we have basic routing setting and we have it set up so that if you have a route transition and you would like a data request to happen when a certain route transition happens, that will happen," but then someone would like infinite scroll and we want to use a query param. When a query param changes, I want to update the query and fetch more records, except that the glue code that we wrote to tie our router to our redux async stuff is not aware of query params. It has no concept of what a query param is or what to do when it changes. Also, it has no concept of refetching the data without a full route transition, so what do we do, this person wants infinite scroll but I first have to implement several layers of framework code before I build the UI feature that you want?

CHARLES: The basic heuristic there is ratio of direct feature code to code that supports the direct feature code and code that supports the code that supports direct feature code. It's anytime you're anywhere above that first layer on the stack.

CHRIS: Yeah, I think Taras nailed it like what's the 'what' versus the 'how.' If you're asked a question that is concerned with the 'what' and you spend more time focused on the 'how,' then you might have a framework.

BRANDON: I think people will think of building an application like a recipe. If you think of it in those terms, people think of frameworks as very restrictive but I'm a big fan of Blue Apron, a sponsor of this podcast. Thank you.

They pre-select the ingredients and they give you the instructions and you know what to do, you still have to do the effort but you know if you connect these pieces together properly that you're going to wind up having a good experience and then, it gives you a lot of freedom to experiment and be creative beyond that, should you choose to. I think one of the signs that you've done a crummy job is that you're staring down, like Chris Freeman said, you actually starting to restrict your choices like, "I can't actually build you that feature because we don't have time to take on the amount of work necessary to build the support structure, to build you that feature," or if you find yourself writing a test framework.

CHRIS: Oh, yeah we did that too.

BRANDON: You know, we were real deep in this. There are developers that are like, "I really want to feel like I'm walking into a grocery store and selecting all the things necessary for my recipe," and so it really depends on what the problem actually is. If you're working at a giant megacorp and you have a two-year timeline to deliver something and their goals are not about delivering stuff on a tight turnaround, that's usually a recipe for a software failure anyway but let's say, that you're in the 5% of those types of projects that's going to succeed, that might be a good place where you can say, "What we're trying to do here is so custom and we have such a long lead time and a long leash and such a high level of internal expertise here that we should be shopping in the grocery store and we should be selecting all these things and we should be solving these problems."

Basically, when is it time to use a framework? Well, when you don't have 10 times the time you think you do, when you don't have the ability to spend 80% to 90% of your time in the first three to four months of your project, maybe six months, debugging you're glue code in between the different libraries that you're gluing together and then coming back and realizing that you've painted yourself into a corner and you have to re-architect your whole framework, then you could be so proud of this baby, 18 months to two years from now, when you actually have delivered both a framework that took about 70% of your time and an application that took 25% or 30% of your time.

CHARLES: Yeah. I think it's important to realize that people think we'll do it and we'll build it as we go but I want to call out right there, you will be spending 80% of your time and you have to be upfront about it. Of this two years, 18 months of it is going to be spent building this framework and six months of it is going to be spent actually writing the feature code and you have to be 75% of your tickets or your issues, whoever track the work, 75% of that has to be dedicated to the framework.

BRANDON: If you're going to bake in that kind of overhead purely for the satisfaction of a single or one or two developers that like inventing things, that is literally the worst possible reason you could do that. That is almost like a guaranteed recipe for failure. It has to be for some other business reason like, "We want to be the company that owns this." There has to be business value attached in making that kind of investment. If you can't justify that at the outset, then you should probably just go ahead and lean on an existing framework and join a community of people.

CHARLES: Yeah and I think one good litmus test for that is, "Is this a 'what' for which there is currently no 'how?' One of the reasons we're writing BigTest is because for the general JavaScript community, there are a number of acceptance test frameworks out there but the market is very, very limited. When we look to actually acceptance tests, our React application, this thing does not exist. Now, we had experience with something that was very like Ember specific and so, we kind of knew what the 'what' was, we experienced the 'what' but there was no 'how' for our current situation. That's like a place where you might be called upon where makes business sense to actually invest in a framework.

I'll tell you another thing too is if you have made the decision to kind of follow the beaten path on the other areas, then when a framework is called for, you have the bandwidth. You've allowed for the buffer, for the margin, for you to write in with that framework, whereas if you're already just by default, maintaining all the glue code in every single thing, then if some unique 'what' comes along, for which there is no 'how,' you're not going to have a bandwidth to tackle it.

BRANDON: Yeah. That's a real bad situation to be in.

TARAS: There's something else that I find interesting is because there's a certain point, like this two-year mark where everyone's like, "We want to fix this now." I think what is interesting what comes next which is the three years of undoing all the stuff that you made because the biggest challenge, especially in really big projects. When your projects has to borderline into platforms and a platform threshold is when you have a multiple teams working separately to write separate modules that run, maybe in a separate Git repo and maybe, packaged in separate npm package and assembled together.

Then what happens at that point, the question arises like how do you actually make this changes in this environment. Answering that question is actually really difficult. I think if you look at frameworks like Ember, Ember has made it their business to figure out exactly how to make this happen and I think they've done it really well but it's a really challenging endeavor, especially in incorporate environments where they don't have an update. You have like upgrades are like a curse. It's like a thing that you don't really want to ever do and because most quite often, they don't have the right testing habits in place to be able to support the change if necessary.

I think what a lot of times happens is that the team that made the framework in the first place, they end up trying to maintain a fort but you won't have like 10 people and they only have machetes, you know? All you can do is run around and try to chop down little twigs but at the end of day, the trees is still going to keep growing. I think that's the really challenging part of being two years into a project, where you realize that you actually need something much more comprehensive than initially thought you needed.

CHARLES: On that, assuming that you have decided that you are going to make a framework, it's a good business decision for you. Based on the criteria of this discussion, how can you assess whether it's good? Chris, you talked about needing to integrate query params with routing and asynchronous data loading and making sure all of that coordination happened and worked together easily. What's the difference between your framework just missing features kind of having holes in it that can be filled in, versus something that's not good and it's going to cost you lots of money down the road.

CHRIS: Yeah.

TARAS: One thing, if you look at what makes a good library of any kind, it tends to be like how effectively and how much words to take the address the use cases that you need. The problem is that to build a good framework, you need to understand the use cases. This is what usually happens over time. Two years in, you've actually understood the use cases and now, it's time to change and so, I think if you want to build a good framework, you actually need to understand those use cases quite early on or account for understanding use cases over time and that's a big question -- how do you figure out how to know what you don't know.

CHRIS: Yeah, I think that's exactly right. I think about what you were just saying Charles and Taras like one of the things that I think has a big impact on and what this process looks like is the completeness of vision for what's your project actually is. If you have a very, very clear idea of what the entire product you're building is going to be or, at least what the key money-making feature is going to be and you can understand the ins and outs of that, then I think that's the point where you can look at what you have and say, "Have I created a good or bad framework? Does this framework have the ability to solve this one very important thing that I have to be able to do? If the framework doesn't do it, then I need to build my own but I now know what very important features I need to front load my framework with."

I kind of think of it as imagine that you're like Jeremiah Johnson, the Reverend Jeremiah Johnson and you're going to go trekking through the woods for some unknown amount of time and you have no idea yet. You don't actually know where you're going. You don't know what you're going to see. You don't even know what's out there because you haven't done the research or whatever and you need to be prepared for anything, so you bring just a hodgepodge of stuff.

If that's you at the beginning of your company or the beginning of your product and yours is kind of like... I don't know, we got to get product market fit and that means that we may have to kind of pivot once or twice or we need to be very flexible, then I would think long and hard before you commit to writing your own framework because you don't even know what framework to build and you might as well take a broad array of tools and use what you need.

There will be times where that's frustrating and there won't be exactly the right tool for the job but 80% of the time, it's going to do just fine but if you know you have to do this one very special thing and you know that a framework is going to give you a lot of stuff that you won't need and it doesn't really excel at the one thing you do need, then don't force the framework. There may be time to build your own but just know that you need to go in with a very clear idea of what you're doing before you start building the abstractions that constitute a framework, rather than just like a constellation of libraries.

CHARLES: I have a question on that then. Going back to one of the things we were talking about like React plus Redux. Your opinion, Chris that it is not a framework, so the question is does a framework actually exist for React?

CHRIS: My guess is that many frameworks exist for React.

CHARLES: Is there a public framework?

TARAS: There is one called Fusion but it's [inaudible] what you would have imagine. It is essentially Redux and React together conventionalized. They addressed a bunch of concerns around service rendering and such but it does exist.

CHRIS: How about Next? Next.js?

TARAS: I'm not familiar with its features from a single page application perspective.

CHARLES: I think it does have a router. It does bundle with Redux and this is one of the things that when you first started using Redux, it's like, "How do I even get my store to my components?" Yes, I can connect them but there's actually a lot of stuff that you have to do. First, you have to say, "I'm going to put my reducers here and then when I create my store, I'm going to fold all my reducers. If I've got a whole bunch of reducers in my application, I've got to fold them all together. I've got to pass them off to the store. When I create the store, I have to inject the middleware and then, everybody else just imports my store and then, I have to put in a provider and then, I can connect my components."

That's actually a lot of stuff that you have to do and I think that, for example, Fusion just says, "Put your reducers here and we'll take care of all that process," and so it makes that decision for you, right? It says, "For state management, you're going to use Redux. For your reducers, they're going to go here. For your actions, they're going to go here." I don't know exactly how it's laid out but I remember reading the ReadMe, it was basically layering conventions over that. That's definitely going into framework territory but that's the only one that I know of, which is really, really odd.

TARAS: There's something interesting that's happening also and this goes to what Brandon was saying earlier is that choosing the best in class, there's this 10 things but then, what if one of the best in class stops being the best in class. The fact that the creators of Redux was essentially saying that we needed to basically provide a way to do Flux that was better than 10 different options that were available, so here's Redux. We've created Redux but we don't really think it's ultimately the solution. We need to have something else in React that provides a foundation for us to be able to deliver a better state management than what Redux is, so what happens when one of the best in class is no longer the best in class? The bridge is already standing. There's people walking across the bridge already. How do you replace one of the chains in it?

CHRIS: Over the course of six months while you figure out the differences in API between Flux and Redux and all the custom route transition data loading stuff you did with your Ajax library in your state management software that you put in a case statement inside there that you now have to change over. It's easy. It's no big deal. Don't worry about it.

BRANDON: Just a simple matter of programming.

TARAS: At least 25 years of collective frontend development experience is laughing like hyenas about the simplicity of building a --

BRANDON: Yeah, I'm actually looking at some of the old code that Chris wrote for trying to glue together, Redux Saga. I've been out of the game long enough to not know whether that's been superseded by some new or best in class piece of technology and even then, it was really challenging. This is true for frameworks too, is they don't really optimize for best in class. They optimize, hopefully for best fit for purpose but the world has moved on since Ember launched obviously. A lot of things have changed and it's, at least as difficult to try to keep that up to date with evolving trends and technologies and updates for a core team at a framework level as it is for you, as an engineer on the team. The difference is you get to outsource that work to a core team for a framework.

Ember has not done a fantastic job in keeping up with. They've done a good job and they've tried their best but if there were more people working on it or if there was more effort applied to it or if it was a higher priority, you would see Ember being a more up-to-date framework using more modern tools. As a framework author, if you stay too close to the bleeding edge, all you're going to do is change out your build system. You're going to replace a Broccoli with webpack, with Rollup, whatever's after that. What's new in Packer?

CHRIS: Parcel?

CHARLES: Parcel.

BRANDON: Parcel. You should immediately go build your framework with that and have fun. I am excited by the new and interesting stuff that's happening in these ecosystems and I think it's important not to get lulled into the siren song if your goal is to actually ship a piece of software on a timetable or a budget.

TARAS: One thing, if it's a red flag, if you think this is easy, if you think your decisions can be made in this isolation without talking to somebody else and actually kind of flashing it out, then you're probably doing something wrong because a lot of these things are not trivial. There's a lot of thought, there's a lot of considerations used to go into decisions that you make, especially when you're creating something that is going to be used by more than a few people. I think that's really one of those things where it's hard to know what you don't know but if you think you know and you haven't done this before, you haven't done this a few times before, you're probably missing some pieces.

BRANDON: Yeah, I agree with that.

CHRIS: I think one of the things that's really enticing about React and Taras, you just hit on it but I've never felt as clever as when I was writing a React app. If I'm clever, I mean, clever in the same way that I felt really clever when I wrote some unbelievably convoluted Scala one-liner that six months later, neither me nor anyone else could decipher what it meant but at that time, I felt like a god of programming. That's how it felt like, "Well, a lot of the React stuff is addicting." It felt so much fun. It was so much fun until I really had to do something and it mattered for my job and there was a deadline and people were depending on me and I've realized that the clever thing I had done a month later was not the right clever thing but I can see how, if you're like what Taras was saying, where you are at the point where these decisions are easy. These decisions make sense. We're going to be fine and you haven't done it enough to kind of like know where all of the pitfalls are. That cleverness that you feel is fantastic and I can see why it takes two years before you look back and if the cleverness was finally worn off and then, you're just mortified at what you've done.

CHARLES: Pride cometh before the fall.

CHRIS: Yeah.

BRANDON: It's like being a dungeon master in Dungeons and Dragons, where you're like, "Oh, look at this fiendish world." All right, cool. Now, you actually live there though. I have to move into an apartment on Mordor.

TARAS: You know what's the funny flipside to that is that coming from Ember world where it's so normal to leverage the work of other clever people, like really smart people who've invested a lot of time to solve a particular problem, is that there's no stronger sense of being dumb than having to write it from scratch in React. That first feeling of like, "I've actually never had to implement this from scratch," and I feel like a bunch of applications before but because I've leaned on for accessibility, I've leaned on something that someone else has done and it worked really well for me and it was perfect. But now, I need to implement autocomplete from scratch in React and I have no support. I'm basically learning as I'm going on this and it's that sense of discomfort that you get from having to do it from scratch and then, comes the euphoria of having to figure it out. But if you figured it out, you figured it out in the last month. You've written it for the first time in the last month and you now understand what all the things that the Ember implementation does for you. It's an interesting psychology of doing this --

CHARLES: Yeah, it gives you a lot of perspective but you have to ask as a business owner, who may or may not be technical and this is the hardest thing for technical people who are business owners is to be able to not see things through a tactical lens. Is what you really want to pay for is to basically give your programmers this kind of a-ha moment of their own shortcomings because that what you want to be buying.

BRANDON: Yeah, you want to maximize leverage. Your goal with technology is to maximize leverage. It's like being hired as a chef and you walk in and then you're like, "I'm a terrific chef. I worked in these fancy kitchens in New York and I'm known as a great chef," and they're like, "Okay, cool. Here's some flint and steel and a spear."

CHARLES: Go hunt.

BRANDON: You're like, "Wait, what?" Yeah, yeah, yeah. Show me what you can do.

TARAS: We had a conversation in one of the previous podcast with Michael Jackson and we asked him, "What is the one thing you wish like React community would do more of?" and he's like, "I really wish React community have more conventions." All of this is to kind of say as like, there is a place for frameworks in React world. There's a very strong place for it. The question is how and what it said and how do you actually build it and when do you --?

BRANDON: So we need a framework for making framework.

TARAS: Getting really meta here.

BRANDON: I totally agree with that and that's a great observation and that was actually the point of my talk as well, which is if I could convince people just to use Ember and improve Ember, that would be great because I think it's a really great starting point. But the React community is much larger because it had such a great adoption story. The adoption of Ember was very difficult and the adoption of React was very easy and it expanded to include the scope of full end to end applications in terms of what people thought the problem spaces they were thinking of with React.

Ember was built to solve that but it was hard to get into. React was really easy to get into but it's actually hard to build applications with. I would love to see a dedicated subset of the React community, except the idea of shared solutions and the philosophies that made Ember into sort of a powerhouse of value delivery but built out of tools that satisfy the React community and a little more modular and a little more available for people to customize and built in that ecosystem.

I'd really love to see that that included all of the main components of what we accept as, "This is an application framework. It handles testing. It handles accessibility. It handles data loading," and it doesn't have to be best in class in every scenario but it does have to be a reasonable bridge across that chasm and have a group of people look at this the same way. I would love to see a collective subset of the React community dedicate themselves to this idea. I don't know if that's too culturally opposed or even orthogonal to what the value system inside the React community. I haven't been able to fish that out but I would really love to see that emerge.

this is something I would love to push for and I'd love to see other people jump in and push for as like, "What if 20 of us got together and decided we're all building our applications in similar ways, instead of one person saying, 'I'm going to use --'" Even create React app is kind of a Band-Aid on that, it isn't useful past a certain stage of life. I would love to see a group of people, though, get together that are sort of like-minded like that, the Michael Jacksons and maybe even Dan Abramov or a group of people that shared that set of values or came into React from the Ember community.

That’s actually one piece of advice I would give to people. You said, "How do you convince this engineer that they've built a bad framework?" Use a decent one. That's the biggest guide. Use a decent one. Build something in Ember and ship it to production and go, "Oh, I get it." If you've used a good framework, you can't go back to rolling a crappy one. Your standards have been ratcheted up.

CHRIS: I wholeheartedly agree that you should try something else and Ember is a great option but I don't want to dismiss just like, "React is cool as hell," and there's a lot of stuff in React that's really, really awesome and things that I wish that will show up in Ember and they are starting to show up in Ember but they're taking a while and it'll be nice in there but who knows when that will be but I would encourage even more so is both sides, like Ember folks who are listening to this podcast, if you have never messed around with React because you feel some kind of tribal affiliation that you can't betray, please set that aside and go do something in React because you will learn a lot about why Ember does what it does and you will see a lot of really interesting things that will probably jostle some ideas loose in your brain.

The same thing goes for React developers. You, 100% should spend a weekend building something in Ember and nothing about that means that you have to switch or it's going to change the path that you're going on at work but I guarantee you, you will go back to your React application with some new and fair useful perspective that you didn't have before and that's okay. That's great. There's no identity crisis that will come about as a result of that.

CHARLES: That is a fantastic advice, Chris. It will only stretch you.

CHRIS: Yeah.

BRANDON: I think developers have been sold this idea of a competitive landscape by authors of these frameworks because it helps sell the framework. You can build and strengthen a community by leaning into the tribalism that can surround the usage of a tool. The older I've gotten as a person who was deeply tribalistic about Ruby on Rails when I got into it and Ember when I got into it, because I love tribes, I think tribes are awesome and it's a way to make friends but when you really lean into that, the costs are too high and experimenting with other technologies and noticing flaws in your own technology is not only not a betrayal, it's actually critical to your growth as a developer. The more people that do that, like Chris was saying, the better both of those ecosystems will get.

CHARLES: Absolutely because having spent as much time in React as I have, I really appreciate the precious things about Ember. It will make you appreciate the things that you hold dear. It will make you appreciate the really, really, really special things about the tool that you're using and at the same time, it will highlight the weaknesses which you can immediately use to feedback and make your tool better. It really is a win-win situation.

TARAS: I just want to do a little plug before we close up. I think the feels of working with Ember is actually gone into microstates and we're still getting our things together to make microstates look accessible and usable by everyone but that feeling of pleasure that you get from working with Ember and just things just being there for you, like we really want to reproduce that and make that available in React community and the stuff that we do in microstates is actually really designed for that.

CHRIS: Yeah, I see that in BigTest too as well. That's definitely another place where it's like, "These people definitely used to spend time in Ember and they're now in React-land." It's cool to see that stuff getting ported over.

CHARLES: Absolutely because it fundamentally changes your taste. Working with an application that doesn't have like a bolted on testing framework is like eating water soup. You just can't enjoy your life. It really is flavored everything that we do. On that note, we can go ahead and wrap up. There actually is some pretty exciting news. We're actually going to be launching a BigTest launcher. Up until this point, you kind of had to roll your own using BigTest for your assertions but using something like Karma to actually launch the browsers and we're actually launching our own launcher. I guess we've written our own launcher and we're going to be pushing it to NDM, not to overload the word launch.

You can look for that in the next couple of weeks. There's going to be a CLI that ships with BigTest to help you do even more set up, to make it so that you can just drop BigTest right into your application, whether it's jQuery, React, Ember, you name it. That should be really, really fun. Be looking for that and with that, if anybody has any other remarks...

BRANDON: If people are coming through RubyConf this year, I'll be there talking about management stuff. That's my only near-future conference stuff coming up. Hope to see some of the more Ruby-flavored folks out there.

CHARLES: All right-y. Definitely, go to every single talk that Brandon ever gives. You won't regret it. I can base that on very dear personal experience. You won't be disappointed. You know, not to put the pressure on or anything like that but you could never put any more pressure on Brandon than he puts on himself. With that, we will say good bye. Bye Chris, bye Brandon. Thank you so much. This is a great conversation. It certainly clarified a lot in my mind --

TARAS: Yes, same here.

CHARLES: -- About these problems. With that, we will say goodbye. Thank you for listening The Frontside Podcast. Please get in touch with us at @TheFrontside on Twitter or contact at on email. We do a range of custom services from full stack project development to JavaScript mentoring, to as you go JavaScript help desks kind of stuff. If you need to reach out to an expert, please get in touch. Our podcast as always is produced by the inimitable, Mandy Moore. Thank you very much and we'll see you all next time.

Aug 23 2018



Rank #16: 117: The Frontside Podcast 2019 Reboot Preview

Podcast cover
Read more

We're rebooting The Frontside podcast with a focus on JavaScript platforms. We'll zero-in on what it takes to build, maintain and grow web applications using popular JavaScript frameworks and tools. Join us for deep architectural conversations, interviews with fascinating speakers and stories from the the trenches of building large platforms.

Dec 27 2018



Rank #17: Frontend/Backend Team Collaboration with Sam Joseph

Podcast cover
Read more

Sam joins the panelists to talk about frontend and backend team collaboration.


Sam Joseph is a CoFounder of AgileVentures, a charity that helps groups of volunteers gather online to develop open source solutions for other charities all around the world. Sam’s been mucking about with computers since the early 80s and followed the traditional education system through to a PhD in Neural Nets. Next he went all industry, researching mobile agents at Toshiba in Japan, going freelance and then swung back to academia to research peer to peer system and collaborative systems. He now spends the majority of his time trying to make AgileVentures a sustainable charity enterprise, with occasional moonlighting as a contract programmer. Check out his blog at

Please join us in these conversations! If you or someone you know would be a perfect guest, please get in touch with us at Our goal is to get people thinking on the platform level which includes tooling, internalization, state management, routing, upgrade, and the data layer.

This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC.


CHARLES: Welcome to The Frontside Podcast, the place where we talk about user interfaces and everything that you need to know to build it right. My name is Charles Lowell, a developer here at the Frontside. With today also is TARAS: Mankovski.

TARAS:: Hello, hello.

CHARLES: Hey, TARAS:. Today we're going to be continuing our theme when we think about UI platforms and web platforms, continuing the theme of collaboration and with us to talk about this is Sam Joseph. Welcome, Sam.

SAM: Hi, thanks for having me.

CHARLES: We've already talked a great deal about how the way in which your team collaborates and the communication that happens between your team and between the different pieces of software, your system, form one of the pillars of the platform that you can't just take lightly. You need to actually be intentful about that. I was thinking we could kind of start today's discussion, kind of talking about some of those collaborations.

One that we've probably all encountered, which is usually teams will be split into people who are focused on frontend, people who are focused on backend systems, kind of the services that make sure that all of the nodes that are running on our laptops and our desktops and stuff are running smoothly and error-free and obviously, those two groups of people can sometimes arrive with different sets of priorities and how do we resolve those priorities to make sure that that communication flows freely.

TARAS:: What's interesting about these frontend and the backend teams is that our users are not seeing that separation. They only see one thing. They only touch one thing. They actually see as one group but there's tends of be this kind of split between the frontend and the backend. It's kind of interesting that how the user get into this.

SAM: Yeah. Obviously in some teams, there's a very clear cut distinction between people at the backend and working with the components that are serving JSON over the API and there are some people who are very, very focused on the frontend and drilling CSS and a number of bits and pieces or even just staying explicitly on the design or UX design and there's a mythical full stack developer who is up and down the platform. It doesn't run exactly in parallel but there is this key thing which is almost how much sympathy or empathy can you have for another person who is not you, trying to use something that you set up.

If there was a direct parallel, you'd say, "Obviously, all people who will be working on the frontend are more of that sort of person and perhaps, the people on the backend are not so much that sort of person," but actually, I think you can have people who are doing backend stuff and they're designing API is very, very thoughtfully or the kind of people that consumes those APIs and sometimes, you can have people who are very, very focused on the design and the aesthetics when not necessarily so plugged into how will someone else use this, how will it fits into their lifestyle, which might be very different from my own, so that's maybe another axis, if you know what I mean apart from this sort of pure technical [inaudible]. Does that makes any sense?

TARAS:: Yeah. What's interesting is that everyone is trying to do a great job. Everyone is setting out to do something really good. What people's way of expressing good might be different, so if someone could be really focused on the quality of their code like they want to do their version of doing a really, really good job is doing the best code they could write. Sometimes that doesn't necessarily equate to the best user experience. I think everyone that I've met -- engineers who are writing code, almost everyone that I know is trying to do a really good job. If everyone is doing a good job, it doesn't necessarily always equate to the best user experience.

CHARLES: I think we had a reference that everyone wants to make sure that their system is of the highest quality possible but quality in of itself is not an absolute value. It's relative. In other words, a good definition of quality is how well a system is fit to a purpose. If it fits very well to that purpose, then we say it's of high quality but if it fits very poorly to a particular purpose, then we say, "This is a system of low quality," but what constitutes something of high quality is relative to the purpose. The question is, what is the purpose of writing the frontend system? What is the purpose of writing the backend system? So it seems to me you're going to have a lot of dissonance if the purpose is divergent but if they both share the same purpose, then that is kind of standard quality on both sides. Does that make sense?

SAM: That makes sense and what even more makes it tricky is that actually, purposes can evolve over time and so the thing with the frontend that needed to do with the business today is different tomorrow and the day after. The trick then is sort of the frontend and the backend, as people try to do a great their job, there's this question of how far ahead are we looking so you can talk about important things like sort of asking close modification about [inaudible] extension and there's a [inaudible] of different coding heuristics as best practice that say, you should kind of go in this direction.

Sometimes, that will be the hill they want to die on. It's like, "This code needs to be this way because of this thing," and the idea is that it's sort of future-proofing them but I think the messy reality is that sometimes, the thing that you put in place to future-proof, the whole system gets canned. In two weeks, the business changes and what have you, so the extra effort that you are pushing in on one day to protect yourself against changes in the future actually gets lost and perhaps, if only you'd be able to deliver a shortcut pack, this one feature that that will got the next line of funding in, either one advocates cutting corners but... you know what I mean? Like --?

CHARLES: Yeah, absolutely. I just wanted to chime in and vehemently agree with you that the purpose can change radically, especially if you're in an evolved environment. What constitutes the good code or the good quality solution can vary just as radically because it needs to fit that purpose.

TARAS:: When we talk about frontend and the backend, it seems there's this relationship, which is kind of positional like there's the frontend and then there's the backend. One is in sequence from front to back. It's the direction with the frontend. It's closer maybe to the user where the backend is not. But I think in practice, it's probably more like the left and the right hand where when you have to do two things together, you actually need to do two things to coordinate together.

What you describe about and this is I think where taking shortcuts sometimes can actually be a good thing is that if you say, "I'm going to spend the next few weeks on a backend and doing this specific thing," and then you find out that 10 days into the iteration that it doesn't fit, the better approach to synchronize would be to stop the action and realign. But if you persevere, then you might overstep and you actually be out of sync. It makes me think that the art of creating cohesive organizations from development perspective is to create context where the two kind of work in synergy together. I think that's where a good tooling that allows its synergy to exist. I think that's a lot of the work of actually creating systems where the user experience is kind of cohesive and integrated.

CHARLES: Actually, there was something that you just mentioned in there but it's actually a little nugget that I'm curious to explore and that is if you're 10 days in to like a 14-day piece of work and you realize that it isn't right and it doesn't fit with the whole, right action is to throw it away. I feel like software organizations and this might be a little bit off topic but it's something that really is interesting to me, so please indulge me. I feel like we see the product being the kind of the code output, even in Agile environments and there is an aversion to throwing away code that has been written.

There's the, I would say, incentive is to go ahead and persevere because developer time is so expensive. These are days out of people lives, so they've already invested 10 days. Why not just have four more days just so you have it. When in fact, you actually have more if you just throw that work in the trash because it's an obstruction that's not needed. It's a piece of weight. It's actually something that you now are going to own and it's actually going to be cheaper in the long run and it can be more beneficial to your organization to not own it.

Do you all see that happen kind of play out where people become attached to software that they've invested and will make the decision to hold on to it? Say, we'll spend two more days to complete it, even though it's the wrong thing, like identifying which things need to be thrown away? I feel like we don't actually do that very aggressively -- to say, "You know what? We need to not complete this work."

SAM: I think that is a really tricky one because I think whatever people might say, when you spend time working on something, you become emotionally attached to it. I would say strongly that how logical or rational or whatever sort of a person you are, my experience is being that people working on things want to see them used.

I think in a situation with version control where you can keep things on a branch, they can be useful explorations, things don't have to be thrown away in their entirety. Our charity is doing work for the National Health Service in the UK where there's a lot of employees in Europe and I've noticed the user interface that we're supplying them and I was suggesting some sort of minor tweaks and one of the developers has sort of run with the entire, big, advanced search feature that partially solves the problem but brings in a lot of other bits and pieces. He does some good work there. It's a great work but I think he kind of ran further than I was expecting down that line and I think we have now found a much simpler solution that rather than bringing an entire cabinet, it's a little shading off the side of the existing one.

But I think that doesn't have to be a loss and I was reassuring him that the work was valuable and that there is interesting learnings there and potentially, we might use it in the future version of the project and now of course, the way that stuff is moving on, just how it's going to branch, it doesn't mean you can then sort of magically lose some of the work.

In that case of doing this 10 days out of 14 and so on, the real question is can you get any value from switching somebody that fast? If they spent 10 days in and they realized they don't need that thing, it's like can you switch them quickly onto something else where they'll do four days or might they as well, just finish up there and leave that on a branch. That's a pull request that gets closed and it's there to go back to. That's kind of depends team by team about how quickly you can repurpose people missed rigs, if you know what I mean.

CHARLES: I absolutely agree but the key thing is leaving it on a branch and not integrating it into production, like not actually deploying it because I feel like when we see a feature, it's like we've got to get this thing done and it's done and we're just going to get it in versus now that we've learned how to do this, let's put that on a branch and let's rewrite it and let's take a different approach, rather than just being married to the idea that we're going to get it right the first time or that now is the time for this feature because we understand the complexity of what it actually takes. It is a tricky question. I'm wondering if our processes don't include enough implicit experimentation. We talked a little bit about this on a prior podcast that if they don't include some incentive to not deploy features just because you have them.

TARAS:: I think from a business perspective, there's not a lot of model to evaluate a certain thing. We don't have really any effective way of evaluating learning. You can measure code by the numbers of lines of code that somebody wrote and how much of code was shipped but you can't really evaluate how much was learned and how much was persisted.

I think a lot of this work around supporting effective collaboration is in building a cumulative systems of knowledge like why is a good Git history useful is because it has a built in mechanism for understanding history. It gives you a way to return back to time in your project and understand the context of that specific change and I think this is something that really good teams do this really well. They will respect this because when it's necessary, it is valuable to have this. When you don't have it and you are a year into the project and something happened and then, you are using the only thing you have, which is your troubleshooting skills or you are trying to figure something, as supposed to going back and relying on that history, on that knowledge that's built into the system, what I'm trying to get to is there is an element that is inherent to our development process, which is we don't have a way to quantify it. We have no way to really evaluate it. I think this is the problem that makes it difficult to throw away work because you can measure the amount of time they'll spend but you can't measure the amount of learning that was acquired.

CHARLES: Right. Thatís true.

SAM: I think if you have a positive team environment, if you have your team that is stable in there -- your contacts are coming in, the money is there, everybody is there and you've got the team, you don't necessarily be able to measure the learning because the output of the team will be good. They're kind of doing that in the background but I think individual comments are not going to want to pay for learning experience. It's certainly not at the rate of software developer's cost.

Although, the throwing-aways, if you're familiar with the [inaudible] book, which I think is a [inaudible] is the author, you know, build one, to throw away, you will anyway. We have a frontend mob that we run weekly doing frontend stuff and CSS and so on and we've done like it's a mockup for the client and there's this question about in my [inaudible] and so Iím saying to other developers there, "Let's not get too attached to this. We may need to throw it away and it will be a great learning to sort of restart on that." The [inaudible] to look quite nicely and the client might get attached to it. They want to ship it and I'm like, "Well, actually there's a lot of other stuff that needs to happen," and so, it's a minefield. It really, really is.

TARAS:: I think some of the business relationships that we have to this kind of client consulting company relationship, that relationship might not always create the fit to purpose team for specific challenge. You can have a company that has a lot of employees but their team and their team dynamics might not be fit to purpose to the problem they're trying to solve. If you're building a platform over a long time, you want to be creating that space where that learning gets accumulated over time. It doesn't matter what necessarily the relationship is between the companies that are participating in this process. I think what matter is what are you producing as a result.

If you're working together with people from different companies and they're working together and they're building this kind of an environment where you can collaboratively build things together and then people learning from the output and that knowledge is being carried over and people are being able to stack their knowledge continuously over time, if you're creating that environment and you're building a large platform for example, then you are creating a build to purpose kind of technology team to fit what you're looking to accomplish and that'll include consulting companies. I think those team, they're kind of secondary but I think it's just [inaudible] to that. It's like building a quality development organization to fit the purpose of building whatever it is that you're trying to build. If you're building something small, you might have a small team that'll able to build that effectively. If you have something big, you could have a big team that is building that effectively but building that team in a way that is appropriate to what you're trying to accomplish, I think that's the real challenge that company struggles to do.

CHARLES: Yeah. In the context of these real teams, I guess what can you put in place given that you have backend teams, frontend teams and each one of these needs to be specialized. This is kind of the power of the way that people work is that we're allowed to specialize and there's power in specialization. You can have someone who can be super focused on making sure that you have these high throughput backend systems that are resilient and fault tolerant and all these wonderful things, so that they don't necessarily have to have the entire context of the system that they're working on inside their head at a given time and the same thing someone working on CSS or working on a frontend system architecture, which has grown to be a very complex problem domain in its own right.

But these teams can be working in a context with a purpose is whip-lashing around and changing quite drastically and so, how do you then keep that in sync? Because we've identified purpose as being actually something that's quite a dynamic value. How do you keep these teams keyed in and focused and so, that they're kind of locked in on that similar purpose of they're going to be adapting the systems for work that they're responsible for and specialties that they're responsible for to match that?

SAM: It's a good question and I have my own bias view there --

CHARLES: I would love to hear it.

SAM: I can't bear working on things where I don't understand in great detail how that end user has experienced or what is the effect overall that it's trying to be achieved. You know, I've been working in boards between the industry and the charity for like 30 years and I know people are commenting like, "You were the person who wants to understand everything."

I think there were some people who are maybe quite satisfied who get ticket off the general board or what have you and work on that thing and if the API specs have filled in, so that's it. Go home and they weren't losing a sleep over it. But I think if youíre going to be dealing with these changes and sympathetic that the changes is coming down the path, I think you need to have some degree of empathy with the people who are driving the changes. Do you know what I mean?

CHARLES: Oh, absolutely yeah.

SAM: You know, as we've mentioned already, I think people get attached to what they build and I don't think you can do anything about that. They will get attached to what they build.

CHARLES: Yeah, we've all experienced it. It's so true. It's impossible to [inaudible].

SAM: Yeah. We can try and target it but it's sort of part of our nature. I think there are sort of the tools of the design sprint, of the design jam, of these sorts of things where if you can build to some level is obviously that it can't be shipped but can actually tease out the needs of the user, the designs sprint, the Google team, they have an example with kind of like this robot for hotels where it's like the whole thing is they can have robots that can deliver toothpaste to your door if you run out of toothpaste. In this design, obviously, that would be a huge undertaking to make that as a sort of our production system but they used like a remote control of a robot to simulate all of the key touch points when the client of that hotel, will actually interacts with that robot.

I think the same is true when you're building these systems if you can, again going to touch back on we don't fit a code in that way that I think an ever better thing is not be building the code in the first place and to build an almost a non-code system and then, maybe some of the backend are not going to be interested in the results of what people have learned through this kind of user experience trial before they [inaudible] forever but I think it's seeing other people try to use the end system that puts you in place where you can be empathetic.

I argue for the bias point of view that I think people on the backend of Netflix, trying to optimizing the streams in that or the other, they need to spend some time watching Netflix or at least watching the comedy of Netflix in order to empathize of how their work relates to the end experience and then, when those end experience needs changed, it's important for them to make change on the backend. Do you know what I mean?

CHARLES: Right, exactly. They have to watch through that kind of glass window where they can actually help the person. They can't give them any information. The only levers of control they have is through their own work, making the thing changes that they need to make on the backend, so that one of those users is going to have a good user experience.

This idea reminds me of something which I believe is the case at Heroku where they rotate everybody in the company through pager duty, which I think is kind of a brilliant idea where the entire team is responsible for providing technical support to the end users. When a problem arises, you get to understand what it's like to be someone who's trying to use the system. You get to exposed to the satisfaction, whether an issue was resolved or when it's working correctly or your pager is quiet for your entire shift but you can also get exposed to the frustration that you're engendering in the users if something doesn't go quite according to plan.

SAM: Yeah. I'm not [inaudible].

TARAS:: There is movement in this direction because there is actually a term that has been floating around. It's like a product engineer. It's someone who thinks about the product. These kind of people tend to have the highest value in Silicon Valley as someone who thinks about the product as the outcomes supposed to their code as the outcome. Even in the Agile space, there seems to be movement in that direction because I think one of the challenges, like to do that, you have to understand how you fit into the bigger picture. I could see it being really difficult. Imagine if you're working at a bank or something and being pager duty at a bank would be impossible, simply because their organization is either too big or too sensitive.

The way that their company is dealing with that is they have these group of people where you have a product manager working closely with the frontend engineer and the backend engineer so there's this exchange that is happening where people get to understand the consequences of their actions a little bit more. They understand how things fit together. There is definitely a movement happening in that direction that I think just the more, the better because one of the big differences now is the things that we make are very palatable to the users and the quality of the user experience that users are now expecting is much higher than they were in the past. I think the world is changing.

CHARLES: Yeah. We mentioned this when we were talking before the show but going to the University of Michigan as I did, I was in school with a bunch of mechanical engineers. Their goal was to go work for auto companies: Chevrolet and Ford and everything like that but their mindset was very much, I think the product engineering mindset. All of them loved cars and wanted to be part of building the coolest, most comfortable, most responsive cars. For whatever definition of a good car -- there are a lot of them -- they wanted to design good cars but they were into cars and they were into the experience of driving a car, so what's the equivalent then of that product engineer in software?

I think that every conversation that I had with any of the mechanical engineers who were going into the auto industry, I'm sure there are some of them that were out there but it wasn't about carburetors or whatever. They really wanted to just get into the building of cars. In some aspects, I'm sure they all integrated in some way or another but it was a group that was very focused on that outcome.

SAM: In the UK, I'm hearing this term, 'service designer' a lot that's coming up. Are saying that, Charles, you get the feeling that even getting into software, I'm not so excited about using their own? Like the car, I want this amazing car and then I can drive the car and I'll experience the car --?

CHARLES: Right and other people will experience the car that I've helped design.

SAM: Right and in some way, in software, it's almost like the software itself there's this kind of mathematical beauty of its own and it's like always been more important than the other software heads around me like the software that I wrote. I mean, the user? At the conference and all the software guys love it, that's the key objective, isn't it? Yeah.

I work with a lot of learning developers who are rightly focused on wanting to improve their skills and wanting to level up in particular tech stacks that are the ones that will lead to jobs and the future and financial stability and so on but I kind of wish I could inculcate in them this desire that the user experience was the higher goal than which bit of code does this or the other.

Maybe, I'm being unfair to them when I say that. Coding is hard. There's a lot strange concepts to grasp than sort of grappling with those concepts -- how does this work or why does this work or should I use this function or should I use this method or what have you. I don't know. I think [inaudible] bit a wall when I'm sort of saying like, "Let's think about it through the user perspective, what does the user needs here." It feels like they want the safer answer of what's the correct solution here, how should this be refactored because you need a skinny controller or a fat model or whatever happens to be. I don't know if that's --

CHARLES: Right, like what's going to make my life easier, in a sense of if I'm going to be maintaining this code and it's important. It's very important. You want to be happy in your job, you want to be happy in your work and so, you want to have the skinny control or the fat model because it's going to lower the risk of pain in your future, supposedly. I definitely understand but that can't be the only incentive. I think it's what I'm hearing.

The thought just occurred to me, I actually don't know that much about game development. I know the game industry is certainly has got its problems and I don't know much about the development culture inside the game industry. I do wonder what it's like because it does seem to be somewhat analogous to something like the car industry, where if you're a developer in the game industry, you're probably extremely focused on the user experience. You just have to be. It's so incredibly saturated and competitive for just eyeballs and thumb on controllers. Like I said, I don't really know anything about the game industry when it comes to development but I'm wondering if there's an analogy there.

SAM: Yeah. It sounds strong to me and as much of my cousin who works in the game industry and I sort of taught game programming and work through a lot of it. The game industry has got these sort of user testing experience baked in and it kind of like repeat, repeat, repeat, repeat. There's this sort of constant cycle of doing that and in the somewhat wider software industry, in a certain extent, pay lip service to that.

CHARLES: The game industry, they live and die by that. The code lives and dies by how it actually plays with real users.

SAM: Yes and it feels like in the general world, there's a lot more user interfaces that they just sort of struggle on whatever market dynamics people need to use, these existing vested interest, these banks, these supermarkets and what have you. I guess the market is too big, almost. It's not covered enough but do we really want our industry to be so cutthroat? I don't know.

CHARLES: Yeah. We've kind of seen an example of a couple of industries: the car industry, the game industry which is kind of adjacent to where most software development happens but they have this concept of exhaustive user testing, kind of the pager duty if you will, where you get to experience that. So how do we, on our team and when I say our team, I mean anyone who happens to be listening, what's the equivalent of pager duty for the applications that we write? How can we plug ourselves into that cycle of user-ship so we can actually experience it in a real and repeatable way.

SAM: In the work that we're doing with the NHS, they have a similar program. There's a lot of people who are working purely death by desk jobs but they do have a framework for us to go and observe in the hospitals and emergency rooms and so on. I guess the 'how can we achieve that outside of those clients who have those framework in place,' it seems like maybe we need a version of the cycle where a different person gets to be the product owner and tries to represent what the users are experience each week.

I think almost though, it seems like we need more of that thing you mentioned, Charles which is like kind of being behind the one-way silvered mirror as some sort of framework that connects the loop between some of the individual developers are doing and their experience of how the users are seeing things. I think that's going to be difficult to introduce. Just to sort of back up a little bit with them, I see this kind of idea of Agile, which says, "Let's be using the software which is the thing that's kind of changing and evolving unless you already deployed and you are in the maintenance mode from the beginning and you're getting that thing out there so you have your one-week or two-week or three-week cycles where you keep on having touch points," and I think that's better than touching once every two years.

As malleable as modern software potentially is, it's too sticky. It's like you were saying Charles before with that deploying or whatever, these are all gyros and so, you kind of need a really good mechanism for mocking out interfaces and having users experience and there's a couple of [inaudible], vision and there's something else that's sophisticated systems on the UX space where you can put together sort of a simulation of your interface relatively cheaply and you can run these things and then have sort of video capture of the users interacting with the system.

I think the difficult part that we have in the software industry is we are in this thing, where there's not enough people wanting to be software developers, partly with I guess the cars and the games, is there's so many people want to be game designers that the industry can kind of set the terms but we're in this inverse situation here with software developers where software developers are so much in demand, they can kind of say, "Don't put too much pressure on me. I'll kind of like, I'll go off to different company."

You know, we kind of have to like herd the cats, as they say into allowing these high powered software developers to go in the direction as they want to go in and so, it may be difficult to impose something like that, where you're getting software developers to really experience the end user's pain.

I guess what one has to do is somehow, create a narrative to sell the excitement of the end user experience and the beautiful end user experience to software developers such that they're fully out of themselves and say, "Yes, I want to see how the users are using my software." Do you know what I mean?


TARAS:: Yeah. Because a lot of company had this process where there'll be a product manager, there'll be a designer, they'll design through mock ups and they'll just hand it over to developers to build. There could be some backend, some frontend. I think if you're doing that, there is no emotional engagement between the creators of the actual implementation and the people who are going to be using that.

One way to do that is to try to add more of this actual 'however you do it.' You know, introduce more of the personal experience of the users to go along with the actual mock ups so that people understand like, there's actually be a person on the other end that are going to experience this and create some kind of emotional engagement between these two end. How you do that, I think that's a big question but I think if the organization is simply just throwing designs over to development, that's where the part of the problem is and trying to --

CHARLES: Well, actually, that's a fantastic point because ultimately, we've talked about emotional engagement and attachment to the software being a liability but the reason it exists and the reason it's intrinsic to the way we do things is that's how things get built. We get emotional attachment to it. It's the impetus. It's the driving force. It's literally the emotive force causes us to go forth and do a thing. It's why we're going to do it as a good job.

Like you said TARAS:, if you just kind of throwing your tickets over the wall, there is no emotional engagement and so people will look for it wherever they can find it. In the absence of an emotional engagement, they will create their own which is good quality software that's 'clean' code because people need to find that meaning and purpose in their work. Maybe the answer is trying to really help them connect that emotional experience back to that purpose of the user experience, so that there is no vacuum to fill with kind of synthetic purpose, if you will.

SAM: That's a great point. The charity in AgileVentures that I run, when we get things right, that's the thing that happens in that. We go for transparency at open source. We have these regular cycles where the charity client is using the software in a Hangout with us, with the developers who work on these things and the developers whether they're in a Hangout Live, whether they're watching the video a week later, they see the charity end user struggle with the feature that volunteer developers have been working on and they make that attachments. It's more than just 'I want to learn and level up in this thing.' It's like 'I want to make this feature work for this end user' and we're very lucky to have these charities who allow us to do that level of transparency.

The difficulty often comes that I would see in our paid projects where I would love to be recording the key stakeholders using the system but for whatever political reason, you can't always get that. I think that process of actually connecting the developer with the person who using it and doing that reliably, so that they can have that empathy and then get that emotional connection. It's just tricky in the real world.

CHARLES: It's very hard. One thing that we've deployed on past projects, which I think has worked fairly well is kind of putting a moratorium on product owners writing stories or writing tickets and actually having the developers collaborate with the product owners to write the tickets. In other words, instead of kind of catching a ticket that's thrown over the wall, really making sure that they understand what is the context under which this thing is being developed and then almost as in a code review sense, having the product owner saying, "Actually, the reason we're doing it is this," and having a review process where the developer is actually creating the story in support from the product owner.

Because ultimately if they have that context, then coming up with the implementation is going to be much easier. It's really is about facilitating that upfront learning than being able to do the actual work. That's something but a lot of organizations are resistant to that because the product owners really want to say like, "No, I want it to go this way and I want to just hand this to a developer and I want them to do it."

It's kind of wrestling in control and saying, "You've got veto power over this. You're the editor but we really want to make sure that you're on same page with the developer." In cases where we have been able to kind of have product owners make that shift where the developers are owning the story, oh sorry, or the primary authors of the story and more of the code reviewers of the story, if you will, implementation just seems to go so much more smoothly.

The questions, the key points kind of come out of the front of the process and by the time you start actually working on the thing, the manager or the product owners has the confidence that the developer understands what is involved in making it work.

SAM: Getting that done, what one will say something as tricky to do, I think in the ideal world, you have more of the developers involved in the design sprints or the design jams. The logistics of it are you can't really afford to have all those developers in all of those soft meetings where they are coding away. That sounds a great medium there. I think there's various organizations that do sort of their kick offs where their stories are kind of if not code designed, then there's cooperative voting on the complexities of the stories and making sure that they have folks understand the stories that they're working on and there might have some very different organization that are going to have different constraints on how much time that the organization feels, the different people can be allowed to spent on different sorts of activities. It's sort of tricky, isn't it?

CHARLES: It is definitely tricky because any time that you allocate for people, that's the most expensive resource that you have, so you want to be smart about it.

SAM: Which comes back to that issue then again of repurposing people. If you've got that feature that you go over 10 days, can you say to that person, "Can I switch you over onto this other thing for four days?" Maybe logically, that would be a better outcome for the sprint but maybe emotionally, that person is so attached to that. They are not fighting that front.

The biggest trouble for me, I think over the last 30 years is I assumed that the logical stuff was tantamount. These things like the skinny controller and the fat model, we'd agreed on that that was correct and so, that's why I should pushed for, that's why I should fight for because it's the truth or whatever and actually, maybe I'll sling back around in another 30 years, you can choose your battles because the level of emotional pressure on people, then the whole thing just explodes and nothing gets done. You know what I mean?

TARAS:: Sam, I have experienced something very similar and I think about this all the time. It's just how many perfect things are perfectly acceptable to people in using a different lens when I think about technology because the more skilled you are, I think quite often, people become more pedantic about how they approach things but in practice, the more things that you see that are not written but you realize how really imperfect they are and how in many ways, they fit the world very well, people use it. It's being used by many people in its imperfect state, so there is something like this hole between perfect implementation and the role of this perfect implementation in the world that I think that duality is really interesting.

CHARLES: Yeah. There's a fantastic paper written by, I think it was Richard Garfield back in the late-90s or early 2000s called 'Less is More,' where he kind of talks about this exact tension and he calls it the MIT school of software and the Berkeley school of software and I think Garfield came from the MIT school but basically, the whole thing was saying the Berkeley School is actually right and the name of the paper is 'Worst is Better.' It's a really interesting essay but just talking about working things that are in people's hands will beat the best design every single time because those are the systems that get used and improved.

There's a lot more to it than that. He talks about this exact fundamental tension and obviously, no system exists on either one of those perfect poles -- the MIT school or the Berkeley school. I think what he was trying to point out is that exact fundamental tension that we're talking about, the quest for the 'correct solution' and the quest for a solution. I'm actually have to go and re-read it. I remember it being an intriguing paper.

SAM: I guess the thing that makes me think of is sort of related to philosophy value. I read recently about this, attachment to outcomes. I'm going to segue back but we've got this discussion in one of our teams about, this is sort of microservices versus monoliths and in reading this, I doubt microservices, which is actually pretty radical in some of its suggestions that they're talking about it in Greater Than Code Slack where it's sort of saying that actually, if you keep your microservices small enough, then a lot of the things like code quality become actually kind of irrelevant it sort of almost argues that a lot of the things that we like about the Agile and these things are our ceremonies that are only necessary because we trying to feed these monoliths.

I'm not saying it is true. Iím just saying it's a pretty radical position that itís taking and it certainly, captures the minds of some people in our organization. Some things that I've been trying to make some simple changes just to smooth off some of the edges of the platform that we're working with and I had this respect of like, "No, we can't just make those simultaneous. We need to move to microservices." They're great and it will be perfect and they will allow expansion and so on and my immediate reaction is sort of, "I'm glad we don't have to build microservices because [inaudible]. It's all about attachment to outcomes, so am I attached trying to automate part of my week that I think will have some positive goals in the future? No one's got a crystal ball. That's only a guess on my part.

If I've got some folks who are excited about doing this thing with microservices, maybe I should empower them in that and I should started a mobile microservices and we kind of playing with these set of framework and so on. It's interesting stuff as I'm working my way through the book. At the same time, while we've been doing that, I've actually delegated it to someone else to sort out this sort of thing and I've actually kind of addressed the problem what we would need the microservices for through a different mechanism but still, the microservices thing rolls on and I kind of think, "Well, is that all a complete waste?" But then actually maybe, in two years down the line, it will turn out and that will be a beautiful thing that will enable things.

The further that I go on, the more I say, "I just don't know," and actually, if I can detach myself from caring too much about the outcomes one way or the other, I think it's both long and enjoy myself but it's a tricky thing when you got to pay the rent and pay the bills and so on. I don't see any resolutions to that. I love people being able to use things and get stuff done. I'm so excited about that and I guess, I will keep pushing all of the developers that I'm with towards trying to have a better empathy or understanding of their end users because I think software is more fun when you're connected to the end people who are using that.

CHARLES: Absolutely. Microservices reminds me kind of the experience that we've had with the microstates library. Because we've kind of identified this one very small slice of a problem, a 'refactor,' it's basically a ground up rewrite. If you've got a library that is a couple of hundred lines of code but it presents a uniform API, then you can rewrite it internally. You can refactor it by doing a ground up rewrite and the cardinal rule or the cardinal sin is you're never supposed to do a rewrite.

SAM: Yes and that's the microservices that they're saying. It's like you should rewrite everything all the time, basically.

CHARLES: Exactly. You should always be rewriting it.

SAM: Yeah. Should be able to throw it away because it's a microservice and it can be rewritten in a week and if you're throwing one away, it's only a week worth of work and you can keep on moving away. It is an amazing idea.

CHARLES: I have to read that book. Anyhow, we're going to have you on again to explore --

SAM: Well, let's do another one on microservices. It was a great fun. Definitely, it's time to wrap up but I really appreciate you having me on the show and being able to discuss all these topics.

CHARLES: Fantastic and I can't wait to talk about microservices. This might be the impetus that I need to finally actually go learn about microservices in depth.

SAM: I'll recommend Richard Rodger's book, 'The Tao of Microservices.'

CHARLES: All right. Fantastic. Anything we should mention, any upcoming engagements or podcast that you're going to be on?

SAM: Iím always on the lookout for charities, developers, people who want to help, you can find us at We're busy trying to help great causes. We're trying to help people learn about software development and getting involved in Agile and kind of like experience the real software in action, software development where you ideally interact with the end charity users and see how they're benefitting from the product. We love any support and help. You can get involved in that, if you want to give a little bit to open source and open development. We go for transparency. We have more mob programming sessions and scrum and meetings online/in-house every day, so just come and check out and maybe, see you [inaudible].

CHARLES: Yeah and if they wanted to say, reach out to you over email or Twitter, how would they get in touch?

SAM: It's and I am at @tansakuu on Twitter. Hit me on Twitter or just at

CHARLES: All right. Well, fantastic. Thank you, Sam. Also, if you need any help with your frontend platform, you know where to get in touch with us. We're at @TheFrontside on Twitter or Thank you, TARAS:. Thank you, Sam and we will see everybody next time.

Thank you for listening. If you or someone you know has something to say about building user interfaces that simply must be heard, please get in touch with us. We can be found on Twitter at @TheFrontside or over just plain old email at Thanks and see you next time.

Mar 29 2019



Rank #18: 011: Hype Cycles and Reprogramming Your Brain

Podcast cover
Read more

Michael Coté joins in a (sort-of) Drunk and Retired reunion to talk about Gartner's Hype Cycle, how it affects developers, and how they can actually benefit from understanding it. Coté is an Industry Analyst for 451 Research who helps his clients understand what’s going on in the tech world, what to buy, where to invest and where to start. We also talk reprogramming your brain for empathy, and about the trough of disillusionment in new technology.

Oct 27 2014



Rank #19: 012: Is it OK to not love programming? (with Sarah Mei)

Podcast cover
Read more

Sara Mei joins us this week to discuss passion and whether it's a job requirement that you "love programming". She’s a Chief Consultant at DevMynd, a co-founder of RailsBridge, and an all-around rad human. Today we talk about whether it’s okay to get your motivation from things other than your sheer passion for programming, such as societal impact or what you can do with your code.

Oct 31 2014



Rank #20: 013: Ember-Metal, HTMLbars, and the death of script tags

Podcast cover
Read more

Guest hosted by Ember Release Team member Stanley Stuart, this episode is a Canadian edition with Ember contributors mixonic (Matthew Beale) and mmun (Martin Muñoz). They talk about what’s up with Handlebars, HTMLbars, Metal Views, the differences between them, and why you won’t see script tags in Ember markup anymore.

Nov 06 2014