Ask Slashdot: One Framework To Rule Them All? 287
New submitter ittybad writes "I work with a small web-based company, and, for some new web applications, we are looking to possibly change frameworks if it will be a benefit to our developers and our customers. We have experience with PHP's Symfony 1.4, and are not happy with what we are experiencing with Symfony 2.0. We have some Ruby guys who would love us to implement a Ruby on Rails solution, and our backend is Python powered — so maybe Django is the way to go. So, I ask you, Slashdotters, what web framework do you find to be the best and why? Why would you avoid others?"
Drupal (Score:4, Interesting)
Drupal can be used as a framework [benbuckman.net]
Wt (Score:5, Interesting)
Wt [webtoolkit.eu] is the best one I have tried. I use the C++ version, although there is also a Java version (JWt [webtoolkit.eu]).
What makes Wt unique is its approach: widgets. You develop web applications like you were developing desktop applications. Also, the API is Qt-like (but using Boost).
I gave up on Rails after I used Wt.
Want a virtualization console? Take Wt, libvirt and an HTML5 VNC client and you are done.
Need Active Directory authentication? Wt, Samba (or Windows APIs if you are on Windows), done.
Streaming? Wt, ffmpeg libraries, done.
Forgetting about bindings and being able to use the millions of C/C++ libraries out there was a huge relief.
Avoid Django (Score:2, Interesting)
If you can, avoid Django - it's a powerful framework, and fairly flexible, but when trying to set yourself up with it, the documentation is very poorly written and organized. We tried using Django for a quick project for an academic assignment - it was nothing short of downright painful. The configuration was very touchy, and the code rather long compared to the equivalent Ruby code.
This is just my opinion based on when I was trying to get myself into Django - and I didn't like it.
Don't use Cake. Try Yii instead (Score:5, Interesting)
Don't use Cake. There's limited support for actually getting back true objects with their ORM, which means you can't really deal with an intelligent data object. I did a lot of heavy research on the subject last year for my web company and found that Yii Framework (http://www.yiiframework.com) really fit my sweet spot well.
My legacy code is/was all in PHP (up to 8 years of code), but I wanted the flexibility and advantages of a good object based, MVC system that I could fit over top of my legacy code and upgrade as I had time (without having to do an entire rewrite of the code from scratch).
If you mainly do small one-offs that don't require much ongoing work / maintenance, then either RoR or Django would work fine. But if you already have a sizable code base, the benefits of using a framework in the same language is noticeable. I keep finding new things I can do with Yii after a year that make me faster and faster. Haven't run into any needs that haven't already been planned for in the framework (compared to CFWheels, a Coldfusion Ruby-on-Rails clone I've been switching a client to, that while quite thorough, does have limitations I'm already hitting after a week). And the Yii forum is quite active and seems to have steady readership and input from the main committers. So wrinkles with the framework get resolved on a timely basis. It's been a joy coding in.
Good luck!
Re:Drupal (Score:5, Interesting)
Now, in my opinion, the real problem with Drupal is that it does not rely on the MVC pattern, and most developers are used to that. Also, it is not object-oriented!
At my place, we have developed an MVC framework that we can plug to Drupal. This way, we get the benefit of Drupal and all its modules, and when it comes to pure PHP development, we have a nice MVC framework instead of those bloody Drupal hooks. If you want to have a look:
It is released as open-source, it is functional, but documentation is not complete yet so I would not recommend using it until we finish the documentation (probably in January).
C for serious (Score:3, Interesting)
There's no framework for serious development, but you'll do fine with any of the bunch as long as you stay a small timer.
So, save yourself an effort if you plan getting big and go with C directly -- Not only will you earn a magnitude of performance over your competition, your development time will be less as well. That's because competent C programmers will not dick around with completely useless cargo cult programming, like picking frameworks. Nor will they spend 90% of their time building useless OOP frameworks (with 10% of actual functionality) on top of what ever framework they started with.
Keep it simple, STUPID!
Avoid frameworks like the plague... (Score:5, Interesting)
... unless you're in the business of throwing together form-based database apps quickly.
That's really all they do well, and there area lot of form-based database applications in the real world, so that's not a small niche.
But for anything that's a little different, you end up spending a lot of time learning the framework, and then even more time working around its limitations. The better approach is to look at your problem and find a set of libraries that are well suited to the task at hand, well documented, well supported, and modular.
Also, take the time to learn your tools properly and exploit them to the fullest. Learning a framework takes time. So does learning about Apache modules and SQL stored procedures. The difference is that the time invested in the framework isn't generally applicable to other problem domains, while Apache and SQL are everywhere, and are worth learning well.
Simpler is Better (Score:4, Interesting)
My experience with python-based frameworks is that they tend to help at the beginning and get in the way when you want to do something that is outside what they do easily. Here's what I have learned:
1. If your developers have access to the file system, then stay away from anything that tries to be a content
management system (I'm looking at you, Zope).
2. Think hard about how user permissions will be handled, because if you screw it up it will make debugging and
security a nightmare.
3. Debugging is harder with web-based development than with desktop development. Make sure your framework
has great debugging tools which (for python development) means:
a. The stack traceback is readily available and
b. The framework doesn't try to catch and handle everything. If it does you will find that your error
messages are raised no where near where the actual problem lies and you will have a terrible time finding them.
4. Maybe skip the framework altogether and instead use individual tools. I use:
- webpy for the dispatcher
- Tryton (with Proteus) for handling the database (This allows me to quickly assemble the "administration"
portion of the application in Tryton instead of building a web front-end)
- genshi for templating
- formencode for validation/user error messages
- pyjamas plus YappyCat for AJAX.
Is it sad that everything I have learned about using frameworks can be boiled down to a
short slashdot post?
Django (Score:5, Interesting)
I've read the comments in this post, and I agree with most of them, especially the guys who argue in favor of avoiding frameworks all together. I get where they're coming from, I really do. In fact, not so long ago, I would have made the same argument. The problem is, to do web development, you really need some sort of "framework" or "library". It doesn't make sense to recreate the wheel for URL parsing, environment param passing (ala CGI), etc...
At the end of the day, you'll need to pick some set of utilities in order to be successful at a web project. It's debatable what constitutes a "framework" vs "utility library", because there's a lot of grey area there.
Of all the ones I've used, ASP.Net, ASP.Net MVC, Sprint, Struts, Cake, Symfony, Django and homegrown, I'm landed pretty solidly on Django.
The reason for this is how it really gets out of your way, and just lets you code. It has all sorts of fancy features if you want them, but you aren't compelled to use them.
It's lightweight (I run several Django + postgres instances on a VM with 500mb of RAM with sub 200ms response times), the different parts are pluggable, you can swap out the ORM, templating engine or admin parts for anything you like, and it embraces the pythony way of doing things.
There isn't a bunch of black magic, it's really very straight forward. The framework code is very readable, and minimal. The core "framework" is really just a set of python modules that give you very handy utilities - URL routing, ORM, Templates, etc...
Don't like sessions? No problem, just don't include that module. Don't like the ORM? No problem, roll your own, or use something else.
Want a full blown framework with automatic admin interface, and all the bells and whistles? Great, it's there for you if you want it.
In general, I've been one to avoid frameworks because I agree with the sentiment of many other posters on here - frameworks do the "easy 80%" quite nicely, but the final 20% ends up being weeks and weeks fighting with the framework.
Django is the only one I've encountered that doesn't have this problem. I've never had to fight with Django at all. My only problems were a lack of solid python skills, but one I picked that up, Django was beautiful and made a lot of sense.
It's the most intelligently designed, practical, useful framework I've ever found, and has done what no other framework I've used has done: actually saved me enormous amounts of time.
Re:Avoid frameworks (Score:4, Interesting)
I don't get it. A framework has piles of domain-specific code that has been tested and is pretty much guaranteed to work. Sure you can hunt around for some open source implementation of every little thing you might use, but having it built in helps.
Chances are, if you're not using some sort of framework, you're using your own libraries or code which basically take the place of a framework. Unless you're doing no output, having something take care of the remaining browser quirks really helps, and especially handling the new mobile platforms.
What quirks you say? Write to the standards? Of course. And then you get a router whose configuration is javascript-based, and does not work at all in Chrome, but works in FireFox and IE. Sure blame Linksys for being crap, or not testing enough, or whatever.
The point is, frameworks do things for you so you don't have to. I can't think of any project that wouldn't be helped from a framework. Unless you're doing something with processing on the server and display on the client. Then it's pretty obvious you don't need a framework, and aren't the audience for the question.