You can listen to the podcast and read the show notes here
Michaela Light: Welcome back to the show, I'm here with John Farrar, and he is an active community member in the ColdFusion community, and he focuses o a strategy that will bring impact without getting delayed over engineering. We're going to talk a bit about that more later. He's giving a talk called Vue More With Less. Which I think there's a pun in there, because Vue is a JavaScript library. We're going to be covering what is Vue.js, for those folks who haven't figured that out yet, and how he used to avoid JavaScript, and how it advanced ColdFusion, because he did that. Why he moved beyond jQuery, what problems do the various JS frameworks solve, and how you should pick a framework. Hint there, it's not just a popularity contest guys.
The interesting story of how JavaScript has evolved over the years, how Vue.js makes JavaScript super-friendly. The challenges of being in the framework's Olympic circle, and why he's concerned about the mounting technical debt in companies today. Now I'm not talking about the US national debt, it's technical debt. So welcome John.
John Farrar: Hello, glad to be here.
Michaela Light: Yes, hello, welcome to the podcast. So glad you're here. What exactly is Vue.js?
John Farrar: Vue.js is another one of those libraries, and I'll probably talk on that later, some of the things you mentioned there. But Vue.js when version one was out it was really cool looking, had a lot of promise, but it wasn't holistic enough that I was ready to drop an investment of my time and encouraging others to. When version two shipped, it really took off. What Vue.js is, a lot of use have heard of the phrase, single-page applications, I'm a part of the people out here who are trying to change that phrase, because when you use a phrase that doesn't describe it well, it confuses people.
What I do is I call it a progressive web app. What that basically means is you've got a web app, and you're basically building an entire client that is running inside the browser, and it's more than just not refreshing the page, because we're changing the data on the grid. It's more than just not refreshing the page, because we're cycling through a slideshow. What's actually happening is the page that you load, the whole page can change without going back and pulling a whole new page from the browser. You have pages and pages of content running more like a desktop application than a browser application.
It's pages within an application, but all run in one request. Except for of course the extract request or stuff you're doing. Mixing those pieces together it just makes for an experience where your web app's actually feel like a desktop application. They don't feel like a web application anymore. Vue.js is one of the leading libraries that does that. It really makes it simple. Of course there's a level of complexity to anything, but one of my standards for software, wherever I work or consult, is I have a little acronym I use. It has to be ASC oriented. That A-S-C, which means approachable, sustainable, and collaborative.
Michaela Light: Could be taken another way when you said ASC orientated.
John Farrar: Yes, A-S-C, ASC, but if you don't say it right, you're going to have someone … Be careful, you can be misunderstood. But there's so many things that have come out. Angular1 was very approachable upfront, but as you worked with it, day in and day out, there were a lot of people who had extreme pain points with it. They learned how to solve them as a community, and you had so many people were so invested in Angular1, because they had invested deeply and hard into it. Then when Angular2 shipped, there was blood being spilled, because it broke the chain of progressive upgrade.
That happens, and by the way, that's why I didn't jump in with Vue 1, that's why I didn't jump in with jQuery 1. There's some languages I've determined from the start they would upgrade smooth, but Microsoft used to have a motto, I'm not saying they practiced it, I'm only saying it was a motto. That was, “Never first, never last.” That's actually a really good business model. You can choose for yourself how well they did at practicing eating their own dog food there. It's still a good motto.
Michaela Light: That way you're not on the bleeding edge when the first version comes out, but you don't miss the boat by later versions.
John Farrar: Right, and if you're going to be on the bleeding edge, then … There we go, Jim Collins, I can't remember which of his books it was in, but he talked about fire bullets before canon balls. Steve Blank talks about it, he says you need to invest small until you have a winning product, and then you pour your fuel in. A lot of people invest too much, too soon. It's okay to be bleeding edge as an experiment, as a test, but when you go whole hog with bleeding edge, you're reducing your chances of winning. That's not good.
Vue.js 2, I think they're in there. I'm behind it, in fact I didn't mention I have a project that we can talk about later if we have time or want, but I'm looking at building an open community project called the Open Learning Server, but I'll save that.
Michaela Light: Why did you used to avoid using JavaScript, and how did that end up advancing ColdFusion?
John Farrar: Well my years of JavaScript and web programing go back all the way to before Internet Explorer 3. In fact, I don't have it anymore, but I actually got a t-shirt from Microsoft, because I was one of the first 100 people to download Internet Explorer 3.
Michaela Light: Oh.
John Farrar: That's when they were ramping up their battle with Netscape. Back in those days, if you wrote JavaScript for Internet Explorer, or Netscape, or any other browser out there, that's where it ran right. You had to write another version for this browser, and another version for that browser. Back then, to be honest, I didn't, and most people didn't even know how to detect which browser you were using. That was a difficult thought. If you don't know which browser you're using, you basically put a sign in the website that says, “This site runs with this browser.” If it didn't work, they saw that sign, and you tried to force people to Netscape or Internet Explorer, and JavaScript was … It was the work of penance. It was just horrible.
Now to that point, I mentioned that JavaScript advanced ColdFusion. Nowadays, we've got jQuery, we've got all these libraries, and you can do all kinds of cool stuff in the front end. You've got handlebars, you can do templating, you can just transform a person's website on the front end. Before JavaScript was really alive and functional, that forced us to change stuff on the backend. As funny as it sounds, as poorly as JavaScript was running, JavaScript create an appetite to do stuff that was dynamic. But it didn't deliver the promise of dynamic, because it didn't run the same from one browser to the next.
What actually happened is it created an appetite that actually pushed the server platform, so we had dynamic websites, but they weren't dynamic through JavaScript, they were dynamic through a backend language that could change the pages with data and stuff, and send a fresh page, even though it was the same URL, it was a different page depending on how the user interacted with the site. That was the time when ColdFusion was coming out. JavaScript, being as bad as it was, actually was one of the reasons that ColdFusion prospered.
Michaela Light: You eventually did get into jQuery?
John Farrar: Yes I did, in fact I started, I had a transition point between there where I was doing Prototype, you know Rick Mason, I believe?
Michaela Light: Yeah, I know Rick.
John Farrar: He runs a ColdFusion users group on Lansing, Michigan, the capital. Well we had a … Back when Ajax was coming up he invited me up to speak at Ajax. You're going to love this, you would think that someone who last year was married 30 years, it wasn't last year, it was obviously a few years ago when Ajax was coming up. He planned this meeting, and he told me that there was only one person who ever drew more people, to his meeting, than I did with that meeting. That was obviously [Ben Porter 00:10:32].
The real funny thing though, is it was not the day you would have expected a big meeting, because neither Rick or I were smart enough to remember that the second Tuesday of the month is always when he was holding his meetings. It happened to be April 14th, sorry, February 14th. We planned the meeting on Valentine's Day.
Michaela Light: Oh, not the best day to do your meeting.
John Farrar: We had an unbelievable turnout, they really liked it, but that was with Prototype. Then as jQuery went into version two and got traction, I really jumped into that community, because I just saw what they were doing, how they were connecting the pieces. I thought jQuery was solving the challenges that developers were dealing with best. That's how I rate any JavaScript framework, what are the current challenges? That's half of it. What do you think the challenges are? One of the things Steve Blank says is there are no facts inside the buildings. It's part of the startup manifesto in his book.
What he means by that is he says he's a college professor, and he jokes about it. He says, “We all have hypotheses.” He says, “That's just a word a college professor uses so he can sound educated.” He says, “What they actually are is guesses.” He says, “And our guesses are exactly that. We don't know, until we test. If we test and we're right, then it was a good guess.” He says, “But we don't know until we test, there's no facts inside the building.” We do the same thing with our frameworks. Is jQuery great? Okay, but we test it. We fire those bullets or canon balls. We see if it really works. If it's working for us, we invest deeper.
When we do that with our frameworks, we start to find out what they're about. That's what we should be doing with our frameworks. jQuery, with the problems that people are actually having, did a wonderful job at solving the real-world problems that people were dealing with. That's how come the reason I was right, was because I tested a lot of those things. It wasn't as much intuition, as it was the process.
Michaela Light: What problems do the different jQuery frameworks solve? If we look at jQuery or Vue.js, or React, or Angular?
John Farrar: Well jQuery has a number of libraries out there, including they've jQuery UI. Obviously it solved the need to make dealing with the UI from JavaScript more approachable. In fact, I do a lot of this, I run it through that little ASC acronym, it made it more approachable. The code was more sustainable when you went back, you could update the code. Someone else could see what you had done. That was a whole thing. The whole collaborative thing, it was just very approachable, sustainable, and collaborative for the problems it was solving. jQuery itself, when you wanted to interact with the DOM, you know you turn your HTML into this Document Object Model.
Interacting with that was difficult back then, you had still the problem of the different browsers running different. When you use jQuery, the differences were negated. You could one set of JavaScript, and jQuery was one of the big pushes, and paradigm shifts, and thinking that made us believe. In face I think jQuery one of the biggest contributions it made, is it did so much at helping so many people to write one set of JavaScript that ran everywhere, that the browser vendors stopped creating unique JavaScript because it didn't help them. They could not control the market by writing unique JavaScript. Thank you jQuery for putting an end to that craziness.
Michaela Light: Effectively it's like having a virtual Java engine on top of JavaScript, you don't have to care what the JavaScript underneath is.
John Farrar: Yes. jQuery had a technical social impact that a lot of people have not realized, they may be the highest impact thing that has brought us to a single compatible JavaScript and CSS. I think they are perhaps the biggest player in that game. That's the top award I would give jQuery.
Michaela Light: What about React, what's the problem that's solving?
John Farrar: React, when you start moving up into single page applications, progressive web apps, what you're doing is you're trying to run a site without hitting the browser when you go to different parts of the site. You're actually running the site in the browser, and you may pull a new template for a page, but the page is already there. That's what React did, React of course is a project like Facebook, and React still one thing it doesn't do is prevent fake news. What it does do is they were trying to build this thing with interacting with the backend server, they've got all these parts of the page running at once, and they need everything to be running together off sort of this data model.
What they call that in React is the state. So this is the state of my data. When you change data, the user interface automatically updates. You add another row, it adds another row to the table. It's a responsive UI, and that's what it's doing, it's reacting to the data state. That's what's really cool about it is [inaudible 00:17:02] I'm not going to hit the technical side of how it does it, but basically React does this, and so does Vue. They create a copy of the DOM that is not actually running in the DOM.
One of the slowest thing your browser does is update the view. Reading the view, querying it, and updating the view is just one of the slowest things it does. Just like one of the slowest things we do with the server is hit our database. Same type of thing. Angular too has this type of feature too. By creating this shadow, this copy of the DOM, when they change something they compare it to the copy. Then they rewrite the DOM from the copy, because they can see what the changes were.
By splitting that out, all of a sudden Facebook became very responsive very fast. That's why React changed the whole game. That's the kudos for react, and that's one of the big wins because they changed the way JavaScript runs. jQuery what it does, it's actually make it easier to interact, easier to search the DOM, it's making that code so it's more standard. It's not solving the same problem. In fact, so far I haven't seen anyone take and build a jQuery library that is solving that problem. If it did, I don't technically think it would be jQuery.
That gives that whole concept which you brought up earlier, the Olympic Winner's Circle. Okay, we've had over the years, I remember when I was a kid one of my favorite, Mark Spitz and Bruce Jenner, they were Olympic athletes that I remember, they just did an incredible job. I don't think any of those guys have considered going to the Olympics for more than a decade, because they would just look embarrassing, especially with the Olympic crowd. Everybody has their season where they shine, where they perform.
The problems that we have with the internet, a lot of the problems we faced back then, well they were solved. These tools, like jQuery, solved it better than anyone else. The model for jQuery used to be do more with less, that's why my talk is called Vue More with Less. For me, it's the next evolution and taking the same type of fun and benefit I used to have in jQuery, and it seems like every once in a while you're coming up with new challenges, new challenges, and they're stacking up. A new solution comes along that just really super-solves your problems.
We all say it, “This is fun.” jQuery, and Prototype before that, Vue.js all of these are JavaScript tools that to me have reignited new fun into my programming career.
Michaela Light: You also mentioned Angular there, what's the problem that framework solves?
John Farrar: Angular is a more rich-based, whether we like it or not, in fact I don't know if all the listeners know, but it used to be Angular2, and then they were talking about Angular 4 is coming out now. The new thrust is it's Angular. They're dropping the versions, it's just going to be Angular. As you hear about it in the future, and you're just hearing Angular, there's a reason for that, because they want to be progressive and backwards compatible. The shift they had moving from one to two, part of the goal of that shift is to maintain backwards compatibility.
It's solving a lot of that same type of thing. The difference is Angular is more of a deeply object oriented solution, where I would say React and Vue.js are more of a MVVM solution, so Model V View Model. It's solving things a lot more in that direction. Currently if you're building mobile applications, there's probably more tools out there for mobile apps that are Angular based.
Michaela Light: Then what's the problem that Vue.js is solving?
John Farrar: Vue.js is solving the browser side of the problems at this point. Have you heard of [Weex 00:22:10]? Do you know what that is?
Michaela Light: I've heard of it, yeah, tell us what it is?
John Farrar: Weex is the Chinese mobile superstar.
Michaela Light: Oh, okay.
John Farrar: It's sort of like Ionic. Weex has committed to their platform being Vue.js oriented. They're the superstar in China, so probably in America we're not as familiar with it, but we would know about all of our stuff over here, like Ionic, that we just don't hear it as much. But it's probably not a coincidence that they jumped in there, because do you know who created Vue?
Michaela Light: No, tell us who?
John Farrar: You. His name is actually You. His name is You, and yes that is fun to do to people. What? What did he say? It was created by You, Evan You I believe is his name. He happens to be Chinese also. I'm not sure where he lives at the moment. The fact that he speaks the language gave him a bit of an in-road with Weex, because he can interact with them in the same language. I'm going to tell you this, the Vue site it's full English, it is absolutely amazing. You can Google it and hit it, it is just a super site. It's one of the best document sites I have been to.
Of course, like anything, I heard the gentleman who runs the Laracasts site, by the way, he said, “If you want to learn technology, you do not learn technology with documentation.” He says, “You need a training resource to learn, documentation has a purpose, but it's not the best way to learn something.” Vue.js their site though, it is absolutely incredible, there are some sites, they've got a [inaudible 00:24:15] community Glitter based site, for some reason they didn't go Slack. I guess not everybody goes to Slack.
The problems it solves just building an interactive site, and the way it builds code, is just super-friendly. In fact one of my favorite things it does, is on the same page I create a template, which is your classic web template. Then it has a section of interactive code there, not too detailed, you still break the pieces off. It's enough that it's on the same page in another segment. At the bottom it has script, not script, styles, and you can give it a little keyword, and those styles will wire themselves up so that they only impact the template on that file.
You don't have styles that are leaking all over the place, and you're not putting styles up inside your code. It is the classic styles. It's just really cool, because it works, it's simple. Someone can come back and share your codes, very collaborative. You can come back in six months and your code still make sense, for those of us who've programmed a while, we know that scared us more than once when we were first getting started.
Michaela Light: Yup.
John Farrar: Have you ever done this Michael, because I know I did this two or three times when I started learning to code differently. I'd go back and look at code and be like, “Who wrote this?”
Michaela Light: Yeah.
John Farrar: I'd go back and look at the records, and it's like, “Oh, me. I'm glad I didn't say that out loud.”
Michaela Light: Yes. I often tell people when they're writing code, you need to write code to be maintainable, easy to read, have some documentation and other conventions. Not just for other people who are going to read it, but for your future self in a year's time who's going to read it.
John Farrar: Right, and that's why, speaking [inaudible 00:26:25] over the years, I've got into that concept of technical debt. It's hard when you work at a company and they're so deep into production, that they're not documenting stuff. I'm not an ultra-documenter, it's like I like this phrase, your code should be well documentation, but documentation is not an excuse for poorly written code.
Michaela Light: Well and if it's really well written, it almost documents itself.
John Farrar: Right, and that's the goal. You write code that's self-documenting, but we all know that something you're doing is foreign to new guys document. Something you're doing … You did have a production restraint, so you couldn't actually make it as nice as you should have, document it. Do that type of thing, make it approachable. I like the fact that like Vue, the way it's organized, it takes a new developer, and it kind of stinks from our perspective, because they're writing this code that's sort of self-documented. You're like, “Yeah, that's just where I started, I was that good when I started too.”
Michaela Light: How would you define technical debt if people haven't come across that term?
John Farrar: Technical debt is you're running around, you're coding, and there's things that you need to fix. Or, I'm writing this, I'm writing another page, I'm writing another page, and then I come back and do an update. What happens is your productivity starts to decline because you're trying to manage all these shortcut issues, or I'm going to be as productive as possible issues. While you can do that, that process ends up costing you more time in the long-range, or more features et cetera, and less upgradability. Writing that way, all those conflicts you'll have, that's what I call technical debt. We all have technical debt. It's not a question of do you have technical debt.
Michaela Light: That would be personal technical debt thought, right? Not national technical debt?
John Farrar: Correct. Although that's the first health website that went up obviously had a boat load of technical debt, but they did get that worked out, since they couldn't get it to run right. It was a classic example of technical debt. They just about had to rebuild that thing to correct it. Another thing, technical debt can be vulnerabilities. About a month ago Amazon had someone just type a command in and just about brought down their whole Amazon farm, had all kinds of big companies that their sites came down. That's another example of technical debt, you do testability and there's lots of things, but none of us enough time to correct it all. How do you solve it? You pick technologies that solve your most critical issues first.
Number two, you create tests that are the highest critical level, then when you come back you can … Well here's the bug, you create a test that goes where there's bugs, so that test never sticks its head up twice. When a customer comes back to you with the same bug, you're destroying your business. You will lose their confidence, and your customer's trust and your integrity. I'm not just talking about moral integrity, I'm talking about your technical integrity. You have to maintain that, and that's where technical debt … There's just all those issues that come in and chew at you. Some of the speakers that are talking about … I'm trying to think of some of your podcasts. Different areas like load testing, someone's talking about NGINX, there we go. Can't say it right, what is it? N-G-I-X, how do we say that?
Michaela Light: NGINX. It's a clever way of spelling NGINX.
John Farrar: Thank you. I could do it before I was sitting here, but it just …
Michaela Light: I have the same problem.
John Farrar: All of those things …
Michaela Light: I have a …
John Farrar: Charlie has a good talk coming up on that.
Michaela Light: Yeah, he does.
John Farrar: I love it when there's two tracks, but I hate it when there's two tracks, because I want to be in both sessions.
Michaela Light: You need a multiple personality disorder so can attend both at the same time. I don't know how to do this, but I just had this sudden idea. You know how the national debt they have that clock in Time's Square that shows how many trillions of dollars we all owe as US citizens.
John Farrar: Yes.
Michaela Light: What if every company had some kind of measurement of how much technical debt they had, and that was a publicly available measure, and you can see how much is racking up every day. That might-
John Farrar: Well there actually are some measurements, if you watch the company morale, if you watch the … You just look at those signs, in fact it's one of the things I use for my life coaching. I tell people it's back to the questions concept. If you will just record the questions that you're asking yourself, and note when new questions are arising, you can monitor the new questions, because it's a new signal. That new signal is just like analytics, if we kept a question journal, and actually used frequently asked questions as an analytics tool. Okay, if we're getting this question over and over, it isn't because people are stupid, it's because we're trying to interface out customer with our software, instead of our software with our customer.
We do that stuff, it's crazy. You know it's funny, we understand that usability is interfacing our software with our customer. Well when we're doing stuff like Vue.js or ColdFusion, here's a wild one, that little command how you write the code, how you organize your code, your methodology for coding, your frameworks, the problems it solves, that is the same thing … Well it's the same kind of thing as you have an interface that you interact with your customer, your GUI. The way your code works is an interface that interacts with your developers.
A lot of people, and we had some errors in this in the past in the ColdFusion community also. We were so bent on being pure, object oriented, that we weren't looking how do coders interact with it? Are they actually more productive? We were all about the technical excellence, without seeing if it actually accomplished anything business-wise. It did accomplish stuff, but we needed to figure out where it won, and where it didn't. Our technical excellence actually for a season starting pointing us to technical debt. It was a bit of an irony where our excellence was hurting us.
Michaela Light: You talked a little bit earlier about how you pick a framework, and you don't just go for the most popular one. Tell us a bit about it. You mentioned it has to solve the actual problem you have, and we talked about some of the problems these different frameworks solve. You wanted it to be fun as well. Are there any other criteria you use when you're picking a new framework?
John Farrar: Yes, there are. I helped out a friend of mine, his company had actually moved from ColdFusion to, you can probably guess, WordPress.
Michaela Light: Ooh.
John Farrar: Yes, it's like … But, it was a friend, so I went and helped him out. We looked at using jQuery mobile, because we thought maybe this would solve the need. As we started using it we found out that it just had issues. We ran into problems with how do I even code this? Number one. Number two, the screen isn't refreshing right, so Google is penalizing us be they have what they call above the fold. What it means is when your web page first loads that code from the top of your screen to the bottom of your screen, that needs to display as quick as possible.
Anything below that border, you could have a webpage that's 20 pages long, it doesn't matter, you don't need to send any of those graphics, you don't need to … All of that stuff is not … Google has a tool called Page Speed, if you go to that tool, it'll show you. As we started digging into that, and firing those bullets, it just wasn't performing. What they figured out is although they were looking at doing that, looking to move to a different platform, we actually went back and we rewrote their site for Bootstrap.
Bootstrap Mobile first did everything we needed, what they really needed was to rewrite the bootstrap stuff, instead of move to mobile. That same thing, why were we considering that? We were considering that, because that's when Google split. Some people know this, some don't, but if you have a website that's publicly visible, then you have two listings for every page on Google. Google scans your page as a mobile browser, and they scan your page as a desktop browser. They rate them completely separate. How long does a person spend on your page, that's probably the biggest influencing fact of where you list on the Google engine.
They will also pre-judge you. If your website takes a long time to render the page, they're going to guess that people won't spend a lot of time there, they're going to bounce and not even go there again. They're looking at those type of things. When you're choosing a framework, being it Vue.js, Bootstrap, all these different things, you need that page to come up. It needs to hit fast, and it needs to flow. That's also Google now no longer … It used to be Google could not go through a React based site, or a Vue.js, or an Angular2 site. These single page apps, these progressive web apps, they'd hit the first page, and it wouldn't display right. They especially couldn't click through it, like they do on a normal site.
Nowadays it completely works, so you can build these apps where you could not have even two years ago. It's the same to Google as without it, but to your users it's a completely different experience. That first page may be a little slower, but after that it's just next page, next page, go here, go there, everything's just snappy. That's the type of benefit the new winner's circle of the apps that perform those functions well. That's why currently I pick React, Vue.js and Angular2 as the top winners.
Michaela Light: They're the gold, silver, and bronze.
John Farrar: Yes, there are others that do it.
Michaela Light: They're the gold, silver, and bronze in the Olympic Winner's Circle.
John Farrar: Right, and depending what your company's needs are, you can award the medals that you want. You probably are rewarding them right. It depends on what your needs are, who you have for staffing. They're all functional solutions, and I don't get into the hostile type approach. It's like mercy, but the software is working, right? Yes. It's up dateable and you're putting in the new features, you're making good progress, your company is profitable. Sir you have a win. Something else may have a different level of a win, but you have a winning project. You don't need this because you have something that wins more in this anecdotal area.
You don't need to sound like a bunch of teenage guys who are fighting over something because testosterone is kicking in, it's a new phase in their life, and they're just used to that volume. I was there too, I remember doing it.
Michaela Light: What is the challenge for these frameworks when they're in that Olympic Winner's Circle?
John Farrar: I think the challenge is to understand where they win, to establish themselves in the market where they win. I think the worst thing they can do is look at a competitor to leave their challenges behind, and start trying to beat their competitor where they don't have a strength. That's a lot like life coaching too. All of us have our own strengths, we have our own challenge areas. If you have a leg that's two, three inches shorter than the other, you probably are not someone who should pick a career as a basketball player.
You might be the exception to that, but the general [inaudible 00:41:15] I'm correct most of the time. The same way you don't try and strengthen … The Gallup poll, the organization that does all these giant surveys. They've interviewed over a million successful people, and what they wanted to know is what makes people's success. They said one of the biggest things that shocked them is we've always been told if you will strengthen your weaknesses you'll thrive. They said out of a million people they couldn't find a single person that held true for.
Michaela Light: You should strengthen your strengths, and find a way to ameliorate the weakness.
John Farrar: Right, you look for opportunities to thrive in your strength areas. There's this middle area that's called profitable. If you don't have an opportunity for your strengths, then you do what's profitable, and you lay aside some of that profit. When you have an opportunity you can invest in it. Your challenge areas, that's where we do damage control, and that's why we have testing, and stuff like that, because we need to deal with the challenge areas. Actually those same principles carry right over into software development.
I mean even your team, this guy's really good with an API, you want him learning to do some of the other stuff, not so he spends the same amount of time, but so he knows how to talk to the front end developers. So he knows how to interface with them. It's just like you want your developers to actually sit and watch someone use their code, because Dan and Chip Heath wrote a book called Switch, and they talked software developers in that book, sitting down. They just kept saying, “Stupid users, what is wrong with these people?”
They put them in a room where the people were using the software, and a light bulb went on. They said the same people came back from watching people use their software, and they're like, “Oh, we didn't do that right, we've got to fix that. These people need software they can use.” It's like when they watched them, they got it. When they're sitting in the dark, hidden room, it was just stupid users out there.
That type of thinking, it changes the game, and the whole Olympic Circle these are the tools that have actually gotten out there and interacted with the users. They know how the users are using it, and they're solving specific problems. That's why React developed that reactive interface, and they have other stuff that goes with it. Angular, they have this super-object oriented dependency injection framework for doing JavaScript. In fact the more popular way of doing Angular is with typescript, where you fundamentally have a fully object oriented JavaScript. It's not that JavaScript Prototype function, I hate that thing. Whenever I have to look at that, it makes me want to go back to Avoid.js. Okay so … Go ahead.
Michaela Light: Yeah, tell us more about how you pick your framework.
John Farrar: Okay, so let's put these more in a bullet point list, and I don't have a pre-made list here. Basically, sit down and figure out why do I want to use a JavaScript library? It needs to be more tangible than, “Well the competitors are using it, and they're using this one.” That's not a great strategy, because it's not just … 100 reasons, but you want to know what problems you're solving. What challenges, or what benefits you're after. I can remember when I first started consulting, which was decades ago, and people wanted to buy a computer. This was when computers were first coming out, PCs. I'd ask them, “Why do you want to buy a computer?” They'd get the glass-eyed look.
It's like they're not answering, why are they going glass-eyed to why do you want to buy a computer? Finally they would answer, and it blew my mind. They would say, “To make more money.” Apparently buying a computer was the pot of gold at the end of the rainbow. A lot of people when they're choosing frameworks and technology, their decision is they're looking for the pot of gold at the end of the rainbow, but they don't understand this rainbow is nothing more than light shining through rain. It's not a good way to make a decision. You need to think about what problems is it actually solving. You need to make a good, intelligent decision.
Get out there and get counsel, hire a good consultant. Number two is community. There needs to be a growing or a thriving community around us. You need to have somewhere to go for support, questions, there should be great documentation. Even better if there's good training courses already out there. Another thing you want to make sure is the community has viable funding, that's one of the things that blew my mind, how many companies when Vue.js2 came out, it was like they got super-funded. All kinds of companies jumped behind them. I was the only one waiting.
Is it validated in real-world solutions? That's the never first, never last type concept. It's okay to jump in sooner if you're testing, but you need to know it's actually validated out there. Those are good ways to check.
Michaela Light: Those sound like a great way to check. Tell us a bit more about Vue.js, and how it makes JavaScript super-friendly. You mentioned a few things earlier.
John Farrar: Another thing that a lot of good libraries have that Vue has, it's not what makes a library good or bad, but it's a benefit to the Olympic Circle I just mentioned, is plug-ins. It's one of the things that really skyrocketed jQuery. Well Vue.js has a lot of plug-in type things also. It's like have you heard of … I think it's Flux, the React library, it's used for managing data states?
Michaela Light: Mm-hmm (affirmative).
John Farrar: Basically, as your app gets bigger and bigger, Angular you don't have to add something in, this has it pretty much from the start, and they've got tools that are in there to do this. The one that's known for popularizing this need, because what happens as we talked about data having a state. When it changes, the front-end responds to it. Well that's all good until your app gets bigger and there's more pieces, and there's data states impacting more things, in more directions. That's a lot of what my talk is going to be about at Into the Box. There's a library for Vue called VueX. What VueX does is it creates a way to maintain the data that's more sophisticated.
It is a little more work, especially because there's not a lot of training on how to do it. It doesn't take a whole lot of training, it just takes someone who can explain it without sounding like they're technical. Just because we're technical doesn't mean we need to sound like it. That's what they do, is it's just a different way to package your data, and some of the things I'll show is how to stick your data in name space. A lot of times when we create a little package of logic, up inside our logic we'll have a name we use for a variable, and a different package we may use that same name.
Well if you're using straight Vue or React, or not watching it when you're creating Angular when you're doing this, what people do to avoid conflict is they start building these super-long underscored names. It's like okay, we don't need these super brief names, but name spacing takes some [inaudible 00:49:59] down, so here's the name space, here's the value. It creates a nice staple, manageable data set. That's one of the things that VueX does. It's just solving little problems with that. As far as that goes, that's one of the problems is you start getting more and more data, managing that data with jQuery is a super-monster.
Let's just say it's a problem that you may have solved it, but it's unique, and it's probably not easy to pass on. If it is unique and easy to pass on, you probably could actually develop quite a following online, because a lot of people in jQuery would like to see it. In fact, jQuery had a project, his last name was Morris, a guy from Microsoft that was working on jQuery templating. He went off and built something along that lines, but he could not figure out how to get it to that level. At that point, I had a contract with PACKT to do a book on jQuery templating, but they couldn't get it to that point. That's when I started using Knockout.js which is what I use to supplement my jQuery for a season until I jumped into Vue.
Michaela Light: You've been looking at JavaScript for a long time, what have you noticed about how it's evolved over the years John?
John Farrar: Originally there was a challenge, speaking of damage control, where it didn't run the same for each browser. Basically jQuery, in addition to giving us new features, did great damage control. It was one of the benefits. When they changed the browser, the community came together and always did the damage control. That was one of the progressive things, but it used to be you built static webpages. We would ship them out and a person could go from one page to another, that was it, that was where the web started as far as what we call the web. There was other web-ish type things, but that was when it actually really took root.
From there we started building dynamic sites, which meant you would interact with a server, and we would change the content, and your site could have customized content, depending how you interacted with it. All of the changes happened on the server. As JavaScript has evolved, more and more of this is moving to the front-end, and we're doing less of that whole thing on the server. In fact the new trend anyone out there who's a developer is probably tired of hearing this, API, API, API. It's like all you hear nowadays is API. If you're not doing API, you're a dinosaur.
I don't feel that way, but you feel like it, because it's all you hear about. That's because a lot of this rendering and managing of the page that we used to do, is moving now to the server. In fact, one of the new things coming in technology is the ability to render that first page that's JavaScript rendered. They're doing stuff so you can take and pre-render that page using the Vue.js or Angular, React, you pre-render it on a … There we go, not Jason, what do we call it? Vue.js. Okay, what do we call a JavaScript server? Node.js, there we go. They pre-render it on a Node.js server and deliver it.
Wherever you hit the page, it's even more responsive, which helps with that page speed type stuff. What's happened is JavaScript wasn't just something … It started out as something we avoided, or we forced people to use our version of JavaScript and when you came to the website, you had to use this browser or the JavaScript didn't work. Well nowadays it's not uncommon, even some people who do ColdFusion they mix their site, and they have part of the site run off a Node.js server for doing stuff like this. Pre-rendering that part of the JavaScript site.
Like I said, it's become very object oriented. We have amazing tools, like WebKit does is when I'm coding in most of my Vue.js, I build this code and JavaScript actually compiles my pseudo code down so it will run on any browser, because not all the browsers will support the features. In fact, you have this import feature in JavaScript, and you'll import and use something, but these packages that you import, that doesn't work on any of the modern browsers. Although you can use EJS 2016, even better in some cases, so you're using all these fancy new ways of writing functions and everything. That particular feature they're not looking to push to the browser, you pre-compile that stuff to send it forward, and all these tools are now part of JavaScript.
What's really wild about that, as much as I disliked JavaScript, I also used to hate using command line. It was just non-productive, it wasn't how I was wired. It wasn't my strength. Nowadays, I don't think I spend 30 minutes in code without popping back and forth between the command line. I'm at the command line probably 20 or more times a day now, and I love it, because they've changed the whole experience. That experience is actually powered by JavaScript. Except for the other tools that I use were actually powered by ColdFusion, because some of the work from [inaudible 00:56:23].
I love CommandBox, and yes, I've written some of my own tools using CommandBox, because I'm more comfortable doing it in ColdFusion, but I like JavaScript too. I get to use both of them from the command line, which is something I never expected in the past. I thought we're getting more technical, we're going to be more GUI, less command line, less of these tools. I found out that there was some classic benefits to it that were worth revisiting.
Michaela Light: Let's just switch gears slightly, this is a question I'm asking all the people I'm interviewing. Why are you proud to use ColdFusion?
John Farrar: Well ColdFusion has given me career-wise something more than any other tool, and that's success. I've been able to help customers win. We build sites, they do what they need, we're able to keep timelines. I'll not 100% win all around, but I've looked at our success ratio, and the ratio of competitors, and when I'm getting faster delivery and a higher success ratio, then it's what I call modern ColdFusion. I'm not using ColdFusion 5, I've actually built objects.
I have stuff like CommandBox, this isn't like one of the former people said, at the [inaudible 00:58:01], the phrase was, “This is not your father's Oldsmobile.” Well the ColdFusion I'm using isn't my father's ColdFusion. Although technically that would be me, because I have a son who's a full-time professional ColdFusion developer also. But he's not using the ColdFusion I started with. This is a very mature feature. I think it was with your interview with Lewis, in fact.
Michaela Light: Yeah, that's a phrase he likes to use, the modern face of ColdFusion.
John Farrar: And it is, it's really a … It has the modern features. I have people that once were all skeptical, and I just walk them through some of the features I'm using, and they're like, “Oh, I didn't know that.” I tell that's okay, let me know when you're ready to start.
Michaela Light: What will it take to make ColdFusion more alive this year?
John Farrar: When I look at making ColdFusion alive, that's one of the things I look up. I've mentioned Steve Blank earlier, we talked about there's no facts inside the building, so get outside. One of the things we need to do is actually measure what's making a difference. I mean back during [inaudible 00:59:25] we talked about there was a decline at that point in the number of ColdFusion people who were publicly visible. I think that's actually true, because more and more of the ColdFusion jobs, like Ford Motor Company, they thrive on ColdFusion, they absolutely love it. There's a lot of other companies like that. They're selling more ColdFusion. You know where all the sales are going?
Michaela Light: Where?
John Farrar: Apparently the Wizard of Oz is the one who's buying ColdFusion, because it's all behind the curtain, it's places we can't see it.
Michaela Light: It's all intranets.
John Farrar: It is, and that's the reason people don't see that ColdFusion is thriving, because it's thriving in the intranets. With that awareness, that changes the game. Which also means it's a super business-to-business tool. If you can run intranets and business-to-business on it, maybe it can get business done. What we need, and what I would like to see, someone had mentioned that they thought Adobe needed to do more, I'm not sure if they do or not, I know it would help if they did more. Where I would like to see them do more is to do more outside the corporation. I think they've started to do that, they're sponsoring conferences a little more aggressively. I just hope they keep moving in that direction, and measure the benefit there.
It's a different benefit, and I think that'll really take off. I love what Lucy's doing in the same area, a lot of what they're doing is awesome. In fact, I think the biggest thing I've seen as I'm dealing with people and introducing them to ColdFusion, I can get a new developer set up, and I could get them going on Laravel fairly simply, or WordPress. Or I could get them going on Ruby on Rails, but the honest easiest way I can introduce a new developer, is I say, “Okay, bring me your computer, let's look for content on CommandBox.”
They download it, and I just show them how to get a site set up with CommandBox. It is the drop dead simplest way to get a developer started. That type of thing, I think we need to introduce more people to CommandBox. I think we need to get more ColdFusion developers aware of it. When they look at it, and they spin up a server that fast and that easy, I like watching their mouth start to dry up. They're just sitting there with their jaw hanging. It's like, “What did you do?” It's like, “You saw everything, that was it.” “But you didn't download the server.” I said, “No, it's running in Lucy.” It actually did, it's in the Box package, and the way it pulls it. I said, “That's just how long it takes.” They're like, “Huh?”
The disbelief, it's … When you get people doing that, it is a powerful thing. Again, that's the measure in … What is the pulse? What are seeing? What are the results? I think if we would use that to get a whole bunch of developers, “Oh, who wants to learn web development?” Okay, we'll start off learning HTML and CSFs. What's the quickest way to get a server set up to do that? CommandBox.
Michaela Light: CommandBox, yeah.
John Farrar: The biggest win is to get there before they get to the server. The biggest win is to get them from the very start, and I think CommandBox is a super tool for this. We all need to high-five Brad and the Ortus Group for that. It's got some zest.
Michaela Light: Fabulous.
John Farrar: While they're at it, we can then do some write your own script. Here's how you can run a ColdFusion page. The first dynamic language is sitting right there. Then we can introduce them to ColdBox, if they want to get sophisticated. I think doing that, I think that our secret tool is CommandBox.
Michaela Light: I love it. When I ask people this question, what will it take to make ColdFusion more alive this year, I'm not just looking at external things, I'm looking at what each of us in the ColdFusion community can do, and how can we empower ourselves more, and not be sitting around like victims waiting for some giant corporation, or some other thing to change.
John Farrar: Right.
Michaela Light: There are things we can do as a group.
John Farrar: Well when you look at that, look at WordPress, who owns PHP?
Michaela Light: It's Open Source, isn't it?
John Farrar: It is Open Source, but it's actually owned by Zend Corporation.
Michaela Light: Oh, okay.
John Farrar: Here PHP is that has a commercial library, that has an Open Source side-by-side. In that aspect although there's differences, it mirrors the ColdFusion community. You've got ColdFusion, you've got Lucy. You've got Zend PHP and Open PHP.
Michaela Light: Oh.
John Farrar: What was the difference that catalyst drove their community, and what it actually was is their community projects did a lot more than Zend did. The success of PHP was not Zend. Although that gave it some success, if you look at the percentage, it's not Zend. I mean [Mercy 01:05:17], what is it, over 27% of the internet right now is run on WordPress, over 27%. Over 35% of all the commerce sites are run on WooCommerce, which is a WordPress plug-in. That is absolutely crazy.
What was it, it's how the community came together. The word camps, the synergy, and we don't need to do everything just like they did, what we need to do is get a pulse, where are we winning? What are people looking for? Let's look at it just like a healthy business. Okay, let's test this out, do we get traction with this? Invest more. No traction? Shift your investment. Fail early, fail often, pivot. If we will do that, we will see ColdFusion come alive in new ways.
Michaela Light: That's a great answer. We're going to be at In the Box next week, what are you looking forward to at the conference?
John Farrar: I will enjoy being frustrated that I have to only pick one or two great sessions. I will be more frustrated on day one, because I'm going to a class, so I have to one of four or five, I'm going to say four, I think it's five, but four is less depressing, because I want to attend all of them. In fact Brad made a smart crack today on a Slack, he said, “We're going to give John an egg-timer, and every 15 minutes we're going to let him jump from one to the next.” I was like, “Thanks guy.”
For me it's just a great opportunity to get exposed. Almost all the speakers, there's just little nuggets of wisdom and those little nuggets to me, I just come back and it's like where can I use this, number one? And number two, what is the benefit to the other members of the team? I subscribe a lot to Simon Sinek's approach, Leaders Eat Last. When I'm going, I'm looking because I know our team, we've developed a friendship. I know this is for this person, focus is this person's newer, this person's not yet acquainted with this. It's how are they introducing this? How can I show them this concept so it's easier to adapt to?
Everything we do, every new technology is an adaptation. You're shifting from one familiarity to another. It's not that the technology is hard most of the time, it's unfamiliar. All these speakers, they have a different perspective. I get to learn, not just the technology they're teaching, but I'm also there to glean from their perspective, how do you interact with your clients? What challenges have you had? How do you solve those? They're solving it with the same technology stack I am, which means they're solutions I can apply. There's probably not a better place for me to go to learn how to win in these areas. There's that.
Michaela Light: All right, well I'm looking forward to it too, and we get to experience Houston, Texas, which is special as well.
John Farrar: I was in the Navy three hours south of there, so …
Michaela Light: Oh?
John Farrar: Kingsville Texas, which used to be the world's largest ranch. It wasn't just a tale, Texas did have something that big. They rent the Navy base to them for a dollar a year.
Michaela Light: Oh, wow. Well I also want to thank you for listening to most of the podcast episodes we've released so far John, I think you're probably the most active listener. I'm happy to hear from any other people listening to this, who've listened to all the episodes as well. I've had a whole marathon here, we've done 26 recordings in less than month. We wanted to get them all out before the conference starts. I just want to ask people listening if you can subscribe on iTunes, whether or not you listen through iTunes, or Stitcher or whatever, the more people who subscribe, the higher up the popularity stakes, then the more other ColdFusion developers can discover this and help keep ColdFusion alive. Just want to mention that too. If you have any other ideas on how else we can make the podcasts better, please let me know, we're always happy to improve it. Well thanks for being on the show today John.
John Farrar: I appreciate the opportunity.
