It can also generate clients and webhooks. Authentication is just declaring a SecurityScheme in the OpenAPI document then implementing a single function. The rest of the backend is just implementing a single interface. Unlike oapi-codegen, there is no need to tinker with routing libraries or middleware for authentication and logging.

Pair this with sqlc[2] and SQLite's `pragma user_version`, and you get type-safe database code and database migrations for free. I will concede that adding SQLite is a manual process, but its just two imports added to main.go.

Frontend is entirely your choice. Go's standard library provides good enough text templating that I don't miss ERB or Django-style templates. Using the standard library's `embed` package, one can easily embed static assets into a single binary, so deployment can be as simple as `go build` and moving the binary.

I have a hard time using languages besides Go for developing backends, because the code generation tools make Go as convenient as frameworks like Quarkus while staying lightweight and fast.

[1] https://ogen.dev/

[2] https://sqlc.dev/

There's a lot of noise coming from Microsoft to sell their new products (this year: Aspire.NET). But don't be mislead by this noise: .NET Core (C#, ASP.NET Minimal API or MVC, EF Core) is more batteries included and reliable than most other options. The only gripe I have is the need to get into the OOP and DI mindset ("create custom implementations of some abstract classes and put them into DI and the framework calls your implemented methods magically" kind of stuff). Takes some time, but not a big deal for experienced devs (and younger ones can learn faster anyway :-)).

Java, Kotlin, Scala, C#, F#, OCaml, Haskell, D, are also much better for networking tools and CLI.

And nowadays people can't even complain the Java AOT options are commercial, or .NET is stuck on Windows.

One can argue it goes against some of the Go principles, but it's a really nice stack for solos or small teams without dedicated SREs. And as you grow you can BYOC & deploy it yourself or completely rewrite your API layer using Go stdlib.

You would still need NextJS or Remix/RR7 for the front-end, but one nice thing is that it would auto-generate the client SDK in TypeScript which makes integration a breeze. And while I personally prefer Remix/RR7 for frontend, Encore has integration with Vercel PR feature which is really hard to beat.

But it still needs to mature quite a bit before I’d be comfortable saying it’s anywhere near Django or Rails

My gut still says rails for customer facing, Django for internal tooling or data work.

[1] Stop Designing Languages. Write Libraries Instead:

http://lbstanza.org/purpose_of_programming_languages.html

Jumpstart Pro is great. https://jumpstartrails.com/

So is Bullet Train. https://bullettrain.co/

I’m also not sure how much time you imagine one spends on setting up CI. In my case it’s just one file with about 20 lines in it, and I usually just copy and paste it from previous projects.

Obviously Django ties you into python and its ecosystem while Rails means ruby (and its gems). The ecosystem is more important than the language. This can either impact your project a lot, or not much at all, depending on context.

Rails doesn't have the equivalent of Django's admin CMS. There are gems but Django is still much stronger. A lot of orgs have their entire CMS / administrated-by-staff part of the product written in it.

Rails, otoh, has a very powerful scaffolding cli. If you are proficient, you can generate some basic crud stuff in minutes from A to Z.

In general, I think Rails is at an even higher level of abstraction than Django. A lot of the architecture or structure is more or less given with rails, whereas you need to make a lot more choices with Django yourself. Routing is a good example. The 'batteries' that are included are also a bit bigger and seem to be in much more active development than Django.

Also a generalization: rails/ruby seems to value brevity and the DRY principle a lot more than is common in django/python. There's a split in taste on this, often python devs find the 'magic' of Rails rather frivolous and unreadable - even though django has a fair bit of metaprogramming itself, whereas Rails devs think the 'pythonic simplicity and straightforwardness' is actually rather crude. Or to be a bit more precise: in the rails world, code duplication seems to be thought of as a greater evil than semantic coupling.

I realize these are all quite subjective, and probably reflecting my own development experience more than being an accurate feature-by-feature comparison.

If I was building a web ‘app’, consumer facing product, I’d reach for Rails. I think scaffolding up to ‘market ready’ seems easier in Rails. I say this having never really done this in production.

For internal tooling (using the admin panel), data based work, or geospatial work, stick to python

I also like ActiveRecord + Arel more than the Django default ORM, but that's more so preference driven by like the Ruby AR syntax more than the Python. (And a general unsupported opinion that Ruby is a slightly better/more pleasant language for writing code than Python.)

Rails gives you way more structure than Django.

At the same time, I am always shocked out how many people fight against Rails conventions when building in Rails. (Not that you've done this, but seriously, I take over a random code base and they'll have done something like written a worse version of Active Job from scratch for no real reason.)

Or any other constraint for that matter, every few months I look for ADD CONSTRAINT again, only to rediscover there isn't anything.

The lack of any sort of PL language (or even just trivial stored procs aliasing queries) also makes migrations more annoying, CTE can handle some of the load but the verbosity and limitations of basic SQL make that awkward, and needing to round-trip through the host language for everything is frustrating (even more so when the host language is statically typed and thus requires adaptation out).

That said, I do think it's really positive that sqlite3 is now a first class option in the framework. Tons of high quality work by very smart people has been invested in recent years.

EDIT: this comment is more about rails itself than the actual blog. I take the point being, that sqlite is fine for starting out with a tiny app if you have very little users, and I think that is true.

However, migrating later on to a different database is a always a pain, so I wouldn't recommend starting out with sqlite if you intend to do that later on (with your production data).

But in the rails context couldn’t you mostly manage with an ActiveRecord validation? I know it wouldn’t be ideal.

Nooo the setup should be easy no matter how experienced you are.

I found jekyll quick to get started with, but that is because I already had Ruby and RubyGems installed.

with scaffolding and other rails generators with custom templates is that really a big asset? might not look amazing out of the box but you can find css templates easy enough too. maybe they should make an admin generator but rails is king of crud and if you need it ootb you can use one of the many gems.

Save me from my free tier GitHub pages / Netlify / SaaS hell.

This is the hottest tip in this thread imo

I think that the doctrine of convention over configuration leads to content that is much more legible to LLMs in training. I find querying Claude for Rails issues to be really helpful. I suspect would be very helpful to a novice.

As a SWE and infosec guy, please don’t just roll this stuff yourself. Maybe Devise is more complicated than it needs to be, but a lot of this stuff is far more subtle than people realize and trivially easy to get catastrophically wrong.

I’m absolutely certain a lot of the parts you think are unnecessarily complex are the result of having gotten it wrong before. How do I know? Because I’ve personally submitted vulnerabilities to Devise (specifically the lost password flow) that ended up getting a redesign to fix the vuln.

So even if you don’t use Devise, please use some other project which has already suffered through iterating over vulns so you don’t have to.

I also find devise pretty simple to get setup and use. It's so easy to mess up some small thing while writing your own auth. I've always pretty much trusted myself to at least get devise setup properly.

[1] https://github.com/18F/identity-idp/blob/main/Gemfile#L30

My pet peeve with most of the auth solutions is that they tend to be extremely coupled to hard-coded emails, which makes it varying degrees of annoying to use third party tools for the parts of a product funnel that intersect with auth and also to integrate SMS cleanly. But I guess I'm the kind of person who finds it annoying to override a "send invite email" method with something that triggers events or sends an SMS instead just because it's not really what it says on the tin at that point.

Yes, it can seem esoteric and magical (in the bad way) until you wrap your head around the idioms and design philosophy. There's a lot of functionality that happens unless you override it. I fully get that this rubs a lot of people who aren't in the pool the wrong way.

However, in addition to the impressive selection of modular capabilities mentioned elsewhere in this thread, there's a very bright light that goes on when you realize that you can make powerful changes to the way the library works by reopening a few controller classes and defining your own methods.

My strong advice for anyone looking at Devise and perhaps feeling stumped is to open up https://github.com/heartcombo/devise/tree/main/app/controlle... and spend some tens of minutes looking at how the library does what it does. These controller - especially sessions and registrations - contain all of the business logic driving the "magic". Not only do they reveal themselves as relatively simple and well thought out, all of those yield calls mean that you can call those methods while passing a block to them. Whatever is in that block will be evaluated inside of that method when it runs.

The people who designed Devise put a lot of thought into this stuff. When you get it, you suddenly don't want to be without it.

Rails 8 comes with a basic auth generator: https://www.bigbinary.com/blog/rails-8-introduces-a-basic-au...

There's also https://github.com/lazaronixon/authentication-zero that goes beyond that.

So if I have to do a little brain damage to configure Kamal but then can push sites to it easily? I’m in

But I'd be interested to know where Python is more useful, apart from science, data science, ML, AI, and such.

> it is painless

Huh, I wonder why.

I think the answer to your question is the same as any large application: pay attention to your supply chain, architect your systems well, if you don’t know how to do things securely go learn before building (or learn as you go, but that has consequences typically).

I tried hard to find an alternative that could sway me away from rails, but I could not find anything I felt nearly as productive with or enjoyed more. I'm kind of relieved rails is having a comeback. All of the good stuff of rails never really left. People just got too pulled into SPAs and microservices, and rails 8 just showed many who are paying attention how much better things can be.

The group think of SPAs and microservices has been crazy to me. I don't think devs took the time to fully consider how much complexity they were accepting with SPAs and microservices. Certainly SPAs and microservices have their place, but not for everything.

In an ideal world, you hire engineers who have a breadth of knowledge of programming instead of specializing in one language/framework, and then it doesn't matter if a language is "dead" or not, you just pick the best tool for the job. Unfortunately, there's not enough good engineers to go around for such a strategy. As it stands, I would estimate that most people employed with the title of "Software Engineer" barely know what they're doing

Specifically, it might be useful to know if a once very popular (dominant in some circles) framework is significantly less so. That downward trend might be relevant for someone, somewhere. "Dead" is still probably not the right word.

I've done a ton of rails upgrades in my career, they've all been easier than any other framework (except the current batch of js/ts frameworks that use codemods to update the majority of breaking changes).

DHH has been making some pretty wild changes with non-Ruby parts of Rails, but Rails 8 still fully supports sprockets, their asset pipeline introduced 15 years ago. All of the other asset pipeline alternatives are still supported, even though Rails introduced "Propshaft" as a replacement.

The only thing we've had trouble with upgrading has been when Rails added full support for read/write shards... it wasn't fully compatible with Aurora Serverless at launch, but we had wanted to migrate off that anyways.

So.... try adding some signal instead of just noise. Cite specific issues, rather than just try to ride a bandwagon.