HN Explorer

Ask HN: Do you know any good web framework performance comparisons?

4 points by goatking ↗ HN
I am trying to create a new website, and decided to go with a framework which renders on server side. I don't want to use any React/Angular or similar frontend frameworks.

Currently I am looking at these frameworks:

- Django + HTMX

- Ruby on Rails

- Elixir + Phoenix

I haven't used any of these in production yet. I am trying to find some information on the performance of these frameworks, the scalability, how much hardware they need, etc. I also wanna see how much TPS they can handle on the same hardware (CPU/Memory) with similar access patterns.

Does anyone know any good posts/websites that does a detailed comparison? I am having trouble finding any good analysis that actually makes sense...

(I would love to go with Elixir + Phoenix, but after some research I realized the library support is nowhere near to Python/Ruby. But I am a bit worried about performance if I go with Django or Rails. I want to spend as few dollars on hardware as possible.)

10 comments

[ 3.3 ms ] story [ 178 ms ] thread
nomilk
Something I'd probably do is make a very basic app (e.g. 'todo' app) in each framework, deploy all 3 to heroku, and check out the 'metrics' tab. For a few hours' work, that should give a rough idea of CPU and memory, at least for a very small app.

One other thing:

> I want to spend as few dollars on hardware as possible.

This is a perfectly sensible objective, but always keep in mind any trade offs between development time and server costs. Sometimes less efficient frameworks are faster to develop in, and it can be worth suffering a slightly greater server bill to get an MVP out quickly, especially if the server bill is small to begin with.

metaloha
You could use https://codebase.show/projects/realworld for this instead of writing something new.
nomilk
Wow, that's a very useful resource! It looks like the rails/django/phoenix apps were all updated in the past year, so could probably be deployed rather quickly.
goatking
This is really cool, thanks!
goatking
This is something I could definitely do. To be honest I am trying to save myself from the trouble.

But if there are no existing, up to date comparisons, this will be my fallback plan.

> This is a perfectly sensible objective, but always keep in mind any trade offs between development time and server costs. Sometimes less efficient frameworks are faster to develop in, and it can be worth suffering a slightly greater server bill to get an MVP out quickly, especially if the server bill is small to begin with.

That totally makes sense, but I already researched a bunch of frameworks, and that's how I came up with these 3. I have hobby experience in all 3, and all 3 seems very efficient to work with.

nomilk
One side-benefit: you might find you have a taste for certain frameworks and not for others. Being able to use a language/framework you enjoy more could make a bit difference in the long term.

One other thing, tangentially related, is someone did build the same app in 10 different frameworks, which is a fun overview: https://www.youtube.com/watch?v=FQPlEnKav48

metaloha
Ruby is traditionally quite heavy compared to Python and PHP, similar to Java and ColdFusion, though that is likely less a problem these days. I personally have found Flask (Python) to be super lightweight and still has a great ecosystem of libraries and packages.

For the final word in web speed, though, G-WAN - write your code in C and feel the lightning ;)

bell-cot
> ...trying to create a new website...

Guessing that massive web traffic will (at best) be kinda far in your future - how useful are metrics such as TPS here?

I'd pick based on the resources needed to set up & manage your ops side, developer productivity, time to market, and such. With a veto on that winner possible, if its performance is seriously bad.

goatking
I am actually trying to learn a stack and stick with it in future projects. So I am kinda trying to future proof myself.

Additionally, the more TPS the stack can handle the better. (I can use smaller instance to host the same application)

beardyw
> So I am kinda trying to future proof myself.

That's a worry. I would suggest being ready to change direction at any time would be a better strategy at this stage. There has never been a future proof. Best assume your first choice will be the wrong one.