No content

Full stack frameworks are too hard for beginners Micro frameworks don’t provide enough to work with Kohana being discontinued Too much boilerplate code Questionable design choices in some frameworks Mastering a framework requires a lot of experience

Easy to both learn and master High performance ( more on that later ) Fully unit tested Component based ( use only what you need ) Dependency injection No static class members Perfect for small to medium projects

Query builder ORM Validation Authorization and authentication PHP and HAML templating Cache Database Migrations Image manipulation …and more, out of the box Components can be used outside PHPixie

http://www.techempower.com/benchmarks/#section=data-r9&hw=ec2&test=json&l=sg

Flexible configuration component MongoDB support, with automatic query optimization Relationships between objects in separate databases… …but still using subqueries wherever possible 100% code coverage ( some components already covered ) Full PSR compliance Separate Domain layer Console API for CLI tasks Switch from service location to full constructor injection

Simplicity is prerequisite for reliability. - Edsger Dijkstra

Instance members Static members Object instantiation B class A class

Right tool for the wrong job

Good ones: User interfaces HTTP Requests Real-time updates A new USB device is found Currently in PHP world: ORM model is being saved A user has logged in Content filtering Indirect method call

Events come from outside the system ( user click, API request ) Application only processes events, but does not trigger them Unpredictable by nature Have clearly defined subscribers

Are triggered by the application Easily predictable Anything can subscribe to anything Subscription may occur in the most unexpected places

Non-linear execution flow Possibility of an infinite loop Hard to debug ( event hell ) Should be refactored by injecting dependencies … … but the process requires a lot of rewriting Once introduced quickly invade all parts of the system Observers are a common source of memory leaks

Some things don’t need simplification

Requires lookup of service identifiers Decouples DI from implementation Multiple formats may hurt consistency Doesn’t solve injection into non-service classes

Automatic… …at first Requires another dependency Reliance on string identifiers

Straightforward Transparent Easy to understand Easy to debug Easy to layer Verbose Why simplify this?

Heavy use of chaining, shift towards domain languages All components support multiple configuration profiles V3 components avoid container awareness Distinctly separated layers ( V3 ORM is a good example ) Tests follow class inheritance tree

http://phpixie.com http://github.com/dracony http://github.com/phpixie