Starters Discussion: What kind of starters should be supported? Refactor current implementations?

[ryankopf]

This discussion issue is opened to address the recent proposals and conversations regarding the management and selection of starters in the Loco framework. The conversation has evolved around the renaming of "SaaS App" to "React App" and the potential inclusion of other frontend technologies like HTMX.

Starter Selection Criteria:
What should be our criteria for including new starters? How should we balance community demand with maintainability?
JavaScript Agnosticism:
How important is it for the Loco framework to be JavaScript-agnostic? Should this influence our decision on the default frontend technology?
Starter Management Approach:
Should we continue to include starters within the main project, or should we consider moving them to separate repositories?
Do we need starters at all?
Ruby on Rails has ONE generatable starting template, but you can configure it through various flags. Do we need to refactor loco's design to more fit this, or should we keep doing things our way, through git cloning a repo, since it's working? If we refactor it, is there a goal version or timeline?
Roadmap Alignment:
How do these proposed changes align with the overall roadmap of the Loco framework?

[ryankopf]

Starter Selection Criteria:
I think we should be willing to include any starters that the community is willing to put forth a volunteer to maintain. However I'm also agreeable if we pick a primary JavaScript that is NOT React. But see below.

JavaScript Agnosticism:
I think this is very important: people had a difficult time with Rails adopting Prototype, then jQuery, then Webpacker, then Turbo, then Hotwire. If we pick something, replacing it should be dead simple. That's why I support HTMX.

Starter Management Approach:
Instead of including ANY starters in the main project, I think we could develop a system that uses an index of our community's starter templates, and when each version is updated to "pass" all tests related to the latest version update, then that starter can be included in the index.

Should we continue to include starters within the main project, or should we consider moving them to separate repositories?
See above

Do we need starters at all?
I think we should plan to move to more of a generative design by version 1.0.0, but I see that at least 2 years off.

Roadmap Alignment:
I don't know the plans of the maintainers here.

[codeitlikemiley]

i do have some quick question , because loco is just fairly new to me about 30 mins exposure.
Does Logo uses cargo generate under the hood?

What ever your answer is , I think it would be easy to leverage cargo generate an additional cli command
e.g. loco ui
where in we can pass in --react or --vue or --htmx or --custom="path_to_git_url"
that way we can support later on other UI frameworks

I do have experience creating a template with cargo generate , i can possibly create this stuff , and make a PR ...
But the stuff that needs to be added on each template should have been discuss and approved by community or maintainer.

[mateusdeap]

I'll weigh in my 2 cents on this since I like the project and intend to use it myself.

Starter Selection Criteria:
I think we should be willing to include any starters that the community is willing to put forth a volunteer to maintain. However I'm also agreeable if we pick a primary JavaScript that is NOT React. But see below.

Agreed. I would say that, at least as far as the loco new command is concerned, it should necessarily have the option to say "I just want a plain old HTML+JS+CSS app with no other dependencies", wether it be an actual option or a --skip-react flag or something.

JavaScript Agnosticism:
I think this is very important: people had a difficult time with Rails adopting Prototype, then jQuery, then Webpacker, then Turbo, then Hotwire. If we pick something, replacing it should be dead simple. That's why I support HTMX.

Also agreed. But I even think the option below is even better.

Starter Management Approach:
Instead of including ANY starters in the main project, I think we could develop a system that uses an index of our community's starter templates, and when each version is updated to "pass" all tests related to the latest version update, then that starter can be included in the index.

Should we continue to include starters within the main project, or should we consider moving them to separate repositories?
See above

100% this.

Do we need starters at all?
I think we should plan to move to more of a generative design by version 1.0.0, but I see that at least 2 years off.

Roadmap Alignment:
I don't know the plans of the maintainers here.

I honestly have no opinions. I wouldn't say they're needed, but I think them good things to have. Or at least some way to generate about 3 options?