Switching Frameworks to Vue.js with David Rogers

We interview David Rogers (a.k.a Al-the-X) about his career path among the front-end frameworks and his latest roles for firms switching from Angular and Backbone to Vue. A very valuable discussion takes place about why both firms chose Vue.js against a "shootout" of Angular, React, Ember, and RxJS, and how aspects of Vue worked well for the switch.

Where to find David Rogers (Al The X) online

Full Transcript of Show

Megan Schemmel: Welcome to This Old App a podcast about learning, coding, smacking stuff together, breaking things apart, startups, failing, winning and any other buzzwords we can think of 

Don VanDemark: Hey Randy today we've got with us David Rogers. David is a senior software engineer with the Grove Collective and somebody I've known for many many a year so welcome.

David Rogers: Thanks for having me guys. 

Don VanDemark: Yeah, sure. So David, as I said David and I go go back aways and and it would be Folly to try and figure out how far back but but certainly back to the days when David used to live in Orlando now living in North Carolina, correct David, 

David Rogers: that's right. Just outside of Raleigh, North Carolina, and we're in Durham for for work these days.

Don VanDemark: Okay. Okay. So I used to we used to run the same circles David would run the local PHP meet up in addition to many others here in the Coding Dojo for a while and I'd pop my head in in those places every every once in a while mainly because David's a good communicator and a good teacher and whatever he's talking about something you're going to learn something. So and and he's a he's a good guy to hang around with to so that's why we invited them on today as well. So so David after after doing that for a few years David we actually worked together for about a year, correct?

David Rogers: That's right. That's right. Yeah, we're we're on the Kony rocket ship there for just a minute right rocket ship without without going to to into the details rocket ship could be the right explanation. So the right description depending on which rocket ship you're talking about. So.

David Rogers: Turns out whenever you set the backend of you on fire and try to anchor this cards. It's a risky proposition. Yes. 

Don VanDemark: But we had a good time David was leading the engineering effort for for the for the marketing side there and he brought he brought me in as long with a few others to try and steer it in the right direction. We did about as well steering as you can on a rocket ship. So it was good times for the most part. I'm glad I'm glad we had the time together. It was it was good times and it 

David Rogers: we both learned a lot. That's 

Randy Burgess: what was Kony explain to me. What Kony was other than a rocket ship. 

David Rogers: It was a rocket ship. Kony was is still is a enterprise-grade mobile application development platform. It was one of those right in one language and deploy to Native versions of iOS Android at the time Blackberry cuz Blackberry was still making their own OS the time. Yeah Windows phone was still around all that stuff. So they would they had an IDE. And you your developers would get access to the IDE and to their to their software you developers would build kind of a wireframe version of the app in their IDE. And then the IDE would build out native versions of the the app in Android and iOS, and so on and so forth. It was kind of like a business logic piece running in in JavaScript at the time kind of like Appcelerator, Titanium, or Xamarin. Yeah, we're at those types of solutions. 

Randy Burgess: So it's not so like now people are using React Native and Cordova and ionic and stuff like that. So that's what it was essentially doing.

David Rogers: Kind of sort of Ionic and and React Native. Yeah. They're your they're building taking JavaScript and actually transposing it directly into the native widgets. Kony's technology was slightly different in that it was mostly using JavaScript as glue between native components that they had built and you were you know, you can style a component, but they were they were doing the similar translation exercise.

Yeah, the time people were doing a lot of PhoneGap stuff. That was one of the targets that you know that we had as well as like if you want an HTML5 Phonegap wrapper as a initial as an initial goal than you know, push that button too. 

Don VanDemark: So but we both of us have moved on. So David is now as I said earlier senior software engineer at Grove Collective.

So David tell us a little bit about Grove Collective and what you're doing there. Yeah. 

David Rogers: Well Grove is, you know on on the surface an e-commerce company for eco-friendly home brands. We're worst that's again. Like I said the on the surface, right? We have a site you can sign up to the site and get your favorite eco-friendly Brands like Mrs. Meyers and Burt's Bees and Seventh Generation and those sort of things delivered to your home on a regular subscription. So it's kind of like a subscription first. But we also have our own Flagship products that we manufacture and they're also eco-friendly products. So we have a line of tree free paper products for the home toilet paper tissue paper paper towels that sort of thing that are made with no tree fiber at all the made from from harvested bamboo and upcycled sugarcane. That's one of our product. We have a bunch of other products that we also sell. We also manufacture and sell a lot of reusable vessels. We've got a laundry system that uses reusable vessels and low-impact organic plastics for the containers and non-petroleum animal not an animal-based detergents and that sort of thing.

So it's like the Save the Planet version of of all of your tides and and cascades and that sort of thing. So we have we have that side with the manufacturing side. We also distribute all of the products that we sell from the vendors that we Supply from. And we have the website that we Supply so we're kind of like a little baby Amazon.

That's how I describe it. We've got we're making their own products where warehousing her own products were fulfilling our own products were handling Custer's of customer support and we're selling them on a subscription instead of kind of like stapling them on after the fact because wouldn't you love to have a subscription every year for that for that heat pump that you just bought.

David Rogers: Sure. So so based on the news coming out today. I assume you all pay taxes as opposed to Amazon. 

Randy Burgess: There's New York care about you all as much as they care about Amazon. That's a question. Well, you know, that's the question really. 

David Rogers: We're actually really big in New York and several of the other large Metro areas, but we're really big out in the midwest.

A lot of art we found that a lot of our customers are in the suburbs in the midwest there. The products that we sell are not as readily available in those markets and people people love just not having to go to Target and pay the extra Target markup for the special products at Target and it's having them delivered to their house and Tristan.

So what what what go ahead. Randy laws are say 

Randy Burgess: What brought you to this company like what what were you doing before and what brought you to this new role? 

David Rogers: Yeah. Well before this I was working for the hot start up in Raleigh called Pendo. They're a very different business. That was a traditional software as a service business and it was kind of like the meta software-as-a-service.

It was software for a service for people who make software as a service so that they can make better software-as-a-service analytics platform. We  collect all of the user activity for their use for your users for example, and we would, we would display that in dashboards, but then you could also tag the features retroactively because we were collecting all the analytics all their activity all the time.

You could tag retroactive to analytics so you could pick up a feature that you didn't know was a feature or you might have you know, it turns out that someone changed the the path to that feature and you need to update that will you can actually update it both? So that you have both features the old feature and the new feature reporting on the same analytics and then beyond that you could you could set up messaging so you could do a pop a light box or do a walk-through or just put a tool tip in the right place for specific users based upon their analytics and their activity those big infrastructure that was lots of crazy stuff and very meta is definitely not something that's easy to explain to your grandmother.

Yeah. The reason that I the reason I shifted they identity and a half years at Pendo and I just started got an email from Angel list about a company that was looking to come to North Carolina looked up the company really liked what they what Grove was doing so just opened it down. Like let's just email this Chris guy and see what he's got to say and he hooks me up with Noah, who's the who's coming out to Raleigh who was coming out to Raleigh at the time to set up a second office for them. We hit it off really well and the opportunities that I had to to lead to help them work through a big Mike several big migrations the types of problems that they were dealing with the baby Amazon scale like the their growth curve where they had just had a huge uptick in users and an orders.

They were having to scale up to that like the problem seemed really interesting the culture seemed very appealing and it was something that I could explain to everyone. 

Randy Burgess: Yeah, it's always harder when you can't really tell people what you do, right? Because the in that in their mind it defeats what that you're doing anything, right?

So yeah, I've been I've been there before 

David Rogers: I tell most people most of the time that I have built the internet one tube at a time for many years. 

Randy Burgess: So you're at Kony and I'm assuming between Kony and Pendo what kind of work have your all the way through? You've been working with mobile kind of front end types of things.

I mean Don mentioned PHP earlier, but what's the trajectory of your technology you've been touching from Kony up to now what have you been focused on? 

David Rogers: Yeah, when I was at Kony was kind of an inflection point for me. I had been doing a lot more back-end development and full stack development and I mean like full stack from the point of writing the bash scripts that the boot the stupid thing.

All the way out to implementing the CSS, right? So I've been doing that for many years with with PHP with Python and Django with the many WordPress sites over the years. I got my start in Orlando Florida working for what became Purple Rock Scissors a big agency down there in downtown Orlando. I was their first lead developer and when I got to Kony, I was really interested in I was very intrigued by what was coming out of the front end development world. So Angular was pretty new and I wanted to try to experiment with that and they were nominally looking for someone to handle the marketing side of things but once I got in there I saw a big need for for a project that they were trying to launch to put there.

On-premises solution their standard on-premise Appliance into a cloud-based infrastructure and have a management portal and kind of have like a Heroku for Kony. Yeah, very appealing to me. So that was that was why I ended up coming on with them and that's also why I drug Jon and Curtis and first of guys into it with me because I knew I wasn't gonna be able to manage all of the marketing requests as well as build out this dashboard and the UI and the API for that.

So that's kind of the project that I worked on skunkworks while Don was helping me manage all of the marketing side and that got me my first foot in the door with Angular.js and some of the, you know, reactive View components back in towards that 2013-2014 done knows a long time 8 2012 maybe 2012.

Yeah, 2012-2013 that and just after that I ended up working I went back to freelance after working with Kony for about a year and a half and of working with Code School on their Shaping Up with Angular.Js course, so that was the release of angular 1.2 and Google was really hot about these new changes that they had made to the API that really confuse the heck out of everybody would have been using in front of that.

So Code School got a contract with Google to build out an angular course. But the only people they had on board that really new angular were the ones that were building their CEO their learning management system using Angular.js. They were all great teachers just at capacity. So I got a chance to work with Greg.

I wrote that course, I built all the slides I built the examples. I even got to direct Greg during the video shooting which was it time you kind of hear somebody giggling in the background a little bit. That was a mean trick. We had a great time with that course did some follow-up podcasts and video cast screencast with them on on some material, but that really launched me into full-time front end development.

I've done plenty of back-end work since then but getting into angular and then getting into react and getting into all the things that have come afterwards have kind of been from that that kicking off point at Kony and then the the Code School course and after that Greg introduced me to the folks at the Iron Yard who were launching a 12-week immersive boot camp for tree training folks into the software development.

I taught the front end for cohort therefore a year and a half well year in Orlando and then about a half a year up in Raleigh-Durham help them launch another campus. I was heavily involved with that. But you know, I was I was teaching JavaScript JavaScript JavaScript with a side of HTML and CSS only as needed for a year and a half.

I was I was fantastic. But and now I'm mostly mostly front end. That's kind of been my trajectories like yeah. You learn what you need to learn when you need to learn it. And if it turns out to be really fun. Maybe you get to stay with it. 

Randy Burgess: So then the last two jobs and I know the answer but I'm asking basically for the listeners. What have you been specifically doing with a front end with the last two positions? 

David Rogers: Yeah. So append. Oh it was an angular. They were on a very old version of they were still on angular 1.2 at the time that I came on back in 2016. And they had a pretty small lightweight understaffed front-end team.

But most of the business Logic for their application was built in the front-end back-end was kind of agnostic API was a custom query language kind of like MongoDB. Yeah aggregation pipeline just for specifically for the types of events that we were collecting for analytics purposes. So what I got to do there was help build out that team help build out the strategy for hiring and one of the first things that I implemented was pull requests and code reviews and formalizing that and then from the from the front end architecture standpoint.

We started upgrading to later vert later in later versions of angular. Yeah, made small jumps 1.2 1.3 to 1.4 to 1.5 to eventually 1.6. We started integrating some other tools and things but angular 1.2 at the time that we started making the upgrades from one point one point x. Angular already been end-of-life to write like that are ya the end of life on on angular and at the time, you know, it's like all open source projects like angular 1 point 4 will be the last release of angular and and the community outcries and strangely.

There's a 1 Point 1 Point 5 will be the last release of and you. 1.63 we swear we'll be the last release of angular 1.72. I pretty confident. We'll baby and the life of angular but you know, the writing was still on the wall, right? Google was not throwing its full weight at the end either 1.2 1.0 x project.

Yeah, we've done that angular 2 we were looking at what comes next for us. Are are we going to are we going to go with angular 2? How do we go to angular? How do we migrate to angular 2? Does anybody really want to migrate to angular 2 looked at some other options? We had done some teaching with Vue.

There were some other folks that were very excited about maybe using Vue we had folks that we've hired on that had lots of experience with React. So we kind of did a shootout between the three between Vue and React and Angular 2.0 and or two five seven nine whatever prime number we're releasing this week.

So we did that for we did that for like that I guess three months. We did a shoot out and try to figure out which one we wanted to go with and the okay. 

Randy Burgess: So can we talk about that? This is a this is what a lot of companies go through right now because the front-end framework business is just nothing but radical change. Yeah new features new ways of so when you did the shoot out how. We have a mix of developers that have egos and they like a certain thing. You have the companies like Google that what is Google going to do with angular? Are they going to fall on their face? Vue is brand-new at the time react is really strong with backed by a company that no one trusts necessarily so so like can you talk about the shootout?

How what you remember the strongest about it? Yeah. You came to a choice that kind of thing. 

David Rogers: Yeah, I think with so we had kind of had a powwow of the interested parties on the front-end team. And we had a discussion. We said the oh, these are the kind of the three strongest options. There were some Dark Horse candidates that were thrown in there like Riot JS.

There are people that just threw out answers that didn't even make sense. Like we could build this with RxJS. I am I. Yeah, I don't think that's what that is. There were some folks that were there were really hot for the new for the new angular for angular I/O there were some folks that were really hot for React that it done a lot of very pretty good work with React and there were some folks that had were interested in and had done some work with a Vue what kind of we picked one person from each one of those camps and and said go build the same thing in all three of these.

And Soup To Nuts total Green Field, but also, you know, like try to figure out how we would integrate this into what we're going to do. Now. What's what are some of the pros and cons? What are some of the things that we need to consider? What are some of the pieces of the ecosystem that we need to look at?

And we had several conversations over probably the you know, the course of three months really like we'd have these meetings every other week and people would make progress and report on their progress. People would show more or less work people would have these giant issues that they're working on in GitHub.

They would be adding comments to them and doing pull requests to code reviews with these with these proof of Concepts. We just kind of settled on we should go with Vue for these reasons that it was a closer syntax to angularjs. It was a another architectural and API improvement over what React had established there was less bike shedding and debate to be had about the ecosystem.

If you use Vue you use Vue router and you use VueX or you don't use VueX or you don't use Vue or Vue router there is not the bifurcation X multiplication of ecosystems that you see in React right where there's like seven different pretty decent answers to everything. Yeah. He's reacting to use Redux and we're going to see or maybe we're going to use MobX or maybe we're going to use our X.

We're just going to like shimmy RX into their somehow so that was a big deciding factor as well. Like there was a very clear set of tools that we would be using if we chose Vue and the syntax was designed to be very similar to angular and we could start refactoring. We already had we had a path that we could refactor towards these the these ES6 module type services that would work inside of angular inside of our existing code base, but then we could start reusing in whatever.

Whatever framework we chose. 

Randy Burgess: Did you get significant blowback from a either of the people voting for sticking with angular or the react side? 

David Rogers: Yeah. That's a good question. I think. The folks that were on the angular side the angular 2.0 tube to 7-9. Whatever it is. They came around on their own a little more.

They they did their proof of concept and they showed off their work and. Everyone who was looking at their work including them were like so this is kind of weird and this is kind of funky and this actually changed halfway through the proof of concept which only lasted a few weeks and this this API is completely deprecated now and.

The build system is changing and you know what? Let's just not do this. Yeah. It was just way too much flux inside of angular the angular 2.0 replacement and there was still this concept that if we went with angular 2, we weren't getting anything for choosing angular 2. We were going to be rewriting.

Almost everything in angular. Yeah late in the game angular the angular team announced that they were going to embed angular 1 .5 1 .6 in angular 2 as a backwards compatibility mode so that you could slowly migrate your stuff over and that just made everybody throw their hands up there like what so we'll get we'll get angular 2 and angular 1 at the same time.

But maybe not. Yeah, that was really we're going to rewrite it. Let's just rewrite it. Let's just figure out a way to rewrite it. Now. I want to stay on this path. I do want to ask one side bar question. Did you all look at Elm or Ember we did? Well, it was brought up right? Those are the dark horse candidate.

No one had any experience with Elm and most of the folks that we had on the team were struggling already with with rxjs. We had Incorporated rxjs and some of the functional programming that even RX implements was yeah, I'm probably going to be a little more than what these folks were used to and we want we did not want to have some like Central Elm Guru be the pert the bottleneck that everyone had to go through the documentation on The Big Three.

The the amount of that of resources out there for people to learn the Big 3 was much greater than any of the others and nobody really had a taste for Ember to be really honest. We looked at we looked at a number. Our API was not structured in a way that would make Ember data even useful for us and no one was really excited about basically rewriting all of the models in Ember.

Ember to me has always felt like the rails of JavaScript trying to be the rails of JavaScript totally which if you're a full stack developer, which I was for a long time, especially when remember was gaining popularity. It felt like you were rewriting everything twice, right? The dry principle is don't repeat yourself.

And then the wet principle is write everything twice. It felt very wet that I was having to write all these models in rails or Django or whatever on the backend and expose them being an API and then have to write the models again to find the exact same models again in the front end with Ember.

Even if I was doing something just ever so slightly different it still felt like I was just doing the same thing over again. Yeah. 

Don VanDemark: So that that that's what informed that's how you arrived at the decision at Pendo. How did you arrive at the decision to go with Vue as yeah, 

David Rogers: well, so that decision was was predates me a little bit.

They did a similar shootout situation, but they were coming from a much older code base. The the front-end code had been written in Backbone and Marionette which is Randy and I were joking about before the show. That's kind of like the beginning the dawn of time of front of ya for that is that it works properly phone 

Randy Burgess: Backbone changed the game. It's suddenly gave us a way to organize what had been jQuery spaghetti, right so long so it will and it had a kind of the outlet to finally bringing in data and managing data, right? So that was yet a strong knowledge oil of it. Yeah, exactly. 

David Rogers: You didn't have to go crazy. Why defined the I think that's where we're Amber got off the rails just a little bit is in background.

You didn't have to go crazy to finding all the properties of the of the resource that you are connecting to you. Just kind of gave it a URL and as long as it was a restful resource that returned Json properties backbone would figure it out. Marionette side added a lot of extensibility to views.

So like you're saying that before we had jQuery soup and all this event spaghetti all over the place trigger events on anything. There was no rhyme or reason to it and backbone at least gave us some clarity as to where the events go and how the handlers were set up and the marionette came along and said, well, let's extend that to the backbone views.

Not just the models. Let's come up with a convention for four views and routing. 

Randy Burgess: And to your point, I mean when you say that Ember was trying to be the rails when you look at who is building Ember is Yehuda Katz. I mean I have amazing respect for everything he's done in the open source world, but he he tried to take on everything and where you see the success of React and Vue has been they're starting small in like kind of.

Nailing the piece on presentation and State Management and then incorporating little reacts is kind of out sourced all the back end all the data layer. 

David Rogers: But I don't know GraphQL layer that that's that's also come out of that same Community. Right like the that it was another revolutionary but react was a revolutionary point of inflection.

A lot of people don't know that the jsx syntax that everybody loved to hate when react came out actually came from their PHP HTML subject PHX. They had a PHX. It didn't take off as well because you could already do pH do HTML in PHP and people really didn't see the value there, but then JSX came along and like a change the game substantially the whole idea of hyper script and I've got a declarative syntax to safely construct the DOM nodes and and to do so in an efficient and efficient manner that really changed the game, but you're right they don't they stop with that like this is what we do.

Is what we do. Yep, we render DOM. 

Randy Burgess: So we go to be totally side barred Don's question going back going back to Grove you went through the same process shorter process. Did you have arguments now of having gone through this before that? You could give the team like, how does that second shootout 

David Rogers: yeah, I wasn't I wasn't actually on for the second shootout, but I got to see the the after-effects and mostly the developers were just really hot on Vue. A lot of them had react experience. But even the react devs that were coming to the to the code base when they saw what Vue could do were just very impressed and also made a lot of sense like there for the same reasons that I heard the same reasons coming out of that shootout or read the same reasons coming out of that shoot out that had come out of the Pendo shootout. It was a syntax that was very familiar. It was It was kind of improving upon the best ideas from react and Redux and so on and so forth and there was a very clear ecosystem right like you we didn't have to go have more bike shedding conversations about whether we're going to use Redux or mob X or whatever. Yeah, we're going to use VueX and we can start to refactor our existing backbone services to look like Vuex services in advance of that. You know that there was a path forward to refactor right now and also would material materially improve our existing code base was a was a big boom. I think the thing that I was able to bring most to the Grove team or the thing that I have been able to bring most to to The Grove team because of that experience with pendo was how the heck are we going to do that refactor? How are we going to change? Yeah, I existing code base in such a way that it makes it easy to move to react to Vue and to Vue router and to Vuex. How are we going to integrate that into what we've got right now. What's the right cut over point at pendo? We tried both bottom up. So taking Leaf nodes and making those Vue components and bridging them with angular and top-down.

Let's take an entire page or entire route and convert that over to Vue components and see which one gives us the most value. At Grove, we don't have a lot of a lot of the reusable widgets. We don't have a lot of the widget depth that we did at pendo. So I feel like doing both doing the bottom-up approach and the top-down approach was valid.

It's totally not valid Grove. We in order to get off of angular as quickly as  angular get off on to view as quickly as possible and off of backbone. We're taking a let's when if we're going to touch this. Let's rewrite this whole route. It's only about 400 Pages 400 lines of HTML. It can't be that hard.

Randy Burgess: Yeah. Well, yeah, I mean you're talking about if you had angular working you had a framework. Which is still has value, but we are going from something like backbone,. Marionette green fielding things seems to be the most efficient way to go about it. So talk a little bit about testing. This is kind of a total, you know left turn.

But what is the testing story that you all use at both firms as you've employed Vue? Because that's one of the areas of the Vue side I haven't just heard as much chatter about I've heard much more about jest and react then I have anything else. So what do you all use for unit testing and integration testing end-to-end?

That's I'm kind of curious. 

David Rogers: Yeah at Pando we had we had tests written in in Jasmine originally. We were looking none of us were pretty really happy about the Jasmine suite. But if we had it and a lot of the tests were around the angular services. There weren't as many tests around the components in angular.

In fact, a lot of the a lot of the components are implemented as just giant controllers and I did a lot of refactoring and so did a lot of the folks that came on after me that a lot of refactoring to get those into testable Services instead of just one giant roller. Here it at Grove. They've been on Jest for a while because it is they were originally on Jasmine and they made the switch over just like just like pendo did just as kind of a know just what it's like a bunch of glue around several existing tools.

So yeah, it's using Jasmine's asserts its using all of its expectations, but it's running that around the the it and describe blocks the the suite and test level blocks are provided by Mocha. And then it has a its own little runner layer that the provides the file watching because mochas file watching has always been kind of subpar but given all of the node file watching has been a little flaky.

So they have their own file watching module that reruns the test that determines which tests should be rerun depending on which files were changed and that sort of thing. So they Groves been on Jest for a while and most of our tests in backbone and Mariette are all written in just because they were originally written Jasmine.

It was easy to switch that over to Jest. Yeah. I find the same problems in groves code base as I found in pendo's code-based like just too much assumption of too much responsibility and a single in a single place. In back on marionette there. It's a hundred lines worth of event handler on the route or on the top level view your like.

This is all business logic shouldn't go in here and it was a hundred four hundred lines of business logic stuck in a controller method instead of externally on a service. So we've been fully refactoring that code out to that both places we use some form of Selenium driver to do integration tests it to get those top-level tests and in both places, they kind of got light coverage in that regards those tests are generally harder to write but most valuable because they catch things that when written well they catch things that you wouldn't catch from unit tests or even.

Two or three component integration tests. Jimmy changed something in this service over here and it has an effect on the login screen. Why does it affect the login screen who knew that it was going to affect a login screen? I certainly can't keep all that complexity in my head, but just having the robot run through the login screen or the sign up form or the the checkout form can expose a lot of that.

Randy Burgess: Well where I think I mean testing was so easy on the back end. You deal with a request and response. I mean, that's a very straightforward way to like, what's the input going in? What are we getting out but then you move it to this front end world of event management and side effects and asynchronous calls and you just it's very hard to make unit tests connect and show you that whole the whole picture is working.

So yeah, it's it's a struggle that I've had as I moved to the front end. Getting that testing picture down and it's one of those things where you know, at least on the react side they say they have an idea about how they everyone should do it and then six months later we are changing that we're changing how we're talking about this.

So or you inherit a project that just doesn't do testing at all. Yeah, and that's happening to me anytime. 

David Rogers: That's definitely been in my career as well front-end back-end. It doesn't seem to matter. The the problems are still the same right like a rails code base with 400 lines and every controller method is just as brittle as an angular code base with 400 lines and every controller.

Randy Burgess: So on the side, so let's go back to both teams have made choices of switching from a existing framework to Vue. You have been an educator. You have taught boot camps people one-on-one. I'm sure you've mentored jr. devs in your role? How are you? How are these companies going about educating their teams?

Because I'm assuming you're not going out and finding tons of Vue developers everywhere because it's still kind of new relative to everything our world is working in. How are you ramping people up and stuff? 

David Rogers: That's a good question. I think pain. No did a really good job when we made the decision when we made the call that we were going to we're going to be moving to Vue we sent.

We sent representatives from each of our front-end development teams each one of the feature teams to VueConf. We have budget for folks to do to pay for continuing education on those things. You know, I had I have old relationship with Greg and Adam was our campus operations manager at the iron yard in Orlando, the two of them are doing view Mastery these days. So there are a lot of really good resources for folks to learn that stuff. We chose to go to Vue Conf to get the first-hand knowledge and also to like hold each other accountable through the code review process, right? Like what are the standards that we're going to uphold?

What are we going to look for? What are we going to. How are we going to address those? How are we going to talk about those to one another so that it doesn't seem like anyone person really knows everything. Right? We use the code review process particularly as a way of sharing knowledge. So if there was something that someone was doing.

Those bi-weekly meetings we would have there was something that someone was doing that was useful to the rest of the team. We would do a shared code review. Let's let's all talk about how this team solve this problem and inevitably the different feature teams would solve the same problem in two or three different ways a piece right and we would have to have that that.

Come to the table meeting and talk about how each team had done. It had done it. What were the pros and cons and how are we going to choose to do it as a team, you know who was going to refactor each of the other implementations. There was good that collaborative approach that we took their at pendo at.

After Grove, the team is much smaller. We have like 20 to 25 software Engineers most of them in San Francisco. I'm the only one in Raleigh at the moment, but we're growing team out here as well. And it's similar problem. Right? A lot of folks have experience with Django and have experience with angular or react or something like that, but not a lot of folks have experience with with Vue.js.

So leading lunch and learns trying to lead lunch and learns and doing presentations on best practices and opening pull requests and minimizing. The number of people who are actually working in the code at one point at a time. We've taken a much slower approach to our migration says we're doing a top-down migration.

We've changed our top level application object from the backbone object to a 4-pack for marionette job application to view. Have you component and we've been very meticulous about going through that. This is going to be the example that we're going to show everybody else. We need to make sure that we don't do too much in this conversion in this migration.

That confuses people because you're fixing all these problems. Why are you fixing does is this required we have to do this in order to view them? No, we don't but it we should probably do it. Anyway, we pulling those out and just into separate code reviews and two separate merged changes that can go in early.

And just focusing on this is the this is the right way to do this. Let's go ahead and start with the style guide. Right? Like the style guide says the top level like it's singular application should be called the component the header the footer the notification bar the app. Let's just go with that.

Let's just follow the rules as much as we can and then communicate to the rest of the team why we're following the rules why we're doing it this way, but everybody pile on and ask questions. Best I think like that's the best way for folks to learn right is to actually get in there and see how the code has changed in ingest that ask questions about it.

And if they try to deviate from it, let's let's go back to the style guide. Let's go back to the documentation. Let's figure out why this is the way it is. Why does the linter hate us for doing it?


Don VanDemark: So I want I want to dig a little at a passing comment you made and pull out your philosophy from it real quick get it will get away from from Vue for a minute. You talked about Grove. Most of the engineers are in San Francisco. You're the only one in Raleigh at the moment. Kony we were we were the same way where we have all the developers in the office.

So what what's the philosophy as far as hiring remote at Grove? Are you looking to put people in the office at Raleigh? And do you have a reason for for constraining and and I am using an opinionated word there constraining your job market your job availability in looking at that. Also. 

David Rogers: That's a great question is and I agree with you.

I think that anytime that you constrain yourself geographically you limit your choices and the availability of talent at and most of the places that I've worked, there's been a perception that local developers work better that having everybody together in a room works better. And certainly that's that can be a higher bandwidth than easier.

Method of communication right like have there's nothing that beats being face-to-face with another person or elbow to Elbow onto keyboards when we're pair programming. You don't have to deal with the AV issues with the latency issues. There was a there was a tweet a little while ago that always made me always makes me laugh the the most unbelievable part about the Star Trek universe was that every ship in the fleet had Flawless teleconferencing LED that always work.

It was destroyed static. So yeah, most of the companies that I've worked for have been local first and well, maybe allow you to be remote if you're really valuable or they're crazy constraints, but you better work really hard to communicate with everybody. That's a double-edged sword. Right? Like when we're all local there's immense opportunity for interruption from the people that I'm working next to for example since starting here Grove me and Noah we're the only ones in this office. We collaborate a lot. We communicate highly with one another but that also means that we don't have a lot of alone time if there's a if there's a there's a thing that comes up that affects this going to affect one or both of us or if there's an idea that occurs to one of us we just talked about.

That is in my opinion and in my experience a lazy approach to communication much more disciplined approach comes when I'm not in the room with someone all of the time and I feel like in order to be successful at remote employees in order to have a successful communication Network for remotes. You have to be remote first.

You have to choose that you're going to be remote because then you work out the problem hard problems first and don't get lazy with with on sites. And I think that even when you if your remote first and you're not remote only they're still becomes an us versus them the locals versus remotes because of that ease with which I can interrupt one of my neighbors.

And people don't realize how valuable it is to not be interrupted when you're doing this work. Yes. 

Don VanDemark: Absolutely, and I'll go one step further and and it's not just this work for the most part. It's any any work that requires concentration and continuity of thought just a completely non sequitur example, my my daughter works in translation.

And she works inside an office. So she's heads down translating something. Somebody comes up interrupts or and it breaks her flow and she's been trying to work with her company on getting them away from you know, getting them to where they can separate themselves from getting them to where maybe they can work from home some just so they can have that continuity of focus.

So it's absolutely part of it, but I want I want to poke at that a little because I knew I knew Kony was way it was and it sounded like Grove was was headed that direction and you're right even if your remote first, but you're not remote only you get a little bit of a localization, but it will it will come it will fail if it's not remote first.

You can you can make it work otherwise, but I mean if it's remote first, but you have some collocation but you have to start remote first, you have to build in all the process. I've I've managed remote for 20 years. So it's it is certainly something you have to you have to think about. So what not now we'll Circle back right?

I warned you ahead of time. This was a stream event the angular. I'm sorry not angular Vue versus react when we're talking about technology and when talking about languages and we're talking about anything anything anyone. Where you're comparing products you've got betamax versus that other than the run that other thing that actually turned out to be the thing we all use whatever is inferior product for VHF.

VHS right yet betamax versus VHS you have you have Rails vs. The World rails in the taking over the framework world for our little yeah, you've got react and Vuew where react is the more popular one for the moment for the moment. And and I hear you. I hear you you chiming up for the Vue side there.

So and that's why that's why I wanted to take this conversation is. Everyone that I've talked to very smart people because we've had Greg on as well. We had Greg on a while back if they've evaluated both and they've evaluate both reactant view fairly they end up coming out on the Vue and yet react is the more popular one at the moment right?

So do you see yourself screaming into the hurricane to where you're always going to be fighting that battle? Of of being the better one, but the less popular one. Does that matter? I mean I lived on the side of it of Drupal versus WordPress right where I did a lot of Drupal work where Drupal was probably the more powerful the more Enterprise E1.

But WordPress was the more popular items. So where do you see the future take in that battle going forward? 

David Rogers: Yeah. It's a yeah, that's a that's a head-scratcher there. I don't know. I put I've been I've had a pretty good career of picking the popular winner a little early like I tend to hang back and and not.

Grab cutting-edge bleeding edge anything near the edge it just you know claustrophobia and uh coughs well, I'm afraid of heights really I don't want to be I don't fall through so I I've been pretty good at picking the winning horse after the second lap. Yeah, that makes sense right like so sure in the PHP days.

It was Zend framework. Zend framework was not the most popular but it was the one that was shoved down. Everybody's throat. There were Alternatives at the time when Pete Wentz and was trying to shove it down. Everybody's throat that were more popular or less popular and eventually I think Symphony won, but at the times Zend was the right choice was the right choice and I eventually kick people towards Symphony, but before I left, For I left PHP for the most part where WordPress vs. Drupal right? I spoke it both WordCamp and Drupal Camp almost every year never really spoke much on either one of those two platforms something around the two platforms maybe development process or or particular tools that you could use in conjunction with the two of them. I did a lot more work in WordPress than I did in Drupal in the.

In the in the early days it was Backbone in this new angular kid that had come out and I picked angular and that turned out to be a pretty good choice until the next new kid came along right? I did a lot of work. I did some work with react and I while I enjoyed the work it felt a little too weird and it didn't feel like a step towards though the right answer the right answer being real web components.

There was a while there were people were comparing is angular the angular better than Polymer. No polymers polymers different. I think it is better but it's it's different. It's a different thing. I don't know. I'm always looking for what's going to take me closer to what I feel like is the best answer the answer that's going to go live in the browser.

Long term with the they answer this going to go live in this on the server long-term. What's going to get us there long-term and to me Vue feels that feels like that when you see features that Vue is pioneering that other Frameworks are emulating. That's a good indicator. He was also taken a lot of stuff from react as well like reacting now it's hooks.

If you had any quotation hooks within you know a couple weeks and they've always and 

Randy Burgess: they've never I mean that's kind of one of the endearing things about Vue is that because it's open source is always seems like Evan You as always kind of said, yes, I religiously take the best things from both angular and react and put them into the into Vue and I've always been like that's awesome like.

That's the whole point of open source is improvement across all the platforms. 

David Rogers: So I think I have a lot more a lot of respect for Evan on various levels one of which being he does weigh the best ideas, but he also doesn't jump on every idea. He's got a steady hand when it comes to how far the throttle is on view.

He said no to a lot of things that everyone's like why didn't you build that into the why don't you let other contributors and we would totally open pull request. He's like no. No, I think we think we should think we should go with this pace a real. I have a I have a family I want other people to have a family I want to spend time with my family also want to write this cool piece of software.

I don't think it's necessary for us to cram in every crazy feature idea or request we should have a carefully thought-out approach to how we're going to build this thing the recent slots refactor, right? That was like, oh maybe that's slots thing the thing that we tried to do with slots that one so smart.

This is smarter. Let's do this other smarter thing. 

Randy Burgess: Well, I mean we talked about right we've talked about rails and we talked and now we talked about Evan. DHH was of course the driver behind Rails and a lot of the success of that platform goes back to the way he kind of lead it and Evans a different personality, but that's what react lacks like you might put Dan Abramov in that category, but he truly doesn't make every decision.

He's just kind of a spokesperson. So it's view has the like angular. I couldn't tell you who the heck's in charge of it. But you know Vue goes back to Evan like it he is the he's the not he's not a dictator but he's definitely the the heart and soul of it all I would say. 

David Rogers: So yeah, it's it's the the Guido Rasam benevolent dictator for Life approach right like.

I'm not going to tell you what to do, but I will tell you what we're not going to do. Yeah, whereas DHH was definitely the is still definitely the this is what we are going to do is write the rails as Omakase speak to me like that summed it up thanks, DHH. We all get it Barefoot basically rails is what makes me happy.

But they're you know, you talked to some of the Rails folks and there's tons of stuff inside of rails that it got off the rails right like the whole turbolinks thing where you know, that was basically they're just so that basecamp can continue to exist and start incorporating front-end stuff and it's never made its way out like please just kill that that will you there's some really wacky stuff in the active support side of things where they monkey patch the string class.

There's a lot less of that in in View and I think to your point about Dan as the as the benevolent dictator for life for or the you know, they call him the prophet as the prophet of the react Community. He's still he stayed very hyper focused on react as react. As the virtual DOM rendering thing react end and let me just say focused on that and that has created the splintering of the rest of the ecosystem because you can't you can't have a framework.

That's just a rendering Library. 

Randy Burgess: Yeah, you always have to bring any other tools this it just doesn't work by itself. Right. 

Don VanDemark: So David, thank you for yes joining us today. That's this was a great discussion. Absolutely. I'm where where can where can our listeners find more about you more about Grove on the internet.

David Rogers: Yeah. Grove is a Grove.co That you can find more about them. They're they're good at marketing and I'm mostly known on the internet as "Al The X" as David Rogers is far too common a name and even if you look for David Rogers senior software engineer in Raleigh, North Carolina there you would not believe how many people we have interviewed whose names were. David kept joking. We're just going to create an office of David's. You cannot work here unless your name is David just just so we can keep track of all the people in North Carolina. There's just the David Crowd. So I go by Al D X online if you look for all the acts you only find me and there's you know, Google will do some bad things to the query but I'm on LinkedIn is LinkedIn Al the X.

I'm on Twitter as Al the X with underscores between the words. I'm on GitHub is Al the X with dashes between the words because gethub doesn't do underscores. They're not allowed in here and I'm on Al the X dot me with dashes between the words Al-the-X. Stop me. All right. Well again, thank you. I think it sounds like you've got a cough going on right now.

Don VanDemark: He's covering recovering from a flu. I had food poisoning on Tuesday. So we're all pushing through to try to get get a little relaxation. So, yeah, so, thanks again, Randy any any final words now, 

Randy Burgess: we'll just thank you this I. I talk to people all the time. Where what stack should we be using? What should we be?

Like, how do we keep up with all the this massive change on the front end and I really think that you have a valid experience with the change in switching and making the choice and that's really valuable. So thank you for coming on and I will. Just going to I'm going to presume that we will reach out to you again to talk to you more about this stuff because 

David Rogers: yeah, I'd love to tell you more about how we go how things go groans.


Don VanDemark: All right. Well, have a great weekend guys and we'll talk again soon. Talk to you later. Okay? 

Megan Schemmel: Thanks for listening to This Old App. Show notes and previous episodes can be found on our website at https://www.thisoldapp.online. Reviews on Apple iTunes are always appreciated and help promote the show. For questions comments or things you would like to hear on future shows, please email us at hello@thisoldapp.online.

Show music is Guns Blazing by Fab Claxton license by pond5. Voiceover work is by MeganVoices.com. You'll hear from us soon!

Join our newsletter

Got it. You're on the list!

This Old App is produced by the folks at CTO Think.

© 2018 This Old App. All Rights Reserved.