Welcome, Hacker News! (my article about keeping a "WTF Notebook" did the internet rounds this week)

Dang there sure are a lot of you – this e-mail is going out to over 100 more people than the last one – just over 400 subscribers. Exciting! A little scary, too, but mostly good.

Whether you're just joining us or you've been reading since the beginning – I'm Nat Bennett and this is Simpler Machines, a weekly newsletter that's mostly about making software.


I'm trying to keep these short, so in that spirit – this week I've been thinking about why exactly it is that frameworks like Phoenix and Rails feel so much more productive for small teams than applications with a distinct frontend and backend.

This is advice you'll see from a certain kind of cranky web developer. "Don't let your team split the codebase!" "You don't need all that Javascript!" But usually the explanation is something like "specialization" or "heavy frameworks." I agree with the advice, sure – there're way too many React applications out there that should have just been Rails apps – but this week, I've been writing a lot of LiveView and I've been thinking about why this feels so much better for a small team than a stack with a strong frontend/backend split.

And basically, it's this: I don't have to think as much about where to put a piece of behavior. If I'm wrong about where it ought to go? I just move it. I don't have to change what language it's in or update a client or write new tests or any of that. I just don't have to think as much about whether a behavior "belongs" in the frontend, or if it's complex enough that it ought to be in the backend. I put functions where they're convenient to put them and then I refactor later.

Plus: I don't have to worry about synchronizing the frontend and the backend. There's no versions.

Especially early on in a program's life I pretty regularly get things wrong. I've got a thing right now where I have a whole table that's probably redundant – the whole concept it represents should probably get folded into another one. Fixing that is going to be a little bit of a pain – I'll have to do a migration and all that – but it's going to be so much easier because I don't also have to synchronize the change across two codebases.

Anyway– I guess what I'm saying is, this is one place where I agree with that guy who's always going on about how things were at his last job at Google. If you have to split your application into a frontend and a backend, please at least put 'em in one repo together, and generate the frontend client and the backend view using some kind of gRPC generator.


Again, really delighted to have you reading this. If you've got thoughts, or questions – on this topic or any other – send me an e-mail or leave a comment on the website.

I am tragically behind on my e-mail so there are notes from a few of you about exploration that I haven't gotten to yet – more on that soon as I get myself caught up.

- Nat

Seriously just write a Rails (Phoenix) app

Basically, it's this: I don't have to think as much about where to put a piece of behavior. If I'm wrong about where it ought to go? I just move it. I don't have to change what language it's in or update a client or write new tests or any of that.