One of the stated goals for Trongate V2 is keeping things as close to the core technologies — PHP and MySQL — as possible, so the framework genuinely gets out of your way. The more I work with it, the more I appreciate how deliberate that decision is.

In a lot of frameworks today, you end up learning the framework first and PHP second. You write framework-flavoured code, and plain PHP becomes almost an afterthought. Trongate V2 flips that. You're still writing PHP — real PHP — and MySQL is still MySQL. The framework handles the repetitive, tedious parts (routing, validation, security, rendering) without hiding the language underneath.

A few examples that show what this looks like in practice.

1. Database work stays native

You're not learning a custom query builder or an ORM abstraction that has its own syntax. You're writing SQL, and Trongate stays out of the way:



Execution speed: a simple `get_where` call typically runs in ~0.3–0.8 ms on a modest shared host, with the query itself being the dominant cost. Because there's no ORM hydration layer, there's no extra object-mapping overhead — you get arrays back, ready to use.

2. Your models are still just PHP classes

There's no ceremony, no annotation parsing, no container to wire up. A model is a class, and its methods are methods:



Execution speed: instantiating a model and calling a simple method sits in the ~0.2–0.5 ms range. That's essentially the cost of loading one PHP file and running one method — nothing more.

3. Controllers do what controllers should do

Routing is simple, method names map to URLs, and you're not fighting a framework's idea of how a request should be structured:



Execution speed: a controller action that renders a view typically completes in ~1–3 ms end to end on a standard LAMP stack — again, the bulk of that is view rendering and I/O, not framework machinery.

Why this matters

- Onboarding is faster. If you know PHP, you already know most of Trongate.
- Debugging is easier. When something breaks, it's usually your code or the database — not an opaque framework layer.
- Performance is predictable. Fewer abstractions means fewer surprises when you profile.
- Your skills stay portable. What you learn here is PHP and MySQL, which you'll use everywhere else.
- It ages well. Core technologies don't get deprecated every 18 months.

To be clear, this isn't about being anti-framework or anti-abstraction. It's about the right amount of framework — enough to remove boilerplate, not so much that it gets in the way of the language you're actually writing.

I'd love to hear how others are finding this. Has the "close to the metal" approach changed how you write your code, or how you think about your projects? Any spots where you've found yourself wishing for a bit more abstraction, or (conversely) where the simplicity has saved you time?

I’ve been using Trongate in a production site since 2022. I had followed the system's development for years prior to that, and once I deemed it stable, I took the plunge. My project turned 24 years old this year...

A bit of history
Before that, I used MODx Evolution / Evolution CMS (I won't go further back than that), but then they decided that future versions would be based on Laravel... Up to that point, things were stable, albeit a bit neglected. It had a fantastic caching system, and the templates and site components were open and accessible. It wasn't without its flaws (for instance, the "Problem 5000" issue)—some were resolved, but still...
Why MODx Evolution instead of MODx Revolution? The former offered wonderful flexibility, whereas the latter was hindered by speed issues and high resource consumption.

Experiments with Phalcon
Towards the end—though I really ramped it up—I started experimenting with Phalcon (my hosting provider actually thanked me when I told them I’d be stopping :P). Why Phalcon? Speed, obviously. I had migrated a significant portion of the site, but something just felt off... Sure, it was fast, but then they decided to start adhering to PHP-FIG standards... Goodbye, and have fun following that nonsense.

And that brings us to Trongate
I stumbled upon it while searching for "OOP bullshit," having grown tired of alternatives that overcomplicate things—and, consequently, slow them down. It’s as if developers are trying to prove just how "great" they are by writing massive amounts of code instead of putting in the actual thought—lots of code, very little thinking. The idea is to create something simple yet stable—a solid foundation to build upon.

-No layers... upon layers... upon layers.
-No imposed templating system,
-no awkward, forced-upon-you ORM,
-no massive libraries that just add bloat—whether you actually use them or not (or external ones, which, in order to show that something is happening, undergo fundamental changes themselves)
-no sudden changes just because someone woke up on the wrong side of the bed,
-...and, consequently, no need for follow-up courses and books.

Given my current understanding, it has been refined to perfection!

Hello, I agree with chandresh. When I try to follow tutorials for other frameworks, I get lost because there are too many hidden steps. With Trongate, I can look at the plain PHP and understand what is happening, like in the code chandresh posted.

R-evo, I understand what you mean about frameworks changing and adding too many layers. It is hard to learn when things keep shifting like that. If I get an error here, it is usually just my code, not something hidden, which is much easier. Thanks.

Tina

sasin91
"If needed, Varnish might do the trick :) "

I’ve thought about that, too - like Wikipedia.
CloudFlare works for some, but I’m not a fan.

Vassil