Trongate has been designed to work beautifully with Packagist. Within the 'engine' directory, there's a constructor specifically designed to handle packages from Packagist. Here's the code:



Guess what?

I hate it.

I hate the fact that every single Trongate request has to go through an IF statement to accommodate what I consider to be a fundamentally broken package manager. Just think about that for a moment: Every. Single. Request.

And what have we gained from this? Where's the great conference speech from the PHP Establishment, thanking us for slowing our framework down to accommodate their mess? Where's the article? Or, how about just a mention or a forum or something. Have you seen it? Has anyone seen it? Neither have I.

Trongate's accommodations for Packagist are entirely thankless. It's a speed bump that we never asked for. Nobody asked for it. Nobody thanked us for including it. Nobody really wants it. Of course, just to state the obvious, nobody needs it.

This, my friends, is a classic example of a situation where my own personal coding philosophy differs from the philosophy currently used in the Trongate framework. To be clear, the framework’s current stance on Packagist is this:



My personal philosophy is more like this:



I've been thinking about Packagist a lot recently. Nothing about the "Packagist way" of doing things aligns with what Trongate stands for. Many developers only tolerate it because it’s an industry norm and, until now, there has been no viable alternative.

I think change is in the air. If you're interested in reading more about this, I hope you'll enjoy my latest essay: "Packagist is on Death Row."

URL: https://trongate.io/essays/packagist-is-on-death-row

So, I have a proposal for you and two questions.

PROPOSAL: I think Trongate should remove the Packagist IF statement. We don't need it. It just slows the framework down. In its place, we could put something in the docs for people who are determined to use Packagist. They'll be fine.

QUESTION #1: Do you agree with this proposal?

QUESTION #2: What are your thoughts on Packagist, overall?

Just to be clear: You don't have to agree with me about anything. I'm just trying to open up an honest discussion and I'm really interested to hear your thoughts.

DC

Q1: absolutely fine, i don't see any use for it in the first place and it may inadvertently lead to issues as a result of a package.
I think for the most part, if you use composer it's better closely adjacent to the consuming module. e.g. openspout/openspout then it's no further than in the module root and in the controller that needs it.
Q2: Mixed, prefer to only use it if i actually need it. More moving parts = more potential headache.

Hello DC,

Answer to question #1:
Yes, I completely agree! Trongate does not need to conform to Packagist in any shape or form. There are plenty of other frameworks that do that.

Answer to question #2:
As I have mentioned before in one of the videos the moment you introduce Composer into your stack, your app gets a VERY significant performance hit. At that point, even a blazingly fast framework like Trongate can sink to the level of "normal" PHP frameworks in terms of requests handled per second.

Performance hit is one factor. The other one is size. Trongate weighs in at about 0.5 MB unzipped and ready to go. Adding just a few dependencies for example in order to send emails with a third-party service can increase your base app size by 10 times! Think about it. It's complete nonsense!

The last factor is technical debt originating from heavy complexity. By accepting to carry that huge baggage of dependencies with thousands of lines of code, you introduce new layers of abstraction, complexity, security and maintainability uncertainties down the line. Is it worth it? I don't think so.

In my opinion, Trongate shouldn't be afraid to make such moves. I used to think Trongate was a revolution. But the way I see it now is more like being a new branch in the natural evolution of PHP. Which branch survives? The old one or the new one? Time will tell. But I have a feeling this is the more viable one.

Thank you. I love it.

We have a massive upgrade right around the corner. Maybe this could be a good time to do this.

I read Simon's suggestion about the CSS thing. I know it's off topic but my concern is that it involves adding more code. The 'validacious' upgrade took (a group of us) several weeks to build. We did all of this with the goal of potentially gaining 3% on the benchmarks. My friends, we are fighting for every thousandth of a second! The idea of adding yet more code is something of a downer. Even though it's a CSS file, the fact is - people doing the benchmarks tests will likely just record the speed of the default homepage. They won't care about what files are being loaded. So, I do have a few reservations about that CSS addition. Furthermore, Trongate CSS was never designed to compete against (something like) Bootstrap or Tailwind. It was just for fast prototyping. Forgive me for going off - topic. It's probably best if I talk with Simon privately about that. I respect his opinion enormously and whenever I disagree with him I usually end up looking like an idiot. So, if you're reading - Simon - let's have a conversation about that.

The reason I bring it up is to contrast it with what we're talking about here. This is different. Instead of adding more code, we're talking about removing code. That's totally different. The business of removing code is a beautiful concept. I'm all in for it.

Anyway, I really appreciate your feedback and I do hope that others will chip in.

DC

Just to add my feather to the scale:
Q1: Good idea; just purge it. Good riddance!
Q2: Never used it, never had the need. Did not even realise this handler was in the code.
Just my opinion that I advise to not take too serious.
And regarding the light/dark CSS addition Simon suggested: while I am in awe of his knowledge and creativity, I do not think I will ever use it because I always regarded Trongate CSS as a (excuse me) quick-and-dirty Stylesheet for the designphase and the backend. For the clientside I prefer a chosen CSS that fits most for the job at hand - if I can, I preferably turn to a semantic-HTML CSS like picoCSS (sorry for cursing in church)

Thank you. And just to add a heads up - the 'validacious' upgrade will be out soon. After that happens, it'll be super easy to modify Trongate so that it works with any CSS library of your choosing. If it helps, I can post some tutorials - showing you how that works.

You'll have complete control over things like; how buttons get rendered and so on. All of this you'll be able to change without modifying the 'engine' directory. A huge step forward!

So, here we are, on the verge of throwing open the doors to other CSS libraries and... oh wait ...we're stepping backwards and making Trongate CSS bigger.

koolmees is right - Trongate CSS is just for fast prototyping. At least, that's what I was thinking when I wrote it. If somebody wants to build an entire site around it then that's cool. However, we're already competing against the entire PHP establishment, with the main framework. If we now compete against every other CSS library in the world, I think we'll lose.

There are really three questions at stake here:

1). What exactly is the purpose of Trongate CSS? Is it to be the best CSS library in the world?

2). If we actively discourage people from using third-party CSS libraries like Tailwind and Bootstrap, will that make Trongate a better and more attractive framework for other developers, or will it deter developers from using it?

3). And finally, there's an AI angle to this - isn't there? Let's assume we just keep Trongate CSS as a simple prototyping CSS library but we extend open arms to all the other CSS libraries. From an extremist "native programmer" perspective it's a bad idea because most of the other CSS frameworks are bloated and frequently rewritten. So, I can understand why a purist would say "screw the other libraries". However, it's easy for me to image a situation where somebody is working with an AI tool and they say (something like) "Build me a landing page using Tailwind". Even though I'm no fan of Tailwind, I assume that an AI tool would be able to work with that far better than with Trongate CSS.

I'm trying to move the conversation away from "to pull or not to pull". I think it's more a conversation about, "What exactly are we trying to achieve here?".

Oh dear! I just come to realise I might have been using Trongate all wrong all those years.
My interpretation has been that the function of Trongate was (and is) to handle the routing, to handle all the database related tasks, to organise the queried data into the object and shove it into the view file. The view file, on the other hand, is mostly HTML (with tags that I like, so using <dialog> and <article> for modals with pico) in combination with a made-from-scratch template that binds the css and js of my liking. For me the HTML-tags in my HTML and the included <style>s and <script>s in my template are no bother for Trongate. I always felt as if Trongate could not care less about what is inside the <head> of my template-file.
I may not be the sharpes knive in the kitchendrawer, but how would the stylesheet file I load in my template influence the speed of the Trongate framework?
Disclaimer: I am neither a native English speaker nor a native PHP speaker.

I think there are a few different concerns getting mixed together here, so it’s probably worth separating them out.

On the Packagist side, I’m not convinced the IF statement is where the real cost is. A single "strpos()" check per request is effectively negligible in the context of a full request lifecycle. If we’re chasing performance, there are much larger gains to be found elsewhere. Removing that line may feel cleaner philosophically, but I doubt it produces any measurable improvement in real-world scenarios.

The more important distinction, in my view, is that Packagist support in Trongate is optional, not imposed. Nothing in the framework forces Composer usage. The current approach simply leaves the door open for developers who need it. Removing that path doesn’t really make the framework faster in practice, but it does make it more closed and less interoperable.

There’s also a broader ecosystem angle. Like it or not, a large portion of PHP tooling, tutorials, and increasingly AI-assisted workflows assume Composer. Supporting that pathway lowers friction for adoption and experimentation. Removing it risks isolating Trongate from the wider PHP ecosystem, which could work against long-term uptake.

On the flip side, I do understand the purist position. There’s a strong case for keeping things lean, minimising dependencies, and avoiding unnecessary abstraction. With AI in the mix, it’s becoming more viable to build smaller, purpose-specific solutions rather than pulling in large packages. However, that doesn’t eliminate risk, it shifts it. When you replace a dependency, you take on responsibility for its maintenance, testing, and security surface yourself.

So to me, this isn’t really a question of “Packagist good or bad”, but where you want that responsibility to sit on a per-project basis. Keeping support optional strikes a sensible balance between convenience and control.

On the CSS point briefly, I think there may be a misconception. The choice or size of a CSS library has no impact on PHP execution speed itself. It only affects what the browser loads after the response is sent. So it probably shouldn’t be weighed in the same category as core request handling or framework performance.

I’m all for keeping Trongate lean and intentional. I just think we should be careful not to optimise around ideology if the practical gains are effectively zero, especially if it comes at the cost of flexibility.

I’m going to be direct.

I think there have been some good points made in this thread, particularly around Packagist and flexibility. I’m happy to move forward with the general direction being suggested here.

However, this discussion has highlighted something more important.

We need to be much clearer about what Trongate is trying to be.

Trongate is not trying to grow by adding features. It is trying to improve by removing complexity and staying lean. That is the core philosophy.

That philosophy has to take priority going forward.

So to be clear - contributions that add layers, abstractions, or additional code to the core framework are unlikely to be accepted, even if they are well built and useful in isolation.

That is not a criticism of the work. It is about maintaining a consistent direction.

If something does not make the framework simpler, smaller, or more efficient at its core, it probably belongs outside the core - as a module, extension, or optional add-on.

So, in this instance I will go with what is being suggested. However, going forward, the bar for adding code to the core framework will be extremely high. In most cases, additions will not be accepted unless they clearly reduce complexity or improve performance in a meaningful way.

One practical step I would like to take from this discussion is to make our direction clearer on GitHub. I am thinking of putting together a short README section that explains how pull requests are evaluated, particularly the focus on keeping the core lean and avoiding unnecessary additions.

If anyone would like to help shape that in a clear and concise way, I would welcome the input.

The goal is not to restrict contribution, but to make sure everyone understands the direction before investing time in a pull request.

As always, I appreciate the thought and effort people are putting into this.

I like straight talk. It's the only way to move things forward. I think the direction has been clear ever since Trongate v2 was released. The official documentation says it best:

What does that tell us? Should Trongate sacrifice anything for "flexibility" or Packagist compatibility? How many people have actually expressed gratitude for a constructor that plays well with Packagist versus those who are grateful for a framework that finally picks a side and doesn't apologize for it?

I think most of us prefer the latter. It's human nature to explore new ways to expand, but the core direction is solid. I'm certain you and DaFa are making the right choices, and I fully respect your decisions. You guys are the real visionaries of this industry. Please keep rocking!