Focusing on DX (the Developer eXperience)
A few months back, I had to write an application from scratch. I’ve been using JavaScript nearly continually for a couple decades, and at various points have investigated front-end frameworks, and always, in the end, decided to stick with vanilla JS.
It was the end of 2016. There were so many great frameworks! So much great engineering had been poured into them, by big corporations and independent programmers alike. There were so many starter kit projects out there to use as a template, and tutorial videos to walk you through every step of the way. Not only that, sites like megaboilerplate.com had been started, able to build a starter kit for you out of any stack you liked, because there were just so many choices.
It would be foolish not to leverage some of this greatness somehow, right?
What I found didn’t really surprise the jaded part of me that had been through process this before. Despite the fact that software does not actually rot, it seemed that every kit (or boilerplate generator combination) that I chose either did not work out of the box as advertised, or had some significant shortcomings, like unimplemented features.
That’s OK. This stuff is pretty hard to get right, and I don’t want to put down the gargantuan collective effort that has been put into the ecosystem as it stands today. (Much love to all the front end framework developers out there. I’m just sharing my experience and do not intend to criticize you personally nor claim any kind of superiority.)
But I still needed to decide what to use. I decided to watch some videos, for once. I watched some folks on YouTube build an app with React. I went back to my CodeSchool Angular course notes, and watched some “Soup to Bits.” The videos were high enough quality, but I was struck by an odd thing that happened at least once in every app-building video series I watched:
The experts got stuck. Pretty badly.
Of course experts get stuck, that’s fine. Nobody is perfect. What was odd was the nature of the jam they were in: a typo had resulted in no useful feedback from their DE, nor from the debug console. They were left to manually scour all the code they had changed since the last time things had worked.
Fast forward a few weeks after the application was done. I was still interested in the latest state of things in various coding ecosystems out there, so I had found myself reading The Rails Doctrine, and decided to watch the RoR video.
I was impressed. Mostly with this spot, where the presenter makes a typo on purpose.
I know, the rest of the video was not error-free, and they did have to edit something there. But the DX here is what I want to look at. A typo here meant that the developer was presented with the exact location of the typo, and even some suggestions as to what might have been intended. I know it’s an isolated example, but this stood out to me as an example of The Rails Doctrine at work: the developer experience has been given high priority in the Ruby on Rails world, and it shows.
When I went through the Angular and Ruby/RoR courses at CodeSchool, I hadn’t, at the time, had much trouble with the content of either. They were both interesting and straightforward to work with, and had more finesse than the vanilla JS + Perl stack I had cooked up and maintained for most of my career. I guess I had been lucky enough not to make a typo, or the CodeSchool interface had somehow shielded me from the worst case scenario.
Incidentally, I noticed at least twice in the CodeSchool video, separate from its own getting-stuck-thanks-to-a-typo segment, where one of the presenters said, “Oh, right…we have to do it this way in Angular. It’s easier in Rails, because…” Granted, this video was slightly dated, being about Angular 1.
Later, knowing that a lot must have changed since then, I tried the latest Angular. I dared myself to build an app in four hours, without any prep. I almost succeeded, but just getting into the groove took up over half the time. I even managed to even hit a dreaded Ungoogleable Error along the way, along with a few Googleable Errors That Somehow Never Seem to Have Happened to Someone Else in my Particular Context Before. It wasn’t the worst DX I’ve been through, but I also didn’t quite make my goal.
All of these little observations have added up to this:
I’m going to give the Ruby on Rails developer experience a shot.
I invite you to join me as I try it out for myself, and see what I encounter along the way. I guess that makes this Part Zero of a series. Stay tuned for Part One via RSS below.