I bought this mug recently for use at work. Being a professional web developer, I decided it would establish me as the office's king of irony. The joke on it isn't unique, of course. I've seen it everywhere from t-shirts to conference presentations.
Last month Chris Coyier wrote a post investigating the question, "When Does a Project Need React?" In other words, when do the benefits of using React (acting as a stand-in for data-driven web frameworks in general), rather than server-side templates and jQuery, outweigh the added complexity of setting up the requisite tooling, build process, dependencies, etc.? A week later, Sacha Greif wrote a counterpoint post arguing why you should always use such a framework for every type of web project. His points included future-proofing, simplified workflow from project to project (a single architecture; no need to keep up with multiple types of project structures), and improved user experience because of client-side re-rendering, even when the content doesn't change very often.
We've all been there. You've got an element you want to be able to collapse and expand smoothly using CSS transitions, but its expanded size needs to be content-dependent. You've set
transition: height 0.2s ease-out. You've created a
collapsed CSS class that applies
height: 0. You try it out, and... the height doesn't transition. It snaps between the two sizes as if
transition had never been set. After some fiddling, you figure out that this problem only happens when the height starts out or ends up as
auto. Percentages, pixel values, any absolute units work as expected. But all of those require hard coding a specific height beforehand, rather than allowing it to naturally result from the size of the element content.