Long live to Hono! 🔥

[mcandeia]

This PR is part of our steps towards 2.x

Summary

This PR introduces a significant overhaul to the deco runtime, transitioning from a Fresh-specific framework to a more flexible and web-standard-first approach using Hono. This change enhances the platform's versatility, enabling compatibility with multiple front-end frameworks and broader deployment options, while maintaining seamless backward compatibility with existing Fresh sites.

Changes Overview

Before the PR:

• Framework Dependency: Depended solely on Fresh for routing.
• Platform Limitations: Tied to Deno-specific environment variables (Deno.*), restricting deployment to other runtime environments like Cloudflare Workers.
• Rendering: HTMX framework and renderToString function were built on Fresh.
• Configuration Management: Required providing routes and could not function solely for configuration management.
• Head Definition: Used Fresh’s Head function.
• Hot Module Replacement (HMR): Non-functional due to Fresh's internal issues.
• Publication Constraints: Could not be published on JavaScript registry(JSR) platforms.

After the PR:

• Framework Independence: Fresh is now just a plugin, with routing managed by a Hono server.
• Rendering: HTMX framework now has its own renderToString function that uses hono render.
• Head Definition: deco now has its own Head definition compatible with any framework.
• Configuration Management: deco can be used solely for configuration management, opening future use cases like feature flags using Deco class.
• Bindings: Introduces the ability to pass bindings when initializing deco, enhancing flexibility and allowing to compose with user's hono server.
• Publication Compatibility: Will be able to publish on JSR.
• Backward Compatibility: Fresh sites will be migrated automatically without any required changes.
• HMR: Fully functional when running with Hono.

Transition Plan

• Part 1 (Current PR):
  • Introduces Hono server for routing.
  • Establishes independent rendering and head definition.
  • Maintains Deno-specific environment variables (Deno.*), to be removed in Part 2.
• Part 2 (Future PR):
  • Complete removal of Deno-specific dependencies.

Benefits

1. Framework Agnostic: decoupling from Fresh allows usage with any front-end framework.
2. Enhanced Deployment Options: By removing Deno-specific dependencies, the platform can be deployed on various runtime environments, including Cloudflare Workers and potentially others.
3. Improved Configuration Management: deco can now be used purely for configuration management, paving the way for advanced use cases like feature flags.
4. Functional HMR: Ensures smoother development experience with fully operational HMR.
5. JSR Publication: Expands the potential reach by enabling publication on JSR platforms.

Migration Impact

• Fresh Sites: Migration is automatic with no required changes, ensuring a seamless transition for existing users.
• New Users: Can benefit immediately from the enhanced flexibility and deployment options.

The new fresh plugin code

Since hono exposes an universal fetch handler it can be used anywhere that follows webstandard, so the plugin is very simplified and it just a matter of defining a component that renders whatever is passed as a parameter and a /* route.

https://github.com/deco-cx/deco/blob/remove-fresh/runtime/fresh/plugin.tsx#L36

Using HTMX + Hono

In action at storefront,

dynamic imports has been used to allow minimal configuration as possible.

Breaking changes

• Also, with this change we have deprecated alienRelease feature which has not been used for a while since admin 2.x

[tlgimenes]

I feel like we have a third phase. The third phase encompass moving all features of htmx related framework into htmx and removing from deco.

Features like Async Rendering should be only on the htmx framework for instance. Loaders cache could be shared across frameworks.

[drawveloper]

Imagine doing this before TypeScript. And some people insist TS is useless. LOL!

Amazing work!

[igorbrasileiro]

@mcandeia what do you think about handling responder.headers changes that loaders can do at htmx renderFn? ctx.response.headers.set('key', 'val').

This would be useful to use early hints 103 headers

[mcandeia]

@mcandeia what do you think about handling responder.headers changes that loaders can do at htmx renderFn? ctx.response.headers.set('key', 'val').

This would be useful to use early hints 103 headers

AFAIK response.headers are used when building the final response