Cool Links

Jake gives a really thorough explanation on view transitions, showing some of its shortcomings when animating some specific elements and how to fix them. View transitions are so nice 🤩

The smoothness of a web application is an anti-indicator of its reliability and predictability as a web page.

your team almost certainly doesn’t have what it takes to out-engineer the browser. The browser will continuously improve the experience of plain HTML, at no cost to you, using a rendering engine that is orders of magnitude more efficient than JavaScript.

I remember when I first learned about SPAs and how amazing it seemed like to be able to have smooth transitions between pages. Then, as I started building and using them, it became apparent that those benefits also brought a lot of issues that took a lot of dev work to fix.

Luckily, with View Transitions, lazy loading, and predictive pre-rendering (start loading a page before you click on its link) that a lot of frameworks have now, we can have most of the SPA benefits without having to reinvent the wheel.

Incredible article that not only explains the new-ish text-wrap: balance and text-wrap: pretty CSS properties in-depth, it also goes into the caveats those properties have. It’s well-written, well illustrated, and interactive. What else could you want?

Ahmad once again writing the articles I wish I did. Another well-written and interactive article going in-depth on the also new-ish overflow: clip CSS property. clip has helped me implement designs more than once and it’s so nice to have something that works just like I always expected overflow: hidden to work.

A really well-designed post from the Chrome team showing the coolest new things that were introduced to CSS in 2024. A lot of the things in there are really cool! The sad part is that, unless you’re running an up-to-date Chromium browser, you might not be able to see them in action. I initially saw this blog post on my iPhone (which only has access to Safari) and almost none of them worked.

It’s always fun to see these “State of…” surveys. Noteworthy thing being Astro completely dominating the framework numbers (except for usage, but I can totally see it becoming #1 soon).

Josh has always been one of my favorite bloggers, and this blog post is awesome. You’ve probably seen me talking about Progressive Enhancement before, and this article talks about browser support and figuring out how and where to progressively enhance things.

This is the best explanation of the new HTML/CSS popover API that I’ve seen. It still looks overly complex, mind you, and I’m not sure I like that API. But if you wanna find out about what it is and possible use cases, this video is a nice start!

Great article reflecting on how job descriptions usually suck and how hard it is to find a job working with the things you want to work on, especially if your expertise is in the gap between two different job descriptions. Turns out the easiest way is to try and carve out a way into the work you do best.

Nowadays it seems most packages and developers expect you to use a build system like Vite, Webpack, or anything with NodeJS to build websites.

That shouldn’t be true, but if you’re ever building a simple buildless website and want to use packages, Julia Evans explain how to do that and also a bit of how the different kinds of JS modules work.

Optimizing the resources your website loads is the best way of making sure it loads faster for everyone. I’ve talked before about ways of doing that, but turns out there’s a new, better way of telling browsers what they should load first!

The article has many examples of use cases, but these are my favorites:

• Hero images: “Images inside the viewport typically start at a Low priority. After the layout is complete, Chrome discovers that they’re in the viewport and boosts their priority. This usually adds a significant delay to loading the critical images, like hero images.”
• Image Carousels: “For example, in an image carousel, only the first visible image needs a higher priority, and the others, typically offscreen initially can be set to have lower priority.”

A neat little web component that displays Baseline status of any web feature, that you can quickly add to any web page you want.

I might use this in future blog posts here!

Building on the previous paradox: did you know that HTML was originally meant to be understandable and writable by anyone?

Before us web devs came along and scared people off, HTML was actually seen as a very simple way of structuring and linking data.

And it still is! This course aims to teach HTML to people with no technical knowledge, so they’re able to build their own simple web pages (or just mess around with existing ones, which is really fun).

These “State of” results are always fun, if only for the graphics alone. This one has pretty good data though, as 2024 was one of CSS’s best years, with Container Queries, :has() (which allows for Quantity Queries), native nesting, native page transitions, and more.

I’ve been growing increasingly unhappy with JavaScript frameworks as of late, but I still have a soft spot for Svelte. Svelte is what my blog is built with, and it’s always been a pleasure to use. Version 5 significantly changes some of its core features, apparently for the better. I’m excited to upgrade eventually (and really glad that they kept backwards compatibility).

The web is, at its core, just links to HTML files with some CSS and JS on top. That’s how it was years ago and how it technically still is.

Over the years, things became more complex and many layers of abstraction were introduced. A lot of web developers have never had any real contact with the core of the web.

So we ended up on a place where it’s much easier to find and use an overly-complex, bloated solution for websites than just having the bare minimum (that usually works better).

Isn’t that wild? In the author’s words:

“the web doesn’t belong just to software engineers. The more we make the web complex, the more we push normal users into the enclosures that we like to call social networks.”

I’ve been a web developer for over 10 years now and I can afford the luxury of building my own website - a static, simple, lean one. People with less or no coding knowledge can’t have that. They need to use tooling that ships so much code and complexity if they want to have their own. Or, even worse - they’ll stick to social media platforms instead. 😱

nvm (Node Version Manager) is one of the best tools in my web dev toolkit. It allows you to keep multiple versions of NodeJS installed, which is usually a must if you swap between different projects all day. I’d even say it’s worth it even if you only have one version, since installing NodeJS via nvm is way easier than the official way.

This is a way of using nvm with a graphical interface, in case you’re not too fond of CLIs (or simply prefer a simple GUI instead).

I’ve complained about Safari multiple times in my posts and social media, and I’m not alone. This document pretty much aggregates all the issues Safari has been causing for years and how users (and devs) often have no choice of browser to run to when Safari decides it doesn’t want something to work.

I am 100% in favor of browser engine diversity, and definitely don’t want Chromium to be the only option out there. But Safari (and WebKit, its “heart”) is not a fair competitor because the majority of its users (on iOS and iPadOS) don’t have the option of using something else. And when Safari has time and time again had issues with the implementation of new APIs and, even worse, had issues with having old APIs working in a completely different way from other browsers, we have a problem.

And to make it all worse, Apple clearly has financial incentives to make Safari lag behind. A limited web experience means the only way to provide your service to users on iOS is by releasing an app… on Apple’s App Store. They can’t monetize web browsing, so why make it work well?

This article dives into how the author built a logo strip (i.e. a grid of company logos with varying widths and heights) and the techniques they used to make their weight nicely distributed, way beyond what most people have done in the past (including me). I’ll definitely be using that next time!

I feel like more and more web developers are becoming “Framework Developers”, which means they only really develop with one specific (or maybe two) JS frameworks. This is a problem because these frameworks often change how you interact with web technology. In the end, everything gets compiled to HTML, CSS and JS, but when your dev environment is so different from that, it’s hard to understand exactly what you’re building.

If you already know HTML, CSS and JS, then you can make that association while you’re learning the framework, and things happen naturally. When the opposite happens, though, the path is more difficult.

A HTML, CSS and JS developer can learn any framework (and jump between them) with relative ease, while a React developer might have a hard time working with Vanilla JS or Svelte, for example, because they only learned the React way of thinking instead of how browsers interpret the code.

I do use a JavaScript framework (Svelte) on my website and personal projects, but I’m glad I learned the underlying technologies before diving into any framework. Having that foundation has allowed me to work professionally with a lot of different stacks (Vanilla, React, Vue, Angular, Svelte) while still keeping my foundational skills intact.