Why Another PHP Framework When Laravel and Symfony Exist?

This is probably the most obvious question anyone can ask about EvolvePHP 2.

Why build another PHP framework?

Laravel already exists.

Symfony already exists.

Both are mature, actively developed, widely used, and capable of building serious applications.

Laravel gives developers an enormous amount out of the box: dependency injection, routing, queues, testing, authentication packages, Artisan, Octane, monitoring tools and a large ecosystem around the framework. Its current documentation describes it as a progressive framework that can grow from beginner projects to applications using dependency injection, queues, real-time events and other advanced capabilities.

Symfony approaches things differently. It provides both a full framework and a large collection of independent PHP components. Its Runtime component can decouple application bootstrapping from global state and support different runtime environments, while its wider component ecosystem covers HTTP, messaging, caching, configuration, validation, processes and much more.

So if the goal of EvolvePHP 2 was simply:

Build routing, controllers, dependency injection, database access and authentication.

Then I would probably tell myself to stop.

Those problems have already been solved.

And they have been solved very well.

I am not trying to build a Laravel replacement

This is an important distinction for me.

I don't want the motivation behind EvolvePHP to become:

Laravel does X, so EvolvePHP must have X.

Or:

Symfony has Y, so EvolvePHP needs a better Y.

That becomes an endless race that a small open-source framework is unlikely to win.

Laravel has years of development behind it, a huge ecosystem and a developer experience that has been refined over a long period.

Symfony has an extremely mature component architecture and is used directly and indirectly across a large part of the PHP ecosystem.

Trying to compete with either framework simply by having more features would not make much sense.

Instead, I started asking a different question:

What problems do I want EvolvePHP to care about more deeply?

That question changed the direction of the project.

Framework choice is rarely the biggest problem years later

When starting a new application, choosing a framework feels like one of the biggest technical decisions.

A few years later, that may no longer be the biggest problem.

The bigger problems become things like:

• How do we upgrade this application safely?

• Why is everything coupled together?

• Can one part of the application scale separately?

• Can we introduce a new architecture without rewriting everything?

• Can we move to a persistent runtime safely?

• What happens to request-specific state when the same worker handles another request?

• How do we understand what is happening across the application?

• How do we modernize an old system without stopping business for a year?

Those questions interest me more.

EvolvePHP 2 is being designed around the idea that software will change, and the framework should help the application survive that change.

That is the space I want EvolvePHP to explore.

A framework built around architectural evolution

A typical business application may begin very simply.

Imagine this:

Application
├── Users
├── Billing
├── Orders
├── Notifications
└── Reporting

There is nothing wrong with deploying this as one application.

In fact, for many projects, that is exactly what I would prefer.

I don't think every new application needs to start with microservices, message brokers and complicated infrastructure.

But I would like those five areas to have meaningful boundaries.

If Reporting becomes expensive three years later, maybe it should run separately.

If Notifications grows dramatically, perhaps it eventually belongs in a worker.

If Orders becomes a capability maintained by another team, perhaps it eventually becomes independently deployable.

The important question is:

How much of the original application do we have to destroy to make that change?

I want EvolvePHP to make the answer:

As little as reasonably possible.

That is why modularity is not just a folder structure in the EvolvePHP 2 architecture.

Modules are intended to represent actual application capabilities with explicit dependencies and lifecycle rules.

The application can remain a modular monolith for as long as that architecture continues to make sense.

Only when there is a real reason to distribute something should the deployment architecture become more complicated.

I don't want developers choosing microservices because they are afraid of the future

Sometimes teams over-engineer a new system because they don't trust themselves to change it later.

They think:

We might need independent scaling in three years, so let us build ten services now.

That can introduce problems long before the benefits appear.

Now there are network calls.

Service discovery.

More deployments.

Distributed tracing.

Retries.

Timeouts.

Partial failures.

Data ownership questions.

More infrastructure.

More operational complexity.

All for an application that may currently have a few hundred users.

I would rather have an architecture where developers can say:

We can keep this simple today because we have a reasonable path to change it tomorrow.

That is one of the long-term ideas behind EvolvePHP 2.

Start modular.

Stay together while staying together makes sense.

Extract selectively when there is evidence that separation is useful.

But new applications are only half the story

There is another problem that matters to me because I have seen it repeatedly in real software projects.

Existing systems.

Some business applications have been running for ten or fifteen years.

They may not be beautiful.

They may contain outdated dependencies.

They may have architecture decisions nobody would make today.

But they work.

Customers depend on them.

Employees depend on them.

Money moves through them.

And somewhere inside those applications are thousands of lines of business rules that took years to discover.

The usual technical answer is easy:

Rewrite it.

The business answer is much harder.

A rewrite means rebuilding not only the code developers understand, but also all the strange business behavior that nobody remembered to document.

Then while the rewrite is happening, the business does not stop changing.

New requirements continue arriving.

New integrations are needed.

Regulations change.

Customers continue reporting problems.

The old system keeps moving while the new system tries to catch it.

That can become dangerous.

What if modernization didn't require adoption on day one?

This is where EvolvePHP's direction becomes more interesting to me.

I want developers to eventually be able to get value from EvolvePHP without first deciding to rebuild their application using EvolvePHP.

That is a very different adoption model.

Imagine a Laravel application.

Or Symfony.

Or CakePHP.

Or Yii.

Or CodeIgniter.

Or even a completely custom PHP system built ten years ago.

Instead of saying:

Move the application to EvolvePHP.

the first question could be:

What part of this application actually needs to change?

That thinking led to the architecture behind Evolve Bridge.

Conceptually:

Existing Application
        |
        |
   Evolve Bridge
        |
        |
 New Capability

The existing system remains responsible for what it already owns.

A new capability can begin on the modern side.

Over time, additional capabilities can move if there is a reason to move them.

There is no rule saying the original framework must disappear.

In fact, if Laravel continues doing something well, there may be no reason to replace that part at all.

That is important.

Coexistence instead of framework wars

Framework discussions sometimes become strangely competitive.

Laravel versus Symfony.

Symfony versus something else.

PHP versus Python.

Monolith versus microservices.

I don't think software architecture works that cleanly.

Real systems are messy.

A company might have:

Laravel application
        +
old PHP reporting system
        +
WordPress customer portal
        +
Python data service
        +
Node.js notification service

That isn't unusual.

The question becomes how those systems can evolve without creating unnecessary risk.

So I want EvolvePHP to be comfortable existing beside other frameworks.

A Bridge adapter should not mean:

Laravel is bad. Replace it.

It should mean:

Here is a defined boundary where Laravel and EvolvePHP can cooperate.

Symfony itself demonstrates the value of interoperability through its component model. Many Symfony components can be installed independently instead of requiring developers to adopt the complete Symfony framework.

I think PHP benefits when tools cooperate rather than expecting every project to become an all-or-nothing framework decision.

Persistent runtimes changed one of my assumptions

Another area where I want EvolvePHP to think differently is runtime safety.

Traditional PHP gives developers something very convenient.

A request starts.

PHP runs.

The response finishes.

The request state disappears.

That lifecycle protects developers from many mistakes.

But long-running PHP runtimes change the situation.

Laravel has Octane, which keeps an application in memory and serves requests through application servers such as FrankenPHP, Swoole and RoadRunner. Laravel also provides scoped service bindings specifically for cases such as Octane requests and queue-worker jobs.

Symfony's Runtime component similarly exists to separate application bootstrapping from global state and allow applications to work with different runtime environments.

So persistent PHP itself is certainly not something unique to EvolvePHP.

The difference is that I want EvolvePHP's architecture to assume from the foundation that process reuse is dangerous unless isolation can be demonstrated.

That has led to the idea of an execution.

An execution could eventually be:

HTTP request
Queue message
Scheduled job
CLI command
Worker task

Each one gets isolated execution state.

When the execution finishes, cleanup must happen.

If cleanup succeeds, the process may be safe to reuse.

If cleanup fails and EvolvePHP cannot prove that state from the previous execution has been removed, then the framework should fail closed.

The process should be marked for quarantine rather than quietly accepting the next execution and hoping everything is fine.

For me, this is not primarily a performance feature.

It is an isolation feature.

Why does that matter?

Imagine a worker accidentally retains:

currentUser = Customer A

Then Customer B's request arrives.

Or imagine:

currentTenant = Company A

surviving into work being performed for Company B.

Now a small state-management mistake has become a security problem.

The framework cannot prevent every application bug.

But it can make certain dangerous patterns more difficult and give itself explicit cleanup responsibilities.

That is the type of framework behavior I want EvolvePHP 2 to take seriously.

Observability should not be something we remember later

There is another problem I have seen in applications.

Everything works until it doesn't.

Then somebody asks:

Why is this request slow?

And suddenly nobody really knows.

Was it the database?

An external API?

A specific module?

A queue?

A cache miss?

Authentication?

Some unexpected event listener?

The information might exist somewhere, but the application was never designed to expose it cleanly.

EvolvePHP is therefore being designed with an instrumentation boundary from the beginning.

The direction currently separates two ideas:

Evolve Insight for developer-focused local diagnostics.

Evolve Observe for production telemetry and OpenTelemetry integration.

I don't want Evolve Observe to become another Datadog or Grafana.

Those systems already exist.

The framework's responsibility should be to produce meaningful, vendor-neutral telemetry that developers can send to the tools they choose.

Again, the difference is not that Laravel or Symfony cannot be observed.

They absolutely can.

The difference is that I want observability to be part of EvolvePHP's architectural contracts rather than something we discover we need after the framework is already designed.

Another framework doesn't need another ORM to justify itself

This is probably one of the biggest changes in how I think about the project.

Years ago, if you asked me what made a PHP framework different, I might have compared:

• routers,

• ORM features,

• templating,

• helpers,

• authentication,

• session management.

Those things still matter.

Developers need a productive experience.

EvolvePHP eventually needs good routing, commands, testing utilities, database integrations and all the normal things expected from a modern framework.

But I don't think those should be its identity.

The identity should be closer to:

How safely can this application change over the next ten years?

Can I understand it?

Can I modularize it?

Can I upgrade it?

Can I run it differently?

Can I observe it?

Can I modernize only part of it?

Can I replace one capability without replacing everything?

Can I keep useful parts of an existing framework?

Can I discover when my runtime is unsafe?

Those are the questions I want EvolvePHP to answer.

There will still be cases where Laravel is the better choice

I want to be clear about this too.

If someone wants to build a standard SaaS application quickly, Laravel may be the obvious choice.

Its ecosystem is huge.

Its developer experience is excellent.

It has solutions for authentication, queues, billing, search, broadcasting, monitoring, testing, deployment and many other common requirements. The current Laravel documentation reflects how broad that ecosystem has become.

Likewise, if a project needs mature reusable PHP components, deep enterprise architecture and an established component ecosystem, Symfony is extremely difficult to ignore.

EvolvePHP does not become more credible by pretending those strengths don't exist.

In fact, I think acknowledging them makes the purpose of EvolvePHP clearer.

The goal isn't:

Choose EvolvePHP because Laravel and Symfony failed.

The goal is:

Choose EvolvePHP when the problems EvolvePHP prioritizes match the problems you expect your system to face.

So why another PHP framework?

Because I think there is still room to explore a framework where change itself is one of the main design constraints.

A framework where a new project can begin as a modular monolith without committing to permanent monolithic deployment.

A framework where existing applications can adopt new capabilities incrementally.

A framework that is comfortable cooperating with Laravel, Symfony and legacy PHP instead of demanding immediate replacement.

A framework where request, job and worker isolation are designed into the execution model.

A framework where failed cleanup means something.

A framework where observability is considered while the architecture is being created.

And eventually, a framework that can help developers answer:

What will break if I modernize this application?

That is enough reason for me to explore the idea.

It may not be the framework everyone needs.

It shouldn't try to be.

If EvolvePHP becomes useful to developers building long-lived modular applications, or to businesses trying to modernize systems they cannot afford to rewrite, then it has a reason to exist.

Laravel does not need to lose for EvolvePHP to succeed.

Symfony does not need to lose either.

PHP gets stronger when developers have more good ideas to choose from.

And EvolvePHP 2 is my attempt to contribute another one:

Build for change. Modernize without rewriting everything.

EvolvePHP 2: A PHP Framework Built for Change

When I started rebuilding EvolvePHP, I knew one thing very early:

I did not want to build another PHP framework simply because I could.

PHP already has Laravel, Symfony, CakePHP, Yii and several other mature frameworks. They have large communities, years of development behind them, extensive documentation and ecosystems that EvolvePHP cannot realistically compete with by simply offering another router, ORM, service container or authentication system.

So the question I kept asking myself was:

Why should EvolvePHP 2 exist?

The answer I keep coming back to is change.

Software changes.

Businesses change.

Requirements change.

Teams change.

Infrastructure changes.

And sometimes the framework or architecture you chose five or ten years ago is no longer the architecture your application needs today.

That is where I want EvolvePHP 2 to focus.

Applications rarely remain what we originally designed

A lot of applications start small.

Maybe you are building a SaaS product with users, subscriptions, notifications and reports.

At the beginning, putting everything inside one application makes perfect sense.

You don't need twenty services.

You don't need Kubernetes.

You probably don't need a complicated event-driven architecture.

You need to ship.

But if the application succeeds, things start changing.

The reporting system becomes expensive to run.

Notifications begin processing millions of messages.

A certain part of the system needs to scale differently.

The business expands into another country.

Another development team takes ownership of one part of the application.

A third-party integration becomes critical.

Something that originally looked like this:

Application
├── Users
├── Billing
├── Orders
├── Notifications
└── Reports

may eventually need to become something different.

The problem is that many architectural decisions become very expensive to undo later.

EvolvePHP 2 is being designed around the idea that we should expect this change instead of pretending it will not happen.

Start with a modular monolith

I am not interested in encouraging developers to start every new application with microservices.

In many cases, I think that creates unnecessary complexity.

A new EvolvePHP application should be able to begin as a normal application deployed as one unit.

But internally, I want the application to encourage clear boundaries.

Instead of treating the whole application as one large collection of controllers, models and services, the system can be organised around capabilities:

Application
├── Identity
├── Billing
├── Orders
├── Notifications
└── Reporting

Each module should have a clear responsibility.

Its dependencies should be explicit.

Its contracts should be understandable.

The application can still be one deployable system.

That gives you the simplicity of a monolith without giving up every architectural boundary inside it.

Then, if the business reaches a point where Reporting needs to run separately, the goal is not to redesign the entire application just to make that possible.

The architecture should already give us somewhere to begin.

That is what I mean when I say EvolvePHP is being built for change.

I want deployment architecture to be able to evolve

One of the long-term goals behind the framework is that a module should not be unnecessarily tied to where it currently runs.

A module may begin embedded inside the application.

Later, that same business capability may need to run inside a worker.

Eventually it may need to become a separate service.

Conceptually:

Today

Application
├── Billing
├── Orders
└── Reporting

could become:

Later

Application
├── Billing
└── Orders

        |
        |
        v

Reporting Service

This does not mean moving a module remotely will magically require zero engineering work.

Distributed systems introduce networking, failure handling, latency, retries, idempotency, security and many other concerns.

Pretending otherwise would be misleading.

What I want EvolvePHP to do is reduce the amount of business architecture that must be thrown away when that transition happens.

The framework should help you create boundaries early enough that future change is possible.

Existing applications also need a path forward

The idea of building for change does not only apply to new applications.

There is another problem I care about just as much: existing PHP systems.

There are applications running today that were written many years ago and still make money for businesses.

Some are custom PHP applications.

Some use older versions of CodeIgniter, Laravel, Symfony, CakePHP, Yii or other frameworks.

Some were designed before containers, cloud deployment, persistent workers and modern observability were normal considerations.

The easy advice is:

Rewrite it.

The practical reality is very different.

A ten-year-old business application may contain years of business rules that nobody has documented properly.

It may have hundreds of database tables.

It may communicate with government systems, banks, payment providers or internal services.

Customers may depend on it every day.

A complete rewrite might take years, and the business still has to continue changing while the rewrite is happening.

So instead of making EvolvePHP 2 require an all-or-nothing migration, I am designing Evolve Bridge around incremental adoption.

The goal is to make something like this possible:

Existing Application
        |
        |
   Evolve Bridge
        |
        |
New Evolve Module

The existing application does not immediately disappear.

You modernise one capability.

Then another.

And another, if it makes sense.

Maybe the old application is eventually replaced completely.

Maybe it isn't.

The important part is that adopting EvolvePHP should not require the business to gamble everything on one massive rewrite.

Even EvolvePHP itself should not become a trap

There is another side to this.

If I say EvolvePHP helps developers escape architectural traps created by older systems, then EvolvePHP itself should not become another trap.

That means I have to think carefully about framework boundaries.

Application business logic should not need to know unnecessary details about framework internals.

Modules should not be able to depend on anything they want.

Plugins and application modules should not mean the same thing.

Package dependencies should remain directional.

Public contracts should be intentional.

These things may sound restrictive when you are building something quickly.

But years later, those boundaries are often what determine whether a system is easy or painful to change.

I learned some of this from EvolvePHP 1.

When you maintain software long enough, you start appreciating decisions that make tomorrow's work easier.

Runtime assumptions also change

PHP itself is changing.

Traditionally, PHP applications had a very convenient lifecycle:

Request starts
    ↓
Application runs
    ↓
Response returned
    ↓
Process state disappears

That model hides many mistakes.

If a developer accidentally stores request-specific information in static state, it often disappears at the end of the request anyway.

With persistent workers, that assumption changes.

The same process may handle another request.

Or another queue message.

Or another task.

State from one execution can accidentally survive into the next.

That becomes much more serious when the leaked information contains:

• the current user,

• tenant information,

• database transaction state,

• listeners,

• locale,

• authentication context,

• logging context,

• or other execution-specific data.

So EvolvePHP 2 does not treat persistent-worker safety as something that can simply be added later by putting the framework behind a fast server.

The framework is being designed around explicit service lifetimes and isolated executions.

At the foundational level, I currently think about services as:

Application
Execution
Transient

An application service can live for the application lifecycle.

An execution service belongs to one request, job, command or task.

A transient service can be created when needed.

More importantly, when an execution ends, the framework needs to be able to clean up that execution deterministically.

If cleanup fails and the framework cannot prove the process is safe for another execution, the correct response should not be:

Hopefully it is fine.

The process should be treated as unsafe for reuse.

This is the idea behind the quarantine model being developed in EvolvePHP 2.

HTTP is not the whole application

Another change in my thinking is that I don't want the entire framework architecture to assume that everything is an HTTP request.

Modern applications do much more than HTTP.

They process:

• web requests,

• queue messages,

• scheduled jobs,

• CLI commands,

• background worker tasks.

So internally, EvolvePHP is developing the broader concept of an execution.

An HTTP request is an execution.

A queue message is an execution.

A scheduled job is an execution.

A command is an execution.

They have different inputs and outputs, but they share important lifecycle concerns:

Execution starts
    ↓
Context created
    ↓
Application work
    ↓
Cleanup
    ↓
Isolation verified
    ↓
Execution ends

This gives the framework a more consistent foundation for different runtime environments without pretending those environments are identical.

Observability should be part of the architecture

Another thing that becomes important as applications grow is understanding what they are actually doing.

When a request becomes slow, I want developers to be able to answer:

• Which module handled it?

• What services were involved?

• How many database operations happened?

• Which external calls were made?

• Where was the time spent?

• What happened during cleanup?

• Did the execution end safely?

This is why EvolvePHP has two observability directions in its architecture.

Evolve Insight is intended for local and development diagnostics.

Evolve Observe is intended for production telemetry and OpenTelemetry integration.

They are different tools serving different environments, but both can eventually benefit from the same framework instrumentation.

Again, this is not about trying to rebuild Grafana, Datadog or an OpenTelemetry backend.

The framework should produce useful information and integrate with the tools that already exist.

Understanding change before making it

The modernization direction has also led to another idea I am increasingly interested in: EvolvePHP should eventually help developers understand an existing system before asking them to change it.

That is the thinking behind Evolve Audit and Evolve Doctor.

Audit is intended to answer questions such as:

What exactly am I dealing with?

It could eventually inspect areas like:

• PHP version risk,

• dependency health,

• framework lifecycle,

• global and static state,

• application coupling,

• possible module boundaries,

• persistent-runtime risks,

• modernization candidates.

Doctor has a different job:

Is this application correctly configured and safe for the environment I want to run it in?

Those tools are not the framework today; they are part of the direction being designed for later phases.

But they fit the same philosophy.

Before changing a system, understand it.

Before upgrading it, know what could break.

Before putting it inside a persistent runtime, determine whether its state is actually isolated.

This is why I say "built for change"

When I describe EvolvePHP 2 as a PHP framework built for change, I don't mean that every future architectural change will become automatic.

Software doesn't work that way.

There will still be difficult migrations.

There will still be bad architectural decisions.

There will still be systems that need major redesigns.

What I want to provide is a better starting position.

For a new application:

Start modular, without starting distributed.

For an existing application:

Modernise incrementally, without requiring a full rewrite.

For a growing application:

Extract capabilities when the business actually needs it.

For runtime changes:

Treat isolation and cleanup as architectural requirements.

For operations:

Make the system observable enough to understand what it is doing.

And for upgrades:

Reduce uncertainty before making the change.

That is the direction.

EvolvePHP 2 is still being built

I think it is important to say this clearly.

EvolvePHP 2 is under active development.

Some of what I have described here represents architecture that has already been defined and foundational work that is being implemented.

Other parts, particularly the broader modernization and adoption tooling, belong to later stages of the roadmap.

I would rather document the thinking openly than wait until everything is finished and pretend the final architecture appeared fully formed.

Some decisions may still improve as implementation provides evidence.

That is part of building software too.

EvolvePHP 1 evolved because I kept using it on real projects and learning from it.

EvolvePHP 2 is being approached more deliberately, but I still expect implementation, testing and real-world use to challenge some assumptions.

And when that happens, the framework should be willing to evolve.

After all, that is the entire point.

EvolvePHP 2 is not being built around the assumption that software stays the same.

It is being built around the reality that good software has to survive change.

Why I’m Rebuilding EvolvePHP: Lessons From a Framework I Built Years Ago

 

Back in early 2016, while working on several PHP projects, I didn’t realize I was building a framework.

At the time, I had already learned CodeIgniter and was proficient with WordPress and Joomla. Most of the applications I was working on were not simple websites; they were larger business and enterprise systems with recurring requirements such as user management, authentication, roles, access control, sessions, administrative interfaces, and other shared functionality.

As I moved from one project to another, I started noticing a pattern.

I was repeatedly rebuilding many of the same features.

User management.

Login and authentication.

ACL.

Roles and permissions.

Database access.

Routing.

Sessions.

Controllers.

Common utilities.

I wanted a better way to reuse those capabilities without copying an old application and removing everything I didn't need.

 

The idea started with modularity

CodeIgniter influenced how I thought about MVC and application structure, but Joomla had also exposed me to a different idea that I found very interesting: components and modular functionality.

I liked the idea of being able to build a feature independently and then plug it into another application when needed.

Instead of every new project starting like this:

New project
    ↓
Build authentication again
    ↓
Build roles again
    ↓
Build ACL again
    ↓
Build common infrastructure again

I wanted something closer to:

Application
    ├── Users
    ├── Authentication
    ├── ACL
    ├── Reporting
    └── Other reusable components

If another application needed one of those capabilities, I could reuse or adapt the component rather than starting from scratch.

So I began creating my own structure around the applications I was developing.

At that point, I wasn't really thinking:

"I am going to create a PHP framework."

I was simply trying to solve a problem I kept encountering in my daily development work.

Then I realized I had built a framework

After deploying one of the applications, I looked at the underlying code more carefully.

By then, I had already created many of the things we normally associate with a framework:

• Routing

• MVC structure

• Session management

• Database abstractions

• Controllers and models

• Reusable components

• Configuration management

• Authentication-related utilities

• ACL and permission handling

• Common application helpers

The application-specific code was sitting on top of a reusable foundation.

At that point it became obvious that what I had created was no longer just a collection of helper files.

It was the beginning of a framework.

That framework eventually became EvolvePHP.

EvolvePHP grew with the applications I built

I continued using the framework for other projects.

Whenever I encountered something missing, I added it.

Whenever I found myself repeating code between projects, I looked for a way to make that functionality reusable.

Whenever an application exposed a weakness in the framework, I improved the framework.

So EvolvePHP grew organically.

It wasn't designed in one sitting from a perfect architectural specification.

It evolved alongside real applications and real business requirements.

That experience was incredibly valuable.

Several applications I built with EvolvePHP are still running today, years after they were originally deployed.

For me, that matters more than whether the framework ever became widely adopted publicly.

It proved that the ideas behind it were useful enough to support real systems.

What EvolvePHP 1 taught me

Building EvolvePHP taught me far more than I expected when I started.

It forced me to understand PHP beyond simply using existing frameworks.

I had to think about questions such as:

• How should requests enter an application?

• How should routes be resolved?

• How should controllers be instantiated?

• How should reusable components communicate?

• How should authentication state be handled?

• How should permissions be represented?

• How should application configuration work?

• How should database access be structured?

• How much responsibility should a framework take from the application?

• Where should framework code end and business code begin?

It gave me practical experience with:

• PHP internals and application structure

• MVC architecture

• Reusable software design

• ACL and authorization systems

• Framework development

• System design

• Design patterns

• Component architecture

• Application lifecycle concerns

Some of the architectural decisions I made back then are decisions I would not make today.

But that is part of the value of the project.

You learn a lot when you have to live with your own architectural decisions for several years.

Why I am preserving EvolvePHP 1

When I decided to begin EvolvePHP 2, one question was whether I should simply transform the existing codebase into the new framework.

I decided against that.

EvolvePHP 1 represents a particular period in my development career and a particular era of PHP development.

There is value in preserving that history.

It shows where the project started.

It also gives me a reference point when designing EvolvePHP 2.

There may be ideas worth revisiting.

There may also be decisions that serve as useful reminders of what not to repeat.

And practically, preserving the existing version costs me very little.

So EvolvePHP 1 remains preserved rather than being overwritten by EvolvePHP 2.

Why EvolvePHP 2 is a redesign instead of an upgrade

A lot has changed since I last worked seriously on EvolvePHP 1.

PHP has changed significantly.

The ecosystem has changed.

The way applications are deployed has changed.

My own understanding of software architecture has changed.

EvolvePHP 1 was designed in an era where a typical PHP application was largely expected to handle one request, produce a response, and terminate.

Modern applications increasingly operate around:

• Containers

• Cloud infrastructure

• Persistent workers

• Queues

• Background jobs

• APIs

• Distributed systems

• Observability

• OpenTelemetry

• CI/CD

• Horizontal scaling

• Docker

• Kubernetes

• Long-running PHP runtimes

Trying to force all of that into the original EvolvePHP architecture would create more problems than it solves.

Some of the dependencies are outdated.

Some design decisions belong to an older PHP ecosystem.

And EvolvePHP 1 is much more comfortable around the PHP 7 generation than the environment I want EvolvePHP 2 to target.

So EvolvePHP 2 is not:

EvolvePHP 1
    +
new features

It is closer to:

Lessons from EvolvePHP 1
        +
14+ years of engineering experience
        +
modern PHP
        +
modern infrastructure
        +
new architectural principles
        ↓
EvolvePHP 2

That distinction is important.

The problem I want EvolvePHP 2 to solve

Another thing that has become clearer to me over the years is how difficult software modernization can be.

There are many PHP applications still running important businesses today.

Some were built with older frameworks.

Some are custom applications.

Some are based on versions of PHP that companies would like to move away from.

But rewriting a large production system from scratch is often unrealistic.

A company may have years of business logic inside an application.

Thousands of database records.

Integrations with other systems.

Customers actively using it.

Employees depending on it every day.

Telling that business:

"Rewrite everything."

is rarely useful advice.

That is one of the problems I want EvolvePHP 2 to explore more seriously.

What if a modern framework could help developers gradually improve an existing application?

Instead of:

Legacy System
      ↓
Complete Rewrite
      ↓
Modern System

the process could look more like:

Existing System
      │
      ├── Existing modules
      ├── Existing business logic
      │
      └── Evolve Bridge
              │
              ├── New capability
              ├── Modernized module
              └── New services

Modernization could happen incrementally.

One capability at a time.

Building for change

That thinking has started shaping the philosophy behind EvolvePHP 2.

The goal is not simply to build another framework with routing, controllers and dependency injection.

Those problems have already been solved extremely well by frameworks such as Laravel and Symfony.

The more interesting question is:

How do we design applications that are easier to change several years from now?

That means thinking about things such as:

• Modular application architecture

• Clear package boundaries

• Explicit dependency contracts

• Safe execution lifecycles

• Persistent-worker safety

• Plugin architecture

• Observability

• Incremental modernization

• Framework interoperability

• Service extraction

• Upgrade safety

A new application may start as one modular monolith.

Later, one module may need to scale independently.

An old application may gradually move functionality into modern modules.

A company may want to adopt modern PHP without immediately replacing everything that already works.

EvolvePHP 2 is being designed around those realities.

Doing it differently this time

There is another major difference between how I built the original framework and how I am approaching EvolvePHP 2.

EvolvePHP 1 grew mostly through implementation.

EvolvePHP 2 is starting with architecture.

Before implementing major framework features, I am defining the decisions that those features must follow.

That includes architecture RFCs covering areas such as:

• Framework vision and scope

• Package boundaries

• Versioning and compatibility

• Module and plugin lifecycle

• Execution scope and runtime reset

• Incremental modernization through Evolve Bridge

• Observability and OpenTelemetry

I am also applying a test-driven approach to the framework itself.

Instead of simply adding a feature because it appears to work, I want important framework behavior to have explicit tests and architectural rules around it.

The goal is to make accidental architectural drift harder.

Looking back before moving forward

EvolvePHP 1 was never perfect.

I wouldn't build it the same way today.

But I don't regret building it.

It taught me things that I probably would never have learned by only using other people's frameworks.

It forced me to understand what happens underneath the abstractions I normally depended on.

And most importantly, it gave me something real to learn from.

EvolvePHP 2 is therefore not an attempt to erase the original project.

It is the next step in its evolution.

The first version was built from the experience I had at the time.

The second version is being built from everything I have learned since.

And this time, the ambition is broader:

Build a PHP framework designed not only for creating applications, but for helping those applications evolve over time.

That is the journey I will be documenting as EvolvePHP 2 develops.

 

The Ultimate Laravel Setup for VS Code: Free Extensions to Rival PHPStorm

 

Hey everyone,

I want to put this out there for anyone looking for the ultimate Laravel setup in VS Code. These extensions enable you to experience a superb development integrated environment that can be compared to paid versions like PHPStorm.

 

If you're new to Laravel development or need a robust extension setup, these will give you the required effect. They're all free to use!

Here's the list:

• GitHub Copilot Chat - Microsoft
• Auto Close Tag - Jun Han
• Auto Complete Tag - Jun Han
• Better PHPUnit - Calebporizo
• Code Spell Checker - Street Side Software
• Container Tools - Microsoft
• Docker DX - Docker
• DotENV - Mikestead
• ESLint - Microsoft
• GitHub Copilot - GitHub
• Laravel - Laravel
• Laravel Artisan - Ryan Naddy
• Laravel Blade Formatter - Shuhei Hayashibara
• Laravel Blade Snippets - Winnie Lin
• Laravel Docs - Austen Cameron
• Laravel Intellisense - Mohamed Benhida
• Markdown Preview Enhanced - Yiyi Wang
• Markdownlint - David Anson
• PHP Intelephense - Intelephense
• PHP Namespace Resolver - Mehedi Hassan
• Prettier Code Formatter - Prettier
• Tailwind CSS Intellisense - Tailwind Labs
• Thunder Client - Thunder Client
• Vue - Vue

Let me know what you think and how it has helped you in the comments below!

#Laravel #VSCode #WebDevelopment #FreeTools

Creating a Modular Tic-Tac-Toe Game with TDD principle in Node.js

Building My Command-Line Tic-Tac-Toe Game

Hey everyone, welcome back to my blog!

If you’ve been following my posts, you know I love experimenting with new ideas and tools. This time, I decided to take on a fun challenge: building a command-line Tic-Tac-Toe game from scratch.

But before writing a single line of code, I had to think carefully about how to approach the project. I wanted the game to be robust, easy to maintain, and simple to extend with new features in the future.

---

Choosing the Right Approach

After a bit of research, I decided to go with the popular modular design approach. At first, I wasn’t even sure which programming language to use. So, I did what any developer would do—spent some time digging around on Google.

Eventually, I settled on Node.js because it’s well-suited for this kind of project. Plus, I decided the game would run exclusively on the command line—perfect for Linux users and advanced computer enthusiasts who appreciate terminal-based apps.

---

Using Test-Driven Development (TDD)

Once I had the language picked out, I set out to build the game using Test-Driven Development (TDD) principles.

I began by breaking down the project into phases:

1. List out features the game should support.
2. Write tests for each feature.
3. Make the code pass the tests one step at a time.

This approach kept the project organized and helped ensure everything worked as expected before moving on.

---

Check Out the Code

The full game code is available on my GitHub repository: josiahking/tic-tac-toe: A tic-tac-toe game

When you have the time, give it a try—and see if you can beat my AI opponent. I’ll warn you though: it’s pretty smart. You might need an IQ of 200+ to beat it consistently! 😄

If you have suggestions for improvement, I’d love to hear them. Even better, you can contribute to the project—maybe add multiplayer support over the network using real-time communication. Node.js would be perfect for that!

---

Wrapping Up

That’s all for this project!

I had a lot of fun building this game and learned quite a bit along the way. Hopefully, you enjoy playing it as much as I enjoyed creating it.

Until the next post, stay safe and keep coding! 🚀

My Code vs AI(Co-Pilot): I Spent About 75 Minutes Solving a Pyramid Problem on CodeSignal — Here's What I Learned

Today I went on CodeSignal looking for a fun coding challenge to sharpen my JavaScript skills. I came across an ASCII art problem that looked deceptively simple:

Can you generate a pyramid of asterisks with N rows?
Each level adds two more stars than the level above, centered with proper spacing.

Here's what it looks like for N = 5:

    *    
   ***   
  *****  
 ******* 
*********

And for N = 10? That’s what I set out to build.

⏳ Time Spent: 1 Hour 15 Minutes

I took this challenge seriously—no AI help. I wanted to test my problem-solving process.

Here’s my final code after 75 minutes:

const printChar = "*";

function buildPyramid(rows){
    var asteriskCount = rows * 2;
    var pyramid = [];
    var spaceCount = 0;
    for(i = 0; i < rows; i++){
        var asterisks = "";
        for(c = 0; c < (asteriskCount - 1); c++){
            asterisks += printChar;
        }
        pyramid.push(addSpace(asterisks, spaceCount));
        asteriskCount -= 2;
        spaceCount += 2;
    }
    
    return pyramid.reverse();
}

function addSpace(item, spaceCount){
    var before = "", after = "";
    const space = " ";
    for(i = 0; i < (spaceCount / 2); i++){
        before += space;
        after += space;
    }
    return before + item + after;
}

console.log(buildPyramid(10));

🤖 AI's Solution (Much Simpler)

Out of curiosity, I later asked Copilot/AI to solve it, and this was its version:

(Q)Can you write a program that generates this pyramid with a N value of 10 in JavaScript? 

function generatePyramid(N) {
  for (let i = 1; i <= N; i++) {
    const spaces = ' '.repeat(N - i);
    const stars = '*'.repeat(2 * i - 1);
    console.log(spaces + stars);
  }
}

generatePyramid(10);

💡 Takeaways

• Don't overthink simple problems: I went deep with logic and arrays, while the AI focused on core string operations.
• Learning happens in the process: Writing my own solution helped me practice nested loops, string manipulation, and thinking in reverse order.
• AI is a powerful reference, but it's also satisfying to struggle and arrive at your own solution.

If you’re learning JavaScript or just want to keep your brain sharp, try solving small visual problems like this. You’d be surprised how much you can learn from 10 rows of asterisks.

👨🏽‍💻 Have you solved something cool lately? Drop a link or comment below!

From Go Tour to Go by Example: My Real Journey Into Golang

Go Programming Update: From Go Tour to Go by Example

Hello again! How’s it going out there?

Here’s another update just for you.

✅ What’s Next After “A Tour of Go”?

After completing the Go Tour, I moved on to the next learning resource — Go by Example. It’s a practical, snippet-based guide that teaches Go through annotated code examples.

But before diving deep, I had to set up an IDE for actual development.

💻 Choosing an IDE: LiteIDE vs VSCode

There are many editors out there, but I narrowed it down to two major options:

• Go LiteIDE
• VS Code with Go extensions

I decided to start with Go LiteIDE to get a more native experience.

⚙️ Installing Go LiteIDE Wasn't So Easy

Installing LiteIDE wasn’t as straightforward as I expected. It took me several minutes and a few web searches to get it right.

I had to follow multiple setup steps, but eventually, it worked.
📌 Spoiler alert: I’ll be writing a separate post on how to install and set up LiteIDE for Go.

🧠 My Observations So Far

1. Go Strings Use Double Quotes Only

Unlike languages like JavaScript and Python, where both ' and " work, in Go, strings must be in double quotes (").
Single quotes (') are for runes, not strings.

2. if/else Syntax Must Be Properly Aligned

Go is strict about how you write if/else.
This will not work:

if 1 == 1 {
    // do something
}
else {
    // error: unexpected else
}

This is the correct way:

if 1 == 1 {
    // do something
} else {
    // now it's valid
}

3. Still No Section About Comments or String Concatenation

So far, I haven’t seen an example of how to:

• Add comments
• Concatenate strings

This suggests that Go expects some prior programming experience from its users. It’s not hand-holding like beginner-friendly languages.

4. Arrays vs Slices in Go

Here’s a simple example to show the difference:

array := [3]string{"j", "d", "d"}     // Array
slice := []string{"j", "d", "d"}      // Slice

An array has a fixed size specified inside the square brackets.
A slice doesn’t specify the size and is more flexible.
They look similar but behave differently.

🧵 Final Thoughts (For Today)

Go continues to be an outstanding language — clean, powerful, and strict.
It forces you to think like a low-level systems developer, even while giving you modern conveniences.

I’m still getting used to the syntax and structure, but every day I learn something new that surprises me.

Until the next update — keep learning, and stay curious. 👋🏽

Learning Go: My Honest Thoughts After Completing the Go Tour in 2 Days

Go Programming Update: Day 2 – The Weird, the Wonderful, and the “Why Though?”

Hello again, and thank you for taking a moment to read through.

I understand your time is valuable, so I’ll keep this brief going forward.

🧠 Yesterday Was... Interesting.

Yesterday was another opportunity to experience something brilliantly human: a programming language created by man — Go.

Now, here are a few things I’ve learned that made me pause and go, “Wait, what?”

"In Go, it's common to write methods that gracefully handle being called with a nil receiver."

But… look at this code:

package main

import "fmt"

type I interface {
    M()
}

type T struct {
    S string
}

func (t *T) M() {
    if t == nil {
        fmt.Println("<nil>")
        return
    }
    fmt.Println(t.S)
}

func main() {
    var i I

    var t *T
    t.S = ""
    i = t
    describe(i)
    i.M()

    i = &T{"hello"}
    describe(i)
    i.M()
}

func describe(i I) {
    fmt.Printf("(%v, %T)\n", i, i)
}

Output:

panic: runtime error: invalid memory address or nil pointer dereference

There's nothing “graceful” about that! 😅

But honestly, if I had seen this code a week ago, I could only understand maybe 30% of it. Go code feels more like advanced programming—almost in the league of low-level languages.

🧱 Constructors and NewSomething

Then I stumbled on this: image.NewRGBA.

That threw me off completely at first. Coming from PHP or JavaScript, I assumed New was part of the method name.

Turns out, New is a convention, not a keyword. The actual type is image.RGBA. Go uses NewTypeName() to return an initialized instance — like a constructor function.

🟰 nil Instead of null

Go doesn’t use null — it uses nil.

🚫 The Underscore _ Is Not Just a Placeholder

for _, v := range arr {
    // Do something with v only
}

_, ok := someFunc()

The underscore isn’t decorative — it literally means: “Ignore this.”

💡 Keep an Open Mind

If this is your first time learning Go, please… don’t get your hopes too high in the first few days.

You're going to say “Hmm, this is weird” more than once.

• No shorthand if statements — braces {} are required.
• No class keyword — methods are tied to types via receivers.
• No inheritance — Go favors composition.
• Go forces unused imports and variables to be removed — and that's a good thing.

🧬 Go Method Syntax

func (receiver Type) MethodName(arg ArgType) ReturnType {
    // ...
}

If you don’t have a receiver, it's just a function. With a receiver, it becomes a method.

🔠 Naming Conventions

Go uses PascalCase like this: ErrNegativeSqrt.

I’m used to camelCase and snake_case, so this is another learning curve.

🧠 Old Habits Die Hard

I still find myself:

• Using () in if statements
• Ending lines with ;
• Trying to destructure like it’s JavaScript 😅

But that’s okay — it’s part of the learning curve.

🎉 I Completed the Tour of Go!

In just 2 days, I finished the official Go Tour tutorials! 🎉

I’m proud of this progress. It’s a strong start, and I’m beginning to appreciate the beauty and simplicity Go aims for — even if it’s not always obvious at first.

💙 Onward and Deeper

Next, I’ll dive into more advanced Go concepts: goroutines, channels, error handling, map, struct, slice and possibly building an API.

Until my next update, stay safe and stay healthy.

Learning Go Programming as a Web Developer: My First Impressions and 4-Week Plan

So I Started Learning Go

I recently began learning the Go programming language after putting it off for years, considering it unimportant on my to-do list.

My First Look: A Tour of Go

Go is a simple and clean programming language that experienced web developers can pick up fairly quickly.

My goal is to learn Go in under 4 weeks with an aggressive approach.

As developers, many of us get bored when we spend too long learning a new language. We often abandon it and move on to something more exciting. That’s exactly why I’ve set a strict deadline—to stay focused and committed.

The Go syntax reminds me of TypeScript, Python, and maybe even Java—they share some similarities.

Go doesn't care about semicolons (;), and I see now why it's better suited for developers with some programming experience.

Go may not be the best choice for absolute beginners. It has a few advanced concepts that take time to grasp. But honestly, with discipline and determination, anyone can learn it.

One thing I find impressive is how Go handles imports. You can import packages that aren’t even on your server—pretty neat!

Oh yes, if you've used Java before, you’ll recognize the use of main. In Go, everything starts with:

package main

import "fmt"

func main() {
    fmt.Println("Hello, world!")
}

The way Go defines variables is also cool. You can use the var keyword, or a shorthand := for quick declarations.

Constants are declared using the const keyword, and you can define typed or untyped constants.

Go also has something called slices, which are like advanced arrays. To be honest, I initially found them a bit confusing. Why not just improve arrays? Why introduce slices? Maybe it’s just the tutorial that didn’t explain it well.

One thing I do appreciate is how Go handles loops. It's clean—no unnecessary complications. Just a simple for loop. I wish arrays were that straightforward too.

Unlike other languages like PHP, JavaScript, Node.js, Java, Kotlin, or TypeScript, Go keeps looping simple. There’s no for-in, foreach, while, do-while, or any of that mess. Just for. 😁

Final Thoughts

So far, Go isn’t as fast as I expected—but maybe I haven’t dug deep enough yet. I’m still exploring and plan to share more updates soon.

Stay tuned...

Simplest way to remove and uninstall react-native module or package

Hi guys, I recently ran into an issue while working with react-native. I installed a package for storage but the package didn't work as I had expected and it was causing significant error in the mobile app. I had to install a different package.
So, i went ahead to remove the previous package by doing normal npm uninstall --save
The above code only had effect in my package.json file, and caused the app to start showing white blank screen.
After several hours battling with the app and codes, I discovered that decided to try using react-native command rather than npm.
Show I did react-native uninstall which worked and everything began to work in the app again. The effect of this code is that it not only uninstall the packages the right way, it also unlinks them if they are linked.

Thank you for read, happy coding.


Follow me on twitter: http://www.twitter.com/_josiah_king Join me on Google+: https://www.plus.google.com/u/0/113541005774136102412/posts/p/pub?cfem=1