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.
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
Symfony has a huge lot of magic (text/non-typed config files, factory/abstract bloats, ...), and even dark magic (compilation passes, ...), but it's better than Laravel in many ways indeed.
A simpler framework with modern techniques would be great though.
Too much angst about non standards and preferences. Everyone codes the way they feel comfortable and decides what to implement because the more mumbojumbo pattern magic included the more complexity you introduce to your codebase. And the development time skyrockets.
Just because someone wrote a book about patterns, it doesn't mean it's the high standard and the holy bible by any means. These people are mostly control freaks, who like to exert control on people and think their excrement is akin to a lump of gold.
And then there are the preachers - like you - who disseminate the bullshit these pattern monkeys rant day and night.
Makes sense. I agree on the ORM. I actively don't use Eloquent when I use Laravel. It's fine for simple actions but I find it can get in the way as the project grows more complex. Thanks for sharing.
This is an interesting project—love the idea of learning by building! A few questions for clarity and discussion:
1) Target Audience: Since Dumbo isn't aiming to compete with Laravel or Slim, who do you see as the ideal user for this framework? Hobbyists, small-scale production apps, or perhaps developers exploring modern PHP paradigms?
2) Distinguishing Features: You mentioned drawing inspiration from Hono.dev—how does Dumbo bring Hono's strengths into the PHP world? Are there specific design patterns or DX (developer experience) improvements that set it apart from existing lightweight frameworks like Slim?
3) Learning Resource Vision: As you see Dumbo also as a learning tool, do you plan to include guided examples or documentation for PHP developers looking to understand the modern ecosystem better?
PHP is definitely in an interesting place right now; excited to see what Dumbo evolves into!
1) When I started this, I thought could this be an HTMX-PHP framework. If you see the examples directory, I added a few HTMX examples early days. Maybe I can niche down on this...
2) If I'm honest, I don't know yet. I first started building the router, then I was told through some feedback that there's been a lot of research (rightly so) into this area and I would be better off implementing the FastRouter that's in Slim, so I switched to that...
As mentioned above, if I could make this framework fit with HTMX more, I could have a PHP framework that talks HTMX with less of the wiring up. I still need to figure this out.
3) I've avoided building an official site/docs for it, but I might have to. I had hoped the examples were a good source, but as more features were added, creating official docs site might have to be my next task.
PHP isn't yet part of my default stack, but I am trying to thanks to what I've been learning building Dumbo.
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 https://tempestphp.com/
They say it "can" but it is not first class in their docs or minds, so it's mostly up to you to figure out how to do most of things then. It would be better to have an independent micro framework with a clear scope of what it can and cannot do compared to the full Symfony stack.
But if you're looking for something more modern and interesting, then Hyperf looks pretty cool. They have a mini-framework version you can check out: https://github.com/hyperf/nano
It does require Swoole, but that is a lot easier to get your hands on these days
When you say micro framework, what are you looking for? If you're just looking for a routing library then something like Symfony Flex might be what you want.
I find when I start a project I pretty quickly want to add an ORM, models, and maybe some middleware, and then I'm at a point where I might as well just use Laravel because it's fast enough and I know my way around.
True true. I went back and forth so much in the early days of CodeIgniter, Rails, Fuel and Cake.
Eventually discovered just building stuff was going to bring me the most joy, no matter the tool. It's been a joy learning PHP again though, even if I do suck at it right now.
I ask a a REST turned GraphQL advocate to be clear but criticisms I hear tend to be opinions or issues with specific implementations but not ones based on the technical shortcomings of the technology
I can't comment on all the shortcomings and this may be reflective on my lack of experience with different implementations, but doesn't using GraphQL basically just enable a tonne of unoptimised database queries to occur that, at scale, could cause some serious load issues?
If a certain arrangement makes it more likely to write bad queries, and it requires extra care to write optimal queries, then it’s a worse interface to a database. I bet for really database intensive applications graphQL adds more work than it saves.
You're talking about the implementation of the protocol, right?
That is a good implementation of it, called GraphQL Yoga[0]
However I'm concerned there is a slight disconnect here. I'm saying that the technical specification of GraphQL does not lend itself to being bad, rather its the failure of developers to really understand its purpose and what its for (its a giant aggregator, with various ways to optimally aggregate things together, depending on what is optimal for a given problem set)
For that, I recommend becoming more familiar with the specification itself[1] because thats what I'm talking about. The specification (and thus its technical nature) doesn't prescribe anything regarding how you get data on to the graph. Many people equate GraphQL with database problems[2]
This doesn't mean I don't understand that GraphQL has shortcomings, but all approaches to APIs have short comings. I have found GraphQL has the least amount
[2]: Common complaint I see all the time. I find it stems from a failure to understand how the entirety of GraphQL is meant to work, and some of the mechanics within. Like when to appropriately leverage DataLoader[3], for instance.
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.
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.
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.
Otherwise, the stack is pretty much PHP7 from top to bottom.
There is definitely a discussion like this under every repo at this point but I genuinely do not understand why people feel the need to have AI art for their GitHub projects. It’s subjective but it just looks tacky and cheap, as is nearly always case with AI art. Some online, non-AI logo generator that slaps a generic royalty free icon with a font would be miles better, or honestly even dropping it altogether and just having a header.
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.
I guess that's still to figure out... it's mostly been an experiment to relearn PHP... I guess keeping a similar DX to Hono's context->X is where I was coming from originally.
100% like every other framework. I'm primarily a JS dev, so it's in my nature to create yet another framework...
But seriously, this has been a tool for me to relearn PHP, and those contributing so far have also been learning PHP. If it ends up just bein (and nothing more than) something helps me, as well as others learn more about PHP, it's a success.
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.
What I really liked from webdevt in Ruby was Rack. https://github.com/rack/rack (gosh I prefer the simplicity of the old logo)
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.
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.
Small request: Please make Hono clickable in the README!
Why choose PHP in 2024? There is no concurrency, no unicode support and no generics. What does PHP give that i cant find in any other mainstream language?
Your whole comment history with regards to PHP reads like someone frustrated that the tool they've chosen to shit on is exactly the opposite of what they think it is but they don't want to admit it.
To be fair, there is technically concurrency. But it’s not what you would really expect. But as someone pointed out to me 14 years ago, if you need concurrency in your web request you‘re probably doing something wrong.
There is some very impressive work going on to define how Generics will work in PHP. It’s a matter of when not if Generics come to PHP. I‘m expecting a new RFC for Generics to be created some point next year.
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.
Appreciate the feedback, I'll work on it. I have lots to learn it seems!
Out of curiosity, what do you dislike so much about Laravel?
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
Symfony has a huge lot of magic (text/non-typed config files, factory/abstract bloats, ...), and even dark magic (compilation passes, ...), but it's better than Laravel in many ways indeed.
A simpler framework with modern techniques would be great though.
Too much angst about non standards and preferences. Everyone codes the way they feel comfortable and decides what to implement because the more mumbojumbo pattern magic included the more complexity you introduce to your codebase. And the development time skyrockets.
Just because someone wrote a book about patterns, it doesn't mean it's the high standard and the holy bible by any means. These people are mostly control freaks, who like to exert control on people and think their excrement is akin to a lump of gold.
And then there are the preachers - like you - who disseminate the bullshit these pattern monkeys rant day and night.
Makes sense. I agree on the ORM. I actively don't use Eloquent when I use Laravel. It's fine for simple actions but I find it can get in the way as the project grows more complex. Thanks for sharing.
This is an interesting project—love the idea of learning by building! A few questions for clarity and discussion:
1) Target Audience: Since Dumbo isn't aiming to compete with Laravel or Slim, who do you see as the ideal user for this framework? Hobbyists, small-scale production apps, or perhaps developers exploring modern PHP paradigms?
2) Distinguishing Features: You mentioned drawing inspiration from Hono.dev—how does Dumbo bring Hono's strengths into the PHP world? Are there specific design patterns or DX (developer experience) improvements that set it apart from existing lightweight frameworks like Slim?
3) Learning Resource Vision: As you see Dumbo also as a learning tool, do you plan to include guided examples or documentation for PHP developers looking to understand the modern ecosystem better?
PHP is definitely in an interesting place right now; excited to see what Dumbo evolves into!
Thanks!
1) When I started this, I thought could this be an HTMX-PHP framework. If you see the examples directory, I added a few HTMX examples early days. Maybe I can niche down on this...
2) If I'm honest, I don't know yet. I first started building the router, then I was told through some feedback that there's been a lot of research (rightly so) into this area and I would be better off implementing the FastRouter that's in Slim, so I switched to that...
As mentioned above, if I could make this framework fit with HTMX more, I could have a PHP framework that talks HTMX with less of the wiring up. I still need to figure this out.
3) I've avoided building an official site/docs for it, but I might have to. I had hoped the examples were a good source, but as more features were added, creating official docs site might have to be my next task.
PHP isn't yet part of my default stack, but I am trying to thanks to what I've been learning building Dumbo.
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 https://tempestphp.com/
I was about to start looking for a PHP micro framework. I wish Lumen was still supported.
Symfony 7.2 can work as a micro framework, believe it or not: https://symfony.com/blog/new-in-symfony-7-2-simpler-single-f...
They say it "can" but it is not first class in their docs or minds, so it's mostly up to you to figure out how to do most of things then. It would be better to have an independent micro framework with a clear scope of what it can and cannot do compared to the full Symfony stack.
Can't go wrong with Slim: https://www.slimframework.com/
But if you're looking for something more modern and interesting, then Hyperf looks pretty cool. They have a mini-framework version you can check out: https://github.com/hyperf/nano
It does require Swoole, but that is a lot easier to get your hands on these days
When you say micro framework, what are you looking for? If you're just looking for a routing library then something like Symfony Flex might be what you want.
I find when I start a project I pretty quickly want to add an ORM, models, and maybe some middleware, and then I'm at a point where I might as well just use Laravel because it's fast enough and I know my way around.
Is FuelPHP or CodeIgniter still going? Those were my two favourites back in the day before Laravel came on the scene.
I don't think Fuel is at all, and CodeIgniter is... but not really?
IMO Laravel is kind of the spiritual successor to CodeIgniter, although of course a lot has changed between V1 and V11
True true. I went back and forth so much in the early days of CodeIgniter, Rails, Fuel and Cake.
Eventually discovered just building stuff was going to bring me the most joy, no matter the tool. It's been a joy learning PHP again though, even if I do suck at it right now.
That looks awesome!
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.
e.g the market was wrong on graphQL.
btw Hono is cool, but found the api surface area insufficient for my node.js usecases.
How was the market objectively wrong on GraphQL?
I ask a a REST turned GraphQL advocate to be clear but criticisms I hear tend to be opinions or issues with specific implementations but not ones based on the technical shortcomings of the technology
I can't comment on all the shortcomings and this may be reflective on my lack of experience with different implementations, but doesn't using GraphQL basically just enable a tonne of unoptimised database queries to occur that, at scale, could cause some serious load issues?
GraphQL says nothing about databases at all. Resolvers can get resources from anything, they’re agnostic.
None of that is inherent to the technology but it’s a common folly among developers. This is an issue with REST too but it can be more obfuscated
If a certain arrangement makes it more likely to write bad queries, and it requires extra care to write optimal queries, then it’s a worse interface to a database. I bet for really database intensive applications graphQL adds more work than it saves.
It’s not though. Especially since GraphQL makes no mention of databases. It’s a resource agnostic protocol.
This isn’t a technical issue with GraphQL. It’s a culture issue among developers who shoehorn GraphQL and don’t use it appropriately
As someone who works on very database intense application GraphQL saves me more work than its ever caused.
Any chance you can point to a good graphql implementation/framework that someone could use to learn best practices?
You're talking about the implementation of the protocol, right?
That is a good implementation of it, called GraphQL Yoga[0]
However I'm concerned there is a slight disconnect here. I'm saying that the technical specification of GraphQL does not lend itself to being bad, rather its the failure of developers to really understand its purpose and what its for (its a giant aggregator, with various ways to optimally aggregate things together, depending on what is optimal for a given problem set)
For that, I recommend becoming more familiar with the specification itself[1] because thats what I'm talking about. The specification (and thus its technical nature) doesn't prescribe anything regarding how you get data on to the graph. Many people equate GraphQL with database problems[2]
This doesn't mean I don't understand that GraphQL has shortcomings, but all approaches to APIs have short comings. I have found GraphQL has the least amount
[0]: https://github.com/dotansimha/graphql-yoga
[1]: https://spec.graphql.org
[2]: Common complaint I see all the time. I find it stems from a failure to understand how the entirety of GraphQL is meant to work, and some of the mechanics within. Like when to appropriately leverage DataLoader[3], for instance.
[3]: https://github.com/graphql/dataloader
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.
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.
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.
Otherwise, the stack is pretty much PHP7 from top to bottom.
If nothing else, I love the logo. A hyper-realistic take on the ElePHPhant [0].
[0] https://www.elephpant.com/
There is definitely a discussion like this under every repo at this point but I genuinely do not understand why people feel the need to have AI art for their GitHub projects. It’s subjective but it just looks tacky and cheap, as is nearly always case with AI art. Some online, non-AI logo generator that slaps a generic royalty free icon with a font would be miles better, or honestly even dropping it altogether and just having a header.
I think it looks cute
Small world! Congrats on getting up there on Hacker News, too!
Thanks Campak!
perfect. beautifully designed. I will try this for my next side project.
Yay PHP! Let me know how you get on
Yeah, I believe Sinatra https://sinatrarb.com/ or Padrino https://padrinorb.com/ inspired Hono. So you are back to Ruby ;)
Sinatra is beautiful!
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.
I guess that's still to figure out... it's mostly been an experiment to relearn PHP... I guess keeping a similar DX to Hono's context->X is where I was coming from originally.
This is what I was thinking as well. From the README examples it looks like every other modern PHP micro framework.
100% like every other framework. I'm primarily a JS dev, so it's in my nature to create yet another framework...
But seriously, this has been a tool for me to relearn PHP, and those contributing so far have also been learning PHP. If it ends up just bein (and nothing more than) something helps me, as well as others learn more about PHP, it's a success.
Are there any frameworks other programming languages (besides this one) that are directly inspired by Hono?
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.
What I really liked from webdevt in Ruby was Rack. https://github.com/rack/rack (gosh I prefer the simplicity of the old logo)
And I found a Rack-like architecture in "http4k" https://www.http4k.org
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.
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.
Small request: Please make Hono clickable in the README!
Honestly beautifully designed. Really lives up to Hono name
Hono is to credit for the design, really nice!
Why choose PHP in 2024? There is no concurrency, no unicode support and no generics. What does PHP give that i cant find in any other mainstream language?
Your whole comment history with regards to PHP reads like someone frustrated that the tool they've chosen to shit on is exactly the opposite of what they think it is but they don't want to admit it.
There is concurrency..
There is Unicode support
There is a proposal for generics https://wiki.php.net/rfc/generics
For me personally its not a deal-breaker, there are workarounds if needed.
but for your question, why not?
It's so frustrating to see people just suggesting the "Mainstream" without considering if OP even asked.
Edit : Unicode support is not native. So concede this one, but again not a deal breaker as a language IMO.
To be fair, there is technically concurrency. But it’s not what you would really expect. But as someone pointed out to me 14 years ago, if you need concurrency in your web request you‘re probably doing something wrong.
There is some very impressive work going on to define how Generics will work in PHP. It’s a matter of when not if Generics come to PHP. I‘m expecting a new RFC for Generics to be created some point next year.