#173

(Robin): Despite so much of our economy being set on the foundation of the World Wide Web, I’ve always felt a little uncomfortable about the way that folks talk about it. On stage and in front of hundreds of engineers, people will joke about how hyperlinks are simplistic and boring — portals are the way of the future, man! And I’ve seen how designers will talk about native apps and how they’re better designed, more focused, more beautiful. Seems like there’s so much dissing on the web.

This bugs me an awful lot and I’m not entirely sure why.

Maybe it’s because, even in its original state—without CSS, without JavaScript — the web is still the most impressive thing in the world to me. The fact that you can push a bit of text onto a server and send someone a URL is nothing short of magic. It’s the stuff of science fiction.

Why doesn’t everyone else see the web this way?

I think the web is often seen from a reader’s point of view: they have to deal with extremely intrusive advertising on a daily basis, whether that’s newsletter modals, pop-ups and scroll-hacking, not to mention terrible performance, accessibility and typesetting. No wonder some people hate the web and immediately ask for an app instead.

The web is simply not a respectable place for learning new things for reasons like these, and over time, using it to become a better person. The web is a nightmare in that sense.

But this week, Garrett Dimon wrote about The Web We’ve Made and argues that it doesn’t have to be this way:

Every day, we’re all making choices and crafting the web. In some cases, we can forsake bloated analytics. Or we can avoid bloated front-end frameworks when they create more problems than they solve. We can avoid or delay using features that require brittle polyfills until they’re widely supported in browsers natively. We can care about sending less JavaScript or fewer useless images. We can take steps to learn about and improve accessibility for everyone.

Or, more simply put, we can care a little more about the people on the receiving end of our work. Then, just maybe, after another decade, we’ll have built the web we all want.


📝 From the blog

Finally, it Will Be Easy to Change the Color of List Bullets

There’s a long history of developers wanting to be able to customize the style of list bullets, and as Chris writes here, it’s possible to do that with a new pseudo element called ::marker! Here’s what that looks like:

li::marker {
  color: red;
  content: "►";
}

Without having to do all the bonkers hacks of yesteryear this will style those gosh dang bullets once and for all! Currently, however, this is only possible in later versions of Firefox, Safari and iOS Safari.


JAMstack CMSs Have Finally Grown Up!

Brian Rinaldi looks at just how much CMSs have progressed recently, and if you haven’t looked at the various options available, then Brian has got you covered on that front, too:

Netlify CMS, an open-source project from Netlify, is an example of a git-based CMS. A git-based CMS doesn’t store your content, as a traditional CMS would, but it has tools that understand how to edit things like Markdown, YAML, JSON and other formats that make up a JAMstack site. This gives the content editors tools they feel comfortable with, but, behind the scenes, their content changes are simply committed back into the repository, forcing a rebuild of the site.

I think the really interesting stuff that’s happened lately is the decoupling of all these services — you can store all your content in Git or a service like Contentful without having to do platform-specific things as you might have to with something like WordPress. This is incredibly neat! Plus it means you can move from one service to another and your content or codebase isn’t necessarily trapped or locked away.

And, soon enough, we’ll be able to edit all this content the same we would a Medium post, like this:


When to Use SVG vs. When to Use Canvas

As Chris shows in this post, there’s a lot to consider and it entirely depends upon what you’re building! But Benjamin De Cock writes in to make things a tad easier for us:

One extremely basic way to answer it is “use canvas when you cannot use svg” (where “cannot” might mean animating thousands of objects, manipulating each pixel individually, etc.). To put it another way, SVG should be your default choice, canvas your backup plan.

And Sarah Drasner follows that up with a cracking list of pros and cons for both SVG and Canvas:


Making an Audio Waveform Visualizer with Vanilla JavaScript

Speaking of the Canvas API, Matthew Ström takes a running leap into the nitty gritty details of the Web Audio API to build a visualization of an audio file that looks something like this:

I love the way that Matthew breaks up tough and complicated problems and it’s always fascinating to see how he thinks through things. I particularly love this bit from the conclusion, too:

This is a very, very impractical way of visualizing audio. It runs on the client side, processing millions of data points into a fairly straightforward visualization.

But it’s cool! I learned a lot in writing this code, and even more in writing this article. I refactored a lot of the original project and trimmed the whole thing in half. Projects like this might not ever go on to see a production codebase, but they are unique opportunities to develop new skills and a deeper understanding of some of the neat APIs modern browsers support.


SPONSOR

WooCommerce

WooCommerce is the most popular e-commerce platform on the web. Use WooCommerce to sell anything from luxury mattresses and cupcakes, to date-driven sales like kayak lessons, to one-off items like beautiful hand-crafted jewelry.

Start selling →