Atomic CSS - what is it and is it useful?
The problem statement
I think this statement says a lot on how ACSS and to some degree Atomic Design itself see the world of CSS. Anyone working with wild or free CSS development can certainly recognize some of these pain points. This is not uncommon in scenarios where many developers work in the same project or you have to work on top of a not so well-designed product.
The question is, though, how many still work in that way and why?
In a scenario where you have a defined design pattern, which should be the norm these days, this is rarely an issue. Regardless if you do atomic design or component design, your styles should be easy to maintain and define. Despite this I still see a lot of JS developers adopt inline styling and duplication of CSS in components. This is more common in libraries like React and Angular, I feel (personal experience, no real numbers to support that).
So it is not surprising to see a rise in areas like Atomic Design or ACSS since that help bridge the gap in skill levels some JS developers have and the inherent despise we have to spend more time than we have to on things we don't really enjoy doing. Not to mention, there are some benefits that should not be overlooked.
ACSS - Atomic Design as a preprocessor
ACSS is a preprocessor that will transform inline HTML variables and create CSS from it. It has a fairly simple syntax and it works by looping though the HTML and scrape up the variables and then make a CSS file from what it finds. In many ways, this is similar to inline CSS, but you would get a static CSS file instead of just printing it out in a style tag.
If we borrow an example from the excellent CSS-Tricks site that I highly recommend you check out, then here is a snippet of code where we declare some classes and input a variable to each.
<!-- Programmatic Atomic CSS Example --><div class="Bgc(#0280ae) C(#fff) P(20px)">Lorem ipsum</div>The output from this would then generate the following CSS:
.Bgc\(#0280ae\) { background-color: #0280ae; }.C\(#fff\) { color: #fff; }.P\(20px\) { padding: 20px; }This may seem quite useless compared to a well-defined CSS with variables declared that I could just input, but you could use both of course and use this to override in certain situations. Similar to how you would use inline styling.
The biggest benefit of this however is that the CSS generated would be as small as you could make it. This is because the CSS would be based only on what can be found in the HTML. This can be useful for development in for example Angular and React, where I assume this is mostly used.
In situations where you have classes reused over many components, like this website however, that would not really be as beneficial as having multiple CSS files is never a good thing and you would see duplication of classes. This is of course if you generate the CSS on a modular basis, but not if you render it globally on load somehow.
Overall, I do not see any need for me working with sites like Invision Community and I feel it would not really work well in an atomic design situation with defined styles in both the UI and the HTML/CSS that is reused across components.
I may be completely wrong about that, as I have not tried it and if so, sign off in the comments to tell me I am wrong 🙂
Atomic Design as a Philosophy
The idea of Atomic CSS is simple and, to be honest, not very new. The idea is to create single attribute classes and then stuff the HTML with them. Kind of like you would do using Inline styling, but with a global definition of the styles. It would look something like this.
/* naming utility classes */.relative {position: relative;}.mt10 {margin-top: 10px;}.pb10 {padding-bottom: 10px;}I say that this is nothing new because this has been around since before inline styling even existed. One reason it is not widely used is because it makes the HTML cluttered and hard to read. It is also a bit annoying to work with compared to having well-defined CSS classes as you will have a ton of attribute shortcuts basically rather than a library of styles.
If you are used to working with frameworks like bootstrap, then you are already familiar with the concept, since those frameworks also have libraries of smaller styles that you can mix and match. Atomic CSS is much smaller however and rather than having for example a flexbox class that have the standard values you use all over the site you have to build those up with a set of classes inline in the HTML.
Is it a terrible idea?
Atomic design as a concept can be traced back to October 2013 and an article written by Thierry Koblenz. It has since evolved and you will often see it in reference from the new breed of JS developers that work in frameworks like React and Angular. While it may be a bit unfair to say that these new JS developers do not have that same deep understanding of CSS as the "regular" front end developers, I do see this distinction growing.
For the JS developers however, this is pretty useful as they can focus on function rather than form. You have probably seen the mess that sometimes happen when JS developers mix inline styling, component specific styling and global styling. It is as bad as having multiple novis CSS developers trying to use EM when they do not control the output containers...
I hear some arguments that this makes it easier to avoid specificity issues, but I do not agree with that. If you control your code, then you are a pretty bad developer if you can't handle your classes properly. It all comes down to planning and setting structures after all, unless you are just playing around like I do on this site.
I digress though and to answer the question if this is a terrible idea I think there are use cases for when this can be useful. Since that article in 2013 however, I think those use cases are less now, especially with the introduction of CSS variables. I do however think there is a very good case for using this same idea for defining variables and to keep your classes small as a philosophy.
I do think there are certain scenarios where it is a good idea to use the concept of Atomic design, and that is for overrides. Things like fonts, colors and spacing can be useful to sometimes just make a small adjustment rather than building new components.
Also, if you generate your content at runtime on the server, there are benefits to this since you can combine it with CSS-in-JS to dynamically generate very small CSS files. I guess this is why React and Angular developers are liking this way to organize your CSS classes. You can still do this working with regular CSS, but the files will be bigger since you are bound to have duplicate attributes in your classes.
So it is not a terrible idea, but it comes with some issues.
Allow me to explain...
My Thoughts
While there are benefits in some cases, there are some negatives as well. The biggest issue for me is that while we reduce the CSS, we instead increase the size of the HTML. The HTML also becomes much more cluttered and harder to read because unlike CSS where we can group classes, or even split them on multiple files, HTML will just be one big garbled mess.
Consistency is also an issue because the idea of recreate clusters of classes to achieve the components is done manually every time, then you will see consistency go out the window. We see this all the time in wild or free CSS, where pretty much every component have its own class styles uniquely. This is especially problematic if you have JS developers that are not very good at using CSS and you try to set up a design library.
At the end of the day however, front-end developers are flexible and resourceful people. All of these potential pitfalls can be managed and if Atomic CSS works for you and those that you collaborate with, then go for it. Just don't make the decision just in the development team as you need to work well with both Design and Test so they should have a say as well. Also, your way of working must work across teams, so don't start using Atomic CSS if you at any time will have other teams working in the code as well.
You know all that of course, but it is something that you can never repeat too many times.
Do you use Atomic Design today?
If you do, what benefits and pitfalls have you uncovered?
-
- 0 2675
Developer Velocity Index - one-sided nonsense or useful?
So Developer Velocity Index is a tool for measuring, well, quite a lot actually. At first glance we see a lot of focus on tools, which of course is the main goal for Microsoft as they need to get more clients for Azure Devops that is trying to challenge prominent actors such as Atlassian.
If you look a bit deeper however you will see that the DVI is pretty extensive. While focus is on tools it seems to look at these from a perspective that is not just focused on the development discipline. DVI claim to involve 46 different drivers across 13 dimensions and that is pretty good. I say claim because I have not tried this yet, so I do not know to what extent this is actually true.
The DVI is based on self-assessment through questionnaires, which is not a bad way to do this honestly. It will ensure that the introverts also get a say, which is not always the case in verbal situations where the extroverts are always loudest.
I see the tool angle a lot when reading about DVI, but when you dig down you see that what that almost always mean is that the tools in question bridge the gap between business and IT. Tools that help manage inflow, portfolio management and of course tools to help with clarifying need, especially in Agile teams. I think Tibi Covaci from Microsoft express this best:
I think this is profoundly true. Like my former colleague Eva Nordstrom would say "A fool with a tool is still a fool". Good tools with a good and well-educated organization however, that will truly generate magic. It is my hope that DVI can help illustrate the need for organizational change to help facilitate that. This is often the biggest issue in my experience and one that is very hard to overcome.
It is also no big revelation that most organizations find the funnel between business and IT to be lacking or that this is where most organizations fail. The introduction of Agile often make this worse, which is not the fault of Agile, but the way it is implemented in organizations. Hopefully DVI can illustrate the need to have a proper portfolio management on the operative level and that even in Agile work teams you need to ensure that demands are evolved.
Ad-Hoc and shooting things from the hip are sure ways to make any developer sad after all, and we all want some form of structure to our chaos to ensure we know what to do, yet remain flexible...
Developer Velocity Index is interesting, but it is still a stick that should not be needed in mature organizations. Sadly there are very few mature organizations out there, so I think this is very interesting for many reasons. I will dig into it some more and see what I can learn.
What do you think?
Is it just a selling tool for more tools you don't need, or something that can drive actual change?
-
- 1 2450
Full Stack Developer - what is that and why do you need it?
A full stack developer mean many things to many people, but the short definition is that it is a developer that knows pretty much everything in the development stack. This ranges all the way over into the design area where you are expected to know visual design, user experience and interaction design. On the other end of the spectrum you are expected to know your way around databases, app development and of course devops and even server management.
This is not all however as you are expected to be proficient in HTML, CSS, multiple java script libraries and of course multiple backend languages. It is also implied that you should know things like accessibility through WAI and WCAG, be proficient in Git, easily build using boiler plates such as Bootstrap and manage your code using SASS/LESS with a good understanding of Grunt, Polyfill, coffescript and a ton of other things. Things like Ajax and API are as natural to you as configuring proxies and doing multi system testing for email designs.
Things like testing and requirement management should be second nature to you and you should naturally work with test driven development. You should be familiar with continuous deployment into multiple environment and of course know your way around tools like Bitbucket pipelines, Anisble, Team City, Octopus deploy and Azure Devops. On the servers you should know how configurations for ngninx, apache, Litespeed and Varnish work and how it affect your work. In the database you of course know all about collations, foreign keys and how to define and build different views and structures.
This is of course a bit to much for any one person to master and that is why the term "full stack developer" is very misleading. It is also why it makes me chuckle any time I see a 25 year old put "full stack developer" on their resume as it takes a minimum of 10 years to even get close to this definition. That is assuming you actually spend most of your days working with these areas.
Even more interesting it become when you consider that most people that actually get close to a full stack developer level have long since moved away from the actual development role. They work as senior architects or in a management position because that is where their extensive experience is most useful. If you take me for example I would actually qualify as a full stack developer because I have worked in all areas and I have extensive knowledge of each. You will never find me doing any code in a professional capacity however, even if I have 25+ years experience as a developer.
If having a great understanding of the whole chain in a development pipeline is the strength of a full stack developer, then the lack of specialization and fragmented knowledge is the downside. While I can walk into any team and know what they are talking about I am never the expert in the room. There is no way I can keep the same level of expertise splitting my attention over a dozen areas as a person who can focus on 3-4 areas. There are simply not enough time to manage that.
I know many front end developers such as @Ornamo Antar and @MikaelX that are wizards on the front end while still have a respectable knowledge of both the design aspects and the devops aspects. In my mind they are absolutely full stack developers, but with a high focus on the front end. Would I put them in a back end development team or stick them in the development pipeline? No, I would not, because even if they probably will do fine, it is not where their expertise or passion is.
Another example would be @Mauron who is one of the best architects I know. His knowledge of back end development and the server stacks is second to none. He also know tons of design and front end, making him a full stack developer no question about it. Would I put him on a design team or a front end team? Of course not. His skills would be wasted there as his passion and knowledge is in other areas. He probably don't want to admit it himself, but for me he is even wasting it on doing code at all, because his ability to teach and support others are invaluable.
The answers you seek
What is a Full Stack Developer?
A full stack developer, as I see it, is an experienced developer that have extended their knowledge into the areas surrounding their core area. They are not experts in all fields, but have solid knowledge at least. They still have expert knowledge in at least one field and this is what separate them from the generalists. This level of experience usually take 10-15 years to develop depending if it is done through natural progression or through focused effort to learn new areas.
What do I do when people ask me if I am a full stack developer?
Ask them to define what a full stack developer means for them. Explain to them what your area of expertise is and how you measure up on the other areas to see if you match their expectations. If you don't get the clarification then you could end up with different expectations that lead to conflict. Better to be up front and ensure you both have the same expectations.
How do I become a full stack developer?
Focus on your area of expertise and you will naturally extend your knowledge over time. If you are a front end developer then you will naturally dip into the back end through API and working in mixed templates that are in many systems. As a back end developer you will naturally dip into operations as you dig into proxies and network configurations.
All developers will get involved in deployments (and yes you SAP people, I consider CHARM to be deployment) as well as code repositories with code versioning. Everyone work with requirements in one way or the other and everyone will deal with test.
As you become more experienced you will get into things like optimization, browser cache, network speed and even outside the system itself into SEO and CRO. You will interact with design and many, many different management tools.
In short becoming a full stack will come naturally.
If you want to speed things up then try new things! I know several people that have moved from back end to front end or vice versa and it have given them great knowledge. I also know that most front end developers dabble in UX and CRO to become better front end developers and so on. This is especially great if you are still relatively inexperienced as it will give you better understanding once you choose your area of expertise later on.
So do not be shy to experiment and extend your expertise early on, you will benefit from it greatly later on.
You can also join this site as I am very much dipping into all areas of a full stack developer. Just ask any question here and I will do my best to help you find the answers you seek so you can grow towards becoming a full stack developer.