Friday Frontend: Explicit over DRY code Edition
Hope you had a great week! What stood out to me this week were a pair of articles arguing in favor of being explicit, even if it means duplicated code, over super tightly refactored and ‘DRY’ code. Definitely mirrors my own evolution as a coder; the longer I do this the more I lean towards extremely explicit solutions.
Also a bunch of really great CSS and JS specific articles. I particularly enjoyed the CSS motion path article, and the off-thread Vuex architecture article.
KBall from ZenDev
CSS & SCSS
Second article in a fantastic series on CSS grid. In case you missed it, I linked the last one last week. This one focuses on grid lines, which were one of the harder things for me to wrap my head around because they behave subtly differently than gutters did on old flexbox or float based grid system. However, they’re well worth learning well, especially because with named grid lines they enable some very cool semantic css.
A wonderful look through (with lots of visual examples) how different types of units scale differently both with zoom level and default font size. For someone like me with bad eyesight, it can make a huge difference if you make your site and typography react well to zoom & changed default font size.
I love this! With the latest Firefox and Edge releases it’s now supported in all major browsers to define a path along which you can place and animate objects using CSS. This dramatically increases the ease of doing complex path-based animations with pure CSS.
Wow. I was surprised - I’m pretty familiar with a lot of CSS, but this article was pretty correct, I had no idea about 6 of the 7, and honestly the 7th is a bit tongue in cheek anyway. But it’s fascinating, particularly since some of them are out of the realm of traditional web and looking at things like audio, video, and printing.
Short and sweet, looks at two different methods for stacking elements in front of/on top of one another in a page.
What I love about this article is it moves through a variety of types of testing, including some that I don’t see as often like automated accessibility testing and visual regression testing.
Very interesting look at what it would take to move state management and related computations off into a web worker so they don’t interfere with the main UI thread. I like this pattern! I’d like it more if it were wrapped up in a library or integrated with the framework in a way that you could get it for free.
Another fun Vue article, this one looking at taking a concept from GraphQL - resolvers that are invoked lazily based on need - and moving them into the front-end of your application. Super cool!
This post advocates an approach that I’ve also gravitated towards over time - being more and more explicit in my code. One naming practice I picked up recently is using very long, awkward names for functions that should only be used with extreme caution. React is a poster child for this in the OSS ecosystem, with names like
Another great look at why over-abstracting or prematurely abstracting code can lead to problems down the road. I love the framing of trading off reduced duplication for the ability to change requirements. I talked about this exact concept in a JSParty interview with Michael Chan a couple years back - “DRY” code is rigid code - there are times in a project lifecycle when that’s the right choice to make, but many times it is not.
This is a great article to get you started on performance budgets, even if your current application is super slow. I love the framing of setting up a performance budget as a safety net, not a challenge.
Super fun list of web APIs and other cool stuff that is available in browsers today, at least in experimental form. Some of these are clearly useful (e.g. web payments API), while others range from whimsical (vibrations API) to downright dangerous (native file system API), though even the dangerous ones have some great potential uses. Check them out!