Ep. #21, Why GitLab Chose Vue.js

Brian Douglas: So welcome to another installment of JAMstack Radio. On the line we've got Ben Mischenko

Ben Mischenko: Hey. I am a developer at Netlify and I work on Netlify CMS, which is a great big React app, it's basically the editing side of Wordpress, without the rest of it. So you can use a static site generator with it.

Brian: Cool, and then on the other side of this call is Jacob Schatz.

Jacob Schatz: That's right, yeah. So I am one of the lead frontend developers at GitLab, and, I was the first frontend developer at GitLab. GitLab, if you don't know, it is a way to host Git on your own server. We also have gitlab.com, where you can store your own repositories for free, which is really great.

Brian: Cool, I didn't realize you were one of the first, and now you're a lead frontend engineer at GitLab. How long ago did the GitLab start?

Jacob: So GitLab started a while ago, we really started moving along in 2013 the product was split into GitLab CE and GitLab EE, and it was originally all free and opensource, but then, it split in around 2013. And in 2014, we were totally open, and we got some more seed funding, and all that stuff. I joined in the end of 2015 as the 29th employee.

Brian: Okay, that's still pretty early on. I know you guys are distributed, where are you at in the US?

Jacob: I'm in Washington DC, and, the rest of my team we have 17 frontend engineers, and the rest of them are all over. We have people in Turkey, in Lima, in Portugal, we have people all over the place.

Brian: And how big is the actual company as a whole now?

Jacob: The company as a whole I totally lost count. I believe we're over 200 people at this point. Or if we're not, we're very close to 200 people at this point.

Brian: Nice, yeah, I've heard of GitLab for a while. I have a GitLab account, I have one project on there. And it was always mentioned as the other thing that you can host your code on. But only within the last year I've actually used it on a regular basis and taken it seriously. So it's nice to see another place to actually host your code, which is awesome.

Jacob: Yeah, I originally had all my code on GitHub, and then I had it on Bitbucket because that was free. And then I started using GitLab just because the UI was so much better and I thought to myself, "Hey, this is an awesome product, I would love to work for them, and make this thing even better." So now I just keep everything on GitLab, just because for me it's a much better experience.

Brian: Yeah, nice, and then you can also complain to the person on the team that does not give you the right experience.

Jacob: Yeah, I can fix it myself because the code is in my hands, but also anybody else could fix it, too, because it's opensource which is, you know, the benefit of opensource.

Brian: I was going to ask that, too, so you work on I guess, is the CE the opensource side?

Jacob: Yeah, yeah.

Brian: I guess E is the Enterprise?

Jacob: So you have the CE version and you have the EE version, the CE and the EE are the same in the base, so the CE is the base of the EE. The EE has certain enterprise features that a lot of business customers like. We have some customers that have a tremendous amount of developers working on GitLab and that's more focused towards those people. But I work on both products, the CE and the EE. The frontend winds up doing the homepage and we style the blog, and all that stuff, so yeah we do everything.

Brian: Cool, and then the reason I had you on because I think you actually specifically wrote the blog post about you guys choosing Vue as your frontend framework. So I wanted to talk a little bit about that, but before we go into that, what did you guys use before Vue?

Jacob: So it's a really interesting thing. I came on as the first frontend engineer, and, when I came on, I kind of peeked through all the frontend code, and, it's Ruby developers who are really, really good at frontend stuff. But I would say that their focus is Rails. So they were doing everything in the Rails way. If you send on a form you say remote true, it'll automatically make a form like Ajaxy and stuff like that.

You know changing to sign-ease and all that stuff, it did it all with this Rails sort of Ajax way and they added in jQuery in there and they added in little jQuery snippets to make sense in the places it made sense. And what I immediately saw was like okay, we can continue to do this, this totally works, it was separated really nicely.

It was written beautifully, but if you want to scale and do really cool things like we're starting to do now you really need to get something a little meatier in there.

Brian: Yeah, and I think a lot of people around that time too, 2015 and a little bit prior, started making the experiment with actually adding other frameworks to their Rails code. I went through two companies between then and now who added new frameworks to their Rails code and kind of moved into the future of the web or the modern web which is like no longer shoving jQuery wherever you think it might fit. So it's cool to hear that. Talk to me about how you guys approached using Vue and why?

Jacob: So in the beginning like I said I was sitting there fixing bugs and you know we hired a couple other frontend engineers and it was like three or four of us and we were just sitting there fixing bugs like no big deal and we could have continued going on our merry way fixing bugs. So there was a lot of stuff to just clean up, there was a lot of stuff to fix. But I remember there's an issue page where you're like looking at a single issue and I wanted to make that page Ajax, where you close and it doesn't refresh the page.

I remember writing all of this tremendous amounts of code just to get the close button and open, which is you know, I've done that a million times, totally legit and me personally I've done tons of Angular, I've done tons of of React, and Vue had just started to be a really new thing I think it was still in beta when I joined and so it was like there's this painful thing and we can continue to do it or we can definitely improve.

Now keep in mind GitLab is a humongous project. There's that typical like junior developer thing where it's like I want to rewrite everything. And I'm sure that we've all done that at a point, you know you come in you're like, oh this code is so crappy.

But you don't realize there's all these decisions that were being made in the first place to get to this point. So you know it's not just a, let's stop everything and rewrite everything because we have to continue you know moving forward with what we're doing. So that's when I was like okay, so let's see what's even possible, it wasn't just like one day I was like Vue, you know it was a very long and you know, a big decision that we had to make.

Brian: Cool and I read a little bit of the blog post as well, but what Vue.js did, the actual API itself is really small, so did you guys approach it by just styling one thing in Vue at first and then kind of see how it looked at there? I know you mentioned the Issues page, is that your first foray into Vue?

Jacob: Yeah, so what we did is I actually did a complete different side project in Vue.

I took a big idea and I just made it in Vue and I made it as hard as possible too. Because you know there's that point where you think "what's going to happen when the rubber hits the road and you're getting into lots and lots of code?" So I think I took a month and just did a little side thing and you know it was a tremendous amount of code and realized "this thing scales really, really well."

There's like not a problem that I need to solve, you know you get to that point where you need to solve certain problems at scale and it was all already answered, it was clearly thought out. So that's what I did and then we took what is now the Trello like issue boards where you can have those issue boards that look like Trello. We just decided we'll just write that in Vue so that was our first thing that we wrote in Vue.

The main reason we did it was to like get rid of all of that spaghetti code because it's just like immediately you write Vue and it's like pop, you know the answer is like right there. It's really, really easy, the answer's right there, it's just like very simple.

So since then we just have just pointed at something, we're like that would be really cool. Now we don't rewrite everything, if it already works and we're not going to change anything and there's no reason to necessarily do it we won't rewrite it in Vue, we're not just rewriting in Vue for the heck of it. Because the jQuery code is tested, you know it's fully tested, it works, there's no reason to do that.

But for example we just made the issue titles and the issue description, real-time so that's a perfect opportunity to put it in Vue. We're now doing a lot of things in real-time so we're just like okay, do it in Vue.

But then you also have to say the backend has to be ready for Vue and they also have to be ready for real-time so getting to that point of like, can we do real-time and not just like real-time, we have like a ton of users, if all of them are, if we're going to do a pinging, are we going to do web-sockets, so all that had to be figured out first, before you just like say, let's do real-time and we DDoS the server or something like that.

Ben: Cool, one of the things you mentioned in the webcast that you did after the blog post was that kind of the way you've used it so far is that you have a bunch of little single-page apps instead of one big one. Has that kind of stayed that way as you guys have used it over the past few months?

Jacob:

So one of the really tricky things is taking the jQuery code and replacing it with Vue because right now the only way to really do it is an all-or-nothing approach. You can't replace some of the jQuery with some Vue, because Vue takes over a DOM element.

You say like, L is this DOM element. So you can't just say like, okay I'm going to pull out some jQuery and replace it with Vue. So if we're going to take like the merge request widget, we have to replace the entire freaking merge request widget, we can just replace some of it. So what we've been doing is we've actually made several, single-page applications within the page.

So several Vue elements within the page because like we pull out what we can, but other stuff we have to keep, but we have to keep the scope of our work really, really small so that's it's actually doable and this is something that we can really solve. So we just recently replaced the entire merge request widget which has I think 21 different states. A merge, it can be in conflict, it can be unable to be merged, and all these different things.

So that little tiny widget, you know, I think it took us three months just to replace the widget in Vue just because there was so many different states that you wind up having to figure out. Now what we also did is like the sidebar where you can change the assignee, change the time tracking, all that stuff, each one of those is a major feature. So you can't just like replace the whole sidebar in one fell swoop.

So what we wound up doing is each component in the sidebar is a Vue app right now. And then it won't be hard to just like make the whole sidebar one giant Vue app. So right now the assignees, which we made into multiple assignees, does it as a Vue app and the time-tracking is a Vue app, but the subscriber is still a jQuery thing because you've got to replace stuff with the time that you have you know.

Brian: Yeah.

Jacob: It works so let's not you know break it as much as we possibly can.

Brian: That's really interesting to because when you talked about the Juno developer problem you talked about oh, here's a hot new framework or hot new library, I need to use this for everything. Realistically you can't really halt development on a product that has like, probably at this point like millions of users. You have to continue to move forward so I think approaching it like separating like each one of these Vue apps into Vue apps.

I think it's more clear to have it in one way, I think you guys are kind of sold on Vue at the moment where one day you will be 100% Vue. I guess if that's the goal. So where are you guys at now as far as if you could put a percentage on how much jQuery code is out, or how much Vue compared to jQuery is there in that?

Jacob: So, it's kind of depressing to think but also at the same time it's also very exciting,

You could say, "okay we're going to replace everything with Vue at some point", but the truth is we probably won't and there isn't a good reason to do that.

And jQuery isn't like a bad tool. It's very, very good. This is the idea that like you should just remove jQuery as a dependency, but I don't know if you've ever tried to remove jQuery? Like all the browsers support it and we still support IE-11, but even if we didn't support IE-11 it's not that you can't do it it's just that it's a huge pain in the butt to do all those things.

So you'll wind up writing this little tiny library that does all these little things and then what you wind up doing is writing jQuery except you're not going to write it as good because jQuery's been around for a million years. So we're going to keep jQuery around. Now in terms of the percentages we rewrote a bunch of stuff in Vue. You know GitLab has a tremendous amount of features, it has like a ton of features and we're rolling out new features every month.

So all new features as they warrant it are written in Vue. And it's rare to find something that doesn't need to be written in vue.

But most things are written in Vue and then as we see we're taking something that if we want to make it real-time for example, we'll rewrite it in Vue. So I don't know a percentage, it's really hard to put a percentage on it but the issue boards, the merge request widget and now the next big thing is to take all the comments. Because the comments are now on real-time, editing them is in real-time.

We can actually make like, if you think of Reddit it seems like not a big deal, but they have 5,000 comments on a page. To have that many DOM elements on the page, if any event listener is attached to every single one of those, you know it's going to slow down the thing. So we can tremendously speed up the comments section just by adding Vue to that because of the virtual DOM and things like that. You know how do you get 5,000 comments on the page without the page like freezing and getting janky, it's a tricky thing.

Ben: That touches on something that it kind of seems like it's been a theme in what you guys have said and written about Vue so far. Which is that it really seems, a lot more than other frameworks, like it's designed to be able to coexist with those kind of older code bases. Do you feel like that's an advantage that's particular to Vue, versus other frontend frameworks?

Jacob: It is a huge advantage.

One of the main reasons I love Vue so much is it doesn't give a crap what you do. It's like "here's what you have to work with, take it or leave it."

It shows you how you can integrate jQuery, because a lot of people use Select2, which is a dropdown jQuery library, or Chosen or Selectize, those are the like really popular ones. You're not going to like suddenly replace all those things if you've been using them for a million years and you wrote all this custom stuff to make it like sort cities, or whatever you're doing.

So why would you suddenly replace that? That's silly, instead you can make it an actual Vue component so that it's easier to use those jQuery things because you're going to, you're going to use them. In real-life, you don't have the time and you don't need to spend the time to rewrite everything, it's just silly. So that's the great thing about Vue, it doesn't give a crap and it's going to help you continue to use the things that you're using. Not to say that you should keep bad code in there, if there's bad code, you know you should rewrite it. But it's just really fantastic in that way.

Brian: Cool, and how is Vue in comparison to like community wise? I know two years ago if you looked at the React community, they were pretty sparse and it was mainly more of like a Bay Area thing. But now that's way different, like how is the Vue community today? What do guys define help and stuff like that?

Jacob: Right, so if you look at what Edwin Yu wrote I think he wrote a Quora article, he said if you look at Silicon Valley companies alone you probably won't find any high profile Vue usage because those people tend to rally behind like Facebook and Google and things that are validated with Facebook and Google. And really when we adopted it it was relatively new.

But you could tell you know when I read through the source because you know of all the choices I was going through and making, I read through all the source code of everything, you know I read through the source code of React. I read through the source code of Mithril and I really loved Mithril. I was like "oh man, I wish we could use Mithril it's just it looks horrible to write, it just looks so horrible, but it's so fast."

You could really get like huge performance out of that, but you have to like balance this stuff. It has to like, you know if you're putting it in an opensource thing you want people to contribute. And so you know I wanted people to contribute to GitLab and it's like okay, so I have to have something that looks good in there. So you're not going to find a ton of people using it right now, although I think it's going to explode once people realize, "hey this is like really, really easy and this is just like, takes the grunt work out of a lot of things."

There's not a lot to learn, you can just like look at the Docs for two seconds and start writing stuff. There are bad ways to write Vue because it's so ambiguous in some ways, it's not super ambiguous, but in some ways it's ambiguous. So there are ways to write bad Vue code, but yet that's what we're trying to do. We're now we're paving the way for us at least, and if other people want to follow, like what is good Vue code?

What is the standard of Vue code? So if you look at our Docs we have documentation on how to write Vue. We didn't make it a GitHub thing, like Airbnb wrote their JavaScript style guide. We didn't do it like that, but we're writing style guides and we've written style guides on Vue and what's the best way to write Vue. Don't do this, do this, and here's why. And every time we get burned, we're just like okay, write it in the documentation.

Brian: Where's that documentation at?

Jacob: If you look in the GitLab Docs under the JavaScript stuff, on the frontend stuff you'll see it, there's a whole section on Vue. And one of our biggest things is to document everything. So our documentation is huge and it's, you know we try and be as complete as possible so that's in one of those regards. Because

New frontend devs will come in and they'll be like, "okay, Vue, I've written Vue before and then they'll just something completely different." We want all of our Vue code to look the same, like it's like one person wrote it.

Ben: The project I work on is really focused on opensource contributions and one of the difficulties I've noticed with using React has been that you kind of have to work pretty hard to keep your tooling in check. And make sure you know it's going fast and everything's working the way it's supposed to. So I kind of wonder if Vue's approachability and that's particularly bad with the tooling, it can be really hard for, especially people who are new to JavaScript to get into it because there's a huge amount of front-loaded work to start using React the way you're supposed to use it.

And it kind of seems like Vue's approachability might do a lot to make up for what might be a smaller community by being more approachable to bring somebody new into the code base. Have you seen affect your opensource contributions at all, the level of activity there?

Jacob: Yeah, so in terms of React's approachability and Vue's approachability, React's gotten so much better. I remember I started using it like when it was first announced, like the beginning and I was like, "what is this?" Because in the beginning it was really hard.

You're like "what do you do with this, what is it for?" But now it's really easy, but it does have, it has a curve, it has a learning curve to it and Vue's learning curve is less, in my opinion. I'll tell you something that's really funny, which is just like hilarious is that especially in the very beginning when we first announced the Vue stuff and we decided on it, I wrote the article and that was great.

Every, I'd say it was like once a month or so, a contributor would write a huge contribution and it would all be in React. And there you see in the railsapplication.js they just added that one line that adds React in there. Like you can't, we're not using React right now. I mean I love React, it's wonderful but we're just not using it. We're not going to have Vue and React in here and every once in a while someone would just try and sneak in React in there, which is just really funny.

And we thought, of course, it's like okay, I'm sorry we really have to reject all this wonderful code you wrote because they wrote the whole thing in React, thousands of lines and all that stuff. So that's the thing, there is a lot of tooling around Vue. One of the things that people are learning about more is the testing, the testing is a little, it's not that it's tricky it's just that it's not as well known how to properly test Vue.

So that's something that we've done a deep-dive into and you know you have Vue-ettes, and you have Vue router and all this stuff. But

I found that you really don't need a whole lot just to make Vue work. You can just use Vue on its own and if you follow the Docs it has guidelines on how to make a huge app and it's very productive in that way.

Brian: As far as Vue, and I know Vue Conf is coming up and by the episode comes out it will actually be after Vue Conf so if you missed that you should definitely check out the videos, because I'm pretty sure the videos would be out by the time this podcast comes out. But are there any other companies that have bitten the bullet, I don't know if that's the right term, but taken the chance on Vue that you know of?

Jacob: I've talked to a couple, so I've been talking with a guy from Codeship who has like by himself taken Vue on as a major thing and he looked at like, this is how we're going to test it. This is how we're going to do this. And so I've been talking with him, his name is Roman Kuba, he is going to be speaking at the Vue Conference along with me. So I know that there's a couple other companies that have taken it on, but its relatively small at this point.

It's been like the best decision, like it's never been a sticking point. It's never been a pain-point, it's always been like a very productive point in our structure, even though it's still a small thing and even though not everybody's using it. You know sometimes you just have to be backed by Google or Facebook and then everybody's like, " oh my gosh, it must be amazing." You know but it's still just been absolutely fantastic.

Brian: As far as like hiring and onboarding, do you guys, because you've been a couple months and I'm sure you've hired somebody since on the frontend team, possibly? How is there, I guess, getting up to speed with Vue?

Jacob: Yes, most of the people we hire don't necessarily know Vue but as long as they know, a lot of them know React and still use React. It's good to just know kind of a cornucopia of different frontend frameworks. As long as you get the gist of like frontend frameworks in general, Vue is not very hard. Now they all get Vue, sometimes it's harder to get everybody to write Vue in the same way to make sure that we're all making the same decisions, that's a little trickier.

We've written linters for that because we have tests that runs every time you make a merge request. We have linters that stop people from writing certain code so your test will actually fail, which is really great when you're trying to get people to write everything in the same way. Within GitLab, within the frontend team we have a couple of people that we've designated as the Vue team that help decide on all things Vue.

Because there are decisions that you can make, there's decisions to be made. So we have about three or four people that write the Vue documentation and make the Vue choices and if it's someone's first time with Vue then we make sure that for the first week every day they meet and they say, "What's your direction you're going?" because you can go in any direction, you can just really take off with Vue.

And so we just want to make sure that in that first week of coding that they're constantly on track. They go this way, we push them this way, if they go this way, you know just keep them on that line of the direction that we want them to go and it's not that their code is bad or good, it's just that we want to keep it going in that same direction. So we have people that are kind of holding hands and making sure, and then after a couple of weeks they get it and they just like take off and they go in that direction every time.

Brian: Cool, and Ben did you have any followup questions?

Ben: Yeah, I was just curious, was there any thing that you really found more difficult with Vue? You know just stuff that was, felt like it should be different?

Jacob: No. I think that the testing is just really tricky because to do the testing you have to know more of the internals and you can't just read like the gist of the document you really have to get the internals down a lot better. I think that will improve over time. I know that there's some work to get Vue in line with GraphQL and stuff like that, because people are going to start using GraphQL a lot more.

I know we're going to at least be checking it out so the question is how does Vue work with GraphQL? You know React is made with relay, they're like made to work that way so it's like kind of an automatic plugin thing. So things like that are a little trickier but everything else has just been you know very copasetic.

Brian: Yeah, actually just before this call earlier today I was actually messing around with learnapollo.org they have a Vue.js example. Now every other example has like a step-by-step how to build it. The Vue example is just an app you can look at with the code so one is super simplistic and so it definitely could use some Prs on there as opensource project for how to use Vue with GraphQL. But I was actually tinkering with that, because I'm pretty heavy into GraphQL at the moment.

Jacob: Yeah, that's the cool thing. It's like when Swift came out, I remember the first day that Swift came out, I was like "okay, how do I do this?" I start looking on Stack Overflow and I'm like "wait, there's nothing to look at it just came out today." There was nothing there of course and then the questions started coming in, but honestly this is like so much simpler because it's like the answers are there.

And if you read the documentation like most of what you need to know is there. I would say just the testing stuff is a little trickier. But also it's cool because you know we get to pave the way and say "this is how we're going to do it and we'll make a good decision." We have a lot of really good, really excellent frontend engineers and they get the gist, they get the big picture and we can kind of pave the way for Vue in that way.

Brian: Cool, well Jacob, thanks for coming on and talking about Vue and GitLab and getting everybody up to speed about what you guys have been doing since that blog post came out. I'm going to transition us into Picks, so these are Jam-Picks, anything you've been jamming on, that gets you going. It could be code related, food, entertainment, what have you. So since I am the host I will go first and give you guys a chance to get up your links and refresh yourselves.

But my first pick is the Bay Area Discovery Museum. So I'm in the Bay Area, I don't know if I told you that, Jacob before hand, but here in Oakland, California and I have a small child and there's actually this Discovery Museum, it's basically a children's museum and it's really awesome. There's like, right underneath the Golden Gate Bridge it's like where all the, not Fort Baker, it's the other side of the bridge but there's a fort where there's housing and they've converted some of that into an actual museum, where you have a lot of like hands-on stuff.

You have like art projects and they have a Daniel Tiger exhibit that's going till September, which is pretty awesome and my son's a huge fan. I highly recommend if you are in the Bay Area check that out, it's kind of pricey, even for Bay Area residents, it's like 20 bucks for adults and like 13 for kids. But they do have a yearly membership where you can just pay a lot more money and just go for like unlimited amount of times.

But definitely check that out. My second pick is outside, I just want to remember we were talking about code today, but remember everybody to go outside. We've had some really good weather here in the Bay Area last week and the week before, so don't forget to get your vitamin D and do something outside. And then finally the Serverless Docs in Gitter I just want pick that and shout that out.

Episode four of this podcast did David from Serverless talked about Serverless here which is the framework to do Lambda and Azure and OpenWhisk functions as a service. I finally got into the app I talked about which is the app to tell you when there's a home baseball game to avoid public transportation. I kind of mentioned it, that I built it every year, every baseball season.

So essentially I just need to know when there's a baseball game so I can just avoid the city those days. I finally got around to building that app and started using Serverless to do it and needed the documentation and stuff like that on the Gitter Channel, so they're super helpful on there if you have questions about DynamoDB or Lambda or even like Azure and Openwhisk. People are always around to chat about Serverless stuff, so check that out if you haven't done that yet. And Jacob, did you have any picks for us?

Jacob: Yeah, so I love to explore all the new languages that are out there and I want to make sure I learn them all, so lately I've been taking a look at Kotlin, Is that how you pronounce it? It's one of these words I've never heard pronounced?

Brian: Yeah, I've heard Cot-land as well, I haven't heard it spoken like in real-life.

Jacob: Right, I've only seen it written, right exactly. So I've been taking a look at that, even though I've always wanted to write Java without Java, so anything that compiles to the JVM, I've been taking a look at that.

Brian: Yeah, I think you're not alone, with all the other JVM languages out there.

Jacob: Right, clearly there's a need that needs to be filled there. So that's one of the languages I've been looking at recently, and just taking a deep dive into that and the cool stuff that you can do with the web and there's this spark, Java Spark, not the Apache Spark, micro- frameworks that it has, so I've been taking a look at that. And it's really, really neat and the language itself is fantastic.

Unfortunately I think you still need to know Java pretty well, like you need to know that whole Java ecosystem to get started on that, unfortunately. And then the other thing, I'm a big environmentalist myself and I like to make sure that I'm not polluting so I'm always trying to find ways that I can like not use my car. So I've been trying to learn as much electrical engineering as I possibly can.

So I learned how to solder and I've been learning how to weld, I got a big, MIG welding machine, so I made my first electric skateboard and I've been using that to try and commute around on that. It gets, on each charge, it gets about 12 miles which is pretty good, so that's 12 miles that I don't have to drive in a car and you get the fresh wind in your face and all that stuff so that's been really great.

Brian: Wait, did you find plans somewhere, how to build this?

Jacob: No, I just kind of went for it, I wound up using like the battery pack was just sitting, Velcro'd on the bottom of the board so I got a Tupperware and I stapled the Tupperware to the bottom of the board, you know some of it was a little rough around the edges but the rest of it was really great. So I'll have to see if I can put some plans together about how to do that. So now I'm on my next version of the skateboard which it's using these big, 12 inch pneumatic tires, so it rides like a Cadillac, it's so smooth. It's amazing.

Brian: Wow, I'm sure you get a lot of like, second looks.

Jacob: Oh yeah, definitely a lot of looks.

Brian: If you get it around to do on a blog post or Tweet that out, I'd love to see a pictures of that.

Jacob: I feel like every programmer should learn electrical engineering, it's like that other thing that we probably don't know how to do. So that's it for me.

Brian: Cool and then Ben, do you have some picks for us?

Ben: Yeah, so first I'm going to plug my absolute favorite radio station of all time, it's a local Portland Jazz station. If you're in Portland it's 89.1 FM and if you're not, you can listen to it online, which I do pretty much 24/7, at opb.org/kmhd. It's pretty much the best. And the other thing was Node v8 came out today and there's a really cool addition which is util.promisify.

Basically if you're somebody like me who writes a lot of Node scripts without any pre-processing you'd had to import a dependency in order to get promises in Node Standard Library. Well, util.promisify will just take any of the Node standard library or anything that takes callbacks and just promisify the whole library. So you don't have to use dependencies for that anymore which I'm really excited about.

Brian: Cool, yeah I was actually coding yesterday trying to find out about Node 8 and if it was coming out because I wanted to make sure I was using the latest and greatest and I was like, "I saw a Tweet, like it's coming soon." But it wasn't out, so it's good to hear, I didn't see that come through the wire yet.

Well guys, thanks for coming on, talking about Vue and GitLab and just jammin' out with me. Jacob, hopefully I'll see you around, I'm looking forward to seeing your talk and then Ben, again, thanks again and keep spreading the jam.