You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue encapsulates the current roadmap for Captain. Please comment with any thoughts on the overall roadmap. Please use individual v1/v2 issues for thoughts relevant to those stages.
What is Captain
Tailwind is a great framework, but often suffers in two main places: repetition at the onset of a project, and scaling pains when working in teams, on large projects or on long-lasting projects. Captain hopes to help with those problems.
Captain is a production-ready, ITCSS framework that utilises Tailwind for the utilities layer, and Tailwind's config for the design tokens. It then provides an inverted triangle of settings, tools, generics, elements, objects and extra utilities that work harmoniously with Tailwind to give structure and efficiency, resolving two of the potential problems with straight Tailwind.
The primary aim of Captain is on giving a structured, extensible framework to any project, no matter the size, complexity or visual design. It's concerned with reducing the burden of working with Tailwind with a team or a long-lasting project, as well as providing common objects and tools that often are the first to be abstracted (such as wrappers).
The de facto aim is for Captain to become a household name, alongside Tailwind, as a standardised approach to utility-first frameworks without the headaches that come at scale, or concurrent workload.
Overall Plan
For v1, we're going to produce something SCSS based, inline with what we're familiar with. This will allow us to rapidly prototype the tools, classes and workflows, as well as stress test our perception of what this framework should look like.
v2 will then look at whether or not we can remove the SCSS aspect, and move to straight PostCSS (and whether we even want to do that). That will include questions like, what audience are we targeting with this framework? What do we gain or lose with the move? What would the community like to see? Who is using the framework already?
We'll then produce a v2 build with the aim of meeting the requirements we find from those questions.
Contributions of ideas, discussions, bug reports or feature requests are welcome, in the form of issues or in pull requests. I encourage you to read our contributing guidelines first, before spending the time working on any code, so that we can ensure it has the highest chance of being merged.
This discussion was converted from issue #1 on December 19, 2020 13:12.
Heading
Bold
Italic
Quote
Code
Link
Numbered list
Unordered list
Task list
Attach files
Mention
Reference
Menu
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
This issue encapsulates the current roadmap for Captain. Please comment with any thoughts on the overall roadmap. Please use individual v1/v2 issues for thoughts relevant to those stages.
What is Captain
Tailwind is a great framework, but often suffers in two main places: repetition at the onset of a project, and scaling pains when working in teams, on large projects or on long-lasting projects. Captain hopes to help with those problems.
Captain is a production-ready, ITCSS framework that utilises Tailwind for the utilities layer, and Tailwind's config for the design tokens. It then provides an inverted triangle of settings, tools, generics, elements, objects and extra utilities that work harmoniously with Tailwind to give structure and efficiency, resolving two of the potential problems with straight Tailwind.
The primary aim of Captain is on giving a structured, extensible framework to any project, no matter the size, complexity or visual design. It's concerned with reducing the burden of working with Tailwind with a team or a long-lasting project, as well as providing common objects and tools that often are the first to be abstracted (such as wrappers).
The de facto aim is for Captain to become a household name, alongside Tailwind, as a standardised approach to utility-first frameworks without the headaches that come at scale, or concurrent workload.
Overall Plan
For v1, we're going to produce something SCSS based, inline with what we're familiar with. This will allow us to rapidly prototype the tools, classes and workflows, as well as stress test our perception of what this framework should look like.
v2 will then look at whether or not we can remove the SCSS aspect, and move to straight PostCSS (and whether we even want to do that). That will include questions like, what audience are we targeting with this framework? What do we gain or lose with the move? What would the community like to see? Who is using the framework already?
We'll then produce a v2 build with the aim of meeting the requirements we find from those questions.
Roadmap
Contributing
Contributions of ideas, discussions, bug reports or feature requests are welcome, in the form of issues or in pull requests. I encourage you to read our contributing guidelines first, before spending the time working on any code, so that we can ensure it has the highest chance of being merged.
Fair weather to ye.
Beta Was this translation helpful? Give feedback.
All reactions