What no meta-framework does.

The suite of meta frameworks Qwik, Astro, Fresh, Next, Solid Start, Svelte Kit all don't do this one thing, they don't have the ability to import a package that is encapsulated with route(s), client component(S), ssr data, and have it run within the framework.

Update Remix has a way to do programatic routers using the config file. With this simple feature you can do most of what I'm talking about. However may get tricky to share context across routes, like a database client for instance.

I fundamentally want to write applications in a different way then most of the file-based-routing meta-frameworks do. I want write small ui components with server actions and server loaded data all to be defined in one file, and have the ability to load that file in as a "plugin" to the framework. I want global contexts that allow plugins to access things like databases, env vars, and 3rd party api clients.

Meta frameworks all do one thing well they glue components / server code together with file based routing making projects have more structure then they previously did. It's easy to navigate a project set up with file based routing.

File based routing has one fatal flaw composability, it does not let you break the form.

I think express / oak did routing the right way on the server by allowing you to compose and nest full routers that could be npm modules. We've stepped away from this and it means we can't break our code down into sharable chunks.

Kent C. Dodds recently published an article called "Full Stack Components" a concept that is very similar to my idea of having all the endpoint code in one file. However remix doesn't allow for anything other then file based routing, meaning no programatic way to add in a Full Stack Component from NPM.

I see one of two futures either frameworks start to see the benefit of adding modularity to their codebases and add the ability for plugins / modules / url imports to contain routes, components, islands, database access, context, etc. or we come up with another way using Micro Frontends.

Why is this desirable?

Without the ability to import code things we write can't be shared, apps are two dimensional / single use. Why is it not easy to boilerplate simple site functionality? The problem is that everyone is to preoccupied with static site generators, front-end frameworks, and file-based-routing. You're missing the mark! The future is isolated server + client ui elements "full stack components" and this doesn't need sight of a bigger framework / system to run.

I essentially want wordpress plugins. Wordpress had an amazing ecosystem of plugins that could do anything to the system, and new database tables, new ui elements, new themes. I even dabbled in drupal too, so much control and very complicated to use.

I imagine a whole framework with clean supabase plugins, shopify plugins, google drive plugins, to allow for local caching of information from third party api's.

Fred the creator of astro even gave this a shoutout, even though it sadly isn't possible within astro.

const calendar = wireCalendarScheduler({
  google: {
    client: GOOGLE_CLIENT, 
    secret: GOOGLE_SECRET,
  },
  ...calendarSettings
})

// what might calendar return?

const { routes, headtags, styles, components } = calendar
const { Calendar } = components

Thinking about all the things that go into a "calendar scheduling" app like calendly.

1. Have access to google calendar
2. Create Webhook routes for calendar event updates
3. Have access to supabase
4. Create a database table in a service like supabase
5. Cache the calendar data locally supabase
6. Ship SSR Server Code
7. Ship interactive Client code (if any)

Deno even made a clone of calendly called meet-me built with fresh. It's a standalone thing, you need to boot an server to use it. Why can't this just be a thing I can add on to my custom fresh website?

• Alternative to Files / Folder Structure for using 3rd party islands / api endpoints #693

• Implement plugins for islands and routes (meet-me as plugin)

RSC and Next.js

I really thought that this new era of "server components" and Next.js was going to open the flood-gates for innovation. The issue is they haven't even figured out how to have "one-off" components that's backed by the server, let alone components coming from a package...

Random thought

Perhaps truly embracing "server components" as just functions could liberate us?

Prior Posts:

• Example Meta Framework Where Client + Server Code Self-Split Within the Same File
• What Are Micro-Frontends, What Problem Do They Solve?
• Declarative Server & Client Code to Enable Linting and Splitting.
• Federated Widgets: Frontend Components and Backend Endpoints in One Module

Comments

[Fatih Aygün]

Here's my plans for Rakkas plugins (which don't exist yet). Rakkas already has:

• Server hooks that can add middleware, inject backend routes or server-side context (like DB connections), and bunch of other things like injecting things into the document head or HTML stream.
• Client hooks can do things before hydration or inject contexts (that will be available in client-side data fetching hooks)
• Isomorphic hooks that can control isomorphic routes.

The router is not fully configurable yet, but it will be. And hooks will be able to add page routes too (backend-only routes are already possible).

A Rakkas plugin will be able to add any of these hooks. Also it will itself be a Vite plugin so it can add even more (virtual modules, special transforms etc.).

Most of Rakkas's features are implemented in terms of these abstractions. It's not super clean yet (there are some interdependencies) but it's close.

Add useServerSideQuery and useServerSideMutation (and the upcoming useFormMutation, like form actions but composable) to that mix and I think most of what you want will be achievable.