Does it make sense to avoid a framework when building a large webapp with PHP?

Question

Being a PHP web application developer for several years now, I've had my share of MVCs and frameworks. At first I thought they were the best thing since sliced bread; everything seemed to be very easy to implement.

Now however, it seems that the more complex the application gets, the more hassle the framework introduces, so I have to develop workarounds to overcome them. Such workarounds are usually pretty daunting and complex since I have to delve down into the framework core code and make changes so that it behaves the way I want.

For example, in one of my projects where I use Slim(C)+Idiorm(M)+Twig(V) (which I believe is very flexible), I have to create a custom function just to display dynamic data in parent templates; without a framework I could have simply executed mysql_query() in the included file.

Okay, frameworks are cool if I'm creating a simple company profile website; I can just whip some code in one night and they're usually ready by the morning, and the amount of good coding practice and design patterns I've learned from them is very valuable.

But really, for a complex web application like an all-in-one web based school management system, frameworks usually get in the way of my business process like in the example above.

So my question is: is it okay to just go back to basics, and use standard PHP code and libaries for doing my next project where there might be a gazillion frameworks and libraries, provided I can sufficiently use good coding practices and follow sensible design patterns like MVC? My development team is pretty small: only 2 programmers and 1 designer. The other programmer agrees with my thoughts above.

Answer 1

My experience is pretty much the opposite of yours. When doing small, quick things, a framework can "get in the way" a bit as you need to lay out your code in a certain way and think about things carefully before proceeding. By just jumping straight to mysql_query you can have your prototype up and running much quicker.

But for large, complex sites, carefully laying out code and really thinking about how you write your code is extremely important if you want a site that will be maintainable going forward.

In particular, adding mysql_query calls to random parts of the page cycle are generally a really bad idea. You might have one here and one there to begin with and it's no big deal, but before long you'd got dozen spread all over the place and you're wondering why your pages take 3 seconds just to render. Or you change your schema and seemingly unrelated sections of the site break for unknown reasons.

Answer 2

In my opinion a framework should only be used if it makes the development process easier for you, and not cumbersome. There's nothing wrong with not using a framework or building your own, especially for small projects.

Obviously you will still need to pay attention to the structure and security aspects, but considering you have been using frameworks for many years you probably already know those aspects inside out.

For larger projects, I agree with the others, meaning that using a framework is probably going to be the best option in the long run.

Answer 3

My experiences with server side "frameworks" have been pretty unpleasant, for example:

A) Jar file hell where frameworks conflict with each other or the app server for mutually incompatible versions of stuff you don't want and don't know anything about and are not in a position to dictate anyway as it will prevent you from deploying on multiple servers.

B) Catastrophic explosion of the simplest object creation into thousands of unnecessary SQL executions.

C) The bizarre notion that coding 100 lines of XML is somehow easier or more reliable than coding 2 lines of Java.

D) The need to write 100s of lines of completely unnecessary server side POJOS to map onto client side objects in another, or sometimes multiple other languages (C# JS etc)

E) Not having a clue what really happened when you get a 30-level deep stack trace that doesn't even include the line of code you used to call the framework.

Be a renegade, write your own framework... you won't regret it as long as you plan first to eliminate all the unnecessary stuff the others fool you into thinking you need. Then you will understand all of it, it will ship in Kb instead of Mb and it probably will "run anywhere" which was one of the founding principles of Java wasn't it?

Try thinking this way "why do I need this... is it just to keep the framework happy?" .. If I don't need that, then what else don't I need?

Answer 4

There was a presentation way back by the Django developers, which I am having trouble finding now, but they talk about the "valley of efficiency" where a framework makes you more productive.

Assuming you have no knowledge of the framework when you start a project, your productivity initially will be very low - you will be learning the convention of the framework rather than the idiom of the language (which hopefully you already know).

After a short amount of time, you will have picked up on the conventions and this is where frameworks really shine - suddenly your productivity is through the roof and you're progressing and amazing speed through development.

Eventually, though, the project will become of such a size that the framework is more of a constraint than a boon, and you will see yourself railing against the framework to try and implement some features.

In the presentation, they mention that of course if you already have knowledge of the framework's conventions then smaller sized projects do not have the initial hindrance to efficiency.

Thus, for small projects (in my experience, anything under ~500 hours) your efficiency with a framework will be greater, likely, than your efficiency without. Once you get into a certain threshold (between 500 and 800 hours, IME) then you start realizing that there are limitations to what the framework can offer.

With that said, frameworks offer a much greater benefit than just efficiency - a framework like Symfony or Django or (I am assuming) Rails provides a convention that allows a team to flex dynamically and also allows clients or product owners to change their staff without requiring the new resource to completely relearn a new system - if they are familiar with the convention of a framework, and that convention has been followed, they will be much more productive initially than otherwise.

Answer 5

A well-designed framework should be an aid to the programmer, not a hindrance. If the framework you've used is getting in your way too much, I would suggest looking at a different framework. Each has its own coding style, and its own pros and cons.

Having said that, the Zend framework seems to be wildly popular these days, and honestly? I struggle to see why sometimes. I've had to work with it in the past and I haven't liked its architecture one little bit. The Zend_Form class is ridiculously overengineered, its decorator system is utterly horrid in use, and the decorators tie forms to views, breaking a fundemental concept of OOP stating that objects should be loosely coupled. It also has a lot of code implemented as Singletones (which are bad for reasons that are well documented so I wont reiterate) and the Registry object also contributes to encouraging a sloppy coding style.

I've heard that Zend Framework 2 (currently in beta) is a much better product, but the bad taste Zend 1 left in my mouth means I'm not in any hurry to try it out.

Still, at this point I'm just ranting. :) There are plenty of frameworks out there, each with their pros and cons, I'd suggest evaluating a few of them.

Answer 6

What you describe has been called "abstraction induced complexity" in the past. The only paper on managing it is: Managing Abstraction-Induced Complexity by David Keppel. Keppel would suggest that the frameworks have a design that causes abstraction induced complexity.

Answer 7

Working with a framework is helping you to speed up your development by not reinventing the wheel. Framework also provides you the tools to help you properly design your application (but it doesn't stop you from doing poor design decisions e.g. accessing the database directly from the view).

Sometimes when you need a custom functionality it may take longer to properly write it. But if you're constantly hacking and finding workarounds then you're working against the framework or the framework doesn't suit your needs.

Bottom line is this, using a big framework for simple projects (e.g. displaying a few fields from a database) can sometimes be overkill. For big or complex projects, use a framework.

Answer 8

There are multiple sides to writing your own code vs. using a Framework:

The size, basic knowledge and experience of the team you are working with: If they never used a framework or have an idea of how to architect an application you are better with a well documented framework with a lot of examples and see that you speed them up.

The size of the application: You never know beforehand how it will be used. So you better be prepared for growing and changing. Can your framework, that you want to code in one night, grow with the needs of the management? Change field-types in the DB and it takes a minute or a day to implement, that is my point here.

The Preparation: If you use a framework you can start designing the application instead of coding the core of your application, use one where security and deployment are important parts, that is what takes so much time. Everytime.

I always argument with "the management" to use Symfony2 as it is a framework for webdevelopment. Management thinks it's to big, it will cost money and shy away programmers as the learning curve is steep.

Answer 9

Frameworks are still going to be used for any language in modern, especially for large projects. The larger a project gets the more important a framework is, so you know where the logic is for everything, and every feature has a similar layout. It makes modifying a project easier and learning it easier when you know where to look for all data access, or all presentation, or where business rules are managed.

It is necessary to pick a framework that fits the project though, an enterprise solution requires an enterprise capable framework. This is the problem you are going to run into when using PHP. Many (most) frameworks aren't intended to be used at a large scale, they work fine for smaller personal sites though. For something like the school management system you mention, its going to require a more robust framework, and it may take some time to find a proper framework in PHP.