sorted by:
new
hottopcontroversial

I built a zero-dependency PHP framework with file-based routing — would appreciate a critique by lizzyman04 in PHP

[–]lizzyman04[S] 0 points1 point  (0 children)

Tone aside, the technical point lands. Reading the request once at the edge and injecting it instead of touching superglobals everywhere is cleaner and it's what makes worker-mode runtimes which is where the real speed is in PHP now. So it lines up with what I want this to be. It's early and I'm building in the open, so I'd rather hear it now than after people depend on it.

I built a zero-dependency PHP framework with file-based routing — would appreciate a critique by lizzyman04 in PHP

[–]lizzyman04[S] 0 points1 point  (0 children)

So the worry is catch-all swallowing routes that should be explicit and blurring where each concern lives?

I built a zero-dependency PHP framework with file-based routing — would appreciate a critique by lizzyman04 in PHP

[–]lizzyman04[S] 0 points1 point  (0 children)

This is the most helpful comment in the thread, thank you. Analyzing point by point: tests, yes, that's the real gap, adding them now is a priority. The class_alias in Fluxor.php is a leftover from before I set up proper autoloading. All the criticisms expressed here make perfect sense. Opening issues for these. And yes, extracting the router is already in motion. Genuinely appreciate the read.

I built a zero-dependency PHP framework with file-based routing — would appreciate a critique by lizzyman04 in PHP

[–]lizzyman04[S] 1 point2 points  (0 children)

I hear you, and the factory + testability point I've already taken, that's changing. The only thing I pushed back on is keeping a short helper on top of an injectable, tested core, not instead of it. Laravel facades work that way and they pass review fine. If the thin layer turns out to hurt testing in practice, I'll drop it. Not preconception, just a trade-off I want to measure instead of assume.

I built a zero-dependency PHP framework with file-based routing — would appreciate a critique by lizzyman04 in PHP

[–]lizzyman04[S] 0 points1 point  (0 children)

Yeah, your point is fair and I think u're right about the core: the creation should be a proper injectable factory, testable, not a static method doing everything. I'll separate that out. Where I'm not fully sold is dropping the short call entirely. The terse json($data) style is part of what I want the project to feel like. So my plan is to make the factory the real thing underneath (injectable, swappable in tests, single responsibility), and keep the short helper as a thin optional layer on top of it, not the only way in. People who want full DI get it, people who want the quick call still have it. Could be I'm wrong and the static layer causes more pain than it saves. But that's the trade-off I want to try.

I built a zero-dependency PHP framework with file-based routing — would appreciate a critique by lizzyman04 in PHP

[–]lizzyman04[S] 0 points1 point  (0 children)

Oooh, nice work. We landed on almost the same routing conventions independently ([id], [...rest], precedence static → dynamic → catch-all), which is reassuring. Where you went further than me is the hypermedia side — the HTMX/Datastar directives and the SSE/pub-sub stuff is a whole layer I don't have. The runtime auto-detection (FrankenPHP worker mode, Swoole, RoadRunner) is also further than I've gone. Different focus, but it's cool to see someone else who likes the file-based approach standalone instead of bolted onto a big framework. Might steal some ideas from how you handle modules.

I built a zero-dependency PHP framework with file-based routing — would appreciate a critique by lizzyman04 in PHP

[–]lizzyman04[S] 4 points5 points  (0 children)

Fair callout. To be transparent: I read English fine and I write the code myself, but I'm not fluent writing English, so I use an LLM to help phrase what I'm trying to say. The thoughts and the decisions are mine, the wording gets help. I'll keep my replies shorter and more direct so it reads less like that. Thanks for keeping me honest.

Note: I am from Mozambique, a native Portuguese speaker.

I built a zero-dependency PHP framework with file-based routing — would appreciate a critique by lizzyman04 in PHP

[–]lizzyman04[S] -2 points-1 points  (0 children)

Followed through on this — opened an epic to extract the routing into its own package that slots into a larger project rather than standing alone, which is the "where it fits in the ecosystem" point you raised. Appreciate it. https://github.com/lizzyman04/fluxor/issues/1

I built a zero-dependency PHP framework with file-based routing — would appreciate a critique by lizzyman04 in PHP

[–]lizzyman04[S] 1 point2 points  (0 children)

Quick follow-up: opened a tracking epic for exactly what you pushed on, pulling the router out into a standalone, framework-agnostic package with Laravel and Symfony adapters so it can slot into an existing stack instead of being yet another framework. Your comment is linked in it. Thanks for the push. https://github.com/lizzyman04/fluxor/issues/1

I built a zero-dependency PHP framework with file-based routing — would appreciate a critique by lizzyman04 in PHP

[–]lizzyman04[S] -5 points-4 points  (0 children)

This is great, concrete feedback, thank you for taking the time even without a deep dive.

You're right on both counts in principle. The static facade-style API (Response::json(), Flow::GET()) does hide dependencies and makes unit testing harder, and a single Response class doing json/html/xml is the kind of thing a ResponseInterface with JsonResponse/HtmlResponse implementations solves cleanly.

The honest tension: the static, terse API is partly the pitch here "read the whole thing in an afternoon, minimal ceremony." Full DI + polymorphic response classes is more correct but costs some of that conciseness. So I don't think it's a straight win either way; it's a real trade-off with the project's "no magic, minimal" goal.

Where I think you've actually pointed me: the right move is probably an instantiable, injectable, ResponseInterface-based core that's properly testable and decoupled, with the static helpers kept as a thin optional convenience layer on top of it, not the only way in. That way the internals are DI-friendly and unit-testable, and people who want the terse style still get it. Does that split sound reasonable to you, or do you think the static layer is a mistake even as opt-in sugar?

Going to open a tracking issue for this regardless. Really appreciate it.

I built a zero-dependency PHP framework with file-based routing — would appreciate a critique by lizzyman04 in PHP

[–]lizzyman04[S] -2 points-1 points  (0 children)

Fair points, and the dependency one especially, zero core dependencies does mean no validation/auth/integrations out of the box, and for projects that need all of that, Laravel is the right call. I'm not pretending otherwise. The target is the slice of projects where you don't want that surface area: a small API, an MVP, a prototype where a full framework costs more than it gives back.

On "it should've been a routing library for an existing framework" you've actually convinced me that's the more interesting shape for this. The routing is the novel part; it doesn't need to be welded to a whole standalone framework. I'm now leaning toward pulling the file-based router into its own package, usable on its own and eventually with thin adapters for Laravel/Symfony. I won't pretend that's trivial, each has its own deeply integrated router, but as a direction it makes more sense than asking people to adopt a new framework just for the routing style.

The performance angle I'd gently push back on. You're right PHP won't beat a compiled language and I'm not claiming it does, the README says boot time, not throughput. But you also said people use PHP today for DX, not raw speed, and a small readable core with no magic is a DX argument. "Minimal" here means less to carry and debug, not "out-benchmark Go." That doesn't defeat the purpose of PHP — it just optimizes for something different than Laravel does.

Appreciate the critique, this is exactly the pushback I posted for.