Not hands on with Django (or other Python based frameworks) so pardon the basic question. How do the speed of the generated application compare with the speed of a generated rails application? I know the latter has made some strides recently..
I built a data app one time and one of my devs spent a lot of brain cycles trying to get data to process a little bit faster.
We were getting data through a partner who restricted our data access through an API, where we were limited to 100 records per call. Turns out discussing Spark vs Duck DB isn’t helpful if 99.9% of your software latency is from having to make 750,000 HTTP calls every weekend to run your BI pipeline. For the record, that API was a Rails app - but it was certainly not the fault of the framework in that scenario.
Point being, for web apps, I don’t think it matters unless you’re in the top 100 websites, and even then it probably doesn’t. Complaints about htmx efficiency always confused me for this reason. Your app isn’t slow because you rendered HTML instead of JSON.
Sorry to digress, others may know better than I do but this one is just my experience.
The only time I’ve run into computation speed bottlenecks in either was doing data analysis in Python, and you usually just bring in Python libraries that aren’t written in Python like polars or DuckDB. Sounds dumb, but it works pretty well.
Standard practice has always been for me that long running tasks get sent to a job queue anyways. So ideally nothing in the UI is dependent on something that is long running. But again, in my own work any long running tasks is almost always limited by network latency.
Python is generally faster than Ruby, especially in the newer versions. That said, we’re still talking about two of the slowest languages out there, so the performance gap probably isn’t that big.
This was generally true before the introduction of YJIT, but with YJIT, Ruby's performance has improved significantly and may even outpace Python in some scenarios[1].
sroerick|1 year ago
We were getting data through a partner who restricted our data access through an API, where we were limited to 100 records per call. Turns out discussing Spark vs Duck DB isn’t helpful if 99.9% of your software latency is from having to make 750,000 HTTP calls every weekend to run your BI pipeline. For the record, that API was a Rails app - but it was certainly not the fault of the framework in that scenario.
Point being, for web apps, I don’t think it matters unless you’re in the top 100 websites, and even then it probably doesn’t. Complaints about htmx efficiency always confused me for this reason. Your app isn’t slow because you rendered HTML instead of JSON.
Sorry to digress, others may know better than I do but this one is just my experience.
The only time I’ve run into computation speed bottlenecks in either was doing data analysis in Python, and you usually just bring in Python libraries that aren’t written in Python like polars or DuckDB. Sounds dumb, but it works pretty well.
Standard practice has always been for me that long running tasks get sent to a job queue anyways. So ideally nothing in the UI is dependent on something that is long running. But again, in my own work any long running tasks is almost always limited by network latency.
rednafi|1 year ago
ismailk|1 year ago
[1]: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...