Tell me about yourself and how you got into development.

My father was a teacher in the New York City public school system in the 80s, when they had a pretty ahead-of-its-time computer literacy program. He’d teach kids LOGO and BASIC, and he’d always be bringing home computers to fool around with. The first one was a Commodore PET, when I was probably four years old. It had a green-screen and a tape-based storage system – I mean cassette tapes, not backup tape drives – and would take forever to load anything, but when he showed me how he could make it play Tic Tac Toe, I was pretty sure he was a magician. Over the years he brought home all sorts of machines – a Commodore Vic 20, a Commodore 64 (that one’s still in his basement), all kinds of Apple desktops, and after mastering BASIC I got into C programming on our first IBM PC clone, making little video games. I started doing some web development in college when I was the online editor for the campus newspaper, and I’ve pretty much been doing web and mobile development ever since.

Tell me about Sails.js. Where did the idea come from? Why did you guys create it?

Mike McNeil created the first version of Sails in 2012. He was convinced that Node.js was a huge technology that would open up development to a much wider audience. All that was lacking was a robust framework to make building web applications in Node easy, the way Rails had done for Ruby. I started working with him about a year later at Balderdash, the Sails.js development shop he’d started in Austin. After working on a bunch of client projects, we began to see a lot of patterns – especially in our back-end development – that could be automated. So we started building a tool to do that, and we ended up spinning that project (called Treeline) into a separate company that we took through Y-Combinator. Since then we’ve evolved into The Sails Company, which is involved in lots of different aspects of the project like maintaining the open-source framework, creating new tools, building apps for customers and providing enterprise support for companies using Sails in production.

Do you still do much javascript/nodejs or have you moved on to something else?

Clearly I’m pretty heavily invested in Node and Javascript, and I think the future’s looking bright there. The most recent versions have a lot of exciting new features (notably native support for async/await, which forever puts the “callback hell” argument against Node to rest!), and I still think Javascript is the easiest and fastest way to get new people interested in development. But that’s nothing against any of the other great technologies out there – my wife and I have a side-business called CraftLaunch that lets Etsy sellers create separate, branded shops, and it’s all written in Python. I like to do some iOS development from time to time just to keep my chops, and I’ve been messing around with Go and Scala a bit for fun ;)

What are your thoughts on the current climate of Javascript? All the different frameworks, etc. Is there a best one? Is it Sails.js? Does it really matter which one people use?

In general, the more the merrier.  More development tools means more people taking JavaScript seriously, which means people caring enough to create better tools, and so on.  When the framework space gets too crowded, it’ll shake itself out, because to be successful you need great support and that means either 1) a big company with a lot of money behind you or, 2) a big open-source community willing to contribute.  Both of those requirements are self-limiting – only so many companies are going to want to compete in the same space, and a developer only has so much time to devote to an open-source project – so less popular projects die off naturally (not that popularity necessarily means quality, but hopefully there’s a rough correlation there!) I can’t speak for everyone, but Sails.js is certainly the best framework for us, and we try to make it the best at what it does.  But strictly speaking, no, I don’t think it matters what you use, as long as it’s not objectively bad (like riddled with bugs and horribly slow) and you know how to use it well.  Whenever someone is starting a new project and asks me what language they should build it in (or hire for), I tell them to do what you’re best at and find people who are good at what they do.  Sure, certain languages and frameworks are good for certain things, but in the end they all do the same thing, so you’re better off optimizing your people.

What are your thoughts on pre-processors like coffeescript and typescript vs vanilla javascript, or things like babel?

We don’t use Typescript or Coffeescript, and we don’t allow it in pull requests to the Sails core.  I understand the rationale behind Typescript, and I have nothing against it, but as far as I’m concerned it’s a different language, and it’s hard enough to keep track of a big open source project even when it’s all in vanilla JavaScript.  Coffeescript seems far less relevant in the world of ES6/ES2017.  Babel is still a necessary evil for front-end systems, since browser support for newer JavaScript flavors varies, but one day we hopefully won’t need that anymore either and the folks behind it can put their considerable intellect to some other use.

Do you have an opinion on, or favorite, when it comes to things like bower, browserfy, web pack, etc.

Sails.js ships with Grunt, and despite some protests from our users, it still suits us just fine (and you can easily replace it with something else).  I don’t have much of a dog in that fight.  Webpack definitely has some benefits when you’re using it with front-end systems that are designed with dependency-injection in mind, like React or Angular2.  Browserify comes in handy especially when writing isomorphic JavaScript (code intended to be run both on the server and the front-end), but you have to be careful not to end up with a giant blob with lots of unnecessary dependencies bundled in.  Bower we’ve tried to love but it always seems to install too much junk – I’m sure there’s ways around this, but nowadays more and more front-end libraries are getting installed via NPM, which is a new and interesting (and at times unsettling) development.  I wonder how @izs feels about it.

What are your thoughts about the current direction of Javascript, some of the newest features, and what’s on the roadmap?

We’re pretty deliberate at The Sails Company when it comes to adopting new tech, so it took us a while to come around to some of the newest features, but life before async/await now seems like a distant nightmare.  A lot of the other new syntactic sugar is pretty great, too.  That being said, the feature has grown considerably since ES5, and every new feature will need to be supported for a long time, especially after browsers adopt it.  So we’re still pretty deliberate, but as I said before, I think the future is looking bright for JavaScript.

What do you think that javascript is lacking most, or what would you like to most see added?

Hmm…a good compiler?  This is coming, I’m sure, but it’s not quite here yet.  Which means that it’s still non-trivial secure the source code for something like an Electron app.

Tell me a little more about treeline.io and your experience creating it

Treeline.io is a tool that allows you to design application back-ends by connecting pieces (called “machines”) together in an online, drag-and-drop interface.  The tool then compiles your designs into a fully-working Sails.js app that you can deploy anywhere – it writes the code for you.  It includes a library of basic machines, and you can create new ones right in Treeline with a built in code editor or, even better, by combining existing machines in new ways.  But the real beauty of it is that the worldwide Node.js community can contribute their own machines and make them available for others to use, so that eventually the ecosystem could grow to the point that you rarely have to actually write any code at all.  Very soon after our initial launch, folks had already made dozens of “machinepacks” for services like Twitter, Mailgun and Twilio, as well as utilities for working with things like passwords. Our goal in building Treeline was to open up back-end development to a whole new set of people, starting with front-end developers who up to this point were reliant on others to build that part of the app.

The experience of taking Treeline though the Y-Combinator program was pretty special, and by far the best part was that it gave us the opportunity to sequester ourselves away from the world, put our heads down and do nothing but work on our pet project for three months straight.  Besides the fact that you can make an amazing amount of progress in that environment, living together for that time really brought us closer as a team.  I’d recommend it to anyone.  Three months is obviously a long time and requires either funding or a nice nest egg, but even going somewhere for a few days or a week can have a pretty profound effect on both your product and your morale.

In the last year or so we’ve taken a step back from Treeline in order to focus more on building the next iteration of the Sails.js framework (and, to be candid, to generate some revenue), but we still very much believe that this is what the future of development will look like.

Anything fun or exciting that you’re working on?

I’m building a six-foot metal dinosaur for my front lawn… or did you mean development-wise? ;)

What do you like most/least about development?

A lot of people mistakenly think of software development as something primarily scientific or mathematical, but when you’ve been doing it long enough you recognize how much art there is to it. Crafting the pieces of a program and fitting them together is like designing and building a complex physical machine – like an engine – and when it all coalesces after a lot of hard work and struggle, I’ll often throw my arms in the air and shout, “it works!” (both my wife and my coworkers can attest to this). My favorite part of development is building tools to help other people get to those moments faster.

The worst part of development for me, in the technical sense, is the frustration that comes from often having to deal with a complex and ever-shifting sea of technologies – browser compatibility issues, library updates that break your code, new phones that no longer support that amazing mullet app you built for the original iPhone. That’s what makes something like Docker so exciting for me. In a more general sense, the hardest thing for me about development as a career is that it can be somewhat isolating, especially if (like me) most of your work is not consumer facing. It’s not the easiest thing to talk about at parties. But it helps to live in a town like Austin where there’s a really great tech scene, with lots of meetups (like the Node.js meetup that my company hosts) and events like Austin Startup Week.

What technology do you currently find exciting?

I’d say that most of my experimenting with new stuff is on the front-end – there’s always interesting new frameworks and concepts to try, even if some of them flame out pretty quick. We’ve been using Vue a lot at work, and I’ve gotten into React/Redux lately, which is really interesting especially when you combine it with Electron to make native apps! But my biggest nerd-crush is on Docker. I presented a native, one-click install version of a desktop app at DockerCon 2017 that eliminated the need to use the command line to set up and run Treeline apps, and it really whet my appetite for what the technology is capable of.

What are you really looking forward to in the future?

A couple of years ago I gave a talk at NYC Camp, at the UN, titled “Welcome to the Machines” in which I preached my devotion to the idea of the Big Red Button – the thing you press that just does it all for you. We are on an unswerving path towards more automation, and it can be a bit scary at times, but I believe that in the case of software development it means removing more and more barriers to entry. I mentioned earlier that I believe programming is an art. At its best, automation allows us to focus on just the art, and leave the more mundane parts (and programming has a lot of mundanity) to computers. Personally, I like writing code, because it’s what I’m used to, but mark my words – the days of writing code as we know it are numbered!

What advice would give to other developers, or general wisdom you would impart to anyone?

Following from the previous question, my advice to folks just getting in the game is to try your best to develop an intuitive understanding of programming concepts, rather than just studying hard on how a single language like JavaScript does things. Not only does it allow you to move more freely between different technologies, but it future-proofs you against sea changes in how development is done. There may come a day when there are no more for loops, but there will always be flow control. Hopefully whichever companies survive the current Coding School Hunger Games we’re having will do more than just create JavaScript drones, because in ten or twenty years it’s possible that a lot of the actual JavaScript will be written by robots!

That being said, this is a great time to be a developer, with more ways than ever to get started and a huge demand for talent. So to anyone who’s interested, I would say don’t be intimidated – start with the goal of learning to build something small, fun and useful to yourself, get involved in some online (or better yet, offline) communities, and before you know it you’ll be up all night making cool stuff.