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?"
Go where your expertise is (Score:5, Insightful)
If people in your group already love RoR, it's best to go with their expertise. Technically, there isn't enough difference to make it matter.
Backends are virtually always in a different language than frontends (not that that's a good thing, but it shouldn't worry you too much).
CI (Score:4, Insightful)
My personal framework of choice is CodeIgniter, though if you have Ruby people on the team then you should definitely check CakePHP.
I like CI because it works, and it isn't as arcane as most of the other frameworks out there, meaning that if I want to write my own library, it is fairly easy to do so and I don't need to spend weeks digging through all the other crap first.
Also, it is fairly well documented, and that's very important.
Just stay (Score:5, Insightful)
Why not stay with Symfony 1.4? It's a mature and well-supported framework. We have been playing with Symfony2 ourselves at my current job, but decided to keep using 1.4 until the formgenerators of Symfony2 are a bit more mature.
Of all the php-frameworks i've worked with, Symfony 1.4 still makes me most productive.
Re:Sounds Like Cake is the way to go (Score:4, Insightful)
It is still PHP though so it won't force all your dev team to write better code as much as RoR will.
I sincerely hope this isn't being listed as a plus for using Cake. If "language/framework/methodology n forces me to write better code!" is ever heard as a complaint, the source of said complaint is in the wrong field.
That being said, Ruby and/or Rails doesn't force anyone to write better code. I have seen some crawling horrors perpetrated in Ruby that have kept me up nights. They do facilitate the writing of better code quite nicely. Whereas PHP doesn't do anybody any favors. Ever. PHP WTFs are generally of the "never sleep again" variety. The Cthulhu of WTFs.
No easy answer (Score:5, Insightful)
There isn't an easy answer. All frameworks are great at getting you 80% done then make the last 20% nearly impossible.
What you know best is properly the right thing to use as long as it's capable of getting the job done and you can still find new staff who have some knowledge of it.
Re:Duh (Score:3, Insightful)
Assembly is best if you want highest speed and smallest memory size
Until you realize that you're not better than a C compiler.
Re:Duh (Score:2, Insightful)
Assembly is best if you want highest speed and smallest memory size
Until you realize that you're not better than a C compiler.
Until you realize that you're not better than a PHP interpreter.
Re:Avoid frameworks like the plague... (Score:4, Insightful)
Using a framework doesn't mean you need to drink the cool-aid or use ORM - in fact, if you choose a hybrid framework, you can pick the components you need, and still use your legacy/custom code for the rest.
Re:Wt (Score:4, Insightful)
"What makes Wt unique is its approach: widgets. You develop web applications like you were developing desktop applications."
You mean apart from ASP.NET WebForms?
If the 90s taught us anything it's that native code on the web is a security nightmare. If WebForms taught us anything, it's that no matter how hard you try you can't sensibly mangle the web into supporting a desktop widgets style development paradigm without countless side effects (like grossly excessive postbacks).
Now I don't like to prejudge something without trying it, but this thing sounds like all my worst development nightmares come true.
Re:Avoid frameworks (Score:4, Insightful)
I take the opposite view. I've seen developers who avoid frameworks because they were Not Invented Here, and then spend a lot of their time re-inventing their own framework.
That's not to say that some frameworks aren't bloated and hideous and not worth the cost (the original Java Enterprise Edition comes to mind).
Don't underestimate the "no framework" option! (Score:5, Insightful)
We've gone through a number of options where I work, from a homegrown framework to Struts to various other trials. Eventually, when I managed to pull us into the RIA world, I make a suggestion that got crooked looks initially but which now, a few years on, is seen as ideal: NO FRAMEWORK AT ALL!
We're primarily a Java shop, but this can apply in any shop since there are similar options available for .Net, PHP, whatever else, but I'll describe our model because its very simple: our apps are nothing but POJOs (Plain Old Java Objects for those not in the Java realm) that we talk to via DWR.
That's it.
No Struts, no JSF, no Spring MVC, not even straight servlets! Nothing but pure, simple Java classes with no real tie to any HTTP-related objects (well, usually... some exceptions here and there are required).
The benefits are many: the code is simple and clean... the classes are so easy to unit test that we actually manage to get our developers to do it (sometimes)... configuration doesn't get in the way (no, it's not as simple as some frameworks because there IS configuration, but its so minimal no one minds)... performance is top-notch since there's no extra work being done by a framework first (granted modern frameworks are very efficient and this difference is probably minimal, but still)... and new developers can be brought up to speed in less than a day and no one is ever confused by the code, that's fore sure! There's also been an implied side-benefit: our apps are written in a very stateless fashion since using state becomes unnatural in this architecture (there IS some usage of state used in some places where it's truly necessary, and that's the exceptions I mentioned earlier to not using HTTP-related objects). Yes, this was one of my goals in pushing this approach in the first place, but it's nice that I didn't have to hand down any edicts or anything because it came naturally out of the architecture anyway.
What you wind up with really is a service-oriented design since you're doing more work client-side and the server-side code is a lot thinner... things like navigation and such, transitions between states, are no longer handled by a server-side framework (there's way you still COULD do it server-side, but it becomes pointless). This definitely takes some getting used to and we had our share of paradigm shift-induced ugliness. But we got through it and we're all the better for it.
But, if this isn't the type of application you're looking to develop, if you want the more "classical" web app model, this probably isn't the way to go (although it still can be valuable to mix a technology like DWR in to your, say, Struts-based application... that can be a good first step in fact). You definitely do have to rely on client-side code more (no, NOT at the cost of security, you can be just as robust in that area as you could ever be if you do things smartly). Pair something like DWR with a top-notch front-end library (ExtJS is our choice) and you have yourself a very powerful architecture that you could even call a framework if you want.
My point is simply that you shouldn't get into the mindset that you HAVE to have some big, do-it-all-for-you framework to be productive, and in fact if you go to the opposite extreme and use no framework at all, if you do it wisely, you can find you are more effective then you'd be even with the best framework backing you up. "None of the above" can in fact be a viable and even possibly utopian answer to the original question :)