10 Minutes with Tim Griesser

The Laravel conference is approaching fast and I really can’t wait. It’s always great to come together as a community to socialize, learn new things, and just have fun. The speaker line up is amazing and I had the opportunity of interviewing Tim Griesser who is going to be speaking about “Demystifying Modern JavaScript”.

#Can you share a little information about yourself, for those that may not be familiar with your work?

I think I’d actually be a little surprised if many were familiar. So I’m Tim Griesser, I’m originally from the Philly area, recently relocated to the Boston area for work. I love building and contributing to open source software whenever I can. Right now I’m working mostly with JavaScript (client and server), though I have used Laravel quite a bit in the past and still use it for projects here and there.

I help out as a collaborator on the Backbone.js project (I’m sure most have at least heard of that one) and about a year ago I created two libraries, Knex.js and Bookshelf.js which attempt to bring some of the query builder and ORM magic from Laravel to server side JavaScript via Node.js.

#What made you decide to port Eloquent to node?

So I’d started to play around with Node a bit, just to see what all of the buzz was about, and I realized that it’s actually a really neat platform that’s especially suitable for web applications. The paradigm of doing everything I/O related (filesystem, network, database, child processes) asynchronously really makes sense once you wrap your head around it… even more so if you’ve gotten over the hurdle of learning how to play nicely with JavaScript.

As it’s a relatively new technology, the database abstraction scene seemed a little immature. A few ORM libraries existed and had gained a bit of popularity, but for one reason or another each was missing something important. None of them seemed to keep a good separation between the query layer and the model layer, or didn’t support transactions (which are pretty important and difficult to tack on last minute when everything is asynchronous), or didn’t support various relation types. Each good efforts, but really a bit disappointing when coming from more mature frameworks / languages.

So while building some projects in Laravel, and using Backbone’s models and collections client side, I thought – wouldn’t it be great if there were a package for Node that offered the convenience of Backbone’s models / collections, but with the power of Eloquent and the Laravel query builder? I guess one day I just decided that it would be a good idea to start seeing if it’d be do-able. Knex, the query builder was initially an almost 1-to-1 port from the Laravel Query Builder, though the code has changed quite a bit since then. Bookshelf is actually a hybrid of some ideas from Eloquent, but actually takes more influence and patterns from Backbone.js’ Model and Collection foundations.

My major goal with these libraries is to try to dispel this myth that if you’re going to use Node, you need to do so with Mongo, or some other NoSQL variant. Relational databases are tried and true technology, based on relational algebra, and they’re really not going anywhere. I think making them “cool again” in Node by providing strong, well written libraries, and building upon the foundations of other languages and frameworks will really fill a big need in the Node ecosystem.

#I see your topic for Laracon is “Demystifying Modern JavaScript” can you give a few more details on what you plan on covering?

I remember when first taking a shot at learning JavaScript, all of the recommendations went something like “oh just read Crockford’s JavaScript: The Good Parts and you’ll be good”. I recently looked back on some JS code I’d written after doing that and I was horrified… I felt like I’d really missed the boat on which “Good Parts” were important to focus on and which things I’d overlooked when coming from PHP.

The ecosystem around JavaScript right now feels a bit like the wild-west. It’s an exciting time, but it feels like every week there’s a new library, M-V-whatever framework, build tool, package manager, dependency manager, etc. each followed by a number of blog posts explaining why one is better or worse, using very arbitrary metrics for comparison. It can be pretty overwhelming, I can’t imagine how it might seem to someone who isn’t following as closely. Just when you start to learn a new framework, someone comes along and says that it’s suddenly considered to be outdated and you need to be using something else? It’s all pretty much nonsense.

So my talk will try to cut through a lot of what’s going on, give a high level perspective of this wild-west ecosystem, where things are and where they might be heading, and then try to provide some practical tips for working with JavaScript in general as a language that would be just as applicable if you’re sprinkling some jQuery in your Laravel views, or if you’re setting off to build the next big $INSERT_FRAMEWORK_HERE single page app using a fully REST-ful api.

I’m mostly hoping that maybe after this talk, at least one person might like working with JavaScript a little more, or at least hate it less.

Also, if anyone reading this has something JavaScript related they’ve been wondering about, I’m open to suggestions!

#I’m sure everyone is dying to know. Which do you prefer CoffeeScript or JavaScript?

So for library code, I prefer JavaScript, just because everyone knows it so you reach a larger audience of those who will try/contribute to the project. For personal code I by far prefer Coffee. It says everything I want to say in JavaScript, but with fewer lines of code, more expressive syntax which is quicker to write, read, and refactor, and introduces a number of neat little features like destructuring assignment and classes/inheritance – which are possible but a bit of a pain to do by hand in normal JS.

Every time I step away from Coffee for a bit and come back, I’m amazed at how much quicker I feel I write. I’ve definitely heard the opposite though, so I guess it really depends on what you like.

#As a Backbone contributor and user to you ever use extensions like Marionette, Chaplin, or Thorax?

I haven’t personally ever used extensions like Marionette, Chaplin or Thorax, mostly because I haven’t found the need, but that’s not to say that they’re not a good choice. In fact, if you are beginning with Backbone, I’d almost recommend starting with something that provides a few opinions, particularly if you don’t have any. Backbone’s main feature is its simplicity, which also ends up being its curse. It leaves a lot of room for shooting yourself in the foot, which I have probably done myself on more than one occasion.

#Do you ever see Backbone growing to more than the simple library it is now?

I don’t see Backbone growing to more than a simple library than it is now, from the docs its aim is to “discover the minimal set of data-structuring and user interface primitives that are generally useful when building web applications with JavaScript”, and I think it’s held pretty true to that goal.

In the future I’d really like to see Backbone make more use of Promises around any of the REST-ful Model/Collection syncing behavior. For those who might not be familiar, Promises are great pattern for harnessing async code and the dreaded “callback hell” by turning asynchronous operations into a value, which can be chained using “.then” methods, and end up as something like “try / catch”, but across multiple async operations. They’re added officially in ES6 (the upcoming version of JavaScript), and both Chrome and Firefox have recently shipped built-in support.

#What is your preferred editor? Sublime, VIM, etc.

I go with Sublime, mostly because I’ve only been programming for a few years, I haven’t really taken the time to learn anything too fancy. Maybe one day.

#Anything else you would like to say…

I’m really impressed at what a great community come together around Laravel, I’m looking forward to heading to the conference again this year and meeting some new friends!