Articles by
Robin Rendle

Technical writer, CEO of staring blankly at a screen full of CSS, pro-blogger

ECMAScript Modules in Browsers

As Jake Archibald says, they are starting to land! The support landscape is already:

  • Safari 10.1.
  • Chrome Canary 60 – behind the Experimental Web Platform flag in chrome:flags.
  • Firefox 54 – behind the dom.moduleScripts.enabled setting in about:config.
  • Edge 15 – behind the Experimental JavaScript Features setting in about:flags.

There are plenty of weird gotchas to be aware of, like minor syntax things that are intentionally not supported, and the order of script execution.

We covered Stefan Judis's post, who's sure we'll continue to bundle:

Just because we might have support for ES6 modules in browsers soon, it doesn't mean that we can get rid of a build process and a proper "bundle strategy".

But there are folks who wish all this wasn't so complicated, like Pawel Grzybek:

Three things that I wish I could ditch from my everyday front-end workflow: CSS preprocessors, JavaScript transpilers and module bundlers.

Does CSS Grid Replace Flexbox?

No. Well. Mostly No.

Grid is much newer than Flexbox and has a bit less browser support. That's why it makes perfect sense if people are wondering if CSS grid is here to replace Flexbox.

To put a point on it:

  1. Grid can do things Flexbox can't do.
  2. Flexbox can do things Grid can't do.
  3. They can work together: a grid item can be a flexbox container. A flex item can be a grid container.

(more…)

Getting Started with CSS Grid

This was a blockbuster week for front-end developers as CSS Grid landed in the latest versions of Firefox and Chrome without a feature flag. That's right: we can now go and play with Grid in two of the most popular browsers right away.

But why is CSS Grid a big deal and why should we care?

Well, CSS Grid is the first real layout system for the web. (more…)

Annotation is Now a Web Standard

This sure is exciting news: the various groups that make up the W3C have agreed upon a set of rules by which we’ll be able to annotate, highlight and make comments to a webpage without the need of a third party script or framework.

Dan Whaley describes why this could be a big deal:

The W3C standards are a key milestone towards a future in which all pages could support rich layers of conversation without requiring any action by their publishers—because that capability can be built into the browser itself and be available as a native feature, just like like web search. The shared vision is that conversations will be able happen anywhere on the Web, or even on documents in native apps, and inline instead of below-the fold, in a federated, standards-based way.

HTML APIs: What They Are And How To Design A Good One

Lea Verou writes about the design of HTML APIs and how we might write better documentation for web designers. An HTML API is term for a JavaScript library that is configured and controlled through HTML rather than through JavaScript. For example <div data-open-modal="#modal"></div> might tell a library that this element is in charge of opening a modal. There is no configuration or initting other than loading the library itself.

My favorite part of this piece is where Lea confronts what might generally be seen as a simple plug-n-play JavaScript library:

Even this tiny snippet of code requires people to understand object literals, arrays, variables, strings, how to get a reference to a DOM element, events, when the DOM is ready and much more. Things that seem trivial to programmers can be an uphill battle to HTML authors with no JavaScript knowledge

By giving folks an HTML API we can avoid potential headache.

...remember that many of these people do not speak any programming language, not just JavaScript. Do not talk about models, views, controllers or other software engineering concepts in text that you expect them to read and understand. All you will achieve is confusing them and turning them away.

Lea's made a collection of libraries that have HTML APIs.

Optimizing GIFs for the Web

Ire Aderinokun describes a frustrating problem that we’ve probably all noticed at one point or another:

Recently, I’ve found that some of my articles that are GIF-heavy tend to get incredibly slow. The reason for this is that each frame in a GIF is stored as a GIF image, which uses a lossless compression algorithm. This means that, during compression, no information is lost in the image at all, which of course results in a larger file size.

To solve the performance problem of GIFs on the web, there are a couple of things we can do.

Switching to the <video> element seems to have the biggest impact on file size but there are other optimization tools if you have to stick with the GIF format.

Most of the web really sucks if you have a slow connection

Dan Luu on the sorry state of web performance:

...it’s not just nerds like me who care about web performance. In the U.S., AOL alone had over 2 million dialup users in 2015. Outside of the U.S., there are even more people with slow connections.

This other note is also interesting, and I think that Dan is talking about Youtube’s project “Feather” here:

When I was at Google, someone told me a story about a time that “they” completed a big optimization push only to find that measured page load times increased. When they dug into the data, they found that the reason load times had increased was that they got a lot more traffic from Africa after doing the optimizations. The team’s product went from being unusable for people with slow connections to usable, which caused so many users with slow connections to start using the product that load times actually increased.

icon-anchoricon-closeicon-emailicon-linkicon-logo-staricon-menuicon-nav-guideicon-searchicon-staricon-tag