It's pretty awesome how they're using it actually. They completely rebuilt Sales Cloud with this new UI. I'm hoping it makes using SF more bearable... https://developer.salesforce.com/trailhead/lex_migration_whatsnew/lex_migration_whatsnew_nav_setup

http://salesforce.com/lightning

This is a problem for text editors to solve. Browsers love this approach and it makes a ton of sense from a development perspective too. We shouldn't compromise on output just because it looks/feels clumsy to work with.

It's definitely a different way of thinking about how your design works. It's a system so there should be a decoupling of the class from a specific page element which will seem weird to someone who is not thinking of the design as a collection of modular components.

I wouldn't recommend it for smaller projects, but removing the design complexity from the CSS and managing it through classes in your views makes a world of difference in large, complex projects. It's an amazing feeling being able to drop in a collection of classes into a view and performing all your design in the view rather than trying to do the same within your CSS architecture that has a tendency to become easily bloated and disorganized.

I think it's first-and-primary focus is not for others to build web apps with it, but for Salesforce’s team to build and extend its sites/apps with. If the team can adopt and learn to use this system, it's a huge win—everyone understands and uses the same design language.

Building a system like this for an environment where you potentially have a few dozen to hundreds of different people making code changes has to be crazy difficult and a monster—I can see the reasoning and argue for classes that accomplish specific things. The fewer the dependencies, the less room for error when extending the system and less likely that the changes will negatively impact the hundreds of use-cases.

It does feel odd when you are looking through someone else's code like this because of how bloated and clunky it looks initially, and they don't seem to explain their approach anywhere. But if you can get past the initial appearance and dig deeper into the approach behind it, it's basically a very optimized way of implementing CSS that is easier to maintain and scale and minimizes bloat. I would even call it a thing of elegance. :)

On teams it's easy to get in the mindset of coding things on the fly as needed, and it feels like the fastest way to get things done initially. But that leads to a lot of reinventing the wheel, specificity issues (styles leaking to areas they shouldn't, fighting IDs, !important patches), and inconsistent design implementations, to say nothing of how much time is wasted by the next person working on that code just trying to figure out what's going on. And even in projects maintained by a single developer, it's easy for structure and specificity issues to creep in over time as a project grows and evolves.

The Salesforce System is built on SMACSS and BEM concepts which has quite a few benefits: it makes the code more human-readable, it minimizes specificity issues, and it improves the speed and consistency of implementations (to name a few).

SLDS is obviously built to solve web app needs so it won't be for everyone, but it does seem to have a great set of components and using these kinds of increasingly popular CSS standards will make it easier for developers coming from other systems to hit the ground running.

I think all build processes for anything reasonably complex should include some kind of module like task like purify-css or un-css to get rid of unused CSS (in order to make this kind of concern moot). That said, this method does not seem to be recommended by the team, nor is this policy enforced as often as it should be when CSS frameworks are used.