The Changelog: Software Development, Open Source - Lineman.js and JavaScript apps (Interview)

Episode Date: August 28, 2014

Adam and Jerod talk with Justin Searls about Lineman.js, building for the web with JavaScript, and his abstract "The Social Coding Contract."

Welcome back everyone. This is the changelog and I'm your host Adams to Kovac. This is episode number 128. Jared and I talked to Justin Saros about his work on Lyman JS, building JavaScript apps and much more. Today's show is sponsored by CodeShip, PagerDuty harry's we'll tell you a bit more about pager duty and harry's later in the show but our friends at code ship they're rock solid hosted continuous deployment service that just works

you can easily get set up with continuous integration for your app in just a few steps and automatically deploy when all your tests pass. CodeShip has great support for lots of languages, test frameworks, as well as notification services. They easily integrate with GitHub or Bitbucket and can deploy to cloud services like Roku, AWS, Nojitsu, Google App Engine, and even your own servers. Setup is easy. Takes just three minutes. Get started today with their free plan and make sure you use our code, the changelogpodcast. Again, that's the changelogpodcast. When you use that, you're going to get a 20% discount for three months on any plan you choose. Head

to coachship.io and tell them that changelog sent you. And now, on to the show. Welcome back, everyone. We've got a fun show lined up today. Today is Friday, August 1st. We're actually broadcasting this show, in particular, live on 5x5. We don't always broadcast live, but today is just one of those days where we've got to broadcast live. So, I'm Adam Stachowiak. I'm joined by Jared Santo, our managing editor. So, Jared, say hello. Hello, hello.

And we also have our guest today on the show, Justin Serrells. Justin, how are you? I'm doing fantastically well, thank you. Fantastically well. What makes you fantastically well? I am just really excited to have gotten over the hump on a dozen really annoying things that were on my plate this week after a two-week vacation. Wow. Yeah, I saw on Twitter you said you made it to Friday and you were celebrating. dozen really annoying things that were on my plate this week after a two week vacation wow

yeah I saw on Twitter you said you made it to Friday and you were celebrating I celebrate every Friday yes Fridays are good days we end our sprints on Friday we started going to one week sprints so Fridays are good days is that working better were you doing two weeks previously

we were yeah I think the shortness and the just the fast pace of one week, and it helps us bite-size things better, gives us quicker iterations, has really helped us out a lot. Helps our planning process. I don't know. It seems like we just get through that quicker, and we give ourselves breaks once a month.

We'll give ourselves a week to kind of catch up, and three weeks on, one week off kind of thing. It's been cool. A little sidetrack there, DevTalk. Well, Justin, we have you on the show. To talk about Lineman.js, amongst other things, you've kind of been maybe prolific would be the word, open source contributor.

I first found you, I think, because of some of your work with Jasmine and some of the testing tools that you've put out there. So I've been using those for a long time, but Lyman seems to be a bigger project that you're building, and I appreciate having you on. Thank you. I kind of wanted to kick off the conversation with quoting you to yourself. Oh, no.

That's always a good way. So you can defend yourself. No. I cannot warrant anything that past me said. Past me was not a smart guy. But we have it on tape. So you have to stand by it. You said, and this was recently, I think you've even given talks on this uh as as recently

as was it rails cough 2014 where the title of the talk is the quote that i'll say is that the rails of javascript won't be a framework um obviously we don't have time to go into your 30 minute discussion on that i know you have tons of details um around that sentence but maybe just kind of unpack it for us tell us what that means and why you say that and then maybe just kind of unpack it for us. Tell us what that means and why you say that and then how it kind of led into Lineman, if it did. Yeah, so the talk is broken up into two parts. The first half is a discussion about application development as it is, especially in this era where people are trying to build lots of, you know, whatever you want to call them, fat client JavaScript applications meant to run in web browsers and then phone home to like, you know, a lightweight API on the backend.

So just a discussion of like, you know, what's, what's painful about that if you're using something like Ruby on Rails, you know, the monolithic aspect, the fact that the sort of community has been gradually moving to Node.js and Ruby gems aren't, you know, quite, quite, quite so populated. Then the second half of the talk is like just like a basically like a demo of how we've built Lime and JS to alleviate all of those problems with monolithic Rails application development. But the pivot in the middle, I guess, is maybe what the title is referring to, which is Rails

is really fantastic for a couple of reasons. And I think that over the course of 10 years, what we've learned is that some of the things that we initially loved about Rails turn out to not be fantastic for long-term, long-lived projects. I break up Rails responsibilities into sort of three categories. There's the build aspect, right? Like all the rake tasks, all of the confusingly task-like things that you have to type Rails for instead of rake for. Then there's the actual application framework.

That's the types that you're extending and the active support APIs that you can just kind of reach for wherever you are in your app. And so all the coupling between your custom application code with the framework code and all the lift that that gives you. And then in the middle is just like sensible defaults that you don't have to specify. And then conventions that we all just sort of follow socially, like you learn about from a buddy or from a guide um and and as a result we don't have to repeat ourself from project to project and we don't succumb to uh what i might call like accidental creativity right which you see in a lot of other communities where it's like i've got this 500 line long grunt file over here i'll copy and paste it and i'll diverge it you know uh inadvertently um so when i look back on my experience with Rails,

the hardest thing to learn, but the most valuable part was sensible defaults and convention-driven design. The application framework stuff has a lot of problems. And the build stuff was really awesome in 2005, and it just has not progressed to handle the sort of static assets we're building for the web very well. And so what I want to do is just like cargo call the really great stuff in the middle

and then apply that to front end web development. And what I'm finding is like in the node community, that's like, that's, that's, that's news to them, right? Like they're, they're very kind of Unix velocity. You want lots of different, like an eclectic blend of tiny little modules to work with as opposed to, you know, well, here's just like a default project. And then you can just specify how your project diverges from those defaults. So culturally it's a,

it's a, you know, I feel like it's a point of friction, right? Like you got Ruby on one side who understand this, but they've, they're very much tied up in the Ruby ecosystem and they don't want to leave it.

And then you have like, because Lyman's written in Node.js, you have Node.js on the other hand, where it's like all these people just like don't understand the cultural benefit of that, but they do have the technical tasks and tools to get awesome stuff done quickly. So Lyman comes into kind of, like you said, CargoCult, what you thought were the good ideas in Rails, bring them over to the front end via the command line and give that structure that we so desperately need? Is that what you're saying? That's my hope. And, you know, in practice at our agency, Test Double, where we're like, you know, a consultancy who builds a lot of apps, we've been using Lineman for a couple of years now on most of our projects.

And my favorite thing about it is very similar to my favorite things about rails. Like I can hop into any one of our projects and I instantly know, you know, how to run stuff, how to build stuff, how to get the test running. Uh, I know that it's already set up for Travis CI out of the box and I can just push it. Um, I, I really love that. Uh, if I look at somebody's application config, I can just literally see like them declaring, these are the ways that I'm not normal. So I can understand what's unusual about their build and where their backends are and all their proxies and their server stubbing and stuff is all like, you know, really readily apparent. Um, in fact, if you want

to, uh, kind of broaden the discussion just a little bit behind my tool, I got the chance to finally meet Tom Dale and Yehuda Katz in person this year. And as I've talked to them about their trials and tribulations in selling Ember.js outside of the Rails community, I feel like they're doing an analogous crusade from the Rails community's understanding of what makes a good application framework to Node.js land or just to the web more broadly where people are kind of anti-frameworks because there's so much framework fatigue on the front end. And I think that they're trying to accomplish a lot of the same things, especially when it comes to sensible defaults and common conventions, whereas my focus has been more on build tools as opposed to application framework design. Yeah, so Lyman itself, not a framework, it's a tool, and it works with the front-end frameworks that you would want to use, whether it be Ember, Angular, Knockout perhaps, all of the popular JavaScript frameworks of the day.

So it's not actually trying to solve the application framework problem or structure problem. It's actually trying to solve the build tools problem. It's a single responsibility principle thing. Yeah, exactly. So, I mean, if when you when you say lineman new project, it's going to assume you've got a totally vanilla JavaScript and CSS app and and you just want to build it. But as soon as you say, well, I want to use Ember, then all you have to do is say npm tech tech save dev lineman ember and hit enter, and it'll install a lineman ember plugin that will kind of behind the scenes totally dynamically without generating any cruft or crap in your project,

just modify the configuration and the tasks and the order that they run in so that now you're building an Ember project. And it's doing everything, you know to handle the templates appropriately and so forth. Same thing with Lime and Rails. If you want to proxy back to a Rails application, our goal has been all along to avoid code generation, but make it dead simple to integrate with and build plugins for whatever you want at the top of the stack, whatever application framework you want. We want to be totally agnostic to that. Cool. So if you don't mind, I'd like to step back for a second. We'll get back to alignment and the features and the details there.

I'd kind of like to talk to you a little bit from a consultant perspective. I also run a development firm. And at Test Double, you're making the decisions on behalf of your clients, I assume lots of times, which technologies to use, which style of application they actually need. We've seen this massive move towards rich JavaScript front ends, especially in the edge of the development community. There's lots of problems that can still be solved with traditional page-based or Rails application structure. How do you decide when your clients come to you? Is it just based on the needs of the app? And how often are, a follow-up question, how often are you doing the rich JavaScript clients and how often are you still doing traditional

apps? That's a great question. I think that there's really a third category too, when you try to break down the percentages of how we work. There's a third category too, which is like client already has a system and they need, they need help. And, uh, we're, you know, I think very pragmatic because what we want to be doing is, uh, build trust with the client by meeting them where they are. Um, uh, and to choose our battles, to choose to like, you know, take a stand only where you're making a change from their perspective is going to like, you know, they're going to appreciably benefit somehow. So sometimes like we're, we're working in really eclectic and weird, you know, environments

and we're totally cool with that because if it's solving the problem as well and as efficiently as possible, and it's in a way that's copacetic with the client wants, that's great. But now to your question of like Greenfield apps that we're just building. Most important thing to me is to understand what are they trying to get out of the application? Is user experience really important? Like if they want to have a really fantastic, tight, crisp, enjoyable user experience because somebody is going to be in this application all day long, maybe working out of it, or maybe on the other end of the spectrum, like it's a public facing application, they want to be really sexy and convert a lot of users and build a lot of affect and loyalty. Then it starts to sound like rich client might make a lot of sense because anything

happening locally in your browser is a much tighter feedback loop. And you have a lot more kind of UX tricks in your toolbox. But on the other, you know, on the other hand, if what they need is like, they don't have a lot of money they they don't have a lot that maybe they only have a handful of users and it's a seldom used app front-end application development like with javascript is like significantly more expensive and i think that some people don't acknowledge that because they're so busy trying to sell browser as the runtime everything's going this way but you have to acknowledge like it's doing a lot more work like a back-end rails Rails app is a specification of the user interface. We're just rendering some HTML.

The browser's actually doing the UI programming. But introducing a fat client application is just a much more expensive thing because now you're building two things. You're building an API application and you're building a fat client user interface application. And I try to be as cognizant of the cost of that as possible, in spite of the fact that I'm super duper excited about all the cool stuff you can do on the front end. Yeah, I think I fall in that same category where, you know, it depends obviously on the customer's needs and on the actual business goals of the application that they're building and their

budget and all sorts of things like that. Oftentimes what I find is a very simple, traditional web application can serve companies quite well at first. And you just kind of sprinkle in the JavaScript, the interactions here, make this do that fancy thing. Maybe have some Ajax-based stuff, but still doing the traditional style. And then over time time it gets to

the point where they just keep asking for more and more and more of that to where even if you've been pretty diligent which i try to be with the the structure of the javascript side of the application which has been growing in line count right yep it gets to a certain point where it becomes not unmaintainable but just not as efficient as if this would be an Ember app with an API. Do you guys ever fall into that? Yeah, the worst part about that particular phenomenon is that, let me phrase it this way. Going back to sort of, because was it, Adam,

you mentioned that you just moved to one week sprints. We were talking about like agile stuff. Right. So one of my favorite agile dogmas is when you pull a story card and you're trying to implement it, do the simplest thing that could possibly work, right? I think a lot of agile teams fall into this trap of equating simplest with quickest to get done, right? Yeah, that's the truth for sure. So quickest to get done is let's just spin up a Rails app,

put a view on there, and then, you know, maybe iteration two, three, four, we start sprinkling on unstructured JavaScript and sort of like the, you know, the front end equivalent of like one gigantic main method that we kind of like tease apart in an ad hoc fashion. The problem with what I call like the simple trap is you're kind of going up this complexity hill in a monolithic way, in a totally unstructured way from the front end perspective. And then all of a sudden you'll reach a point where it's just like, you can't go any further. And they want features that would demand of a fat client front end app. Like maybe it's a graphing tool and they want zoom and filter and all this stuff, you can't go any further and they want features that would demand of a

fat client front end app. Like maybe it's a graphing tool and they want zoom and filter and all this stuff that you can't possibly rasterize on the backend. Uh, there's no, there's a huge chasm there. There's no logical way to take the stuff that you've already built and iterate further to where they need to go. You have to, you have to break that monolith up now and, and do some amount of rework and, and build a new thing and breaking it up is really hard. And, and rework is really hard,

especially if somebody else is paying you for it. And you're the one who recommended them the, they go down that path in the first place. So of the greenfield apps, what do you give me that percentage breakdown? Obviously just ballpark it, new projects. How,

how many are fat clients? Of our new projects, probably two-thirds fat client, one-third all back-end. Just like an API to a... What do you mean all back-end? Because as I think about it, I'm trying to think, when was the last time we had a client who actually engaged us for a traditional like Rails view layer? I think maybe a fair percentage would be say like 50-50, fat client web being 50%, and then the other 50 being a combination of just like device integration, network integration, all back end services,

and also maybe a little bit of traditional Rails crud. But we don't see a lot of traditional Rails crud anymore, because I think that the skills have commoditized a bit. And it's, you know, a lot of people can get by just fine on that stuff without needing to call for help. Right. Cool. Interesting stuff.

I think, you know those those decisions obviously as developers or as consultants whatever role we play we're making these decisions on which way do i go so now let's get back into lineman let's assume you know i'm convinced i need a javascript fat client lineman looks cool uh lineman says that its mission statement is to make fat client javascript web applications as easy to build as traditional server-side html web applications that's your guys's goal so what are the killer features what makes lineman awesome to work with so um caveat of uh when you're the person who built the thing you you you you use the thing differently than than anyone else will use the thing. My usage patterns of Lyman are probably very different than most of our users. So I can only really speak for myself because I'm not very good at marketing this thing.

I spent like a year and a half to build that talk that you referenced at RailsConf. My usage is I really like rapid prototyping new ideas quickly, right? So I previously have been using Rails for rapid prototyping, but when it came to JavaScript interactions, I love being able to say, Lyman, new foo, create a new project I got to build already, and I can just start writing code and it's immediately showing up in a browser. I like the consistency from project to project

when we're all building Lyman applications. I like that we can take a common bit of, one of the biggest Lyman users is Rackspace. So there's a group at Rackspace that's doing internal tooling. And one of the cool things that they can do is they have like a sort of standard stack of Lyman plugins. And Lyman actually supports meta plugins too. So you could say like make a plugin called Lyman Rackspace.

And all it represents is like pulling in all of the plugins that it depends on at the versions that they specify and maybe any sort of deviations in configuration. So you could literally, as like an organization, just settle on like, this is our default, you know, initial project stack and be off to the races on a new project in like two command lines. The other thing, the other kind of half to the equation, other than the fact like what Lineman doesn't do, like unlike Yeoman, it doesn't generate a whole bunch of garbage into your project that you can't tease out later can't upgrade later or have to deal with you know a community that's not supporting your your your uh bootstrap nonsense um the other thing that that i think is really great about lineman is it you don't have to throw the baby out with the bathwater from a server side perspective. Like if I'm building a rails application,

um, and I just want to, you know, do the next major feature on a standalone page as a lineman application, that would be a fat client JavaScript application. I can build that lineman application at in a world where that's the only thing that exists totally separately, totally physically divorced, but then lineman has features to proxy back to the Rails application easily. So like any request that Lyman doesn't know how to handle, it'll just phone home to Rails. And that way you can develop against Lyman support, but still be inside of your Rails application and get all of the benefit without having to completely redesign your Rails application to be completely just like, you know, API, API only, or divorced from any

hint of ERB or templates that drop in little JavaScript variables. So you can get up and running on almost any project immediately, even if it's a long standing existing one. It's not only for Greenfield projects. So do you just check that code into your main app then? Or do you have to keep separate repositories or either, I guess? Either. It depends on, you know, a person's priorities. If the, if the team has already figured out, cracked the nut on how to do deployments well with multiple repos at multiple versions, then this is just another repo. And just like you'd probably put your iPhone or Android application in a separate repo, it can make sense to put your fat client JavaScript application in a separate repo

because at the end of the day that's all it is it's just another client to your api but i think for most people especially right out the gate um because versioning is extra hard and because the deployment story can be more more complex just adding that to your repo as like another root directory is probably a-okay um and then on the the benefit of doing it that way, too, is that we have a gem for Rails called RailsLineman that you just merely install the gem and tell it where your Lineman app is, and then whenever you run rakeassets precompile

as part of your deploy, it'll actually do a Lineman build, sneakily shove that into your public assets directory, and so you don't have to configure it, but you actually get all of Lineman's assets for free without having to think. Let's pause the show for a minute and give a shout out to a sponsor. If you've ever gotten to work only to find out something happened while you're out,

the server's down, customers are unhappy, chaos everywhere, you got to listen up. One of our new sponsors, and I'm excited to have them on board, PagerDuty. PagerDuty eliminates the noise, chaos, and manual processes to help you streamline your entire incident lifecycle and ultimately decrease the amount of time it takes you to resolve issues. You can get reliable IC alerting and on-call management. You'll receive instant notifications when incidents are reported so you can quickly resolve those issues. They're trusted by companies like Etsy, GitHub, Nike, and we want you to try them for free. Sign up today for a free 30-day trial at pageofduty.com slash the changelog and tell them the changelog sent you. So you mentioned Yeoman briefly, and it seems like if Lyman had a competitor, it would be Yeoman, both tools trying to provide help for front-end projects.

Yeoman is a combination of Yo, which I believe, and you can correct me if I got details wrong, but this is a scaffold generator, a co-generator. Grunt, which is the task runner, and then Bower, I believe, or the dependency management of some kind i think it's bauer um how does lyman compare to yeoman pros and cons of either side um we have a a table up at lymanjs.com where i spent some time answering specific questions from the community about this and i wish i had in front of me um so so to LymanJS.com, check out the table for probably better answers than this. But my off-the-cuff reaction is that Yeoman misses some opportunities that Lyman seized upon. And it does some things that I think are very attractive for adoption purposes, but long-term have a poisonous effect on the sustainability of projects. One of the opportunities that it failed to realize is that there is a higher order concern

than simply running tasks. A build is really, you know, like its own domain model. It runs tasks, but it has to figure out the order and when and how to do it in a way that's like maybe, you's maybe iterative. Like if, say, only one file changes, just compile that one file and find a way to graft it in as opposed to rebuild everything on every single file change. So there's a whole bunch of build responsibilities that they just kind of left on the table that something like Joe Liss's broccoli tool was built to be.

The other aspect that stands to me about Yeoman that really bothers me is that it's got all of these community driven generators for you. Like they've got this website that's like, you know, pick which of the 15 bootstrap three generators you want. If you want to pull or like start a bootstrap project, or if you want to start this project here and some of them are in total disarray,

some of them are relatively maintained. Some of them are maintained, but they actually have like very weird or, or incongruent opinions about how to do things well. But all of them just generate a lot of cruft that you then have to commit into your repository. And when you do that, if you need to upgrade later,

maybe none almost none of those generators have clear sane upgrade paths so it's like you're making a project and it's like at this point in time this project will and forever will be you know tied to this version of this one particular tool because we chose to you know uh get the convenience of an easy quick start um uh with without you know having to have paid the cost for a tool that sort of like embedded conventions for us it just sort of handed all this stuff um and that really that really bums me out because when i see that there's not a lot of help i can do for people other than recommend that they start fresh yeah i've used yeoman a little bit for a

few small angular apps and i can definitely those statements resonate with me. I found your table, by the way, so just a few other things here that you missed. You provide HTML5 push state simulator built in. I think really the big differentiator from my perspective is the testing story. So Lyman seems to provide, for those interested in writing tests for their JavaScript, which is a pretty good idea if you ask me, you have a test runner, you have API stubbing and stuff like that, so that you can easily get started testing. Can you talk about how the test runner works? Yeah, so the test runner that we use is called Testum, and it was written by a great developer down, I think it's in Atlanta, his name is Toby Ho. And Testum is a test runner that was written by a great developer down, I think he's in Atlanta. His name is Toby Ho.

And Testum is a test runner that was written to be completely agnostic of the test library. So you can use Testum with almost anything. You can use it with, obviously, QUnit, Jasmine, and Mocha, the big three. You could use it with Casper. You could use it with almost anything you want on the library end. And then on the other end, it's able to capture lots of different browser environments with a little tiny script and some socket IO. So you can easily run your tests in any browser you like, like, you know, whether that's IE, Safari, Firefox, or what have you, or mobile browsers or different devices on your network if you have a device lab and so forth.

And it does all of this with a very sexy and curses-like terminal UI that lets you arrow between the different user agents that are running your tests. You can see how the error messages might differ from one to the next. And then it sort of ties a bow around all that with a very nice CI mode. So this is all the interactive mode, but in the CI mode,

it'll run under PhantomJS and it'll give you, you know, any format you want, like whether you want the JUnit style XML formatting or whether you want tap formatting so that you can, you know, aggregate those results in your CI system. So Testum is really like, Toby did 100% of the heavy lifting there. What Lyman does, just like it does with all of its grunt tasks that it runs

and everything else, is it just provides a default configuration that just works out of the box. And this is maybe a little selfish, but I also shove all of my Jasmine test helpers that I've built over the years into your helper's directory for you right off the gate. And I do that because I use them and I was sick of downloading them, but hopefully people find some benefit from that as well. Cool. Yeah, that leads me to my next question because we talk about downloading helpers and whatnot. Another big differentiator, Yeoman, the third part of that would be Bower, which is, you know, it's not really dependency management, but it's a downloader, so to speak.

Lyman seems to just completely punt on package management. It's true. Yeah. Is that purposeful? It is purposeful. You got tired. It's very intentional. And I think that it's a couple of years ago now, I wrote a blog post called Unrequired love about required js um and how i think that in open source my goal has always been to identify areas of pain and then think really hard about why am i feeling that pain

and then and then sit and then think really hard again and then eventually start writing tools to alleviate that pain somewhat and i feel like the obsession with front-end package management tools, whether it's Require or Browserify, or to the extent that people use Bower as a dependency management tool, when I agree with you, it's not really. It's more like a very fancy downloader. What I worry is that they're identifying the pain of, I've got all of these third-party scripts everywhere, but then they apply the wrong prescription, which is, let's give me something to manage all of these third-party scripts. When a better prescription would be, let's write leaner, meaner applications that don't, you know, that are architected well enough that we can solve a lot more of our own using packaging tools to kind of organize and require explicitly their own code, like say I've got a model that my view wants to use, I require that model from that view.

There's nothing wrong with that. It's just it's not built into JavaScript. It's not part of the language and it's not something the browsers understand yet. And so you're kind of marrying yourself to this one-off implementation that will probably look silly two, three, four years from now. When you could just solve it the way that, you know, by respecting what a JavaScript web application really is, which is the, you know, it is equivalent to the concatenation of all of its listings. So just know how to concatenate it right, and then you're done. And better yet, write code that is order agnostic and design systems that don't matter what order you load stuff in. So then you don't have to even worry about what order it gets concatenated in. Those are the ways that we've tried to solve those problems. Now, people like to use Bower.

We have a Lineman Bower extension that you can use with lineman but i personally have been frustrated by it for for a lot of reasons one is that it by default will go and grab master of your github repo and that's not a release right it's got a version probably in a file somewhere uh but it's it's going to be divergent from the release which has caused a bunch of my friends who maintain libraries to freak out because now they're getting all these issues filed against stuff that's happening in master when people are just grabbing the wrong artifact uh it encourages organ uh like open source maintainers to start committing generated artifacts and then track that separately so then the source of truth of like it is just counter diversion control in my opinion um and then the worst part kind of belies your first statement, which is, well, it's not a

dependency management tool. It's a downloader. Like the fact that it seems like a dependency management tool gives everyone a false sense of confidence that it's doing things like, you know, negotiating version conflicts and transitive dependencies, you know, that every single time you download a specific version of a dependency, you're getting exactly the same one. Like you would be from NPM or from Ruby gems. You're not. And so those people using Bower are like, well,

don't commit your, your vendor dependencies because you have a Bower, like part of your build, we'll just pull those in and then you'll do a build and then they'll just be kind of transient. It's, it seems totally backwards to me that Yeoman on one hand will generate all of this cruft. That is literally your uh, that you don't need and that

you can't upgrade. Uh, uh, and then on the other hand, not commit the actual stuff. That's like literally your runtime, the system that you're building, uh, that, that isn't controlled by you shouldn't be controlled by you. So I feel like it's just coming at a lot of these issues from diametrically opposed perspectives. Yeah. Yeah. So what do you do then?

You just like W get the file into a vendor and then you just, I mean, just old school style? Old school, man. Yeah. It, you know, if it, if it doesn't hurt, if it's not broke, don't fix it. I just have not run into the problems of scale that some other people I've talked to had, like, you know, basically anytime I get into a 50 cuffs internet fight with somebody about

this, they eventually pull out like, well, my app is eight megabytes of compressed JavaScript. So I have these problems. I'm like, okay, cool. But don't turn around and like offer this as generic advice of like best practices that everyone should be doing, because whether that was a necessary eight megabytes of complexity, which I doubt or not, it's just not representative of most web applications.

It's a problem you can push off till later. And every time I see people try to adopt it on day one, whether it's Browserify, Require, or even Bower, it just introduces all of these stupid engineering problems that are a distraction from the goal of building an application. And Lineman's all about getting up and running and building an application quickly and not having to worry about those stupid engineering problems like they built get focusing on your build and so forth um and uh it seems to just not respect the cost of that right on

so lineman you know lineman js, the name is Lyman.js, but if you go to GitHub and you click on the language statistics, 59% CoffeeScript, 40% JavaScript, but I can't actually find where that JavaScript is coming from. It seems like it's all CoffeeScript.

I think it's probably in the archetype, which is the project that gets generated when you Lyman new, there's JavaScript in that. I thought maybe there was some sort of thing that was automatically built that had the JS in it or something. No, and in fact, I understand why there's a – first of all, there's the natural reticence to CoffeeScript in the broader outside of Ruby community. Yeah. in the broader outside of Ruby community because it's different and it's nonstandard and it is, you know, it looks foreign if you've not used a dynamic language before,

and it looks foreign to some Rubyists who've never used a white space sensitive language before. Personally, I'm sold because I, you know, there's myriad benefits that we could talk about separately, but the things that are important to me is I want to write code that's as clear and as reliable and understandable and maintainable as I possibly can, because maintaining open source is hard. But I want to be handing people code that they can run with and easily understand and make sense of. And so when you install Lyman and then run Lyman new and make a project, everything is all JavaScript. No CoffeeScript gets generated unless you use the tack tack coffee option to convert all of that to CoffeeScript for

you. And so I feel like it's a kind of a straw man argument. You're not the first person to bring it up. Some people have literally been like, I won't use this because it was written in CoffeeScript. And that just seems to me like it's coming from a point of entitlement, right? Like I refuse to spend the 30 minutes it takes to learn CoffeeScript. Because it's really a very, very tiny language when you think about it. And therefore, your thing sucks and we should all not contribute to it and we shouldn't use it. Right. Plus, as you say, this is a tool that you use. And as an end user, it's a nothing to you, what it was written in, right?

It's generating JavaScript for you. It's a command line tool. It shouldn't matter. That being said, as you said, some people, they're very averse to CoffeeScript. Have you gotten a lot of that kind of feedback with Limeit? Maybe even on the contribution side, how have the contributors worked?

Contributors have been fantastic. I mean, I always want more of them. I guess I'll break that up into two questions. First on contributors, I feel like because we've been using this every day for two years on almost all of our client projects, Lyman solves the problems I needed to solve. And it is mature from my perspective. I mean, we never did a 1.0 release, but it does almost everything I need pretty well. And there's things I want to fix, like there's rough corners, but I can live with them pretty well. And so when people open issues or have problems, I would really love if they would more often contribute to the project because their itch is not my itch. And so I could half-heartedly go and try to build it for them. But really, there's just sort of a depression that sinks in when you realize that you're

spending a lot of time just trying to make other people happy on the internet for free, just like arguing on the internet. And it bums me out when people kind of like open an issue from a state of entitlement, like, hey, your thing's dumb because it doesn't do this. And then I get the thing in my inbox and realize I'm blocking somebody and I feel really guilty and I feel beholden to them to like, you know, go implement that thing. When, you know, 90% of people never even offer or think to open a pull request. That just, that bums me out. And now I've forgotten the first half of the question that I also was excited to answer.

Oh, just if you have a lot of so-called haters because of the copy script. I think there's an interesting point to this too, which is that, uh, coming from the Ruby community where like, I think that like, I see the same hundred, 150 people at all of these Ruby conferences across literally the world. It's a much,

much smaller, tighter knit community. And as a result, we kind of all like, you know, there's a monoculture aspect to that, you know? Yeah, we have debates and arguments, but then things settle down and we either separate into camps or we just sort of adopt the new way. You can't do that with

JavaScript because everybody is stuck with JavaScript. The whole world is writing JavaScript and they're all from these different tribes and these different heritages and different backend environments. And so a lot of times I'll see people, whether it's from Ruby or Python or.NET or Java, they will enter the JavaScript world with nothing but the perspective of their backend experience. And then they'll immediately freak out because they can't see any agreement. Like, what's the right way to do X, right? What's the standard way to do Y, right? What's, what's the standard way to do Y? And the answer is like, of course there is no right way. There is no standard way. Um, and, and you have to kind of identify just to signal to noise, you know, manage your

life. You have to identify a group that, that seems to agree with you well enough that you can be productive. Uh, and one of the ways that I have sort of self-selected a group that seems to agree with you well enough that you can be productive. And one of the ways that I have sort of self-selected a group when I'm working on Node.js stuff is if somebody comes to me and says that because I write CoffeeScript, my project's dumb and I'm dumb too, I'm like, boom, bozo button. Yep, you're out of my tribe. The world is much too big for me to feel like I have to make absolutely everybody happy. Please tell me you have a real Bozo button. I was going to say, I like that button. I want that button. Well, I tapped on the lid of my water bottle when I said it, so

that'll be the new Bozo button, I guess. Can you start that? Yes, right? And it just automatically blocks them on Twitter and GitHub. There could be an API on everything for it. Yeah, yeah. I love this because open source is so interesting.

We have the purely technical aspects of it, right? Which we can talk about all day long and debate and evaluate and improve and all that. And then you have the social meta, kind of like the people of open source and all of the interesting and and troublesome uh situations that arise around that um then you have the corporate the corporate aspect where we see more corporate backing of open source um licensing like there's all these kind of conversations around open source that we can have and we do have um and justin you have a talk that's coming up you've been you've been working on it you have an abstract called the social coding contract which i think speaks into this milieu of the the community the open source

community especially in in the world that you run which is really the ruby and javascript community specifically um i'll just pull a quote you sent this us. I'd love to talk about it a little bit here. I'll pull a quote out of this. It's probably not going to get a gist, but it's my favorite paragraph. And you say, sometimes I swear I can feel a teetering sensation from how precariously our applications are perched on top of an ever-growing web of open source dependencies. Fears that our tech stack is about to topple over have been fomenting in recent years, but are those fears founded? That's kind of the question you pose.

You have a specific scenario which kind of leads to this. Go ahead and speak into that and tell us your thoughts on this. Yeah. So I think the zeitgeist right now is a little bit cynical, at least among the people that I follow on Twitter and that I engage with in the community, is that we've been on this sort of, we've been riding this rocket of ever increasing convenience in the open source world. It used to be the case that open source was a pain in the ass. And you had to be really thoughtful when you pulled in an open source dependency. Not just legally, but literally. Pre-GitHub, pre-all of these cool dependency managers. I remember the pain, even in 2004, of getting a jar

and getting that jar in my class path and working in my Java project correctly. Whereas RubyGems made it quite a lot easier. Bundler made it easier still. NPM makes it almost comically easy to both publish dinky little scripts and also to consume them. So from a package management perspective, it's easier and easier to slurp in new dependencies

and it's easier and easier to publish new ones. And so because there's so many solved problems out there and no one wants to feel like they're reinventing the wheel, every single application becomes a kind of defined by the 15 totally disparate things that it stands on top of. for the most part, white dudes in their twenties doing it in their spare time, who might, you know, probably have a 40% chance of never committing to that thing again. Right. And that is what runs the world software. You know, that's, that's what runs pretty soon, you know, real-time systems, even not like that. Several friends who work in real-time systems, this trend is coming to real-time systems, trend is coming to real-time systems things that run hydroelectric jams things that run airplanes right those embedded devices are getting so strong now that they can realistically run you know uh if not dynamic languages certainly stuff like rust and go and that's been brought up in this culture

of of of convenient uh uh open source grabs, we're seeing in the news constantly all these open source projects that literally 80% of servers rely on be like, oh, there's a gigantic security hole and everything we thought was secure for the last 10 years on the internet wasn't. Oops. We have all of these,

basically like you could almost just paint your application as a graph of single points of failure. Like here's all of the millions of things that could go wrong, that could break us. And we don't understand any of them because our understanding stops as soon as we've typed the name of the gem into our gem file or the name of the package into our package JSON. And so the thrust of the talk is like,

not that this is necessarily bad and we're all doomed. It's that users have, I think have a much greater responsibility to understand what dependencies they're pulling in, who's maintaining them under what pretenses, not just how it's licensed, but how is it being built? Is there a healthy community around it? Is it small enough to not be an albatross, but is it big enough to have the gravitas necessary to be able to rely on stable releases and fixes in the future? And I think most users have kind of just lowered their standards over time as the convenience has gone up.

From companies that use open source, like you mentioned companies, companies have a similar responsibility. They're getting a tremendous lift, a huge amount of free value from open source. And if I think of my friends who work in enterprises, they have carte blanche ability now to use whatever open source they like. Maybe they have to run a license by a lawyer or something. But then if they try to spend two hours to submit a patch, basically they have to either use vacation time and then still talk to the lawyers, or they just don't and can't. And I think that corporations that are using open source

and getting all of this tremendous value from it have a responsibility to give back something. And I don't know exactly what that is yet, but that's some of the stuff I'm going to be chewing on for the talk. But maybe the more interesting part to me, because I publish a lot of open source and not everyone does, is I want to kind of peel the curtain back a little bit into just like, what's the psyche of an open source maintainer. And for me, the saddest thing about it is that I build tools to solve

problems that I have. And I get some day one gratification of like, man, I just solved that problem that I had. I granted, I spent all day on a tool to solve the problem when I could have solved the problem some other way in 30 minutes, but you know, now I've automated it and that's fantastic. But then days like two through end of the project are, well, I had that first problem, but now almost all of my problems are maintaining this thing that solves that same problem for other people into perpetuity. And when you build a thing because you wish it existed in the world, you don't get to enjoy it the same way as if it had already existed. Because you have to maintain it.

You have to worry about it. And you have to take the heat when it doesn't work out for some stranger on the internet. And all of those things really contribute to the sort of burnout that we see in open source. And that burnout feeds directly into the instability of all the dependencies that we stand on. So there's just this, uh, healthy, unhealthy burning of the candle at both ends that's going on. Uh, and it's structural and we have to really think radically, I believe to, to figure out what's a sustainable way forward, um, for all of these shared tools.

Cause granted everyone, no one wants to have to like, you know, resolve all the same problems in every single enterprise and just sort of have like this big nasty dark closet of of real reinvention uh because that's you know similarly hugely error-prone but there's got to be a better way uh to to sort of just find like that's why i called it the social coding contract like we have to find some sort of cultural mores to shift both our expectations as users and also how we view maintainers. They are not these superheroes that have a bajillion stars on GitHub and have figured out how to do software. They're mostly just people who published a thing and it got popular and now their life is dominated by that thing.

Let's pause the show for a minute. Give a shout out to a sponsor. This sponsor is Harry's. And for many of us, man or woman, shaving is an absolute pain. It sucks. It's uncomfortable. Nicks, cuts, scrapes, razor burn, plus the razor blades today. They're just crazy expensive.

And that's where Harry's comes in. They started by two guys who wanted a better product for shaving without having to pay an arm and a leg to get it. Harry's makes their own blades, and they ask why pay $32 or more for an 8-pack of blades when it's just half the price with Harry's. On average, an everyday shaver saves about $150 a year on blades using Harry's. To wrap it all up in a nice pretty bow satisfaction is guaranteed visit harry's.com right now and harry's will give you five dollars off if you use our special code changelog with your first purchase that's h-a-r-r-y-s.com and enter the coupon code changelog at checkout and you'll get $5 off. Start shaving better today.

Wow, so do you have any radical ideas or are you just kind of broaching the topic at this point saying this is something that we need to talk about? I have some, but they're probably too early to speak with with any confidence. I think that the um the overarching message is going to be that that both parties need to meet in the middle right users need to have a deeper understanding of what they're using you need to like default to open up source and

look at how the source works and contribute back a little bit um because only through having the deeper understanding of what you're on top of could you ever hope to contribute. There's like this demystification that occurs when you actually look at the source of the thing and you're like, oh wow, that guy was a human. Huh, I thought it was magic. Yeah, there was a real moment in my technical career as a software

developer where I went from being too afraid to do that to that becoming the first thing I'd do almost immediately. Sometimes to a fault where I'm like, like too afraid to do that to like that becoming my the first thing I do almost immediately sometimes to a fault where I'm like I'm gonna blame this dependency when really just my code is got a bug in it but but like I agree with you absolutely like you as users of open source like we should be hopping into that and being able to diagnose or try right it's difficult for beginners to do those kind of things but um you know the earlier and sooner you do it and dive into the mucky muck so to speak

the sooner you realize like it's not magic in here this is this black box has parts that make sense and some don't work and some do and and you grow as a developer as part of participating in that process i think that's changing though i that process. I think that's changing, though. I think for beginners that's changing because of the source being so pointed to and pull requests being so social now. I think that's beginning to evolve. I think people are becoming more and more aware that their first resource should be not just asking your buddy, hey, how does this work, or ask the maintainer,

hey, where's the API for this or the docs for this or whatever. It's like digging into the actual code themselves. I think that thought, Jared, is kind of evolving a bit. I agree that it's evolving a bit, and I think that GitHub and pull requests have helped. But one of the things that's actually, I think, kind of unfortunate is that our tools have taken several steps back. I talk about just focus on Ruby and JavaScript today, say. Like Ruby's debuggers aren't fantastic. Ruby offers a lot of introspection capabilities

of like what's going on in the runtime, but not a ton of introspection about like, where's this source and what is it? And how do I open it? Node is about a bajillion times worse than this because debugging, you know, what's going on under the covers is notoriously difficult, to the point that, you know, the operational standard in Node is like, oh, well,

yeah, every single Node process leaks memory like a sieve, so just make sure that operationally you can bounce those servers whenever you need to. And it really starts to feel after a while like a black box, like what's going on under here so i guess i mean one one approach would be invest the time in tools that make that lower that that barrier of entry to to hop over into the source code or even just like exclaim and visualize it and put it in your face even when you don't ask it to so that like you know sort of like code folding right in browser in editors what if you could just like every time you called a third-party API, you could unfold that code and see the source of that method, like, in every editor? That sort of stuff would just dramatically, I think, increase the level of engagement from users.

Yeah, absolutely. You think perhaps languages like Go and Rust have easier time developing those kind of tools that we would have in our communities just because of the nature of the languages. It seems like this thought kind of came into focus, you said, when you took over RSpecGiven recently after Jim Weirich's death. I know you are a huge fan of Jim Weirich. Can you speak to that, kind of the process of taking over, and just anything you'd like to about Jim? Yeah.

So I've taken over the project with another wonderful fellow named Doug Elkhorn. He's at Gaslight Software in Cincinnati. And we've taken it over in name only. We haven't yet actually started digging into the code and starting to work through the backlog of issues. But it's funny because we started this process like five months ago and we only like got Ruby gems access a few weeks ago and we're only able to announce it like last week. And a big reason for that was a combination of situational problems that are very common.

I believe that like Jim didn't specify this kind of stuff in a will, right? Like who's the executor of my open source cache? Like who runs rake now? Right. And as the world ages, as like all this open source is around longer, we're going to have to deal with this. Like literally like you need a living will for your open source. You need to specify whose copyright it is if you die and who can maintain it because places like GitHub, we have since learned, will require stuff like that legally before they can just hand you a repository. It's not enough that the guy passed away. A lot of other services are very accommodating, but maybe have less rigor about that kind of thing. But then at the same time, they're also operating on shoestring budgets and they just can't handle the, the,

the volume of customer help requests that they have. So like Ruby gem specifically, they don't have the funding to, to spend a ton of time on support. And so it took quite a while to get feedback from Nick and Evan about, about how to move forward. So, so situationally that was,

that was painful. I think, I think just structurally what i worry about is that we we just aren't geared for for sharing dependencies with other people sharing control with other people i guess the other half of the talk to get to give you sort you, we talked about the user responsibility. The other half of the talk is maintainers generally built their stuff to solve their own problem. And when somebody else wants to help, they're solving a slightly different problem.

They're solving a variation on the problem that is colored by their perspective. And as a maintainer, I don't want to cede control to that guy. Cause he's going to like, you know, if he's really active, he's going to kind of pull the project away from my center of gravity towards where he wants. Maybe it's how he codes things or maybe it's what it does and how it does what it does.

And so I think a lot of open source maintainers, even though they're great people tend to be kind of control freaks because they've been burned, you know, however many times with pull requests that introduce bugs and then they have to maintain and so forth. But I keep seeing all these projects that have literally one contributor on them. And my goal is to try to discourage that in my own work and try to pull in additional contributors and try to more actively solicit people for help. Not just because I don't want to spend the time working on it constantly, that would be great,

but because it is more stable the more people have access and control to things and have had eyes on it. You know, I've never read RSpec given 2.0's source code. I was familiar with 1.0, but 2.0 was a rewrite. So I'm going to have to go in basically with no help and totally figure it out soup to nuts. And if I'd spent just a little bit of time pairing with Jim and he had an open offer on the table for me to pair with him on it, which I obviously regret not taking him up on, now I'm totally on my own. To say nothing of how important his documentation is going to be to me, which is another area where a lot of open source falls short. So that project in particular, I love it because it's just,

Jim gave several talks on RSpecGiven. If you have any familiarity with RSpec or with BDD-style unit testing, I think that Given is a really, really thematically honest, conceptually pure way to write unit tests. And it has a lot of benefits that are just not obvious at first blush. At first blush, it looks like, oh, these are just aliases to give in and before each and so forth like that. It's just more DSL kind of, you know, machinations. But when you really dive in and you realize like how the structure of the tests becomes much more clear and the additional tools that it gives you with using fewer keywords, it's a fantastic tool.

And I've got a port called Jasmine Given that does the same thing for Jasmine, which is why I've got the interest in maintaining both going forward. But anyway, yeah, I love the tool and, and, uh, you know, speaking on Jim a little bit more broadly, uh, my goal is to be more like him in how I carry myself in the community. no matter who you were or what your idea was or what you had to say or whether Jim had learned that thing that you learned 100 years ago, he treated you like you were fascinating. And he got excited for your excitement. And he just had so much joy in his heart that he couldn't wait to share with whoever was around him. And he was so welcoming that even when, you know, he was a well-rounded guy and he got mad at stuff. I think one time he said that you, you've never really understood a dependency until you've come to hate it. Um, he, he, he could be biting. Like I, I, this is several years old now, but like when he gave me criticism

about, about, uh, code that I wrote or how I wrote it, I wanted that image where it's like, lie down and baw it hurt me so much was because it was so true. And his feedback was so crisp and so grounded in just so much expertise and so much wisdom that he didn't get that wisdom because he was older and he'd been programming a long time. He got that wisdom because he was incredibly thoughtful and introspective and careful. And he managed to have both that aspect, which I, which, uh, you know, I try to pride myself on, but also this ability to very gracefully meet people where they are and get inside of their heads. And, um, that's something that, that I think that all of us could, you know, do a better job with. And it just makes me really sad. We're not going to be running into him at all the conferences throughout Ohio from now on. Yeah, absolutely, man. Uh, speaking of Jim, the Ruby Rogues did a great tribute episode. I don't know if you heard that or not. Episode 151,

look it up while you're talking there. Uh, the Ruby Rogues talk about Jim and all the impact he had on them. He had such a dramatic impact on so many. It's just amazing how many people, even though it's a small community, that he specifically touched a huge loss to the Ruby community. Well, Justin, I think that's a good place to wrap. Appreciate you coming on. We're excited about Lyman and what you're

doing there. I've used it a little bit. I'm excited to use it on some more projects. And thanks for coming on and talking to us. Right on. Thank you, guys. I really appreciate being here. And if anyone has any questions at all, feel free to reach out to me on Twitter or I'm justin at testdouble.com. And specifically with Lineman,

we don't have an IRC or anything, so if you have a question or something's confusing, just open a GitHub issue. It's not just about, this code doesn't work. We just want to have the conversation in one place and help everyone out. Awesome. Well, we'll be back conversation in one place and help everyone out. Awesome. Well, we'll be back next week and let's all say goodbye.

Bye-bye. So long. We'll see you next time.