Transcription
Heydon Pickering: Yeah, a tough act to follow there, but I’m going to do my best. I’m going to talk about something a little bit different today.
Yesterday I was walking around Berlin, and I noticed this enormous poster. I was walking around with my wife, Fan, who is with us today as well. And I decided I’ll walk towards it because I noticed there were some lines across the person’s face here. On closer inspection, I noticed that it was computer code. It was syntax highlighted computer code, and it was jQuery because I saw the remove method and the CSS method.
My talk is about writing less code because I think it’s gone too far now. I think when it gets to the stage that we’re laser engraving jQuery on people’s screaming, agonized faces, and then boasting about it by getting that printed up in a big photo and plastering it all over Berlin, someone needs to say something, and so that’s what I’m going to do today.
Most technical talks that you’ll hear about how to write code. My technical talk is about how not to write code. But I don’t mean how to write code badly because that’s sort of an ambiguous expression, although I could talk about that the whole fucking day. I have a lot of experience in how to write code badly. No, it’s about how to avoid writing code altogether because there’s too much of it already and most of it is shit.
It’s loosely based on an article I wrote a little while ago called Writing Less Damn Code, and because that was an article that was published on the Web, what I did is I did some performance there, and I removed the E-D at the end of damned. I said it was two less bytes that I was putting over the wire because that’s how much I care about performance. Both arguably grammatically correct, so it was okay.
It was a big hit on Reddit. Osvaldo has commented, “Seriously, write less damn article.” The article was just under 1,000 words, which is a lot, a lot of stuff to get through, quite a challenge to read if you learn to read by browsing Reddit. But the principle remains the same. Less of anything is good. And if there’s less of anything, then there’s less shit stuff as well.
You get simplicity. So if you don’t give yourself very much code, if you budget yourself to having a small amount of code, then you don’t end up producing that much stuff. You're forced to focus on the things which are important, the things which people actually want. So you end up with a simpler interface, which more people can use. Naturally, you get performance as well because there’s less code to execute, there’s less code to actually send to the client.
There are some fringe benefits too for developers. If you’re a Web developer and you’re writing not code, you’re not writing code at all, then you can leave out comments because there’s nothing to comment. There’s no technical debt because, well, for obvious reasons. And you can use a combination of tabs and spaces –
Audience: [Laughter]
Heydon Pickering: – because everything is white space surrounding the point in time and space at which your application doesn’t exist.
To be perfectly clear, I’m not talking here about perceived performance. I’m talking about doing, actually doing less code, actually not doing as much. So instead of sending the stuff that the user actually needs first and then secretly sending loads of extraneous shit that they don’t need behind their back and fucking their data contract, that’s not what I’m talking about.
Ideally what you should do is not start at all. Don’t do any coding. Don’t even start the project. Someone says, I’ve got a great idea for a project. You say, fuck no. I’m not doing any more of that.
Audience: [Laughter]
Heydon Pickering: Then you don’t have to tell them about it. You don’t have to make the modal, which says, hey, we’ve made this app. For instance, you might have a Web application already, which serves lots of people because, as Tim was talking about, the great thing about the Web is it should be universal. It should reach everyone.
Then you make the decision that, why don’t we do the same thing, but do it on the iOS using Xcode or some shit like that. Don’t fucking bother. Then you don’t have to do the modal to tell them about it, so you don’t have to code a modal, so you can get rid of that as well. Perfect.
You’re sort of doing your good deed for the day then as well because if you’re not using that modal, then that’s another modal, which is in the common pot, which someone else can take. Twitter’s interface is made entirely out of modals, so you’re sort of doing a favor for them. They can take your modal that you would have used and add another modal to their Web interface, so doing a good deed.
Already we’re on a roll. We’ve destroyed one entire native application. We’ve decided not to code that whatsoever. Therefore, we don’t have to do the modal and make the modal accessible and make the modal responsive and all of that stuff.
But it’s easy to sort of forget yourself. You think, well, I’ve budgeted, and I’ve done very little, so great. But then you think, well, in that case I’ve still got more budget. I’ll do something else.
For instance, in this talk, I’ve got this picture of Rick Astley, which is totally unnecessary. There’s no point of that being there at all. It’s a 200-year-old meme. It’s not funny. It was never funny, the Rickrolling thing. It wasn’t funny. And it’s 936 kilobytes. I found that GIF on the Internet, and it’s 936 kilobytes. You should be able to make free, entire working Web applications for that amount of code, so fuck that as well. We can get rid of that.
Right. Now Carousels. I was bound to talk about Carousels at some point, so I’m going to talk about Carousels next. This is what a Carousels vaguely looks like.
When you build a Carousel, you have to ask yourself lots of important questions, don’t you? For instance, you have to ask yourself, how do I support touch? If it’s in a touch interface, how do I do it so it does that thing where I can flick, but it will sort of stick, so it shows the whole picture? Then when I flick again, it sort of locks into position, right? You ask yourself questions like that.
You also ask yourself questions like, what should be the accessible name for the handles on either side? Should it be previous or should it be back? And how should you actually put that label in there? Should it be an area label attribute, or should it be a span with a special class, which means it’s visually hidden, but not hidden to screen readers?
What the fuck are those things even called? Are they tips? I don’t know. Pips or something like that.
They’re all the wrong questions, actually. I was leading you up the garden path there. You shouldn’t be asking any of those questions. The only question you should be asking is, how do I get out of coding this thing that everybody hates?
All of the research that has been done, all of the anecdotes done and everything points to the fact that everyone either hates Carousels, doesn’t know how to use them, doesn’t want to use them, or prefers to use something else, which brings me to unprogressive non-enhancement, which is a new concept that I’ve come up with. Unprogressive non-enhancement is where you take some structured content, which follows a vertical flow of document in a time honored fashion in a way that everyone understands, which people can traverse easily by either dragging their scrollbar with their mouse, operating the keyboard using the up and down keys, using the spacebar or, if they’re using a touch device, simply flicking backwards and forwards in that easy way that we’ve all become used to.
What you do is you take that, and you fucking well leave it alone. You don’t do anything else. You don’t turn it into a Carousel. That’s unprogressive non-enhancement.
Ideally you wouldn’t be asking any questions. You wouldn’t have even started with any of that kind of stuff because, as soon as someone said the word “carousel” in a meeting, in your office, or at any time at all that you were on the job, what you do is you drop to the floor like this.
Audience: [Laughter]
Heydon Pickering: And you simply roll out of the room like that. Don’t engage, basically. Don’t entertain the idea.
Social media buttons is another classic one. I wrote this blog post a little while ago, Look at this Shitty Tweet Button. That’s the entire blog post. I’ve now bridged that. Which is great for people who are Redditors, of course, because that means they’re able to read it without falling asleep, farting, dying, or whatever they do when they run out of the ability to read stuff.
It did confuse a few people who came to my blog. Johnny Doe weighs in with “wut”. Thank you, Johnny.
But the point of it was to say that is just simply a button, which has “Tweet” written on it, and all it does is use an endpoint in Twitter’s API, which prefills a tweet, and then you can then tweet something.
This is the amount of code that it’s made of. It doesn’t actually fit on the screen. It goes about there, like that. That’s a big of JavaScript. It pulls in an iframe, which contains JavaScript, CSS, and HTML.
I spent some time trying to find the bit that actually did the thing that I wanted it to do, and I’ve highlighted it here. The rest of it is absolutely extraneous.
You can see that the Twitter engineers have done some really good, what I call, PERF here. What they’ve done is they’ve used this highly optimized and fast attribute, the ID, and they’ve only used just one character in those IDs so that the JavaScript runs really fast, and they’re not using many characters at all. That’s what I call PERF, taking a fundamentally stupid fuckwitted idea and doing superficial and unhelpful enhancements just to convince yourself that you care about performance.
Some of you may have noticed, the eagle eyed among you, that I already have a link, which does exactly the same thing on all of my blog posts anyway. That uses only this amount of code. Again, as I said, it just uses the API, and it’s just a couple of query parameters for the text that you want to appear in the tweet preloaded and the URL to link obviously to the resource. A tiny, tiny amount of code.
But does anyone actually use it? Do they? Fuck no, so get rid of both. Get rid of the tweet button, and get rid of that. I haven’t got rid of that yet. I’ve left it. I’m lazy. I don’t update my blog design. But I should be getting rid of that too.
As a sort of side point, recently there was a competition called 10k Apart, which is organized by the A List Apart people. I was a judge. The idea was that you had to try to make a working Web application with just 10k.
Someone did a fantastic thing. It was remarkable, but it was done with so little code. Then they decided it would be a good idea, in their entry, because we have to judge all these, obviously independently, to include a tweet button. He took his 10k application, which did all of that stuff, and added a tweet button so that people could share it –we weren’t going to share it because this was a closed judging circumstance, anyway –and made it 50k. The decision for me as a judge was fairly easy. I disqualified that, but it’s a shame.
I guess the serious point here is just because you didn’t write the code and you’re just using someone else’s, that doesn’t mean it doesn’t appear on the user’s client, right? Oh, well, I only wrote 10k. The other stuff was someone else’s. Yeah, that wasn’t really work.
I’m an accessibility engineer and advocate or whatever, so I talk a bit about ARIA. Did you know, though, about ARIA that it’s actually not a real specification? The first rule of ARIA is, don’t use ARIA, which is kind of weird, isn’t it, if you think about it that ARIA as a specification is to say it’s like they’ve spent years working on this, and it’s a very noble cause as well to try and make the Web more accessible. They’ve spent ages on all of these lists discussing how to make all of these attributes and everything work together. They're basically, at the end of it or at the start of this specification to say, by the way, everything else in this is just a joke. If you use it then you’re going to look pretty daft.
That’s not quite what they mean. What they mean is, don’t use it unless you have to. So let’s look at a few examples. Don’t do this. This is just ridiculous. You’ve got a div. You’ve got an ARIA roll off heading, and then a property of aria-level=2, and that’s just the same as that in terms of interoperability, in terms of how it would work in a screen reader. Just use that because it’s less code.
The same with this. If you have a div with a roller button and a tab index of zero, that makes it keyboard accessible and, when you focus it, it will announce to the screen readers this is a button. Great. But also you’ve actually got to write some JavaScript, which I haven’t included here, to actually make enter and space key presses work. That’s a hell of a lot of code when using that will do all of it for you.
This is a list, which you could just make out of list items.
And this one I saw on a project the other day. Someone has tried to reinvent the image tag using a div, so there’s a div, the class of image. Presumably the class of image is to give it some sort of basic image styling, and then an ARIA label of picture of cat because you can’t use an alt attribute on a div, so there has to be another labeling mechanism. Style, an inline style attribute of background image URL and then the image there like that. What you really should be doing is that instead. Why were they doing this? Because they could.
Should they? Fuck, no, they shouldn’t. Right. ARIA isn’t for making HTML accessible. It’s for making inaccessible HTML accessible. That’s sort of a good rule, so it’s for sort of patching shit HTML, which had already been done badly. If you get accessibility thinking into the design process, obviously that shouldn’t happen.
But, yeah, it’s for patching stuff for the most part, but there are a few things that you can do with ARIA that you can’t do with basic HTML 5. One is states, so ARIA expanded, which takes a value of true of false, should say, well, should tell the user whether or not the thing that the button is controlling is available or unavailable, open or closed.
But the thing is you don’t actually have to use the button role just because you’re using the state property. You can just use a button, which has an implicit role. The button has a button role without you having to write it, I guess. Then just use ARIA expanded with it.
Complex relationships like a good example is ARIA described by is a good way of connecting up hints for form elements. You have a bit of like a paragraph with an ID, which says you need to fill this in in a certain way, and you connect it up to the input using ARIA described by, which has a value of the ID. That way when the user focuses the input, it will read the description.
It will append that to the other information that’s there. If you just put a paragraph in the form, you’ll never get that information because you’re browsing by focus. You won’t actually move to the paragraph directly.
Live regions, of course, which are really cool, they’re like an oral messaging system. You would end up filling out some information in the live region, which would say, oh, you’ve made this error or whatever. Just by populating the live region, it gets announced in screen reader technology. Otherwise they wouldn’t know that that was happening because it would just be visually appearing somewhere on the screen. There’s stuff that you can sort of progressively enhance into HTML, but just don’t use ARIA where it’s not needed.
Text resizing: Who has seen a website, which has something like this on it? Yeah, and some of them look a bit like that. Or if you’re really ambitious and you’ve done a lot of cocaine –
Audience: [Laughter]
Heydon Pickering: –you might do that. There is no need to do any of that. All you’re doing is sending redundant code to the client. It’s just more code, more JavaScript or whatever –you might have to pull in jQuery just to do that one, a perfectly normal textual site –because users already have things like command plus or control plus to zoom, and they can also change the text settings in their browser.
A really important thing to remember is that the outer bit around your interface is also an interface. The browser Chrome is an interface. Really, actually, your interface is a sort of pseudo interface. It’s just content, which has interactivity.
But the great thing about deferring to changing the text size there is that it will be in the same fucking place whatever website they’re visiting because it’s part of the browser. I mean like anyone is going to be interested in learning your particular take on a text resizing widget every time they go to a different website. They’re not.
But some people would protest and go, but what if some users don’t know that those features are there? And I would reply that, well, they could Google it. They could try and find out that way and type in “resize text in Firefox.” Oh, that’s how you do it.
Now, not everyone knows how to do that. Tim was talking about this before in terms of the technical literacy of some people that we take for granted that people would know how to use things, but often they don’t. But the point is if they don’t know how to do that, you putting a custom text resizing widget on the site is not going to fucking help them.
Right, so if you want to support the vision impaired, what you do is you just make sure that what they change in the browser actually gets honored. You don’t suppress the features that are already there. You don’t add your own features because that’s just more redundant code. You don’t suppress the features that are already there.
You use relative units for things. You use M in REM, et cetera because, despite the fact that most users will do full page zoom, which that will work using pixel units, but browsers still have the option of resizing things in the settings, so you can resize the body text. That will only resize the body text. If your body text resized is in Ms, but your line height in pixels, everything is going to go fucky, basically. Everything should be in relative units.
Don’t put that in there. That’s a really good example of doing less, but giving a better user experience. If you just take user-scalable=no out of your viewport meta tag, then everything is just better for your user, so just take that away. Less code; better product. And also avoid fixed and absolute positioning wherever you can because as soon as someone starts pinch zooming and things are kind of fixed in a particular place, everything is going to start getting obscured. Things are going to overlap in a horrible way, so just try and just go with the flow as it were and use static positioning wherever you can.
If someone approaches you and says, “Oh, we should have a text resizing widget to help people with low vision,” say, “Well, that’s cute. That’s nice. I’m glad that you’re thinking about people like that.” But actually what I’m going to do now is I’m just going to –
Audience: [Laughter]
Heydon Pickering: –roll out and leave. Right. Okay. I need a drink before this one.
Device break points: Has anyone heard of device break points, like versus content break points in terms of responsive design? There are different ways of approaching it.
Now, I’m figuring that most of you don’t fall for this trap, but what happened was a little while ago – I say a little while ago. About a year ago I saw this tweet that someone did, and it was a picture of all of the dimensions of a load of iOS, like Apple devices, and all the viewports available on iOS 9 for responsive Web design. Me being a dick wrote, like, quoted them, the dick thing of quoting them and said, “I don’t think that’s how responsive Web design works,” because I don’t think it – I mean first of all because not everyone has an Apple device. But also, like, the idea that just when a new device comes out, then responsive design changes. It doesn’t.
I said that, and they replied, and they said, “Ideally, I agree, but a key for a successful mobile experience is to understand the real world.” So what he’s saying there is he’s saying because you don’t exist in the real world, like, actually, you’re a figment of my imagination. Therefore, I’m right. What am I, like, fucking, Roger Rabbit or something like that? Like I’m super imposed in some cinematic sort of fashion.
But in any case, this seems to be how a lot of people do responsive design. They go, okay, what we’ve got is we’ve got your MacBook Pros, you’ve got your iPads, and you’ve got your iPhones. So we’ll do a breakpoint for each, and then it’s responsive. Brilliant. We’re sorted. Great. Good work, Brad. Good work, Scott and Hunter, whatever their bro names.
Audience: [Laughter]
Heydon Pickering: We’ve – we’re sorted. Great. We’ve done a great job. Everyone is covered. Everyone is fine. No one is going to have a broken experience because they’re the only things on the market, right?
Let’s settle down and let’s just watch the Apple keynote. Shall we? And see what they have to say.
Oh, fuck. Oh, okay, so now – now there’s four devices. So, right, okay, right. What are we going to do? Okay.
So all of our current apps, all of our old apps, and everything we’ve made so far was only designed to work on those three. Now we’ve got this fourth one to cover. We’re going to have to pull of lot of late nights. Brad, if you could get some cocaine, like a lot of cocaine. This is going to take months. We’ll pull a few – get out the MacBook Pro, Jeb, or whatever your name is, and we need to cover this other device because what’s happened here is the responsive landscape has changed. It’s a paradigm shift, isn’t it? The tectonic plates have gone fucky.
Audience: [Laughter]
Heydon Pickering: So that takes about six months to cover that. We’re like, woo, okay, right. That is quite a lot of coke. It’s very Moorish coke. Let’s settle down and watch the Apple keynote.
Audience: [Laughter]
Heydon Pickering: Timmy, see, again, he’s – yeah, okay. Now we’ve got this other iPhone, which is a slightly different size. Brad, yeah, I think that’s probably enough coke for this. If you go get the coke and I’ll get a pizza and the coffee, you know, the gourmet coffee and all of that, and the beach balls or whatever people have in these offices. We’ll sort this out.
Right, okay, that takes another six months or thereabouts. About time for another Apple keynote. Ah, fuck!
Audience: [Laughter]
Heydon Pickering: You’re killing me, Tim Tim. You’re killing me. What the fuck is that?
Audience: [Laughter and applause]
Heydon Pickering: Loads of people had lead poisoning and suddenly think they’re in the Jetsons for fuck sake, right. Then you’ve got design – I mean I’ve never designed a responsive site for a watch. I mean who is going to read, like, a blog post on a watch?
But, yeah, in any case, as I said, I think probably you will get this already. You get the fact that this is a daft way about going about doing responsive design. You should think about it so that you only really have to change things whether the content comes under pressure.
As you narrow the view port, if something sort of wraps in a way that you don’t like, you put in a breakpoint, and you fix that. And then you’re covering all of the Apple devices and all of the other devices. It takes less code. You’re actually writing less code because you’re not sort of being heavy-handed and saying, okay, this device, this device, this device, and you’re covering a lot more, so that’s good.
You can also actually – some of the other stuff that you’re doing in your responsive design, say in terms of scaling the font size and that sort of stuff, you can do that too. You can automate that. You can use viewport width units.
The problem with viewport width units is that they don’t scale, so they’re not accessible on their own. But what you can do is you can enter them in an equation with an M using the calc function. What you then get is everything is going to be one M or more depending on the width of the viewport, right? It kind of works like this. Because one M plus no viewport worth is still one M, you actually have a minimum font size. A lot of people have mooted the idea of having a min font size property in CSS. You kind of don’t need it because you can do this.
Now, you don’t have to do that thing where you have the breakpoint and go, well, at this breakpoint I’m going to have my H2 at 38 pixels and my P at 12 pixels or whatever. You don’t have to think about it because it just does it for you. So you save a lot more code that way too.
Right, now, grids. Okay, so the thing with grids I’ve noticed is that if you put the number of columns of a website, and I mean the columns of the whole page against the likelihood that it’s a shit show, it’s sort of, you know, like that. That’s only a correlation. I’m not saying that it’s – of course sometimes you have sites, which have multiple columns, and they’re fine. But generally it’s worse.
There’s nothing wrong with this kind of layout. That’s a one column layout. You’ve got your logo at the top. You’ve got your navigation. You’ve got the main content. You’ve got a max width to make sure that the line lengths don’t get too long, so people don’t have trouble reading. You’ve got your footer at the bottom.
It doesn’t have to be exactly like that. You can do this, do full width for the navigation because you don’t have to worry about measure there because it’s individual compartments. A big footer or a smaller footer, whatever. Move the logo up there. Have that as your home link as well. It saves on redundancy. It pulls the main content further up.
Things start to go to shit when you do this. And the reason is you’ve got this big space here, which does nothing. And that only gets worse when you start to scroll and everything is just lopsided.
You can fix that by doing this: making sure that you have exactly the number of pages needed to fill up the whole viewport going vertically.
Audience: [Laughter]
Heydon Pickering: That’ll only work for that viewport height as well, obviously. Then you have to use position fixed, of course, then, so that when you scroll, that stays where it is. Yeah? The trouble then is if you do add another page so that you get another item in the navigation, no one will ever see it because the position fixed meaning that you can’t scroll it into view. So you have to make that scrollable.
Can you see how it’s going to fuck already just by – and that’s just two columns that you’re adding to there. Yeah. But most of the time you don’t have enough navigation items in the first place. A simple site with a decent information architecture shouldn’t have that many links one after the other. That’s why we invented things like this to fill the gaps.
Audience: [Laughter]
Heydon Pickering: And this where you pull in a whole other fucking website and put it in an iframe and stick it in there.
With just two columns, things have gone wrong because that’s not how the Web is designed. Like I said before, the bit in the middle of the browser is for the content. It should be like books don’t have multiple columns. Word documents don’t have, like, a little bit on the side and then everything skewed off to the side, you know. Also, when you go down to like a mobile sort of width, you can only afford to have one column anyway, and you’ve got to maintain that layout and make sure that the UX for that layout still works. What’s the point in going that way?
Jerry Jones disagrees with me. He says, “I love sites with multi-column layouts. It makes it obvious which content I should ignore.”
That is true. I get that. So if you’ve got three columns, and then you go, well, that’s obviously some advertisement shit. That’s like art and music on fuckbook or whatever. Then you go – you know, it’s sort of everything points towards the middle, so I get what he’s saying.
But I disagree. I think we should start mobile first and just stay there. Just don’t – one column is fine as long as you’ve got a maps width there to make sure that the lines don’t go out too far. Then you’re okay.
As you may have guessed, I’m not big on grid systems like these big dependencies we bring in just to make layouts, which we’ve decided are actually shit anyway. But putting things next to things is okay. I approve of that. For instance, you might have, like, product teasers or thumbnails in an image gallery, that kind of thing. Why not? Do that. That’s a good idea, putting it all up together and making a bit of a grid of that content is absolutely fine.
It turns out you can do that in all cases with this tiny amount of code. You don’t need a grid system or whatever. You can just use Flexbox. Use margin and the negative margin for the gutters. You use what’s kind of a container query, which is the Flex basis property, which is the last argument here on Flex 10m. Now what that means is that each item will be around 10m is they can fit to be 10m. It will actually grow because you’ve got Flex grow set to one.
Everything sort of basically fixes around the 10m measure, and everything just collapses and folds together, as expected, like this. You don’t need any breakpoints whatsoever. You just let it do its stuff. That’s all the code you need.
Just to be a bit of a troll, I turned that into a framework. Oh, I should just mention that it’s also progressive enhancement because if display flex isn’t recognized, and it is recognized in most browsers, if display flex isn’t recognized, then everything just goes back to being in one column as if everything was displayed block rather than display flex.
But, yeah, I made a framework called FUKOL, which is based on this. It has a distinctive logo, which looks a sea anemone, as you can see. It’s 93 bytes minified, which means it fits in a tweet. That was before –
Audience: [Laughter and applause]
Heydon Pickering: Thank you. That’s actually before I refactored it. It’s smaller than that now because I’m using some redundant properties in there. Someone else pointed that out.
Dependency management: I started off just saying, well, I just put it in a Read Me file in the repo and just said, “Copy and paste it. I’m not doing Bower and stuff like that.” And then foolishly I said, “If it gets 1,000 stars on GitHub, I’ll put it on Bower,” so now it’s on Bower, so you can install it on Bower if you want to.
Audience: [Laughter]
Heydon Pickering: Or, as Hugo pointed out, there is actually a node module, which allows you to acquire from Twitter, so you could just put in the ID of the tweet that I wrote back here, and you can just install it from Twitter into your dependency stream, so there you go.
Audience: [Laughter]
Heydon Pickering: Now, one final one is single page applications. Alex Russell recently has been doing some great stuff. When I say great stuff, he’s been doing some incredible rants on Twitter. I don’t know if you’ve read any of them, and I’ve been nodding my head violently going, “Oh, yeah, this is brilliant.”
One of the concepts he’s come up with is the idea of a zero budget. The idea is you don’t start with a framework because a framework comes with loads of stuff, which you don’t need. And the only way you can compete with the performance in native is to actually just code the stuff that you need.
Single page applications, there’s not actually a lot that makes them single page applications. Angular allows for you to do single page application type stuff, but it comes with loads of other stuff. The API is actually 1.2 megabytes.
What you can do if you’re making a very simple single page application is just to use things like this. This target pseudo class is a really, really interesting and important thing. It’s a CSS thing, obviously. What it is, it’s a cipher that mediates between the hash fragment in the URL and an ID for a piece of content in the page. So if you write this CSS here where you have a set of views, which have the class view, and then you use a pseudo class of target on just one, what you can get is this kind of effect where you click the link. Because it’s then going to that hash fragment and it’s loading it in the URL, it’s like loading views in the way that views are managed entirely with JavaScript in something like Angular or that kind of thing.
You can get what’s fundamentally, I think, what kind of makes a single page application single-page-applicationy without even JavaScript, which is kind of cool. Una has got a really cool page here as well, which is about lots of things that you can do without JavaScript. I think it’s always very controversial to talk about the progressive enhancement and whether things should have JavaScript or not. I think there’s lots of things, which do need JavaScript, but we use JavaScript for things that we don’t need to use JavaScript for, and it’s necessarily less robust and necessarily less performance where we do. If you were just using standard browser behavior then you’re going to get something, which is a lot more robust and a lot more performant.
But of course I’m aware that you’re going to have to use some JavaScript in a single page application. And, as it happens, the onhashchange event is really handy, and it’s just a standard event that’s supported pretty well universally. You can just use that for an event every time the hash changes in the URL. It also even has a property of old URL, which is a standard part of that Web API technology, which points to the previous hash fragment that you’re at. You can manage all the history and stuff like that really easily.
Then you don’t get any back button woes whatsoever. You just click the back button. That changes the URL. That fires the event. Your single page application is doing everything you want. The stuff that you hang off that onhashchange event can be whatever. You can render stuff using templating, or you can change some of the content or do an XRH request or whatever. But it’s really pared down, and it’s the basic skeleton of a single page application without all of the other extraneous crap.
Who has heard this expression “Less is More”? Okay. Okay. When I was researching this talk, I got the expression, and I looked it up in Google Image Search, and you get a lot of these sort of inspirational posters about it like this one, “Less is More.” And what they’ve done here is a visual metaphor. I don’t know if you can see this, but what they’ve done is they’ve made more sort of like more by making it bold, so to sort of ram the point home.
Another one here, and I think one is funny because there couldn’t be a more complex way of representing less is more, and they haven’t even got “is” there. They’ve had to go for equals because otherwise it would have been unreadable, so that was a bit unfortunate.
My all time favorite is this one because it’s really on the nose because it says “Design Inspiration” at the top. It’s like less is more. What the fuck are you talking about? It’s design inspiration. Ah, clever. Right. I see where you’re going.
Audience: [Laughter]
Heydon Pickering: I think actually in this case by less is more what they meant is less contrast, so brilliant.
Audience: [Laughter]
Heydon Pickering: Now there’s something about the “Less is More” principle or whatever you want to call it that bothered me. It sounded off, so I did a bit of research, and I looked up the word “less.” It says a smaller amount of or not as much. I thought, that doesn’t sound like more to me. That actually sounds like less.
Audience: [Laughter]
Heydon Pickering: The next thing I did to follow up on that piece of investigation was to look up the word “more.” That says a greater or additional amount of or degree. I thought that’s weird because that sounds like more, not less, as the inspirational designers would have you believe.
Then to double check, I went back to less, and I noticed this here, an antonym. For those of you who don’t know what an antonym is, it means opposite word. It means a thing, which is the opposite of. Instead of less being more, actually being like more, what they’re saying is it’s actually totally different. It’s completely a different thing.
I thought, fuck. Right, so I thought, right, I’ve stumbled upon something here, which is like monumental and I really need to, like, unearth. I need to tell everyone about this. But I couldn’t rely on the anecdotal evidence of dictionaries because that would be flimsy, so what I did is I decided to use a scientific approach, and I used the greatest mechanism known to man for determining what is true or false, and that’s called JavaScript.
I put JavaScript into my console and wrote ‘less’ == ‘more’ like that, and it came out as false, so all of those fucking designers, that was bullshit.
Audience: [Applause]
Heydon Pickering: They wouldn’t know a bullion if it hit them in the face.
As it turns out, less is actually less. On the Internet it’s scientology. That’s sort of stating the obvious, but less is less. That’s actually a good thing because, if you have less of anything, then you necessary have less weight, less complexity, less distraction, less bother, and les bullshit. Let’s face it. I think we could do with less talking, so I’m going to shut the fuck up now.
Audience: [Laughter]
Heydon Pickering: Thank you very much.
Audience: [Applause]
