Is this project still maintained?

[nobrelli]

Is this project still maintained?

[fullgukbap]

I, too, would like to see a moderator's answer to this issue.

[alnwt]

Hi, @brendensoares.

TLDR: There are a number of things I'm going to work on, would you be willing to have them under the umbrella of @revel project, probably to be released later as a backward incompatible Revel v.2?

I'm about to start working on implementation of a framework that could provide a complete full-stack experience requiring as little boilerplate as possible. While still using the approach of Revel controllers with code generation, and extending it to views and models, I expect the framework command to cover not only back-end side but also produce production-grade web and mobile clients. That is, the ones that could be competitive at least with existing JS solutions. To be more concrete, some of the ideas I have in mind:

1. Structure the project the way proposed earlier and followed by some Revel offshoots/rewrites: a set of independent tools at the center (revel/revel), user app is a regular standard library compatible program but with Revel style magic controllers invocation; other packages, being easily replaceable in the user's app, could live in their own repositories (revel/*).
2. Use something akin to elm-ui to abstract HTML & CSS away leaving only common building blocks for all platforms. Consider if it would make sense to use Houdini API to implement a custom layout working similarly across platforms.
3. Use either LiveView Paradigm style (not perfect for offline first apps, I'm thinking the solution over since otherwise this is the approach I prefer) or htmx like approach, or consider some form of code generation that would produce assets of reasonable size and speed.
4. Come up with a solution for models and automatic app deployment. What I want to achieve, in particular, is a way to develop and deploy stuff seamlessly without worrying about migrations explicitly (a built-in mechanism for blue-green deployment could be provided as a module). Specifically, I consider two options:
   4.1. The traditional one. Make databases pluggable; so sqlite/mock can be used on dev/test, mysql/postgres on prod.
   4.2. A crazy one. Turn revel into a micro orchestrator (optimized for a specific set of use-cases) and use containers for running the same database system both on dev and prod machines.

Also to be addressed but no specific ideas yet:

1. It used to bother me that Hot Code Reload, which is basically just an automatic recompilation of the user app, makes the app forget its state. Sometimes that sucks. I don't know how to address that yet. But what I'd aspire to is Smalltalk / LISP Repl kind of experience.

Is it something that can be done under the umbrella of @revel project? If so, I'll work on its fork so it can be merged back later. If not, I'll start from scratch.