The only frontend stack we should talk about
Explore the platform. Challenge yourself to discover what the modern web can do natively. Pure HTML, CSS, and a bit of vanilla JS…
Ethan follows up his Fluid Grids article with an equally excellent piece on resizing images.
Explore the platform. Challenge yourself to discover what the modern web can do natively. Pure HTML, CSS, and a bit of vanilla JS…
Put the kettle on. This is a long one!
Matt takes a trip down memory lane and looks at all the frontend tools, technologies, and techniques that have come and gone over the years.
But this isn’t about nostalgia (although it does make you appreciate how far we’ve come). He’s looking at whether anything from the past is worth keeping today.
Studying past best practices and legacy systems is crucial for understanding the evolution of technology and making informed decisions today.
There’s only one technique that makes the cut:
After discussing countless legacy approaches and techniques best left in the past, you’ve finally arrived at a truly timeless and Incredibly important methodology.
SPAs were a clever solution to a temporary limitation. But that limitation no longer exists.
Use modern server rendering. Use actual pages. Animate with CSS. Preload with intent. Ship less JavaScript.
It seems like the misguided perception of needing to use complex tools and frameworks to build a website comes from a thinking that web browsers are inherently limited. When, in fact, browsers have evolved to a tremendous degree
And by LLMS I mean: (L)ots of (L)ittle ht(M)l page(S).
I really like this approach: using separate pages instead of in-page interactions. I remember Simon talking about how great this works, and that was a few years back, before we had view transitions.
I build separate, small HTML pages for each “interaction” I want, then I let CSS transitions take over and I get something that feels better than its JS counterpart for way less work.
The joy of getting hands-on with HTML and CSS.
Also, tipblogging.
Responses to my thoughts on why developers would trust third-party code more than a native browser feature.
I’m trying to understand why developers would trust third-party code more than a native browser feature.
Gotta keep ‘em separated.