Geekly Articles each Day
📜 ⬆️ ⬇️

Modular CSS: - The toolkit that we have now in the arsenal is just a fairy tale


The toolkit that we have now in the arsenal is just a fairy tale!

Andrei Okonechnikov, a developer with 15 years of experience, of which more than ten were given to user interfaces, Andrei will tell HolyJS about using PostCSS and Webpack to solve front-end development problems. Andrei's talk is called “Modular CSS” and is about how to work with CSS on large-scale projects with the help of JavaScript and AST. Starting from the subject of the report, we asked Andrew several questions that will allow you to understand the depth of UI / UX connection with the work of the frontend developer, as well as about the problems and future of CSS on large projects.

The main problem of the modern frontend is inhibition


- Many people are accustomed to the fact that a UI designer and developer are not only two different people, especially on large projects, they can almost not even communicate with each other. What, in your opinion, are the consequences of this disunity?

- In 2007, I spoke at the first RHS with the report “Profession Frontend-architect: who is it?” And raised this problem there. It's funny that almost 10 years have passed, and the situation has not changed much. Developers and designers try not to leave their comfort zones: some post beautiful “interfaces” in the dribble, while others rewrite the front-end each month using a new technology. The result is usually very sad. On the Internet a lot of uncomfortable, questionable quality sites and web applications.

- What, in your opinion, is the main problem of the modern frontend? What do you think, which of these issues most affect the end user?
')
- Speed, but rather, inhibition. Slow loading, especially noticeable on mobile devices, leads to the fact that users leave the site without waiting for it to load. And the popularity of SPAs (Single Page Applications) does not improve the situation - most web applications first load a huge JS file before showing anything. Well, few people still make loading custom fonts correctly. Therefore, I think, in the near future, great emphasis will be placed on optimizing for mobile users and improving tools for assembly and analysis.

- Your report focuses on PostCSS and Webpack . Why exactly they? Why not SASS?

- My report is more about choosing the right tools for certain tasks. PostCSS and Webpack, in my opinion, solve problems in this context that other tools cannot solve or solve badly. This does not mean that SASS is bad. Just to solve the problems I’m talking about, it’s not very suitable.

“Boxed” solutions are good for “boxed” tasks.


- What do you think about the toolkit hell problem? Postprocessors for css, separate template engines, does this whole overhead head influence the final result? Is it possible that in the development process, features are discarded, the technical execution of which conflicts with the use of a specific set of tools?

- I have been doing web development for more than 15 years and, in my opinion, the toolkit that we have now in the arsenal is just a fairy tale! I do not understand how automatic placement of vendor prefixes, asset bundler with embedded best practices for the modern web or modern CSS linters with plugins for any syntax can interfere with the development of features. On the contrary, I think that given the increased complexity of the frontend, it is impossible to make features on time and qualitatively, without using modern tools. I do not argue that all this should be studied, tuned and maintained, and this, of course, is worth the time. Just a few people say how much time these tools ultimately save.

- What do you think about the increasing popularity of “boxed” CSS solutions, such as Bootstrap, Material UI and Semantic UI? Many developers complain about the limitations that this imposes on the process and the result of the development. Perhaps a more unified and visually predictable web will create a more consistent UX?

- I think that “boxed” solutions are good for “boxed” tasks. If there is a task to quickly create a user interface, then, probably, without such a framework it will be very difficult. But if the task of doing something unique, then such things will usually only interfere. I do not urge to do everything myself, on the contrary, I think that writing your dropdown in 2016 is just silly. But when choosing a framework, the developer must understand well all the limitations that he imposes. Ideally, I would like to see a framework that implements a standard library of frequently used controls in such a way that it is very easy to change both their presentation and behavior.

- Do you think that the CSS in the latest standards has somewhat “outgrown” its original minimalistic declarative design? Animations, complex selectors, slowly starting to resemble XPath. Is it because of the need to add mixins, variables, and other constructions that are more common in imperative languages?

- Yes, there is a feeling. It seems to me that CSS is trying to become a programming language. At the same time, it still has not solved the problems of isolation, modularity, determinism, and others, which are no longer problems in normal languages. CSS was created not for web applications and SPAs, but for styling hypertext documents. That is why, it seems to me, we are now seeing a lot of activity in the field of CSS-in-JS - the temptation is too great to use "normal" or at least one programming language to describe and represent the UI. I see nothing wrong with that and am willing to treat CSS as a compilation target. Ideally, from the side of the CSS community, I would like to see a fundamentally new standard that would take into account the changed landscape of use. But there is a problem that the developers from the CSS and JS camps overlap very little. I think we should start to solve the problem with communication and understanding of the common problems of the language.

This is a misconception that the Developer Experience does not affect the User Experience.


- How do you define the moment when the project has become so large that it needs tools for more organized work with CSS? How familiar with this toolkit can slow down the development for a small team?

- I think that this is the moment when a decision is made to create a project. Here, however, there is a problem of interests: the business says that it is necessary to start as quickly as possible, so now we will be shoveling all one pile for 6 months: JS, CSS - it does not matter. After launch, however, it is time to support and develop new features. And at this moment everything must be rewritten, because no one dares to touch the old code (there is no time for rewriting either). I think this approach is very stupid, because the time for rewriting could be saved if code quality tools were originally used - it does not matter, again, CSS or JS. How much this can slow down depends on the team. Ideally, tools should not slow down, but rather accelerate.

- Adaptive frontend - almost standard for users in 2016. Does your approach simplify work with a huge number of permissions, with adaptation of sites for people with disabilities?

- My report is not quite about that, of course, but it is highly likely that as a result of a good project architecture, more time will be available both for creating adaptive versions and for accesibility. But in general, the architecture of the project does not affect this in any way - these are only additional requirements for the quality of the project.

- There is an opinion that the current direction of development of front-end frameworks is somewhat narcissistic. It puts in mind the beauty of the code, correctness, modularity, compatibility, but such things at first glance have little effect on the UX itself. Perhaps you have something to argue?

“I think this is a misconception that the Developer Experience does not affect the User Experience.” The beauty of code and modularity are directly related to the confidence of developers when making changes to the code, which, in turn, is related to the quality of the product. The number of bugs, the speed of release of new features, attention to detail - this is also part of the UX. No good developer will want to work on a project where there are a lot of problems and nobody cares.


To everyone who wanted to dive deeper into the topic of modular CSS, we suggest visiting Andrei’s report at the HolyJS conference, where any JavaScript developer can find many other equally interesting topics:

Source: https://habr.com/ru/post/316308/

More articles:


All Articles