What is our preferred front-end toolkit?

[stevepolitodesign]

There's precedent for Suspenders to configure a front-end toolkit. At one point, Suspenders shipped with Bourbon.

Now that we've release Roux, should Suspenders ship with that?

[stevepolitodesign]

There's also a case to be made that we should use Superglue. In that case, we'd have the whole React component ecosystem at our disposal.

[stevepolitodesign]

Or, maybe a simpler approach is Roux + Web Awesome

[pangolingo]

I feel like Roux would be a good default, with an option for bare (no styles).

And Superglue would be another option - we'd likely use Superglue with Roux.

Roux should ship with some good standards for flashes and forms.

[jaredlt]

I think the Roux feels like a sensible default. It's a boilerplate to enforce our best practices around CSS architecture. That makes sense to me.

Note: I documented one approach I used for adding Roux to a Rails app here thoughtbot/roux#12 (we'll need to decide if PostCSS is the bundling option we want)

I feel that Superglue should perhaps be its own discussion separate from Roux / CSS.

[vburzynski]

I feel like the choice of front-end should be an explicit choice determined by the architectural characteristics (non-functional requirements) of the application being built. The choice for how to approach the front-end is significantly impacted by how far you wish to delegate presentational responsibilities to the front-end (https://thoughtbot.com/blog/from-rails-to-javascript-a-spectrum-of-integration-options). When opting for a React frontend, for example, there are many approaches each with their own set of tradeoffs (https://thoughtbot.com/blog/how-to-integrate-react-rails). Superglue may not always fit every set of architectural characteristics.

If Roux and Superglue are desired sensible defaults (they seem to be), then it would be desirable to easily to opt out and not include them (and still benefit from Suspenders' templated setup). Or, said another way, Suspenders doesn't need to fit every set of architectural characteristics and it's be nice to skip setting up parts of the default boilerplate that might not apply to a particular application.

Perhaps another discussion altogether, the lib/templates/web.rb suggests that Suspenders assumes that you are building a Rails app that will have a dedicated front-end. It's often necessary, for example, to build an API-only Rails app. This might be the case when you want to serve a dedicated Node app to serve frontend services, and a dedicated Rails app for backend services. It can also apply to architecture choices like the Backends for Frontends pattern or Micro-Frontends pattern (amongst others).

I wonder if Suspenders could follow a progressive enhancement approach.

1. none — no frontend; a baseline API-only mode Rails app
2. classic — Rails app with a primarily static frontend (ERB with or without Hotwire)
3. dynamic — Rails app with a primarily highly-dynamic frontend (probably Superglue)

Divisions like these might allow for some flexibility without adding the complexity of too many variations