A commentary on the history of mobile development and approaches to serving content to disparate device types and screen sizes
In the old old days mobile was never really a concern for most developers. All you really had to worry about cross anything were browser issues. Desktop screen sizes were debated back then, but they could be overlooked; the differences were not so great or prevalent, and the "fix" came relatively quickly as the industry settled on . . .
Best practices for developing world-class front-end code
Be the handshake between design and logic; what the user sees and interacts with and what the back-end development team builds. With this in mind:
Seek perfection and excellence in code
- Write beautiful code
- Keep code well organized, readable and DRY
- Be consistent
Code with the development teams ease of use in mind
- Provide intelligent and . . .
This is important. No, seriously... This is really important!
I can't stress enough how important it is to start a project with some kind of organizational structure in mind. Even if you don't know what shape the application is going to take it will serve you well to have a basic structure in place.
Organizational Heart and Soul
The organizational heart and soul of a Rails application is
. . .
Try not ... no ... DON'T Repeat Yourself! In CSS this means consolidating where possible. There are also some other techniques that do not DRY up your code in output per se, but they do DRY things up when writing your stylesheets, before they are processed: Variables and Mixins.
Here is a rundown of some of the techniques I use:
. . .
Over the years I reviewed or worked on a lot of other front end developers work, and have found a lot of recurring issues that I would like to address here as stylesheet tips:
Consistent Use of Preprocessor Formats
It would be better to pick a format such as .sass and .scss, and stick with it sitewide. Syntax varies slightly between the two, . . .
I have my way of naming classes and IDs, and I've seen things all over the board. Here are the guidelines I follow:
- Keep it simple
- Keep it semantic
- Keep it short
- Use underscores between words
Keep it Simple and Semantic
I've never been too crazy for style names that really have no meaning like:
:class => 'H2603A'
Okay . . .
There are those who write code with the highest degree of organization, consistency, and in a word... STYLE. And then there are those who don't. One group seems content at "if it works it's fine," the other group takes it a step further. They think in terms of readability; for the team and for the next person, and in general . . .