Jeremy Keith

Jeremy Keith

Making websites. Writing books. Speaking at conferences. Living in Brighton. Working at Clearleft. Playing music. Taking photos. Answering email.

Journal 2321 Articles 64 Links 6021 Notes 2498

Tuesday, July 26th, 2016

Monday, July 25th, 2016

Animating

I’ve noticed a few nice examples of motion design on the web lately.

The Cloud Four gang recently redesigned their site, including a nice little animation on the home page.

Malcolm Gladwell has a new podcast called Revisionist History. The website for the podcast is quite lovely. Each episode is illustrated with an animated image. Lovely!

If you want to see some swishy animations triggered by navigation, the waaark websites has them a-plenty. Personally I find the scroll-triggered animations on internal pages too much to take (I have yet to find an example of scrolljacking that doesn’t infuriate me). But the homepage illustrations have some lovely subtle movement.

When it comes to subtlety in animation, my favourite example comes from Charlotte. She recently refactored the homepage of the website for the Leading Design conference. It originally featured one big background image. Switching over to SVG saved a lot of bandwidth. But what I really love is that the shapes in the background are now moving …ever so gently.

It’s like gazing at a slow-motion lava lamp of geometry.

Class teacher

ES6 introduced a whole bunch of new features to JavaScript. One of those features is the class keyword. This introduction has been accompanied by a fair amount of concern and criticism.

Here’s the issue: classes in JavaScript aren’t quite the same as classes in other programming languages. In fact, technically, JavaScript doesn’t really have classes at all. But some say that technically isn’t important. If it looks like a duck, and quacks like a duck, shouldn’t we call it a duck even if technically it’s somewhat similar—but not quite the same—species of waterfowl?

The argument for doing this is that classes are so familiar from other programming languages, that having some way of using classes in JavaScript—even if it isn’t technically the same as in other languages—brings a lot of benefit for people moving over to JavaScript from other programming languages.

But that comes with a side-effect. Anyone learning about classes in JavaScript will basically be told “here’s how classes work …but don’t look too closely.”

Now if you believe that outcomes matter more than understanding, then this is a perfectly acceptable trade-off. After all, we use computers every day without needing to understand the inner workings of every single piece of code under the hood.

It doesn’t sit well with me, though. I think that understanding how something works is important (in most cases). That’s why I favour learning underlying technologies first—HTML, CSS, JavaScript—before reaching for abstractions like frameworks and libraries. If you understand the way things work first, then your choice of framework, library, or any other abstraction is an informed choice.

The most common way that people refer to the new class syntax in JavaScript is to describe it as syntactical sugar. In other words, it doesn’t fundamentally introduce anything new under the hood, but it gives you a shorter, cleaner, nicer way of dealing with objects. It’s an abstraction. But because it’s an abstraction taken from other programming languages that work differently to JavaScript, it’s a bit of fudge. It’s a little white lie. The class keyword in JavaScript will work just fine as long as you don’t try to understand it.

My personal opinion is that this isn’t healthy.

I’ve come across two fantastic orators who cemented this view in my mind. At Render Conf in Oxford earlier this year, I had the great pleasure of hearing Ashley Williams talk about the challenges of teaching JavaScript. Skip to the 15 minute mark to hear her introduce the issues thrown up classes in JavaScript.

More recently, the mighty Kyle Simpson was on an episode of the JavaScript Jabber podcast. Skip to the 17 minute mark to hear him talk about classes in JavaScript.

(Full disclosure: Kyle also some very kind things about some of my blog posts at the end of that episode, but you can switch it off before it gets to that bit.)

Both Ashley and Kyle bring a much-needed perspective to the discussion of language design. That perspective is the perspective of a teacher.

In his essay on W3C’s design principles, Bert Bos lists learnability among the fundamental driving forces (closely tied to readability). Learnability and teachability are two sides of the same coin, and I find it valuable to examine any language decisions through that lens. With that mind, introducing a new feature into a language that comes with such low teachability value as to warrant a teacher actively telling a student not to learn how things really work …well, that just doesn’t seem right.

Sunday, July 24th, 2016

Saturday, July 23rd, 2016