RFC: towards a single template master generation -- with options.

[jondot]

We'd like to move to a single master starter template, but have all major options available for users.

By evolution and iteration, we've learned that there are 3 types of starters:

1. Lightweight service (e.g. "Sinatra/Padrino" in Ruby world)
2. API (e.g. Rails API)
3. SaaS (e.g. Rails omakase)

Unlike Rails and Devise and their relationship, we've added User auth to API and SaaS by default. We think it's OK to leave it there, and have users just delete it when they don't need it.

We'd like to create a way for us to maintain just one starter, but to preserve the level of safety and testing we have today (which is great, we simply go into a starter project and test it out as a living thing).

Rails has rails-templates, and some custom way of specifying a starter -- which I'm not sure how maintainable it is for a small team of maintainers.

In addition we may need to introduce some unification or infrastructure at the Loco side to support better testing for various starter templates.

---

We'd like to get some feedback:

• Is this a good number of options? are there any other starter types we don't see? are there starter types we don't need?
• How would you expect to pick a starter? (open question)
• Would you like custom, social/community ways to generate starters? (Rails had a period of time that everyone were showcasing their own Rails template, powered by rails-templates)
• For each option, would you want to compile-out features? (e.g. more extensive use of Rust features), or it doesn't matter?

Any other feedback or ideas are welcome

[Sillyvan]

I like the 3 options. Personally i barely see use cases for the lightweight service but i dont think it hurts.
In terms of auth im not sure. Either having it in by default or having an additional CLI command to generate it seems good. Putting an option in loco new would just make things harder.

In terms of Ui i dont like the frontend option. I know Loco is supposed to be opinionated but just shipping some random react starter just dosent feel good to me and adds a ton of additional maintance if done correctly. I think a simple step by step guide to add a frontend in the Docs would be a better choice. This would also make the whole decision about "auto generated admin / login / etc" a lot easier. Love the options for HTML or HTMX

[nagashi]

Sillyvan makes a good point. One question I have, is React the only frontend option? If not, is the simple step by step guide to add a frontend to the docs applicable to other choices?

[Sillyvan]

I can spring in here. the answer is it depends

So first up your classic SPA aka React, Vue, Svelte etc do all work. As long as you can run a command which ends up building an html file + js + the rest. Basically like the good old days where you dropped ur build folder in some FTP. With Loco we can easily just serve the HTML file which does all the magic for us. No additional work required.

On the other hand if you want to use the so called "metaframeworks" so Next, Remix, Nuxt, SvelteKit etc it dosent make sense to have them inside ur Loco. Those frameworks will require Node on the server to render ur HTML for you etc. You CAN do this and its not bad! BUT its a standalone App which can talk with Loco over the network with a Rest API or what ever.

Back to your question. is the simple step by step guide to add a frontend to the docs applicable to other choices? Almost. You will always need a build command and a folder for loco to serve. How you do that can be a bit different but if you choose a frontend framework you are very likely to know how this works. Even with SvelteKit you can use a so called Adapter-Static which as the name implies gives you a static output. Realistically if one guide, lets say react is written up. You can probably add docs for another one in a matter of <10 minutes. Just have the correct output folder in ur config. and run npm run build. Biggest difference here is probably Vite vs Rsbuild because they have different config files.

I really dislike writing docs but if someone ends up making a good one i would happily help to add all the common frameworks myself

Maybe we could even get away with just showing the user to edit their vite/rspack config and choosing the build folder to be /frontend

[nagashi]

The codebase should be as lean as possible, which puts the weight on the document. Sillyvan, like you, I find coding much more fun than documenting. What does make a good document to you, one that will provide a rich user experience? I think it should be easy for newbies to understand, while at the same time informative for those who are more technical. Thoughts?

[Sillyvan]

In my opinion a "newbie" should just stick to the templating engine (server assets) if you dont know how a frontend framework works, you will end up a lot slower.

And the ones that do know how to use it will not struggle if they know that loco just serves their static output.

[isaacdonaldson]

My vote is to make Tera and server-side rendering the default and then have guides in the docs on adding in client-side assets.

In regards to keeping one starter, we could keep a lean starter that has data api routes, rendered views, mailer, and a singular model (as an example?). Adding in Auth, Tasks, Workers, and other things could be done on the CLI though an AuthGenerator, WorkerGenerator, and so on. This does have the downside of having to maintain the generators (which could be tough) but could allow for having a single starter template.