> The Backbone code is brutally honest about what it's doing. An event fires, a handler runs, you build some HTML, you put it in the DOM. It's verbose, sure, but there's no mystery. A junior developer can trace exactly what happens and when. The mental model is straightforward: "when this happens, do this."
> The React code hides a lot. And once you move past simple examples, you hit problems that don't make sense until you understand React's internals.
I relate to this a lot. I have had to read these two very large articles multiple times to calcify my mental model for understanding exactly _when_ react does something and _why_ it did or did not.
https://overreacted.io/a-complete-guide-to-useeffect/https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-...
Backbone was also my first framework that I haven’t touched in over 10 years, but looking at the code examples from the article I completely understood what was going on.
I think what the blog post is getting is OTP and the mystical/but not mystical GenServer / Supervisor/ distributed pattern. It's baked right in there as a core part of the Erlang VM. I think the post glances over the fact that in rails land solid queue may be right there to use (I've not really used rails in over 10 years).
Thing is with Elixir though, yes the tools are right there, but you do have to take time to understand them. I've been on and off with Elixir since 2016 and I'm currently wrapping up on a fairly complex elixir project with zero UI. (connecting Shopify GraphQL to a series of 3rd party fulfilment providers who use SFTP (gross). So yes, GenServer, Supervisor etc are all right there as first class citizens, but whilst they are relatively simple to start using, you can end up with some horrifically structured code that would have been much better written without the distributed stuff.
Personally, I prefer Django. Been using it since 2006 and as a person who started off in design but ended up as an engineer, nothing beats Django's template engine (braces for incoming). Django isn't perfect but nothing is. When I have to get something done quick and there's UI work for me to do, I go to Django. When performance or no UI, I go elixir. If someone else is doing the UI, I go phoenix.
That's also where I'm at. For any project with UI (and auth/auth etc) I went back to Symfony (and Vue). I can't stand Phoenix templating especially layouts and I couldn't convince José of the greatness of template inheritance like with jinja2 in python ;)
But I'm happy running worker type things in elixir & Phoenix if I can.
IMHO Django's templating engine is its worst feature but that only proves how subjective all these matters can be. I'm currently making money both from Django and Rails. I made quite a bit of money from Phoenix years ago. Customers choose their platforms, I can choose customers.
About OTP's primitives, they are great but a background job system has more features than those primitives offer. We wrote a fair amount of extra code to get what we needed for our production system. I'm using Sidekiq in Rails in my current Rails project and it's more feature complete than what we built for Phoenix. I'm using Celery with RabbitMQ in my current Django project and we would like to get rid of it. It's too fragile.
After using both Flask and FastAPI extensively I can attest that Flask is the better technology. Flask is extremely stable and has solid organization around them via Pallets. This is a great benefit as they are keeping the ecosystem moving forward and stable.
Versus FastAPI which is lead by a single maintainer which you can search back on HN about opinions on how he's led things.
Flask also has at time of writing only 5 open issues and 6 open PRs, while FastAPI has over 150 PRs open and 40 pages(!) of discussions (which I believe they converted most of their issues to discussions).
Lastly on the technical side, I found Flasks threaded model with a global request context to be really simple to reason about. I'm not totally sold on async Python anymore and encountered odd memory leaks in FastAPI when trying to use it.
flask-openapi3 looks good but has only 246 stars. Would be worried using it in production. flask-pydantic has no openapi tie-in. Oh look, there's me bumping the openapi request that's been an issue since 2020: https://github.com/pallets-eco/flask-pydantic/issues/17 which has an open PR since 2022.
It's possible between Quart and svcs (for DI) and some Pydantic/Marshmallow/OpenAPI extension you might be able to mimic what FastAPI does. But I'd just use FastAPI. I use async too. It's a lot easier to scale in my opinion.
Do none of these pieces matter to you? Like do you not do any data validation or care about OpenAPI?
Dependency injection in fastapi honestly feels like a horrible afterthought. Flask's g is much easier to reason about, and 99% of projects don't need the 'performance improvements' of async.
Flask is old. It's mature, nothing left to add, little if anything remains to fix because nothing is really broken. OTOH its static typing story is pretty weak, and this is likely unfixable by design. Its use of one-letter global objects also feels a bit weird.
It's the "choose boring technology" poster child, of sorts: get things done reliable, without using any design younger than 15 years ago.
I setup a fresh rails 8 app on Fly last year, using PG for the main data store but using SQLite for the ancillary solid stack dbs.
Only fuss I remember encountering was with fighting with rails migrating solid queue properly, but this seemed like a rails unit issue and don’t remember it being a Fly issue.
I’ve been contemplating migrating my pg primary to SQLite too. Anyways don’t have much else to offer other than an anecdote that I’m happily using fly with partial SQLite.
Love that you mentioned the skateboarding history of it. I have fond memories of our young crew finally acquiring a “death lens” for our VX1000. It was such a fun challenge to see how close you could get because it looked so sick.
Of course that meant we ended up with a bunch of scratches over the years on the lens, and I had my fair share of hitting the lens :)
I thought litestream was just for streaming backups? How does it enable you to coordinate with multiple instances of an application? Is one instance the "primary" where writes all go and either can serve as a reader?
This is a quirk that could cause data loss in rare scenarios but basically, in most cases, you'll have a single instance of your application because your load balancer will only send traffic to the other instances if the main instance isn't responding. But the load balancer will have to be setup to send traffic to a single instance at a time, and only try other nodes if the current node isn't responding.
The other instances are mostly redundant. That's how sites like Hacker News tend to operate, and why I chose this architecture. It's simple and stupid but doesn't work in scenarios where you have multiple servers in different locations for example. There's LiteFS to solve this problem but I don't have experience with it yet.
I'm interested in knowing more about this too as I like the database localised with my app server (no network RTT!) but I also like to have a standby for HA and not being paged with everything down.
How litestream handles master-master or promoting a slave and switching back later isn't clear to me.
A lot of similarities but I believe Turso replicates data between nodes.
Litebase writes data to a tiered storage system (local, network, and object) for easier distribution. Using SQLite's VFS API I've also implemented a different type of storage that allows the primary to write data without full consensus with replicas. It's kind of like a multi-versioned log structured merge tree.
I've been using RSS via the Readwise "Reader" app over the last year and it's been awesome. First time using RSS and love that so many developers make sure they have feeds on their blogs.
The lack of the algorithmic "feed" and the fact that I'm "pulling" rather than being "fed" content is such a great change in content consumption.
