4 ms·
Congrats for successfully getting your rails site to load faster, but it's still slow. Honestly, what you're doing at this point is delaying the big rewrite. T
by 23david 14y ago
Congrats for successfully getting your rails site to load faster, but it's still slow.
Honestly, what you're doing at this point is delaying the big rewrite. That's not a bad thing, but it will still be necessary at some point to offload your real-time features to systems that are intended for those kinds of things from the ground up.
Rails was fundamentally designed to optimize for programmer productivity over speed of execution, with the idea that people generally cost more than hardware. Unfortunately once you get to serious scale the hardware necessary to keep things quick starts costing a lot and operationally it becomes a big headache and stuff just doesn't work.
It's going to take a seismic shift for rails to suddenly outperform lightweight 'real-time' frameworks running on faster scripting languages. We need to be honest and aware of both the benefits as well as the limitations of our tools.
- batista 14y ago>Congrats for successfully getting your rails site to load faster, but it's still slow. Looks pretty snappy to me. >Honestly, what you're doing at this point is delaying the big rewrite. That sounds brilliant! As in: http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000069.html
- 23david 14y agoThat's definitely a classic article. It just doesn't apply here. Hard to explain why without going into a ton of details, but basically: Layervault in 2012 != Netscape in 1996 Netscape's crufty spaghetti C code != Layervault's elegant but slow Rails code