Since the beginnings of the Internet we’ve always had the need to style our websites, CSS has been around forever and has evolved at its own pace over the years, this article will take you through it.

To begin with we need to be on the same page of what CSS is, I think we can all agree that css is used for describing the presentation of a document written in a markup language.

It’s no news that CSS has evolved along the way and has become more powerful nowadays, but it’s widely known that additional tooling needs to be used in order to make css somehow work for teams.

CSS in the wild-west

In the 90’s we use to focus on creating “fancy” interfaces, the wow factor was the most important thing, inline styles were the thing back then, we just didn’t care if things looked different, in the end Webpages were like cute toys we could threw some gifs, marquees and other horrible (at the time impressive) elements over and expect to catch your visitors’ attention.

Ivan Todorov on Twitter

Microsoft's fist website, back in 1994. :) Looking pretty cool #microsoft

After that, we started creating dynamic sites, but css remained a consistent mess, every developer had his/her way of doing css. Some of us struggled with specificity, causing visual regressions when introducing new code, we relied on using !important to set in stone our strong will to make a UI element look in a certain way. But we soon realized that:

All those practices became more evident and bigger problems as soon as projects grew in size, complexity, and team members. So not having a consistent pattern to do styling became one of the biggest blockers for experienced and inexperienced developers who struggled to find a right way to do things in CSS. In the end there was no right or wrong thing to do, we just cared to make the thing look ok.

SASS to the rescue

SASS transformed CSS into a decent programming language in the form of a preprocessing engine that implemented nesting, variables, mixins, extends and logic into stylesheets, so you could better organize your css files and have at least some ways of deconstructing your css chunks in smaller files, which was a great thing back then.

It essentially takes scss code, preprocesses it and outputs the compiled versions of the file in a global css bundle. Great right? but not so much I’d say, After a while it became apparent that unless there were strategies and best practices in place, SASS only caused more troubles than it alleviated.

Suddenly we became unaware of what the preprocessor was doing under the hood and relied on lazily nesting to conquer the specificity battle but causing compiled stylesheets to go nuts in sizes.

Until BEM came along….

BEM and component based thinking

When BEM came along it was a breath of fresh air that made us think more about reusability and components. It basically brought semanticity to a new level, it let us make sure that className is unique thus reducing the risk of specificity clash by using a simple Block Element Modifier convention. Look at the following example:

If you analyze a bit the markup you can see immediately the Block Element Modifier convention in play here.

You can see that we have two very explicit blocks in the code: .scenery and .sky, each one of them have their own blocks. Sky is the only one that has modifiers as it could be foggy, daytime or dusk, those are different characteristics that could be applied to the same element.

Let’s take a look at the companion css with some pseudo code that will let us analyze it better:

If you want to have an in-depth understanding of how BEM works, I recommend you take a look at this article , written by my colleague and friend Andrei Popa.

BEM is good in the sense that you made sure that components were unique #reusabilityFtw. With this kind of thinking some apparent patterns became more evident as we started migrating our old stylesheets into this new convention.

But, another set of problems came along:

• Classname selection became a tedious task
• Markup became bloated with all those long class names
• You needed to explicitly extend every ui component whenever you wanted to reuse
• Markup became unnecessarily semantic

CSS Modules and local scope

Some of the problems that neither SASS or BEM fixed was that in the language logic there is no concept of true encapsulation, thus relying on the developer to choose unique class names. A process that felt could be solved by tools rather by conventions.

And this is exactly what CSS modules did, it relied on creating a dynamic class names for each locally defined style, making sure no visual regressions are caused by injecting new css properties, all styles were properly encapsulated.

CSS-Modules quickly gained popularity in the React ecosystem and now it’s common to see many react projects using it, it has it’s pros and cons but over all it proves to be a good paradigm to use.

But… CSS Modules by itself doesn’t solve the core problems of CSS, it only shows you a way of localizing style definitions: a clever way of automating BEM so you don’t need to think about chosing a class name ever again (or at least think about it less).

But it does not alleviate the need for a good and predictable style architecture that is easy to extend reuse and control with the least amount of effort.

This is how local css looks like:

You can see that it’s just css, the main difference is that all classNames prepended with :local will generate a unique class name that looks something like this:

.app-components-button-__root — 3vvFf {}

You can configure the generated ident with the localIdentName query parameter. Example: css-loader?localIdentName=[path][name]---[local]---[hash:base64:5] for easier debugging.

That’s the simple principle behind Local CSS Modules. If you can see, local modules became a way to automate the BEM notation by generating a unique className that was sure it wouldn’t clash with other’s even if they used the same name. Quite convenient.

Styled Components to blend css in JS (fully)

Styled-components are pure visual primitives that act as a wrapping component; they can be mapped to actual html tags and what they do is wrap the children components with the styled-component.

This following code will explain it better:

If you see the styled component is very simple to understand, it uses the template literal notation to define css properties, it seems that the core styled-components team nailed it this time as it blends the full power of ES6 and CSS.

Styled-components provides a very simple pattern to reuse and fully separate UI from Functional and Stateful components. Creating an api that has access to native tags either in the browser as HTML or Natively using React Native.

This is how you pass custom props (or modifiers) to a Styled Component:

You can see that the props suddenly become the modifiers that each of the components receive and they can be processed to output different lines of css, neat right?

This allows us to move faster and use the full power of JS to process our styles while making sure they remain consistent and reusable.

Core UI for everyone to reuse

It quickly became apparent that CSS Modules nor Styled Components by themselves was not the perfect solution, it needed some kind of pattern in order for it to work and scale. The pattern emerged by defining what a component is and separating it fully from logic, creating core components which sole purpose is to style and nothing more.

An example implementation of such component using CSS Modules:

If you see, there’s nothing fancy in here, just a component that receives props and those are mapped to the children component. In other words: the wrapping component transfers all the props to the children.

Then your component can be consumed in the following way

Let me show you a similar example of a full implementation of a button using styled-components:

What’s interesting about this pattern is that the component is dumb and only serves as a wrapper of css definitions mapped to the parent component. There is one advantage of doing this:

It lets us define a base UI api which you can swap at will and make sure that all UI remains consistent throughout the application.

This way we can fully isolate the design process from the implementation process, making it possible to trigger them in parallel if wanted; you can have 1 developer focusing on the implementation of the feature and another polishing the UI achieving full separation of concerns.

Sounds like a great solution so far, internally we had discussions around it and thought it was a good idea to follow this pattern. Together with this pattern we started identifying other useful patterns as well:

Prop receivers

These do the function of listening to props passed to any component, thus making it easy to use these functions in any component you want, making it the holy grail for reusability and extending the capabilities of any given component, you can think of it as a way of inheriting modifiers, an example of what I mean by this:

This way you are sure that you won’t need to hardcode all the borders again for each specific component 🏆, saving you tons of time.

Placeholder / Mixin like functionality

In styled components you can use the full power of JS to be able to create functions not just as prop receivers but also as a way of sharing code between different components, here is an example:

Layout Components

We’ve detected that one of the first things we need to do when working in an application is layout our UI elements, for this purpose, we’ve identified some components that aid us in the process.

These components have proven to be very useful as often some developers (not familiar enough with css positioning techniques) have a hard time setting the structure, here is an example of such components:

If you can see we have the <ScrollView /> component which takes a width and a height as props and also receives the horizontal prop so the scrollbar appears below.

Helper components

Helper components make our life easier and allow us to reuse heavily. This is the place where we store all our common patterns.

These are some of the helpers I’ve found quite useful so far:

Theme

Having a theme lets you have 1 source of truth of values that can be reused throughout the application, it’s been proven useful for storing values that are commonly reused in the application like color palette and general look and feel.

Pros

• The full power of JS at our hands, meaning full communication with the component’s UI.
• Eliminates the need of mapping components and styles through the use of a className (this is done under the hood)
• Great development experience so far, it reduces the amount of time spent thinking about classNames and mapping them to the component.

Cons

• Yet to be tested in the wild
• Built for React
• Super young
• Testing needs to be done via aria-labels or using classNames

Conclusion

Whatever technology you use whether it is SASS, BEM, CSS Modules or Styled Components there is no substitute for a well defined styling architecture that makes it intuitive for other developers to contribute to your code base without thinking too much, breaking or introducing new moving parts to the system.

This approach is crucial to scale properly and can be achieved even if using plain CSS and BEM, the main difference is the amount of work and LOC needed for each implementation, overall styled-components feels like a great suit for pretty much all React projects, yet to test it in the wild but quite promising indeed.

If you have any feedback thoughts, opinions, advices or anything please comment below, or feel free to reach me via twitter @perezpriego7

Design shouldn’t be just beautiful

A light introspection on what I think about design .

When talking design the word “beautiful” often comes to mind as if it was the ultimate goal, we tend to forget that design has a purpose; its purpose is to give life to ideas and ensure that they become a reality. By definition design is:

As a noun:

1. A plan or drawing produced to show the look and function or workings of a building, garment, or other object before it is built or made.
2. A decorative pattern.

As a verb:

1. Decide upon the look and functioning of (a building, garment, or other object), by making a detailed drawing of it.

You can see immediately that when design is used as a noun it has a static meaning, something that lives only in someone’s head, some plan that hasn’t been implemented yet.

But when used as a verb you can see how design has a voice, it is the guiding force that puts the idea in motion so it can become a “real thing”, it is not longer about pleasant or beautiful but it’s more about making it happen.

Design should be transparent

So many companies and agencies focus on providing great looking experiences, most of the time to win awards or have a richer portfolio. Rather than spending a lot of time designing the product for great looks, it is always more important to focus on solving a core problem. Quoting this great article from the people at Intercom:

Too many designers are designing to impress their peers rather than address real business problems.

In fact design should be transparent, it should help people to visualize possible solutions for a problem. Once the solution is understood, there’s no point on throwing noise on top of that choosing a nicely looking color palette (at least early in the process). It’s always better to present ideas in the form of wireframes or even drawings so all the noise caused by other factors is not relevant when discussing about a possible solution.

The 80 /20 rule

There are two types of designers, the ones whose primary focus is in providing solutions and the ones who spend most of their time making things look awesome.

The first kind is the one who spends 80% of the time thinking about the problem, trying to think about the most important possible scenarios, even if their designs don’t look great they succeed at providing solutions, this type of designer is humble, asks the right questions, would sacrifice some eye catching graphics in exchange for many other factors like development speed, complexity, scalability, etc.

The second type of designer is utterly focused on making things look great and spends 80% of the time creating awesome mockups that look amazing, but often fail to be the easiest path to solve a problem, some of us spend too much time refining the details and fail to see that the ultimate purpose is to solve a problem as fast as possible with the minimal effort.

I think this quote summarizes these thoughts clearly:

“I have found that all ugly things are made by those who strive to make something beautiful, and that all beautiful things are made by those who strive to make something useful.” Oscar Wilde

Maybe this quote is a bit too drastic but it shows perfectly the point I am trying to make. It’s almost always the case that beautiful is not a requirement for functional. Design shouldn’t be confused with art. Now a days we tend to applaud awesome looking sites that win awards but often focus on superficial things rather than solving a real problem.

Design is not Perfect

Often design is done in a passive manner by using a linear way of thinking about it. When we think of a product often we realize design is something that should be done before the product comes to life but most often we end up wasting time postulating the wrong premises before exposing them to the final user.

Design is more about doing and proving yourself right or wrong. It is about continuously make an effort to make something better everytime. It is about solving problems for people and make a commitment to always figure out how to make them accomplish more with less effort.

Design is embedded in each step of the process.

Every stage of a project needs design, wheather it is designing how data will flow, how an architecture should be built, how a product should serve its purpose or how a button should give feedback. Design is in all the extense of the word just pure attitude towards problem solving.

Good design is not about making pixel perfect UI but more about taking the user through a flow with the least amount of friction. It is not about colors or spacing but about anticipation. It is about daring to explore different ways of doing things trusting that each iteration your product will become a better tool.

Design is a continuous process, it never ends, there are always better ways to accomplish things, better patterns to follow, better tools for communicating and making things happen faster.

We should never stop designing.

TDD (Test Driven Design)

In programming we are used to do test driven development which essentially consists in writing an hypothesis, make the test fail and figure out a way to make it pass. Design is not much different, we take a premise, build an hypothesis (prototype) and then work around ways to make the hypothesis solve the right problem.

This can be done at scale, weather it is a simple feature or a more complex endeavour we can use this process to be able to come up with valuable solutions. Test Driven Design is just about decreasing the feedback lifecycle to be able to adapt faster to a problem solving scenario.

There are tools and techniques that can help us along the way to test our design such as A / B testing, Behavioral analysis, observation and any other idea to help you better understand your users.

Design needs eagle vision

Every designer needs to be aware of the primary context of the problem to solve. Weather it is talking to stakeholders for clarification on requirements, talk to developers about implementation and decide what is a possible solution. Design is about making choices and be sure that the scenarios are tested properly before releasing to a broader audience.

A designer needs to be aware of the circumstances surrounding product decisions. Weather it is business value, development complexity, or even release strategy.

“A great designer solves the problem the user is facing, a great designer anticipates solutions for problems users don’t even know they have”

Design is doing

The only way of testing something is by doing, this can be done in several ways, whether it is a sheet of paper or a working prototype, designs can only be tested when they are built, so we need to make sure that enough effort is put in place in order to prove premises right or wrong.

Design is not right or wrong, it’s proving that you are one or another.

Once you dare to jump in the doing cycle you will see that by investing enough time and effort into building something that can be refined in each step of the process is really exciting. Designs suddenly become not only passive things to admire but useful tools to use, test and refine.

Design is about empathy

Having the ability to take a time and see how a user feels a product is essential for becoming a good designer, spending enough time understanding the user context is crucial to come up with great ideas.

Most often simple solutions are better than astonishing interfaces. Design needs to be subtle, almost invisible. It is not about the designer itself, it’s about solving a problem for somebody else. In order to design something useful you need to go beyond what you think it’s best and dare to put your idea on the wild and iterate through it along the way.

Design is for everyone

Whether your users are other developers, children, professionals, housewives, you always need to think about how design impacts their lives. Need to wear their shoes for a while and try harder every time to empathize with their problem. That way is the only way to fully become a good UX designer.

Design for everyday use, think about objective facts around you not just pure subjective aesthetic decisions. It is not about learning Photoshop but more about the way to approach a solution to problems. Everyone can learn to design, in fact we are all potential designers; it’s not as much as a technical skill but more of an attitude towards providing solutions that matter.

Getting immersed in the problem before providing a solution is critical, I won’t lie and say that everyone should be a designer, because it requires passion and dedication, but I feel that being a designer is such an intuitive task that everyone can learn how to do; if enough attention and dedication is put into it.

Would love to hear your thoughts.

Here at AlphaSights we are a group of passionate engineers and designers and always welcome new talent. Are you interested in joining the team? remember we are hiring

A few days ago I watched a really interesting video presented by Harry Roberts at dotCSS 2014. He talks about principles, or best practices, to become an effective front-end developer. In reality, however, these principles can apply to all kinds of developers. Below I have summarized these 10 principles and provided my thoughts on each.

1. The Simplest Option is Usually the Best

As engineers our job is to solve problems. We are curious by nature and many of us feel the strange desire to constantly learn new things, frameworks and technologies. Often in an effort to become better developers we tend to over-engineer solutions. Most of the time we feel the need to ditch everything that we know in favor of new paradigms, but most of the time it comes with a cost: the cost of overcomplicating things.

No one appreciates over engineered stuff.

I couldn’t agree more on this point. Whenever choosing a way to execute a solution, pick the simplest option. It’s less likely to break, it’s less complex, and it’s easier to understand. In addition, it is always faster and cheaper to implement. Conversely adding levels of abstraction introduces the need to learn new ways of approaching a common problem. Less cognitive overhead when working at scale is always welcome.

I think it’s important to stress the word “usually” in this principle because I would not always consider it a rule of thumb. There are certain cases where we need to sacrifice simplicity over adaptability, scalability and security. But more often than not these are rare exceptions.

2. Reduce the Amount of Moving Parts

Code that is simple and concise is always easier to maintain. As dependencies grow in a project the overall complexity of the code-base increases as well. This also increases the chances of injecting bugs and problems. It may seem easier to add a shiny new library that solves the problem faster, but in reality this introduces new problems that in the beginning you may fail to consider.

Any moving part we inject in a system comes with an added cost tied to its maintainability. So whenever you think about adding new things in a system think twice and ask yourself if the benefit of adding new dependencies will solve the problem in a more efficient manner or if it will only take you out of the problem temporarily.

The best code is no code at all

I believe that whenever there is a chance of getting rid of something, it’s better to choose that path instead of adding more moving parts to the system. Think of it this way: more code = more time spent maintaining, fixing, and refactoring. So next time you see the possibility of safely getting rid of something, do it. Every moving part of the system is a potential point of failure.

Refactor to reduce complexity. It’s always a good exercise to try to refactor things in such a way that lets you simplify your solutions. I’ve found that it’s most often a good idea to try to find the patterns that are core, and kill code and even features that don’t add much value.

3. Understand the Business

Put yourself in your employer’s shoes. Always think about where your effort can lead to the greater benefit. Understand the value of your work for the good of the company. Connect with everyone else’s problems and always be ready to help. Know that others can avoid making the same mistakes you did by providing useful advice. This kind of mentality will put you in a much more valuable position in the long run.

Increasing your technical abilities is good for you but not necessarily for your company. Find a good balance between self-improvement and team-development. Remember that you are not isolated and that your work has a big impact even if you haven’t realized it yet.

Know your strengths and also your weaknesses so you can be ready to guide and ask for guidance whenever needed. Understand all the things that make you valuable. Don’t be just a developer, try to have a wider perspective and also understand how your work translates into wealth for your company. Don’t just build features, create solutions.

4. Care Less, Care Appropriately

No one cares more about your work than you do. Often there are trade-offs that need to be made in order to keep the workflow running smoothly. You will always find different opinions about everything, Whilst it is sometimes useful to engage in a debate, you may not want to waste the time debating superficial stuff.

Know that every time you express your opinion, there is time spent by your colleagues, understanding you and responding to you. Be respectful of the time of others and also to yourself while expressing an opinion. So the next time you share something publicly, think twice on the value that it will add to your team’s collective knowledge. Pick the right battles. Stand up whenever you are sure about something with humility and be open to hear opinions. Remember you won’t always be right and that there is value in considering different points of view.

Balance the needs and wants of everyone

Care less about your work but more for your team. Be less selfish and also be ready to make sacrifices for the good of others. Care more appropriately for everyone else’s jobs. Remember that your work, words and opinions have an impact on your team mates work even if it’s not that evident at first. Think about how you can make your teammates’ lives better by removing stress, not adding it.

5. Pragmatism Trumps Perfection

It is better to be timely than perfect. Things change fast in our industry. We are continually trying to innovate and find new ways of making better products. Sometimes in an effort to ensure the quality of a product we make certain trade-offs. I am not saying quality is not important; every company should have at least a basic set of quality standards so every product provides the best experience possible. But in my opinion there should be a right balance between good enough and perfection.

Good enough today is better than perfect tomorrow

Measure features based on business value. Don’t wait so long to release. Does it work to the minimal quality standard set by your company? If so, ship now to solve the core problem and assign some time to refactoring tasks later (Make sure you do, otherwise quality can deteriorate over time). Measure every feature built based on its business value and prioritize accordingly. Nothing is or will ever be perfect. You shouldn’t delay a project for superficial decisions. Focus on defining what is the minimum viable product and ship it as fast as possible. Later you can spend some time refining the experience. Something hacky that works today is better than something perfect that works next week.

6. Think at the Product Level

Your job is not just to produce features as if you were a factory. Whenever you are asked to build a feature is always good to give it some thought and ask yourself how much value your work is adding to the product. Don’t be afraid to respectfully question management decisions. If you are not convinced on something, make sure you discuss it with your leads before going down that path.

I am sure they will find your opinions valuable or will light your way in case you are failing to see a broader scenario. Do it with respect and be flexible. Great managers are good listeners that will value different perspectives, and will try make the right decision based on the knowledge they have.

Think of the all the factors in play, whether it’s team velocity, complexity, or productivity. Make decisions considering all possible factors. Get involved with everyone else’s issues, don’t just do your job. Be informed about the context of the project and make decisions that add value.

7. Don’t Design Systems Around Edge-Cases

Don’t let edge cases rule your product decisions, but rather focus on what yields the most benefit. Consider first solving the problem for your core audience and work on refining the experience later for edge cases. In other words, don’t let the minority lead the majority, and don’t base an entire product based on statistical outliers. These rare cases where something does not work for a specific segment shouldn’t hold back the release of a product.

Think of your major user base and design for them not the rare anomalies. Build for the most common scenario first. Solve edge cases separately and later in the process. Define your ideal core user base and solve problems based on hard statistical data (for example browser usage). Sometimes we may spend a lot of time fixing a bug that affects only a minimal amount of users. If it’s not critical, you shouldn’t jeopardize the release of a product in the quest for perfection.

Everything is prone to have errors, and everything will be buggy, but know that releasing a product on time could yield to greater benefits than delaying the release for very uncommon situations. Have a release strategy and make sure you allocate time to fix those nasty errors but just don’t wait until those are fixed in order to start gathering data or even ROI.

8. Don’t Make Decisions Based on Anecdotal Evidence

Whenever someone tells you something is great, do you research before taking anything for granted. It’s easy to jump into judgment and conclusions too quickly if something does not fit our current mindset. Do your homework, try to make unbiased decisions and always look for different opinions on the matter.

In general, rare anomalies or strong opinions that don’t fit the common denominator are based on lack of understanding or deep introspection. If the later is the case, you should consider it. Make sure that those opinions are based on first-hand experience and careful analysis.

Don’t believe everything that everyone says, but rather draw your own conclusions based on factual data. Anecdotes are not always representative, and may lead you to wrong decisions. Never trust gossip, always trust data.

9. Don’t Build it Until you’ve Been Asked for it

It is really tempting to come up with a shiny new solution that wows everyone by how smart and innovative it is. But most of the times building something without everyone’s approval is disrespectful not only because your time is costly to your employer but also because everything that you build has a maintenance cost.

It’s really cool to over-deliver, but think twice before implementing things. Is it a requirement now? Are you 100% sure it will have a positive impact? And most important, is it approved by management? Maintaining things that nobody asked for is irresponsible. Solve every single problem whenever you encounter it, not before. Don’t do work ahead of time.

It is not smart to solve problems that nobody has now. Be smart about how you use your time and the next time you want to create something awesome discuss it with your leads before doing so. I am sure if its really good you will have an approval sign and support from stakeholders to execute. Remember that communication is key for proving yourself valuable. It shows you understand how things work and that you are aware how your work impacts the organization.

10. Expect and Accommodate Change

Worry about something that solves the problem right now. Tomorrow’s technology will most likely change, so you will need to adapt anyway. Focus on something that fixes the problem but be flexible enough to let the next developer easily adapt to your code. Make sure you can undo things.

Surely I’ve been bitten before for not following these principles, which is why these principles resonated a lot, I really wish I would have heard this before I started working with a team, since it could have made me so much more valuable. Now it’s time to apply them as much as possible. What do you think? Are there other principles that you think are important? I would love to hear your opinions!

Watch the video of Harry Roberts at dotCSS2014 below:

10 Principles for Effective Software Development was originally published in AlphaSights Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.