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?"
Duh (Score:5, Funny)
Re:Duh (Score:4, Funny)
Flint is extremely sharp (Score:4, Informative)
Correctly flaked, flint is MUCH sharper than any straight razor you can find. We don't use flint in for example atomic force microscopes as tips (instead of say steel) for nothing, you know.
You may think stone age people had just stones for tools, but their flint blades were sharper than any steel (or even soft iron) blade you can get.
I find that comparing assembly to flint is extremely apt. Especially so when you consider the fact that our circuits use a silicon substrate. You do know what flint is, right?
Re:Flint is extremely sharp (Score:4, Funny)
And, if you consider the flint is considerably more brittle/delicate if the wrong type of force is applied, as compared to steel/iron, the analogy gets even more apt.
Wow, what an amazing analogy, and it doesn't even involve cars!
Re:Flint is extremely sharp (Score:4, Informative)
That would be obsidion that they use in surgery. An properly flaked obsidion edge is much sharper than the sharpest steel. How do you define sharper? Obsidion will flake to a single-molecule edge. Steel must be sharpened, and even when extremely sharp, will rip more than slice.
As I recall, the reason obsidion cuts heal better is because the sharper edge slices between the cells of the body, rather than ripping through them like steel.
Re: (Score:3)
Nope, in fact the little bit less sharp tool leads to better healing because it is not cutting that good but disrupts the tissue.
Regarding sharpness Flint and Obsidian are on par. Also steel can be sharpened to have an edge that ends in one molecule. You forget that steel can be really sharp, just as sharp as anything. Modern razor blades or scalpel
Re: (Score:3, Informative)
No. View any high quality steel scalpel edge at high magnification, and you'll immediately notice it's immensely irregular (and thicker) compared to blades composed of flint or obsidian. In particular, obsidian edges average 3 nm in thickness. Steel blades simply cannot achieve that. Where are you getting your information?
Re: (Score:2)
Re:Duh (Score:5, Funny)
One tool to rule them all: Assembly.
An Assembly Server Pages framework, HTML with embedded assembly for processing stuff?
Re:Duh (Score:5, Funny)
That would go against the whole idea -- you're supposed to write to the network card's ports directly. The instructions you want are IN and OUT. You can do better than to use an existing inefficient IP or TCP stack.
I guess some soldering iron monkeys will try to dismiss me for not going closer to the metal, though.
Re:Duh (Score:5, Funny)
The questioner asked for the "best" framework without defining what best meant, so we can pick whatever criteria we want.
Assembly is best if you want highest speed and smallest memory size but don't care about development time.
Personally I would write everything in Perl, because my criterion would be highest job security.
Re: (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: (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: (Score:2)
One tool to rule them all: Assembly.
Well, you could cut him a little slack: FORTRAN will probably be just fine. And yes, of course I'm aware that anything that can't be done in FORTRAN can (and should) be done in Assembly. And, of course, that if it can't be done in Assembly then it isn't worth doing... :)
PL/I (Score:2)
PL/I FTW
Re: (Score:3)
You joke but Facebook has some in-house tool that converts PHP directly into x86 code, and then this is what actually runs when a page loads. I don't know what mechanism they use to pass the URIs to the executables but it would be most efficient for the http server process to do it directly, eliminating the PHP server entirely on the production site.
Re:Duh (Score:4, Informative)
Re: (Score:2)
Ah thanks, I hadn't heard of it in a while, didn't know Facebook open-sourced it.
Re: (Score:2)
It doesn't make sense for the use in this article but for Facebook and other hosts of popular services it makes a lot of sense.
Re: (Score:2)
I wouldn't mind compiling all my production PHP code, if it means it will run an order of magnitude faster.
Sounds Like Cake is the way to go (Score:5, Informative)
If you have an existing base of PHP and Ruby developers then Cake sounds like the way to go to meet them both in the middle so everyone can pick it up fairly quickly. Cake is based on many of the same concepts as Ruby on Rails so everyone should be fairly at home. It is still PHP though so it won't force all your dev team to write better code as much as RoR will. The flexibility of a PHP base can be a plus though unless it is put in the wrong hands.
http://cakephp.org/ [cakephp.org]
Personally I am struggling through my first Zend Framework Project at the moment but I am not sure I would recommend it as it has caused me a few too many frustrations. I do worry that this will just knock all the other PHP Frameworks into the long grass though as it is by the same people as PHP. I am starting to see quite a few job offers coming my way now I have added Zend Framework to my CV so it does seem to be very popular for some reason.
I just noticed you also mention having a Python powered backend, this may change my advice above but it does bring about another question: Do you really need so many different technologies? Surely this must drive up your costs considerably as you need developers with a much wider skill set or more of them.
the cake is a lie (Score:5, Informative)
Cake is second to avoid? (Score:2)
If Cake is second on your list of frameworks to avoid, what's the first?
Re: (Score:3)
Re: (Score:3)
If it's not even public yet, how is it listed among popular frameworks?
Re: (Score:3)
Re: (Score:3)
Cake is loaded with deeply awkward black magic and bad practices
Wow, I didn't realize they'd copied Rails so accurately.
Re: (Score:3)
Y'know, back in the day, we didn't call them "frameworks", we called them libraries, and rather than replacing one bad scripting language with another, which is effectively an interpreted language running inside another interpreted language, well we just had these library functions to tackle common problems.
I think that instead of slowing down the scripts even more with pattern glut and reinterpretation, these people should just invent a brand new language that incorporates all these practices as first-leve
Re: (Score:3)
The reason people call these frameworks is that these environments pretty much dictate how your code will be written. You build your custom code onto the framework provided by these products which is usu
Re:the cake is a lie (Score:4, Informative)
That's why I'm a fan of the Architecture First method to development. Do a formal architecture for the application, then pick the framework that fits that architecture (if any). If none do, fit the closest one and remove anything from it that doesn't fit.
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: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.
Re: (Score:2)
To understand recursion, you must first understand recursion.
I'll see your .sig, and raise you mine.
Re: (Score:3)
I have to disagree with the Cake recommendation. I've tried many frameworks and watched presentations from some of their creators. Using Cake you'll often end up writing just as much code as if you didn't use a framework at all, which defeats one of the reasons for using a framework in the first place.
At my company we use a custom PHP framework. But if your backend is Python anyway, I recommend Django. It's especially good if your front-end is just a CMS. Even if it's much more than that, Django leaves
Re:Sounds Like Cake is the way to go (Score:5, Informative)
Hmm, I don't mean to sound horrible, but if you're finding Zend difficult then I'm not sure you're at a skill level high enough to give a useful answer to this question.
In the world of PHP, Zend is about as good as it gets as an MVC framework, the rest have too much cruft that either require you to work to their own obscure bastardised definition of MVC, or hack around their forced methods of doing things in an ugly way.
As for my personal opinion, well, it's hard to give a single option, there isn't enough information in the original post. Frankly if they're using Microsoft hosting platforms only then C# and ASP.NET MVC are the best choice, if they're using a combination of hosting OS' and want something that's rock solid and will scale well then Java with something like Spring is the best bet, if they're more of a just get something working attitude and are not too fussed about the kind of code consistency and testability then stick to PHP and Zend, although even that's getting quite good in terms of testability now too.
If Zend knocks all the other frameworks into the long grass it's not because of any association with the PHP developers, it's because the other frameworks can't even get the simplest things right, like implementing MVC properly and because they're developed in the same inconsistent haphazard manner as PHP itself historically has been. If however you really really do need something higher level where much more is done for you, then Drupal is about the cleanest, most modular, and most well written that I have found.
Re: (Score:3)
Drupal (Score:4, Interesting)
Drupal can be used as a framework [benbuckman.net]
Re:Drupal (Score:5, Funny)
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).
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).
Re: (Score:2)
Re:Go where your expertise is (Score:4, Funny)
Why? My bank accepts my pay checks.
one (more) framework to rule them all (Score:4, Funny)
http://xkcd.com/927/ [xkcd.com]
I like (Score:2)
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.
Re: (Score:2)
But if their backend is already in Python, why would they gain by being able to use C/C++ libraries?
Re: (Score:3, Funny)
Regular 15 minute breaks.
Re: (Score:3)
That depends on the impact that the frontend has on the whole system; if it's small, 9 hours optimizing the Python code might be more valuable than 90 learning C++ and a new framework.
Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered.
-- Knuth
Re: (Score:2)
That depends on the impact that the frontend has on the whole system; if it's small, 9 hours optimizing the Python code might be more valuable than 90 learning C++ and a new framework.
The opposite is also true: being a C++ developer, I'd rather go with Wt than (re-) learn Rails, PHP or Django.
Also, size: Rails, Django (and even PHP) just do not fit in an embedded environment. Wt does.
Re: (Score:2)
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: (Score:2)
Sorry but no. With ASP.NET you still have the concept of page, session, etc very very present. With Wt, you don't. It makes a huge difference.
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.
Re: (Score:3)
Re:Avoid Django (Score:5, Informative)
Could not disagree more. I've worked with a variety of Web platforms/frameworks; on my current job, there is a bit of Drupal fandom, despite almost no one having any experience (except me) with Drupal - it's just become a popular buzzword here (another story).
So one of my first projects after arriving, management had already had it in their heads that it would be Drupal-based. After digging in to the requirements for a week, working on a prototype/proof-of-concept, I quickly hit some walls and realized I'd be spending as much time patching bugs in existing Drupal modules as writing original code - the data model is complex and Drupal's database abstraction layer is about as ugly as they get.
Annoyed and frustrated, after a few beers with an old friend the night before, I read the first few pages of the Django getting started docs on the way home one night - by the time I got home I felt like I had a strong sense for how the framework was structured, the conventions it followed, etc - the docs were clear, concise, and the framework sounded elegant and straightforward, with a clean design (unlike Drupal, which seems to suffer from no particular design).
I hit the ground running with Django and haven't turned back - since that first night with it, I've not run into any big surprises - everything just works as expected. The code is solid, the design obvious, and I'm really in love with Python (having only written simple scripts with it in the past).
I don't think I've ever found the docs to be wanting, and not sure what you mean by the config being touchy - it practically holds your hand, the integrated debug mode gets you straightened out quickly. It does help to understand what Pythonic code looks like - Django is pretty damn close to a perfect expression of what it means to be Pythonic, so it's advisable to get comfortable with Python itself of course.
The one thing I thought I'd hate with Python - the use of whitespace as structure - I got used to very quickly, with the help of a decent text editor. Otherwise it's been a joy.
FWIW.
Re: (Score:3)
+1 for Django from my end, too. It can be a bit complex at times if you still know what CGI is and are used to code your web pages accordingly, but once you've got going with it it can be amazingly flexible and powerful.
Also, the built in "admin" will save you a ton of work down the road.
I'm not a full-time developer mind you, but the people I've heard good things about Django from are right up there with the best of them as far as development skills go in our company.
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.
Re: (Score:2)
If you have Ruby people on your team, use Rails (or Sinatra/Padrino if you need less magic). I say this only because the Rubyists are going to spend more time flogging any other language into behaving more like Ruby than on actual domain problems.
On the other hand, if you choose a PHP or Python-based framework, one of them might come up with a really handy gem that lets you generate PHP or Python code from Ruby, and you could blog about it.
Not even trying to start a flame war, I'm a Rubyist, I work with Rub
Re: (Score:2)
Yes by all means, code igniter rocks for most applications, just enough framework, fast and stays out of my way.
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
Avoid ORM in any framework to increase performance, though, and CI has no problem letting you write native SQL queries.
I disagree on that. I'm using Doctrine2 with CI2 and it works like charm. Are my native SQL queries faster? For simple cases, probably yes. For a complex application, I am confident that the caching Doctrine does for me will be a benefit, and the reduction in bugs and gains in ease-of-coding are more than worth the performance impact.
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.
Rapid protoyping isn't just an empty name (Score:2)
Rapid prototyping isn't just an empty name. I've noticed a strange hesitation to use rapid prototype frameworks to rapidly prototype something and see what happens.
Its not Java; you'll have something up and working in a day or less. Try them all for a short period of time, see where you're "stuck"/"working" for each platform, then decide which to pursue. Last time I tried this, the optimum framework where I am, for the in house internal app I was working on, was RoR. Your mileage will vary.
The only thin
Re: (Score:3)
The fear of "waste" by rapid prototyping doesn't just show up in a reluctance to use it. Such prototypes have a nasty habit of evolving into the production code that they were never actually meant to become, and that causes headaches for everyone.
It's an incorrect use of rapid prototyping, but it happens, and that needs to be accounted for.
Re: (Score:3)
Rapid prototyping should be done on paper. That way customers understand we are on the design phase and nothing has been coded yet.
The minute they see something they can run and play with they will keep asking why is it taking so long since you had most of it already built.
It takes a lot of discipline to avoid taking the prototype and force it into a production ready product.
no love... (Score:2)
what? No love for ASP.net?
Kidding aside, why would you avoid any framework if it gets the job done? Limiting yourself to one solution only limits what you can get done. Why drop Symfony 1.4 at all when it works for you? (honestly I don't know, I've never used it, or 2.0)
If it's RAD your after, personally, I can't think of anything better for it than MVC in ASP.Net. Sure it might be slow and bloated, but when your balance that against the fact you can build a working system in an afternoon it's nothing to be
Re:no love... (Score:4)
Re: (Score:3)
Oh... You've done it now. Mentioning anything Microsoft in a non-disparaging fashion is first-degree flamebait, on par with advocating pedophilia. On /. we take our religious hatred of Redmond very seriously.
may just as well ask... (Score:2, Offtopic)
emacs or vi? Flamewar at 6!
Use Grails - Ignore your RoR zealots (Score:2, Informative)
As someone that's done web application development in PHP, Java, and Grails (and looked at Ruby on Rails and Scala/Lift), here's what you should be using:
1) Grails
2) Grails
3) Grails
4) Java + Spring / Spring WebMVC
Symfony and Cake try to be full-fledged frameworks but fall short (see other comments.) CodeIgniter is the assembly language of frameworks. You can make any of them work, but I'd still switch to Grails.
I suspect there's nothing wrong with Python/Django, but I've never dealt with them as enterpris
Re: (Score:2)
Instead of Lift, checkout Play [playframework.org] (make sure you watch the screencast)! Scala support is currently a plugin [playframework.org] but will be the first choice language in Play 2.0 [playframework.org] (currently in beta), and it has commercial support [typesafe.com] available.
Basically, it's Ruby on Rails for Scala and Java.
Pick from the toolbox (Score:2)
You should pick from the toolbox; the best framework or tool for the job is the most appropriate for the job, not the most buzz-word compliant or necessarily the last tool you used.
That and "Don't Reinvent the Wheel."
Django or Rails (Score:3)
I have this discussion frequently with customers.
If you have people dedicated - use your people to let them use what they think it's best. If they like the adventure, you can also invite them to explore something else. You have to know, do they like the tech because they are geeky about it, or do they fancy the tech, because they are fanbois with big egos? First group I would let convince me of Ruby for the project and give it at least a try, for the second, I would wait until those programmers mature, and consider a choice more on sheer technical reasons - without any personal ones.
Otherwise, if I have to take a toolkit, I will blindly prefer django over RoR for amountless masses of reasons; but I know a lot of projects who stalled because programmers thought django is easy to master - and projects where django was too light weight to get it running in the direction they wanted to go.
I am a freak for django nowadays, but I learned about it quite early, and needed the db stuff personally for some small project you do if you should actually do other stuff, I would have never thought anybody else than some individuals will ever use it. With rails it was always more about being in a peer group, than liking the language objectively, so I say, do not ignore taste, for it shows insight, but also dont rely on blind fanatism in this decision, it's still a technical one (meaning: depending on your project setup).
Re: (Score:2)
pardon, didnt mean language, i meant framework.
ruby vs. python is another flamewar.
The best things about frameworks... (Score:2)
...is that there's so many to choose from!
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.
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!
Go rather than C (Score:2)
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.
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.
Take a look at the Yii Framework (Score:2)
Comment removed (Score:3)
My Experience With Frameworks (Score:2)
The usual solution to this appears to be to pile on more and more frameworks until you have nothing but a twisty maze of frameworks, and then
Another idiot (Score:2)
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?
Zotonic (Score:2)
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 :)
Re: (Score:3)
At the risk of sounding like a shill for myself, I've actually written about this approach in my books and articles, and have given presentations on it as well (probably not as directly as we're discussing here, but more of a philosophy discussion). Feel free to check it all out at zammetti.com. You can also contact me directly if you want with any questions you might have.
Let me try and answer a few things here though that I've seen in replies...
1. Re: session... it's handled not much differently actuall
No silver bullet (Score:2)
I'm a ruby dev and let me say it clearly: there is no silver bullet. Even in the ruby world Rails is not fit/best for everything (try Sinatra, fall in love). And there are things no ruby framework is fit for (See Twitter, and their sad (originally) misiguided history w/ruby).
There are a lot of non general projects/requirements out there. Watch out. For general stuff I would say yes, go with RoR and Sinatra. One nice thing about the RoR community is that it's very strong on clean code, unit testing (TDD, BD
Django (Score:2)
I'm a ruby on rails developer, but since you already have a backend in python, Django looks more appropiate for your particular case than Ruby on Rails. Django is different than RoR, but your RoR enthusiast will also find things to like there.
I would avoid PHP as much as I could - but that's just my personal opinion.
Solar framework for PHP (Score:3)
I'm really enjoying working with the Solar [solarphp.com] framework. It's well engineered and cleanly constructed.
Certainly worth a look if you're sticking to (or stuck with) PHP.
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.
Opinionated vs. unopinionated software (Score:3)
Assuming Python is important since you have a backend in Python (unclear): choose Django if you want an opinionated framework that makes lots of decisions for you about how *you write code*, or choose Pyramid if you have a desire for an un-opinionated framework. Both are good -- but very different -- choices for the right situations and coder preferences.
RoR and Django are opinionated. I'm guessing there exist opinionated and un-opinionated frameworks in practically any language/runtime. The same is true about the amount of inversion-of-control assumed by the framework in relation to how you extend it.
Give Yii a shot (Score:3)
If you want to keep your existing PHP code, the Yii framework [yiiframework.com] is very nice. I'm using it for a fairly complex web application after having evaluated the other popular PHP frameworks, and having spent a lot time using (and hating) Zend. Yii is simple and light, providing the core MVC but most everything else is up to you. This makes it easy to integrate existing code into it, though inexperienced coders could get a little lost. There is very little hand holding.
It's faster than any other PHP framework [yiiframework.com] I've worked with, though you really do need to use it with mem cache, APC, or similar. In fact speed was my primary reason for using it. We do all our dev work on a VM and even with all the debugging and code analysing, it doesn't slow down much. On our servers it absolutely screams, the weakest link is always the DB. There is a Yii extension for Mongo DB which we are investigating to hopefully cure some of these issues (mostly massive logging/tracking inserts).
There are quite a few extensions written for Yii, and it's easy to create your own : I've created a few and the process is extremely simple.
There are some web based auto generation tools that produce sane code skeletons, for example to create a model directly from the DB. Again this is just the basic structure, it doesn't get in the way, and you're not required to use these tools.
One of our requirements was internationalization, and Yii has a few methods that make it easy to translate and to display prices, numbers and dates in the correct format, etc ...
All in all we were very impressed with this framework, so much so that there is now talk of migrating other applications to it, which are currently using a purpose built framework. In some cases Yii is actually faster, and a hell of a lot easier to code / debug ;-)
Re: (Score:2)
That depends on the framework. There are multiple modular frameworks, where you only pay the penalty for the components you actually use. Pyramid [pylonsproject.org], for example, follows that approach.
Re:Avoid frameworks (Score:5, Informative)
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).
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.
Re: (Score:2)
I disagree partly.
i would not call every framework nowadays just clutter, since frameworks with bad APIs already lost a lot of influence in the last 10 years.
libraries are not written only by single individuals, they have communities behind them.
however, what the typical cluttered "framework" of yesterday was, becomes more and more the "CMS" of any sort. Thats an example, why you should not use php "frameworks" - because they are not frameworks.
django however is well made, you can use it as libraries and se