Frontend as part of Buffalo (and the CLI)

[paganotoni]

One of the key differentiators that give an advantage for Buffalo when comparing it to other Go frameworks is the frontend pipeline it ships with. Buffalo not only takes care of the backend part of building web applications but also provides a good foundation to integrate with your web tooling by using Webpack.

That said, and while it's one of the most valuable part of the Buffalo framework, maintaining the frontend tooling that Buffalo uses has been one of most time consuming tasks for the (tiny) development team that maintains the framework.

As we take a look towards Buffalo v1.0.0 I think is time to consider where do we stand in terms of maintaining and providing a holistic development experience within the framework. Taking into consideration our team size.

Some thoughts I've had include:

• Building node-less frontend tooling with ESbuild and import-maps (as Rails is doing now).
• Using something simpler on the CSS side to reduce the number of dependencies/tools we use.
• Providing the possibility to extend the CLI and build custom generators/builders.

cc @gobuffalo/all @fasmat @sio4

[sio4]

In my opinion, along with the consideration of the team size, we also need to consider which group of users are the target users of the buffalo. From my point of view and my experience, the fact that buffalo comes with a frontend pipeline (both Javascript library and CSS integration) is a big advantage for small teams (users) and small projects while the bigger team may have separated teams for backend and frontend. So if the buffalo is also targeting those small teams, I think they are a big portion of our users, keeping that differentiator could be an important direction of the buffalo framework.

In my opinion, separating that part as a CLI plugin could be the best solution. Also, this direction could provide a possibility that people (inside our team or outside contributors) create additional/alternative options. That plugin, let's say buffalo-plugin-webpack, could be also a kind of "unsupported" or "legacy" plugin within our team repositories and we could "officially" support a tiny plugin of a "simpler" one as a default frontend-support in the v1.0 era.

[hubyhuby]

The target audience is very important as Sio mention.
If I have a look at meteor.js and the nice ecosystem thay have.
With a much bigger team , they managed to maintain many packages in the core wich is wonderfull.
INMHO I believe for small team using buffalo their should be a decision made on a complete pipeline that may be used maintainted by core team.
This core implementation shall serve to other teams to do other implementations of the front.
For example having a Vue.js forntend (or CSS, react or whatever is prefered by the core team) is for me a must have.

If we think by the end , in 12 monthes we have Buffalo V1.0 :

1. There is no front end integration at all.
   Persons like me will go back to more integrated framework. Because I will not be able to start a complet working project in 1 month for POC.
   The onboarding experience is crucial : when I evaluated buffalo 4 years ago, it just worked out of the box and within 5 days I had something very intersting running. Which I couldn t do with any other Go framework. With other framework I was left wondering after trying them for 2 hours "I could never prototype my plateforme alone, the investement will be to big".

2. There is a frontend in whatever language:

• I can prototype quickely my product and start iterating in 1 month. (like I did 4 years ago)
• Another team doesn t like vue.js in the core frontedn package.... They decide not ti use buffalo for now....
• Yet another team 3 monthes later starts on working on a react implementation getting inspiration from the vuej.js core frontend.

Bottom line : I don t think there is a better front end those days. They are all Javascript. For a small team evaluating Buffalo - obviousely starting a green field project - they will be focused on "what can I get done in 2 monthes". If yiu have to learn vue because you know only react; you can do it in a week. Now if there is no react or vue in the framework you have 2 extra monthes of work to add which is a no go I supppose.
UPDATE:
Food for thoughts, the pagoda starter kit echo "Third-party middlewares" from January 2022 seems to be experiencing some interesting things :
https://github.com/mikestefanello/pagoda#frontend

[WSQN-bixal]

I agree that there is room to make this simpler and more modular.

For basic SCSS to CSS conversion, there are simpler solutions today than using Webpack. I'm not sure what Hugo uses for that, but it is a pretty streamlined toolset.

For Javascript, I think there are far too many flavors of framework to maintain this into the future. Ideally, a plugin system that allowed users to create their own compile and/or build chains would provide the most flexibility, without a huge maintenance burden. It would make sense, in that direction, to transition Webpack to an optional plugin that may be considered legacy.

Other frameworks, like Rails, can provide some good comparisons. I'm familiar with the Drupal community. The frontend "theme" layer that comes with core is pretty thin and aims to be modular. It does not try to include SCSS/JS compilation. The focus instead is on optimizing the scripts/assets on the page, and how they are loaded. For example, avoid redundancy, and provide some flexibility to specify whether scripts are included in page head or footer. That could be something to consider, especially given the popularity of component-based design in the front-end world.

[saurori]

I agree with previous comments. A modular approach would be beneficial given how frequently front end tooling changes. A sane or minimal default with the option to generate a different toolchain via the CLI / generators that operate via plugins or similar. Build commands could be specified in .buffalo.dev.yml for example.

[paganotoni]

Thanks, everybody for your comments here. I love to validate some of my assumptions for the new CLI architecture I'm working on and I'm happy to see that we're opening the conversation about important Buffalo topics. @sio4 recently asked me about the goals of the new CLI architecture, I've concentrated on doing progress but I think his question is excellent and it's worth an answer.

The overarching theme for this initiative is to provide a better development experience for the Buffalo users (developers). I think the CLI is a vital part of the developer experience and in that sense, I'm hoping to compact the default stack that buffalo ships with to concentrate on what developers actually use, I'm hoping this results in having more mature default generators leaving the door for customization on developer specifics. We will, by default, have a simpler stack, but have the default generators be more focused on providing an excellent experience for our users.

Some of the non-functional attributes of this new plugin architecture will be dependency reduction
and complete adoption of Go modules.