Throughout my career I’ve always had a certain affinity for simple solutions that are just complex enough to get the job done. This started for me very early on by saying NO to the bloat of Java Enterprise Edition and building something pragmatic, effective and lightweight in its place (called JServer for anyone interested). It didn't have all the features of J2EE/JEE of course, but it was good enough for our needs at the time. And the complexity was just right (at least for the most part). And most importantly, the complexity didn't stand in our way, but instead enabled us to achieve our goals faster (and likely cheaper).

Every now and then during my career I've come across other individuals and companies that have shared this philosophy, and one that sticks out in particular is of course 37signals and its founders. Therefore it's fitting that I write this post on this equally pragmatic and simple platform! 

However, during my 2+ decades working in software development, there have been far too few beacons of simplicity - quite the opposite really. The last decade has been especially troubling, with more and more bloated frameworks and (misunderstood/misapplied?) architectural styles. And it’s happening everywhere - from absurdly distributed nanoservices (orchestrated by Kubernetes of course) to hopelessly over-engineered frontend frameworks with complex state management frameworks and dependency nightmares… The list goes on...

The lust for unjustified complexity in our line of work almost feels pathological sometimes. Is it just a case of infatuation with the latest shiny technology? Or is it that we so desire to be the next Facebook, Amazon, Netflix or Google that we simply carbon copy their solutions without asking any questions or even doing a sanity check? Or is it simply the case that many of us are suffering from a bad case  of premature scalability anxiety...? Whatever the reason, we need to remind ourselves why - and for who - we build the things we build.

But lately it feels like the tide has turned a bit. We’re beginning to tire of all the unjustified complexity. We're starting to realise the folly of chopping up our backends into quantum sized meatballs in a spaghetti mess of over-distribution, before even starting the project. We stop using complex JavaScript frameworks, and rejoice at the simplicity of #nobuild and a node_modules-hell free life. We even start to question if we really need the Cloud (😱).

As one who focus a lot on the frontend, I find the trend of moving away from complex SPAs - and back towards a more standards based and HTML-centric approach - especially refreshing. This started already a few years ago, when the recommendation against "SPA as a default" became commonplace. But the most recent trend is to go one more step further and move away from JavaScript as a default entirely. Which - when you think a bit about it - isn't all that strange, especially given the capabilities of modern HTML and CSS. And this shift has been made even easier with the help of frameworks such as Hotwire (by 37signals), HTMX and Unpoly - to name but a few.  

I don't want to get too long-winded in this first blog post - after all, we're talking about simplicity here! 😅 But I wanted to close by touching briefly upon another frontend framework I personally spend some time around, namely Flutter. It has a slightly different sweet spot than the frameworks mentioned above though (true multi-platform, with a slight mobile tilt). I wouldn't go so far as to call it lightweight, but it is still refreshingly efficient, pragmatic and complete (both when it comes to the language Dart and the UI/app-framework itself). And importantly, it isn’t plagued by the dependency nightmares (and consequent security risks) of JavaScript apps. 

However, even the Flutter ecosystem sometimes suffer from the same problems as other parts of frontend, i.e. over-engineered architectural patterns and bloated state management frameworks. The latter is especially strange, since Flutter out of the box more or less contains what most apps need in this area, unless you're in the FAANG & co bracket of course (in which case it may be justified to reach for something like Riverpod). 

Notice that I said "more or less", by which I mean that there are still room for some quality-of-life improvements over the built-in stuff. And this is why I finally ended up writing a small package to do just this (I was almost ashamed of doing it at first, since I didn't want to add more noise to the package ecosystem 😱). My goal is to keep it small and simple (while still adding value), which means rather removing stuff that slapping more things on. Hopefully I manage to stay true to this goal — and most importantly perhaps: the goal of keeping things simple.

So, anyway, if you're interested in a pragmatic, effective and lightweight state management package for Flutter, perhaps consider result_notifier for your next project.

Keep it simple out there!
/Tobias