{"id":2289,"date":"2020-01-07T10:06:29","date_gmt":"2020-01-07T09:06:29","guid":{"rendered":"https:\/\/www.codemotion.com\/magazine\/uncategorized\/css-build-your-pipeline-with-style\/"},"modified":"2021-07-05T13:12:57","modified_gmt":"2021-07-05T11:12:57","slug":"css-build-your-pipeline-with-style","status":"publish","type":"post","link":"https:\/\/www.codemotion.com\/magazine\/frontend\/css-build-your-pipeline-with-style\/","title":{"rendered":"Build your pipeline project with\u2026 style!"},"content":{"rendered":"

How many of you are afraid of Cascade Style Sheet<\/strong>, also known as CSS<\/strong>? Honestly, I am really scared of it, maybe because I\u2019m not a designer and my ability on computer graphics is not so good to make me feel comfortable with CSS. However, when we are in a medium-sized project, or when we are working alone on a small project, we need to think about the general architecture of the technology stack of our application to succeed. This includes style with the right choice such as which style language will be applied, which level of browser compatibility we are looking for, and so on.<\/p>\n

In a frontend<\/strong> perspective way, we need to cover and think about many different topics from usability<\/strong> to functionality, from user experience<\/strong> (UX<\/span><\/strong>) to User Interface (UI) and last but not least, which kind of main<\/span> library or framework we will use to build our components and client side application logic.<\/p>\n

So this is the main<\/span> reason why, at Codemotion Rome 2019, I listened to Giacomo Zinetti\u2019s talk – from Liferay an open-source company – with the hope I would increase my knowledge about the pipeline building project that involves styling.<\/p>\n

Giacomo revealed to us what kind of questions we need to answer in order to do it right, starting from scratch for the style point of view.<\/p>\n

Environment<\/h2>\n

Our environment is not only about what software or IDE<\/strong> will we use to write and build the application. Mainly, the environment is composed by people who work together in one or more team. So, the team is the first resource that we need to know well, in order to enjoy the work and get the most from everyone.<\/p>\n

We need to know the level of experience<\/strong> of our team to assign them the right work balance.<\/p>\n

Next, the type<\/strong> of the project is also fundamental to understand not only how many people we need to involve on it, but it will be the key to choose from library or a framework or build all the css rules from scratch. The type of project can be a complete web application like an e-commerce, a simple landing page, a single web component or an admin panel made mainly with charts and data table.<\/p>\n

After that, the life-span<\/strong> of our products is another aspect that we need to evaluate before selecting what kind of framework or not we need. A light technology stack is preferable for little projects with a short life-span.<\/p>\n

Then we have to decide about Vendor Compatibility<\/strong>, Browser Compatibility<\/strong> and Performance<\/strong>, but we do not always handle those aspects; most of the time both are imposed constraints and we don\u2019t have to much control over them.<\/p>\n

Finally, we need to discuss handling the application logic, do we need a framework like Vue, Angular or React<\/a> or even to try the new way of the Web Components<\/a> or stick with Vanilla JavaScript<\/span> (please don\u2019t use jQuery anymore). <\/p>\n

In addition, what kind of architecture should we choose? Microservices<\/a> Architecture pattern or Monolithic Architecture pattern?<\/p>\n

Microservice architecture is a method of developing software systems that tries to focus on building single responsibility function modules with well-defined interfaces and operations. The trend has grown popular in recent years as Enterprises look to become more Agile and move towards a DevOps and continuous testing.<\/em><\/p><\/blockquote>\n

Style Build Pipeline<\/h2>\n

Let us begin to discover how many ways we have to get involved with CSS. It sounds like a very nice job from Giacomo\u2019s words.<\/p>\n

First, we discovered that out of the Bootstrap<\/strong> framework, there are many other frameworks! Wow! I need to admit that I am too addicted to Bootstrap.<\/p>\n

Secondly, related to CSS framework like JavaScript framework<\/a>, we can have different kinds of typologies, from pure CSS library to a complete set of CSS rules with a set of JavaScript scripts that give us components like Carousel or Hamburger Menu, but I discovered an unknown typology to me: utility framework like Tailwind or Tachyons.<\/p>\n

A utility framework does not have a default theme and there are no built-in UI components like Bootstrap, Foundation or Bulma. On the other hand, it also has no opinion about how your site should look and does not impose design decisions that you have to fight to undo. Instead, it provides highly composable, low-level utility classes that make it easy to build complex user interfaces without encouraging any two sites to look the same<\/em>.<\/p>\n

However, if you like to write custom CSS or modify an already existed one, what kind of steps do we need to take?<\/p>\n

There are two main steps: pre<\/strong>–processing<\/strong> and post<\/strong>–processing<\/strong>. <\/p>\n

Pre-processing is the step where our CSS syntax code is not written in standard CSS but with another language like SASS, Less or Stylus. Therefore, we need to transform the new syntax that seems to be like CSS, in plain CSS to make it understandable for the browser.<\/p>\n

Why we use those kind of languages? To add \u201cpower\u201d to our syntax and get access to mixins, functions and variables, that we use in standard programming language<\/span>, and can be useful to get more control on our style code.<\/p>\n

\"\"<\/picture>
SASS Example<\/figcaption><\/figure>\n
\"\"<\/picture>\n
Less Example<\/figcaption>\n<\/figure>\n

Post-processing is the step where our CSS is transformed in CSS (yes, it seems to be the same) which enriches our rules with vendor prefix, optimises tasks such as compression and minification, the linting task involves error checking operations and checks the style guide related to the code we write.<\/p>\n

If our project is a lifelong one, Giacomo advises us to stick to classic CSS with semantic names for our class styles to prevent a choice that can be deprecated or abandoned in the future.<\/p>\n

Is that all? In truth, before starting every project, it is good to write and share with all team members a style guide and a naming convention like BEM, to have a clear folder structure with the appropriate file names which improves organisation and finding operations.<\/p>\n

A linter helps us write better code. With the right settings, we can check our code while we are writing it and get suggestions and warnings. It can greatly improve our productivity and prevent hidden problems.<\/p>\n

Finally, do not forget that stylesheet is determined by the cascade feature. It is a fundamental feature that defines how to combine property values coming from different sources. This is the key to know how an element can be rendered in a certain way.<\/p>\n

\"\"<\/picture>\n
Why you need to know cascade<\/figcaption>\n<\/figure>\n