JavaScript in Latin America

Welcome to JS Party, where it’s a party every week with JavaScript. I’m Mikeal Rogers. We’ve also got Alex Sexton, and Rachel’s internet went out this week right before we were about to record, so luckily we were able to get a guest host in right away. Say hello, Juan Pablo Buritica.

Hello! Do I have to repeat my name, too? Hello, Juan Pablo Buritica.

There you go, yeah! [laughter]

How’s everyone?

Awesome!

Alright, so let’s just jump into it today. Because we’ve got you on, we’re taking the opportunity to talk about a topic that we wouldn’t have had the expertise to talk about if you weren’t on… We really wanna get into JavaScript in Latin America and what the whole scene looks like. Why don’t we start with you telling us a bit about yourself and how you got involved in JavaScript community stuff?

Sure. I am now an engineering manager, I live in New York City and I work for a company called Splice. It’s basically like GitHub for music producers, and that where we’re gonna leave it; it’s pretty cool.

In parallel, in my free time I’ve been very involved with the JavaScript communities for the past seven years, mostly in the spirit of paying open source forward. I never saw myself as someone who would have enough time to maintain open source software, so I chose to paint and create open source software communities, especially focused in Latin America where I saw there were a lot of holes and things that we could bridge. So that’s what I’ve been up to lately.

Juan, I have a question for you… Who has been to more conferences for JavaScript - you or me?

You have. I think you’ve been in Brazil, you’ve been in Uruguay, you’ve been in Argentina and you’ve been in Colombia, so you have the four – you’ve spoken at the four existing JavaScript conferences in Latin America. I’ve only been to Colombia.

Oh, really?

Yeah, that’s it. I’ve only been to Colombia. I meant to go to Argentina, I meant to go to Uruguay… I think I may end up going to Uruguay at the end of this year, and in Brazil I haven’t.

Well, now I feel like a jerk because I thought the answer was you, and I was trying to set you up, but now I just…

It’s okay. I’ve been to more JSConf Colombias than you.

That’s for sure.

So how did there get to be so many awesome JavaScript events in Latin America? I don’t know that every language community has that.

It’s been pretty cool… I think some of it started in parallel from different groups. The biggest challenges that we always have is it’s really hard to get access to high-quality content in Spanish. Before JSConf Colombia we started boa.conf, which was just a general software development conference in Latin America (in Colombia). Then there was StarTechConf in Chile, which was just general. I think we didn’t have enough density to only do JavaScript, but then a couple years later I think JSConf Argentina came up, because Guillermo talked to Chris Williams.

[03:56] I think it was actually the second even to pop up, or the third one, other than JSConf Europe. He hosted that one, it went pretty well, and then once we saw that there were enough people interested in JavaScript in Colombia - I think we had at the time probably six meetups, so it meant that we could at least try to get 300 people together, and we threw JSConf Columbia in 2013; that was the first one. Uruguay I think was born in the same year, if I’m not wrong, or maybe a year later. Brazil was probably around 2013 as well, or maybe even earlier.

I think it was 2013. It only lasted a year, but there was also BrazilJS, which was huge.

Yeah. I think Google has organized JSConference once or twice, and then BrazilJS was just gigantic. Brazil is like a continent on its own.

Yeah. I don’t know if it still maintains, but at the time it was the most people who had ever come together for a JavaScript conference that anyone could think of.

Yeah, they were aiming – I think they actually made the purpose of hosting the largest JavaScript conference in the world.

It was like 1,200 people, or something like that.

Yeah.

A handful.

So I think over the past five years, and even especially with the rise of Node, there’s a series of events that we have - I think four conferences. We tried to get some in Central America, but we’re still trying to figure that out, and also in Mexico, which is North America.

There’s a great amount of Node School events, also there’s NodeBots events… So there’s a lot of JavaScript interest. Just in Colombia I believe we have ten regional meetups, which is pretty big. It’s pretty cool to see it grow.

Yeah. We don’t even have that in Texas. We have three, four… Something like that. [laughter] Anyways… You mentioned something that I’m gonna spider off from; you mentioned that it’s hard to find content in Spanish… I’ve had these conversations a few times in a few different places, and one theme that comes up that is very interesting to me that I would not anticipate - I talked to some of the people from Platzi as well, which is a primarily Latin-American learning platform for code. People trust the courses that are in Spanish less than the ones that are in English.

The same person could give the same course in English and in Spanish, and people will listen to the one that’s in English because they assume that the content isn’t as good in Spanish. Is that still true?

It is true. We have a pretty heavy cultural problem in Latin America which is we don’t trust each other, because we tend to take a lot of advantage of each other, too. There’s a lot of sketchy content or refurbished content, or just not high-quality content. If you search for web tutorials or programming tutorials in Spanish, the majority of stuff that you’re gonna find is just very old, outdated content, because the bleeding edge is written in English. This probably happens across many cultures. Mariko and I have talked about this a lot.

The bleeding edge usually starts in English, and naming rights come from English. Then as you have people who are bilingual who have enough time to translate this content, then they’ll do so. But you end up also having a lot of people who are bilingual who start with introductory content, so they start translating that, and ultimately you end up with a lot of outdated introductory content. So it’s easier to just jump straight into English and just default into trusting English.

[07:51] I see. I guess why I brought that up is it feels like the conferences that you ran - JSConf Colombia, and I spoke at a few of those other ones, too - is the talks were half and half in Spanish and in English, depending on who gave the talk. Then there were translations there and Platzi I think does a good job of having actual good Spanish content; I don’t speak Spanish well enough to do that, but that’s what I’ve heard.

Is this changing? Is this something that is getting better? Obviously, I understand that if someone writes a new React library in English and writes the docs in English, you have to be able to speak English in order to get that information on day one… So it makes sense, but it seems almost critical that we reach people in the languages that they speak, at least on the long tail.

Access is definitely improving. I think that definitely Platzi has had a huge impact. I think the first JavaScript course I gave was on Platzi and that definitely had a really – I think it was Node, writing an API in Node… And it had a really broad audience.

One of my current engineers who is from El Salvador in L.A. saw my Platzi course before he worked at Splice, which is just mind-blowing.

There are several educational initiatives that are trying to get really good quality content in Spanish, and I really – I support Platzi especially because they’re already going after changing the way that people get educated in Latin America.

The other portion - a lot of the initiatives in Latin America are interesting… One of the things that we did in Colombia and I’m really proud of is that we’ve always aimed to highlight the local talent, and not make it a conference where international speakers come to talk to us. Overall, we usually have a portion of guest speakers - we always launch with three or four guests speakers that we invite, that we curate. Then there’s a portion of international speakers that we have slots open for the CFP, and then we have to have Colombian speakers - there has to be someone for Colombia speaking - and then we consider anyone Latin America as a local speaker, and then we do simultaneous interpretations for both Spanish speakers and English speakers.

There’s a really fun video of Alex’s talk in Colombia, I think we should share the link because it’s a really funny intro. But the aim has always been to connect, to bridge, and not to have the colonial approach of “Here we come to educate you.”

One of the founding principles of JSConf Colombia was that within the first five years we wanted to have one of our local attendees speak at an international event, and I think right now there’s three of them who’ve spoken, who are attendees from JSConf Colombia locals, who have spoken internationally. We’re really proud of that.

The Argentina group does really well these days too, at JSConfs and things like that, I see… I went there, and then at the next JSConf I was like, “Oh, I recognize all these people…” So I think that even outside of bringing stuff to these places, which is helpful and helps give people access to things that they may not have had access to prior, but I think they’re really good jumping off points for people in these communities to go out into the international scene. That’s really nifty.

Yeah.

I know a few people from the circuit that kind of started out in Argentina or Uruguay or Colombia…

Argentina and Uruguay… I think the culture of the Southern cone of America is very different from the tropical area, and Argentina and Uruguay - you can see there’s a lot of content produced in the Southern end of Latin America, much more than in the tropical region. I’m actually pretty jealous of a lot of the frontend stuff that comes from Argentina, because they’re really good at organizing and leading many things.

[12:12] You have Pony Foo… There’s a ton of React stuff, and of course, all the things that Guillermo Rauch does. It’s pretty cool.

What are the particular challenges of doing this kind of work in Latin America, community organizing in general? Because you’ve done a lot more than these conferences; you also do one of the largest JavaScript meetups in the world is in Colombia as well.

Yes… We’ve mostly tried - and I haven’t done this work myself, so I have to highlight my co-organizers, because I’m in New York and I don’t really do a lot of this stuff… But the objective has always been to give access and to include people who either are excluded because there’s not enough density in every tiny city to start a JavaScript meetup. You may have one JavaScript developer in a remote area in any country of Latin America, so we’ve started initiatives to increase access online; that’s the one that’s called Charla, which is like an online meetup. We’ve had three episodes of that one, and I can tell you a little bit about that later.

We have the local meetups, which is how we started. After the first conference we did in 2011 in Bogota, we started Bogota JS, which is now five years old. It started as the first JavaScript meetup in Colombia, and then we moved one year later to Medellin, and then we moved to Calle… We’ve tried to motivate people to start their own regional current.

We do something that’s called the Empanada Offer, which is I personally offer to sponsor the Empanadas of your first meetup; I will pay for the soda, I’ll help you find a venue, I’ll help you organize that, as long as you commit to have the event, and find the speakers and adopt a code of conduct. That worked really well.

We have 11 meetups in Colombia right now, and between Medellin and Bogota, which are always sort of like fighting at the top for membership, I believe we have 6,000 people in total between those two meetups. Right now, Medellin is larger - which I’m very proud of, because it’s younger - and it’s spread out… We’ve helped start a couple in Venezuela… In Central America I think I’ve talked to the Costa Rica guys… It’s been pretty cool.

Ultimately, the challenge is threefold. First, content - finding people who know a lot about JavaScript locally, who have had the experience to learn and then share it, is really hard. If you look at, for example, BrooklynJS or WaffleJS, or any of these meetups where every event is almost a conference, the quality of the content is just incredible, and then you look at the content that we generally have in Latin America - it’s more introductory.

So finding people who have been given a chance at work to try something really innovative or to do a lot of stuff is hard. I think we’ll have to continue to rely on international audiences for the majority of the innovative content. We’re producing some good stuff.

The other one is language - we try to fill during the events by having simultaneous interpretation and that sort of stuff, but it’s always just challenging. You can’t expect everyone to speak English; it varies a lot from country to country. I’ve also noticed it varies from community to community. I’ve helped the Ruby committee kickstart their conference in Colombia two years ago, and I think only 30% of the attendees required interpretation devices, wherein JavaScript around 60% of the attendees required English interpretation.

[16:10] I think the last one is resourcing. Local companies don’t sponsor; the majority of the money that we usually get is from international companies. The local companies expect something in return immediately, like “Okay, if I give you $100, then what am I gonna get? Can I speak for 30 minutes?” There’s a lot of cultural challenge there.

Finding a venue is super tough. I think Bogota still after five years doesn’t have a fixed venue; we’ve been trying to solve that. Even multinationals and the people who are evangelists for multinationals in Latin America have a very different culture perspective. I’m not gonna mention names, but a large software company in Colombia loaned us their auditorium, but then we found out after the fact that they wanted to do a 30-minute pitch of some of their services to our audience, in exchange of it. That’s something that we don’t really like. We appreciate the necessity of sponsorship, but there’s just some abusive practices that we’re not really fond of. So that’s sort of like the three angles that are hard.

That kind of stuff isn’t unheard of in the U.S. as well at meetups. There’s just so many companies that you can usually find some that are thinking a bit more long-term than that and aren’t trying to do something so sketchy. But I actually have been at U.S. meetups where they tried that kind of thing as well.

And sometimes as an organizer you ensure that doesn’t happen, and then suddenly someone’s giving a 20-minute pitch on your stage, and you have to figure out what to do.

Juan, is there an upcoming conference in Colombia?

There is. I think the event will happen in November - the 1st to the 4th November is the dates that we have the venue. We’re opening the CFP right now today. JSConf Colombia right now has three confirmed guests. We’re gonna have Tom Dale (I think some of you know him), we’re gonna have Suz Hinton (some of you know her as well) and we’re gonna have Elba Sánchez, who is a local Colombian rising star. She worked with me at my last company, and she’s been writing a ton of Node, and working with AI and bots and stuff, so we’re really happy to have her.

Then we’re looking for workshoppers and speakers. We pay for travel, we pay for accommodation, we pay for your significant other if you’re a new parent, and we’ll also arrange childcare as well… So it’s a pretty sweet deal. We’re hoping that at some point we will be able to pay speakers, but we’re not there yet; it’s a challenge.

The URL is cfp.jsconf.co. Please apply. I think it ends in June 11th or 12th. It’ll be a blind CFP, and I recuse myself from judging, because I know how some people write… But it’ll be pretty cool to have a broader audience. It’s been super fun to have people come to Colombia, because we’ve been generally isolated from the world, for some fame we’ve gotten ourselves into… But we’ve had some pretty fun times. I think, Alex, you had some good food…?

I had more than good food, but yeah… The food was very good. I really enjoyed JSConf Colombia. I haven’t had a bad experience at any of the conferences in South America or Latin America, so I would encourage everyone to go to all of them. You’re only kind of related… You started this a while back, and now it’s Catherine and Julian…?

[20:11] I’m coming back this year.

Oh, you’re coming back… So you returned.

I retired…

44, MJ.

Jenn Schiffer gave her last tech talk at JSConf Colombia 2014, and then I said that was the last conference that I was ever organizing (2015), but this year I just realize I miss it too much, and Catherine has also started spreading out to other events. Today, right now she’s actually at a ScaleConf, which is a distributed systems conference that she organized with a different team in Medellin.

So Julian and I are going to be co-directors this year. I think the goal for this year is to get three junior organizers, who will be able to inherit the relationships, the sponsorships, all the stuff that we’ve built, which is what has allowed us to do them, and do a really nice hand-off over for next year. That’s the plan.

Oh, man… I just realized, as we come up on a need for a break, that the three of us organized conferences; I think maybe in a future episode we could talk more about the organize part and less about – I think the Latin America conversation was much more interesting [laughter]… But the idea that you eventually get tired of running the conference and having a known successor that can do it with your for two years, who can inherit those relationships and cow paths, is such a good idea that I really wish I did, because if you all noticed, TXJS takes a year off here and there… [laughter] Just like JSConf US did, just like NodeConf does, and the HTMLConf, or whatever.

I think a hundred percent of us seem like we could have benefitted from that… So keep us up to date on how that works out.

I will, that’s the plan. I tried to do it last time, but there’s five main organizers and we wanna be actually conscious of passing it off and not just own everything, so… That’s a plan. I’ll keep you posted, definitely.

Awesome. Alright, we’re gonna take a break real quick, and when we come back we’re gonna talk a bit about all this JavaScript tooling that’s out there. Stay tuned.

Alright, let’s talk a little bit about tooling. Gina Trapani wrote a good article explaining modern JavaScript for ancient web developers, which I’m realizing I actually fall into the category of now… And I think you two too do as well, so this is probably not the best panel to talk about this… [laughter]

Speaking of tools, Mikeal… [laughter]

[24:03] That’s brutal…

…how do you feel about the explosion of them?

[laughs] Yeah…

I love tools.

Okay, so I’ll run a real thing that happened to me by you all, and you can tell me if you agree or not. I was curious about something that was going on in Yarn… In particular, we had this issue where we were thinking about adding an install step into Node Core for npm packages, then I went “Oh, Yarn wrote that, too… Let me go look at the Yarn code.” So I go into the Yarn code, and this is… It’s just a command line tool, and it uses Webpack, Babel, Flow and Gulp. And just getting into the code just a little bit, I was just kind of pushed back, and ended up just giving up because I was just like “I don’t wanna learn all these tools just to figure out what this code pack looks like.” Am I just like way too old now?

Yup.

Do I need to be put out to pasture? Is this the new reasonable thing to do?

I mean, you mentioned those tools like they all do the same thing, but they don’t.

They don’t, but it’s a command line utility. Are they really necessary?

Well, if you want to write code that is type checked, then you can; you don’t have to, but they chose to, because it’ll make their command line tool better for some reason for them. Then if you want to write in ES6 or whatever, and still work in older versions of Node, which is a requirement for them, then you have to compile, which is Babel, and then if you wanna watch that compilation or do anything like that, you can use Gulp and Webpack for separate parts of that.

I don’t see a problem… My favorite response to that is just like “It still works without all that stuff.” If you want to personally write all your scripts by hand, using only VARs and ES3 prototype methods, that also is compatible and you can do that. But forcing your idea of a baseline of tools on people seems arbitrary.

Okay, first of all I’ll argue a little bit with that notion that you can’t use modern JavaScript features and support older versions of Node… You should not be supporting 0.10 or 0.12. Those are literally not even getting security fixes anymore, so it’s detrimental to your community to support it.

Yeah, but that’s very idealist.

No, it’s not idealistic, it’s actually practical.

But for a company, it isn’t.

Especially if you’re a company. You are literally not going to get critical security fixed anymore. Like, that’s gone.

Right, but I’ll give you a real-time example. Elizabeth & Clarke - my wife’s company - has one engineer, and what he works on depends on the time, and I’d rather have him work on mission-critical business stuff than him catching up to date, because we’re literally a three-person company. So it sounds like we could do it, but unless – we can’t compare and expect or everyone who’s a developer to have the resourcing that Facebook or other large companies that have maintenance-dedicated teams to do this.

But this is a false dichotomy. If you’ve got some stuff up in 0.12 and you don’t wanna upgrade it, fine. But you’re also not gonna get the newest Yarn installer either. Like… No. You’re not gonna get the newest dependency and have that support these ancient versions. You either aren’t updating this at all anymore, or you’re updating it and you’re using a version that actually gets critical security fixes, period. I don’t think that those are like–

[27:59] If you put out a competitor to npm and npm has a set of version that it works on, and you don’t work on and you don’t work on those versions, then you instantly are at a disadvantage.

New versions of npm do not work with 0.12 and 0.10.

They do.

No, they don’t.

Terminal challenge.

No… New, new versions don’t work with 0.10 and 0.12.

Fine… But they did two weeks ago.

Do we have a live fact checker?

If they are still working with them, I’m gonna yell at Isaac tomorrow, that’s what I’ll do. I think that we honestly owe it to ourselves as a community to push people in the direction of actually being secure and not being open to huge security vulnerabilities, and part of that is pushing the off of 0.10 and 0.12.

I am aware of security vulnerability landscapes, but there is a different vector, there is a different amount of possibility of security problems when you’re talking about a build tool versus a runtime application. So if you only use Node as a build tool, which I think is a massive portion of the way people use Node…

Huge.

Yeah, like half or more, it feels like… The amount of security vulnerabilities that you have are vastly reduced, and the need to upgrade versions of Node on your Jenkins server is much lower than if you run Node in production, serving requests and things like that.

Well, that was a really bad example, because we’ve had to upgrade Jenkins because of Jenkins’ security vulnerabilities like twice a year, so… Yeah, sorry… You hit my sore spot with Jenkins, it’s awful… Awful, awful software!

Man, I feel like we’re about two levels off of the actual discussion here, though… So I’m not talking about upgrading Node…

Cause like because being a manager and having the chance to only write JavaScript in my free time, every time – I said I have a random side project, and I’m like “Okay, I’m gonna try out Flow.” I wanna learn a little bit about this type-checking stuff, because I think I’ve come to the point where I have to learn it, and I spent an entire Saturday setting my environment up, because there’s all dependencies that I had not been aware – there’s all this cargo cult that… Culture cargo – I have no idea what I’m saying… But I felt like I needed to know a lot about the state of the JavaScript community to even get a tool working. I felt – I don’t know if old, but incapable of writing certain stuff, and it was rough. So I think for the tooling perspective, it is becoming less new-people-friendly sometimes, I believe.

This is an interesting topic, because a lot of the people who advocate for these tools say that it’s actually lowering the barrier to entry. These tools add a bunch of value that makes programming easier, and another set of people (which I think we’re representing here) are saying “No, it’s a bigger barrier to entry because now you have to learn all this extra tooling.”

At no point in time does this tooling become entirely universal, right? Not even all frontend developers are using this exact toolchain; there are other competing toolchains out there, even for the frontend stuff.

I think there’s two discussions here. If you expose an API that you document, that has nothing to do with Webpack, Gulp, Flow or whatever else you mentioned, and you use those tools to build that library or API, then use a thousand tools if that’s what makes you productive and that’s what you wanna do, and then expose the correct things… Unless you’re writing a Webpack plugin.

[32:06] If you are leaking out those abstractions from outside, then I agree with you - you’re forcing people to learn it. But if you just wanna pull in a tool like Yarn, it’ll maybe build all that stuff, but to use Yarn, you just “npm install –global yarn”, and then you can use Yarn. It doesn’t matter that they use Flow, or anything like that.

That’s a really good distinction, actually. That is a really good distinction. I didn’t care about what Yarn was built in until I wanted to look at the code for some reason, which means that I’m not the normal user of that software. But to Juan’s point, when you wanted to go and use Flow, it wasn’t like you could just pull Flow down and start using Flow; he had to move his mindset into this, I’m assuming, Webpack mindset, because I haven’t’ actually used Flow, so I’m just assuming that it’s embedded into this other Webpack workflow… But I could be wrong.

I was trying to get it with Babel. I basically had an existing project that I wanted to bring in, but I was also using AVA, the test-runner, so it already had a config… It was just very weird. I finally got it to work, but then I was just not encouraged enough to actually try it out, so I just removed everything and I switched back to my regular branch and I just said, “You know what? This is not the time for me to learn static typing anymore.”

You literally got it set up to learn it, and you were like “I’m burned out now.” [laughs]

I was literally frustrated, because I could have spent my Saturday working on my bot, but I couldn’t.

You could… You chose to try to install something that was hard to install. Nothing forced you to try to use Flow.

My curiosity…

Sure, but it’s an experiment for a reason. Some experiments that you try are gonna fail, and that’s part of the deal, but I guess it’s an amortized cost. I agree that there’s some overhead to learning some of these tools, but if you spend the day (I guess that’s what it took you to be able to hook Babel and Flow)…

I’m exaggerating, but like four hours.

Yeah, I would give you more than that… It can be hard. I would definitely encourage any new developers to always use a starter kit for these types of things. Go find a React, Redux, Flow, Babel starter kit; that exists, you can go get it, you install it and you run it, and it immediately has all these things directly in it, with none of the configuration. Create React App has most of that stuff in it out of the gate. So get used to using it, and then once you need to customize it, then you can go into it.

You’re gonna tackle that problem slightly differently, 1) because you are a pretty experienced developer and you assume that you should be able to just pull something in and it’ll work pretty easily… But for new developers, I think there actually are quite a few tools that can make this instant and nice, without them learning how to set it up. But let’s say it even costs you a day to set up Babel and Flow, but how many days do you have to use Babel and Flow before that dividend is paid back to you? I would say it’s not that long.

Oh, right… Don’t get me wrong, the return on investment - it was attractive enough for me to spend a day trying to figure it out, because it’s an awesome thing. I think a lot of these tools have ultimately maybe a better developer, and not even having any formal computer science training, the fact that I got to a point where I valued static typing and type-checking because I thought it would be useful for my project is awesome.

[35:57] If I were writing code every day, it would have definitely paid off within a few hours. I do think that even as more open source projects start adopting all this tooling, they become less new contribution-friendly, and I think that’s the only problem I have with it.

Yeah, I agree. I think it should be a goal of any popular project, or of any project, but it becomes a higher priority goal of any popular project to have a “Run these exact things and we promise it will work and you don’t have to know about the build chain” and “Separate the concerns of building and authoring”, and things like that. Mikeal, you were talking about Yarn and doing all those things - those are parts of the build chain, but I can’t imagine that any algorithm Yarn is writing for dependency resolution is gonna have anything to do with the configuration of those tools, right?

I understand that in order to get it running on your machine, that kind of sucks, but the actual reading of the code shouldn’t have necessarily been affected, other than you might see some type definitions here or there. Does that make sense?

I feel like the “npm run configure” or whatever would be a really nice thing to maybe standardize or become more of a popular thing, to where it’s like a one-click install type of things. But honestly, it really feels like npm install does most of that already.

StandardJS does a very good job of this, right? You can run it as a command line thing, it just works; it just works in whatever linter that you’re plugging it into… If you have some giant toolchain, you just kind of plug it into one of those places. It doesn’t really have an opinion about how you integrate it into these workflows. It’s exposed in a really nice way.

I really like that one.

That’s Feross’, right?

Yeah. I wanted to come back to the thing you said about Create React App, and generally there is some kind of bootstrap Get Started thing. Every new framework and every new library, or every new big piece of software that comes out has one of these, and they tend to actually define the standard workflow. In fact, people that are really good React programmers that have built tons of apps with it and know it really well still use Create React App to start out.

There continues to be this argument, like every time that they put a new version of Create React App or something similar, people complain about the size of the dependencies that are included in it, and it ends up being this massive, massive dump of code… Which is always kind of hilarious to me, because I am one of those people that kind of care about that, but I also am not the kind of person that would use Create React App, so I’m wondering where is the overlap in these use cases exactly? [laughs]

So you just hate yourself…

No, no… I don’t complain about Create React App because I’m never gonna use Create React App, so I honestly don’t care… So I don’t understand the argument from that perspective, but we are getting to the point where these are getting huge. The baseline to set up is just enormous.

Yeah… I think actually the Ember community nailed this before more or less anyone else with EmberCLI. EmberCLI is one of the best… Like, I did Ember before EmberCLI, and I did Ember after EmberCLI, and baking in EmberCLI is like an officially supported thing; the docs for Ember have EmberCLI usage to where you don’t have to know how to create a new file because you can just Ember New up a new file and you can run the test through it and you can install things to it, and it can check extra things that npm doesn’t check, and you can do add-ons… The whole ecosystem can be built into this tool, and I think that far and beyond even Create React App, that ecosystem is one that people can instantly spin up and do with very little trouble until they wanna upgrade it, which is its own problem with those bootstrap things, because when you’re generating files it becomes very hard to then upgrade the runner of those files that generates new types. I mean, they have good strategies, but it’s a hard problem.

[40:13] I’m with you with that, because EmberCLI is to me the de facto example of how these tools should work… But what I respect from EmberCLI is that they have a vision; they had a vision and they implemented across add-ons, across templates… All that stuff just works. But I’ve had the opposite experience and I know that the Angular CLI is still an RC candidate, but I’ve come to the point where I expect so many things to actually be done by this, and it just doesn’t work. We’ve struggled a lot at Splice, even having people dedicated at just fixing some problems with getting some of this stuff working, because once you have to do AoT because if not you’re shipping a giant… Like, either you are doing tree-shaking or you wanna get a faster response time on your shipped build, it gets super frustrating. It’s one of those things that if it doesn’t work properly, then I’d rather just not have it at all.

Yeah, the Create React App eject stuff I think is a good idea for those situations, to where you always a way of just busting out of the thing; it writes the configuration files that you already have and then says “You can figure it out from here.” But that’s when updates become hard.

I think the thing that the Ember community accidentally really nailed is that the community bought into the tool, and since it’s officially supported, when you write an add-on or when you write a third-party thing, it’s your job to integrate it with EmberCLI rather than Create React App, which has to manage all of its own dependencies and say, “Alright, we’ll pull these in and update them as they come in.” And then if someone else is using Create React App and they wanna use a third-party library that isn’t compatible, then they have to bust out no matter what… So flipping irresponsibility of compatibility to the third-party author I think is a solid community idea. Also writing docs with it… Because it’s best for new developers, I think docs are critical here.

All the docs for React are still just “Open this file. Write jsx directly in it and try to run in this way or that way”, whereas the Ember docs say “npm install EmberCLI and then run these commands through EmberCLI”. So I would love the React community to switch the docs to default to Create React App if it became an official thing. There are problems with that and more considerations than me just saying that, but I think that’s a really nice initial experience.

On that bit of advice, we’re gonna take a quick break. When we come back we’re gonna get into the project of the week. Stay tuned.

Now we’re gonna get into the project of the week. Since Juan’s here, I wanted to continue to embarrass him and call him out a little bit… You wrote this great guide called The Collaboration Guide; it’s on your GitHub. I wanna feature this as the project of the week because it’s awesome. It’s literally just a guide to help people collaborate when they’re in remote teams, and I think these are problems that every company that ever does some amount of remote working runs into. This is really the bestest breakdown of like “Here’s a nice diagram for how to get a hold of somebody without annoying them.” It’s really good.

Thank you… Now I’m blushing over here.

[laughs] So why did you write this?

It came from the real struggle that we were having at Ride, basically seeing the rest of the company try to adapt to the fact that engineering was completely distributed just motivated me to make sure… So these guides had to purposes. First, telling engineering how I expected them to communicate and to collaborate, the default of our values, and then we shared this document to everyone else in the company, basically telling them “This is how we work, and if you need us, please adapt to this.” Because the constant interruption, the Slack channeling all the time, or the DMs… The missed expectations meant that I had to do a little bit more of a deactive management, but it came out really well.

A lot of it is, of course, inspired by the open source way of working, but it was mostly to just define the culture of how we communicated, and it turned out pretty good. I’ve applied the majority of this stuff at Splice now, and it’s worked really well. You’ll probably see me every now and then tweet about “Please don’t use ‘adhere’ all the time, don’t abuse it” because one of the most challenging things with distributed teams or hybrid teams is the constant interrupting, which is just like in an open office just being touched on the shoulder and like “Hey, can you look at this?” and you just break the entire flow. So that was the inspiration.

A few people have forked it, and actually I’ve seen some better or more thorough ones – I forgot the one… I think it’s LenaSun; she has a broader one that she did for her company. I’ll find the link and I’ll share it, but it was even more detailed than mine. It’s pretty cool to just bring that and open it up and see how people react to it.

When I hear people talk about having remote people and remote teams, they tend to bring it up in this context of like “Oh, you can just hire these really good people that are somewhere else”, and I’ve worked with a lot of companies that have done this and it hasn’t worked out very well when they have a few remote people, but they still have an office, or they’re still centralized in decision-making somewhere. Is your company laid out where all of engineering is distributed and that’s just the way that everybody works, or are there a few key people in the office?

At Splice right now we have an engineering office in Santa Monica, California, and that’s engineering only; that’s where the CTO is - the CTO and founder, Matt Aimonetti is there. We have two QA engineers, two backend engineers and Matt. Then the rest of engineering is distributed between Latin America and the U.S., and I am consciously and on purpose not hiring anyone in New York for engineering, to force the rest of the company to act distributed, because we do have the entire product team and the entire business team in New York, in office.

The reason why people think that being collocated is better is because we’re just lazy around communication and being around people; everyone ends up finding out about this stuff that’s going on in the company. But when you have one person out of the office and you’re actually remote, you have to do a conscious effort of keeping everyone in the loop.

[48:16] So I wanna keep that until we grow; right now we’re 12 engineers… Probably around 20-25 I’d be open to having people in the office, but it’s something that Matt and I are still trying to figure out, because we really like the distributed engineering culture and the vision of just letting people be adults and work on their time, work on their projects and so on.

If I ever - and of course I do wanna start adding more junior members - that will switch my approach, because then I’ll probably have to instill some really solid support structures for entry-level positions and that will require having people in office, or at least very available for them… That will probably switch things a little bit, but it’s a little bit too early to get together.

What are the key benefits of having a remote team? Do you think it adds a lot of more diligence in how you do communication and how you do the planning?

Can I jump in on that? Because I have a strong opinion. As a remote employee for a large Silicon Valley company…

That has a big office of engineers, right?

Yeah, a ton… So I wanted to talk to you about not hiring people in New York for a little bit - that may be an extreme case, or whatever, but that’s fine… Stripe I think has learned that you definitely don’t wanna have one engineer who is remote on a team if you can help it.

No.

It’s like a team of ten engineers, and one is remote - it’s almost always gonna be a bad situation.

Was that you for a while, though?

Oh yeah, for sure. We were only 40 people, it was gonna happen. But there’s some critical mass, and I think we actually have some percentage number - that I don’t know, so I’m not gonna say one - of a team needing to be remote before the whole team acts in a way that is helpful for all remotes. But there is this line that every company using in their hiring: “We wanna hire the best engineers in the world”, or “We have the best engineers in the world” or something like that, and I always find it very interesting whenever companies that say that only hire locally… Because it’s like “We hire the best engineers within a 15-mile radius of downtown Chicago, which we are now considering the world.” So I find it silly to think that everyone is gonna be collocated within a short distance from your office. The talent pool grows so…

Right, it’s math. It’s just math. I like the exposure to cultural diversity as well, and also remote work enables people like single parents who probably just have to be next to their kids all the time… There is just a very different approach to distributed teams that I like, and I philosophically prefer having the adult mindset in my teams, so people who are not just “Listen, you have to be here, and this is how you’re going to do your work. Here’s all the lunch, so please don’t…” - I don’t like having pampered, entitled people on my team, so I go with the other approach: “You’re an adult, this is your mission, this is your job. Tell me what you need to do it, and do it.” It’s much easier to do so from a distributed perspective, at least in my experience.

This is actually a really good point. The more that you can break up a workload into asynchronous steps, rather than this synchronous working mode, the more flexibility people have in their schedule and the more kinds of people that you can get. There’s a lot of people out there that just don’t have the schedule flexibility to do this kind of stuff.

[52:04] I’ve talked with the people from Free Code Camp about this, and how they’ve designed their learning curriculum so that you don’t have to sit down or go into a bootcamp to learn it. It’s really asynchronous, so that people who have kids, people that maybe already have jobs can follow up when they have time and it works with their schedule.

Big shocker, Mikeal’s advocating for an asynchronous, non-blocking I/O for learning… [laughter] Mark it on the board!

Oh my god… Yeah, and like me – if you’re working remotely, which I do, you should probably live in the most expensive place; that’s a good idea, so that’s what I do.

Like downtown Manhattan, like I do.

Yeah… Anyway, let’s move on to picks. Time for picks! Juan, do you have something for us?

I need five minutes. I am a procrastinator.

I’ll go first.

Alright, go for it.

I generally use maybe like a 1 mm pick, usually with like a grip, maybe like a good Dunlop… [laughter] My pick of this week is another specification, which is the CSS Grid specification. It recently went into production with Firefox 52, which was earlier this year (6-7th March). It was kind of the last desktop browser holdout for CSS Grid, so if you built grids with class names, like “the bootstrap grid” or “flexbox grid” or something like that, it’s a pretty different concept, but it roughly gets you a similar thing.

There are definitely the long tail of things that you could do with it that are very confusing, but the core use cases where you set up a grid, you literally just describe a grid in almost a grid format in the CSS, in order to explain the column and row layout that you want. So it’s really powerful, but also really approachable from the usability, the dev experience standpoint, and not just the power behind what you can do with it, and for that reason I think… Maybe don’t – I don’t know if you should use it yet, because if you support mobile at all (which you should) it will be difficult to get to work. You can have decent fallbacks in place, but then you have to write two things… Whatever. But look into it - CSS Grid specification is out there.

There’s an old CSS-Tricks article that’s pretty good on it, but there’s also GridByExample.com, which is based on a book that Rachel Andrew wrote, and there’s just a bunch of very simple examples of what the different parts of CSS Grid are and what the different words mean, which I assure you are much easier than the flexbox terminology, and then a bunch of code to learn how to do layout, and all that kind of stuff. Go check it out.

Cool. My pick is kind of interesting - Bcrypt… Ian, who works at Brave, put out this great tweet this week that was asking what people’s favorite security UI is, and what I said was I really like how browsers have started to move towards the default look of a page and the default UI elements around security have gotten more and more strict over time, and it’s been this gradual shift. So if you were using a web browser five years ago, you’d notice that there was a lot of fanfare added to SSL certificates, but if you weren’t using a certificate it looked sort of normal.

Now, if you’re not using SSL, it looks broken… It notes that this is just not a secure page, unless you’re using TLS. In that vein, all these same browser vendors have been amping up the requirements to get a lot of that extra fanfare and what that looks like, including starting to dig and investigate some of the security authorities. So SSL securities authorities were supposed to do a bunch of vetting of companies to get these upper-level certifications that make them look extra good…

[56:16] So not just the LetsEncrypt, like “Just get a certificate and encrypt stuff”, but actually websites that say that they are from a particular company. Literally, you’ll see the name of the company in the URL bar where the security information is.

Some of the certificate authorities have not been actually investigating those companies, not actually vetting those companies like they’re supposed to, including Symantec. And the more that they dug into Symantec, the more that they realized that something like 30,000 improper certificates were given out by Symantec… So what Google Chrome is planning to do is remove the trust certificate for Symantec, and they will not be considered a valid certificate authority anymore.

This is pretty unprecedented, for a major browser vendor to go after a certificate authority like this. And I actually expect Mozilla to fall in line, as well.

I think Mozilla has done it in the past as well with a few… There were the people who lost their private key or whatever – it’s happened before, but not on this scale, and Symantec is definitely a larger CA than others. If you don’t follow Tavis Ormandy, I think he is the one who finds a ton of this stuff with the different security companies, and LastPass and a bunch of stuff. His bug reports are always very impressive and very scary in how easily he constantly finds massive security vulnerabilities in security company things.

I want this dude’s job, that sounds super fun. [laughs]

It’s part of a… It has a name, like “Google something.” I can figure it out and put it in the show notes. There’s like a team whose job it is to just make security on the web better, so that’s literally his job, to go around and find security vulnerabilities in the web.

Nice. Staying on the Latin American team, I was playing around this weekend with NextJS, and I found it to be sort of a very refreshing way of making websites kind of the old school way, but with modern tooling, with React. NextJS is by ZEIT, I think… Guillermo and his team. It’s an isomorphic frontend framework; it’s React-based, but you can do some server-side stuff, so it’s pretty cool.

I was impressed with the way I was able to just get everything running. It’s extremely fast, although I do some CSS and some JavaScript code-splitting, which was impressive. If you wanna see it running right now, if you go to Zeit.co - that’s what they built to power that site, and then in the spirit of open source they published it. They’ve been moving really quickly, and the deployment also with Now is fantastic. So that’s my pick.

Yeah, I’m using Now, as well. Now is fantastic. And just a bit of background for people that aren’t aware. Guillermo also wrote Socket.IO, which kind of made websockets real-time usable in the early Node.js days… So a really long-time impressive figure in creating beautiful, easy to use JavaScript APIs.

Yeah, he also did JSConf Argentina. I went to JSConf Argentina and I was asking if anyone knew where Guillermo was, and they had no idea what I was saying. I remember that the double L in Argentina is pronounced differently…

Yeah, it’s pronounced differently.

They had literally no idea what I was saying. As a callback to my thing - Google’s Project Zero is the security team that I was talking about. But that might be all.

Yeah, that’s all the picks. Thanks for tuning in. If you have any suggestions for show topics for us to take on, you can head over to github.com/thechangelog/jsparty and log an issue or send a PR with great new topics for us to check out. We record live on Fridays, so you can listen to the live stream and pop into the Slack, as well. Rate us on iTunes to get the word out, and that’s all. Thanks everybody for showing up!

Thanks for having me too, and shoutout to Rachel and her internet.

[laughs] Can we get a sample from the board for Rachel? Can we get a cat hair sample…?

That’s amazing.

Brilliant! We live in the future! See y’all next week!