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?"

Comments

Sounds Like Cake is the way to go

[Ash Vince]

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.

Re:Sounds Like Cake is the way to go

[Xest]

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.

the cake is a lie

[ircmaxell]

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. .

Re:the cake is a lie

[ircmaxell]

To me, there is a significant difference between a framework and libraries. Libraries are collections of code to do one or more tasks. Frameworks are libraries that enforce architectural constraints in exchange for reducing boilerplate code and making things easier (and faster in theory) to develop. The tradeoff comes back when those architectural constraints are not inline with the application. This either leads to tons of pain when building the application (I've heard the phrase "just do it the rails way" a few times), or when maintaining due to changes in the app requirements or bugs that are deep rooted in the architecture of the application.

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.

Re:Avoid frameworks

[james_van]

Agreed. Frameworks are nice, but I'm finding them to be very very very overused. Take a minute and really look at your project. Does it actually need a framework? Does the use of a framework save enough time in development to justify the additional overhead? If so, is that because you (or the people working on it) have been taught frameworks as opposed to learning actual programming (laugh if you want, I've met far to many people who know a bunch of frameworks, but couldn't write the most basic raw code if their lives depended on it), or because it actually streamlines the development process? The majority of the projects I've worked on haven't actually benefited in any way from the use of a framework when they've been properly evaluated. Not saying yours is the same, but make sure you take a good, long, objective look at it before you decide on something. My $.02, take it or leave it.

Flint is extremely sharp

[Anonymous Coward]

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

[LF11]

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:Flint is extremely sharp

[Anonymous Coward]

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?

Use Grails - Ignore your RoR zealots

[Anonymous Coward]

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.)

Re:Duh

[larry bagina]

HipHop for PHP converts PHP into c++.

Re:Duh

[Anonymous Coward]

Assembly is a very powerful and useful tool but it has many limitations. First Assembly is (in most cases) very limited as to what you can do with macros. And in the cases where the macros are sufficiently developed the language turns into more of a C language. The language also suffers from Namespace pollution, I have yet to see an assembler that handles namespace pollution in an elegant manner. This means that without a seriously well thought naming convention you could end up with unmanageable code fairly easily.

Second Assembly is not portable. This means that you cant just write the code once compile and use it everywhere like in java. Nor can you just recompile for each architecture. So if your management decides to upgrade your servers without consulting you (Since many management teams know so much more than their programmers) you will have to recode everything, and if you have hundreds of thousands of lines of code good luck. This problem can also arise if the hardware your currently using is discontinued.

The problem with PHP is that it doesn't differentiate between the webpage and the GCI code. Depending on what your trying to do it may still be your best option. But you need to look at your options. Java is best for portability, it can be transferred from system to system without recompiling. if your looking at needing that behavior java is the way to go. Next is C a very powerful language, does everything you will ever need it to do. It's also very fast and has a low memory foot print, making it ideal for imbedded systems where you don't have a lot of memory. (I can also almost guarantee you that C is supported on almost any architecture you will ever use, it's usually the first language implemented after assembly) If your using low end servers or plug servers this may just be your best option. Next is C++ this supports OO, and aside from a few minor differences it's basically the same as java with the exception of needing to recompile for every architecture. C++ uses more memory but is comparable to the speed of C on more modern systems. C++ often relies on having few cache misses to make up for it's code that would normally be slower than C. C and C++ are identical for most practical purposes if you don't use OO. As for Python, Ruby, and Perl. I don't really see a need for them unless your plan on using a more mathematical language such as Lisp, it's probably better to stick with the more mainstream languages as they may increase the stability of your systems and allow you more flexibility. (and often don't require as much retraining of new hires as they were probably taught these in school.)

Re:Avoid Django

[Binary Boy]

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:Django

[Anonymous Coward]

Strongly agree about django.

The frameworks i've used, or thoroughly reviewed are:
Symfony
Grails
Zend
RoR
Django
CakePHP
Turbogears
Wicket
GWT
Drupal (bordeline framework) ...along with a bunch more i looked at more briefly

Django is the best by far. The design just makes a lot of sense, and more significantly, everything you do is just so damn quick. Besides, using python on the server is really nice. It's library-base is big enough to pretty much do anything you want, which is good if you find yourself lacking a feature or two in the framework.