Preact vs Stimulus

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.

Generally I would advise you pick Node.js for your backend if you want to run a GraphQL service. The main reason for this is the tooling and support you get from the language around GraphQL and the native feel due to the spec being initially written in JavaScrip for JavaScript. However that isn't to say that you couldn't use Go for a service underneath your GrahpQL layer - but I would say that's probably complicating it too much to begin with.

Node.js has great support for reading from databases and using a server such as Koa will give you great performance (we operate several Node.js services in Koa with over 1000req/s). Additionally it keeps your initial simple stack in the same language so it will be easier for you to jump backwards and forwards.

If you were not to use GraphQL then I'd say it's really up to you whether you want Go in your ecosystem or not. It's a fantastic language and super performant, along with being more memory efficient than Node (if you are worried about costs at large scale).

If you're at infancy stages and haven't picked certain parts - and this is a customer facing application - then I would recommend you look at Preact instead of React and URQL (instead of Apollo Client). Both are great libraries that are very performant and don't need much advanced learning. Additional swap out MySQL for PostgresSQL (they are interop primarily, but offers you more features as you grow) for its ACID compliance, better performance at scale and support for NoSQL if you were to go that way.

Preact offers an API which is extremely similar to React's for less than 10% of its size (and createElement is renamed to h, which makes the overall bundle a lot smaller). Although it is less compatible with other libraries than the latter (and its ecosystem is nowhere as developed), this is generally not a problem as Preact exposes the preact/compat API, which can be used as an alias both for React and ReactDOM and allows for the use of libraries which would otherwise just be compatible with React.