Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 10 months ago.
Improve this question
I wanted to develop a large-scale web application using Tailwind CSS.
Is Tailwind CSS suitable for large-scale web applications?
& Tailwind CSS worth investing time and money, or should I go with Vanilla CSS or another UI framework?
In my case, I have a design system and extensive database records, and I will need to use Animations, Drag & Drop ..etc. to build my SaaS product (Dashboard Builder).
I am looking forward to your guidance.
Just offering some counter points to these answers saying don't use Tailwind:
Setup properly (eg. using webpack/postCSS, not just pulling in a .css file from a CDN), you actually have a lot of control.
You can use a tailwind.config.js file to configure almost all aspects of the CSS - setup new colours, spacing, enable/disabled hover/focus effects etc. Once this file is setup correctly for your design system it is very easy to create a consistent application.
Tree shaking is built in by default - on running a production build your bundler will scan your code and strip out any classes which aren't used, resulting in the smallest possible file size.
It comes with a bunch of functions, mixins and helpers where you can create your own classes if need be - while keeping it consistent with default tailwind classes.
Another big one is that any future developers working on the project won't. have to learn your CSS system, they can read Tailwinds well-written documentation and know how to use it fairly quickly - if they don't already.
It's been tested by thousands of developers worldwide, so it covers a huge amount of edge-cases and browsers quirks you might miss if you're building your own system. A lot of developers think they can build a better system but that's not always the case.
This isn't to say it's right for your project - there's only really you who can weigh up whether having absolute control of your styles is worth losing the time saved using Tailwind - but a lot of the regularly thrown out negatives of Tailwind (file size/control/'need lots of classes') are not really issues if setup correctly.
I wouldn't recommend in your case. TailwindCSS should not be preferred if you have a design system at hand. Your code will get messy when you try to apply tailwind classes conditionally. You can work around this by using selector utility functions to decide which classes you'll use. I would prefer something like SCSS or a UI framework.
In my experience, Tailwind is useful for rapid development - for when the priority is speed rather than extreme customizability. There is also rather a learning curve to be proficient at creating good pages with tailwind (outside of copy-pasting existing components).
For a large-scale application in the space of a "dashboard builder", I'd think that there'll be lots of custom-designed components, so I personally wouldn't use Tailwind.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I am working on a large team project that has react-bootstrap 1.0.0 as well as bootstrap 4.3.1's css+js. Some developers prefer using react-bootstrap components, while others prefer styling elements with bootstrap classes. So we've ended up with two different styles of code:
<ListGroup>
<ListGroup.Item>
Cras justo odio
</ListGroup.Item>
vs.
<ul className="list-group">
<li className="list-group-item">
Cras justo odio
</li>
What obstacles might we encounter by continuing this way?
One issue I see might be upgrading react-bootstrap or bootstrap in the future. Since react-bootstrap depends on bootstrap, upgrading one would require upgrading the other at the same time. This means following two migration strategies at once.
The answer could vary depending on who you ask, but I would suspect a large majority to agree that it is a bad idea. There really is no such thing as "just being inconsistent." A lot of the reasons why this should be avoided boils down to the fact that something, somewhere is inconsistent. Here are a few examples:
Cross-Library Interactions - The biggest reason in my opinion is that Bootstrap is a DOM-manipulating JavaScript Framework, and React is a JavaScript UI Library. In order words, it's possible for Bootstrap to unexpected modify React components, resulting in unintended side effects. Imagine using jQuery to manipulate your React components. With Bootstrap, that's effectively what you're doing. React Bootstrap was built to replicate Bootstrap with the JS implementation was rebuilt from scratch, but reuses class names that can be targetted by the core BS JS.
Speed/Performance - By including both Bootstrap and React Bootstrap, you have two dependencies that serve the exact same purpose. Regardless of how small it may be, you can save a few extra bytes by dropping one of them.
Maintainability - If your application needs to be updated, you either need track down someone with that particular expertise or have someone learn that style anyway. Even if all your developers are familiar with both styles, it gets confusing having to switch between two different mindsets.
Expectability - Which parts of your application uses which style? How do you know? How would a developer know when they need to switch styles? Rather than have it be a coin toss on what to use when, it's easier for everyone if the entire application was consistent.
Hiring/Training - In any team, let alone a large one, people come and go. So should you ever lose a developer and need to replace them, this is an extra factor to consider, whether it be in the hiring process itself or (more likely) part of the training.
Your React-Bootstrap components and your JSX with Bootstrap classes will be styled by the same CSS file. RB doesn't include any of its own styles and requires you to use Bootstrap's CSS. No double migration necessary there. If you update or replace a stylesheet it will affect both of your code blocks.
React-Bootstrap also doesn't use Bootstrap's JavaScript, but its own reimplementation. That means attaching Bootstrap's JS shouldn't affect the function of RB components and that it would be necessary if you wanted to use Bootstrap's JavaScript behaviors in the second version of your code.
Info here:
https://react-bootstrap.github.io/getting-started/introduction/
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I've recently started on a large multi-year client project, and the first phase of front-end development is creating a pattern library to use across the project. I'm using Compass and Blueprint for my grid. The #include blueprint-grid mixin looks perfect for this project: it'll automatically generate semantic classnames (i.e., .span5) that the rest of the team can reuse across all pages.
However, the Compass documentation states:
Best practices discourage using this mixin, but it is provided to support legacy websites and to test the sass port against blueprint's example pages.
Why is that? Why is there a push to use non-semantic classes in modern grid systems? It seems less DRY to create a new CSS class for various page elements that will all share the same grid widths. For example:
.dashboard__chart {
#include column(6);
}
.dashboard__news {
#include column(6);
}
when I could simply just have a .span6 class to apply in my markup.
This may be situational: the non-semantic classes make sense if your entire project has a similar layout throughout (e.g., a news website or blog). However, this dashboard/reporting tool project has somewhat differing layouts throughout every page.
So back to the original question: why is it best practice not to use semantic classes, and what's the best way to avoid them?
it'll automatically generate semantic classnames (i.e., .span5)
I don't think that "span5" is a semantic name in that it doesn't describe the content at all but describes the layout in a fairly specific way.
Of course, the term "semantic" is thrown around a lot, but in its purest sense it should have little or nothing to do with presentation.
Reasons not to use names which describe presentation:
If the layout changes, the name is wrong
The layout may be adapted to for a different device for which it is wrong and/or meaningless.
The markup has less meaning to anyone reading it (i.e. your team)
Layouts can become brittle; changing one class that has been used in many different places and with many different meanings may break in some places in which it is used.
The biggest downside to generic classes like "span6" is that they are abused (I've seen this with Bootstrap, which has similar grid classes defined). "I need this element to span 2 columns...great! I'll just slap a 'span2' class on it and be done!"
This doesn't mean that you shouldn't look for reuse; but that reuse can come from class names that are related to the content (admittedly, this can take some effort) and through the use of mixins.
I've recently started on a large multi-year client project, and the
first phase of front-end development is creating a pattern library to
use across the project.
Most projects end up with exceptions/compromises for the sake of practicality, but you have the opportunity to start with a best-practices approach.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
Is there any best practices or very practical solutions to organizing mass amounts of css files.
Firstly, how should you use css within a page, should you have a external style sheet for each individual page, and a include css file for 'css reset' and all common elements. Say you have a included header how would you style it, would you have another external style sheet.
This just add up to mass amounts of style sheets, then secondly how to you organize them, do you have a folder for each external style sheet for each page?
Lastly, is there any standard naming conventions, for example if the file was an include would it be 'filename.inc.css' or if it was for a specific page would it be 'filename.pagename.css'
I object to the premise of the question...somewhat. The fact you have so many CSS files speaks to unnecessary bloat. You are probably coupling your styles to a specific context rather than to classes of content. Check out what they are doing at Yahoo for what I mean.
When your CSS is less-context specific, it becomes leaner. This then dramatically reduces the size of your files and mitigates your issue by curing the disease rather than treating the symptom.
So take the time to rethink your CSS to make sure it is only as big as it needs to be. Then organize your layout according just to whatever makes sense for you. After all, the layout of your CSS into multiple files is for your benefit only as a developer. The files will be minified and combined into a single file for the purposes of caching and performance.
And CSS files that are less likely to change because they have been designed for maximum immutability are ideal for caching.
Check http://smacss.com/
SMACSS (pronounced “smacks”) is more style guide than rigid framework.
... SMACSS
is a way to examine your design process and as a way to fit those
rigid frameworks into a flexible thought process. It is an attempt to
document a consistent approach to site development when using CSS.
My advise is always use a preprocessor, it makes the modularity easier. And use SMACSS because is the best way to do CSS especially when dealing with large styles. Check bootstrap repo for an example https://github.com/twbs/bootstrap/tree/master/less
If you have a stylesheet for each page, then every page will have to download a new file. That's definitely not good. You want to take advantage of caching (this goes for anything on the web, not just css) so it would be better to have a little more overhead on a larger css file that only needs to be downloaded once for the whole site. This is a subjective question, however, so there could be and probably are cases where it could be better to split them up - maybe if there were two distinct parts of a site that both needed a massive amount of css.
Generally, having multiple css files is for development only and they should be combined for performance reasons. For example, if I had a menu.css, header.css, etc, those should be in one file when deployed. One example where multiple css files is more acceptable is when they are lazy-loaded by a plugin system like Content Management Systems use. Because the content is so dynamic and the plugins are not tightly coupled to the CMS, it doesn't make sense for all of the css to be combined. That would make it pretty difficult to add and remove plugins.
Oh! In addition to combining all of the css, minification is also great!
There are also libraries like LESS and SASS that are useful in organizing code and cutting down on the amount you need to write.
The best practice would be to have one external style sheet for the entire website. If you can try to name your classes and id's uniquely where they need to be set apart so that there is no confusion between them all in your styling. This way you can maintain the entire site from one file.
If it is absolutely necessary for you to have different style sheets for each page then keep the majority of the styles you will need to render and load that are not page specific and occur on all of the pages to one main css file, then keep the remaining ones that are page specific to a minimum, this will keep your performance higher and save yourself a lot of headaches down the road.
The less technical debt you acquire the better.
Also if you do need multiple style sheets and there are page specific styles you will need that occur on several pages, I would recommend bundling and merging your style sheets to keep the downloads to a minimum and keep your performance higher.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I would wish to start a discussion to get some good ideas on how to organise style sheets in a very big project with a big team of developers working on it.
One possible approach here is to have just one sheet with all the styles organized using comments and regions, unfortunately even using a one-lined writing approach with tabs this sheet would become incredibly big and even having SVN commits and updates could become messier.
So we think it would be better to divide styles in different sheets. What we are not sure is how to organize this as we have different ideas for it.
One possible idea is to organize it for types: colors.css, fonts.css, forms.css, ...
Another idea is to group them by functionality/behaviour: navigator.css, menu.css, warnings.css, errors.css, ...
We could also organize them by page: login.css, contact.css, home.css, ...
Or even use a combination of those three ideas together.
Now what worries me is the fact that we would prefer not to add all the styles to every page, as not all the pages require all the styles and we are really worried about performance as our project is consumed by millions of users everyday. We of course compress it later on deploying but even so we think it's wiser to load only the required ones per page.
On being so, I am worried about other developers not loading styles in correct order, as having different sheets needed to be loaded depending on the page, or on the group of pages, they could get this messed up and on doing so cascading will fail (imagine they load menu.css before global.css, global would override some menu styles!!!).
Now we could just go for one sheet, we could just load all of them always, or we could use some idea we came to like using an alphabetical prefix to tell developers the loading order:
a_global.css
a_forms.css
b_region1.css
b_anotherregion.css
c_page.css
But that looks a bit horrible being honest. So now I was wondering if there is some type of popular css architecturing out there or at least some good ideas we could use for our project here.
Many Thanks!!
Go with a preprocessor, so you can organize source files however you want. (Our team uses LESS, because we've started with Twitter Bootsrap and it stuck). The compiled CSS file should not be under version control, each developer should compile their own version for testing. I'd recommend a grunt task to compile a minified version for production. I'd go with component-centric approach (forms, navs, grid, typography etc).
Using a preprocessor gives you the power of variables and mixins. You can keep files like variables.less and mixins.less in which you define common styles. So you when that blue color changes into slightly lighter blue you just change it in one file.
One large file including all the CSS you need should be fine as it is cached by browsers, so it minimizes HTTP requests to your serwver. Page-specific stylesheets are OK when a particular page has many uncommon elements.
Create a style guide html template which includes every common element you can think of. Headings, link colors, lists, photo thumbnails, form inputs, grid configurations, accordions etc. When you need to create a new component add it to this template, modify the stylesheets, see if it breaks any other elements and how it fits with the rest. Then use these snippets to create particular pages.
SASS or LESS
This will help you to keep your code easy managed. (variables, mixins etc)
Divide in multiple count of files.
Always a good idea. How to divide.
I suggest basically to divide them per page.
BUT -
Exclude general styles to seperate files which will be included everywhere.
By the way, one single file doesn't imply low performance. Are you sure that 10 requests for smaller sheets will be faster than one request for bigger file?
Additionally this files will be cached in web browser, so one file doesn't look like a bad idea.
Yesterday I asked a question here that got more momentum that what I thought it would. Here is the question link since it is related. I am interested now in the possibility of that using two frameworks together will be worst than using a JS framework and CSS from scratch or the other way around.
The question is clear, if you think there are arguments against using a CSS framework like Blueprint CSS please tell me what you think they are.
The main argument is that CSS is not really a programming language. A framework is meant to include reusable functions and data structures. CSS has neither of these constructs. A CSS "framework" is more akin to a template in a word processor. It provides ready-done design work, but it also imposes more constraints than starting from a blank slate.
Incidentally, this was what drove the development of Compass. It's similar to a CSS framework, but instead it uses the CSS metalanguage Sass, which does have functions and variables. Thus rather than (for example) having columns baked into the framework, you can write something like +columns(5) +column-margins(1em) and it will generate the appropriate CSS.
Browser compatibility? We're continually struggling to maintain IE6 support for the 1/3 of our clients that cannot or will not upgrade. Lots of CSS issues.
I use the YUI CSS libraries, but I'm not sure if that counts as a framework.
YUI handles the basics for fonts, layout (grids) and other formatting and makes it consistent across browsers and Operating Systems. It's under a free software license, also.
They also have a very useful interactive grid designer.