I don’t think the size of the framework is a problem. Hopefully, as the Yii community continues to grow, more hosting providers will have ‘preloaded’ yii core framework installations which would help for those with limited server access or slow FTP connections. But it’s something you deal with once per server and then you have everything you might need to access without making the framework less friendly/appealing to people who use some of those less common technology stacks.
I could (not) care less how big the core of the framework is since it loads stuff on-demand and as needed.
Storage space and server speed are commodity items these days!
Bloated, in framework terms, to me means a framework that tries to support every imaginable pattern and concept by providing loads and loads of independent abstractions. Zend Framework is a good example.
To me, that’s worse than anything - in my experience, it’s usually better to provide a low number of carefully selected concepts and patterns that are proven to integrate well. This makes for a lighter framework, fewer difficult choices, easier integration of various components and thus more productivity.
Most patterns essentially solve the same problems in different ways. Of course, some patterns are better suited for certain tasks, but, the art (to me) is not in mastering all possible patterns, but in selecting the right ones and integrating them with as little friction as possible.
That’s the main reason why Yii works for me 
technically you only need yiilite.php if all you want is the basic framework
which is about 272kb file and it will do all the basic stuff. only thing
is you can’t use any nice features like zii,widgets etc
I think main benefit of using yiilite is peformance as you can put
the compiled code in memcache, another benefit is you only need to encrypt
one file if your using zend_guard and distributing this to your clients.
Wow, I can’t believe anyone thinks the Yii framework is heavy.
Really there are better things to spend developer resources on than reducing the byte count of an already slim framework for an edge case. These people can trim what they need.
Primary task is focus on users who use this framework,easy to use for everyone and understandable.
And yii is good standing in easy to use philosophy
+1
I don’t care if it takes 10MB ,40MB or 150MB from my disk space as long as it’s fast and easy to customize. Using autoloading, caching and smart class design is a way to go. Futures I don’t use? I don’t care as long as they don’t slow down my application. Modularity will increase fragmentation and maintenance time. At the moment I host multiple Yii webapps and they all use single yii framework installation. When new yii version comes out, I install it on test server, run unit tests from all my apps against the new yii version and if everything is ok, then I simply move it to production server. With modules, I would have to remember which apps use which modules and install them explicitly. I see room for packages/modules only as a method of distribute 3rd party extensions.
As I understand it, library is a piece of code which helps you to complete a single, particular task. Toolkit, is just a set of libraries helping you complete different, usually related tasks. Framework and the other side is a complete, working application with an empty spaces developer can fill. Therefore frameworks have to be bigger in size and have to contain more futures then simple library. No one can expect framework to be similar in size to some validation library. It’s almost impossible to create a complete framework with AR support smaller then set of AR drivers and classes.
Frameworks are so cool because they provide almost everything in one place, coded in similar way, using similar API, sharing the same documentation, etc.
TBH I’ve never said anything about future of Yii, because decisions made by key developers have always fit my needs perfectly. I say, keep it fast, keep it flexible, keep it easy to maintain.
I don’t see any problems with size of framework its self.
Im waiting from Yii2 in general more “manageability” if you whan’t 200kb website you should simply make it, i see its usage in embed systems, mobile, etc where you have TIGHT resources. If you say i never\won’t develop such thing doesn’t mean any one else won’t.
Yes you need to fight complexity not because its only good for development and understanding Yii, but because in final count its webapp that benefit. All project is targeted on benefiting for using it in custom projects don’t forget that.
Yes and possibility to MANAGE them and understand on level for best usage and it shroud be as low as possible. Best example what i can think of is CRUD, when you use scaffolding i can imagine(speculate) 90% who uses it don’t even realize that the use it and abusively doesn’t understand how its work inside and its very good, yii should be totally like that.
Less understand inside complexity to get maximum for application.
About management of application(now its just web but where its going now-one knows), how hard understand that any framework its like habit, bad or good depends how correctly its used. In current version of yii supports statically already lots of protocols that mainly targeted for medium webapp. E.g
by design its forces hard limitations like you cant build any other application than MVC. but if i need MVP instead or MVVP. Or even something very custom that was build over yii like two years ago. By now its not even possible in terms of time\effort\price.
Inside complexity of framework shroud start above any templates. when you know main templates its not very hard to determinate what to use in particular case. And if main-stream patterns count less then 20 its possible to create some-kind of bases for them and use any of them in needed situation when it best fits (and in any combination).
Conclusion: my concern is manageability.
Modern web frame work should consist of less coupled brick’s N levels where first is root-class-yii-base no doubt about it, every second level bricks(or call it layers) must expand functionality or narrow it from last level as needed. Not hard understand concept that you don’t need very time MVC, some times you just need Urlhandling and Sqlite meaby some ViewRenderEngine for compectability but its just URL->VIEW, its like mvc without M and C. But some projects must have Multilanguage-Url-Handling, Mysql(or Oracle,or MSSQL,Or able use any CRAZY NOSQL system),XML,AJAX, and mobile-version of it and Yii in this case Yii2.0 will provide such functionality will be great success. And i personalty support main theme of yii frame work should be lightweight and unbelievably fast. For that i like to add that applications on it must be fast to, so need to provide some performance instruments or include in standard using ther-party software.
is two posts in row is bad manner?
It’s about different layers:
layer-0 : php
layer-1 : glue - a glue framework - framework of “frameworks”, through adapters to take different frameworks in.(it’s thin, slim)
layer-2 : stack - core and components as one of the “frameworks” mentioned in layer-1(E.G Yii compnents is a stack, Zend is another stack)(which implements some functionities and patterns, like httpClient, SOAP, …could be use independently, They have their interface respectly) to be adapted in (glue together by layer-1), you can mix zend framework,PEAR… etc. in. in this layer, component design with loose coupling in mind.(it’s weighted, full stack, or you say bloated but that’s your repository - your armory, your strong backup, so big, is good)
layer-4 : application infrastructure - Hooks, Observers, A Set Of specific communication protocols between different parts. in this layer, relations between objects design with tight coupling in mind to facilitate quick coding(but object in relationship should be replaceable)(loose coupling pattern generally not so handy in coding) .
layer-5 : cms base - introduce js css module package all high level funtionity to provide a good base to quick development
====================
Every layer is built on lower level and replaceable with multiple candidates.
This is my concept of a framework, may not yii fitted.
You can define more layers also, it’s just a rough design.
Seen some complex patterns that were easier to understand than some of simple to intermediate complexity, simply because the approach to solving the problem of the pattern was easy to relate to something else.
Yii is not bloated, but it might be nice to optionally control the installation of package options (class files) based on user preferences. I mean, it might not make sense to some to install selected package files if they are never going to be used. Then again, a user might change his mind after the framework is installed and want support for package options not installed earlier.
A localhost-based installer with integrated ftp support might make sense and be a realistic solution to this problem. Then the existing distribution can remain on localhost, and a subset of core files, packages, and package options can be installed remotely and recorded locally. Once framework dependencies and file versions are mapped, your installer can make the initial installation based on user choices, handle the installation and removal of packages and handle upgrades to framework files on an individual file (i.e., individual files based on version number) or upgrade package basis.