frippz.se

As of OS X Yosemite, the built-in version of ZSH is 5.0.5. If you’re, like me, a fan of the latest and greatest, you might be tempted to use the Homebrew version of ZSH instead of the default system one. As of the writing of this post, the latest version of ZSH is 5.1. Here’s how you install and set it as the default shell.

This very short guide assumes that you’re already familiar with Homebrew and have it installed. Once that’s sorted, install ZSH.

$ brew install zsh

Edit /etc/shells to add a new entry for the Homebrew ZSH.

$ sudo vim /etc/shells

At the end of the file add /usr/local/bin/zsh, which is the path to the Homebrew binary for ZSH. Your /etc/shells should look like this:

# List of acceptable shells for chpass(1).
# Ftpd will not allow users to connect who are not using
# one of these shells.

/bin/bash
/bin/csh
/bin/ksh
/bin/sh
/bin/tcsh
/bin/zsh
/usr/local/bin/zsh

Now we need to set our Homebrew ZSH as the default shell.

$ chsh -s /usr/local/bin/zsh

Now open up a new terminal, and we’re done! Welcome to the bleeding edge of ZSH!

I did some work on a project for a client yesterday, where I was working on some specific JavaScript based functionality. By some weird chance, the JavaScript didn’t execute due to some weird error and nothing was showing up in the browser console. Later on it was found to be Webpack that didn’t build the file, hence no JavaScript. Anyway, this little event prompted me to post the following on Twitter:

Why is my JavaScript not doing its stuff?! Oh, it’s not executing at all… See now kids why progressive enhancement is important? (^ω^)

— Fredrik Frodlund (@frippz) June 29, 2015

Apparently, this just rubbed some people the wrong way.

@frippz PE is much more than "needs to work without JS" though.

— Anders Ekdahl (@andersekdahl) June 29, 2015

Which is absolutely correct, which Christian Heilmann has pointed out very well. But you can’t always get everything you want into 140 characters. Then came the tweet that set off about an hour’s worth of what I’ve come to loathe; arguing over Twitter:

@frippz And you can certainly be doing PE but still require JS.

— Anders Ekdahl (@andersekdahl) June 29, 2015

Needless to say, I disagreed with this. Not in full, mind you. You certainly can and should apply progressive enhancement to your JavaScript as well, but I really see little point in drawing your line there and call it a day. What ensued was a discussion on what progressive enhancement should mean. Or rather, what we thought it meant.

Back in 2008, Aaron Gustafson wrote for A List Apart on progressive enhancement.

Getting into the progressive enhancement mindset is quite simple: just think from the content out. The content forms the solid base on which you layer your style and interactivity. If you’re a candy fan, think of it as a Peanut M&M:

Start with your content peanut, marked up in rich, semantic (X)HTML. Coat that content with a layer of rich, creamy CSS. Finally, add JavaScript as the hard candy shell to make a wonderfully tasty treat (and keep it from melting in your hands).

This is a great description of what progressive enhancement is, and even if this article is coming up on being seven years old, I see no reason why this definition should change. The key here is the rock solid foundation; the content. You can’t base this on JavaScript and call this your baseline. Take away the JavaScript (which still happens all the time), and you’re left with an empty page. Not very rock solid.

I do realise that we’re drifting into the deep waters of semantics and that while Anders do have a point of sorts, that progressive enhancement can certainly be applied to just JavaScript, the underlying idea of a rock solid foundation goes out the window. What’s worse to me is the confusion this causes.

Imagine the following scenario, if you will. Developers express an intention to develop a website using progressive enhancement. Jubilations all around!

Developer 1: “Alright! We’re going to start with a rock solid foundation of semantic HTML, then we’ll add styling using CSS to carefully…”

Developer 2: “Uh…”

Developer 1: “What?”

Developer 2: “That’s not what progressive enhancement is. We need to require JavaScript for this.”

I don’t know. Maybe the core problem is the semantics and like Jason Garber says: maybe we should just call it Responsible Web Design. While I don’t feel that core functionality without JavaScript is some kind of “baggage”, maybe there’s a point to it. I just don’t feel that it is very responsible to scrape the icing off the layer cake and ignore the rest of the layers.

In the wake of the news that Facebook has put out a new product that allows iPhone users to read news articles without leaving Facebook, several prominent characters on the web have put in their two cents on the matter.

Peter-Paul Koch was, as always, spot on:

The movement toward toolchains and ever more libraries to do ever less useful things has become hysterical, and with every day that passes I’m more happy with my 2006 decision to ignore tools and just carry on. Tools don’t solve problems any more, they have become the problem. There’s just too many of them and they all include an incredible amount of features that you don’t use on your site — but that users are still required to download and execute.

The trend is hard to miss. There’s an insane amount of tools and frameworks out there and using them is more the rule than the exception. PPK asks himself the question of why this is:

Why all these tools? I see two related reasons: emulating native, and the fact that people with a server-side background coming to JavaScript development take existing tools because they do not have the training to recognise their drawbacks. Thus, the average website has become way overtooled, which exacts a price when it comes to speed.

While I absolutely do not disagree with his conclusions, sometimes the answer seem to be even more simple, and depressing. Based on what I’ve seen throughout my career as a front end web developer, the reason often is that developers are just plain lazy. With the advent of libraries and frameworks such as jQuery, Twitter Bootstrap, and not to mention the torrent of CSS preprocessors such as LESS and SASS, developers have not only become disconnected from how to properly build something for the web on their own, some of them have also turned horribly lazy.

First of all, let’s be clear about a few things. Just because you use a framework such as jQuery does not automatically make you lazy. Neither does the use of even Twitter Bootstrap. They all have their uses, and when used properly, they can save a developer loads of time. The problems start to come when you as a developer start to default to dropping in whatever framework comes to mind just because you couldn’t be bothered to give the problem at hand a few extra rounds of brain time. I’ve seen projects where hapless developers have thrown in jQuery UI (and I really mean everything that said framework has to offer including the kitchen sink) just to get a few tabs in their UI.

The same can be said for something like the CSS preprocessor SASS. While I personally are not very interested in their use and fail to see what good they are, they can be used responsibly, which of course is close to impossible since they open up for misuse at every turn. In either case, they can save a developer a lot of time, but often that comes at the cost overly bloated code instead. Not always, but very often.

Now, a lot of developers would surely scream bloody murder at me calling them lazy, citing insane product owners, psychotic project managers and ultra-tight deadlines as reasons for their use of all these frameworks. Maybe, maybe not. I believe, that just as frameworks and preprocessor tools open up for way too many ways to bloat you product, so does the aforementioned circumstances. They are all a source of stress for us as developers and it makes it damn hard not to fall into that trap of throwing tools at the problem.

The very uncomfortable truth might just be that you just lack the proper knowledge to effectively solve the problem at hand. Guess what, that’s totally fine. It happens all the time to most developers. No one is perfect and what really makes you a professional is what you choose to do when faced with such problems. Maybe take a step back, admit that you don’t have the right tools for the problem and that you need to aquire them before continuing.

The thing is that the tools I’m talking about can’t be downloaded as a zip file from some website.

Last week, a link came up in my Twitter feed that resonated very well with me, as is often the case when it comes to posts and articles championing the practice of progressive enhancement and responsible use of JavaScript. The article in question was titled “Everyone has JavaScript, right?”

This morning, Aaron Gustafson linked to a comment on Reddit from a discussion thread regarding that page, that resonated equally well with me. For the sake of posterity, I’ve choosen to quote the comment in it’s entirety here.

Why is this difficult?

Because it’s not a blog full of content - it’s a revolutionary interactive animated graphical UI paradigm which merely happens to deliver textual content to users.

They aren’t really on your site to read your article or check what time their train leaves - they’re really there to marvel at your buttery-smooth, hardware-accelerated 60fps animations and 1337 client-side javascript skillz that mean you can browse the entire site without ever once touching the server after the first page-load… just as long as you don’t mind that first page-load being 3MB in size, crapping out on unreliable mobile connections and taking whole seconds between DOM-ready and the UI actually appearing.

But it’s ok, because the ToDo app I wrote to test this approach performed pretty well with just me and my mum using it, and I don’t care whether Google indexes it or not or whether blind people can see it because fuck them - they should just get some eyes, amirite?

Likewise anyone who ever wants to consume my content on a device I haven’t explicitly allowed for (or that isn’t even invented yet) can just go do one. What is it about the word “web” that makes people think of interconnected nodes that all work across a common set of protocols and idioms and allow information to flow unimpeded from one place to another?

Idiot hippies - they can consume my content in the way I decide they should or they can fuck off, yo. Because I’m a professional and nothing says professional like choosing a technology because all the cool kids are currently going “squee!” over it, rather than because it’s a good solution that follows solid engineering practices and performs well in the specific problem space we’re working in.

Besides, if people bitch and whine about not being able to bookmark individual sub-pages I can just go out of my way to implement ass-backwards hacks like the hash-bang URL support (I know Google themselves advised against relying on it as anything but a hacky workaround, but what do they know, right? They only invented the technology), forcing the entirety of my routing into the Javascript layer for ever more.

Because that’s what we want, right? To force more and more legacy code and functionality into the front-end code we serve to each and every user for the rest of time, because it’s literally impossible to ever route hash-bang URLs on the server? Sweet.

Hell, having built my entire app on the client-side, if it turns out I actually need it to be statically accessible (not that that would indicate I’ve chosen my entire architecture completely, absolutely, 100% wrongly or anything) I can always just intercept the requests for an arbitrary subset of all the clients that might ever need static content, host a client on my server then run the client-side logic in the client on the server, extract the resulting static DOM and send it back to the actual client on the client-side.

Then the only problems left are looking myself in the eye in the mirror in the morning and ever again referring to myself as a “real engineer” without giggling.

Shit’s easy, yo. I don’t know what all you old grandads are bitching about with your “separation of concerns” or “accessibility” or “declarative data”.

Shit, I don’t even know what half of those words mean. But I still know you’re wrong, right?

/s

– User Shaper_pmp on Reddit discussion thread.

I just love this!

Boy, this never gets old, does it? Back in the day, when I was but a green, eager to learn, front end web developer, I more than once fell into the trap of referring to everything (almost) as a tag. A couple of years down the road, I know better. But some people never learn, it seems. That gives me the urge to vent.

It’s not rocket science

An old colleague and mentor of mine once wrote, almost ten years ago:

When talking (or writing) about HTML, it is common for many people to refer to just about everything as “tags” instead of using the proper terms: “tag”, “element”, and “attribute”. A lot of the time what the author really means can be figured out by looking at the context, but sometimes it can be confusing.

Using the correct terminology is not very difficult. It will also make it easier for others to correctly interpret what you mean, not to mention lend more credibility to what you have to say.

– HTML tags vs. elements vs. attributes by Roger Johansson, 456 Berea Street

I think that most people will get what you are trying to say, with little risk of confusion. It’s a fairly simple situation. My gripe with not using the proper terms is a lot more simple; you come off looking like a clueless twit!

I mean, come on, it’s really not rocket science, is it? (Or do we say rocket surgery now, since Steve Krug titled his wonderful book in that fashion?)

This is me doing something about it

I guess the biggest problem for me is that each time I correct the culprit, I come off as the asshole. Ok, let’s just do some HTML 101, shall we?

Elements

In general, a HTML element consists of a start tag and an end tag. Here’s a lovely heading for you.

<h1>This is a heading</h1>

Preferably, there should be some content between the start tag and the end tag.

Tags

Tags are what makes up the start and the end of an element. You’ve might come across some of the, like in the previous section, like, five seconds ago.

<p>

The above start tag denotes the beginning of a paragraph. Attributes are optional, like so.

<p class="whatever">

In order to close you paragraph, you’ll need and end tag.

</p>

There are a few HTML elements that requires no end tag. The <img> element is one good example of those.

<img src="photo.jpg" alt="">

Attributes

Noticed those thingies with an equals sign and some quotation marks? That what we in the business call an attribute. Attribute. Yes. Now, you might’ve heard some clueless nitwit refer to them as an alt tag. That’s complete gibberish, since there’s no such thing as an “alt tag”. If you hear someone use that term, you’re totally allowed to slap them with a rolled up newspaper.

Don’t be that guy

My former colleague is ever so courteous in his post on the subject:

You may call this nitpicking, but I don’t think it is. Sure, most of the time people will understand what you mean even if you call everything a “tag”. But by using the correct terminology you reduce the risk of being misunderstood, and you will sound more professional, so you really have nothing to lose by learning the difference.

– HTML tags vs. elements vs. attributes by Roger Johansson, 456 Berea Street

He’s right, of course. You really have nothing to lose by using the proper terms. But remember, you also limit the risk of coming off as a clueless git. 😉