Co-location, CSS-in-JS, and software engineering best practices
Awesome that you are here. This week’s top software engineering reads are all about programming best practices and whether or not they are still valid. I am sure you are familiar with the separation of concerns and the DRY (Don’t repeat yourself) principles.
But, DRY hasn’t such a great reputation anymore and, did you know that co-location is the hottest thing right now?
What does this really mean and when you should take principles with a grain of salt? Let’s find out through my newest top software engineering reads. Enjoy!
Co-location
In this article, Kent C Dodds reasons about why your code should always be co-located with almost everything that is closely associated with it. The main idea behind is that things that work together should be together. So this means that he suggests that code and tests should be in the same folder, or even in the same file. Comments should be in the code file, and not saved and edited somewhere central. But Kent goes even further, he argues for caution with extracting utility functions, and for CSS-in-JS. Especially the CSS-in-JS part was intriguing and somewhat contra-intuitive for me. I am a big fan of the principle of separation of concerns. Still, I am not a react developer, so I found it more than interesting to read on about this “movement”.
The CSS-in-JS movement
So, intrigued by CSS-in-JS, I continued reading the article by Mark Dalgleish. In this article, he explains why co-location of CSS and Javascript can be beneficial. His first argument is that this allows you to avoid problems with the scope of the CSS styles for larger projects because the BEM (Block Element Modifier) principle is already backed-into CSS-in-JS.
Now, if you imagine that CSS-in-JS as attaching styles directly to each element, you are somewhat right. That’s how this movement started. But this early version is nowadays mostly replaced by a focus on dynamic style sheets. Well, if that all sounds interesting to you, read on to learn more here.
Best practices thread on Twitter
On Twitter, an interesting discussion I want to share with you was started by Dan Abramov. He asked which “best practices” we learned when we just started out programming. This thread is a real treasure, as it has many interesting discussions, and reflects nicely how the perception on principles such as DRY (Don’t repeat yourself) or the separation of concern principle changed over time. If you are interested, here is the twitter thread for you to dive in…
Gumroad founder’s successful failures
Quite a different read is the story of Gumroad’s founder. In his recent blog post, he shares how he failed to make Gumroad the next Silicon Valley unicorn and how this failure helped him realize what it means to build a sustainable and healthy business. I really enjoyed reading his failure/success story.
Hashnode switched to Caddy
Hashnode is a community of developers and they recently introduced developer blogs. And when they introduced this new (really cool and very well-made) perk that every developer can have their own SSL enabled blog, they run into trouble. The performance for their old tooling used for the webservers wasn’t as good as they wished. So, they changed to Caddy. Caddy is a web server with automatic HTTPS. Here is the full story on how and why they moved away from nginx to caddy.
Noobs
Well, this isn’t something to read. Rather something to play. In this interesting project, you get to play with different kind of APIs that challenge your creativity. What does it exactly do? Well, that’s up to you and me. I haven’t had the time to play around with it yet, but I found the idea funny. So maybe, if you need a break, have a look.
So, this was the third edition of my engineering reads. I start to like this theme more and more. I really enjoy summarizing the articles for you, and I love choosing and combining the article in a way that brings value to you. Let me know how you like it and leave awesome articles you recently read in the comments.
Don’t forget to sign-up to my email list. I’ll make sure to only send you relevant emails. And, you never miss a blog post.
I want in!
As a subscriber, you profit, in addition to my awesome emails about software engineering, also from exclusive treats I prepare for you, such as my code review e-Book.
