The are some Questions to think about... I have worked with a lot of different technologies and wrote frameworks in different languages. I can tell you specific things but to me there's more of a question catalog to challenge your thoughts.

1. Who do you write it for?
2. What do you want to solve?
3. What are the constraints? Is it utility over speed? UX over flexibility is it to strike the balance between those?

those are the first questions because they should already define certain patterns.

For example maybe it's better to route in a module pattern?

@route('/my/path/:id');
function doSomething(app, request, response) {
 // do something
}

or is it in a hook system?

class ControllerPattern {
   classicAction(app, request, response)
}

function bootstrap() {
   const app = new App();
   app.register('/my/path/:id', ControllerPattern.classicAction)
}

or maybe it's better to use a PSR-4 approach ?

// class in folder src/Controller

class MySpecificController { 
    public anotherAction(app, request, response); 
}

// which maybe resolves /app/my-specific-controller to this endpoint
return resolve(uri);

We also can talk about DependencyInjection vs ServiceLocator. ..... hundreds of Questions :)

As a starting point:

• Should it be FP or OOP?
• how much code should be shareable between the client and the server?
• how is the code shared between?
• is there isomorphic rendering aka SSR that hooks up on the client
• how do you approach the basic problems of routing ?
• do you want an event dispatcher architecture?
• is it built async?
• is it built on streams?
• how do you define the templates?
• is there a specific DSL?
• is the view rendering done in a WCAG conform way?
• is the architecture data or event driven ?
• how do you separate the buisness-logic ?
• do you want a facade pattern ?
• do you want a strategy pattern ?

those are some points. Question of VDOM and Compositions can be solved on so many levels. If you for example use observers and register DOM nodes with atomic compontent wrappers to them in a state centric format you don't need the VDOM at all.

The VDOM is to avoid massive paint times by using batch updates .... just set the observers async and it will be a batch update. There are so many different ways to solve certain problems.

Think more about what you're going to make better from a developer perspective :) for example .... can I generate an app with your commandline tools ?

Maybe MVC is the right pattern ... maybe it's not ... it has a lot to do with how flexible your system should be :) MVC built as fascade is not flexible at all but it's rigid. On the other hand if the MVC is the result of a composition of Command patterns wrapped in observers it's very flexible.

I can ofc now start drawing UMLs etc but it's your fun journey not mine :) just think about your core philosophy first :)

On the other hand if you never done this before ... maybe just write something really straight forward

path -> router -> function
object -> render -> output

I can imagine loads of solutions :)