The beauty of atomic design (and why we don’t just use it as is)
I’ll likely never forget the first official meeting we had as the newly formed design system team. It was four of us, two designers and two developers (including me). The goal of the meeting was to define the different parts of the design system and give them names that both designers and developers would understand.
“So we have ‘components’, like buttons, inputs, etc. What do you call these in the dev team?” The design lead on the team was driving the discussion.
“Components. I guess?”
“Cool! Then we have more complex objects. Like list views. What would you call those?”
…
Disclaimer
This is going to be a blog post series about our learnings at rexlabs building a design system, mostly from my perspective as a developer. At the end of each of these blog posts, you can find a TL;DR with the lessons we learned. But I hope the articles themselves will also give you some interesting insights into the problems we encountered and the ways we dealt with them.
The intention is not to tell you how exactly you should go about building your own design system. It really is more about us sharing our experience, hoping others may find…
Why create-react-app is so great and what we can learn from it
Disclaimer
This is not meant to be an article about why toolkits are awesome and super powerful; my goal is not to berate everyone who chooses not to use them. Instead I hope to provide some insight and context, based on my experience with toolkits, that allows you to decide for yourself whether or not toolkits might make your life easier, based on your specific product, team and requirements.
I should also mention that in this article I specifically look at toolkits for Javascript. …
A quick recap on why Redux isn’t dead and why you should not always listen to others
Starting with the conclusion
Mainly because it’s the most important bit of this article, but also because I’m painfully aware that very few people will read yet another one of those “Redux is not dead” monologues through to the end 😅
Choose whatever solves your specific problem and works best for you, your team and your specific setup.
That’s it. That’s all you need to take away from all of this. All solutions have their benefits and trade-offs, depending on what the exact use case, requirements and restrictions are. …
A less technical and more conceptual in-depth overview of React Suspense and our mental model of loading states
ReactInDepth is moving away from Medium. This article, its updates and more recent articles are hosted on the new platform inDepth.dev
I don’t want to dig too deep into the technical details of React Suspense and how it works under the hood, there are already plenty great blog posts, videos and conference talks out there that do that. Instead I want to focus more on the impact Suspense will have on us application developers in the way we think about loading states and architecture our apps.
Still, a brief technical introduction
To get everyone who hasn’t heard about Suspense or doesn’t really know what it…
Julian Burr
Frontend developer @rexlabs — https://github.com/julianburr
