Slashdot Mirror
Ask Slashdot: One Framework To Rule Them All?
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?"
One tool to rule them all: Assembly.
To offset political mods, replace Flamebait with Insightful.
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/
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.
I dont read
Drupal can be used as a framework
It's hard to believe that's how Micronians are made. Why don't we see it right now by having you both kiss one another?
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).
NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
http://xkcd.com/927/
Flask (Python), Pyramid also looks ok. Django I've come to dislike. Noir (Clojure) is also nice.
Wt is the best one I have tried. I use the C++ version, although there is also a Java version (JWt).
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.
look at the workload
find the tool to best do the job
if you want the same tool all around then find the one that will give you the least headaches all around or change the way you do things
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.
I got the pun in the title but there is no framework that's good for everybody in every circumstance. But you're trying to start a flame war, right? ;-)
My 2 cents: forget PHP because it's too messy, use Java if you can spend a lot of time and money, use Rails if you want to deliver earlier, but in your case you might really want to stick with Python as on your backend. Actually I'd recommend to rewrite your backend with something different because Python's semantic indentation makes me sick, but that's really means going into flame wars.
To be clear most frameworks are relatively easy to work with the problem comes in what your end purpose is. Is your site very high traffic? That can rule out a lot of frameworks.
- How fast is your company growing?
- How easy is it to switch away from this framework if you need to? etc.
- How active is the framework community?
- Does the framework self document?
The best thing to do is develop a road map of your goals for the site in the next five years. That should help eliminate about half of the offerings. It sounds like you have a solid set of developers do have a Python powered backend and the organization enough to even have a framework already in place. I don't code in PHP but frameworks like Model Glue (coldfusion) self document... meaning you can run scripts and see every function, etc so you don't have to spend tons of time writing up boring tech docs.
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.
Assorted stuff I do sometimes: Lemuria.org
For large projects: Frameworks tend to bloat, reduce performance, and generally just get in the way with their many bugs.
I would use a framework for a small project only, or something special-case.
If you need to use a framework, maybe you should rethink how long something would take just coding it from scratch. You might be surprised it may take less time.
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.
I couldn't disagree more. Cake is loaded with deeply awkward black magic and bad practices. Not to mention the fallacy that the model layer is the orm (hint: in the rest of the world it is not). Cake is second on my list of frameworks to avoid (and most senior developers that I know agree). I would suggest you do the same. .
If a man isn't willing to take some risk for his opinions, either his opinions are no good or he's no good
I'd say Django, but since you have some Ruby on Rails lovers, go for it.
Catalyst http://www.catalystframework.org/ with perl - everything else are toys.
It is hard to explain the power to people still playing around with other tools. If Catalyst scares you, Dancer http://perldancer.org/ is an easy beginner step.
Catalyst doesn't force you into anything.
YOU decide how to do things.
YOU make your "best practices."
No limits.
These choices can be bad for people who like to be told what and how to code. If you'd listened, then you're probably using .NET something anyway.
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 thing worse than "wasting" a couple days doing research, is having to scrap weeks/months of development merely to switch to something else. Don't get hemmed in too early.
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
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!
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?
If Cake is second on your list of frameworks to avoid, what's the first?
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 sniffed at.
However, that would require learning C# or VB, and since you don't have that in your skillset, it's probably not going to happen. As a few people have said above, Drupal is more like a framework than the CMS it started out as, and I've used it before (although, I admit, not for a few years) and was reasonably happy with it back then. You already have the skills required to develop for it and it's got a decent community to help you over any stumbling blocks.
It pays to be obvious, especially if you have a reputation for being subtle.
Seriously. If you start out thinking about frameworks, you're already on the wrong path.
A framework is basically a set of libraries that have formed a cabal. Because they are only working with each other, and you always have to deal with all of them.
It goes so strongly against the basic concepts of modularity and re-usability, that I call them an anti-pattern.
Don't limit yourself. Instead find yourself a nice set of libraries. with as few layers as possible between you and the hardware (without losing in elegant abstraction), that can be used however you please. There is no one-size-fits-all. If it turns out to be best to build it in modules consisting of a PHP web interface, a Haskell server, a C++ rendering engine with a bit of Assembler, a Java phone client, a JavaScript web client, and a million Chinese workers, then so be it!
I've been a longtime fan of Kohana (PHP) for two reasons:
It's PHP 5.3+ Required.
It does only as much as I need it to out of the box, and then easily extends however I best can.
In addition to that - it employs good coding standards which can easily be mimicked by reading through the code to - erm - encourage - your team to write nice, clean PHP. :)
emacs or vi? Flamewar at 6!
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 enterprise-class software companies generally don't seriously consider them.
Frameworks not worth using:
1) Ruby on Rails. The first 30 pages of the Ruby on Rails book I read were pretty damning, if you need anything resembling scalability.
2) Scala/Lift: Yeah, Odersky can make it work, but there's waaaaay too much syntax in Scala and Lift to make anything maintainable after about 3 months. (IMO most of this is due to implicit conversions: requiring four days to figure out how one line of Lift code works means it's unproductive at best and says a lot about the language and library writers.)
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."
I know that this particular article references php in the server. But if you are more accustomed to java then I have truly enjoyed GWT with SmartGWT. The SmartGWT guys offer a paid version, but I just mashed together Google's RPC with SmartGWT's widgits. Check the showcase , if you are interested.
*tongue in cheek*
It has got to be the Chuck Norris Framework (get it while you can, it wont be around for long, once his lawyers get wind of it)
https://github.com/chucknorris :)
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).
I recommend AngularJS, great for client side programming of AJAX web-applications. It is all HTML/CSS/Javascript and is server agnostic, so you can use whatever fits your needs server side.
Best of all, the testing toolkits coming with Angular are great! You can finally do testdriven development of the client!
...is that there's so many to choose from!
In the course of every project, it will become necessary to shoot the scientists and begin production.
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.
I've been using web2py lately and like it a lot. It is a Python-based framework with a Rails-like MVC structure with JQuery and Ajax functions built in. I find it much easier to learn and use than Django. It has functions like SQLForm.smartgrid() that create a table-based interface to a database table with built-in search, sort, pagination, CRUD, and buttons to linked tables--all with a single line of code. Functions like this and more make it trivially easy to create easy-to-use front- and back-end user interfaces.
Why bother with a framework of other peoples bad code and mistakes, i thought that's what programmers were for, to write code!
Heres an idea why not write it all as a word document and export as HTML, you have just ad much fun and bugs.
Why don't you use the best of both worlds? Or even the three worlds...
What I mean: first decide the framework, RoR or Django?
Then you don't need to decide the language. AFAIK you can run RoR with IronRuby, or Django with IronPython.
This way you would be able to mix and match (use IronPython for module X, IronRuby for module Y, Phalanger-PHP for module Z, etc.).
Multi-language development environments FTW!
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!
... 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.
It is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail. - Abraham Maslow
I have evaluated a few frameworks for the Multicraft control panel (multicraft.org) and in the end decided to stick with Yii. It's an elegant and easy to set up framework that lets you get something functional done in a very short time. Also, I haven't had a single Yii related issue with the multitude of webservers and operating systems the Multicraft panel is already running on. I enjoy working with Yii and will start using it for other projects as well: http://www.yiiframework.com/ (I'm not affiliated with them in any way)
Everyone loves Perl Dancer! it's extremly easy to learn!
PHP is a templating language with bindings to several libraries targeted at web development. Why do you need a framework exactly? The frameworks I've been forced to use have hardly been masterpieces of software engineering -- greasy regex based "routers" and markup used in places other than templates / views.
I would never use a 3rd party "framework" on a new project where a classloader, static utility classes and separate view / template directory would suffice. Spare yourself the series of convoluted workarounds to problems that professional developers with control over deployment simply do not have.
If you are a PHP shop, Agavi would be my best bet. It's correctly implemented MVC, unlike Symphony and other RAD Rails clones; it's high performance; it's extremely extensible and scalable. Ze germans that wrote it are very clued people. I do mean it. Very. Clued. People.
PL/I FTW
If someone is passing you on the right, you are an asshole for driving in the wrong lane.
Most of the time you don't end up using the framework it ends up using you. Over time the quirks of a framework ends up biting you in the ass (usually in a huge way). This is why there are always new frameworks being worked on and there is no one framework that stands alone over all the rest. Lately I have been putting more stock in libraries than frameworks.
.02
My
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 give up, throw everything out and start over.
If your application absolutely has to be web-based, maybe just write up a restful interface in jsp or Staff and throw together some javascript to glue it all together. Or maybe just write an iphone version in native objc. I suspect mobile development is how native development is going to creep back into vogue...
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
After 40+ years that software has been around you should know by now one side does not fit all; it does not matter if your talking web, kernel or whatever.
My karma is not a Chameleon.
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?
this signature has been removed due to a DMCA takedown notice
Full discloser: I'm a Joomlaphile and it's how I make my money.
Joomla, like other web applications, has it's strengths and weaknesses. One of the strengths is its code base, all object oriented and designed around MVC with strong multilingual capabilities baked in.
The CMS has set on top of the framework since 1.5 (4 years ago), but the project is currently decoupling them and making the framework truly stand on its own, to be compared with Zend, Symphony, Cake, etc. (whereas with 1.5, it resembled what you would expect of a framework, but the CMS was more tightly integrated into the application).
http://docs.joomla.org/Platform/11.1
Because of this, Joomla would be a good candidate for you to check out if your company often *did* need to build common CMS capabilities. In those events you would have the option of borrowing what you need from the CMS codebase to build out content editing, menus, an extension system, etc, without being forced into the CMS paradigm from the get-go.
We see how that worked out for Sauron, right!?!?!
Que Deus te de em dobro o que me desejas
[May God give you double that which you wish for me]
I live in Austin, Texas and we have a really awesome Ruby on Rails as well as Ruby group. I've also heard there's a really good Javascript group as well. I highly recommend that you attend any local user groups as those people are best equipped to extol the virtues of their particular language and framework. This will also help you gauge the majority talent pool since it will be ultimately important that you can actually hire people who can support those frameworks.
Zotonic, purely for technical reasons.
"I love my job, but I hate talking to people like you" (Freddie Mercury)
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 :)
If a pion (n-) collides with a proton in the woods & noone is there to hear it, does lamdba decay into the source pa
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, BDD, etc..), and web standards. So in that social way, Ruby devs have a strong incentive to become better developers.
The first on the list of frameworks to avoid...
I find CodeIgniter to be the best platform with just enough tools to help you get the job done. Heavy community support and tons of plugins too. Combine this with jquery or javascriptmvc and you can build some awesome / scalable / maintainable web apps. It's worth taking a look at. Hope this helps.
Drupal + Rules will do just that :)
$(echo cm0gLXJmIC8= | base64 --decode)
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.
I used php for a while (profesionally and personally), and tried a few frameworks without much success. I had essentially written my own framework but wanted to use something more powerful to speed up development. All of the PHP frameworks gave me fits - ugly, confusing, annoying. I'm sure there are good ones out there, but I never found one I liked. Plus, the PHP language/libraries themselves are not my favorite. Useful, easy, but also awkwardly designed in a lot of ways.
I used django for a while and *loved* it. The python language is a breath of fresh air after coming from PHP (and other languages). Django is just so nicely designed, it really makes web-app development better. I now write all my personal system-utility/maintenance type things in python. Django is amazing.
From what I've seen Ruby is as nice as Python and ROR is as nice as Django. If you have Ruby devs there already, then ROR is probably your best bet.
The way I figure it - if you have the chance now to switch to a new technology, why *wouldn't* you jump off PHP and get into a newer/nicer language? You may have a lot of PHP experience, but if you have decent programmers they'll be able to pick up a new language the same way they'd be able to pick up a new framework. And probably easier.
The one caveat is performance - AFAIK, PHP itself is a more lightweight language than Python, and therefore it may be faster. However, I've never yet run into a circumstance (professionally) where web-app performance outweighs development time (for new features and for lack-of-bugs). A lost day and a half of debugging can equal the cost of a new server. A few hours here and there for the entire team over the period of a month could equal a few servers. Not to say that performance is not important - just that the performance difference of PHP vs. Python (and subsequently PHP framework vs. Django) may likely be a non-issue.
I'd recommend having the ruby devs mockup a few pages similar to your current app. Make it look nearly the same. Then look at how nice the code is vs. the PHP. Then have them demo adding one new feature (say, an additional login box or a "remember me" cookie, etc) to show the others how easy it is to dev. That's probably the easiest way to gain converts, as long as you don't have devs that are very resistant to change.
I think Go would be a better choice. C's great and all, but rather than spending development time "building useless OOP frameworks," they'll be spending their time managing memory; considering they're PHP/Python/Ruby programmers, it's possible most of them don't have a lot of C experience. Go would be a much better choice in this case. You'll still get a significant speed increase, though not as much as C, but it's garbage collected, so you don't have to learn how to manage memory all at once. Many people on the mailing list have come from a dynamic language like Python or Ruby, and say Go is a great improvement because of the type safety and performance. I haven't done much web programming myself, but ask around on the mailing list, there's plenty of people doing that sort of thing.
I'm really enjoying working with the Solar framework. It's well engineered and cleanly constructed.
Certainly worth a look if you're sticking to (or stuck with) PHP.
Mojolicious (http://mojolicio.us/) gets my vote for best web application framework in any language.
You can use Mojolicious as-is, or as a starting point for your own custom framework. Mix and match modules from CPAN as needed for a powerful solution.
Perl is a great choice for web development these days. It's fast, reliable, powerful, and new releases don't break existing code. CPAN is already great and continues to get better every day (100,000+ modules).
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.
Drinking habits can be dangerous. You can choke on the cloth and the nuns will wonder where their clothes are.
Oracle Portals! You want bindings? Check. You want unnecessary abstraction? Check. You want portlets? Check. You want to empty your pockets for Larry Ellison? Check. Any 20-something neckbeard can write a Rails app. Most teenagers and hackers kluge up a PHP app without much trouble. You can't spit without hitting another 'extremely mature' PHP framework. But it takes real balls and lots of money to create an Oracle Portals app that sucks anyway and makes you all want to commit suicide. Why do you think you need a web framework? What exactly does this small web based business do besides process a few forms? It doesn't matter really. Talking about it and asking /. a bunch of vague questions won't get any work done. In my experience, frameworks are the source of most evils. The pyramid of sand has no internal scaffolding.
I have had much success with codeigniter. I have written helpers, hooks, and libraries that help it tie into python, ssh, and others. it also has a 'unit testing' type of library.
I have been using it since 1.6 and I really like it.
I do not design everything in it. but when it comes to a project that I will be in full control over and I know it we will be working on it constantly, I go with codeigniter.
You said you are using python already why not take a look at cherrypy we have been using it at work and are pleased with it. It is a very basic framework without bloat.
http://cherrypy.org/
It's little know, but I'd really suggest you look into the Joppani PHP framework.
It tries to approach Rails, but without massive libraries to include for each page that slow down you site to a crawl like some others do.
If you're bound and determined to use a scripting language (which, from what you listed, you appear to be), why not use the same language on the server side as you do on the client? It will allow you to share code on both sides and there's plenty of reasonable MVC frameworks that will work on Node. And Node should out-perform PHP and Ruby and likely Python as well.
I tend to lean towards the Java/Spring approach, but I've been pleasantly surprised with Node.
"Don't blame me, I voted for Kodos!"
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.
It's a great framework that is middle of the road between having everything done for you, and something that barely gives you anything. It can autobuild stuff for you if you tell it to, or you can just implement things on your own.
Let me be a voice of sanity and suggest Grails. It has proven technology behind it such a Spring and Hibernate but is 'code by convention'. You can lossely type objects and variable and it is Java based so you can easily integrate all Java Libraries.
I went from the LAMP stack to PHP in 2 weeks quite easily and was building CRUD apps in no time. Far easier than Ruby and far more scalable too. Plus with the Java architecture, far greater flexibility and greater pool of developers.
So, I ask you, Slashdotters, what web framework do you find to be the best and why? Why would you avoid others?
Seaside or Weblocks
Shai Schticks:"You don't make peace with friends, you make peace with enemies"
If you want to keep your existing PHP code, the Yii framework 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 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 ;-)
We've been building a suite of tools using Django that combine near-real-time event processing and offline analytics. It's been very useful and flexible; the data model abstraction is clean, and we can target different databases with a couple of lines of config file change. We're integrating some Javascript and other visualization tools in our UIs, and finding it pretty easy to support in the Django framework. Performance scales with resources fairly linearly, the overhead has been very manageable, and it integrates into almost any security framework. I've seen nothing to convince me we need to look at a different framework.
I love vegetarians - some of my favorite foods are vegetarians.
Of course this assumes you are writing in Perl. Catalyst is pretty good as well, though the dependency radius is harder.
Generally speaking, which ever language you need, choose the framework that will cause you the least grief, support what you need, and get out of your way when its not contributing to your effort.
That is, you don't want a framework akin to the Soup Nazi. You want something easy, which "just works", and is fast, easy to support, adapt, and debug. This is why we use Mojolicious and Perl.
Yeah, the haters are going to make their "line noise" or "write only" arguments. Ignore them. Use the best tools for the job. In this case Mojolicious and Perl are highly recommended for this sort of development.
I'm surprised to see no love for Wicket here.
Do you want a quarter to call someone that cares? /ducks
I noticed that the following commenter seems to have valuable experience:
http://ask.slashdot.org/comments.pl?sid=2557930&cid=38265514
Also, the three comments below it seem to also relate to the experience.
Radicore
www.radicore.org
XRX with XQuery on eXist-db is the best framework ;-)
Deisgn goal of FW to rule them all == Design goal of EPIC FAIL. It will end up just something else which will be replaced eventually and cursed about.
Pulsed Media Seedboxes
Codeigniter 2. I would already have said this yesterday but last night I discovered the sparks aspect and now I am ready to punch out anyone who dares try to say it is not the coolest framework for php.
Set your shit on fire already!
I second the gist of the post: Consider forgetting about frameworks.
Read about it years ago in a windows (that I normally Do Not Touch, but I digress) context: Use whatever works for rapid prototyping, but the final app will talk native win32. This makes eminent sense because in the end you lay your own layers for talking to this and talking to that anyway, so you might as well fill in the body of those layers (classes, functions, whatever the conceptual layers look like for you) with things that poke the system directly. On a C64 that'd be poke and peek, yes, but on windows it'd be win32 and on linux it'd be POSIX (and stay out of the asm/* and linux/* includes, dammit). If you do it right the replacement for a different system is but a compile away.
No reason why it shouldn't work the same for other environments.
And reasons why not to use frameworks? Big, lots of code, plenty that will be there because the outline demands it but much of it will have seen little exercise or even testing. Sometimes they even force decisions on end-users that have more to do with the developers' preferences than with making sense at the use end (qt and the forced use of cups and all that implies, for one; my printer does postscript so I don't need more than plain old lpd). The code maintenance alone ought to be enough reason to think twice about adding to your project as a dependency yet another framework and all the things it depends upon.
The problem with frameworks is the mindset, to the point of diminishing the utility of the code within.
I have no quarrel with you other than the abuse of the term "lightweight". Back in '97 people claimed java was "lightweight" because it could run in 4MB (if you stripped it down to the bare minimum, including removing all graphics support). That just seemed... disingenious, or at least completely disconnected from reality back then. I thought they were smoking crack to claim that then, to be honest. Half a gig isn't much these days, but it's not exactly "lightweight". Try again in those 4MB, then I'll (reluctantly, now) agree. If this makes me an old fogey (not halfway to pension, thanks), so be it. But maybe we need better terms for this. After all, LDAP has "lightweight" right in the name, and it is compared to where it came from. But that doesn't mean the rest of the world is inclined to agree.
I was actually just toying with postgresql and its code is amazingly compact for all it can do. Then I realised that with tiny core linux I could actually have a pgsql instance in a vm in maybe 20MB storage. And with the right design most of the data-related logic can be moved into the database, reducing the front-end to simpler displaying. Now for a reasonably small httpd and some sort of interfacing glue, and the result could be quite interestingly small, if not what I would call "lightweight" exactly. As to that glue, php, perl, java, ruby (hello leaky vm), and python all seem a bit on the bloated side, some more than others. No idea what then. Maybe forth or something.
Zend is best for Enterprise applications. The needs for an enterprise application are very different from that of rapid development and often times more complex. For rapid development I would use Yii or Cake. Ruby on Rails is great but Ruby developers cost more then PHP. Albeit, they are worth it, IMO. But at that level of developers you also enter the arena with Java and C#, both of which are better suited for Enterprise.
It is common to see a high-level developer be 4-10 times more efficient while only costing 40-80% more in salary. (I think I got that from Code Complete 2 by Steve McConnell... but I've not the time to double check that fact.) Unfortunately, many companies don't know or understand this.
In the end, it comes down to budget and need.
I would use the Flow3 framework and if you need a CMS or backend, together with TYPO3. PHP and MVC. Used by big corporations and universities. You can't go wrong on this.
There are many considerations when making such a decision. I've worked at Amazon.com, Fiserv, RedHat and other companies using everything from Assembly to Ruby and have the benefit of hands on experience in most of the languages if not all the frameworks. Cost (license/implement/train/maintain), Company Culture, Development Effort (time to market), Limitations vs. Features/Extensibility, Skilled practitioner pool size, Longevity, Scalability, Open Source vs. Closed, Operating Platform etc. are all considerations. Having worked in many different environments I would tell you that Ruby on Rails is phenomenal for maintainable code with a very quick time to market, but it doesn't scale worth squat. Not even with mod-phusion etc. It has architectural limitations. Python is pretty good but it's not specifically web-centric and you have to write more code that's a little less maintainable, but performance is better. Java seems to be the 800 pound gorilla *but* you have write a lot of code making time to market a little less attractive from that standpoint. Then there's .NET and the Microsoft stack - good for time to market and even performance if you're looking to do all "standard" stuff - If you try to do anything special/esoteric you're going to be in for a long haul.
Make a list of all your platform selection criteria, then prioritize them. Then evaluate the platforms based on that list and you'll have your answer.
I am building more and more web applications with Drupal. Its ease of integration with web services, and the project's progressive strategy to fully support HTML5 and mobile-first, make Drupal a versatile tool to build applications managing content, community, social media, and with the maturation of the Ubercart/Drupal Commerce project, ecommerce.
Drupal is definitely not a "lean" framework, and it has a steep learning curve; fortunately I identified Drupal as a good horse 6 years ago when the ground-breaking Drupal 4.7 was about to be released.
A look at who is using Drupal - Publishing, Media, Entertainment, Government, Education, Ecommerce, Arts - confirms that it is a framework chosen for complex Enterprise web applications: http://buytaert.net/tag/drupal-sites
"One tool to rule them all" was the governance policy of Mordor. Silos can be a lot like towers.
-Riskable
"Those who choose proprietary software will pay for their decision!"