Composer, Packagist And PSR-4 - Where Does Trongate Stand?

There is sometimes a tendency within the PHP world to treat Composer, Packagist and PSR-4 as though they are inseparable parts of modern PHP development. They are not. They are three separate technologies and concepts that often work together, but they do different jobs. More importantly, there is no requirement for a PHP framework to build its core architecture around them.

Trongate takes a deliberately straightforward position.

Trongate works perfectly without Composer. It also works perfectly with it.

The same applies to PSR-4.

Trongate's core does not use PSR-4 autoloading. But if you want to use PSR-4 within your own code, or if a third-party package requires it, Trongate does not stand in your way.

That distinction is important, so let's take a closer look.

Composer, Packagist And PSR-4 Are Not The Same Thing

Before going any further, it is worth clearing up some terminology.

Composer is a dependency manager for PHP. It allows you to declare the packages your project requires, install them and manage their versions. Composer can also generate autoloading code for those packages.

Packagist is the main public package repository used by Composer. It provides a huge catalogue of PHP packages that can be installed through Composer.

PSR-4, meanwhile, is an autoloading standard. It describes how namespaces and class names can be mapped to directory and file structures so that PHP classes can be loaded automatically.

These technologies are commonly used together, but they are not one technology.

PSR-4 does not require Composer. Composer does not require Packagist. And a PHP framework does not have to use PSR-4 simply because Composer exists.

Trongate's Native Approach

Trongate was deliberately designed to keep its core lightweight and easy to understand.

There are no third-party dependencies required to run the framework. There is no vendor directory shipped with a standard Trongate installation. There is no requirement to install Composer before you can build an application.

Trongate has its own class-loading mechanism, and that is all the framework needs in order to load its own classes.

This is consistent with a much broader philosophy behind Trongate.

The framework should provide useful infrastructure without forcing an entire ecosystem upon the developer.

If you want to build a massive, commercial application with millions of lines of code using nothing more than Trongate and PHP, you can.

If you want to introduce third-party packages, you can do that too.

Nothing is being imposed upon you.

Using Composer With Trongate

Suppose, for example, that you want to generate PDF documents using dompdf.

There is no reason why you cannot use Composer to install it:

composer require dompdf/dompdf

Composer will install the package and generate its autoloading infrastructure.

You can then load Composer's autoloader from your application's entry point:

require_once APPPATH . 'vendor/autoload.php';

And your Trongate code can use the package in the normal way:

use Dompdf\Dompdf;

That's it.

Trongate continues to handle its own classes using its own class-loading system, while Composer handles the packages installed through Composer.

The two approaches can happily coexist.

What About PSR-4?

This brings us to PSR-4.

Trongate's own core architecture is not based upon PSR-4. Trongate's controllers, models and other framework components are loaded using the framework's own conventions.

That does not mean that PSR-4 cannot be used within a Trongate project.

If you install a Composer package which uses PSR-4, you can use it.

If you write your own library and decide that you want to organise it using namespaces and PSR-4 autoloading, you can do that too.

If you are developing a module that you intend to distribute as a Composer package, PSR-4 may make perfect sense.

Trongate doesn't need to adopt PSR-4 as its own class-loading architecture in order to allow developers to use it.

We're Not The Only Ones!

Within the world of modern PHP frameworks, Trongate's position on PSR-4 autoloading is unusual, but it is certainly not unique.

One of the most familiar examples of a project taking a similar approach is WordPress.

WordPress does not build its core architecture around PSR-4 autoloading. Yet this does not prevent WordPress developers from using PSR-4, Composer and Packagist within their own projects.

In fact, the official WordPress Developer Blog has published a detailed guide showing developers how to use namespaces, Composer and PSR-4 autoloading when developing WordPress plugins.

The WordPress guide to namespaces, Composer and PSR-4 provides a useful illustration of this distinction.

And that distinction is important.

There is a difference between building a framework around PSR-4 and allowing developers to use PSR-4 when it makes sense for their particular project.

Trongate takes the latter approach.

You don't have to use PSR-4. You don't have to use Composer. You don't have to use Packagist. But if you want to use them, Trongate isn't going to get in your way.

Why Doesn't Trongate Simply Use PSR-4?

This is a perfectly reasonable question. And the answer isn't simply, "Because we don't have to."

Trongate's class-loading system is deliberately different because it delivers some very significant benefits.

1. Exceptional Performance

Let's start with the most measurable benefit.

Trongate is exceptionally fast.

Our benchmark results demonstrate this clearly. Under the published test conditions, Trongate v2 has achieved 13,965 requests per second.

We encourage you to look at the benchmarks for yourself.

Performance is not the only consideration when choosing a framework, of course. But when a framework can deliver this level of throughput while remaining remarkably small and straightforward, it is difficult to ignore.

Trongate's lightweight architecture is a significant part of that story. The class-loading system is designed to do its job without introducing layers of infrastructure that the framework itself doesn't need.

2. Truly Modular Architecture

There is another benefit that is perhaps less obvious until you have worked with Trongate.

Trongate modules are genuinely self-contained.

A module can contain its own controllers, models, views and supporting files, including but not limited to JavaScript, CSS and images. There is no requirement for every class in your application to be organised into a huge, centrally managed dependency structure.

This has practical consequences.

When you work with a Trongate module, you know where its files are. You don't have to go hunting through a vast vendor directory to discover what is happening behind the scenes. PHP itself does not have to make a round trip through an external dependency-management structure simply to resolve a class that belongs to a Trongate application.

The result is a remarkably tangible form of modularity.

You can take a module, understand what it contains and understand how it works. Then, you can literally copy and paste it into any Trongate web application. It just works.

That's what we mean by truly modular.

And this is one of the reasons why Trongate's approach to class loading is so closely tied to the framework's wider philosophy. The goal isn't simply to make classes load. The goal is to make the architecture understandable.

To be clear: We're not just trying to make Trongate understandable to humans, but also to AI tools. This will be an increasingly important consideration as AI becomes an integral part of the modern software development process.

3. One Less Thing To Learn

There is a third benefit, and it is particularly important for people who are learning PHP.

Modern PHP developers are expected to understand namespaces, use statements, autoloading standards, dependency managers, package repositories and a growing collection of conventions that sit on top of the language itself.

Trongate doesn't require all of that.

Yes, we know what namespaces are.

Yes, we know how to use a use statement.

And if you want to use them in your Trongate application, you are perfectly free to do so.

But you don't have to.

That's an important distinction.

With Trongate, you can learn the framework without first having to learn an additional layer of PHP architecture. You can write a controller, create a model, build a view and get on with building your application.

Quite simply, it's one less thing that you have to learn!

For experienced developers, that may not sound like much. For somebody learning PHP or moving into commercial development, it can make an enormous difference.

And this is really the philosophy behind Trongate's approach.

We aren't avoiding PSR-4 because we don't understand it.

We're not avoiding it because we think it is bad.

We're avoiding making it a requirement because we have a class-loading system that is fast, genuinely modular and simple enough to understand without introducing another layer of complexity.

And - once again - if you happen to like namespaces, use statements and PSR-4, that's absolutely fine. Trongate isn't forcing you to change your coding style.

The Security Question

There is another question worth asking: how much third-party software do you actually want to trust?

Every dependency adds software that you did not write, maintainers that you do not control, and another link in your software supply chain. Composer can also pull in transitive dependencies - packages that your application depends upon without you having explicitly chosen them.

This isn't merely theoretical. In 2026, the PHP ecosystem has seen a number of serious supply-chain security incidents. Packagist itself has reported compromises involving packages such as laravel-lang and intercom/intercom-php, and has introduced additional security measures in response.

Read Packagist's own report on the 2026 supply-chain attacks.

Composer has also had vulnerabilities of its own. In July 2026, a vulnerability in Composer's handling of the bin field could allow a dependency to modify arbitrary files on the host system. Crucially, the vulnerable package did not have to be a direct dependency - it could be several levels down the dependency tree.

See the official Composer security advisory.

Composer 2.10 now includes native malware filtering, which is a useful response to these kinds of threats. But the underlying principle remains:

TOP TIP: You cannot have a compromised dependency if you don't have the dependency.

And Finally

YouTube is full of tutorials on how to work with Packagist. Many of those tutorials recommend only installing popular packages, presenting this as a legitimate security protocol.

As a matter of fact, somebody very high up in the PHP food chain is dodging a bullet today because I cannot find the direct link to the tutorial in which he tells developers that they will be safe so long as they stick to popular packages. It's an outrageous and downright irresponsible thing to say!

Just to state the obvious - popularity is not a security metric.

Not only does this kind of thinking demonstrate a worrying misunderstanding of software supply-chain security - it can also stifle innovation. It can make it harder for 'the little man' to come up with an idea, publish it and enjoy successful adoption.

Personally speaking, I have been at the receiving end of heavy criticism in the past for not being as enthusiastic about the PSR-4 / Composer / Packagist combination as many other framework makers. I suppose my personal stance on these matters is irrelevant, and rightly so. Nevertheless, I hope that I have helped to clarify Trongate's position - a position that is mature, carefully thought out and (I'm going to say the word!) conservative.

Quite simply, Trongate doesn't use that stuff, but you can if you want.

David Connelly