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!<p>In true JavaScript fashion, I decided to learn PHP again by building a framework to put all the pieces together in my brain.<p>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.
You're requiring PHP 8.3 but not using some of the most powerful tools in 7+: strict types.<p>```
/* @var array<string, mixed> Variables stored in the context */
private $variables = [];
```<p>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.<p>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.<p>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.<p>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.<p>Your framework seems like it can only handle `application/json` and `application/x-www-form-urlencoded` requests, but not `multipart/form-data`.<p>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.
We actually target a HUGE legacy PHP codebase (its over 16 years old, with over 1M LOC) with Haxe. I would not EVER write vanilla PHP for anything else than a toy website, because there is no amount of testing that makes it stable enough.<p>We still have a lots of legacy PHP, but its slowly being refactored to Haxe. With Haxe we get a really nice typesystem, and a "faster than Go" compiler. It has pushed our productivity thru the roof.<p>We still need to use external dependencies tho, as PHP lacks any concurrency in the core language, so we also have a Go API for fetching data concurrently, and also use it as a BI directional socket for the frontend and as a queue server.<p>Otherwise, the stack is pretty much PHP7 from top to bottom.
I don't see myself ever using anything other than Laravel, but love these kinds of projects just to see what new ideas they might spark for the wider PHP community. Also interested in <a href="https://tempestphp.com/" rel="nofollow">https://tempestphp.com/</a>
I wish the market didn't determine the technologies we get to work with. because at times the market can be wrong due to incentives.<p>e.g the market was wrong on graphQL.<p>btw Hono is cool, but found the api surface area insufficient for my node.js usecases.
I've went through a similar journey, with some PHP in the early days, then a lot of Merb/Rack/RoR experience. Though I'd not say PHP is back. I'd avoid it for new projects as there are --IMHO-- much better languages available for free.<p>What I really liked from webdevt in Ruby was Rack. <a href="https://github.com/rack/rack">https://github.com/rack/rack</a> (gosh I prefer the simplicity of the old logo)<p>And I found a Rack-like architecture in "http4k" <a href="https://www.http4k.org" rel="nofollow">https://www.http4k.org</a><p>In a way Kotlin can be looked at as a "typed Ruby". Sure Ruby now has optional types, but I believe it's not something easily bolted on later. The whole lang + stdlib should be built in an idiomatic way. Changing the language a lot later usually creates a mess in the stdlib.<p>The framework http4k delivers is very similar Hono/Dumbo, but it has a Rack built in as well. Also, http4k is make by functional programming enthusiasts. So it clearly separates logic and data.<p>Small request: Please make Hono clickable in the README!
If nothing else, I love the logo. A hyper-realistic take on the ElePHPhant [0].<p>[0] <a href="https://www.elephpant.com/" rel="nofollow">https://www.elephpant.com/</a>
What's your distinguishing point over Slim and Silex (rip) because from your example script I don't see anything different. I mean, how would it, (un?)fortunately PHP syntax doesn't let you play as much with DSLs as Ruby or other languages.
For a programming language mostly out of favor, the effort to get a framework right and find the right audience to use this over existing options will be tricky. Good luck!
Yeah, I believe Sinatra <a href="https://sinatrarb.com/" rel="nofollow">https://sinatrarb.com/</a> or Padrino <a href="https://padrinorb.com/" rel="nofollow">https://padrinorb.com/</a> inspired Hono. So you are back to Ruby ;)