Is someone actually doing this? A peer wanted to. He was pretty much just doing some atoms and was enthusiastic about it. But that project fell apart because he had no real idea how to put everything together. I feel this concept is more like a well told story then something productive useful.
I'm sure many others, since it's an industry trend at the moment, I think because of Google's Material Design.
It's particularly useful for very large sites where it's impractical for a designer to design every single page individually- This is a way to break a site down into a system. You might quite rightly wonder how that is different from just having templates.
Atomic design includes templates, it just breaks things down to smaller pieces as well, so that a designer has an opportunity to make smaller elements like buttons, colours, widgets, forms etc consistent with each other and align to a designed grid. It reigns in some of the visual chaos and aligns extremely well to "component based" front end frameworks like react.
If there's anything that this sort of thing can hopefully achieve, is greater consistency in typographic grids and rhythm. The downside of this is it can tend to make websites look incredibly bland and samey- the other side of the coin to improving consistency.
We use most of the principles of atomic design, but not the terminology. Atoms and molecules and whatnot are a cute analogy but make the concepts harder to explain, not simpler.
It’s pretty simple: Design the smallest bits - headings, paragraphs, buttons etc, and combine them into progressively larger components. Use only those components, adding new ones if absolutely necessary.
At work we’re in the process of moving a 20+ year old website with many thousands of pages to a completely component-based system. We’ve gone from about 70 templates to three, massively simplified the stylesheet and increased development speed as new pages are built from ready-made and tested components rather than buildings every page from scratch.
By doing this it means that UX, design and code can be kept consistent through design, development and maintenance.
Atomic design principles are super fit for React component libraries. I don't take the atoms > molecules > organisms pattern quite literally though, as functionally, it makes more sense to group atoms and molecules (composed of atoms) into a single dictionary of components, like a toolkit. I simply `import { hammer, nails, thumb } from tools`...
And then, my organisms are usually groups of organs, that are specific implementations or modules within the app. Anytime I build an abstraction of an organ to be used in multiple organisms, it can probably be added to my toolkit.
Also, I use CSS-Modules and avoid Redux wherever possible, because I build my applications such that state, style, and function are all local & self-contained... avoiding global variables as much as I can.
In my experience, Atomic Design's interesting principle is that of separating Atoms and Molecules. Between Molecules and Organisms it gets fuzzy and arbitrary, and Pages/Page Templates are not a new concept. It's a cool-sounding design language tool and Atoms are really useful, but that's the only positive innovation I've experienced from using it at a previous workplace.
I can't find justifications for going beyond App -> Page -> Components, and introduce lower levels. You can rule out Atoms as layer if you work with a style guide and define them globally at the app level. You'd override or modify "Atoms" values at the component level if you need to. Even just a word or text can be regarded as component if you include the surrounding whitespace. Whitespace matters!
The conclusion is that the highest and lowest levels are actually the same! You build your components from the global style guide/CSS stylesheet!
The benefit of atoms at the company I was at, was to force developers to build reusable micro-components (the type of thing you'd put in your "components" directory in react/redux apps). Otherwise, I agree if that job is already being done properly.
We use it for React+Redux, and the molecule/organism split is actually the best defined one for us: Organisms are connected to the Redux store, molecules and below are not. Organisms are for specific parts of the site, and tend to be tied to that part, while molecules and below are all much more reusable and so we have to avoid tying them to specific data from Redux.
(Mostly at least, there has been some leakage where we broke this pattern, but it's true for like 95% of our components)
