The Dark Side of Javascript Fatigue

Javascript fatigue is a real experience for many developers who don’t spend their day to day in Node.js bashing out javascript. For many developers javascript is an occasional concern. The thing I can’t figure out about the javascript development world is the incredible churn. Churn is often disaster for a programming community. It frustrates anyone trying to build a solid application that will have a shelf life of a decade or more. Newcomers are treated to overwhelming choices without enough knowledge to choose. Then they find what they’ve learned is no longer the new and shiny tool only a few months later. And anyone on the outside feels validated in not jumping in.

Many in the javascript community attempt to couch all the churn as a benefit. It’s the incredible pace of innovation. I see sentiments like this:

The truth is, if you don’t like to constantly be learning new things, web development is probably not for you. You might have chosen the wrong career!
Josh Burgess

Even if we accept that it all the ‘innovation’ is moving things forward more quickly, there is rarely the reflection on the consequences. I’ve worked on an approximately 9 year old Rails app for about 5 years now and I’m still shocked by the number different frameworks and styles of javascript that litter the app:

  • Hand rolled pre JQuery javascript
  • Javascript cut and paste style
  • RJS (an attempt to avoid writing javascript altogether in early rails)
  • YUI
  • Prototype
  • Google Closure
  • JQuery
  • Angular

Eight different frameworks in about as many years. And though we adopted Angular about 2 years ago we’re already dealing with non-backwards compatibility, Angular 2.0. This is a large burden on maintenance and it costs us very real time to spin up on each one when we have to enhance the app or fix a bug.

This is a monolithic app that’s been built over quite a few years, but the big difference is the Rails app was opinionated and stuck to a lot of default conventions. The framework churn of Rails has been much more gradual and generally backwards compatible. The largest pain we experience was going from Rails 2 to 3, when Rails was merged with Merb. The knowledge someone built up in their first few years working in Ruby and Rails still applies. The churn is certainly exists, but at a measure pace.

In phone screens when I describe our main app, I list off the myriad javascript frameworks we use as a negative they should know about. And almost none of the candidates have heard of Google Closure, even though a critical piece of the app was written in it. They often assume I must be talking about the JVM Clojure.

Javascript has never been popular because of elegance or syntax. Rants like the following are not hard to find:

You see the Node.js philosophy is to take the worst fucking language ever designed and put it on the server.
Drew Hamlett

Large majorities of developers would rather avoid it completely to focus on any modern language and hopefully use a transpiler if they have to touch Javascript. In this environment it might do the javascript community some good to settle down some and focus on some stability.

RailsBridge Sacramento

I volunteered to help out as a TA for RailsBridge Sacramento this past weekend at Hackerlab Sacramento. We had 60 people show up to build some Rails in one day. Many of them were brand new to programming or Rails. My section had a lot of people with some development experience in other languages like Java, C#, C, or Scala.

The energy level and overall interest was great. I taught Oracle Java classes years ago and sometimes the majority of the class was only there because their managers made them attend. Teaching disinterested people is stressful and not fun. Even though they were giving up a Saturday almost everyone stayed and coded through the entire day.

As a TA I rotated among people nudging them in the right direction, troubleshooting errors, explaining Rails and Ruby idioms, and discussing the local job market. My only break turned out to be the pizza lunch but I was working off the energy of all these motivated people. Everyone in our group got through the main exercise and built a simple Rails app and got the chance to add extra features like a login with Devise. And even if most of them never build another Rails app they can carry the paradigms that are common in many web frameworks like migrations, integrated REPLs, generators, templates, and ORMs.

The diversity of the group exceeded by assumptions. It’s refreshing to see that the next generation of developers won’t look like the current white male majority. It was rewarding to explain to many people how they could approach breaking in or breaking back into a development job by just showing some motivation and the ability to learn. Hopefully some of the attendees will some day bootstrap more underrepresented groups into software.

Kickstarter Idea: Mac OS X Package Manager

Developing on the Mac has generally been an awesome experience over the years especially with OS X and the UNIX underpinnings. The long pain point in this area is the lack of a solid supported package manager. It’s not in Apple’s DNA to worry about power users who actually use the terminal, and they’re unlikely to ever consider it important enough to delegate resources too. MacPorts and its hipster cousin Homebrew have been around for a while, but they’re always a bit rough around the edges, missing packages here and there, old versions, and sometimes they need extra tinkering just to install. In all it’s a most un-Mac like experience.

I don’t know that it will ever happen, but I know I’d support a Kickstarter that promised to maintain a Mac package manager like rpm or apt for OS X. I don’t care if they use Homebrew or Macports and just make it more robust, or build a new one from scratch. I’d just like a simple install of all those open source libraries. Yehuda Katz did a simple installer for Ruby and Rails on OS X a few years back via a Kickstarter, so I know there’s precedent and this would impact a lot more developers. Saving hassle is certainly worth some bucks for a kickstarter.

Dipping Toes in Other Development Communities

My dad, even with a serious head injury that ended his working life, regularly attended a computer club where he could chat with a community of fellow geeks who accepted him head injury and all. I was always glad he had somewhere he could be accepted, but I never realized I’d end up attending and helping to run programming user groups in my own career.

I first went to a Java Users Group in Sacramento, SacJUG. I had been getting deeper into Java and figured it was time to see what the local community was like. I found a home with some fellow geeks and I attended regularly for the next ten years or so. I even eventually hired multiple developers I met at SacJUG and I appreciated being able to geek out on the language and share war stories. A few years later I got deeply into Ruby in my spare time with the advent of Rails and eventually helped setup the Sacramento Ruby Meetup. It would be a few more years until I got paid to do Ruby, but met some great developers along the way and I still regularly attend. Only a year or so later I helped found the Sacramento Groovy User’s group which continues today as essentially a JVM languages group.

All this experience with user groups has led me to experiment with visiting other user groups from time to time. A few months ago I showed up for an Angular group and met a lot of front-end specific developers I don’t mix with regularly.

If you haven’t tried out attending a user group I encourage you to try it. It only costs you an hour or two and the benefits are worth it. Things like:

  • Seeing the size of say the node.js community in your town and getting a sense of how a new language or toolset is catching on.
  • Getting exposure to something new with a group of programmers.
  • Meeting fellow developers who are trying to come up to speed or stay on top of technologies.
  • Finding a great new candidate for your shop. The developers who regularly attend user groups tend to be more motivated and engaged employees and you can get a pretty good sense of their skills just from chatting.
  • Getting out of the house since many of us are introverts. With the shared context it’s much easier than say the annual holiday party.
  • Practice speaking if you work up the nerve in a low stress atmosphere.
  • A sense of whether a particular language/community is on the rise or fall.

RSpec stub_chain for legacy code

I got asked the other day about whether it was OK to use stub_chain when testing what turned out to be a legacy fat_model class of over 500 lines. There wasn’t much to think about as I replied it was OK if there wasn’t a lot of time in the story for refactoring since the code was already legacy, but it wasn’t my favorite tool. Even the documentation notes:

we recommend treating usage of stub_chain as a code smell

It’s a part I appreciate about Spec. It’s an opinionated BDD framework, but it allows you do use it in a way that works for you. I don’t love stub_chain or even less as_null_object, but when diving deep into badly covered code they can be a nice way to open up a seam in the code and allow you to start a big refactoring.