21–30 of 36 posts
Nitrogen - http://github.com/rklophaus/nitrogen/wikis Erlang web - http://www.erlang-web.org/ Erlyweb - http://erlyweb.org/ And one more for the scalability fetish - http://www.metabrew.com/article/a-million-user-comet-applica...
Scalability is the last thing you need to be worried about. Worry about the business model. If you get the business model right, and you have scalability problems (i.e. "Oh shucks there are too many people trying to pay me money!"), then you can just pay to get them resolved.
Scalability has nothing to do with your choice of framework or language. In terms of scalability, Cake, Django, and RoR are more or less equivalent (the first two are RoR clones after all).
Regarding the "RoR clones" claim, citation, please. Django was publicly released very shortly after RoR, having been developed privately for a couple years. I don't know about CakePHP.
Every major language/framework out there has been used and scaled for large websites. Pick one that you would like to learn, provides you with the flexibility you are looking for, and run with it.
Worrying about how you will scale an app that you have not built yet will be a major drawback. Also keep in mind performance and scalability as you're building the site, but do not spend much time worrying about it before hand. Just take an idea and run with it, tweak the app to scale as you go.
Scalability is extremely application specific. As your application grows, what will be the bottleneck? Maybe it's page-serving performance. Maybe it's the database. Maybe it's disk storage. Maybe it's synchronization of data. Maybe it's raw bandwidth. With no specific knowledge of your constraints, any specific advice is worthless and potentially harmful.
The question you need to ask yourself is not "which framework should I use?" but "how should I architect my application to ensure that the most likely bottlenecks can be resolved simply when I get there?"
If your likely bottleneck is bandwidth, for example, building your application with eventual use of a CDN in mind is probably very smart. If your likely bottleneck is disk storage, make sure you choose a host/infrastructure that allows you to scale that up practically indefinitely. If your likely bottleneck is page rendering performance, make sure you write very clean, unoptimised code, so that when the bottlenecks show up it's a simple matter to boost them without impacting the rest of the application.
Also with Passenger, it scales out just as easily as any framework or language out there. And if you need to jump to multiple servers, you ought to be making enough money to support Engine Yard which solves your scaling problems for you.
Earlier quoted context omitted.
"... Lack of scalability will nag at you and may prevent from making some choices ..." To the point where you have trouble getting more users. MySpace is the classic study here. How do they scale all those windows servers? ~ http://www.baselinemag.com/index2.php?option=content&tas...
This is only a problem if your business model is based around selling poorly performing lower-than-remnant-inventory CPM advertising to users who are largely a) poor and b) disdainful of spending money except on iPods, which famously do not need CPM advertising to reach your users. Not to toot my own horn here, but my (very, very boring) website makes about ~$80 for 1,000 pageviews. It is built on Rails. Supposing I…
Assuming your $80 CPM site is the one in your profile (if it is, what does it use Rails for? edit: nevermind, just read your blog post about your cron bug :p), then it's not very surprising, since it offers a product for download. What would happen if your product made more sense as an online service? If you charged the same price and got the same number of sales, how much would it make per 1,000 pageviews? It would still be a lot more than advertising revenue, but nowhere near $80 CPM.