Hampton Catlin

Starting a new company in 2020, with a whole new stack, is a really interesting opportunity for me to look back over the last 20 years of my career with web software and make the right decision for my company.

And, I went with the most radical decision– which is to ignore "sexy" / "hype" technologies almost entirely, and go back to a stack that I first used over 15 years ago.

For my purposes, we are building a video streaming platform, where I wanted rapid customer-facing feature development, high testability, simple scaling, and ease of hiring great, experienced talent. To be clear, our web platform is NOT responsible for handling the actual bits and bytes of the video itself, that's an entirely different stack. It simply needs to manage the business rules and the customers experience of the video content.

I reviewed a lot of different technologies, but none of them seemed to fit the bill as well as Rails did! The hype train had long left the station with Rails, and the community is a little more sparse than it was previously. And, to be honest, Ruby was the language that was easiest for developers, but I find that most languages out there have adopted many of it's innovations for ease of use – or at least corrected their own.

Even with all of that, Rails still seems like the best framework for developing web applications that are no more complex than they need to be. And that's key to me, because it's very easy to go use React and Redux and GraphQL and a whole host of AWS Lamba's to power my blog... but you simply don't actually NEED that.

There are two choices I made in our stack that were new for me personally, and very different than what I would have chosen even 5 years ago.

1) Postgres - I decided to switch from MySql to Postgres for this project. I wanted to use UUID's instead of numeric primary keys, and knew I'd have a couple places where better JSON/object support would be key. Mysql remains far more popular, but almost every developer I respect has switched and preferred Postgres with a strong passion. It's not "sexy" but it's considered "better".

2) Stimulus.js - This was definitely the biggest and wildest choice to make. Stimulus is a Javascript framework by my old friend Sam Stephenson (Prototype.js, rbenv, turbolinks) and DHH, and it is a sort of radical declaration that your Javascript in the browser can be both powerful and modern AND simple. It leans heavily on the belief that HTML-is-good and that data-* attributes are good. It focuses on the actions and interactions and not on the rendering aspects. It took me a while to wrap my head around, and I still have to remind myself, that server-side-HTML is how you solve many problems with this stack, and avoid trying to re-render things just in the browser. So far, I'm happy with this choice, but it is definitely a radical departure from the current trends.

We were thinking about what to do to make working with our internal Java applications a bit more fun. We use Dropwizard in all of our main backend systems and while Dropwizard has served us well, it has a lot of boilerplate and team members who were joining that were used to Spring / Spring Boot were finding Dropwizard lacking.

We'd also had teams starting to use Lombok to help cutdown on boilerplate POJOs, but the infrastructure team and, well, myself included, were concerned about how Lombok is implemented as a bytecode manipulator. We're cool with generators, but bytecode manipulation seems a bridge too far for many reasons.

We realized that Kotlin can help with both problems, potentially cutting down on boilerplate POJOs and helping with some of the patterns that people find cumbersome in Dropwizard. The fact that you can 'drop in' Kotlin into an existing application or convert it whole-hog without functionality changes is a real game changer for us and made that technology much easier to implement.

We value not leaving all of our 50+ Java services behind, and would rather work with technologies that will allow all teams and all of our services to be easier to work with and more maintainable.

It's still early days with Kotlin, but so far the teams are very excited.

We use Sass because I invented it! No, that's not a joke at all! Well, let me explain. So, we used Sass before I started at Rent the Runway because it's the de-facto industry standard for pre-compiled and pre-processed CSS. We do also use PostCSS for stuff like vendor prefixing and various transformations, but Sass (specifically SCSS) is the main developer-focused language for describing our styling. Some internal apps use styled-components and @Aphrodite, but our main website is allllll Sassy. Oh, but the non-joking part is the inventing part. /shrug

At our company, and I've noticed a lot of other ones... application developers and dev-ops people tend to use Ruby and our statisticians and data scientists love Python . Like most companies, our stack is kind of split that way. Ruby is used as glue in most of our production systems ( Java being the main backend language), and then all of our data scientists and their various pipelines tend towards Python

Python is popular with data scientists and statisticians. That is the end of my statement.

We use JavaScript because it's the standard for web development, especially with browser execution. And, over the years, some smart work by the W3C has taken Javascript from the most-hated-language to the okay-I-can-make-that-good. No small feat!

Obviously, using ES6 and TypeScript is what makes it decent in browser contexts. Throw in a bit of React and now we're cooking with gas!