You can also use flexbox

Re: list vs not a list.

It's the kind of nuance that you could argue either way when there's only a single validation failure to alert the user to. Either would make sense semantically (a single input could potentially have more than one validation failure so a single list item isn't necessarily wrong), and CSS can make them visually indistinguishable.

Perhaps the deciding factor is whether to code for one version that can be used in all situations, or have multiple types? That would probably make me lean towards an unordered list.

Okay. Let’s look at the logic.

Even with in-line validation, there’s still a hypothetical chance of more than one validation error occurring for a single form item.

Therefore, if we go down this road, validation errors would probably need to be presented as individual lists on a per-form-item basis. On the other hand, maybe I’m wrong. I genuinely don’t know.

Folks, none of this feels good to me. We have the fastest PHP framework in the world - but we only beat Phalcon by a whisker. It was incredibly close. I worry we’re standing at the edge of a downward spiral where more and more code keeps creeping in. Each tweak seems insignificant on its own, but over time all those small additions could slow the framework down.

The request is legitimate. Moreover, it's well-intentioned and well thought out. However, I believe my concerns about benchmarks are legitimate too.

Here’s my decision.

I’m going to arrange a video call with NinjaBalazs - the guy who ran the benchmark tests. He understands the benchmarking game far better than me. I want to raise these concerns with him and hopefully come away with some actionable advice on how we can preserve our speed while keeping everyone happy.

I’ll be back.

Hey DC,

Heads up on the way I did the benchmarks (assume NinjaBalazs did the same)

A fresh install of Trongate v2 with only `BASE_URL` configured and the test run against the default app means no custom pages or validation logic were executed. As a result, any changes suggested by codemonkey or sasin91 would not be reflected in those benchmark results that measured average requests per second.

Another way to correctly measure page load time, timing must start as early as possible - specifically when index.php is first executed via .htaccess.

1. in index.php2. In the view you want to measure (e.g. welcome.php):
With the app in its default state, this measurement will be effectively near zero, which is expected and does not represent real-world performance once routing, validation, database access, or custom modules are involved.

You could even add timing to certain parts of the page lifecycle to measure each level of the framework.

Folks,

Thank you for the suggestions and for the continued input.

As I understand it, this feature would almost certainly require adding more code to trongate.css. As you know, that stylesheet ships with the framework and is loaded by the default homepage - which means it is included during benchmark testing.

Because the performance margins are extremely tight, even small increases in payload can affect results.

If you haven’t already, please take a careful look at the benchmarks:

https://trongate.io/benchmarks

In particular, look at the comparison between Trongate v2 and Phalcon. The margin is extremely narrow. Indeed, it is close enough that different hardware or test conditions could plausibly reverse it. That’s how fine the balance is!

Trongate v2 only reached its current position by removing anything that wasn’t essential. For that reason, I’m not willing to add code to trongate.css - or to the engine itself - unless it directly improves stability, security, or core functionality.

If someone can demonstrate a way to implement the feature without increasing the size of the default stylesheet or the engine, I’m happy to review it. Otherwise, it’s not something I’m prepared to include.

If others wish to explore a different direction, forks are always welcome - that’s one of the strengths of open source.

DC

Re benchmark testing: it wouldn't ordinarily include stylesheet loading (unless your styles were embedded in the HTML in a <style> element).

OPcache means that small additions to existing files have no measurable impact unless they're actually being used in the code path. With OPcache, PHP files are not repeatedly loaded and compiled; instead, their compiled opcode arrays are stored in shared memory and executed directly, with only the relevant execution paths run at request time.

But obviously OPcache isn't a miracle worker. OPcache removes the parsing/compilation cost, but it doesn’t make the execution of your PHP logic free. If your request forces PHP to walk through hundreds of tiny “clean code” methods, that execution overhead is still very real.

OPcache accelerates startup cost, not runtime cost.

That's where Trongate shines: an ultra lightweight path from request start to end.

So don't let concern over benchmarks hold back genuinely useful additions that don't actually impact performance.

Not saying that the above is or isn't useful - just that it's something to be aware of in the future.