The Changelog: Software Development, Open Source - Sammy.js and Semantic Versioning (Interview)

Episode Date: April 20, 2010

Adam and Wynn caught up with Aaron Quint, the brains behind Sammy.js, a neat JavaScript framework built on top on jQuery fashioned after Ruby’s Sinatra.

Welcome to The Changelog, episode 0.2.2. I'm Adam Stachowiak. And I am Winn Netherland. This is The Changelog. We cover what's fresh and new in the world of open source. If you found us on iTunes, we're also on the web at thechangelog.com. Or for a real-time view, check out tail.thechangelog.com. Also head over to

github.com forward slash explore. You'll find some training repos, some feature repos from the blog, as well as our audio podcasts. If you're on the Twitter, you can follow Change Log Show, not The Change Log.

And I am Adam Stack. And I am Penguin, P-E-N-G-W-Y-N-N. Such a fun interview this week with Aaron Quint, Sammy JS, a fun little JavaScript framework built on top of jQuery fashioned after Ruby Sinatra. Yeah, it's pretty exciting to have this conversation. Yeah, since we're using it in our project ourselves, it's really helped to organize our jQueries and bring some sanity back to our JavaScripts. Absolutely. So what do you think about this little framework?

Yeah, I'm excited about what it does. I mean, I think having, especially when he talked about multiple applications of SAMI inside of one app, I think it just provides a lot of functionality that we've really been craving but hadn't really had an ability to do. It's nice because it splits the middle between adding some organization to your JavaScript and responding to events and things like that, but without getting full bore MVC on the client like SproutCore, some others that tend to be a little heavier for a lot of projects. Yeah, I think that was one part of the interview I really enjoyed was where he talked about how you can just easily integrate it or just, you know, you don't have to, like, make a large decision to get into it. It's just easy to pull into any project.

Aaron gave us some updates on JSConf as well. Bum that we had to miss that. But we're looking forward to Texas JavaScript coming up in June. Yep, absolutely. It's going to be a fun time down there. The lineup is just outstanding. Well, it's a fun interview this week. Do you want to get to it?

Let's do it. All right, we're joined today by Aaron Quint from SammyJS. Aaron, why don't you tell the folks who you are and why they should care? Yeah, so my name is Aaron Quint. I'm a born and raised Brooklynite, Brooklyn, New York. I've been doing Ruby development for about six years now. And before JavaScript over the past couple months with some little bits of Ruby thrown in. And out of that and out of kind of my desire to kind of, I guess, organize my thoughts and organize these kind of JavaScript applications that I was building. I kind of stole some ideas from one of my favorite Ruby projects, Sinatra, and kind of brought those same API and the same beautiful kind of simple structure that Sinatra has into JavaScript and into kind of the jQuery world with Sammy.js. So Sammy is kind of a, I wouldn't say direct copy, but it implements a very similar API to what everyone's familiar with in the Ruby community with Sinatra, which is kind of simply structure these applications and create kind of single

page apps the way Gmail or Google Reader and a lot of the other Google apps work where you kind of operate on this hashtag so that you can, you know, change the maintained state of a JavaScript app within a URL but without actually reloading the page. And it goes beyond that too, but that was kind of the first, that's kind of the first general overview. And then it goes a little deeper for sure. Yeah, I'm a big Sinatra fan myself. And I think that's one of the things that attracted me to it because in Sinatra, you

know, it's very close, the routes that you respond to with the implementation that respond to those routes. So Sammy's got a really natural DSL to allow you to organize that JavaScript. One of the digs on jQuery is with all this unobtrusiveness. When I was trying to bring a lot of my fellow Rubyists into the jQuery unobtrusive JavaScript fray, they would complain about not knowing where particular functionality was coming from

and where elements were being hijacked. So talk a bit about the routes and SAMI applications and kind of this ability to have multiple applications on a single page. Sure. So actually, to step back a minute too, kind of a funny thing is that where Sammy actually started was, it actually was a,

I'd love to lie and say that it was kind of a 37 Signals, you know, myth that, you know i i built it as part of an app and then i extracted it out into this awesome framework um it wasn't that at all actually it was kind of like i'd been working so much in sinatra and talking about sinatra and working with blake and those awesome guys uh in the sinatra community and I kind of dared myself as an academic experiment to kind of see if I could replicate a lot of the functionality in JavaScript. And first pass, I was able to do it,

but then I was kind of like, okay, what do I really use this for? And it was actually this guy, Alex Lang from Germany, who started using it before I even had a really good use for it and turned it and kind of showed me kind of what I did, which was organize, make it so that this simple API is really useful for organizing jQuery code and organizing and kind of building these applications from the ground up, which is very cool. So the way the applications kind of work is they're centered around, as you said, these routes.

And a route is really just in SAMI, it's a path, a verb, a path, and a callback. So the verb is kind of like your classic HTTP verb, which is get, post, put, delete. And in SAMI, though, that means something kind of different. You know, since we're not actually making round trips to the server and there are no real get or post requests. In SAMI, a get request means you're actually hitting that path, which could be part of the hashtag or it's kind of a location that's stored somewhere.

The location changes to that path. That's a get request. The post requests are actually put and delete to are all focused on form. So if a form submission happens on the page, Sammy intercepts it with the magic of JavaScript and the magic of jQuery and turns that into this, forces it through this route, which then you can respond to and you have this callback function, which allows you to execute on whatever path you're working on. One of the nice things about that, just to interrupt for a second, one of the nice things that I've noticed about that is the param handling inside of those routes.

So it feels very natural if you're Rails or Ruby to have a params hash coming from the form that's been submitted without having to do a lot of form mapping. Yeah, I think it also, in terms of just organizational and sort of your mind workflow-wise, at least for me, I'm realizing that it's very much a Ruby approach and a Ruby and Rails and Sinatra kind of mindset that's driving this and that makes it easy for Ruby developers. It's kind of a bigger mind jump almost for PHP or developers who aren't kind of used to this routes approach. And people I've talked to kind of have to make that mind jump.

But once they do, they understand it. If you think in the workflow of an application like this where you have paths that do specific things and a path is really a state, or a get path is really a state, and then a post path is like an action, when you start thinking about it like that and organizing your code like that

like you said before where jQuery you know jQuery applications can often become these kind of uh chain you know enough chain to hang yourself I guess you could say um and you kind of have a whole page full of these just you know know, bindings to different elements, you know, there's no concept of really state or what page you're on or what action you're on in that, in that kind of workflow. So the goal, or one of the goals of Sammy is that if you start from this kind of application, you're, you're building an application perspective, as opposed to, Hey, I'm just adding some behavior to this page. Um, it're building an application perspective as opposed to, hey, I'm just adding some behavior to this page. It gives you a lot of structure so that you can easily rethink your application or when you're starting from scratch, really lay it out in a way

that other people can understand it and that it's a lot easier to maintain, I would say. You know, while ideas have been borrowed from Ruby heavily in this, we should mention that it's got a very JavaScript flavor to it. So it doesn't feel like you ported one DSL from one language to the next. This is the JavaScript framework. Thanks. javascript framework thanks i think i think um something that uh i really owed a jquery in general is that you know as a as a rails developer and as a ruby developer when i started doing javascript i mean i played around with it forever i've been doing websites since i was like 12 so i mean i you know i made elements on the page blink and I, you know, made

little dots on the screen, follow your cursor, but that's not JavaScript in the way we use JavaScript today. Um, but then when I got into rails, it was kind of prototype was the thing. And though I, though I, I enjoyed programming and prototype and it kind of showed me a way, and I think it showed a lot of people like kind kind of, oh, wow, JavaScript can actually be powerful. My opinion is that a prototype in general, kind of at least the way it is now, kind of hides a lot of the core kind of awesomeness that JavaScript has in favor of making it more Ruby-ish.

And so if you're a Ruby developer and you're coming into Rails and you're like, oh, here's prototype, you make this awesome kind of, you can easily translate the way you've been thinking about applications in Ruby or the way you've been thinking about arrays and enumerables in Ruby easily to prototype. But what happens is you kind of lose the first step,

which I think jQuery at least gave me, which is, oh, in order to learn jQuery, I kind of have to learn a lot more about JavaScript. And not only that, but jQuery really only deals with a very specific subset of browser JavaScript, which is like the DOM and events. And because of that, anything else you want to do, you kind of have to figure out,

oh, I need to figure out what a function is and I want to learn how to organize my code. And that kind of leads you, or should lead you, into kind of learning more about JavaScript itself, which is actually a pretty awesome language. Anytime you actually pull a framework together like you have, you always come out with plugins and different extensions that sort of help you get to a certain point faster.

Talk about the list of plugins you already have available. They're listed in your docs. But more importantly, talk about your idea to architect the plugins the way that you did. Sure. So another thing I kind of stole from Sinatra or tried to steal from the Sinatra community was kind of this, which actually it applies better even in JavaScript than Ruby,

is really kind of forcing myself to keep the core library as small as I possibly can. And, you know, the Sinatra guys, between 0.9 and 1.0, they removed more code than they added. And I think that that was kind of, I took that, I mean, it makes even more sense on the client side when you actually have to download the file. If you can eliminate as much code as possible and make the core as tight as possible, then people can use it in more places and only bring in the functionality they need. So a little while back, I was like, okay, how am I going to do this? And then the beautiful power of JavaScript functions and closures dawned on me, and I realized that a SAMI application is actually just a function,

or a SAMI application block, as I like to call it, even though it's a closure. It's really a function that gets applied to this SAMI application object. So that's an application, but why can't plugins just be the same thing? So plugins are really just functions that are named like Sammy dot something. And all you're doing is when you do this dot use is you're applying the function that is that plugin to the, to the application that you're including it in and adding all the helpers or whatever else you need. So Sammy has this idea of helpers,

which you can use inside of your routes and inside of your templates. And plugins, for the most part, add those helpers. So right now, the main plugins that I kind of use on a daily basis, we have a bunch and most of them are user contributed and I'm happy. I would love to get more people adding them

and extracting functionality that common functionality into these plugins. But the main ones right now that people use are kind of the templating plugins. So we have a mustache plugin that's just basically kind of a thin wrapper around Jan Landhart's and Chris Wanschroth's mustache.js. And then there's a Haml.js one, which is Tim Caswell from the Node community. His client-side Haml parser also has a thin wrapper. I actually just worked on this one that Ruby and Rails guys would appreciate,

but in building this kind of bigger application, I was yearning for some of the form helpers that Rails has, specifically being able to have a text field and have it be auto-populated with an object. So there's this new Sammy.form plugin that I just added recently that kind of tries to replicate some of the form helper functionality that Rails has, but as small as possible. And it's really just putting DOM nodes into strings and stuff like that.

But yeah, the one that I actually, has been around for a while, but people don't actually know about, which I'm going to pull back into core, is this Sammy Google Analytics plugin. Because you can actually track Google Analytics, or track hashtags and stuff like that through Google Analytics. They have a thing mainly for Flash, but

it's pretty easy to adapt for SAMI apps too. One of the ones that I'm excited about is nested params allows you to have those rich, deep object caches if you build your forms a certain way a la the Rails approach. Talk a minute about SAMI storage

and SAMI cache and how you see a front-end framework like this paired with the back-end persistence layer like something you would see from Couch or one of the other NoSQL stores. Sure, sure. So Semi.Storage is basically a really simple wrapper around all or a lot of the options for client-side storage so it can write to cookies

it can write to um html local storage and html session storage and it can also write to jquery data and memory um just straight up basically just a hash. But the idea was that all of these different storage engines kind of have different APIs, so I wanted to try to unify them into a simple, basically key value store API that I could use for storing any local data in an app. I also want to kind of add, I'm looking forward to adding the kind of SQL storage

that WebKit has now and add that as a backend too. But like you were saying, it's really for local storage and almost to allow you to kind of do sessions and stuff like that and caching

in the browser. For backend storage, I mean in the end it's all just JSON being stored as key values. So ideally, the API could be extended to also CouchDB or any other kind of these HTTP or RESTful stores like Couch or even just a general Rails app that you have a RESTful resource and you're pushing stuff up. The only difference is that would be asynchronous. So dealing with that and how you deal with asynchronous storage is kind of a different question, but I'm looking to answer that. In general, Sammy plays really well with these RESTful and server-side JSON stores.

CouchDB specifically has such a cool API. It just seems to fit the web and Sammy so well that I think it's kind of the first choice for a lot of people who have been developing these Sammy apps to just kind of use Couch because it just kind of works. And I'm pretty happy about that marriage, to say the least. You know, I don't think I got the play on words with the name until I checked out the Twitter page, Semi underscore JS on Twitter. It's Semi Davis Jr., right? Yep. As opposed to Frank Sinatra. That's a nice one. The Rat Pack.

Talking a minute about building a successful project, open source project, do you think open source projects stand on their own merits or is it key in finding influencers? Like you mentioned, Alex Lang and I've seen Jan talk about Sammy before. What's the, I guess, the recipe for getting a project over the hump and to a wider audience? Yeah, that's actually a really good

question. I don't know if I have the answer because I don't know if Sammy is quite there yet, but I think there are a lot of things. I think one of the main things that I think, at least for me browsing open source projects, one of the things is documentation. And I think I have pretty decent documentation for SAMI, and I think that's one of the first things that I really worked hard on and I'm continuing to work on. But a lot of projects, it's really hard for,

as an end user, if you're browsing GitHub or just browsing jQuery plugins and whatever it is, to just really jump into something or trust something if the documentation isn't there. And I think a lot of people neglect that and don't really spend a lot of time documenting their code. And it's really, it's time consuming, but it's totally worth it because when you start documenting, at least for me, I often find that I find holes in my API or find, you know, ways I can make things better because if I can't really explain it in documentation, then no one else will probably understand it. So I think that's one thing.

I think the other thing is, yeah, I don't know if it's actually tying yourself to other projects, but I think it's good to, you know, be a part of a – make yourself a part of a community and show how, for Sammy, I wasn't the first one that used Sammy with Couch. It was this guy, Alex, and he kind of realized the potential there. But since then, I've kind of pushed that

and made that connection you know, connection or that marriage clear. And I think that that's helped out a lot in terms of gaining users and getting some momentum on the project. You know, I know what I'm considering a new open source project, whether or not I want to use it in one of my projects. Documentation is key, as you mentioned. What's your breakdown? How much time do you actually spend documenting, Sammy? Because Sammy's got some really nice docs that talk to the API. What's the split between documenting your code and slinging code?

Yeah, it kind of depends, but often I'd say it's at least, I spend at least, well, I guess if you include, you know, working on the mailing list and responding to questions on the mailing list and responding to github issues and responding to um you know uh people in irc and stuff like that if you count all that as like kind of support time and writing documentation all in that i'd say it's almost like 40 writing code 60 support if not more um once you have a project in the wild that people actually use it's it's great at the same time it's also time consuming to actually support it and i think um i'd say yeah if you want if you want actually if you actually want people to use it,

which if you're putting stuff out there, either you want people to use it or just putting it out there to kind of put it out there. And if you want people to use it, I think the, the key is getting other people involved and getting other people to kind of start, you can eventually start delegating support, but for a long time, it's just you. And getting other people involved means that eventual, hopeful eventual goal of a successful open source project, which I guess it's hard to define specifically, but it really means having a lot of contributors and getting a lot of people involved more than just using it. So if you want that, I think, yeah, it's a lot. It's spending a lot of time documenting.

And for me, I just kind of write a lot of inline docs but also kind of try to write these tutorials too. And those are all very time-consuming, but in the end, the goal is that, you know, eventually I'll be able to delegate those tasks, I guess, to other people in the community. I was going to jump out and say it because I think that anyone who's gotten this far into the podcast

has got to be just thinking, what is the sweet spot for Samia? At what point do you decide to turn over a JavaScript functionality to Samia? Where does it really fit into an application? Sure. For me, I wouldn't necessarily suggest that someone takes an application that's totally working and rewrite it for SAMI. I think in general, I think it works better to start with it rather than try to force a lot of applications into it.

However, it doesn't mean that you have to have your entire, if you're writing a big Rails app, it doesn't mean that you have to have any kind of big server-side app and you have a lot of different pages and features on your site. It doesn't mean that the whole site has to be SAMI. In fact, at my current position, we've begun integrating at Paperless Post, we've begun integrating SAMI into different parts of our application. So it's not like the entire web app, which is pretty feature-rich and has a lot of different parts of the site, are all Sammy.js. But we noticed that there are these smaller applications within the larger application that we're using it for.

For example, we have an inbox system where you manage the invitations and stuff like that that you've gotten. And there, it's like, oh, this is a perfect use for Sammy where you're navigating folders, you're navigating different pieces of the invitation, and you're going to details. It's a stateful thing that we can exist on a single page, and that's almost like the perfect use case for Sammy. Just to continue on that thread, I love how Sammy's not an all-or-none proposition.

So with other JavaScript frameworks like SproutCore and some of these others that implement full-blown MVC in the client, you kind of start with either a JavaScript entry point or you don't. With Sammy, you could come into an existing application and say, I think we could take these parts of the application and really organize them and maintain state better just by dropping in a SAMI application on this page. Totally. I think the key with

that is that it's pretty small. When you compress it, I forget the number as of today, but it's less than 15K or less than 20K. And that makes a big difference for when you're, you know, building these big apps. If you want to include something, you know, if you want to include something like jQuery UI right now, that's going to be, you know, 50 to 500K almost. So if you're thinking about something like that, it's's pretty it's kind of like a non-issue to include something like sammy that's so small and because of that i think it's really cool to be able to just bring it in piece the application that i'm working in the big application i'm

working on i've been bringing in you know piece by piece and kind of replacing or using it for these kind of smaller applications but it also um I want to point out, we were talking about Couch before, and in that way, if you're building kind of these, what I like to call these kind of like full client-side applications where either, yeah, and I know some people have been using it within PhoneGap too and within iPhone structure, and that's awesome, but within Couch

and the Couch app framework it's pretty awesome because it just allows you to kind of add structure instantly to data that you have in your database and to kind of this building an application that exists entirely on the client side

which is something I'm really excited about. You really have the choice in templating. You mentioned Mustache and Hamil.js and some of the others out there, but you really have the option still to use server-side templating if you want to do that as well

and just render partials in line. What are some of your other JavaScript frameworks? I know this one's built on top of jQuery. What about things like underscore.js and some of the others that are jQuery add-ons? Yeah, I think Underscore is really cool. That's actually represent, that's another New York City JavaScript guy,

Jeremy, who built that and also CoffeeScript. And he's obviously pretty prolific and does some pretty awesome stuff. The cool thing is because it's really just a jQuery plugin and I really tried to make it as use as few global namespaces as possible and

make it as, I guess you could say, you know, it doesn't really overlap or hurt to include it. I tried to, um, make it really easy for you to build it with other, you know, UI, UI components, jQuery components or underscore or whatever you want. Um, or even, you know, JQtouch, which is the iPhone library that's built on top of jQuery, too. Even though it has its own hash kind of navigation system, you could easily use kind of the, I guess, the UI elements that come with that, too. But as you said, server-side templating works, too. But as you said, server-side templating works too, and I've done that in a bunch of cases where we're really just rendering full HTML and using SAMI almost as kind of just a,

it's really just a controller to control the navigation structure and control the elements that are going to be populated onto the page. I think, actually, you bring up, when you mentioned templating, I wanted to mention that it's actually, that's the, right now we're at SAMI 053, and I'm going to get 054 out hopefully in the next couple days. But I've been wanting to hit 1.0 just because I know a lot of people are already using it in production, and according to Tom Preston Warner's semantic versioning spec, if someone's using it in production, it should be 10 so i feel a little bad about that um so i'm hoping that we can hit

1.0 pretty soon and kind of the big thing that i want to fix for 1.0 is the templating system because i think right now though it works it um it doesn't it doesn't do as much as I wish it could, and it doesn't actually, from, we were talking about support before, and from a support perspective, I've been spending, you know, I'd say out of the, you know, 60% time that I spend on support, I spend 40% of that, or no, like 50 or maybe even 60% of that time dealing with questions around the templating system and rendering and partials and stuff like that. So that's kind of a smell to me that we should do something about it. So I've been kind of stealing ideas and building up a kind of interesting, what I think will be an interesting approach to how we handle templating is based on some of the work that Dave Furbs is doing for LabJS and, not LabJS, sorry, SexyJS, which is a cool kind of sequential AJAX plugin and also kind of the stuff that Tim Caswell has been doing, CreationX for the Step library and the Do library and how he does these really interesting kind of,

um, work with continuations and using functions to kind of progressively progressively to kind of progressive Ajax, I guess you could call it. So tell us about, uh, JS conf and, and,

uh, making bacon. Yeah. So, uh, I mean, JSConf was awesome. I'm sorry you guys weren't there. You would have had a great time.

I can't say enough how awesome Chris Williams or Vujutiki got on Twitter who organized the whole thing and how awesome a job he did. I don't know. I've been to a lot of conferences and a lot of regional conferences and a lot of bigger conferences. And this JSConf is really like kind of this perfect middle where it feels almost like a hacker conf, but as opposed to kind of, you know, young guys or, you know, guys who

are, you know, not that experienced or just kind of trying to learn. It feels like there are a lot. Everyone's there to learn, but everyone there is are a lot, everyone's there to learn, but everyone there is, I mean, I can't speak for myself, but everyone I met was on some kind of other level of awesome. And, you know, between Brendan Eich and Crockford, who kind of bailed really early, but every single talk was just awesome. And even beyond the talks,

just one of the best things I think about JSConf is the hallway track, as you can call it. And I just spent a lot of time hanging out with a bunch of really, really talented JavaScript developers and hearing about their projects and listening to their opinions. And it was awesome. If you didn't see a my talk was a little

off subject chris kind of dared me to do or not dared me but uh we had a kind of long ongoing uh challenge going on that he said he told me that if I talked about bacon, if I made bacon on stage at JSConf, then he would let me be a keynote speaker. So we worked out something, and unfortunately the hotel wouldn't actually let us cook bacon on stage. But I did a little presentation, and I tried to actually tie it back into the JavaScript community about how heritage foods and the whole slow food movement, the JavaScript community

and the development community in general should take some ideas about sustainability and knowledge and respect from that community too. In general, it was a lot of fun. I think you've probably seen some pictures and some blog posts. It's almost been a week since it, or actually as of tonight, it'll be a week since it started. And I'm still not done digesting or processing all the information that I got out of it. A lot of bacon flying around in the IRC channel right now, too. So talk a minute about this renaissance in JavaScript that we've gotten over the, I guess,

last few months, maybe over a year. It seems like, you know, we've got it on the client with jQuery and Prototype before that and some of these other frameworks that made JavaScript suck less. But now it's really being embraced as a new-ish language and being used on the server. And I see that you guys have a new york's uh nyc.js meetup we've got a dallas.js you see i mean the thought of a the javascript meetup five years ago would have just been crazy totally so what's fueling all of this i think there are a lot of things i think one the the simplest you know the simplest explanation is just that browsers are just getting exponentially faster.

So Chrome and Chromium is just an order of magnitude faster, at least for a little while it was. Everybody else is slowly catching up, but faster than everyone else. And that was already faster than every browser a year before that. So I think for client-side at least, now that we can actually build kind of really complex applications and even 3D and OpenGL and Canvas stuff, which we couldn't have even dreamed of two years ago, people are starting to see, oh, we don't have to build a Java app

or we don't have to necessarily build an entire Flash application to sit on top of our server-side application. And because of that, it's just like, wow, JavaScript developers, there's actually a need and desire for talented JavaScript developers now that there wasn't two years ago. On the server-side, I think, you know, server side JavaScript has actually been around for a really, really long time. It's just almost the same thing.

There was never a, everyone kind of thought it was a joke because if you ran Rhino, you know, everyone says Ruby is pretty slow, but Rhino was like an order, like another level of slow. Like if you tried to run, I guess, NVIDIA JS or one of these really early server-side JavaScript frameworks, it was really slow, and it was fun because, hey, I'm programming JavaScript on the server, but there wasn't any actual, you know,

you couldn't actually use it in production. It was just too slow. But now with Node, which is also based on, you know, Chrome's V8 too, the speed is just incredible. And not only speed, but this idea of kind of invented applications is kind of, I think, where a lot of people think the web is heading, which is, you know, kind of these real-time or collaborative web applications that Node and these kind of server-side and pairing in with the client-side frameworks

allow you to have. But I think, I would say what I really love about the JavaScript community is it brings together some of the best minds in all these different communities. Whereas if you go to a Ruby meetup or you go to a PHP meetup, everyone's kind of just doing something different and working on different projects, but everyone's kind of doing very similar things. Especially in the Ruby world, it's like, okay, you go to a Ruby meetup and 90% of the people are doing Rails, and if they're not, then they're working on something else or they're teaching. And, you know, obviously, it's great to talk to people who have a lot of things in common, but there's not as many new ideas, I think, being tossed around as in the JavaScript community. In the JavaScript community,

like I went to jQueryConf last year and JSConf this weekend, too, reminded me of this. But it's just you have so many people whose day job isn't necessarily full-time JavaScript. It might start becoming full-time JavaScript, but you have people from the.NET community. You have people from the PHP community, and everyone kind of has their own ideas that they're bringing to the table. And beyond that, some people are using jQuery. Some people are using prototypes, or the Cappuccino guys, and it's just like, it's just so cool because everyone has so many different ideas to share and really learn from each other.

And it's just a really exciting thing to be a part of right now, I'd say. Yeah, absolutely. I think open source is a pretty wild world to be in, and there's lots of movement. But on that note, in open source software, what's on your radar? What's got you excited about the next big thing or whatever you're really excited about in open source? What's on your radar? after JSConf, one of the big things that I took away was kind of performance and, um, and really thinking about front end performance. And some of the things that, uh, tie into that are, uh, Kyle Simpson's or Getify's LabJS, um, framework, which is, you know, kind of like a progressive download and, um, you know, loading framework, which is pretty cool. And he says he's working on some even cooler stuff after talking to him.

So I'm really keeping an eye on that and hoping I can bring that into some projects. I'd say, you know, CouchApp, I've been a fan of for a while, but J. Chris, one of the main CouchDB guys, and Jan are both working on making CouchApp like an actual usable thing and kind of building frameworks within CouchApp. And this Evently framework that's part of CouchApp now is kind of has – steals some ideas from SammyJS. And at least they admitted that, which is cool. But it's pretty cool and it has some pretty cool functionality built into it um i think i mean i'm still keeping an eye on node and i'm ready to i'm ready to i don't think i'm ready to jump ship from ruby anytime soon but um i've been i've been playing around with it for you know over a year now and it's i'm looking forward to it actually stabilizing so that a lot of people can start building a real

standard lib almost on top of it so that people who actually want to use it for full-blown applications can really make use of it. I think on top of Node, there's the FAB framework, Jed Schmidt's FAB framework, and he talked about it at he gave an actually awesome, awesome presentation at JSConf that he gave a presentation actually at NYCJS about four or five months ago, and I talked to him about it then, and we watched it,

and I think everybody kind of left and was like, oh, what? Kind of had a funny reaction to it because it's a very interesting style of basically turning JavaScript into almost like a really lispy type of DSL. But he's worked on it a lot since then, and his presentation at JSConf was pretty incredible and really did an awesome job of explaining how it worked. So I urge anyone to check that out if they're interested in it. Now, I'm actually really excited about doing the show notes when we do this episode in post,

just to find all the links to a lot of the cool projects that you mentioned, because Adam and I tend to stay on the bleeding edge, but there's a lot of projects that you mentioned that aren't on my radar yet, and I'm interested in checking them out. Yeah. When making notes, you get the one from TP-Dubs, what was that again, Aaron? What did you say that it was his list of? Oh, yeah, the semantic versioning. Oh, semantic versioning.

That's simver.org? Simver.org, yeah. It's, I mean, when he put it out there, it was kind of like just pulling together ideas of how people have been doing it for a while. And I don't think even he would say that it's something new, but it's cool for these kind of, for me as a young developer, and I think for everybody else who kind of maybe hasn't been around in the open source community for forever to kind of put kind of meaning behind the x.y.z numbers that everyone uses. Yeah, I know we're using that as a guide over on the Twitter gem and some others.

Like you mentioned with Sammy, it's not always easy to do, but I'm glad there's kind of a framework out there for giving meaning to the ones, zeros, majors, and minors. Yeah, exactly. Well, thanks for joining us today. Really excited about using SAMI on a couple of different projects. And then when we stumbled across it, we just wanted to have you on

and share the word with the rest of the audience. We appreciate you taking the time. Awesome. Thank you guys so much. I'm a big fan of the show too, so excited to be on. Awesome. Thank you for listening to this edition of The Change Log. Point your browser to tail.thechangelog.com to find out what's going on right now in open source.

Also be sure to head to github.com forward slash explore to catch up on trending and feature repos, as well as the latest episodes of the change log. Outro Music