Friday Frontend: Looking Back Through History Edition
This week there were a couple of really interesting articles that look back through the history of how the web developed. ‘Old CSS, new CSS’ in particular is an AMAZING article, and I highly recommend making the time to read through it.
I also greatly enjoyed the articles on memory management, exploring whether or not you need a front-end framework at all, and the ‘three types of code’.
KBall from ZenDev
P.S. A reader asked me for recommendations about where to find (particularly entry level) developer jobs, and I realized that I’ve only ever used networking to find jobs. I’d love to hear from you all what you’ve found that worked? Oh, and as a side note, if you’re looking for work or hiring I’d be happy to do a little matchmaking, just shoot me a note with what skills you have or are looking for, and what your locational constraints are.
CSS & SCSS
Oh. My. Gosh. This article is AMAZING. It’s also epically long and mostly trivia, so if you’re just looking for practical you can probably skip it. But my goodness… it goes back through the history of the web, the development of HTML and CSS, from the beginning to now, explaining what happened with a wicked sense of humor. This post is so good, it has drawn comments from folks who implemented some of the very first browsers, and folks involved with the specs.
Author puts the TLDR right up front: “yes you can do it in CSS but there’s a much better way.” However - the article is a great exploration of how you would do this if you really wanted to in CSS, highlighting a useful animation technique.
Great in-depth article on using CSS to create a flip card effect. Shows how to overcome shortcomings in traditional absolute positioning based approaches with a CSS-grid based approach.
This is a problem I’ve actually had to independently solve a couple of times, so I’m super happy to see a great explanation of “the right” way to do it. Some of the intermediate images aren’t working for me, but the teaching is great, and the example codepen lets you play along and see every step if you want.
Wow. This took someone a LOT of work, but it’s pretty cool… details the 300+ CSS properties that browsers currently support, showing the allowed values, with visuals showing how they work. It’s a little awkward to get to, but there’s also a way to interact with and tinker with all of their examples - you have to click ‘explore’ and then ‘try’, but then you can see exactly how they built the example and mess with it yourself.
This is an area of pretty common confusion, particularly with the introduction of
While this post is in the context of the recent Ember.js Octane release, and some of the examples are specific to that framework, I think the philosophical discussion of what reactivity is and how to think about it is extremely valuable and cross-framework. Vue’s reactivity system is the most obvious example of a similar approach in a different framework, but this way of thinking also can help you think about how you structure things in React, especially with tools like memoize and hooks.
Another fun walk through history, this one looking back through the history of Trident, the browser engine that powered Internet Explorer and then Edge up until the just-released chromium-based edge. Fascinating look behind the scenes of many of the IE-specific nonstandard features that were developed over the years, as well as some of the origins of functionality that DID go mainstream such as Ajax.
Not sure I agree 100% with the author’s way of classifying code, but it is definitely an interesting lense through which to view things. I might extend his definition of “Salt Mine Code” a little bit. The way he describes it, it sounds as though it is unnecessarily bad, but with the harm relatively isolated… I believe that complexity is conserved and any time you are doing something complex (or interacting with something complex), there will be some part of your code that likely cannot just be boring code. However, if this is well handled it can be isolated away (as “salt mine code”) that does not expose that complexity to either the rest of the codebase or to your users.
One thing I’m enjoying about my new job is getting to work with GraphQL. And I have to say, if you come from a traditional REST API based world, it takes some mental adjustments to do a good GraphQL design. Articles like this are a great help to start thinking of things in the “GraphQL Way”.