Framework Philosophy

I’m starting this topic merely to get you all to stop and think about Yii in a different way.

What is a framework?

A framework is a framework for your code, classes, technical requirements, sure.

But first and foremost, and framework is a framework for thought - it’s all about providing developers with useful concepts to help developers think about goals for their software in abstract terms.

Technical details are important, but the concepts must be sound. Don’t get so caught up in technicalities that you forget to question the usefulness of the concepts they support and encourage. Not everything that glitters is gold.

Just throwing putting that thought out there, and please feel free to contribute your software philosophy to this thread! :slight_smile:

My understanding: Framework = A set of protocols + supporting libraries

Protocols require framework users to follow certain rules when writing code. In Yii, protocols include: properties, events, configurations, MVC, widgets, etc.

Libraries typically implement the protocols or make it easier to follow the protocol. In Yii, examples include: CComponent, CController, etc.

Some philosophies for designing protocols and libraries in Yii:

  1. Protocols should be simple and proven: the more complex a protocol, the more difficult will it be accepted, and potentially more limited.

  2. Libraries should be practical and support 90%+ common use cases: do not use 90% of the complexity to handle 10% rare cases. They are better handled case by case by framework users.

  3. Prefer simple design patterns to complex ones. In other words, no over-design.

Another important thing occurs to me, as we’re discussing many different aspects in other threads in this forum area: If a framework is a constellation of protocols, there is an overall concept behind the choice of those specific protocols and the specific way in which they were combined to form a whole.

The way to succeed with any given framework, is to accept the concept and practices of that framework - you agree to live within the constraints of a “frame”, as outlined and defined by the protocols and their implementations, and in return, the framework leverages those defined practices and lets you skip ahead and get to the “meat” of whatever it is you’re building.

A word of caution: in the wild, there are hundreds (probably thousands) of patterns, protocols, practices, concepts and ideas. Some of those are new and exciting, to the point that some have been declared a "must have" for any serious framework. With all the buzz, just keep in mind that the reason why a framework works, is because of the chosen protocols and the specific way in which they were combined - adding support for a new kind of protocol does not automatically make the framework better, only if that new protocol contributes something significant to the overall concept, complementing the "whole" in some way, making it more complete.

For example, I like the idea of unifying two concepts that have been identified as being very similar, because this decreases the number of concepts you have to choose from to complete a task. We should scrutinize the idea of introducing any new concept - is this new concept a critical, missing piece, required to achieve a significant goal? And if so, does it overlap with some other concept already present in the system? And if so, would life with the framework be significantly improved by replacing one concept with another?

Simply adding more concepts is often very tempting, with some immediate feeling of having made a great accomplishment. Often, that is merely the satisfaction of having learned something new.

I believe it is far more important to refine and improve on decisions already made, than to explore new directions. There’s a million ways to achieve the same thing - a framework should select maybe 10 of those and put them together in a way that works and makes sense.

I think Yii does that, and hope to see Yii 2.0 continue in that vein - refining the existing set of concepts, which have been proven to work, so we can enjoy a productive workflow, writing code that is a joy to write, maintain and share! :slight_smile:

Very well said. It’s easy to get caught up in ‘how’ and forget about ‘why’. One of the real beauties of Yii is how streamlined it is currently and how focused on it’s specific capabilities without all the extra overhead that so many frameworks come with.

It’s really easy to be clever - it’s really hard turn that cleverness into simplicity.

‘simple’ meaning ‘elegant’ rather than ‘limited’ - like in ‘intuitive’.

Yii really has a lot of that quality already. :)

Yii is very good and efficient but it is getting really big.

What I like to see if Yii can have two distributions:

  • MINIMUM: just the core that MUST have for anyone that want to use Yii framework (note: In my mind, I consider Zii as enhancement on Yii framework not the core requirement)

  • FULL: fully loaded with the WORK! demo, docs, etc.

Is that doable?

What do you think?



Yes, it’s doable but it’s still not clear what should be a package and what should be core.

You would know better which is required for a core MINIMUM but in my mind for example:

. CACHE: the "dummy cache" in only required for the framework to run, any other cache is extra and only need to be install when their system support it

. DB support: SQLite is only require for the frame work run anything else can be optional where some system might have support for Mysql, MSSQL, etc

. MODULE: Zii where the frame can do the same just a little more coding so if people don’t care for the extra they might not want Zii


Plus if there is a way to have those optional package that easily download and add in to their site that would make Yii must more flexible to fit in any situation that people need a framework for.


Initially I thought nearly the same but there’s a problem with too many core packages. It will make things complex.

It could be complex but consider the choice between becoming "bloat" framework or "lean and flexible and extensible" framework.


Is the size of the code base your only concern? Please define what is "bloated" and what is the con of it.

Size is just one factor!

“bloated” to me meaning has the extra stuff that most people don’t need or use or system would not have them and just carry around for no reason. Especially on share host that does not allow ssh and using file manager or ftp to transfer files and worst of all some host has certain upload limit on size and number of total files and it stops the upload in the middle.

Yii is exceeding that limit and people just can’t upload Yii to those hosts thus can’t be used on those cases.

By all these, you are still talking about size, and I don’t buy that. For most shared hosting, a few MB extra files shouldn’t be a problem at all (if it is, then you should seek another hosting, or simply Yii is not for you.) There are also many ways to work around the uploading size limit problem (anyway, what if you want to upload a big image whose size is probably more than Yii?)

“bloated” to me meaning has the extra stuff that most people don’t need or use or system would not have them and just carry around for no reason

So here is my attempt to clarify the above statement on "bloated"

I didn’t want to repeat what I said before regarding “bloated” on features like: cache for various type where per the doc if there is no cache in place it will fall back to the default which is the “dummy cache” which is great, like the database many people don’t have mysql or Oracle or Postgres, MSSQL, etc so why carry those around. Every system that run php already has SQLite which Yii already default to SQLite which is great.

There are others like Zii which is nice but if one decide not to use Zii then it is "bloated" and the like.

If there is a way to download the piece that you need then the initial Yii won’t need to be that big and it only get add on features that the person decide to use then no “bloated”

PS: I just check compress size of Yii 1.18 is around 4 MB but uncompress is 15.8 MB on disk.


Who give a flying fart about size anymore? ;)

Gigs are cheap these days.

And we’re moving on to terra-bytes.

No. :)

Primary concerns should be speed, memory usage and flexibility.

I understand you want to keep the framework as lean as possible, and ideally, want the framework to only contain what are actually used in an application. There’s no need to repeat it. My question is: why do you want this? To my understanding, your reason is about the size problem. As we know, the unused files do not affect the performance or flexibility of the framework. Are you ever worried about unused applications that come with your OS and trying to get rid of them? I bet not unless the disk size becomes a real problem.

[font=arial, verdana, tahoma, sans-serif][size=2]

Deleting unnecessary directories (framework/caching, framework/zii, etc.) from your project takes a few seconds.

Implementing a fine-grained packaging system with dependency tracking takes a few months (I think, never done it myself).[/size][/font]

Also, if you run into problems with uploading 16 MB then it’s time to switch hosting provider. It’s likely that there will be other problems with that service.

I did that with Windows XP stripping it down to 200Mb. Worked but with all sort of problems :)

The fact is this framework size “problem” is more psychological one. I’ve heard it many many times that Yii is bloated but never heard about real problem it causes except maybe 10 extra minutes to upload it. People are tend to choose less-sized products because… well, it just feels better. So in the end, I think, solving this size “problem” worth looking at just because of that.

Couldn’t yii be distributed and used as a compressed .phar file?

"The Phar extension is built into PHP as of PHP version 5.3.0"

–> only one single file to deal with.

zlib and bzip2 extensions are not enabled by default, but I guess most providers have them enabled?

–> Reduce file size back to 4MB (I guess, didn’t test it)

Well, compare to other framework Yii is still smaller!

Thank you all for taking the time to respond.