There's a saying in the PHP community: Every developer should build two and a half frameworks.

  1. The first is a learning exercise of the PHP runtime, understanding how pieces move and connect.
  2. The second is an application of their new knowledge to fix the flaws in their first approach.
  3. The third is a project aborted because they have realized their wheel looks just like everyone else's wheels and they're better off just using the existing tools out there.


    The third is where they reach enlightenment and stop using frameworks entirely because they now know how to pick and choose the pieces they actually need for the project they're working on.

All PHP frameworks are actually boilerplates, so I find this extremely relevant when reading Justin Falcone's Medium post Node.js is a Salad Bar.

I've built quite a few boilerplates in my time, for both PHP and Node.js. Sometimes these boilerplates serve as actual launching points for new sites – I built more than a dozen sites using the PrimalPHP boilerplate that I constructed when I was doing agency work – but most of the time these boilerplate projects were actually about learning a stack. In other words, they were my first and second frameworks, constructed to better help me understand the way the various parts worked together and to explore new ways of solving problems. I've got one right now that I've been building to learn the React ecosystem and explore methods that I do or don't see in other boilerplates.

I publish these boilerplates on github not because I expect anyone to actually launch a new site off of them, but so that I can refer to them in conversations with other developers, both for seeking advice from more experienced people, and for teaching other people following in my footsteps. When someone comes in to a chat room with a problem that I've solved, I have a reference example that I can point them at to show them how I tackled it.

Obviously, Not-All-Boilerplates are built for this reason, but I'd bet that a lot of them came from that point of origin: one developer's attempt at learning a new ecosystem. Blaming boilerplates for being bad ways to start with new tools is like watching someone fall out of a tree and then blaming the tree for growing in the first place. Maybe what we need is to teach people how to grow a tree they can climb?

The issue isn't with the existence of boilerplates, its with the copy-paste mentality that you can use a set of tools without learning how they work first. The issue is with developers trying to take shortcuts to getting running websites instead of working out each part of the system individually. Justin thinks the solution to this is better tooling to build the user's site for them. He wants "a higher level abstraction to work with our own frameworks", but that is just further separating the developers from the tools they're trying to learn.

Justin is right that "Novices need frameworks", but the solution is to start teaching them how to build their own again.