Past, Present, and Future: The Evolution of PHP Development

10 years after the dawn of MVC frameworks in the PHP ecosystem, the community is now evolving away from monolithic frameworks, and towards a composition of decoupled components. This talk explores the early evolution of PHP frameworks, to the "2nd generation" of frameworks, to the migration toward components and beyond.

Transcript

1. Past, Present, and Future The Evolution of PHP Development November 15th — Kyiv, Ukraine Nate Abele Radify, Inc @nateabele nate@radify.io
2. The Vanity Slide • Former lead developer, CakePHP • Founder, Li3 (a.k.a. Lithium) • Member, AngularUI team • Lead Developer, AngularUI Router • Architect-in-Chief, Radify • Highly opinionated, sometimes right • @nateabele / nate@radify.io
3. Consulting · Training · Development http://radify.io
4. “It’s difficult to make predictions, especially about the future.” — Niels Bohr
5. “Americans have no past and no future. They live in an extended present.” — Alexis de Tocqueville
6. “Americans have no past and no future. They live in an extended present.” — Alexis de Tocqueville Programmers
7. Why study the past?
8. 2000 — 2004 • Smarty • PEAR • Web Application Component Toolkit
9. 2005 — 2008 • CakePHP • …etc.
10. 2009 — 2012 • Li3 (Lithium) • Symfony 2 / Symfony Components • Composer / Packagist
11. 2011 — 2013 • AngularJS • EmberJS • BackboneJS • etc.
12. 2013 — 2014 • HackLang • ReactPHP / Ratchet
13. Trends • Real-time • Mobile • Apps: mobile + web + desktop • More all the things
14. Back to basics
15. Back to basics • What makes PHP great? • How do we do our jobs?
16. PHP • Simple, get moving quickly • Large community / talent pool • Mature, good resources • Many high-quality tools
17. Our Jobs http://blog.ircmaxell.com/search/label/Beyond
18. Our Jobs Data Data Data Data Data UI UI UI UI UI
19. Our Jobs Data Data Data Data Data UI UI UI UI UI PHP
20. Our Jobs Data Data Data Data Data UI UI UI UI UI PHP
21. Our Jobs Data Data Data Data Data UI UI UI UI UI PHP
22. Architecture vs. Engineering
23. How should we code? • One part of one problem
24. How should we code? • One part of one problem • Composable • Clean boundaries
25. https://destroyallsoftware.com/talks/boundaries
26. Frameworks?
27. https://www.youtube.com/watch?v=WpkDN78P884
28. • Libraries • Design conventions Frameworks?
29. • Libraries • Design conventions Frameworks?
30. Where to go from here? • Better tools for working efficiently with large datasets • Better tools for designing hypermedia systems • Functional programming concepts
31. Thanks! • nate@radify.io • @nateabele
32. Bonus
33. Programming is not math!?!?
34. x2 + 10x = 39 vs. http://worrydream.com/MediaForThinkingTheUnthinkable/ Programming is not math!?!?
35. “Language is a user interface for ideas.”
36. Writing unit tests sucks
37. Set Theory: Domains { Set } => f(x) => { Domain }
38. Set Theory: Domains { Internet } => OpenSSL(x) => { … … }
39. Set Theory: Domains { Internet } => Bash(x) => { … … }
40. Thanks! • nate@radify.io • @nateabele