Paraphrasing one of the most common questions asked by non-technical founders when launching into the phase of building a web application, web service, or mobile API — What framework should we be developing in?

In reality, the question usually takes one of these forms:

• “The outsourced team we hired wants to build in Java, but I’ve heard that newer languages are better, is that right?”
• “I found a Ruby developer and he wants to use something called Padrino instead of Rails. But isn’t everyone using Rails?”
• “We built a prototype in PHP, but now we want to rewrite it. No developers want to be doing PHP. Should we switch to Python and Django so we get the best people?”

You know that all frameworks are really just a set of helpful libraries built to be leveraged by a particular programming language. In many ways, the choice of language will have a longer lasting impact on your organization than the choice of framework itself.

Worrying (or not) About Scale

“But I heard framework X doesn’t scale!¹ because it’s written in language Y!”
Honestly, don’t pay too much attention to such blanket statements. When it comes to making sure your app can grow to support tens of millions of users, here are two truths:

• Whether your app will scale has everything to do with your architecture. You should care immensely about how the code is structured, the relationship between web servers, database servers, caching layers, services, and asynchronous queues. A properly architected application will scale in almost any language or framework. When you read about huge-scale applications, you’ll rarely find them talking about what language or framework they used, but rather what architecture works at scale.
• How efficiently your application scales, on the other hand, may well depend on the language and framework used. For a given application load, you might find that code built in Ruby on Rails might require 10 servers, while the same application running in erlang on Chicago Boss might only require 2 servers. Or vice versa, to be clear. Some kinds of applications suited particularly well to Rails might turn that table.

Just Get It Built

While you might be tempted to demand the most resource efficient framework out of the gate, don’t! You’d be making the mistake of premature optimization. You don’t even know if you have product-market fit yet, let alone what the performance profile of your application will be.

Two factors mitigate the risk associated with choosing a “less scalable” web framework.

1. The ability for your early developers to implement new features and changes rapidly, and with confidence, is absolutely crucial for you to have any chance at your business succeeding.²
2. By the time you have millions of users, your application will most likely be large enough and complex enough that your engineering team will start to rebuild various component pieces using more specialized languages and tools anyway. If you properly architect your application from the start, you won’t be “stuck” forever with any particular language/framework choice.

Facebook is an interesting example. They started in PHP, which was the defacto standard for dynamic web sites back in 2004. Now today, as one of the largest web properties in the world, scale is incredibly important to them. A 10% difference in efficiency makes a multi-million dollar difference in hosting costs and user-retention (faster site = more users sticking around). Rather than change languages or frameworks (an arguably impossible task at their scale), Facebook wrote a custom compiling that translates PHP code into C++ code, so it can run without the interpreter layer on their datacenter hardware. So once you get to Facebook’s scale, then you can worry about all sorts of things. For now, use the framework that gets your site actually built the fastest, over the one that runs it the fastest.

Great Developers Trump Great Frameworks

If you don’t hire a rockstar founding engineer primarily because he wants to build your site in CakePHP when you were leaning towards Scala Lift, then you’re a fool.³

Developers will work best in the tools they are passionate about, and nowhere is that more true than the framework of choice for major web applications. So listen seriously to the reasons your developers want to use a particular framework. Quiz them. Make sure they understand the pros and cons of their choice. And then, in the absence of other compelling reasons, encourage them to go build with it.

Maturity and Community

Different web frameworks, and for that matter programming languages, have different philosophical approaches. Ideally, the kind of software you are building and your process for building it will be aligned with the philosophy of the framework you choose.

For example, if you are building a high-volume messaging or realtime gaming system, you might be better served with a language that’s designed to be really good at concurrency like Erlang, or perhaps Node.js. If you are building rich interactive content site, you might find great support and like-mindedness from the Ruby on Rails community. If you are building a banking application, the legacy and enterprise adoption of Java J2EE might be a safe bet that assures you support from heavyweight customers who care about your backend platform choices.

There’s rarely a reason to choose a framework without a great community, great documentation, and a mature set of companies using it to run successful production applications. For whatever framework you choose:

1. Check out their website. For comparison, here are a few: Rails, Django, ASP.NET, Yii, Play, ExpressJS. Read their main marketing points.
2. Look for other companies using a given framework. Often the frameworks include lists of companies using them right on their site. Do they represent businesses with products like yours? Businesses you respect? Ones whose applications are fast, modern, and running reliably in your estimation?
3. Read the documentation for the major frameworks. Even if you don’t understand it all, does it seem comprehensive to you? Do they include lots of guides and clear english descriptions and code samples?

Finally, evaluate the community around a given language however you can. Talk to developers in your network who have used it (can’t track any down? might be a bad sign). Read threads on some mailing lists or Google groups. Search GitHub for open-source projects, check out their activity and bug lists. Look for communities that are productive and friendly and supportive. Be wary of ones that are too exclusive, too new, or too elitist.

The more mature and well-supported a framework is, the longer it will be around. And the higher-quality the community, the more support your developers will get, both in the way of documentation and friendly online help from others in the community, but also by way of great open-source libraries to help you get more done, more quickly.

A quality community will attract more developers of all levels, which means a better experience for your developers. But also, it means more potential candidates for your business when you look to expand your development team. Candidates looking to build on a modern, fun, and thoughtfully-chosen web framework.

Blah, blah, blah. Just tell me which one is the best?

ClearlyTech will publish a series of articles on various framework choices, so stay tuned. In the meantime, keep an eye on ClearlyTech Recommends for up-to-date suggestions.

Additional Resources

• A Comparison of Web Frameworks