8 ms·

Show HN: Dumbo – Hono inspired framework for PHP

76 points by notrab 2y ago

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.

dzonga 2y ago
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.
- no_wizard 2y ago
  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
  - davzie 2y ago
    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?
    - no_wizard 2y ago
      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
      - ITB 2y ago
        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.
        no_wizard 2y ago
        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.
        jayknight 2y ago
        Any chance you can point to a good graphql implementation/framework that someone could use to learn best practices?
        no_wizard 2y ago
        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 https://github.com/dotansimha/graphql-yoga [1]: https://spec.graphql.org 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 https://github.com/graphql/dataloader
  - deleted 2y ago
    [deleted]
  - bearjaws 2y ago
    GraphQL has too many foot guns for your typical SMB to implement successfully, especially pivoting from REST. It requires you to architect your solution much further ahead than most companies have the capability to. I prefer it over SOAP, but I think it's far too easy to ignore: N+1 issues Security (found that we had our entire schema open including internal data routes at my last job), also we had to refactor from patients being company -> patient to company -> pharmacy -> patient... that was fun Overcomplicating resolvers Not implementing pagination upfront Dead end schema designs, since you need to plan much further ahead it really hurts when you mess it up. In REST you can make a V2 of a route and move on. Especially since many people ignore modules at first. Even large corporations get stuck with UserEntity_V2, updateUser_V2. IMO if you are going "wow if only we had GraphQL" and your team only knows REST you are always better off improving your REST tooling and standards. For example, when adding a new entity/resource you can just plan to understand how your own teams intend to query for this data, rather than guessing with GraphQL or implementing every search pattern.
    - no_wizard 2y ago
      All of these are developer issues and not issues with the technology. They aren’t inherent to GraphQL. By your own admission it’s sloppy developer work that causes issues it’s not the tech. REST APIs actually do have an inherent problem, which is they’re one call == one source. Everything has to be bespoke to the endpoint, where as GraphQL as a technology allows one to not have to do that. Versioning APIs is a code smell. With GraphQL you can combine queries by using Fragments for example. You could also perform concurrent resolution with resolvers and merge data results if if it’s appropriate for the scenario to resolve a single query. There is far more flexibility in the model but you as a developer are 100% in charge of performance and such, no different than REST. GraphQL gives far more flexibility in finding a solution for any given scenario, where as REST is an extremely rigid 1 == 1 resource coupling. As for pagination isn’t built into REST. Anything “standard” about that was bolted on and varies quite a lot. Where as GraphQL does address this[0] on an implementation reference level. Regarding exposing schema, while I question if there is the security risk you're implying it to be (lots of organizations expose their GraphQL schemas, like Salesforce and GitHub) but never the less, any good implementation will have a single line option for turning it off. Apollo does (arguably the most popular of the implementations) but so does GraphQL Yoga and even implementations in other languages. As far as developers go, the biggest mistake developers make is creating schema that is simply a clone of their database schema at the end of the day, and this is the absolute worst way to go about implementing GraphQL. Its explicit purpose is to have a middle layer that lets you express APIs for intended purpose, not to be coupled to your database schema [0]: https://graphql.org/learn/pagination/ https://graphql.org/learn/pagination/
- endofreach 2y ago
  "The market" = facebook. It shouldn't be a surprise.
wink 2y ago
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.
- notrab 2y ago
  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.
- oldandboring 2y ago
  This is what I was thinking as well. From the README examples it looks like every other modern PHP micro framework.
  - notrab 2y ago
    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.
ajith-joseph 2y ago
[flagged]
- notrab 2y ago
  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.
WORMS_EAT_WORMS 2y ago
Honestly beautifully designed. Really lives up to Hono name
- notrab 2y ago
  Hono is to credit for the design, really nice!
crowcroft 2y ago
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/ https://tempestphp.com/
- notrab 2y ago
  That looks awesome!
- racl101 2y ago
  I was about to start looking for a PHP micro framework. I wish Lumen was still supported.
  - notrab 2y ago
    Is FuelPHP or CodeIgniter still going? Those were my two favourites back in the day before Laravel came on the scene.
    - crowcroft 2y ago
      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
      - notrab 2y ago
        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.
  - leftnode 2y ago
    Symfony 7.2 can work as a micro framework, believe it or not: https://symfony.com/blog/new-in-symfony-7-2-simpler-single-file-symfony-applications https://symfony.com/blog/new-in-symfony-7-2-simpler-single-f...
basilgohar 2y ago
If nothing else, I love the logo. A hyper-realistic take on the ElePHPhant [0]. [0] https://www.elephpant.com/ https://www.elephpant.com/
- gagik_co 2y ago
  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.
  - notrab 2y ago
    I think it looks cute
jtreminio 2y ago
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.
- notrab 2y ago
  Appreciate the feedback, I'll work on it. I have lots to learn it seems!
- thinkingtoilet 2y ago
  Out of curiosity, what do you dislike so much about Laravel?
  - 2y ago
eterps 2y ago
Are there any frameworks other programming languages (besides this one) that are directly inspired by Hono?
phplovesong 2y ago
[flagged]
- bilekas 2y ago
  There is concurrency.. There is Unicode support There is a proposal for generics https://wiki.php.net/rfc/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.
  - that_guy_iain 2y ago
    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.
- jtreminio 2y ago
  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.
campak 2y ago
Small world! Congrats on getting up there on Hacker News, too!
- notrab 2y ago
  Thanks Campak!
avinassh 2y ago
perfect. beautifully designed. I will try this for my next side project.
- notrab 2y ago
  Yay PHP! Let me know how you get on
pftg 2y ago
Yeah, I believe Sinatra https://sinatrarb.com/ https://sinatrarb.com/ or Padrino https://padrinorb.com/ https://padrinorb.com/ inspired Hono. So you are back to Ruby ;)
- notrab 2y ago
  Sinatra is beautiful!
cies 2y ago
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 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 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!
shikck200 2y ago
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.
- gr4vityWall 2y ago
  Very interesting to hear about the Haxe PHP target being used like that. How did you start introducing it to the codebase? Were there any devs familiar with Haxe in the company already?
  - shikck200 2y ago
    See my above comment for a semi detailed version of how we do things.
- toastercat 2y ago
  This is really cool to hear as someone who used to experiment with Haxe for game development. Would love to read a case study.
  - shikck200 2y ago
    We started small. And prototyped with just a single feature. Basically we generate code in our src folder under a reserved namespace, and other PHP code can then use that code with imports. As we grow, we might want to split this into separate compilation units (we are not there yet, as the Haxe compiler is really fast!) At the moment the generated PHP code is checked in source control, again we might want to have this done in CI, but it works kind of nicely at the moment. The tricky bits are how to "speak" to PHP. Haxe is a really nice functional language (even its syntax is traditionally class based, but you can have module level fields in Haxe since 2020), so its pretty annoying to handle option types etc from the PHP side. We are still not decided on this part, and many APIs expose duplicate functions for some general task, like foo and foo_exn, and the one that ends with _exn throws instead of returning a variant (like option/maybe etc) Also, its tricky to design where data is fetched from. We tend to keep the Haxe code as pure as possible, and only taking input and returning output (not doing any IO). We also write our own typings for externals, this has actually been really good for us, as we can observe easily what we actually use, and if we can remove some dependency that has some one feature we only use. Overall, im amazed not more PHP devs look into Haxe as its basically a better version of what is TypeScript > JavaScript. Also there is no other compile to PHP language im aware of that ha the same robustness and features Haxe has.
honorable_judge 2y ago
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!
slifin 2y ago
Reminded me of https://fatfreeframework.com/ https://fatfreeframework.com/

76 points by notrab 2y ago

dzonga 2y ago

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.

no_wizard 2y ago
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
- davzie 2y ago
  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?
  - no_wizard 2y ago
    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
    - ITB 2y ago
      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.
      - no_wizard 2y ago
        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.
        jayknight 2y ago
        Any chance you can point to a good graphql implementation/framework that someone could use to learn best practices?
        no_wizard 2y ago
        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 https://github.com/dotansimha/graphql-yoga [1]: https://spec.graphql.org 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 https://github.com/graphql/dataloader
- deleted 2y ago
  [deleted]
- bearjaws 2y ago
  GraphQL has too many foot guns for your typical SMB to implement successfully, especially pivoting from REST. It requires you to architect your solution much further ahead than most companies have the capability to. I prefer it over SOAP, but I think it's far too easy to ignore: N+1 issues Security (found that we had our entire schema open including internal data routes at my last job), also we had to refactor from patients being company -> patient to company -> pharmacy -> patient... that was fun Overcomplicating resolvers Not implementing pagination upfront Dead end schema designs, since you need to plan much further ahead it really hurts when you mess it up. In REST you can make a V2 of a route and move on. Especially since many people ignore modules at first. Even large corporations get stuck with UserEntity_V2, updateUser_V2. IMO if you are going "wow if only we had GraphQL" and your team only knows REST you are always better off improving your REST tooling and standards. For example, when adding a new entity/resource you can just plan to understand how your own teams intend to query for this data, rather than guessing with GraphQL or implementing every search pattern.
  - no_wizard 2y ago
    All of these are developer issues and not issues with the technology. They aren’t inherent to GraphQL. By your own admission it’s sloppy developer work that causes issues it’s not the tech. REST APIs actually do have an inherent problem, which is they’re one call == one source. Everything has to be bespoke to the endpoint, where as GraphQL as a technology allows one to not have to do that. Versioning APIs is a code smell. With GraphQL you can combine queries by using Fragments for example. You could also perform concurrent resolution with resolvers and merge data results if if it’s appropriate for the scenario to resolve a single query. There is far more flexibility in the model but you as a developer are 100% in charge of performance and such, no different than REST. GraphQL gives far more flexibility in finding a solution for any given scenario, where as REST is an extremely rigid 1 == 1 resource coupling. As for pagination isn’t built into REST. Anything “standard” about that was bolted on and varies quite a lot. Where as GraphQL does address this[0] on an implementation reference level. Regarding exposing schema, while I question if there is the security risk you're implying it to be (lots of organizations expose their GraphQL schemas, like Salesforce and GitHub) but never the less, any good implementation will have a single line option for turning it off. Apollo does (arguably the most popular of the implementations) but so does GraphQL Yoga and even implementations in other languages. As far as developers go, the biggest mistake developers make is creating schema that is simply a clone of their database schema at the end of the day, and this is the absolute worst way to go about implementing GraphQL. Its explicit purpose is to have a middle layer that lets you express APIs for intended purpose, not to be coupled to your database schema [0]: https://graphql.org/learn/pagination/ https://graphql.org/learn/pagination/
endofreach 2y ago
"The market" = facebook. It shouldn't be a surprise.

wink 2y ago

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.

notrab 2y ago
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.
oldandboring 2y ago
This is what I was thinking as well. From the README examples it looks like every other modern PHP micro framework.
- notrab 2y ago
  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.

ajith-joseph 2y ago

[flagged]

notrab 2y ago
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.

WORMS_EAT_WORMS 2y ago

Honestly beautifully designed. Really lives up to Hono name

notrab 2y ago
Hono is to credit for the design, really nice!

crowcroft 2y ago

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/ https://tempestphp.com/

notrab 2y ago
That looks awesome!
racl101 2y ago
I was about to start looking for a PHP micro framework. I wish Lumen was still supported.
- notrab 2y ago
  Is FuelPHP or CodeIgniter still going? Those were my two favourites back in the day before Laravel came on the scene.
  - crowcroft 2y ago
    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
    - notrab 2y ago
      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.
- leftnode 2y ago
  Symfony 7.2 can work as a micro framework, believe it or not: https://symfony.com/blog/new-in-symfony-7-2-simpler-single-file-symfony-applications https://symfony.com/blog/new-in-symfony-7-2-simpler-single-f...

basilgohar 2y ago

If nothing else, I love the logo. A hyper-realistic take on the ElePHPhant [0]. [0] https://www.elephpant.com/ https://www.elephpant.com/

gagik_co 2y ago
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.
- notrab 2y ago
  I think it looks cute

jtreminio 2y ago

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.

notrab 2y ago
Appreciate the feedback, I'll work on it. I have lots to learn it seems!
thinkingtoilet 2y ago
Out of curiosity, what do you dislike so much about Laravel?
- 2y ago

eterps 2y ago

Are there any frameworks other programming languages (besides this one) that are directly inspired by Hono?

phplovesong 2y ago

[flagged]

bilekas 2y ago
There is concurrency.. There is Unicode support There is a proposal for generics https://wiki.php.net/rfc/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.
- that_guy_iain 2y ago
  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.
jtreminio 2y ago
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.

campak 2y ago

Small world! Congrats on getting up there on Hacker News, too!

notrab 2y ago
Thanks Campak!

avinassh 2y ago

perfect. beautifully designed. I will try this for my next side project.

notrab 2y ago
Yay PHP! Let me know how you get on

pftg 2y ago

Yeah, I believe Sinatra https://sinatrarb.com/ https://sinatrarb.com/ or Padrino https://padrinorb.com/ https://padrinorb.com/ inspired Hono. So you are back to Ruby ;)

notrab 2y ago
Sinatra is beautiful!

cies 2y ago

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 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 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!

shikck200 2y ago

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.

gr4vityWall 2y ago
Very interesting to hear about the Haxe PHP target being used like that. How did you start introducing it to the codebase? Were there any devs familiar with Haxe in the company already?
- shikck200 2y ago
  See my above comment for a semi detailed version of how we do things.
toastercat 2y ago
This is really cool to hear as someone who used to experiment with Haxe for game development. Would love to read a case study.
- shikck200 2y ago
  We started small. And prototyped with just a single feature. Basically we generate code in our src folder under a reserved namespace, and other PHP code can then use that code with imports. As we grow, we might want to split this into separate compilation units (we are not there yet, as the Haxe compiler is really fast!) At the moment the generated PHP code is checked in source control, again we might want to have this done in CI, but it works kind of nicely at the moment. The tricky bits are how to "speak" to PHP. Haxe is a really nice functional language (even its syntax is traditionally class based, but you can have module level fields in Haxe since 2020), so its pretty annoying to handle option types etc from the PHP side. We are still not decided on this part, and many APIs expose duplicate functions for some general task, like foo and foo_exn, and the one that ends with _exn throws instead of returning a variant (like option/maybe etc) Also, its tricky to design where data is fetched from. We tend to keep the Haxe code as pure as possible, and only taking input and returning output (not doing any IO). We also write our own typings for externals, this has actually been really good for us, as we can observe easily what we actually use, and if we can remove some dependency that has some one feature we only use. Overall, im amazed not more PHP devs look into Haxe as its basically a better version of what is TypeScript > JavaScript. Also there is no other compile to PHP language im aware of that ha the same robustness and features Haxe has.

honorable_judge 2y ago

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!

slifin 2y ago

Reminded me of https://fatfreeframework.com/ https://fatfreeframework.com/