bridgetown
bridgetown copied to clipboard
bridgetownrb
Future: extract Tailwind support to a community maintained repo
With the rapid developments in new and future CSS and seeing how Tailwind has struggled mightily to maintain relevance in the face of it (the :has pseudo-class alone has the potential to revolutionize styling, as does cascade layers, new color functions, container queries, and so forth)—even going so far as to invent a new fake-CSS-language which is some of the nastiest mumbo-jumbo I've ever seen—I have come to the conclusion that Tailwind is a net negative for the web in general and should be avoided pretty much entirely except for very specific "rapid prototyping" use cases. I once wrote a viral article about the dangers of Tailwind, and rather than the new JIT making it more appealing, it gave TW creators license to give into their worst impulses. (Again, it boggles my mind that the bizarro arbitrary values language linked to from above ever made it a production release.)
I've also found supporting the Tailwind JIT to be difficult in Bridgetown, and while v1.1 will support it better than v1.0, I have zero interest in maintaining this, and it's increasingly hard to stomach promoting Tailwind on the Bridgetown website at all.
Thus I'm proposing to extract Tailwind support out to a separate community maintained repo for Bridgetown 2.0 when that's released end of 2022 or early 2023. By then, evergreen browsers should have universally shipped a whole slew of new CSS features which I'll be quite happy to promote. I also think focusing on Open Props, Shoelace, and other projects which utilize "Use the Platform™️" methodologies—rather than attempting to replace them—will service Bridgetown users much better. Heck, at this point I'd rather you kick it old-school and use Bootstrap and Sass, rather than use Tailwind which will isolate you from the world of modern/vanilla CSS.
I'm open to feedback that this is simply a terrible idea and that I'm using my bully-pulpit in an adverse way, but I feel fairly strongly about this point so it'll have to be pretty compelling feedback. 🙂 I'd also love to compile a list of articles/courses/etc which help people learn how to write vanilla CSS and how to create design systems and use web component libraries, so that we have a rich and attractive set of recommendations of what to use instead of Tailwind.
I'd like to see how you or people organize their CSS. Learning how/or writing vanilla CSS isn't the issue for me, but how to create order and organize. Do I list classes alphabetically, by components, different files? This seems to be Tailwind's biggest sell, "never write CSS again" because it's true that naming things is difficult. I'd like to read more about how others organize their CSS and why.
@adrianvalenz Yep, that's the sort of content I'd like to include/link to since it's such a common question.
Hi,
that's interesting. Reviewing the latest beta-release I had the impression that bridgetown would evolve with a strong focus on tailwind.
I could live with the decision, to focus on traditional css.frameworks like bulma and combine that with Shoelace-Components, which programmatically fit nicely with Bridgetown-Components.
Not sure if its wise to maintain tailwind-support in a separate Project.
If its so bad, just scratch the support and move forward.
Whats important to me: Implement a futureproof standard environment as base for a bridgetown style.
Then the unique add-ons (components, lit, ssr) can shine to fullfill the project's promise of a Progressive Web Framework
Can't we use this app? https://tailwindcss.com/blog/standalone-cli
If tailwind support is complicated, putting it in a separate package/plugin is a good idea. But giving it up completely seems like a bad idea to me. Despite of all its features tailwind is a very popular solution. And a complete rejection or a complicated installation seems to me to reduce the number of people who would like to work with bridgetown
@topofocus @work-leonid Thanks for your comments. I can't imagine simply dropping support altogether—as the title goes, the idea would be simply to to extract the bundled configuration out to a separate repo. The installation process would be nearly identical, no more complicated than at present.
Tailwind support was one of the main reasons I started using Bridgetown in the first place. Not having any path, or having a complicated path to setting up Tailwind would definitely be a step backwards. However it sounds completely fair to keep it as a separate package especially if the installation process would stay similar.
Extraction complete in v1.2. Folk can run this automation: https://github.com/bridgetownrb/tailwindcss-automation