1. We're here at Scottish Ruby Conference in Edinburgh, sitting here with Aaron Quint. Who are you?
I'm Aaron Quint, I'm a Ruby and JavaScript developer from Brooklyn, New York, born and raised in Brooklyn, one of the few Brooklynites who was actually born there these days. I do a lot of Java Script development and I've just really been involved in the Ruby community for about 5 years now and now there is is an actual JavaScript community that's pretty exciting. I've been pretty involved in that as well.
I guess it was a JavaScript port of Sinatra and now it's something more. I started it because I just had almost a dream one night that I've been doing a lot of JavaScript and especially in jQuery there is no, unlike Rails or even Sinatra to some extent, which imposes this very constrained structure and best practices at how to organize your code and how to write, how to direct apps and how to separate your concerns. There were ideas in JavaScript, but no one was really talking about best practices or how to organize your code.
So I had this idea "Oh, what if we implemented a Sinatra-like API in JavaScript. Which wouldn't be that hard because where you have blocks in Ruby, you can do function callbacks in JavaScript, you do something similar. At first it was kind of like an experiment - "Will this actually work?" and then I did it in a couple of weeks just like a side project. Then when I actually put it out there and started talking to people, they told me how I can use it almost and from there it's taking off a little bit.
We have a couple of big users it's cool to be in Scotland actually because I got to meet this company - New Bamboo in London - and they've been using Sammy for a lot of their projects. But in terms of what the use cases are, I'd say the big one is for a kind of single page application and since GMail has become so popular, people have realized that building single page applications is a neat thing and using the anchor tag or the hash tag is a way of routing within the browser. You can build more complicated applications and stateful applications in the browser where you can maintain back button history and even have permanent links, but it's not actually permanent links with actual routes that hit the server, they'll be permanent links just for the JavaScript application. It allows you to also keep your code concise and organized and structured so that you know "This code refers to this page or this action almost in this code for this route or this action and not have it just scattered about."
3. Have you seen any use of Sammy on mobile platforms, to write iPhone apps, Android apps?
Yes, I think there are some problems with the that right now, I'd say. Not that it doesn't work. In fact, a bunch of the apps that I've written and put out there I've been lucky to actually after putting it out there be able to take it back and use it for some of my clients and build some neat applications. They all work on the iPhone because it's just JavaScript and it's raw JavaScript and we're not doing anything like browser specific or anything like that.
It works on iPhone, it works on Android really well actually, but the catch is that because it depends on jQuery and jQuery isn't the smallest JavaScript library, Sammy itself is only about 6 K compressed or maybe a little more than that, maybe 8 or 9. That's not a big deal if you are downloading it on a mobile, but jQuery compressed even is like 40-50 K, maybe a little more than that, plus if you want jQuery UI and some of the animation stuff, that's like another 100 K. For mobile, it's not quite there yet.
I know that the jQuery guys have been talking about maybe splitting up the codebase a little more, making it more modular so that for mobile you could just require the core or just require Ajax and not have to worry about requiring all the dumb stuff that you might not need on mobile. Because for Safari, for example, the complex DOM manipulations that jQuery fixes for IE you don't really have to fix for iPhone, you have all this extra code that's part of the jQuery package to do that you're downloading on mobile where bandwidth is kind of a concern.
That said, it's like for building almost GMail, if you've ever seen the GMail iPhone interface not a native app but the web app, you can do jQuery, jQTouch is the kind of plug-in for jQuery. You can do some really interesting stuff with Sammy, like the thing where you can maintain states and when you reopen the browser and it goes directly to whatever message you are viewing or something like that.
4. Have you looked at PhoneGap, the Javascript framework?
I met Brian LaRoux who is one of the main developers on PhoneGap and it's pretty powerful and you can do some awesome stuff with it. I haven't actually deployed anything with it, I played around with it a little bit. I think almost the best part of it is the simulator. I don't know if you've seen the simulator that's packaged with it, but you can actually move the phone in 3 dimensions and see how it affects. Apple is pretty cool, because even in the browser API Apple (at least for iPhone) exposes a bunch of native events that you can bind to almost like for touch and swipe events and stuff like that. Obviously you can't use the camera and things like that, but at least the basic accelerometer stuff you get almost for free.
5. You have another project called Jim, which is a port of Gems?
I do a lot of Ruby work and I do a lot of Sinatra apps actually and a lot of bare Rack apps these days and not as many full on Rails apps. When you are in the Rails, you there is Sprockets (I don't know if you've heard of Sprockets) or Jammit which are these 2 JavaScript compressor libraries where you include it and you say what kind of JavaScript files you want use. Then it bundles them all together in a single file so it minimizes the number of downloads the browser has to do and then it also can compress it too.
It uses the Google Closure Compiler or the Yahoo YUI Compressor to compress it. That's a best practice, too because you can maintain a single file and only have to download that and not have to do all these requires in the code. But, what I found was the problem with those is when I started doing a lot of Sinatra apps and also now I've been doing a lot of CouchDB only apps, like Couch apps where you don't have access to Ruby at all basically in the actual application. I couldn't use Sprockets and I couldn't use Jammit, so I wanted something that would make it really easy to create these bundles of common libraries but also have a way of easily having a repository of JavaScript files I use a lot.
The way Jim works is you actually have a command line utility. It is in Ruby now, people who like it because it manages JavaScript, it should be written in JavaScript, but unfortunately the file APIs and stuff like that for the server side JavaScript just aren't there yet. What it does is you can say "Jim install" and then give it the URL to jQuery and it will actually download the file and put it in this number versioned jQuery directory almost like Ruby Gems.
Then, in your Couch app or in your Ruby app or Sinatra app you just create a Jim file, almost like a bundler Gem file and list out your dependencies in order. Then if you do 'gem bundle' or use this Rack mounted thing, it will just bundle them and pull them together and pull them out of your installed directory so that you don't have to worry about "Oh, have I copied this file into this project yet?" For me - and I'm creating a lot of projects really rapidly or prototyping a lot of different ideas - it makes it so easy to set up and start a project.
6. Are there other package management or package systems in the JavaScript world?
Yes. For the browser side there is Sprockets and stuff like that and there is also a bunch of guys working on client side require stuff where you can, as opposed to defining what JavaScript files you need in your HTML, just embed this little piece of code. There is one called Sexy.js by this guy David Furfero in New York and you just list out what you require and it does it in order and it does it asynchronously. That's for client side. Server side there are I think at least 4 for Node.js basically now, but the problem is no one has decided what the main one is. There is another one for Narwhal too. Narwhal is the system based on Rhino, another server side JavaScript implementation, they have their own package manager. The CommonJS platform, which is a very cool specification for making sure that all these people working on this server side JavaScript things can reuse code between different implementations. It's great, but there hasn't been consensus on how package management should work and the file system APIs and there is no zip library even yet or gzip library. You would have to go down to the command line to do that. It's not quite there yet unfortunately, but hopefully I'm sure someone will come out with one the next couple of months.
7. You brought up CommonJS. Is it a specification, is it a library? What is it?
Common JS is kind of a community effort that has a lot of individual specifications for individual ways. The main goal is to create a common way that these different JavaScript implementations can share code and share ideas because one of the cool things about Ruby compared to where JavaScript is now is that Ruby started with a single implementation, Matz' implementation. That was how Ruby worked and this was the spec and this is how all the file system API should work. Now with the RubySpec and everything even other implementations are implementing against this single spec. With JavaScript there is a specification for the language, like the EcmaScript specification, but there is not really a specification for the APIs that surround the language. These guys, the CommonJS guys are working really hard to get all the different implementations on board so that they can share code and one of them is the packages implementation which specifies a way to share packages between the implementations. It's cool. There are a lot of smart people working on it, it's so new. JavaScript isn't new but this whole new rage about it is so new that it's going to be a while before things calm down a little bit and there is an even playing field.
Yes. They kind of implement the spec in terms of what to do with packages. I'm blanking on the other specs but there are couple of different ones, and every implementer is part of a board who are deciding how we should do this.
9. You mentioned Node.js. What is Node.js?
Node is this very cool project written by this guy named Ryan Dahl who is a brilliant C programmer and who writes JavaScript, but it wasn't even his main concern, he is just a really good C programmer. He basically realized that V8 which is Google's implementation of JavaScript is open source and it's C and if you can wrap it and provide it as a server side API, there are some really cool things you can do with it. But he is also really interested in event loops and writing evented code and he realized if we combine V8 and JavaScript and evented code you can do some amazing things on the server side in terms of speed and organizing applications that people hadn't thought about before.
It's just superfast and there is so much hype around it because it's so fast and because it's so different than all the other frameworks out there and JavaScript implementations. Since he released it about a year ago or a little more than a year ago there has been 6 months or so since he did this talk in Berlin that was what launched it into the stratosphere and since then, there have been packages written for every database, for everything you could possible want.
I think there are more Node.js routing frameworks than there are routing frameworks in Ruby in the past 6 months. It's funny because I think more people are writing packages than are actually using it in production, to be honest. I think eventually it will catch on and people are going to love it.
It's true. I guess it has a lot to do with just the browsers themselves at least for the client side JavaScript and browser JavaScript. It just wasn't possible 5 years ago to do real applications in JavaScript or real animation or even try to compete with what Flash or AIR or things like that were doing with rich Internet applications. Now, because of Chrome and because of WebKit and V8 you can do these insane computations and insane amounts of really cool stuff with it. I think also as the HTML 5 spec has become implemented and you got stuff like Web Sockets and Canvas, there is just so much more power in the browser for doing almost what you could possibly want in a web application. 5 years ago that just didn't exist and now people are like "Oh, JavaScript is actually kind of cool and if I use it correctly, it's actually pretty powerful."
I don't think they are hidden. I would highly recommend everyone to read Doug Crockford 'Javascript - The Good Parts' Book, which I think you are referring to, but he definitely makes some good points about it, but I think the key is that they are not hidden really. The problem is that people are used to using libraries like jQuery or like Protoype, they might hide some of JavaScript's native beauty, I would say and native usefulness and people only go that deep in terms of "All I need to know is how to animate a menu or figure out how to make this DIV open up when I click on it" or something like that. Sure, that's a great way to use JavaScript, but if you just dive like more level deeper there is just so much power and passing functions around as first class objects and being able to basically do whatever you want with functions and have objects that just contain many functions. And bind them to whatever you want and move them around and reuse them and have a function that returns a function that returns a function and have these awesome continuation style stuff that you can't really do in any other language.
12. If the audience is interested in your projects, where should they go?
I have a site, my main domain is www.quirkey.com and on Twitter I have @AQ, and I have a GitHub, Quirkey is my GitHub user name too and I have all my projects out there. I'm constantly adding new ones and I'm pretty good about answering e-mails and answering GitHub issues and stuff like that.