Immediately after switching the page, it will work with CSR.
Please reload your browser to see how it works.
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.
e.g the market was wrong on graphQL.
btw Hono is cool, but found the api surface area insufficient for my node.js usecases.
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!
``` /* @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.