14 ms·

Modern PHP without a framework

221 points by vanilla-almond 9y ago

colecut 9y ago
wow, PHP is on the front page, and it's positive We have come a long way!
lai 9y ago
What the.. PHP has a built-in server now?
- megous 9y ago
  For quite some time already and not to be used in production.
- Akujin 9y ago
  It's not multithreaded so it's impossible to use in production.
  - duskwuff 9y ago
    It's not meant for use in production. It's a lighter-weight substitute for a full Apache stack on development systems.
    - Akujin 9y ago
      Prime example of why I don't comment anymore on most things. I wasn't saying you should use it in production. Like at all. In no way shape or fucking form. But no you just assumed I did and decided to correct me. Like no dude. I'm explaining why you should not use it in production. FML the internet is trash and so are the people on it.
- nostalgeek 9y ago
  Yes, but AFAIK it is not multi-threaded so it's not fit for production, at all. It's good for development and testing.
- thawkins 9y ago
  And a built in debugger.
- tylerjwilk00 9y ago
  Yes. Since 6 years ago with release of 5.4 in 2012.
pan69 9y ago
One of the great developments in the PHP eco-system is the use of components and the inter-op standards developed around them [1]. For many years now, "frameworks" such as Symfony and Zend have been mainly been a set of components with an optional thin framework layer. So, not frameworks in the traditional sense. For those interested, another great resource is "Create your own framework on top of the Symfony Components": https://symfony.com/blog/create-your-own-framework-on-top-of-the-symfony-components https://symfony.com/blog/create-your-own-framework-on-top-of... [1] https://www.php-fig.org/ https://www.php-fig.org/
- oaiey 9y ago
  As a former php dev (15 years ago), it fills my heart with joy every time I see PHP-FIG and composer related innovation. They are the best things which could have happened to PHP.
  - COil 9y ago
    Yes, clearly composer was a huge step for PHP, there is a before and after composer.
megous 9y ago
Anyway, if this is how people use PHP these days, why not just use Java? I guess deployment is different (PHP is not compiled), but code/concepts seem pretty much the same at this point if you want to use this style of programming.
- tyingq 9y ago
  Dynamic types, and less verbose. Which, I agree, can be downsides as well.
  - megous 9y ago
    Is it really less verbose for OOP programming than Java, if you're using type annotations, etc.?
    - tyingq 9y ago
      Java is still burdened with a lot of this.that.this.that.whatever(something) I don't know that I've ever encountered something like: RequestProcessorFactoryFactory.RequestProcessorFactory.getRequestProcessor(XmlRpcRequest) In any other language. And that's not the most egregious example. It's quite common.
      - cutler 9y ago
        Have a look at Zend's SDK. It's full of such nonsense. Symfony also tries very hard to look like Java, complete with verbose naming and files paths.
        tyingq 9y ago
        Maybe. I avoid stuff like that. See https://www.slimframework.com https://www.slimframework.com for example.
      - davidjnelson 9y ago
        Seems more like a dig on inheritance and the resultant code than java as a language.
tyingq 9y ago
Good article, and hopefully contrasts today's php with yesterday's php. To me, it's no worse than any other dynamically typed language now. And arguably better than similar peers because the barrier to entry is so low. FastCGI and user space caching like apcu mitigate the old "one process per request" complaint. It's a true workhorse. Sure, node.js and Golang have advantages, but so does modern php.
- qudat 9y ago
  What would you say are the advantages to php over node, python, or golang?
  - tyingq 9y ago
    Mostly quicker out of the box prototyping. That scales to a reasonable degree. To me, there's a threshold where the others take over. What many people miss is that very few projects ever cross that threshold. Kind of like a table saw vs a CAD router.
    - NightlyDev 9y ago
      What do you mean by "scales to a reasonable degree"? How does others take over?
      - tyingq 9y ago
        FastCGI vs, for example, node.js and their pretty nice async model where the engine is warm for every request. With php, I have to do stuff like caching responses with apcu to get something similar, but inferior. Which doesn't scale beyond a single server host. I can serve a lot of requests with apcu, but the curve does drop off at some point.
        andrewmackrodt 9y ago
        Have you tried a node/express like PHP framework such as amp/aerys?
foxfired 9y ago
3 years ago, I made a (not so successful) youtube series of building a website from scratch using php[1]. I'd basically record myself coding for 1h then add a voice over it as I speed up the video 3x. Although my English falls apart fairly quickly, (if you ignore that) it is a good way to see the entire process of building a framework and understanding what each part does. A lot of the things in this article are covered there, with a little bit of the why. [1]: https://www.youtube.com/watch?v=0sYFo92sFLs&index=2&list=PLrAi51U4eF_GdbhoQNqXkDlru4C0p5f1D https://www.youtube.com/watch?v=0sYFo92sFLs&index=2&list=PLr...
- flanbiscuit 9y ago
  I wanted to improve my PHP skills so I researched and taught myself how to build a PHP framework myself, without composer or any third party libraries. This was a while ago so it was for PHP5 and I used CodeIgnitor and CakePHP as my inspirations because that was what was chosen in the previous places I had worked at so I was familiar with them. I enjoyed the process and I learned a lot. I encourage people to build their own framework without composer as a learning experience if they're looking to level up their PHP knowledge. I plan on going through it again from scratch but following modern standards: PHP7, PHP-FIG, strict_types
dvt 9y ago
I haven't used PHP for almost a decade, but I agree with the sentiment of this article. I built a web app back in 2009 in PHP and didn't use Code Igniter or Zend (basically the only two frameworks back then), opting to do it all by hand. And it ended up being a really valuable and formative experience. No matter what language I use, I understand how a web application really "fits together" under the hood and I think there's value there. As a side-note, compared to Node.js or Rust or what-have-you, PHP just seems needlessly verbose.
- deleted 9y ago
  [deleted]
- halfjoking 9y ago
  I'm someone who uses a custom framework at work, and it's not verbose at all. Maybe I'm doing it wrong? I just spl_autoload_register on a controllers directory. Then based on the url, it creates a class for the first part of the url and passes in the rest... $class = new $class_name(); $class->index($url_parts); That class always extends an output class which uses a template system to render a component. I also use an ORM with a models folder that has a bunch of static functions to get data in each model class. I would love to hear from someone more knowledgable about the disadvantages of my approach or why this articles is a better way of doing it. Of course I use composer and use a bunch of libraries for aws, oauth, Google APIs... but for the actual framework I keep it simple and haven't had problems so far.
  - dvt 9y ago
    > I'm someone who uses a custom framework at work, and it's not verbose at all. Maybe I'm doing it wrong? Probably, not, it was just my sentiment by looking over the code in the article :) I haven't used PHP for almost 10 years, so I have no inkling of what "modern" PHP looks like.
    - fein 9y ago
      Symfony 4 looks and feels like a slightly odd java Spring setup. Annotations are ugly as hell in PHP but thats a result of not having annotations supported in the language itself (you need an annotations preprocessor and they're all in comment blocks). There is an rfc for annotations in php as a language feature, so maybe someday. When that happens, Symfony may as well be Spring for PHP.
gremlinsinc 9y ago
I'll go against the flow and say hell no!... I've been part of teams that pride themselves on using propel + klein to build an app in a non-framework. If you want a light framework just go with lumen, flask, sinatra. Ymmv. All new devs wasted a lot of hours learning propel and klein and it didn't always do what they wanted/needed, and the code wasn't the prettiest, where as most knew laravel, and longed for the comfort/sanity of coding in laravel. Sure, for a hobby project/side project this is a good practice to become a better dev, and understand how a mvc framework is built, but for a large code/team it's best to go with something established so new devs hit the ground running without having to learn a ton of stuff. It's easier to find a 'laravel dev', than it is to find a 'custom built mvc dev with extensive experience in x, y, z packages'.
- wvenable 9y ago
  I've worked in countless languages and used plenty of frameworks (and done a ton of PHP development) but I really don't understand Laravel. You have to do a big dance of putting files in all right places and implementing all the right interfaces -- as you would with any framework -- but Laravel doesn't seem to give you anything for your trouble. Take, as one example, validation -- you still have to write virtually everything yourself! There are some very basic hooks and some wire but that's all. For all the trouble, I expect more actual features from my framework.
  - _s 9y ago
    The opinionated flavour makes a lot more sense in a large team - I can pickup a Laravel App, and if it has followed convention, run composer install and be productive within a matter of minutes.
    - NightlyDev 9y ago
      Tbh, a developer should be able to do the same thing if PSRs are used for the project.
  - NightlyDev 9y ago
    You don't have to do everything yourself, most things are abstracted and easily accessible. It's a framework, it's job is to make it easy to structure the site and handle common tasks for you. Laravel does have validation built in. You might have to put custom rules to use every now or then, but I don't see a way around that. But laravel sure has its cost when it comes to performance - it's not possible to have it both ways.
tannhaeuser 9y ago
Was hoping for a built-in mechanism for HTML-aware, injection-free templating given PHP is invoked via an SGML processing instruction from otherwise static HTML. Instead what's shown is massive Java-ish meta boilerplate for trivial HTTP request/response abstractions.
- tyingq 9y ago
  See something like https://www.slimframework.com https://www.slimframework.com or https://lumen.laravel.com https://lumen.laravel.com
- liveoneggs 9y ago
  welcome to New\PHP where looking like java is the goal
- krapp 9y ago
  >Was hoping for a built-in mechanism for HTML-aware, injection-free templating (...) You may be looking for Hack, which supports XHP natively[0]. [0]https://docs.hhvm.com/hack/XHP/introduction https://docs.hhvm.com/hack/XHP/introduction
userbinator 9y ago
I'm seriously not sure if this is satire. It starts off with a simple example, and then goes down a rabbit-hole of massive complexity to ultimately do the same thing. This reminds me of the many OOP articles that were common shortly before the turn of the century, which would take as an example a perfectly straightforward and simple-to-understand piece of code and then bloat it into an asinine multilayered monstrosity by applying a generous amount of "OOP best practices and patterns" while straight-facedly enumerating all the alleged benefits. When you first started with PHP, you may have used includes or requires statements throughout your app to bring in functionality or configuration from other PHP files. In general, we want to avoid that because it makes it much harder for a human to follow the code path and understand where dependencies lie. Autoloading just means that when your application needs to use a class, PHP knows where to look for it and automatically loads it when it's called for. How in $deity's name can you say that specifying immediately the exact path to the file included, in the file that includes it, is "much harder to follow" than hiding it behind the indirection of the autoloader and whatever it does!? Honestly, WTF!? (Maybe the joke here is that everyone is just pretending to admire the emperor's new clothes, in which case I apologise.) Edit: here's an example of the OOP articles I mentioned: https://csis.pace.edu/~bergin/patterns/ppoop.html https://csis.pace.edu/~bergin/patterns/ppoop.html
- reificator 9y ago
  Even if everyone is in on the joke, it's good to have comments like this explaining to newcomers that this is not how things should work. Disclaimer: I've not written much php nor read the article. Just replying to this one comment because the OOP analogy spoke to me.
  - deleted 9y ago
    [deleted]
- slindsey 9y ago
  Thank you. You stated what I was thinking much more clearly than I was able. I strongly prefer explicit code that states clearly what is happening without having to guess.
- 9y ago
godot 9y ago
I started a startup in 2013, and I picked PHP for a core language since I had a decade~ experience with it by then and it was a good enough reason to use it. PHP 7 wasn't available yet and nodejs was only starting to take off and didn't seem like the future yet. Taking learning from previous companies, I've found the main thing PHP was lacking at the time was a good routing mechanism. We obviously don't want to rely on Apache hitting .php files to handle requests. So we used ToroPHP (https://github.com/anandkunal/ToroPHP https://github.com/anandkunal/ToroPHP) for routing, which is a seriously lightweight routing lib. Indeed we used composer and a lot of dependencies, but for our own codebase we used manual includes instead of the autoloader. With the usual PHP production setup like APC with opcode caching enabled and file stat'ing off (later on opcache + APCu), we handled scale extremely well. (mentioning this because a counter-point for manual includes is that many requests would unnecessarily load way too many code files) As far as codebase maintenance and growth go, that PHP codebase was actually very easily manageable even with manual includes. Having routing solved frees you up to organize your code files in any ways you want. Even today, I have a mini-framework structured this way for myself to start side projects and test ideas with. (Yes, using PHP5 for side projects in 2018 ;) My point in bringing all this up is that the architecture this article is trying to take you in, seems unnecessarily complicated for PHP. This past year I've been working in a full nodejs shop and this entire architecture (from this article) reminds me heavily of how a node/express app is structured. Someone else on this thread mentioned modern languages have their architectures converging. This is exactly what's happening. Even as a PHP fan, it makes me feel a bit of "Why use PHP at this point, instead of nodejs/go/python?" while reading this. It feels like if you wanted to go this route, nodejs is a better option on almost all fronts -- language syntax brevity, availability of packages, community, developer-availability. The only reason to use PHP at this point is nostalgia/sticking to PHP syntax.
- treve 9y ago
  As someone who's been doing PHP for nearly 15 years, but 2 years ago switched to Node.js for a job, I agree. This is even more true when switching to Typescript. We introduced typing later in the project and wow what a step up in safety and productivity.
  - 9y ago
rajangdavis 9y ago
Really random question, but if I were to make a REST API wrapper with PHP, is it possible to use cURL and keep it PSR-7 compliant? Been trying to learn more about the Composer/PHP ecosystem and am pretty confused. In contrast, I was able to create and publish packages in Python and Node with relative ease with little to no experience with these languages.
- andrewmackrodt 9y ago
  https://github.com/guzzle/psr7 https://github.com/guzzle/psr7
aussieguy1234 9y ago
For one project, I used slim. It has routing, a simple container and that's about it. I made my own controllers and integrated them in. Super fast, for anything more I used composer packages.
- ramijames 9y ago
  I did a personal side-project in Slim. It's lovely and I map it in my mind to Sinatra as a bare-boned framework for just getting stuff done.
ramijames 9y ago
In my day job, I work on an application based on Drupal 5. It's not necessarily "without a framework", but really it might as well be. It has absolutely made me a better developer because I've had to delve into how the system works more than I ever did with Laravel (or Ruby on Rails, in a previous life). Things don't just work (hell, sometimes they don't work at all) and poking around until I really understand why is a healthy thing for any mid-level dev to do. That being said, I do miss a lot of the modern niceties and it can be really frustrating to work this way. I'm glad for the opportunity, but I would also like to be able to use more modern dev tools in the future.
- stevepurkiss 9y ago
  Drupal 5? Wow! I began my Drupal journey on the 4.6/4.7 'cusp' after working with J2EE & although I like Drupal because I can see the 'bigger picture' of the business logic being infused into the API, i.e. business problems solved = code as opposed to using something like Laravel & creating new untried, untested code all the time, I only really started liking coding with Drupal 8 as it's almost a complete rewrite from procedural to mostly OO. The major problem over the years of fire-fighting various dubious installs of Drupal is people hack core and contrib modules making it impossible to maintain - if you use the APIs, grow modules & extend instead of hacking then it makes life a whole load easier - all I do to update my sites now is 'composer update --with-dependencies' (well, there's a few more lines to update the db if needed, export config from db to code, etc. but it's super-simple). I hope you have applied a patch to protect against the latest security issue found, here's a link to an unofficial patch for 5: https://www.drupal.org/files/issues/2018-03-28/sa-core-2018-002-d5.patch https://www.drupal.org/files/issues/2018-03-28/sa-core-2018-...
throw2016 9y ago
PHP has been in a weird place for nearly a decade now in technical forums like HN where it is mocked endlessly often to signal a superior technical understanding by people who would not deign to use it. As if its the only language with shortcomings. Yet it continued to be used in some of the most scalable and widely used apps of our generation from Wikipedia, Wordpress, Facebook, Slack and more. It often feels other languages marketing teams have preyed on it in many ways to gain attention. And there has been some kind of war against simplicity that places an unearned respect for 'clever' abstractions under the guise of scalability often in pursuit of resume padding, or 'best practices' entryism and gaining influence in projects via package managers and the like.
mnm1 9y ago
For learning, this is great. For actual apps, this is plain stupid. Not to mention that no one has the time to cook up a framework every time one wants to build an app. Or all the rest of the components that are missing here. This whole PHP without a framework--whether it be creating your own framework or using raw PHP--trend seems like it's promoted only by inexperienced devs who don't need to work on real project in real companies in real life. I would literally fire someone if the insisted on doing this for wasting company resources and time unnecessarily.
Falkon1313 9y ago
While it's good in some respects, all this enterprisization is exhausting and can, perversely - counter to its intentions, be a significant drain on productivity. Once upon a time, we were focused on the important things - problem-solving, domain data, and business logic. But now we're almost entirely focused on abstraction, generics, and boilerplate while the important objective-related stuff that pays the bills just gets whatever scraps of time are leftover (if any). We used to spend 90% of our time determining the right nail to use, the right wood to use it on, and where best to place it, and only 10% of our time on selecting and wielding the hammer. Now we spend 90+% of our time figuring out which GenericAbstractToolFactoryManagerFactoryInterface to invoke and how to properly invoke it a in such a way as to coerce it to ultimately generate something that eventually might generate something else that will hopefully drive some sort of fastener into something in such a way that will possibly hold it together, and the rest debugging why instead it is generating a generator that generates chisels that are chopping away at the foundation. Yes, that's an exaggeration, but how much so? We are smart people, we do figure out how to use these complex combinations of systems to build functioning (bloated monstrosities of) applications. But are they really reducing technical debt or adding to it? Are these systems really going to be easier to maintain in a few years when they have 357 dependencies that have each evolved over time (and or been abandoned)? Easier to optimize, when that means modifying what's going on under the hood of those dependencies? Easier to extend, when doing so would lead to conflicts with those dependencies? I'm predicting that the next wave of discovery and hype in the field will be focused on improving productivity while reducing technical debt by removing the cruft that we're building now and replacing it with something simpler and more to-the-point.
- iforgotpassword 9y ago
  In my current job I inherited a 7 years old php project that's marked as legacy and scheduled to be phased out in 2020. Until then its mostly maintenance and adaptions to changes in stuff it interacts with. It's built with php5, uses pretty static file structure, no namespaces but an autoloader. It has around 150 source files. I must say that it was surprisingly easy to get into the code base. The fact that there are no namespaces means class names have been picked carefully, no generic stuff like "dataholder". About half the classes are entirely static and there is still a lot of assoc arrays being passed around while in other places proper classes are used. The front end is just bootstrap with a little bit of additional js and ajax where it makes sense. Still it is really easy navigating the code base and finding the right spot to extend. I hardly ever felt constrained by the project's design, if ever rather by the inconsistencies of php(5) itself. Yes, sometimes it's annoying to implement a dynamic page update via ajax by hand without fancy abstraction, but if you're not building a modern spa it's not that bad and you actually get what's going on. That other java code base I'm involved with is about 4 years old and really modular and fancy and maven and every time something needs to be added a discussion starts on how to do it, which parts to abstract away in which way, which library or framework might be suited best, and after five trillion years coding might actually start. I might have exaggerated a bit here but that's somehow the feeling I have more and more in modern software development.
ubernostrum 9y ago
There's no such thing as web application development "without a framework". There is only a choice between using someone else's framework, and inevitably building your own. If you reject all third-party frameworks, you will end up reinventing a bunch of design patterns from other frameworks. You will end up writing your own libraries to do the things the framework would have done. And you will -- no matter how good or fast it feels to you -- end up spending more time in the writing and maintenance of your private "non-framework" than you would have spent in deploying an existing one off-the-shelf.
- patricklouys 9y ago
  That's not true. I've worked on large applications with frameworks (CodeIgniter, Symfony) and without frameworks (but with composer packages). In the beginning you might spend a little more time on wiring things together, but on a large enough application your framework will always get in the way somehow and you will have to find workarounds. For large projects, I strongly prefer a frameworkless approach. If you do throwaway apps for an agency, then a framework is probably the better choice.
  - ubernostrum 9y ago
    You chose a set of libraries. You installed them. You used them. And by "used them", I mean you wrote code which called into them and which wired together all the various pieces to make a coherent web application. I know you did this, because if the libraries had come with a magical "make all these things work together" function for you to use instead, you would have dismissed that as a framework. You don't want to call that combination of libraries and in-house wiring-together code a framework. I get that. But that's what it is, whether you want to call it that or not. And I'm sure that you don't see it as a maintenance burden right now. It never feels like a framework or a burden at first, because it's all made up of this code that you wrote and that you understand and that you control, and it feels great! For a while, at least. But sooner or later you will realize you have built your own in-house web framework, and that now part of your business is to be a web-framework developer, instead of a whatever-your-company-actually-needed-to-make developer, and that being a web-framework developer is not a very fun business to be in. And you will hire more people, and they will have to be trained on this thing-you-refuse-to-call-a-framework, but they'll recognize the patterns sooner or later, and will wonder out loud why it's missing this or that feature that the off-the-shelf frameworks have out of the box, or why this particular part of its API is so weird and cumbersome (it made sense back when the codebase was much smaller and only a couple people worked on it, you'll tell them, sheepishly). And maybe some of them will roll up their sleeves and try to add what's missing or clean up the historical weirdness, and maybe some of them will get tired of working on this thing that won't add to their résumé and leave, and others will just do their best to get work done, but at a much slower pace because they're working with a framework built by people who hate frameworks, and still others will start to agitate for just going and getting a proper framework off the shelf and using it already, and you will end up having some very interesting and perhaps very heated team meetings, and you'll realize that you're spending way too much time as a team talking about tools and technologies and not nearly enough talking about products and bugs and features and this is not going as well as it was back when everything seemed so simple and easy in the world of "frameworkless" development. This is the iron-bound web developer's counterpart to Greenspun's Tenth Rule, and in my experience there is no escaping it.
patricklouys 9y ago
I like to use the same approach, I even wrote a tutorial [0] and a book [1] about it. That being said, I am still forced to use Symfony at my current job. It only gets in the way sometimes, it's not too bad. On my previous job we went from CodeIgniter to frameworkless and I really liked that. Not having framework constraints working against you was really enjoyable to work with. [0] https://github.com/PatrickLouys/no-framework-tutorial https://github.com/PatrickLouys/no-framework-tutorial [1] https://patricklouys.com/professional-php/ https://patricklouys.com/professional-php/
- jwdunne 9y ago
  I recently gave Sylius, based on Symfony, a spin. I wanted to add a field to a product, editable in the admin area. The additional code and the extensions were ok. Some of the config changes are understandable but I thought it a bit much when the number of additions to configuration outstripped the amount of code required.
  - patricklouys 9y ago
    I feel your pain. That's my biggest gripe with Symfony. Sometimes it feels like I am spending more time configuring that programming.
    - cutler 9y ago
      Rewind to 2005. Isn't this why Rails was born?
      - jwdunne 9y ago
        Funnily enough, I chose a Rails e-commerce solution, Solidus. I added the same feature, 0 configuration, similar if not less code required. Unfortunately I'm the only one who knows Ruby but I have every faith that my colleagues can pick it up.
rgomez 9y ago
Wait, this is far from vanilla PHP, is this not gloryfing "Composer" as the new meta-framework?
- sbarre 9y ago
  Only if you consider gem and npm to also be frameworks. Or by further abstraction, Github.
  - rgomez 9y ago
    Well, if a project depend on them to actually work, yes, kind of, I consider them frameworks.
andybak 9y ago
Curious about the use of Dependency Injection here. I'm a Python guy and it rarely gets mentioned in my world as far as I'm aware. I always assumed it was mostly an artefact of static type systems. Can anyone share their insight? Either in the context of Python or PHP.
- RhodesianHunter 9y ago
  How well are your codebases unit tested? I shiver thinking about trying to add good tests to a project in any language without good di/ioc.
  - bramblerose 9y ago
    The dynamicness of languages like Python make it relatively easy to do so. For example, it's difficult in Java to mock an http request if you can't inject a `HttpRequestor` (or so) to the object you're testing. In Python, it is common practice to patch objects, which means that even though the code calls `requests.get()`, the call will actually be patched through to a mock. (in the Java world, this is possible with e.g. PowerMock, but generally frowned upon)
troels 9y ago
> So there you have it. With just 44 lines and the help of several widely-used, thoroughly-tested, reliably interoperable components, we have the bootstrap for a modern PHP application. Uhm .. so ... a framework?
- paulddraper 9y ago
  A microframework, at least. Hardly close the complexity/features of CakePHP or others.
- rocketpastsix 9y ago
  No, just components that handle certain things.
fulldecent 9y ago
I read this article and found it to be a great example of why we should NOT adopt modern PHP techniques at our company. 50 lines of code and contrived examples (is HelloWorld class a view or controller? AwesomeClass is a model?) get one line of HTML emitted in a barely readable way. This article fails to motivate why each layer of complexity is added. It basically starts with the assumption that you want to use a framework and says "hey look you can do the same thing with 50 lines of boilerplate, not really, but kind of." I would be much more impressed with an article that starts with the obvious way to write a PHP application (.htaccess, index.php, products.php, library/database.php, library/*.php) and then explains the actual problems that would make you want to opt for more complexity/organization/modern techniques.

colecut 9y ago

wow, PHP is on the front page, and it's positive We have come a long way!

lai 9y ago

What the.. PHP has a built-in server now?

megous 9y ago
For quite some time already and not to be used in production.
Akujin 9y ago
It's not multithreaded so it's impossible to use in production.
- duskwuff 9y ago
  It's not meant for use in production. It's a lighter-weight substitute for a full Apache stack on development systems.
  - Akujin 9y ago
    Prime example of why I don't comment anymore on most things. I wasn't saying you should use it in production. Like at all. In no way shape or fucking form. But no you just assumed I did and decided to correct me. Like no dude. I'm explaining why you should not use it in production. FML the internet is trash and so are the people on it.
nostalgeek 9y ago
Yes, but AFAIK it is not multi-threaded so it's not fit for production, at all. It's good for development and testing.
thawkins 9y ago
And a built in debugger.
tylerjwilk00 9y ago
Yes. Since 6 years ago with release of 5.4 in 2012.

pan69 9y ago

One of the great developments in the PHP eco-system is the use of components and the inter-op standards developed around them [1]. For many years now, "frameworks" such as Symfony and Zend have been mainly been a set of components with an optional thin framework layer. So, not frameworks in the traditional sense. For those interested, another great resource is "Create your own framework on top of the Symfony Components": https://symfony.com/blog/create-your-own-framework-on-top-of-the-symfony-components https://symfony.com/blog/create-your-own-framework-on-top-of... [1] https://www.php-fig.org/ https://www.php-fig.org/

oaiey 9y ago
As a former php dev (15 years ago), it fills my heart with joy every time I see PHP-FIG and composer related innovation. They are the best things which could have happened to PHP.
- COil 9y ago
  Yes, clearly composer was a huge step for PHP, there is a before and after composer.

megous 9y ago

Anyway, if this is how people use PHP these days, why not just use Java? I guess deployment is different (PHP is not compiled), but code/concepts seem pretty much the same at this point if you want to use this style of programming.

tyingq 9y ago
Dynamic types, and less verbose. Which, I agree, can be downsides as well.
- megous 9y ago
  Is it really less verbose for OOP programming than Java, if you're using type annotations, etc.?
  - tyingq 9y ago
    Java is still burdened with a lot of this.that.this.that.whatever(something) I don't know that I've ever encountered something like: RequestProcessorFactoryFactory.RequestProcessorFactory.getRequestProcessor(XmlRpcRequest) In any other language. And that's not the most egregious example. It's quite common.
    - cutler 9y ago
      Have a look at Zend's SDK. It's full of such nonsense. Symfony also tries very hard to look like Java, complete with verbose naming and files paths.
      - tyingq 9y ago
        Maybe. I avoid stuff like that. See https://www.slimframework.com https://www.slimframework.com for example.
    - davidjnelson 9y ago
      Seems more like a dig on inheritance and the resultant code than java as a language.

tyingq 9y ago

Good article, and hopefully contrasts today's php with yesterday's php. To me, it's no worse than any other dynamically typed language now. And arguably better than similar peers because the barrier to entry is so low. FastCGI and user space caching like apcu mitigate the old "one process per request" complaint. It's a true workhorse. Sure, node.js and Golang have advantages, but so does modern php.

qudat 9y ago
What would you say are the advantages to php over node, python, or golang?
- tyingq 9y ago
  Mostly quicker out of the box prototyping. That scales to a reasonable degree. To me, there's a threshold where the others take over. What many people miss is that very few projects ever cross that threshold. Kind of like a table saw vs a CAD router.
  - NightlyDev 9y ago
    What do you mean by "scales to a reasonable degree"? How does others take over?
    - tyingq 9y ago
      FastCGI vs, for example, node.js and their pretty nice async model where the engine is warm for every request. With php, I have to do stuff like caching responses with apcu to get something similar, but inferior. Which doesn't scale beyond a single server host. I can serve a lot of requests with apcu, but the curve does drop off at some point.
      - andrewmackrodt 9y ago
        Have you tried a node/express like PHP framework such as amp/aerys?

foxfired 9y ago

3 years ago, I made a (not so successful) youtube series of building a website from scratch using php[1]. I'd basically record myself coding for 1h then add a voice over it as I speed up the video 3x. Although my English falls apart fairly quickly, (if you ignore that) it is a good way to see the entire process of building a framework and understanding what each part does. A lot of the things in this article are covered there, with a little bit of the why. [1]: https://www.youtube.com/watch?v=0sYFo92sFLs&index=2&list=PLrAi51U4eF_GdbhoQNqXkDlru4C0p5f1D https://www.youtube.com/watch?v=0sYFo92sFLs&index=2&list=PLr...

flanbiscuit 9y ago
I wanted to improve my PHP skills so I researched and taught myself how to build a PHP framework myself, without composer or any third party libraries. This was a while ago so it was for PHP5 and I used CodeIgnitor and CakePHP as my inspirations because that was what was chosen in the previous places I had worked at so I was familiar with them. I enjoyed the process and I learned a lot. I encourage people to build their own framework without composer as a learning experience if they're looking to level up their PHP knowledge. I plan on going through it again from scratch but following modern standards: PHP7, PHP-FIG, strict_types

dvt 9y ago

I haven't used PHP for almost a decade, but I agree with the sentiment of this article. I built a web app back in 2009 in PHP and didn't use Code Igniter or Zend (basically the only two frameworks back then), opting to do it all by hand. And it ended up being a really valuable and formative experience. No matter what language I use, I understand how a web application really "fits together" under the hood and I think there's value there. As a side-note, compared to Node.js or Rust or what-have-you, PHP just seems needlessly verbose.

deleted 9y ago
[deleted]
halfjoking 9y ago
I'm someone who uses a custom framework at work, and it's not verbose at all. Maybe I'm doing it wrong? I just spl_autoload_register on a controllers directory. Then based on the url, it creates a class for the first part of the url and passes in the rest... $class = new $class_name(); $class->index($url_parts); That class always extends an output class which uses a template system to render a component. I also use an ORM with a models folder that has a bunch of static functions to get data in each model class. I would love to hear from someone more knowledgable about the disadvantages of my approach or why this articles is a better way of doing it. Of course I use composer and use a bunch of libraries for aws, oauth, Google APIs... but for the actual framework I keep it simple and haven't had problems so far.
- dvt 9y ago
  > I'm someone who uses a custom framework at work, and it's not verbose at all. Maybe I'm doing it wrong? Probably, not, it was just my sentiment by looking over the code in the article :) I haven't used PHP for almost 10 years, so I have no inkling of what "modern" PHP looks like.
  - fein 9y ago
    Symfony 4 looks and feels like a slightly odd java Spring setup. Annotations are ugly as hell in PHP but thats a result of not having annotations supported in the language itself (you need an annotations preprocessor and they're all in comment blocks). There is an rfc for annotations in php as a language feature, so maybe someday. When that happens, Symfony may as well be Spring for PHP.

gremlinsinc 9y ago

I'll go against the flow and say hell no!... I've been part of teams that pride themselves on using propel + klein to build an app in a non-framework. If you want a light framework just go with lumen, flask, sinatra. Ymmv. All new devs wasted a lot of hours learning propel and klein and it didn't always do what they wanted/needed, and the code wasn't the prettiest, where as most knew laravel, and longed for the comfort/sanity of coding in laravel. Sure, for a hobby project/side project this is a good practice to become a better dev, and understand how a mvc framework is built, but for a large code/team it's best to go with something established so new devs hit the ground running without having to learn a ton of stuff. It's easier to find a 'laravel dev', than it is to find a 'custom built mvc dev with extensive experience in x, y, z packages'.

wvenable 9y ago
I've worked in countless languages and used plenty of frameworks (and done a ton of PHP development) but I really don't understand Laravel. You have to do a big dance of putting files in all right places and implementing all the right interfaces -- as you would with any framework -- but Laravel doesn't seem to give you anything for your trouble. Take, as one example, validation -- you still have to write virtually everything yourself! There are some very basic hooks and some wire but that's all. For all the trouble, I expect more actual features from my framework.
- _s 9y ago
  The opinionated flavour makes a lot more sense in a large team - I can pickup a Laravel App, and if it has followed convention, run composer install and be productive within a matter of minutes.
  - NightlyDev 9y ago
    Tbh, a developer should be able to do the same thing if PSRs are used for the project.
- NightlyDev 9y ago
  You don't have to do everything yourself, most things are abstracted and easily accessible. It's a framework, it's job is to make it easy to structure the site and handle common tasks for you. Laravel does have validation built in. You might have to put custom rules to use every now or then, but I don't see a way around that. But laravel sure has its cost when it comes to performance - it's not possible to have it both ways.

tannhaeuser 9y ago

Was hoping for a built-in mechanism for HTML-aware, injection-free templating given PHP is invoked via an SGML processing instruction from otherwise static HTML. Instead what's shown is massive Java-ish meta boilerplate for trivial HTTP request/response abstractions.

tyingq 9y ago
See something like https://www.slimframework.com https://www.slimframework.com or https://lumen.laravel.com https://lumen.laravel.com
liveoneggs 9y ago
welcome to New\PHP where looking like java is the goal
krapp 9y ago
>Was hoping for a built-in mechanism for HTML-aware, injection-free templating (...) You may be looking for Hack, which supports XHP natively[0]. [0]https://docs.hhvm.com/hack/XHP/introduction https://docs.hhvm.com/hack/XHP/introduction

userbinator 9y ago

I'm seriously not sure if this is satire. It starts off with a simple example, and then goes down a rabbit-hole of massive complexity to ultimately do the same thing. This reminds me of the many OOP articles that were common shortly before the turn of the century, which would take as an example a perfectly straightforward and simple-to-understand piece of code and then bloat it into an asinine multilayered monstrosity by applying a generous amount of "OOP best practices and patterns" while straight-facedly enumerating all the alleged benefits. When you first started with PHP, you may have used includes or requires statements throughout your app to bring in functionality or configuration from other PHP files. In general, we want to avoid that because it makes it much harder for a human to follow the code path and understand where dependencies lie. Autoloading just means that when your application needs to use a class, PHP knows where to look for it and automatically loads it when it's called for. How in $deity's name can you say that specifying immediately the exact path to the file included, in the file that includes it, is "much harder to follow" than hiding it behind the indirection of the autoloader and whatever it does!? Honestly, WTF!? (Maybe the joke here is that everyone is just pretending to admire the emperor's new clothes, in which case I apologise.) Edit: here's an example of the OOP articles I mentioned: https://csis.pace.edu/~bergin/patterns/ppoop.html https://csis.pace.edu/~bergin/patterns/ppoop.html

reificator 9y ago
Even if everyone is in on the joke, it's good to have comments like this explaining to newcomers that this is not how things should work. Disclaimer: I've not written much php nor read the article. Just replying to this one comment because the OOP analogy spoke to me.
- deleted 9y ago
  [deleted]
slindsey 9y ago
Thank you. You stated what I was thinking much more clearly than I was able. I strongly prefer explicit code that states clearly what is happening without having to guess.
9y ago

godot 9y ago

I started a startup in 2013, and I picked PHP for a core language since I had a decade~ experience with it by then and it was a good enough reason to use it. PHP 7 wasn't available yet and nodejs was only starting to take off and didn't seem like the future yet. Taking learning from previous companies, I've found the main thing PHP was lacking at the time was a good routing mechanism. We obviously don't want to rely on Apache hitting .php files to handle requests. So we used ToroPHP (https://github.com/anandkunal/ToroPHP https://github.com/anandkunal/ToroPHP) for routing, which is a seriously lightweight routing lib. Indeed we used composer and a lot of dependencies, but for our own codebase we used manual includes instead of the autoloader. With the usual PHP production setup like APC with opcode caching enabled and file stat'ing off (later on opcache + APCu), we handled scale extremely well. (mentioning this because a counter-point for manual includes is that many requests would unnecessarily load way too many code files) As far as codebase maintenance and growth go, that PHP codebase was actually very easily manageable even with manual includes. Having routing solved frees you up to organize your code files in any ways you want. Even today, I have a mini-framework structured this way for myself to start side projects and test ideas with. (Yes, using PHP5 for side projects in 2018 ;) My point in bringing all this up is that the architecture this article is trying to take you in, seems unnecessarily complicated for PHP. This past year I've been working in a full nodejs shop and this entire architecture (from this article) reminds me heavily of how a node/express app is structured. Someone else on this thread mentioned modern languages have their architectures converging. This is exactly what's happening. Even as a PHP fan, it makes me feel a bit of "Why use PHP at this point, instead of nodejs/go/python?" while reading this. It feels like if you wanted to go this route, nodejs is a better option on almost all fronts -- language syntax brevity, availability of packages, community, developer-availability. The only reason to use PHP at this point is nostalgia/sticking to PHP syntax.

treve 9y ago
As someone who's been doing PHP for nearly 15 years, but 2 years ago switched to Node.js for a job, I agree. This is even more true when switching to Typescript. We introduced typing later in the project and wow what a step up in safety and productivity.
- 9y ago

rajangdavis 9y ago

Really random question, but if I were to make a REST API wrapper with PHP, is it possible to use cURL and keep it PSR-7 compliant? Been trying to learn more about the Composer/PHP ecosystem and am pretty confused. In contrast, I was able to create and publish packages in Python and Node with relative ease with little to no experience with these languages.

andrewmackrodt 9y ago
https://github.com/guzzle/psr7 https://github.com/guzzle/psr7

aussieguy1234 9y ago

For one project, I used slim. It has routing, a simple container and that's about it. I made my own controllers and integrated them in. Super fast, for anything more I used composer packages.

ramijames 9y ago
I did a personal side-project in Slim. It's lovely and I map it in my mind to Sinatra as a bare-boned framework for just getting stuff done.

ramijames 9y ago

In my day job, I work on an application based on Drupal 5. It's not necessarily "without a framework", but really it might as well be. It has absolutely made me a better developer because I've had to delve into how the system works more than I ever did with Laravel (or Ruby on Rails, in a previous life). Things don't just work (hell, sometimes they don't work at all) and poking around until I really understand why is a healthy thing for any mid-level dev to do. That being said, I do miss a lot of the modern niceties and it can be really frustrating to work this way. I'm glad for the opportunity, but I would also like to be able to use more modern dev tools in the future.

stevepurkiss 9y ago
Drupal 5? Wow! I began my Drupal journey on the 4.6/4.7 'cusp' after working with J2EE & although I like Drupal because I can see the 'bigger picture' of the business logic being infused into the API, i.e. business problems solved = code as opposed to using something like Laravel & creating new untried, untested code all the time, I only really started liking coding with Drupal 8 as it's almost a complete rewrite from procedural to mostly OO. The major problem over the years of fire-fighting various dubious installs of Drupal is people hack core and contrib modules making it impossible to maintain - if you use the APIs, grow modules & extend instead of hacking then it makes life a whole load easier - all I do to update my sites now is 'composer update --with-dependencies' (well, there's a few more lines to update the db if needed, export config from db to code, etc. but it's super-simple). I hope you have applied a patch to protect against the latest security issue found, here's a link to an unofficial patch for 5: https://www.drupal.org/files/issues/2018-03-28/sa-core-2018-002-d5.patch https://www.drupal.org/files/issues/2018-03-28/sa-core-2018-...

throw2016 9y ago

PHP has been in a weird place for nearly a decade now in technical forums like HN where it is mocked endlessly often to signal a superior technical understanding by people who would not deign to use it. As if its the only language with shortcomings. Yet it continued to be used in some of the most scalable and widely used apps of our generation from Wikipedia, Wordpress, Facebook, Slack and more. It often feels other languages marketing teams have preyed on it in many ways to gain attention. And there has been some kind of war against simplicity that places an unearned respect for 'clever' abstractions under the guise of scalability often in pursuit of resume padding, or 'best practices' entryism and gaining influence in projects via package managers and the like.

mnm1 9y ago

For learning, this is great. For actual apps, this is plain stupid. Not to mention that no one has the time to cook up a framework every time one wants to build an app. Or all the rest of the components that are missing here. This whole PHP without a framework--whether it be creating your own framework or using raw PHP--trend seems like it's promoted only by inexperienced devs who don't need to work on real project in real companies in real life. I would literally fire someone if the insisted on doing this for wasting company resources and time unnecessarily.

Falkon1313 9y ago

While it's good in some respects, all this enterprisization is exhausting and can, perversely - counter to its intentions, be a significant drain on productivity. Once upon a time, we were focused on the important things - problem-solving, domain data, and business logic. But now we're almost entirely focused on abstraction, generics, and boilerplate while the important objective-related stuff that pays the bills just gets whatever scraps of time are leftover (if any). We used to spend 90% of our time determining the right nail to use, the right wood to use it on, and where best to place it, and only 10% of our time on selecting and wielding the hammer. Now we spend 90+% of our time figuring out which GenericAbstractToolFactoryManagerFactoryInterface to invoke and how to properly invoke it a in such a way as to coerce it to ultimately generate something that eventually might generate something else that will hopefully drive some sort of fastener into something in such a way that will possibly hold it together, and the rest debugging why instead it is generating a generator that generates chisels that are chopping away at the foundation. Yes, that's an exaggeration, but how much so? We are smart people, we do figure out how to use these complex combinations of systems to build functioning (bloated monstrosities of) applications. But are they really reducing technical debt or adding to it? Are these systems really going to be easier to maintain in a few years when they have 357 dependencies that have each evolved over time (and or been abandoned)? Easier to optimize, when that means modifying what's going on under the hood of those dependencies? Easier to extend, when doing so would lead to conflicts with those dependencies? I'm predicting that the next wave of discovery and hype in the field will be focused on improving productivity while reducing technical debt by removing the cruft that we're building now and replacing it with something simpler and more to-the-point.

iforgotpassword 9y ago
In my current job I inherited a 7 years old php project that's marked as legacy and scheduled to be phased out in 2020. Until then its mostly maintenance and adaptions to changes in stuff it interacts with. It's built with php5, uses pretty static file structure, no namespaces but an autoloader. It has around 150 source files. I must say that it was surprisingly easy to get into the code base. The fact that there are no namespaces means class names have been picked carefully, no generic stuff like "dataholder". About half the classes are entirely static and there is still a lot of assoc arrays being passed around while in other places proper classes are used. The front end is just bootstrap with a little bit of additional js and ajax where it makes sense. Still it is really easy navigating the code base and finding the right spot to extend. I hardly ever felt constrained by the project's design, if ever rather by the inconsistencies of php(5) itself. Yes, sometimes it's annoying to implement a dynamic page update via ajax by hand without fancy abstraction, but if you're not building a modern spa it's not that bad and you actually get what's going on. That other java code base I'm involved with is about 4 years old and really modular and fancy and maven and every time something needs to be added a discussion starts on how to do it, which parts to abstract away in which way, which library or framework might be suited best, and after five trillion years coding might actually start. I might have exaggerated a bit here but that's somehow the feeling I have more and more in modern software development.

ubernostrum 9y ago

There's no such thing as web application development "without a framework". There is only a choice between using someone else's framework, and inevitably building your own. If you reject all third-party frameworks, you will end up reinventing a bunch of design patterns from other frameworks. You will end up writing your own libraries to do the things the framework would have done. And you will -- no matter how good or fast it feels to you -- end up spending more time in the writing and maintenance of your private "non-framework" than you would have spent in deploying an existing one off-the-shelf.

patricklouys 9y ago
That's not true. I've worked on large applications with frameworks (CodeIgniter, Symfony) and without frameworks (but with composer packages). In the beginning you might spend a little more time on wiring things together, but on a large enough application your framework will always get in the way somehow and you will have to find workarounds. For large projects, I strongly prefer a frameworkless approach. If you do throwaway apps for an agency, then a framework is probably the better choice.
- ubernostrum 9y ago
  You chose a set of libraries. You installed them. You used them. And by "used them", I mean you wrote code which called into them and which wired together all the various pieces to make a coherent web application. I know you did this, because if the libraries had come with a magical "make all these things work together" function for you to use instead, you would have dismissed that as a framework. You don't want to call that combination of libraries and in-house wiring-together code a framework. I get that. But that's what it is, whether you want to call it that or not. And I'm sure that you don't see it as a maintenance burden right now. It never feels like a framework or a burden at first, because it's all made up of this code that you wrote and that you understand and that you control, and it feels great! For a while, at least. But sooner or later you will realize you have built your own in-house web framework, and that now part of your business is to be a web-framework developer, instead of a whatever-your-company-actually-needed-to-make developer, and that being a web-framework developer is not a very fun business to be in. And you will hire more people, and they will have to be trained on this thing-you-refuse-to-call-a-framework, but they'll recognize the patterns sooner or later, and will wonder out loud why it's missing this or that feature that the off-the-shelf frameworks have out of the box, or why this particular part of its API is so weird and cumbersome (it made sense back when the codebase was much smaller and only a couple people worked on it, you'll tell them, sheepishly). And maybe some of them will roll up their sleeves and try to add what's missing or clean up the historical weirdness, and maybe some of them will get tired of working on this thing that won't add to their résumé and leave, and others will just do their best to get work done, but at a much slower pace because they're working with a framework built by people who hate frameworks, and still others will start to agitate for just going and getting a proper framework off the shelf and using it already, and you will end up having some very interesting and perhaps very heated team meetings, and you'll realize that you're spending way too much time as a team talking about tools and technologies and not nearly enough talking about products and bugs and features and this is not going as well as it was back when everything seemed so simple and easy in the world of "frameworkless" development. This is the iron-bound web developer's counterpart to Greenspun's Tenth Rule, and in my experience there is no escaping it.

patricklouys 9y ago

I like to use the same approach, I even wrote a tutorial [0] and a book [1] about it. That being said, I am still forced to use Symfony at my current job. It only gets in the way sometimes, it's not too bad. On my previous job we went from CodeIgniter to frameworkless and I really liked that. Not having framework constraints working against you was really enjoyable to work with. [0] https://github.com/PatrickLouys/no-framework-tutorial https://github.com/PatrickLouys/no-framework-tutorial [1] https://patricklouys.com/professional-php/ https://patricklouys.com/professional-php/

jwdunne 9y ago
I recently gave Sylius, based on Symfony, a spin. I wanted to add a field to a product, editable in the admin area. The additional code and the extensions were ok. Some of the config changes are understandable but I thought it a bit much when the number of additions to configuration outstripped the amount of code required.
- patricklouys 9y ago
  I feel your pain. That's my biggest gripe with Symfony. Sometimes it feels like I am spending more time configuring that programming.
  - cutler 9y ago
    Rewind to 2005. Isn't this why Rails was born?
    - jwdunne 9y ago
      Funnily enough, I chose a Rails e-commerce solution, Solidus. I added the same feature, 0 configuration, similar if not less code required. Unfortunately I'm the only one who knows Ruby but I have every faith that my colleagues can pick it up.

rgomez 9y ago

Wait, this is far from vanilla PHP, is this not gloryfing "Composer" as the new meta-framework?

sbarre 9y ago
Only if you consider gem and npm to also be frameworks. Or by further abstraction, Github.
- rgomez 9y ago
  Well, if a project depend on them to actually work, yes, kind of, I consider them frameworks.

andybak 9y ago

Curious about the use of Dependency Injection here. I'm a Python guy and it rarely gets mentioned in my world as far as I'm aware. I always assumed it was mostly an artefact of static type systems. Can anyone share their insight? Either in the context of Python or PHP.

RhodesianHunter 9y ago
How well are your codebases unit tested? I shiver thinking about trying to add good tests to a project in any language without good di/ioc.
- bramblerose 9y ago
  The dynamicness of languages like Python make it relatively easy to do so. For example, it's difficult in Java to mock an http request if you can't inject a `HttpRequestor` (or so) to the object you're testing. In Python, it is common practice to patch objects, which means that even though the code calls `requests.get()`, the call will actually be patched through to a mock. (in the Java world, this is possible with e.g. PowerMock, but generally frowned upon)

troels 9y ago

> So there you have it. With just 44 lines and the help of several widely-used, thoroughly-tested, reliably interoperable components, we have the bootstrap for a modern PHP application. Uhm .. so ... a framework?

paulddraper 9y ago
A microframework, at least. Hardly close the complexity/features of CakePHP or others.
rocketpastsix 9y ago
No, just components that handle certain things.

fulldecent 9y ago

I read this article and found it to be a great example of why we should NOT adopt modern PHP techniques at our company. 50 lines of code and contrived examples (is HelloWorld class a view or controller? AwesomeClass is a model?) get one line of HTML emitted in a barely readable way. This article fails to motivate why each layer of complexity is added. It basically starts with the assumption that you want to use a framework and says "hey look you can do the same thing with 50 lines of boilerplate, not really, but kind of." I would be much more impressed with an article that starts with the obvious way to write a PHP application (.htaccess, index.php, products.php, library/database.php, library/*.php) and then explains the actual problems that would make you want to opt for more complexity/organization/modern techniques.