Tags: script



Saturday, June 23rd, 2018

I Don’t Believe in Full-Stack Engineering • Robin Rendle

A good ol’ rant from Robin.

HTML and CSS and JavaScript have always been looked down upon by many engineers for their quirks. When they see a confusing and haphazardly implemented API across browsers (HTML/CSS/JS), I see a swarming, writhing, and constantly improving interface that means we can read stuff that was written fifteen years ago and our browsers can still parse it.

Before jumping to conclusions, read the whole thing. Robin isn’t having a go at people who consider themselves full-stack developers; he’s having a go at the people who are only hiring back-end developers and expecting them to automatically be “full stack.”

Friday, June 22nd, 2018

Offline-Friendly Forms by Max Böck

A clever use of localStorage to stop data from being lost when your visitors are offline.

Thursday, June 21st, 2018

Generative Artistry

Tutorials for recreating classics of generative art with JavaScript and canvas.

Friday, June 8th, 2018

Registering service workers

In chapter two of Going Offline, I talk about registering your service worker wrapped up in some feature detection:

if (navigator.serviceworker) {

But I also make reference to a declarative way of doing this that isn’t very widely supported:

<link rel="serviceworker" href="/serviceworker.js">

No need for feature detection there. Thanks to the liberal error-handling model of HTML (and CSS), browsers will just ignore what they don’t understand, which isn’t the case with JavaScript.

Alas, it looks like that nice declarative alternative isn’t going to be making its way into browsers anytime soon. It has been removed from the HTML spec. That’s a shame. I have a preference for declarative solutions where possible—they’re certainly easier to teach. But in this case, the JavaScript alternative isn’t too onerous.

So if you’re reading Going Offline, when you get to the bit about someday using the rel value, you can cast a wistful gaze into the distance, or shed a tiny tear for what might have been …and then put it out of your mind and carry on reading.

Tuesday, June 5th, 2018

Fresher service workers, by default

“Ah, this is good news!”, I thought, reading this update about how service worker scripts won’t be cached.

And that was the moment when I realised what an utter nerd I had become.

Monday, June 4th, 2018

Web Components Club – A journal about learning web components

Andy Bell is documenting is journey of getting to grips with web components. I think it’s so valuable to share like this as you’re learning, instead of waiting until you’ve learned it all—the fresh perspective is so useful!

Sunday, June 3rd, 2018

The React is “just” JavaScript Myth - daverupert.com

In my experience, there’s no casual mode within React. You need to be all-in, keeping up with the ecosystem, or else your knowledge evaporates.

I think Dave is right. At this point, it’s possible to be a React developer exclusively.

React is an ecosystem. I feel like it’s a disservice to anyone trying to learn to diminish all that React entails. React shows up on the scene with Babel, Webpack, and JSX (which each have their own learning curve) then quickly branches out into technologies like Redux, React-Router, Immutable.js, Axios, Jest, Next.js, Create-React-App, GraphQL, and whatever weird plugin you need for your app.

And, as Jake points out, you either need to go all in or not at all—you can’t really incrementally add Reactness to an existing project.

Thursday, May 31st, 2018

Design Patterns on CodePen

This ever-growing curated collection of interface patterns on CodePen is a reliable source of inspiration.

UTC is Enough for Everyone, Right?

A wonderful—and humorous—deep dive into all things time-related.

Building a calendar sucks. Like there’s really cool shit you can do, since every calendar out there today is basically straight outta 2005, but at the end of the day you’re stuck dealing with all of the edge cases that all your dork friends have warned you about since the dawn of time. (Like literally, the dawn of time is a separate edge case you have to account for as well.)

This also contains a well-deserved shout-out to ISO 8601:

ISO 8601 is one of my favorite standards and/or RFC out there. And yes, you should definitely have a favorite.

I do have a favourite RFC—ask me about it sometime over a beer.

Wednesday, May 30th, 2018

Solving Life’s Problems with CSS | CSS-Tricks

It turns out that Diana Smith isn’t just a genius with CSS—she’s a fantastic writer too. This post is somehow heartfelt and lighthearted at the same time. It’s also very humorous, but beneath the humour there’s an excellent point here about the rule of least power …and doing things the long, hard, stupid way.

Because something about those limitations just calls to me. I know I’m not alone when I say that a rigid set of restrictions is the best catalyst for creativity. Total artistic freedom can be a paralyzing concept.

That can sometimes be the case with programming. If you have the most powerful programming languages in the world at your disposal, it starts to seem natural that you should then have no difficulty solving any programming problem. With all these amazing tools offering countless solutions to solve the same problem, it’s no wonder that we sometimes freeze up with information overload.

Tuesday, May 29th, 2018

Web Push Notifications Demo | Microsoft Edge Demos

Push notifications explained using astrology. But don’t worry, there’s also some code, just in case you prefer your explanations to also include models that actually work.

Consently - Privacy-friendly and GDPR compliant tracking

This looks very useful: a script that will allow visitors to tailor which tracking scripts they want to allow. Seems like a win-win to me: useful for developers, and useful for end users. A safe and sensible approach to GDPR.

Saturday, May 26th, 2018

CSS and Markup in Javascript is an Evolutionary Dead End

The bet to make is that we’re going to see more use of specialized languages. And HTML and CSS are the grandaddy specialized languages that have enough social consensus and capital investment to be the seeds of the next generation.

Wednesday, May 23rd, 2018

Tuesday, May 22nd, 2018

Easy Toggle State

I think about 90% of the JavaScript I’ve ever written was some DOM scripting to handle the situation of “when the user triggers an event on this element, do something to this other element.” Toggles, lightboxes, accordions, tabs, tooltips …they’re all basically following the same underlying pattern. So it makes sense to me to see this pattern abstracted into a little library.

Monday, May 21st, 2018

Identifying, Auditing, and Discussing Third Parties – CSS Wizardry

Harry describes the process he uses for auditing the effects of third-party scripts. He uses the excellent Request Map which was mentioned multiple times at the Delta V conference.

The focus here is on performance, but these tools are equally useful for shining a light on just how bad the situation is with online surveillance and tracking.

Meet swup

This looks like a handy library for managing page transitions on sites that are not single page apps.

Here’s the code.

I’ve said it before and I’ll say it again, but I really think that this handles 80% of the justification for using a single page app architecture.

Saturday, May 19th, 2018

The Slow Death of Internet Explorer and the Future of Progressive Enhancement · An A List Apart Article

Oliver Williams makes the case—and shows the code—for delivering only HTML to old versions of Internet Explorer, sparing them from the kind of CSS and JavaScript that they can’t deal with it. Seems like a sensible approach to me (assuming you’re correctly building in a layered way so that your core content is delivered in markup).

Rather than transpiling and polyfilling and hoping for the best, we can deliver what the person came for, in the most resilient, performant, and robust form possible: unadulterated HTML. No company has the resources to actively test their site on every old version of every browser. Malfunctioning JavaScript can ruin a web experience and make a simple page unusable. Rather than leaving users to a mass of polyfills and potential JavaScript errors, we give them a basic but functional experience.

Super-powered layouts with CSS Variables + CSS Grid by Michelle Barker on CodePen

This article is about using custom properties and CSS grid together, but I think my favourite part is this description of how custom properties differ from the kind of variables you get from a preprocessor:

If you’re familiar with Javascript, I like to think of the difference between preprocessor variables and CSS Variables as similar to the difference between const and let - they both serve different purposes.

Friday, May 18th, 2018


I had some problems with my bouzouki recently. Now, I know my bouzouki pretty well. I can navigate the strings and frets to make music. But this was a problem with the pickup under the saddle of the bouzouki’s bridge. So it wasn’t so much a musical problem as it was an electronics problem. I know nothing about electronics.

I found it incredibly frustrating. Not only did I have no idea how to fix the problem, but I also had no idea of the scope of the problem. Would it take five minutes or five days? Who knows? Not me.

My solution to a problem like this is to pay someone else to fix it. Even then I have to go through the process of having the problem explained to me by someone who understands and cares about electronics much more than me. I nod my head and try my best to look like I’m taking it all in, even though the truth is I have no particular desire to get to grips with the inner workings of pickups—I just want to make some music.

That feeling of frustration I get from having wiring issues with a musical instrument is the same feeling I get whenever something goes awry with my web server. I know just enough about servers to be dangerous. When something goes wrong, I feel very out of my depth, and again, I have no idea how long it will take the fix the problem: minutes, hours, days, or weeks.

I had a very bad day yesterday. I wanted to make a small change to the Clearleft website—one extra line of CSS. But the build process for the website is quite convoluted (and clever), automatically pulling in components from the site’s pattern library. Something somewhere in the pipeline went wrong—I still haven’t figured out what—and for a while there, the Clearleft website was down, thanks to me. (Luckily for me, Danielle saved the day …again. I’d be lost without her.)

I was feeling pretty down after that stressful day. I felt like an idiot for not knowing or understanding the wiring beneath the site.

But, on the other hand, considering I was only trying to edit a little bit of CSS, maybe the problem didn’t lie entirely with me.

There’s a principle underlying the architecture of the World Wide Web called The Rule of Least Power. It somewhat counterintuitively states that you should:

choose the least powerful language suitable for a given purpose.

Perhaps, given the relative simplicity of the task I was trying to accomplish, the plumbing was over-engineered. That complexity wouldn’t matter if I could circumvent it, but without the build process, there’s no way to change the markup, CSS, or JavaScript for the site.

Still, most of the time, the build process isn’t a hindrance, it’s a help: concatenation, minification, linting and all that good stuff. Most of my frustration when something in the wiring goes wrong is because of how it makes me feel …just like with the pickup in my bouzouki, or the server powering my website. It’s not just that I find this stuff hard, but that I also feel like it’s stuff I’m supposed to know, rather than stuff I want to know.

On that note…

Last week, Paul wrote about getting to grips with JavaScript. On the very same day, Brad wrote about his struggle to learn React.

I think it’s really, really, really great when people share their frustrations and struggles like this. It’s very reassuring for anyone else out there who’s feeling similarly frustrated who’s worried that the problem lies with them. Also, this kind of confessional feedback is absolute gold dust for anyone looking to write explanations or documentation for JavaScript or React while battling the curse of knowledge. As Paul says:

The challenge now is to remember the pain and anguish I endured, and bare that in mind when helping others find their own path through the knotted weeds of JavaScript.