The Changelog: Software Development, Open Source - Ampersand.js, SPAs, WebRTC (Interview)

Episode Date: June 13, 2015

Henrik Joreteg joined the show to talk about Single Page Apps (SPAs), Ampersand.js, WebRTC, JavaScript coding styles, and more.

Welcome back everyone. This is the changelog and I'm your host Adams Dikowiak. This is episode 160 and on today's show it's all about JavaScript, single page apps, human ways of coding. We're talking to Henrik Jorteg, the author of a book called human javascript and also a non-framework framework framework for javascript called ampersand js if you haven't heard of it you got to check it out we talked about that single page apps web rtc we even touched a little bit on http2 so you you'll enjoy that piece there. We have three awesome sponsors for this show.

CodeShip, TopTal, and also DreamHost. Our first sponsor is CodeShip. CodeShip is a hosted continuous delivery service focusing on speed, security, and customizability for you and your team. You can set up continuous integration in a matter of seconds and automatically deploy your code when your tests have passed. CodeShip supports your GitHub and your Bitbucket projects, and you can get started today with CodeShip's free plan. Should you decide to go with a premium plan, you can use our code to save 20% off any plan you choose for three months. The code is TheChangeLawPodcast. Again, that will get you 20% off any plan you choose for three months.

Head to CodeShip.com slash TheChangeLaw to get started. And now on to the show. All right, everybody, we're back. Got a great show for you today. One we've been planning on for a bit. We've got Henrik Jortega on the call today. Developer at Anyet, JavaScript, well-known,

well-speaking. How many talks have you given this year alone? Oh, sheesh. I don't know. This year's been kind of busy. It's probably been four or five or something. Four or five. And so you're sort of, you've got this one talk that you've been kind of doing a few times,

or is it several different talks you're doing? It's a lot of the same messaging, but I try to evolve it a little bit each time just because otherwise it gets boring and I get bored of giving it. Right. Gotcha. And then you die. And then I die, yeah. And you die. It's an inside joke from one of your talks. But we've got Jared on the line here as well.

Jared, what's up, buddy? Excited to talk some more JavaScript. I know our loyal listeners love, love, love the JavaScripts. So here we are with some more of it. What is this JavaScript thing you speak of? Good question. It's some interesting thing on the web. I don't know.

We'll find out, I guess. All right. Well, this is right up Jared's wheelhouse. Not so much that it's not mine, but Jared, you went to ng-conf not long ago. What other conferences have you gone to recently that were around JavaScript? Space City JS with you in Houston. That's true. I'm also helping organize the Nebraska JS conf this summer as well.

Speaking of conferences, Henry, you've got a conference coming up. Yeah, we're doing one called Real-Time Conf. It's one that we did a few years ago, and we took a little break, and we said we'd never do it again, and we are. So it's just kind of about a lot of real-time web technologies and really kind of trying to be a little bit more thinking about what the web should be and what we should be working on rather than just the stuff that we could be doing. So made you change your mind you said you never do it again

i'm gonna largely blame adam brault for that uh but uh you know it's just it's just it was a good event we met a bunch of cool people and we we just want to do it again so cool cool and when is that um it's coming up in the fall here i i'd have to put the exact date in the show notes. I should know, but I don't off the top of my head. I think it was October or something from what I saw. Yeah, it's October. But we're selling really good tickets right now. So first kind of batch of tickets is up right now.

Get a ticket. That's a pricey ticket. It is. But we do a bunch of really cool stuff. So we spend it all. Trust me, we're not going to make money on this thing. This is. It is. But we do a bunch of really cool stuff. So we spend it all. Trust me, we're not going to make money on this thing. This is not a profit thing, right? Yeah, yeah.

Community building. Yeah, just check out the last one that we did, and you'll understand why we charge what we charge. Cool. All right. Well, we'll have to do that. We like going to conferences. It's a lot of fun. So aside from putting on this conference and speaking at conferences, you're also pretty well known for a book you wrote and Ampersand.js and your work at AndYet and some of the things you put out in the open source world where if if you were i guess on the change

log stage and you were introducing yourself to an audience that some know you some don't know you how do you introduce yourself oh sheesh uh well so i i mean i'm a web developer right like i think that's kind of the most important thing uh but i use javascript to do so um i've been kind of lead javascript developer at and yet for a while um and i just do a bunch of open source stuff i've got a few hundred open source modules and stuff and uh you know things like uh around webrtc but just a lot of kind of thinking and talking around how to structure web applications in a way that doesn't like make an absolute mess of your code and so that other people can work on it, et cetera. I wrote a book called human JavaScript that kind of attempts to encapsulate some of that knowledge and also kind of training and teaching around those

kinds of things as well. So I don't know. That about sums it up. Yeah. I think, and yet you guys are perhaps most open source famous for ampersand JS. First of all, is that true? Or do you guys have a bigger project that just hasn't hit my radar?

Well, we have one that you shared a while ago called Simple WebRTC. That basically just takes, in terms of like number of stars on GitHub, that's probably up there as well. Okay. But yeah, it just kind of makes webrtc something that an average web developer can do without having to like go study how this stuff works too much right so but yeah ampersand is is definitely kind of our the thing that i think people have kind of seen the most of so so you want to give us the elevator pitch yeah i mean if you take if you think about

something like backbone like a lot of people like the patterns in Backbone, but there's a lot that Backbone doesn't do. And coming from kind of the Node world, we like to split everything up into small modules. So what we did is we kind of started with Backbone. We used to build a bunch on Backbone. And then we ended up kind of just forking and doing our own thing. So we took each kind of component that you might have in Backbone,

and it's published then as its own module. It's all written in CommonJS. So you have to install it with NPM. But as a result, you end up only shipping what you actually need, and people only grab and use the little portion of it that they want. We could have just done the whole thing as a bunch of completely separately named things, but we just kind of called it ampersand to give it something to kind of wrap it all together. I assume the other tie-in there is the thing that sits in front of your business name.

Yeah, well, we rather like the symbol there for some reason. It's a good tie-in. I like that. Yeah. So what's ampersand's relationship to Backbone? Is it inspired by? Is it a fork? Is it a rewrite? Is it the same thing?

It definitely shares some code. At first, I was just kind of writing a replacement for the models because I wanted models that were a little bit more specific as to what they would contain. So unlike Backbone models here, you have to actually define what you're going to store in a given model. You have to at least give it kind of a name and a type. And then the idea is that someone else who's kind of new to a project can like jump in and read your models and actually make sense of what's being stored and, you know, kind of the state that they have available.

But other portions like the router, for example, are much closer to what Backbone does and a lot of code. In some of those cases, we left the license in because there's so much shared code, right? So it kind of varied depending on which component. But definitely if you're kind of from the Backbone world, you'll feel kind of at home here. So Adam and I were talking kind of pre-call about Ampersand, the modularity versus some of the other frameworks and Backbone itself. Who would you say Ampersand is for? Is it for the beginner? Is it for the advanced person who is ready to pick and choose? Who's your core audience?

It's definitely not as easy to pick up as something like Angular. You know, I think, uh, people who've done this for a little while probably are going to understand it and understand this value a little bit easier. Um, that's not to say though, that you couldn't start with this. Um, but I would send to say, for the most part, it's people who, who kind of like the patterns in Backbone, but they want the modularity and stuff that's such a big thing in the Node community. So, but yeah, we, you know, my favorite thing is that the way people are using this is like they'll just grab various pieces.

Like WhatsApp, for example, they use just ampersand state. That's the only module of ours that they use. And they use React as a view layer and all that. And then you get, you know, other companies that are just using, like, I know some folks at Yahoo That's the only module of ours that they use, and they use React as a view layer and all that. And then you get other companies that are just using – I know some folks at Yahoo that only use the router. And to me, that's a good kind of pat on the back that we did something right because that's the whole idea. It's like you don't have to go all in.

You can – here's a bunch of tools. They work nicely together if you want them. If you don't, just pick you know, pick and choose, mix and match with whatever else you want, right? So React or Ampersand View or some other way to do things in the front end? Yeah. I mean, people have been doing it, mixing it up with, there's one called Riot.

There's Ractive. There's, you know, a bunch of these like kind of view layer things that I've seen people use Ampersand with. So the fact that you can kind of pick and choose is, I would say, one of its key features. Being so inspired by Backbone, would you say it's a prerequisite to have some working knowledge of Backbone before you're productive? Or could you just start right in with ampersand? I would hope not. You know, it's possible that we need to do a better job of writing more intro level guides.

But we have some of that stuff on the site, and it keeps getting better. So that's something that if you're new and you're just looking into it and you're confused, like file a bug. We want to know because we want to make it more approachable for people who are new. So we have to ask the question. Every framework that comes on, we tend to ask this and it's kind of the why why ampersand in light of not just in general but in light of your other options right because there's such a diverse landscape there's so many tools out there right now that it's it's commonly asked and talked about which one should i choose? So if you had to put it against an Ember,

against an Angular or a framework like Aurelia, and you say, well, here's where Embersand really shines, and then maybe here's where it's not a great pick, could you do both of those? Yeah, I think so. I mean, in some ways, I kind of hate pitching it or defending it at all because I want it to just kind of stand on its own. And I think the important thing is that people pick tools that, that kind of fit how they want to

work and that let them be productive. Uh, if, if for some people that's, that's something like Angular, then, then great. If that's meeting all your needs and like, stop, don't, don't need to, you don't need to go replace it. Right. Um, but I think, you know, where it does shine is, is kind of being able to handle and tolerate change over time. Um, you don't have to go all in, uh, that's kind of, you know, someone referred to it as kind of a fear of commitment framework. I kind of don't even really like calling it a framework at all. Uh, and I, I almost hate myself a little bit for having contributed to this whole kind of range of available options here but uh for us it was just a matter of like hey here's the stuff

that we're using this seems to work pretty well for us let's share it and see what happens and you know come to find out other people seem to think the same so there are people that have kind of referred to it as a as kind of a natural kind of backbone 2.0 sort of thing. I wouldn't go that far, but it's kind of a Node-flavored backbone, I guess. We shared an article in – we ship a weekly email every Saturday called ChangeLog Weekly. I don't know if you subscribe or not, but in last week's – I should. It sounds like. You definitely should. I don't know why you're not.

Everybody should. ChangeLog.com slash weekly. I don't know why you're not. Everybody should. Change.com slash weekly. Go sign up right now. Will do. But one of the articles we share was, and it was the most popular in this latest issue, was did you pick the wrong web framework? And it had a question mark and a bang after just to put the extra oomph on the end there. Right. and something that might tie into how you think I think is one thing mentioned here was start with humans rather than saying which

code base or which framework works best for us and start with the people that are actually using it and how the teams work together and how they're going to be using this project long term and think of it that way versus the tech start with the humans would you agree with that statement?

Yeah for sure and I mean we you know, we do, we do consulting and, and yet, so we get, you know, we build apps for lots of different types of groups of people. And so we get this question a lot, you know, like, how can I know which tools I'm supposed to use? And I would say the answer is you, you can't, right? Like the, how can we predict the future? What we can do is pick tools that like leave us some flexibility and i would say that's kind of my my biggest concern with uh some of these like more all-inclusive frameworks is it's you're kind of all in like in in some ways and some people are going to hate me for this but in some ways like you know getting really good at angular is is i

would think it's almost kind of like getting really good at Flash in some ways. Like you're kind of going all in on that technology and you're learning that technology almost more than you are learning the problems that that thing solves for you. I think his name is Chris Gale. He was the former vice president at Yammer, former vice president of engineering, said, you know, I'm more interested in people's understanding of problems than solutions. And I think that tends to be the case. We tend to want to kind of grab something off the shelf that just kind of solves our problems. But that doesn't leave us as prepared when we have to evolve it over time or, you know, something else comes along that we're interested in. Like we're kind of all in and it's hard to switch.

And then we have this kind of almost religious buy-in to the framework that we've subscribed to. And I just don't really think anybody wins in that scenario. Like, I think we're better off, you know, kind of identifying and understanding the problems of building applications in this way and then being able to pick the tools and then we're in a better spot to evaluate like which solution actually makes sense here and i also like the concept of you know kind of the small modules thing from npm and only using what you actually need um which then leaves you the option to replace or what have you yeah see i'm on kind of two minds on this because i definitely see the

value in modularity and uh dipping your toe in the water we just had uh the microsoft team the typescript team on recently i think it was uh in 152 and you know typescript's seen some adoption because they decided to go with a strict superset of JavaScript and that allows teams to like dip their toe in the water with TypeScript. And it's not a huge investment right up front to get into it, which it sounds like that's some of Ampersand's power is that you can kind of dip your toe in the water. And I see the value in that. And definitely as you build and things change,

that's the only thing that we understand in software is that things are going to change. Yeah, for sure. At the same time, I also understand that paradox of choice and that paralysis that happens when you're just getting started and i need to pick you know 30 different modules that i'm going to go with and it requires a lot of kind of prerequisite knowledge which i i really don't like either that's something that um like if you've ever been to any of my workshops or anything that's always something i try to kind of just be like hey here's a starting point like if you if

you do this and you build things in this way then at least you kind of you're accidentally learning the various pieces involved here and the problems that we're solving um but yeah i think we've made it way too hard to be a new web developer like way too hard like it's super frustrating um so i you know and i think i mean if you go read hacker news and something you're you're a brand new developer you think you have to build some like crazy isomorphic app or whatever just to start right i'm like you're just scaring people off before they even start uh whereas you know when i was getting into this stuff like when i first first saw jQuery and I'm like, holy crap, I can just open a console and, you know, see some like little elements flying around the page. Like this is awesome.

I now feel powerful, right? Right. And like I think what we're doing for the most part is scaring people off more than actually making them feel like they can jump in. So what I'm kind of interested in is trying to find that balance between like, you know, giving a new person a toolkit that they can just start with without having to like grok everything, but still have the resulting app be something that's, you know, reasonably performant and is well-structured to the point where someone else can jump in and help or whatever. So I think it's a really hard line to walk, but I think we should keep trying.

Interesting. The point that you get where you're picking a JavaScript framework, you've actually already made some decisions, right? And one of those foundational decisions you've made is you're going to be client-side rendering. Sort of. Yeah, sort of you can you don't necessarily have to do it all like that but um generally speaking you've decided to separate out your api your server side from your from your client side which that's a big debate as well right and yeah i was interested i read a few uh pages of your book uh human javascript you have

it online for free we'll link that up in the show notes. One of the things you say there, which was a surprise coming from you, a JavaScript advocate, is that for many types of applications, building a single page app is harder and gives you no additional value. I do think there will be a day when that's no longer the case, but we're not there yet. Yeah, I agree. You got to realize I wrote that two years ago. Okay, so is it outdated? It's not outdated. It's just, you know, like you said, I do think we're moving towards the time when that's no longer the case.

I am going to go and do a second version of the book, and when I do, it's going to be talking about, basically recommending that what you do is that you build kind of static single page apps if you will uh where you basically have everything you know you kind of get your whole file structure but you compile it down to a set of static assets and uh where you also then pre-render anything ahead of time that you know is going to exist at a given url um i really like that pattern of having like kind of drawing that line in the sand,

like, hey, we're building this static app. And I think once you get to that, it can start to feel like, you know, this is a better approach. However, there's still the case where like, you know, for certain types of apps, like why are you doing a client-side app anyway? Like it doesn't really make sense. Like if you're publishing a news site, like why on earth are you doing a client-side app anyway? It doesn't really make sense. If you're publishing a news site, why on earth would you make it client-rendered? I don't understand that.

To me, you're just adding complexity there. It's hard enough to get, if you're working on BBC.com, to make something that's going to work on every device ever. That's hard enough of a problem to solve. The primary purpose, the reason people are coming to your site is to read that content. Like don't make me download two megabytes of JavaScript to read your news article, right? So I think that's where you have to really focus.

Again, you focus on the user, and all those things kind of tend to sort themselves out a little bit. It becomes clear what you're aiming to do. If the answer is to provide this really rich kind of application-like experience behind a login or something, man, by all means, like, write it in JavaScript. But if you're just publishing content or you're doing a blog or whatever, like, let's not make the hard things – let's not make the things that can be simple any harder than they need to be. Yeah.

It kind of reminds me of the post that Martin Fin fowler put out this week monolith first did either of you i did read that one yeah and then kind of the the synopsis there is that there's this trend towards microservices and there are completely legitimate times where microservices is the architecture that you want to take on but oftentimes it's not that you want to take on right but oftentimes it's not what you want to take on at first because you don't know what you're building or uh you're just over engineering for something that may never need it lots of reasons and he goes in the details i think we'll definitely put that one in weekly yeah this saturday in the queue for it is it great um but like keep it simple right and then and then But keep it simple without backing yourself into the corner. Right.

And I think that's kind of what you're advocating there as well, which is don't over-engineer. If your problem that you're solving doesn't require a client-side rich client, then don't start with that just because it's what people do. Right. Yeah, totally. I mean I think there's –'s again make things as simple as it can be software is inherently like difficult there's like the natural state of any code base is entropy like we we don't again it's it's a battle that you have to fight i think is to try to keep things as simple as they can be and if you don't you just get it up with a mess and someone

else is gonna have to clean it up so you kind of asked this question a bit earlier, but I'm not sure if we got a clear enough answer if it was – Okay. I'm just not sure. Try it again. Hold his feet to the fire. Come on. Well, after having this conversation, I'm wondering what kind of developer does Ampersand serve then? How would they choose it over things like Ember, Angular, React, Aurelia? Now put React. Is that React in the notes?

Did you replace Durandal? We have Durandal in the notes, Jared? React is not Aurelia, yeah. Great fit there. Durandal is also, you know, Aurelia. He's moved on. He's moved on to Aurelia, so that's why I replaced it. Anyways.

I mean, it's not one or the other. I mean, it definitely, if you go Ember, like, if you use Ember, you're not going to be using any ampersand stuff. But personally, I've been building a bunch of stuff with ampersand and React, and I like it a lot, where I'm just using kind of ampersand to model some data from APIs and what have you, and then using the simplicity of React as a view layer to just kind of re-render at will. And it's super easy, and it makes things, you know, pretty straightforward. So I think, you know, again, I'm not going to sit here and like tell people to like, you should use ampersand, but for some people, it really, it really fits, uh, how they go

about building things because it, it lets you kind of, I, for example, I was just in Las Vegas at future insights live. And, uh, the guy gave came up on stage and gave a talk about like you know building front ends without frameworks and he starts out with really really basic like he's like you don't need a model you can use these plain json objects and then he goes well then you need to put them somewhere in that case maybe like use a collection then he starts using he's like oh and he started with the ampersand collection like so now instead of having just an array of objects he had an array of small modules that he could or small models that he could then observe and it's like you know that's

kind of the mentality like if you start with the absolute basics first then you can kind of layer in stuff as you find yourself needing it as opposed to like i'm going to use Ember for this app that, you know, you may never need, you may never use a third of what Ember has and has to kind of instantiate for you when you, when you spin it up. Right. So I think, I think it's a toolkit, you know, someone said that it's, it's more like a machine shop rather than a hammer. Like anyone can swing a hammer, but if you have a machine shop you can build really incredible finely tuned things um so i think that's a little bit more of the where it fits in so how we name some of the actual individualized modules

i'm just thinking for some links and just you know some of the core things you use to to build so ampersand state for example is basically an observable object, and it doesn't make any assumptions about how you're going to use it. So basically you define a set of properties that this thing is going to store. You say what type it is, and then it will throw type errors if you try to set a value equal to something else, right? And it's the wrong type. And it will fire a change event anytime you change that value, whether you do it through a set or

one thing that we do that's kind of unique is like, even if you do it via assignment, so you say, you know, model dot property name equals something else, you'll still get a change event from that. Because we're actually, because we're forcing you to register which properties it's going to store. We create these getters and setters to actually do that. So as a result, you end up with this very nice little observable object. And then ampersand collection, for example, is basically an observable array. So you can store plain JavaScript objects in an ampersand collection. But then if you want to talk to an API with that collection and get that data from an API, you can use ampersand rest collection.

And then you just add a URL and you have a fetch method now. So you can call fetch and then you're kind of in backbone style collections. So you can kind of, you see, you can kind of just grab what you need. One of the reasons I originally started messing around with kind of splitting this stuff out is like I was building this, this touch library. And what I wanted to do was be able to model touch events. And if you've ever done with done this directly in a browser, you have to you basically get you get a touchdown, a touch move and a touch up, right or touch end. So if you've ever done this directly in a browser, you basically get a touch down, a touch move, and a touch up or touch end. So if you want to do something that's based on a hold action,

there's a ton of stuff that you have to model there. You have to know, okay, it started at this spot. It hasn't moved more than this distance. You have to set a timer when you first put the finger down. And then at some point, you have to notify the code that cares about it, that it's now being held, right? So it's a bit of a complex example, perhaps, but with something like a, you can take just an ampersand state object to model each touch. And then you just set, you know, the properties, and then you can have all these derived properties based on the values that you set. So you can say I have a – the classic example being I have a full name that's based on first name and last name, right?

But these things get intelligently fired based on changes. So if the end calculated result isn't different, it's not going to fire a change event on the derived property so as a result you can almost kind of do this functional reactive programming style uh and have these very concise easy to describe state objects that will let you you know kind of track complex state like that whether it's you know coming from an api or not right hopefully that made sense and it's a bit of a bit of a ramble and then view obviously we talked about view a little bit earlier it's uh it's not full on react obviously so it's something a bit more right so but you could swap it out for react if

you wanted to yeah yeah so ampersand view is a bit like it's basically a slightly more powerful backbone view um honestly ourselves we've recently been leaning towards just using react as a view layer instead and that's that's precisely the functionality that we wanted like being able to have the ability to swap things out as as we saw fit so um if you like backbone views you'll probably like ampersand views if you like react then you can just use react right just sitting here wondering just personally what your personal technical background is as far as did you cut your teeth on javascript or do you have other languages in your back pocket well i started uh years ago when i had no idea i studied business so i i didn't study this stuff

at all um but i mean i was always into computers but i didn't really like program. In my senior year in college, I wanted to start a business that was like this web-based real estate listing thing. I couldn't afford to hire anybody who was any good to build what I wanted. I was like, how hard can this be? I started just kind of messing around with it. This was like 2005. At the time, I had no idea what to pick i found a really great tutorial on lynda.com um building an app with cold fusion so that's what i did yeah oh yeah oh yeah so but you know but once you kind of pick up a second and a third language like

you start to see that they're really all the same i i uh i did python after that it're really all the same. I did Python after that. I was really into Django for a while. I loved the cleanliness of Python, which is something I still kind of miss a little bit in JavaScript. Python has PEP 8. It's like, hey, the creator said this is how you should write Python. It'd be nice to have some of that to some extent in JavaScript as well. I like that about Go too, where they actually have a tool that to some extent right as well i like that about go too or they

actually have a tool that you know go format where you can run it through and it just basically reformats your code according to the standards it's like awesome yeah totally and you don't sit there and argue about this stuff except but what i don't like is it puts hard tabs in there and it's like oh no you know so like it's all good as long as you agree with my uh with my opinions right no totally i think it's important to recognize though yeah right but i think you know recognizing the things that are important to argue right versus things that aren't right i've recently gotten really into using um i don't know if you guys know frost um does a bunch of crazy web rtc stuff and is big in the node community but he's he's the guy that did web torrent okay how do you spell his name? F-E-R-O-S-S.

He also did PeerCDN, if you ever saw that. But anyway, he had the audacity to create a node module called Standard. That is his set of code style for JavaScript. And I just love it. I've just started using that. It didn't match everything that i believed in in terms of like how i was writing code before it was like i don't care it's got a built-in formatter i don't have to argue with anybody like you just make it part

of your testing there's no config there's no arguing it's like yeah no this isn't the make no no es lint rc no jsIntRC, no JSCSRC. What is that one? I don't know what that one is. It's just another one. That's the one I think jQuery uses. The lesser known? It's actually reasonably popular, but yeah, I haven't used it much.

That's neat. One thing that they do have that's quite cool is that you can kind of have – it has some pretty powerful formatting stuff. So once you define your rules, not only can you say if you validate those rules, you can kind of have it has a pretty powerful formatting stuff so once you define your rules not only can you say if you validate those rules you can kind of say reformat my code to meet these rules which is pretty neat you can opt in to certain things but not everything well what i'm saying is you can go the other way you can have it format your code based on the rules that you give it right so it's like it's not just going to tell you you know shame on you you didn't follow the rules it's going to also say i'll rewrite your code for you to match the style that you defined which is pretty cool that is and standard has has a formatter now too so that's that's also good is

there anything in here that just writes the code all together i wish i would work it on that that's the next step is like you verbally describe your application yeah yeah english to javascript there you go compiler yeah we can get the dragon people you know those people where you talk into the mic and it types for you oh yeah get them involved they'll be excited about that you guys have never heard of brain brain to js because that's that's what that is yeah just brain skip the. You don't need the words. Just straight for the brain. Yeah. Straight for the brain.

Brain to JS. English is a lossy translation. Yeah. It's my new library. It's coming out in 2020. I'll use it. Well, while we're learning a bit more about your background, Henrik, let's tease real quick. We're going to take a a break hear from a sponsor

but when we come back we're gonna hear how you once described yourself so let's let's break we'll be right back you've heard me talk about top towel several times on this podcast but today is different i've got a special treat for you i went out and spoke with a listener who a year ago had never heard of topTile. He listened to the show just like you're doing right here, right now, today, and heard us talk about TopTile and what they're all about, and he decided to get in touch. And now he's living the dream as a freelance software developer with TopTile. His name is Daniel Elzon, and I sat down and I talked with him.

I said, hey, what is it that you love most about TopTile? Take a listen. Well, for me, the thing about TopTal, which I thought would be very hard for me personally as I transitioned to a more consulting role, was the way I would have access to new clients and what quality those would be. So I found that I've had access to awesome clients through TopTal and it hasn't been that hard to find because they have a lot of choice and even more than that there's enough choice and I can actually be a little selective about what kinds of things I want to be working on so I use that

as a way to sort of hone my skills and you know go towards the technology that I think are worth investing in for the future so whether it whether it's including new front-end frameworks or doing a little DevOps work on the side, I usually am able to find clients who have the needs of the things I want to get better at. That's been truly useful. All right, that was Daniel Lausanne, a listener of The Change Log and also a freelance software developer with TopTal. If you want to follow in Daniel's footsteps, go to TopTal.com slash developers.

That's T-O-P-T-A-L dot com slash developers to learn more about what TopTal is all about and tell them the ChangeLog sent you. All right, we're back so henrik you once described yourself as not a good javascript developer and that's on your about page on the and yet website so it's it's in black and white you can't run away from it what what made you say that why'd you say that because you seem pretty good to me well i i mean how do we really objectively know anyway right i mean honestly you just put it on your about Well, I mean, how do we really objectively know anyway, right? I mean, honestly. You just put it on your About page.

That's all you got to do. No, I mean, so what happened was that's – I said that to Adam here at And yet shortly after I started. I hadn't written that much JavaScript, and I just kind of – I don't know. I've been told I have a self-deprecating personality anyway, so maybe it was just a little bit of that. I don't know. But you no longer call yourself this, of course. I've kind of come to terms with the fact that I'm okay at JavaScript.

There you go. So at what point did you start getting deeper into JavaScript? How many years has it been since you came from ColdFusion, python and then now you're where you're at now i've basically been writing javascript exclusively almost for the last five years and and the uh when i first joined in yet we had this really cool project actually where um we were doing this rather intense asset tracking application they had these really cool little devices that um they would set up like a terrestrial network, and then they would be able to track like with super high precision within a small area where everything was. And they needed a web app to do this.

And so we actually wrote like a whole job system that would process tons of that incoming data, and then we displayed all this stuff in a browser on a live map so it'd be the kind of thing where like you could even have someone have a sensor in a briefcase and they'd go up the elevators and we would do things like switch out the uh the floor map based on the barometric pressure on these sensors right like it was it was quite an involved app and it was very, uh, advanced as far as web apps go for it for its time. And, uh, it was right around the time when like we wrote a version of it and then backbone came out.

We were in the process of basically writing our own backbone back then. Cause we knew we needed it. And then when that came out, it was like backbone 0.3 or something. I'm like, Nope, we're using this. And I just rewrote the whole app using that. And that was four or five years ago now. But yeah, I don't know. Just been doing lots of it since then.

For version's sake, right now the latest production version of Backbone is 1.2.1. Just FYI. I'll update. So is that app still in production uh yeah actually it is uh it's it was for a kind of a very sort of private group so it's not like um it's not like something you can really go look at i don't think sure which is nice to be able to write software that's still valuable you know four or five years later yeah Yeah, for sure. Aside from the browser changing and standards changing, I guess, within the browser, you know, older JavaScript apps don't have much of a problem because they can be served from pretty much anywhere if their client's not, right?

So you pretty much just deal with the evolution of JavaScript and the ever-changing landscape of the web. Right, right. Yeah, and at the time it was really unique to have something that was getting that much data pushed to it from the server through these real-time connections. So we had – we were early users of Socket.io, and we were using – before then it was even kind of these long polling systems using Bosch, XMPP, to do this stuff in the browser, which was – so I was writing like XMPP plugins and stuff five years ago, which was interesting. So let's hold off on WebRTC because I'd like to talk about that later just as a standalone topic. But aside from that, how has the web evolved maybe from the time that you started even when you were not so good of a JavaScript developer to now?

And then what are some technologies that are either here or are on the fringe of coming up that are exciting for you? Well, I think how it's evolved is it's just gotten complicated. That's not good. No, it's not. Is that a devolution? In some ways, I think so. But I think that we are starting to see a shift there. And I think, you know, things like, I mean, I think React is one of the few, like, that stands out as like an actual simplifying technology that's appeared in the last few years that actually make lives better for developers. Simply because you don't necessarily have to do individual bindings.

You can just be like, hey, re-render whenever you want. That's extremely valuable from a complexity standpoint. You don't have to keep all that stuff in your head in the same way. Of course, it has its own set of challenges, but I think that's been one of these huge things that have changed for the better.

I totally forgot the second part of your question. Just upcoming technologies, web technologies, ES6 stuff, whatever is getting you excited. I'm writing a bunch of ES6 stuff, whatever is getting you excited. Yeah. So I'm writing a bunch of ES6 now using Babel.js as kind of a transpiler. I think once you get to the point where you have a build step in your application, which I would go as far as to say that we should all be doing that these days. The tools have come far enough to where there's no reason not to. Once you have a build step, you know,

it's a pretty inconsequential thing to just also sneak in a little transpiler in there as well. So, you know, I've been writing ES6 exclusively now for the last little bit here. And I think being able to do that, it just kind of eliminates a little bit of boilerplateplate and stuff that we've had to do before so i think that's a nice change that we're seeing um again like i said before i'm i'm huge on like this whole concept of going back to making your entire client-side app completely a static set of files i think that's i think we're gonna see a lot more of that i see a lot more people doing

that dramatically simplifying operations and stuff as a result because you're back to transferring files. One of the developers from Shutterfly was in one of my workshops, and they went and changed a bunch of stuff. They built a bunch of stuff with ampersand, and they compiled it all down to a set of static assets. And he was like, yeah, our deployment tool is now rsync. Which is like, you know, and in talking to folks from Flipkart, which is one of the largest e-commerce sites in India, they actually have a unique situation there. But they basically do the same thing, right? They compile everything down to a set of static assets, and then they use WebViews inside Android apps to do this stuff. But still, they handled their scaling issues by making their clients do more stuff.

They had a rather dramatic server issue on a very big day for them before, and then this is how they fixed it. So they're passing more stuff off to the client. I think we're going to see a lot more people doing that as clients become increasingly better run times. Yeah, related and maybe perhaps a little bit of a tease for next week's show. We'll be talking HTTP2 with Ilya Grigorik. Oh, he's awesome. Yeah, we had him on earlier this year talking about GitHub Archive, and we're excited to have him back to talk about the update to his book now that HTTP 2 has been finalized and stuff. And that's really going to flip the script on a few things

with regard to best practices and serving static assets because things that we once were like canon truth are no longer true anymore, such as the requirement to concatenate your CSS all into a single file is actually an anti-practice when it comes to HTTP2. So I think things are going to be changing, but they're also going to be getting easier because now you don't even have to have that build step necessarily to have the performance gains. Sort of, but I would still say that most of these people that are building these types of applications, it's not just a matter of five or ten files. We're talking a couple hundred files maybe.

And, you know, I don't know if doing those, even if you kind of pipeline them in the way that you can with HTTP2, I'm not entirely sure it obviates the need for a build step. So it'll be kind of interesting to see what happens. And that logic has to kind of happen somewhere, right? Your server has to be smart enough to know what to send for what. And so I don't know. I haven't seen a ton of really great open source answers to these questions yet.

It's quite possible that I just haven't seen them. But yeah, I don't know. It'll be really interesting to see what happens. Yeah, I mean you're right in the fact that HTTP2 is opt-in. So you're still going to have many, many clients for many years that can't speak that language and you're going to have to provide an optimal experience for them as well um i'm pretty sure that and we'll find out next week we'll ask him this very pointedly but i'm pretty sure that um even with many small files it's actually faster not to concatenate. Right, but you're still going to want to minify them.

Yeah, why not? So the build step doesn't go away, right? Right, the weight. You're going to want to set some of the weight. Yeah, you're still going to have a build step. So the build step doesn't go away. Sure, sure. But yeah, I agree. Just the best practices are changing a little bit, that's all.

Exactly, yeah. And I think it's going to be really interesting to see how kind of the tooling steps up to match that. I'm quite curious to see how that plays out, too, because I think performance is one of those things that we have to care about on the web. And we've seen lacking in some of these larger frameworks, just a little bit too heavy. So seeing the technologies catch up to enable these kinds of things is interesting. Yeah, we'll see. I'll have to pay attention next week too.

I want to hear what you said. For sure. The other thing around performance is we've had a move recently thinking specifically of Facebook's – what's it called? Instant news? Yeah, instant articles or whatever. Yeah, instant articles where they're basically declaring, which is but they're declaring that you know the web isn't fast enough you know we need to be able to catch these news articles so that we engage people faster because people want their information right now or they're going to move on um and so specifically

around content-based sites right news sites right. There's conversation around is it the web technologies and the DOM that's just never going to be good enough, or is it the tools, or is it the developers, or is it the businesses? Do you have a take on that? Well, I think in their case, it's fairly straightforward. I mean, fetching and caching content ahead of time is going to be dramatically faster. And even though they're not saying it, I would venture to say one of the big reasons they're doing it is they want to control the experience of those sites as well, the experience of that content. A lot of people put so much clutter and ads and stuff into these content sites. Like you get these links to BuzzFeed or what have you, and it's just a bunch of – you have to sit there and wait for so many unrelated things to load before you ever get to see what you're trying to see.

I would venture to say that's at least in part what they're addressing as well. It's not that – if they knew that all these sites were super well optimized and served content first, I don't think we'd be sitting here having this conversation, honestly. It's not a big concern, though, for those who care about data plans and stuff like that, that are fetching data that they don't actually want to. You're sort of pre-fetching, assuming you're going to want this content, and then you're sort of like, no, I don't want it, and you're burning through all your bandwidth. Yeah, I mean, arguably, right? That's a good point. But obviously, that's a choice that they made.

And, I mean, I think a lot of people are experiencing content through the built-in browsers on Facebook these days. And I would venture to say that by grabbing content directly from the publishers the way that they are, they're probably minimizing the total amount of size file coming through maybe. But I don't know. Yeah, it's hard to say. I guess if you're in that Facebook wall world, you know, you're in the app, you're not, you know, it's Facebook. It's not a Facebook conversation here, but just a tiny little rant, I guess. Sure.

You know, if you're clicking a link from within Facebook, it's their anticipation that you're going to want whatever you've clicked. And then so they can sort of go to that site and pre-fetch a lot of the data if they need to to speed it up is that what this instant page thing is jared or instant article is that like so when you click through the link it's there faster than no it's actually like a capturing so facebook so imagine new york times has an article facebook's is going to go grab grab that cache it and serve their version of that article to everybody um and so it's just not any new york times server at all anymore yeah they've worked directly with publishers from what i understand to kind of get access and uh right so it's not going to be for every link you click right for specific publishers right and i'm sure there's deals around

making sure they still have analytics and that kind of stuff but um because those aren't those businesses aren't just foolish and i'm sure they're pretty skeptical going into it still but anyways well hendrick did say earlier it's getting more complicated so it is right well i think i think the web is i mean i think it's important to note that the web is getting to be you know simply putting your content out there you don't know how it's going to be used. I mean with more and more devices hitting the internet that are not just big desktop screens, people are extracting content from stuff all over the place. And I think kind of coming up with ways to serve the content in its raw form in a way that still makes sense is going to be a bigger deal. And, you know, we're seeing a lot more APIs and stuff.

But to some degree, there's people getting really stingy about access to those APIs, too. So we shall see. Especially as they get more popular and more traffic. Right. Remember the days of pop-ups and pop-up blockers? I mean, pop-up ads were the worst, right? And then browser vendors just solved it. They're just like, yeah, you can't do that anymore. And nowadays, you know, we have these like full page modal things that are like, it's the content overlay. It's not a pop up. It's just like the entire page is taken over by some ridiculously off off topic ad before we can get to the content. So it's a struggle because publishers need to make money, put the content out that we want, but they're not really serving us.

It's just a mess. Yeah, for sure. But I think the people that are building JavaScript applications, these are not necessarily the problems we're solving. A lot of times the apps that we're building are things that are more control panel type interfaces. I think the whole content conversation is a bit different than at least most people that are using these frameworks and tools that we're talking about here are not building those types of sites. Hopefully.

And I think it's perfectly okay to say that there is a different type of application on the web. I think people get a little riled up about saying that there's any sort of difference between a web app and a website, right? Like that old debate, which is super worn and tired. But from my perspective, it's a fairly clean distinction depending on what type of experience you're trying to provide to the user. Yeah, just to go back again to something that you wrote in your book, he says, building client-side apps is often more complicated than a server-side rendered app. Decide carefully.

Ask yourself, is there additional benefit for your users? Are you building something that is open and closed frequently, or are you building an experience? How often does the data in the application change? Do you care if it changes while the app is open? So I think that speaks well into what you're saying a lot of these a lot of applications that are served very well by client-side frameworks are dashboards and data rich things that need to be updating live whether it's pulled or pushed

and the content sites that we're complaining about like they actually kind of have it easier they have the simpler side right they just need to serve the content and most of the time it's actually you know business constraints that are that are causing they just make it hard and annoying yeah on purpose yeah to be a developer you might end up putting something like back but like i can recall back at pure charity when we were doing some different things. We were doing server-side rendering through a Ruby app, but we were also building Backbone on top of it to provide a better, richer experience for some of the data there. So you sort of still do sometimes have that crossover there when it does happen.

Yeah, for sure. Especially conference sites. That's where it's nice to be able to grab little pieces that you need too. That's another little pitch there for Ampersand, right? And that's how we've seen people use it. I know people at Financial Times that have used it for little like, you know, interactive visualizations and stuff, right? Like that are kind of add-ons to otherwise static sites and what have you. So, you know, I think, yeah, it's definitely, it can be used in that tool set for sure. But yeah, I think a lot of times people are...

Most people that do this stuff day to day are being asked to build these control dashboards and these data input systems and stuff, right? Exactly. Well, I think I like to switch gears to WebRTC. Okay. Sound good? Maybe let's take a sponsor now. We'll take a break, hear from a sponsor, and when we get back,

we'll talk about WebRTC and simple WebRTC when we get back. DreamHost now has managed VPS hosting built for speed and scalability, including solid-state drives, and that's awesome. These VPSs are built for open-source developers and now include one-click installs of Node.js, custom Ruby, and RVM support. Speed, speed, and more speed is what it's all about. Their VPS servers use SSD hard drives and are 20% faster than traditional SATA drives.

All virtual private servers from DreamHost include SSD storage, Ubuntu 12.04 LTS, web-based control panel, scalable RAM, which is super awesome. You can go from 1GB of RAM and easily scale up to 8GB if you need it. Node.js one-click install, Ruby version manager, unlimited

bandwidth, unlimited hosted domains, unlimited 24-7 support. Go check them out and learn more at dreamhost.com slash the changelog. All right, everybody, we are back. We are talking with Henrik Jorteg about all things JavaScript and web and the cool stuff they're doing over at and yet Ampersand.js and another project he mentioned before the break which is simple web rtc henrik can you tell us first of all what's web rtc why is it cool and

then how does your guys's open source tool play into it sure so web rtc is essentially a low latency peer-to-peer networking in the browser. So, you know, WebSockets is server to browser. WebRTC is browser to browser. So you're actually negotiating a direct connection between two browsers. And then at the point where you have that connection, there's no server anymore. So, you know, you can do things like voice and video streaming so you can build in voice and video communications applications or you can use the webrtc data channel to then send you know whatever sort of data you want so you can do

things like file transfer or what have you um but i mean essentially the way that that works is you still need some sort of discovery mechanism uh to let these two browsers find each other um so they're typically which is why people kind of get confused about this because you need a server somewhere to kind of negotiate and send these signaling messages back and forth so that these two browsers can find each other um the cool thing about how that technology works however however, is it kind of attempts to discover where you are. And so if you have two users on the same network, in theory at least, it should be able to discover that they are in the same network. So when you do data transfer, those bits never leave the building.

So it's a pretty cool technology i mean it really enables a different set of applications to be built on the internet so all of a sudden doing skype in the browser is a viable thing um etc so that's kind of i don't know that's probably good of an overall summary as i can i can Awesome. Yeah, it looks like it has kind of, unfortunately, spotty browser support. The latest Chromes and Firefox and Opera all seem to support it, as well as Chrome for Android. But IE, Safari, Mobile Safari, and Opera Mini are all reds on the Can I Use charts. Yep. So what we're doing, I mean, so, well, first of all, that's changing as far as IE is concerned. What happened is Google basically – they created the WRTC standard for all practical purposes.

I mean there's other people involved. Don't get me wrong. But like they're kind of the ones that kind of pushed it along early on. Actually, that's not entirely accurate. Mozilla was pretty heavily involved from the beginning too. So scratch that from the record but um but the point is like you know they just kind of pushed it and shipped it right like they got it out there and uh it's great for small conversations if you want to do like any sort of type mesh network where every user is connected to everybody else, it's fine. But for the, what they realized is like in order to even build something like Google Hangouts using WebRTC,

once you get up to, you know, I would say more than four or five people, it stops making sense to have a total mesh network because now you have to upload your video stream to every single other person that you're talking to and pretty soon your bandwidth and your local just your computer just starts melting down just because it's working so hard right like it's got to encode and decode all this video about it it just it gets really crazy right um so if you're going to do any sort of larger conference scenario or any kind of broadcast scenario where you have one person sending to a larger audience where it's only going one direction, the kind of the peer connection objects that were added to Chrome's API, they kind of don't do that well. They don't handle that case yet well. So Microsoft, they wanted to implement WebRTC, but they're like, these are these problems that we have in order to be able to build these kinds of applications. And so they kind of came forward with an alternate spec, which, you know, you might make you roll your eyes at first, but they actually had really good reason to.

And so everybody's going to kind of jump over to that spec. And that's called ortc and that enables a lot more fine-grained control over the various pieces so instead of having this like one serves everything pure connection object you get all kinds of these more fine-grained control over you can do you know interesting network topologies to make more efficient use of the bandwidth that you do have and what have you. The server is still required though, right? Just for discovery, right?

So you can actually do – once you have a connection with somebody, you can actually drop the server entirely. So has Apple shown any interest in ORTC or they're still going to be i would say they're not going to do it till anyone makes them uh and you know because because let me think about it right like what incentive do they have i don't know because they have facetime they want you to use facetime yeah but microsoft has skype they want you to use skype and they want to build it in the browser so they're and they're being more progressive in my opinion now with that stuff um so the they and the ie team has committed to doing this so they will be doing it um in fact some folks on our team are working with them to make sure that uh that simplewebrtc

abstracts the differences so uh even when you know when they do show up and you know as long as you're using simple web rtc all of a sudden you just get ie support as well um whether that's you know or tc on one end and web rtc on the other the idea is that you know we're going to try to abstract all that stuff out so does does uh this may be an idiot question here but does simple WebRTC support both WebRTC and the ORTC? it will we have to change the name

Jerry we've talked about that before we talked about that with Daniel Stenberg as a matter of fact Libcurl and Curl had several names in its history as it evolved and supported different things we're not gonna change your own game is what i think he normally originally called it and then yeah started doing posts and puts and stuff he's like oh no let's put get those posts no i'm just

kidding it wasn't yeah but he changed the names several times i think i think it's still going to be web rtc and people are still going to refer to the technology as a whole as WebRTC. I don't think – I think that had enough traction. I mean there's entire like WebRTC expos. They're not going to rename them ORTC Expo. I think people will keep referring to the technology as WebRTC. We're going to keep calling the library Simple WebRTC, but it will just support both basically. So my guess is WebRTC was pretty complicated if it required a simplification library like your own.

Um, yeah, I mean, it's just, you know, when I was doing it, um, I hadn't seen anybody do multi-user WebRTC. Um, I'd only seen people do, you know, kind of peer to peer with a single connection. So all I really did was kind of abstract that out into, you know, where you peer to peer with a single connection. So all I really did was kind of abstract that out into, you know, where you could have multiple connections. And yeah, it used to be really messy because it was really poorly and inconsistently implemented, especially getting calls to work between Firefox and Chrome. When I first got that to work, I was like, I don't know, it was kind of, it was a celebratory moment, right?

Like, there was a bunch of stuff that was different between the two implementations. And then they were really moving targets as well because it kept changing. You know, since then, the library is now maintained by Philip Henke and Lance Stout on our team. I really haven't done much with it in the last, I don't know, year or so. But they've been able to, as browsers have gotten better, they've just gone and deleted big sections of code that are no longer needed because it's just standardized now, right? Yeah, so, yeah. It was messy, but it wasn't too bad.

I was kind of surprised that no one else had done it, at least that I was aware of at the time when I released it. So are there any cool projects out there built on Simple WebRTC that you have heard of? Yeah, there's, you know, CodeShare sites. I forget the name of the one I'm trying to think of where you can basically kind of do live coding together, kind of pairing over the web. There's cool stuff like that. Um, a bunch of people have come up and told me they built stuff with it.

Uh, there was one cool example, uh, was a student at Portland state university who hooked it up to, um, an electron microscope and electron scanning microscope. And use that to share their microscope with other universities. Um, so they did did because you can support support multiple videos um you know one of the videos would be the actual results

coming out of the the microscope and then the other would be the you know the person they're operating it so they could kind of work on stuff together even with a single microscope uh different parts of the country or what have you um so it's really cool stuff that people have kind of hacked together but i mean the thing that it does is like it makes the basic part so simple that you don't really have to know much about what webrtc does or how it works to use it um in the same way that socket io abstracted web sockets when it was really poorly implemented i mean it's the same idea that Socket.io abstracted WebSockets when it was really poorly implemented, I mean, it's the same idea here. It's like, you know, it just irons out the differences and gives you a dead simple API. As soon as you try to kind of break from that, it's not going to do everything you want it to.

But SimpleWebRTC itself, you know, given kind of our approach of building things as modular as we can, it's also comprised of a bunch of little WebRTC modules. So if you go to github.com slash otalk, there's all these little libraries that SimpleRTC just requires and uses that do various portions of this. We recently just gave the WebRTC name back to the Google folks on NPM because we had one. A portion of it was just that. How much do they pay you?

Oh, nothing. Just kidding. At least on the air, nothing. So Otalk is an Oron GitHub. What is this? This is different? Yeah, so the idea is like – so we built an app called Talkie, Talkie.io. Oh, so this is AndYet.

Okay. Yeah, this is all AndYet stuff. So what we did is – so Talkie.io was – it started out as my demo page for Simple WebRTC. I was just trying to get this thing to work with multi-user video. And then – so the way that it works is you go to talkio slash you know insert anything here and as long as someone else is at that same url at the same time they're in the same conversation like you don't have to download anything you don't have to sign up you don't have to register you don't have to be logged in it's completely anonymous um you know and it's encrypted peer-to-peer so it's like conceptually it's so much easier than

setting something like google Hangouts up. A lot of people futz around with invitations and all this stuff. So meet me at this URL at this time is something that people found really useful. And so we've seen hundreds of thousands of people start using this thing, and it's been kind of mind-blowing. What's the performance like on it oh it's it's quite good because i mean once again if you're doing this in smaller groups you can get really nice high quality video um and we said anything north and four before was where you start to get in danger zone yeah it starts to get bad so then what we've

done is um we've done a second version of this that actually uses a video bridge technology. And it's called a selective forwarding unit. But the idea is that it doesn't necessarily encode and decode video in the middle. But what it does is it can kind of combine things onto the same peer connection so that you can do larger groups. So we've, we've had, you know, successful calls with like 20 people using our beta version, which is at beta.talkie.io. And that's what we're doing. We're actually in the middle of a Kickstarter for that right now, trying to get some more funding to basically add like recording capabilities and some other fun stuff to that.

So definitely, you know, go check that out if you're interested in kind of open communication on the web so the other piece there is that all the pieces that we're using to build talkie are all individually open sourced and that's all the stuff that's there in the otak libraries okay i was just about to ask is what part of talkio is is open source or if any yeah yeah so i mean the the version that's live right now at talkio is using simplewebrtc the next version the one that beta.talkio is using all these various uh libraries that are there and the other cool thing about that is that it can interoperate. So it uses – it's a standard called XMPP for messaging underneath, which means that you can actually build an alternate service that will do – that you can actually call somebody at, you know, like a talkie service. Like you can call from one system to another system, which, you know, it would be kind of like being able to call from Skype to Google hangouts.

Right. So we need to see, I think that kind of open federated communication on the web. Um, these are things we've come to expect from phones for years. Yeah. The fact that I don't, Hey,

are you, I'm going to call you. Are you on Verizon or AT&T? You know, like that, that conversation doesn't happen because they federate. Uh, but we we're that's exactly what we're doing on the web right now so we want to kind of see that go away interesting well we like to close the the uh the call with some insightful deep impactful questions and uh so deep so deep and and the first question is who are you can have one or many

your programming heroes or one hero many heroes i i have i have a few i think it's hard to pick just one honestly um i don't know i've always been a fan of lauren uh britcher who uh who did like 2d and stuff he's a designer slash developer and he just like ships cool stuff like entirely on his own is a bit of a unicorn in that way. Uh, you know, I just, I'm blown away that somebody can do that at such a high level.

Um, she's certainly not a JavaScript guy, but, uh, that's always been like really impressive to me. you know, people like, like TJ Holloway holloway chuck who can

just like the amount of volume of high quality code that he's generated is just mind-blowing to me um i would list people like faras who i mentioned earlier uh doing some really amazing stuff uh really pushing the web forward um and even you like Guillermo Rauf, he created Talkadeo, but he's also done a bunch of awesome stuff since then. Anyway, there's a few to start. There you go. We'll get those links in the show notes. We always like to link up the heroes when we can.

Sometimes it's a Wikipedia page, sometimes it's a GitHub page. Some heroes are from the 1800s or early 1900s you know like you go back in the day the days of york to some you know to somebody who inspired the web you know yeah you know with a quote like uh jfk or something like that just nice you know i'm saying have we had jfk as a hero we have not. But Hendrick mentioned him in the talk, and that's why I was referencing. I did. You're right. You're pulling in a bunch of references.

Oh, man. I just dropped them in there. You don't even know. It's like four or five in the show you didn't even recognize. I didn't expect you to do research like this. We didn't do it. I'm caught off guard. We're going to have to have a commentary track on this.

Yeah, that would be cool. We appreciate our guests when they come on the show so so we have to we have to do that do our research man so since you're since you're such an edger a bleeding edger you've got to be looking at some very unique technologies and or projects so when you have a free weekend or you know and yet isn't making you work on the weekend which i'm sure they probably don't, but in case they do, if you had a free weekend and you can choose whatever, what project or what repo or what thing out there is sitting out there for you, like, waiting to go play with that's open source that you haven't done yet?

I keep meaning to get around to playing with React Native a little bit, just because it's kind of a cool idea. I got to throw in a mention for Surge too. Surge.sh. I just freaking love those guys. They've done some... They've made this dead simple deployment platform for just deploying static sites.

I just love that too. I've been using that for all kinds of little pet projects and stuff. Nice tagline. Zero BS. Yeah, exactly. So Brock Witten, who's one of the people behind that, he kind of helped do the whole PhoneGap thing.

So anyway, definitely a cool group of people there. Let's see. I don't know. I think it's really interesting to use like i want to see people do more like physics based stuff in the dom uh to get sort of these more interesting drag things around you know gravity and those kinds of effects used inside web applications so um i've seen people use things like D3 as kind of the math engine and then rendering things with React and kind of using that to, I don't know, to get some really interesting effects in terms of interaction effects. I don't know. There's a few things.

Cool. Jerry, do you want to take a closing question? Anything you got for Henrik? No, man. I'm over here on surge.sh. Is that right? You probably just deployed something, right? I may have. I don't even know.

This looks pretty awesome. It's kind of cool. I really like it. I mean, that's something I referenced. As a trainer, that's been really nice to have something like that because one of the first things I do in my workshops and stuff is like I have people deploy stuff. Because, you know, for so long, I think there's been this kind of barrier like, oh, I'm working on this thing. And then how do I actually get this live?

Oh, you call your ops person. And you're like, well, I don't have an ops person. Okay. You have hosting. Yeah, exactly. So it's like it's kind of nice to be like, hey, just get this out of the way. Uh, and so I made a little plug here too. I have, I have like a set of videos that basically show people how to build apps using ampersand react. And I use surge for that too. So, um, that stuff is that learn.humanjavascript.com. So there's some of that stuff in there too. And a good hour of that is completely free. So you can kind of poke around in there and see what you think and at least get your hands on this stuff. Good deal. Well, Henrik, it's definitely been awesome to have you on the call today.

I know that you span so many chasms. In the pre-call, Jared and I were planning for this call, as you can tell we do plan. We were thinking, can we get it all in one conversation? we have you back for for another you know would you be a i should do less things it's kind of annoying actually i'm trying to figure out how to do that simplify man you got to simplify yeah totally i keep preaching that and i need to do it in my own life can you can you read that do you know it off offhand you're uh what you say about that what oh the uh complexity thing um yeah oh shoot i can read it for you if you don't what yeah why don't you read it if you haven't all right so to maximize simplicity this is on the ampersand js uh website so if you don't actively fight for simplicity in

software complexity will win and it will suck exactly so. So that was telling Jared earlier. There's no maybe it will suck or probably it will. It will suck. It will. Complexity always wins, man. Keeping things simple. We're always about keeping things simple around here, man. We try. We try.

You know, it's hard. It's something you really do have to resist the urge to over-engineer everything. Creeps in. It's something I struggle with still. Well, to the listeners, thank you for listening. To Henrik, thank you so much for taking

some time to join us today to talk about everything you're interested in and your heroes. Thank you for having me. I really appreciate it.

It's a pleasure. It's been a pleasure to have you. Also, thanks to our three awesome sponsors for this show, CodeShip, TopTile, and DreamHost.

DreamHost has new VPS options they have us talking about, so check that out if you don't mind. DreamHost.com slash the changelog is the URL to go to. And with that, fellas, let's say goodbye. See you. All right, see you later. Outro Music