That’s the question posed by the thread, though: Are frameworks like CI on their way out because you can’t drop components of them into an arbitrary environment and expect them to work. The consensus seems to be that there will always be a need for CodeIgniters that nudge you into arranging things in a particular way, but the existence of libraries like Flourish brings up an interesting question: How decoupled should components of a framework be? I don’t think there’s any clear answer; Like I said above, decoupling and tight integration are both ways to hang yourself—the only real difference is what color the rope is and how you feel like using it.

If the conversation is moving on to “How can we create libraries [etc] that we can use in any environment?”

My answer to that would be not to use a framework or any libraries like Flourish of any sort, and just use native PHP functions. But, since we have all chosen to ue [or not use]a framework of some sorts, our code is to be bound to that framework. Surely if you want to make resources that can cross pollinate frameworks, cms’s whatever, use native PHP since that will always work. But then of course that poses the point that PHP won’t run in an ASP environment.

@Adam

I think the reason we see libraries exist is to solve non-trivial problems that you don’t want to have to re-code in raw PHP every time. While there are a number of “trivial” classes included in Flourish to sort of round out what I use for projects, quite a bit of work was done in a number of non-trivial places to allow for code that runs everywhere on any version of PHP 5.1+.

For instance, 5.2 introduces great functionality including JSON encoding/decoding, datetime objects, httponly cookies, string-based static method callbacks and more. Unfortunately a large number of the servers on the internet are stuck at version 5.1.6 due to Redhat (and thus CentOS) wanting to stick with a stable version and backport security patches. One of the goals of Flourish is to provide this functionality without having to worry about what Linux distribution your server uses.

In addition, some really non-trivial functionality is included for handling UTF-8 strings in the fUTF8 class and the fNumber class implements arbitrary precision math even without the bcmath extension.

On a similar note, you can use PDO for your mysql connection, or you can use fDatabase and it will figure out if PDO is available. If not, it’ll use the mysqli or mysql extensions instead. This type of functionality is probably a bit less useful if you are working on a single project on a stable environment, but if you are writing PHP to be run on all types of different environments, this is invaluable.

I don’t know if you do much javascript programming, but the libraries in javascript do quite a bit of work of fixing all of the cross-browser issues. Part of what I am trying to accomplish is to do this for PHP, but to focus on fixing version and configuration differences.

So, in that sense I think using Flourish instead of pure PHP actually makes your code more flexible and run in more situations.

There is certainly a fine line between de-coupling all of the classes in Flourish, but at the same time not repeating too much code and keeping usage simple. This approach to trying to make Flourish very re-usable carried through to the Advanced Download page where you can pick the classes you need and it will automatically select the dependencies. Certainly not important for everyone, but helpful for those that just want a bit of functionality.

You choose a framework but after getting to know it you find out things are lacking because they can’t be everything for every one. In CI for example there is no convenient way to handle pages with output based on one template. And what do most people do, me included, create a way to make it possible in CI.
Why do people do this? Because it’s a very common thing and it’s part of the core, load->view.

But instead of extending the loader people create a library. But that library can’t be used in other frameworks because it’s tightly coupled with the framework. At this point you start asking yourself why not use a template library from somewhere else, more seasoned people will skip the first step.

In the end you have a framework that has so many third party code you start to wonder what the added value of the framework is, because all the extensions start to weigh on the framework. If you start to shed the fat and you find out you have a framework of your own, you begin to think about the time you put in to make things work in the framework you choose. While at the same time there were libraries that are more loosely coupled, meaning less time that is needed to spend making things work.

xwero - 22 January 2009 10:02 AM

In the end you have a framework that has so many third party code you start to wonder what the added value of the framework is, because all the extensions start to weigh on the framework. If you start to shed the fat and you find out you have a framework of your own, you begin to think about the time you put in to make things work in the framework you choose.

I’m starting to see your point. While CI gives us a good set of tools, they don’t fit every purpose. Therefore I use CI to make my own tools, but I can’t lend them to a friend as my screwdrivers rarely fit.

I think the main reason for this is not frameworks being at fault, but is more caused by CI lacking a good (official), well-maintained repository for libraries, helpers and various other modifications and the fact that community supplied code is very rarely included or even acknowledged.

This was the cause of the Kahona fork, people getting fed up with not being able to make community contributions. However this is definitely a good thing even though it is a pain. Without good source control on CI, we’d have a bloated piece of crap that nobody would want to use.

We need to find a way to get good quality libraries into the source of CI, or find a decent way of making new libraries known about so people can stop coding their own tools every time, and start swapping with their friends.

Gee, such a long discussion on this… is anybody using CI or whatever framework out of obligation or so? Personally I don’t see myself using any tool if it doesn’t make my job any easier.

I tell you what: I have a hammer, but maybe I am not sure I should keep it… I heard of these things called screws.

Honestly, frameworks are useful for the purpose they serve. If you don’t need them then you naturally don’s use them. It’s that simple to me.

Codeigniter has been a very handy tool for me, that is the only reason I use it.

If the question is: is it possible to move MVC frameworks a step further and save the programmer even more time?
Personaly I know of this tool that goes further and implements a ‘web application patterns’ that one can use out of the box. It’s a cool concept, but it needs to mature
http://web2py.appspot.com/t3/default/wiki/main

If that kind of framework will take over conventional MVC frameworks… I would say it won’t.

Adam Griffiths - 21 January 2009 09:40 PM

If the conversation is moving on to “How can we create libraries [etc] that we can use in any environment?”

My answer to that would be not to use a framework or any libraries like Flourish of any sort, and just use native PHP functions.

Yes, that is the question, but you’re answer doesn’t make sense. Loosely coupled libraries can be used in any php environment. CI libraries cannot without modification. Both use native php functions.

plainas - 22 January 2009 07:58 PM

I tell you what: I have a hammer, but maybe I am not sure I should keep it… I heard of these things called screws.

How about a better hammer? Code libraries and frameworks of all sorts are being created and improved all the time. Don’t dismiss this conversation simply because you’re complacent with CI. I’m never completely satisfied with any tools or anything that I create.

plainas - 22 January 2009 07:58 PM

Gee, such a long discussion on this… is anybody using CI or whatever framework out of obligation or so? Personally I don’t see myself using any tool if it doesn’t make my job any easier.

I asked a general question. CI is the thing to bring the discussion closer to the public. If i generalize it more to an other thing people know, i could pick cars.

There are lots of models but most of them all share basic components. There are only a few undercarriages that are the base of each model, a few types of motors, tires, ...
This is why other companies can manufacture parts for different car companies.

When people buy a car most of them don’t want to change much but there are people who go all out and create cars like this. But to achieve this you need a lot of time.
Other people know they need a highly customized car and instead of buying a car they buy parts and make their own car. This cuts down the time spend making the end product because you don’t have to deal with the flaws the off the rack cars have.

Rick Jolly - 22 January 2009 11:15 PM

Loosely coupled libraries can be used in any php environment. CI libraries cannot without modification.

That’s because they are Code Igniter libraries, that are shipped with Code Igniter, designed to be used with Code Igniter ...

That’s a tautology and doesn’t really address the discussion at hand. The original post asked the question, are frameworks losing their dominant position in the developer landscape to high-quality standalone products? If that’s the reality, is there a case to be made for moving CI (or other frameworks) toward a decoupled application model.

I think the root of the discussion is about the value of loose coupling. As I described above, there’s complexity pitfalls with developing sophisticated standalone libraries. Feature repetition, inconsistencies, and execution overhead are all problems with non-integrated systems. A tightly-integrated system has its own issues—inflexibility and a tendency toward monolithic or “giant blob” application structures are the two biggest ones.

in my opinion there will always be frameworks. and there will always be people who do not use them. the reason we like the frameworks so much is they cut time to do thing. the reason we dont is because you have to conform to a certain style of programming. but this is why the framework is successful. if you had a framework where everyone coded completely different it wouldn’t be a framework. it would be a jumbled mess of code where you had to look up how to call a function each time you called it. there would be no consistent naming conventions, no order to how variables are passed, and the code would most likely be poorly commented / explained.

so there will always be frameworks for the people who dont mind conforming to a style and hacking to get certain things done. and there will always be people who code custom each time because it give them what they want exactly the way they want it will just take longer because you start from scratch each time.

again just my opinion

To add to that, each language also has it’s own twist on the world. PHP uses_underscore_words while JS usesCamleCase words. Some things just make since and should be done a certain way while other things are up the the programmer and the language.

One thing nice about CI (as appose to other frameworks) is that 85% of the time it follows the logical “PHP way” of handling things helping to enforce the structure of the actual language rather than some strange way new way of coding the designer picked up from Perl, C, or Ruby. And I don’t mean improvements here either (like AR) - I mean people that try to code PHP the same way you would code ASP or Javascript. A good framework should TEACH you proper PHP so that you don’t try to go off into some other style that the language wasn’t built for.