←back to thread

75 points notrab | 1 comments | | HN request time: 0.215s | source

Hey HN, I last PHP professionally over 15 years ago, and I loved it. I switched to Ruby on Rails, then Node/Go/React/GraphQL as there was a lot more demand for those roles. However, PHP is back!

In true JavaScript fashion, I decided to learn PHP again by building a framework to put all the pieces together in my brain.

I absolutely love Hono.dev, and decided to base the PHP framework on that. Dumbo isn't intended to compete with Laravel, Symphony or Slim, if anything, it's something people can use in production, but also contribute to and be used as a learning resource for others.

Show context
jtreminio ◴[] No.42174002[source]
You're requiring PHP 8.3 but not using some of the most powerful tools in 7+: strict types.

``` /* @var array<string, mixed> Variables stored in the context */ private $variables = []; ```

This should be typed as `array` (heck, I'd argue ArrayObject instead) and all your classes should have `declare(strict_types=1);` at the top.

Your `Dumbo\Helpers` classes are basically static mine traps that you are unable to mock in unit tests. Why does `BasicAuth` expose a single static method but then calls a bunch of other static methods? What ends up happening in any class that uses any of your `Dumbo\Helpers` classes will always run whatever code is defined in these helper classes.

I'm unsure where the bootstrapping process begins. What file does your webserver need to call to handle a new request? I am hoping it is within a root-level directory and not at the root level itself. In other words, `/public/index.php` vs `/index.php`. Your quickstart in README.MD makes it pretty clear that you expect the latter, which is highly unsafe. See any number of poorly configured webservers that stop processing PHP for any reason but now show your site's full contents to anyone passing by.

I would strongly argue against _any_ magic in your framework. Specifically, routes: they should be explicitly defined. I still work with a legacy Symfony 1 framework project and I can't tell you how much I detest magic routing. For a modern example see how Symfony 2+ requires explicit route definition. Heck, how it requires explicit everything because magic should be left to magicians.

Your framework seems like it can only handle `application/json` and `application/x-www-form-urlencoded` requests, but not `multipart/form-data`.

Take these as positive criticisms of your work. It's "fine". I wouldn't use it, I would actively recommend against using it, but I would actively recommend against using anything that's not Symfony (or Laravel if I were drunk). I do not think your project is at the "Show HN" level - it is still far too under-developed.

replies(3): >>42174199 #>>42174336 #>>42184795 #
thinkingtoilet ◴[] No.42174336[source]
Out of curiosity, what do you dislike so much about Laravel?
replies(1): >>42174433 #
jtreminio ◴[] No.42174433[source]
1) *magic* 2) Its ORM of choice uses ActiveRecord pattern which I find to be hideous. DataMapper is far superior 3) Its weird facade patterns is terrible

I can (and have!) gone in-depth into my misgivings with Laravel, but it is fine for most projects and teams. It has elevated the average codebase quality throughout the PHP community and introduced many engineers to what PHP can do. Its creator and community have been a large net-positive to PHP as a whole.

I still prefer Symfony:

1) explicit 2) DataMapper ORM by default 3) What I am used to

replies(5): >>42175145 #>>42182240 #>>42182458 #>>42182862 #>>42184088 #
dotancohen ◴[] No.42182862[source]
We are in agreement about Laravel's ORM, but I disagree about the magic. Laravel's "magic" is just convention over configuration, and most things can be configured as well.
replies(1): >>42183514 #
1. larsnystrom ◴[] No.42183514[source]
But really, who thought mixins was a good idea? It's the only place in the wild I've seen somebody bind $this when calling closures.