I had the honour of being invited along to kick off the first leg of Mozilla’s Developer Roadshow in Singapore.
Thursday, September 21st, 2017
Thursday, September 14th, 2017
In my experience, “full-stack developers” always translates to “programmers who can do frontend code because they have to and it’s ‘easy’.” It’s never the other way around. The term “full-stack developer” implies that a developer is equally adept at both frontend code and backend code, but I’ve never in my personal experience witnessed anyone who truly fits that description.
Monday, September 11th, 2017
I like Chris’s list of criteria for the nebulous role of senior developer:
- A senior front end developer has experience.
- A senior front-end developer has a track record of good judgment.
- A senior developer has positive impact beyond the code.
- A senior developer is helpful, not all-knowing.
- A senior front-end developer is a force multiplier.
Tuesday, October 11th, 2016
Thursday, October 6th, 2016
It’s not about what works for you. It’s about what works for your users.
If a very complicated set-up with seven brand-new libraries and frameworks and a bunch of other tools satisfies you completely as a web developer but slows your sites down to a crawl for your users, you’re doing it wrong.
If serving your users’ needs requires you to use other tools than the ones you’d really like to use, you should set your personal preferences aside, even though it may make you feel less good. You have a job to do.
But it’s worth remembering this caveat too.
Thursday, July 14th, 2016
This is relevant to my interests because I think I’m supposed to be a senior developer. Or maybe a technical director. I’m really not sure (job titles suck).
Anyway, I very much appreciate the idea that a technical leadership position isn’t just about technical skills, but also communication and connectedness.
When we boiled down what we’re looking for, we came away with 12 traits that divide pretty cleanly along those three areas of responsibility: technical capability, leadership, and community.
For someone like me with fairly mediocre technical capability, this is reassuring.
Now if I only I weren’t also mediocre in those other areas too…
Tuesday, June 7th, 2016
Jeffrey’s right. Instagram’s new deal with developers is openly hostile. It probably means the end of OwnYourGram in its current form …a service whose existence is frankly the only reason I’m able to use Instagram at all.
Sunday, January 24th, 2016
Some of the explanations get a little ranty, but Heydon’s collection of observed fallacies rings true:
- The gospel fallacy
- The Luddite fallacy
- The scale fallacy
- The chocolate fireguard fallacy
- The pull request fallacy
- The ‘made at Facebook’ fallacy
- The Bob the Builder fallacy
- The real world fallacy
- The Daphne and Celeste fallacy
I’ve definitely had the Luddite fallacy and the scale fallacy thrown in my face as QEDs.
The ‘made at Facebook’ fallacy is pretty much identical to what I’ve been calling the fallacy of assumed competency: copying something that large corporation X is doing just because large corporation X is doing it.
Friday, November 27th, 2015
Harry packs a lot of great tips and tricks into one short video about performance troubleshooting. It’s also a great lesson in unlocking some handy features in Chrome’s developer tools.
A look at detecting, pinpointing, measuring, and fixing rendering performance issues.
Thursday, February 19th, 2015
When I look around, I see our community spending a lot of time coming up with new tools and techniques to make our jobs easier. To ship faster. And it’s not that I’m against efficiency, but I think we need to consider the implications of our decisions. And if one of those implications is making our users suffer—or potentially suffer—in order to make our lives easier, I think we need to consider their needs above our own.
Friday, January 9th, 2015
I’m not a new developer, but I can definitely relate to this. In fact, when I’ve spoken to any developer about this, it turns out that everyone feels overwhelmed by how much we’re expected to know. That’s not good. We should open up and talk about this more (like Charlotte is doing here).
Thursday, October 23rd, 2014
The one problem I’ve seen, however, is the fundamental disconnect many of these developers seem to have with the way deploying code on the Web works. In traditional software development, we have some say in the execution environment. On the Web, we don’t.
Lakoffian self-correction: if I’m about to talk about doing something “in the browser”, I try to catch myself and say “in browsers” instead.
While we might like think that browsers have all reached a certain level of equilibrium, as Aaron puts it “the Web is messy”:
And, as much as we might like to control a user’s experience down to the very pixel, those of us who have been working on the Web for a while understand that it’s a fool’s errand and have adjusted our expectations accordingly. Unfortunately, this new crop of Web developers doesn’t seem to have gotten that memo.
Aaron makes the case that, while we cannot control which browsers people will use, we can control the server environment.
Aaron sees requiring a specific browser/OS combination as an impractical impossibility and the wrong thing to do, whereas doing this on the server is positively virtuous. I believe that this is no virtue.
It’s true enough that the server isn’t some rock-solid never-changing environment. Anyone who’s ever had to do install patches or update programming languages knows this. But at least it’s one single environment …whereas the web has an overwhelming multitude of environments; one for every browser/OS/device combination.
Stuart finishes on a stirring note:
The Web has trained its developers to attempt to build something that is fundamentally egalitarian, fundamentally available to everyone. That’s why the Web’s good. The old software model, of something which only works in one place, isn’t the baseline against which the Web should be judged; it’s something that’s been surpassed.
However he wraps up by saying that…
In a post called Missed Connections, Aaron pushes back against that last point:
Stuart responds in a post called Reconnecting (and, by the way, how great is it to see this kind of thoughtful blog-to-blog discussion going on?).
But here’s the problem with progressively enhancing from server functionality to a rich client:
A web app which does not require its client-side scripting, which works on the server and then is progressively enhanced, does not work in an offline environment.
Now, at this juncture, I could point out that—by using progressive enhancement—you can still have the best of both worlds. Stuart has anticpated that:
It is in theory possible to write a web app which does processing on the server and is entirely robust against its client-side scripting being broken or missing, and which does processing on the client so that it works when the server’s unavailable or uncontactable or expensive or slow. But let’s be honest here. That’s not an app. That’s two apps.
Ah, there’s the rub!
When I’ve extolled the virtues of progressive enhancement in the past, the pushback I most often receive is on this point. Surely it’s wasteful to build something that works on the server and then reimplement much of it on the client?
I also think that building in this way will take longer …at first. But then on the next project, it takes less time. And on the project after that, it takes less time again. From that perspective, it’s similar to switching from tables for layout to using CSS, or switching from building fixed-with sites to responsive design: the initial learning curve is steep, but then it gets easier over time, until it simply becomes normal.
But fundamentally, Stuart is right. Developers don’t like to violate the DRY principle: Don’t Repeat Yourself. Writing code for the server environment, and then writing very similar code for the browser—I mean browsers—is a bad code smell.
Here’s the harsh truth: building websites with progressive enhancement is not convenient.
Developer convenience is a very powerful and important force. I wish that progressive enhancement could provide the same level of developer convenience offered by Angular and Ember, but right now, it doesn’t. Instead, its benefits are focused on the end user, often at the expense of the developer.
Personally, I’m willing to take that hit. I’ve always maintained that, given the choice between making something my problem, and making something the user’s problem, I’ll choose to make it my problem every time. But I absolutely understand the mindset of developers who choose otherwise.
But perhaps there’s a way to cut this Gordian knot. What if you didn’t need to write your code twice? What if you could write code for the server and then run the very same code on the client?
For me, this is the most exciting aspect of Node.js:
Some big players are looking into this idea. It’s the thinking behind AirBnB’s Rendr.
Here’s the ideal situation:
- A browser requests a URL.
- If the browser does cut the mustard, keep all the interaction in the client, just like a single page app.
So why aren’t we seeing more of these holy-grail apps that achieve progressive enhancement without code duplication?
Well, partly it’s back to that question of controlling the server environment.
In the meantime, building with progressive enhancement may have to involve a certain level of inconvenience and duplication of effort. It’s a price I’m willing to pay, but I wish I didn’t have to. And I totally understand that others aren’t willing to pay that price.
Three years ago, when I was trying to convince clients and fellow developers that responsive design was the way to go, it was a hard sell. It reminded me of trying to sell the benefits of using web standards instead of using tables for layout. Then, just as the Doug’s redesign of Wired and Mike’s redesign of ESPN helped sell the idea of CSS for layout, the Filament Group’s work on the Boston Globe made it a lot easier to sell the idea of responsive design. Then Paravel designed a responsive Microsoft homepage and the floodgates opened.
Now …who wants to do the same thing for progressive enhancement?
Thursday, September 11th, 2014
The Extensible Web Summit is taking place in Berlin today because Web Components are that important. I wish I could be there, but I’ll make do with the live notes, the IRC channel, and the octothorpe tag.
I have conflicting feelings about Web Components. I am simultaneously very excited and very nervous. That’s probably a good sign.
And here’s what I wrote after the Edge conference:
If Web Components work out, and we get a kind emergent semantics of UI widgets, it’ll be a huge leap forward for the web. But if we end up with a Tower of Babel, things could get very messy indeed. We’ll probably get both at once.
The exciting thing about Web Components is that they give developers as much power as browser makers.
The frightening thing about Web Components is that they give developers as much power as browser makers.
When browser makers—and other contributors to web standards—team up to hammer out new features in HTML, they have design principles to guide them …at least in theory. First and foremost—because this is the web, not some fly-by-night “platform”—is the issue of compatability:
You can see those principles at work with newly-minted elements like
video where fallback content can be placed between the opening and closing tags so that older user agents aren’t left high and dry (which, in turn, encourages developers to start using these features long before they’re universally supported).
You can see those principles at work in the design of
You can see those principles at work in the design of new form features which make use of the fact that browsers treat unknown
input types as
type="text" (again, encouraging developers to start using the new
input long before they’re supported in every browser).
When developers are creating new Web Components, they could apply that same amount of thought and care; Chris Scott has demonstrated just such a pattern. Switching to Web Components does not mean abandoning progressive enhancement. If anything they provide the opportunity to create whole new levels of experience.
Web developers could ensure that their Web Components are accessible, using appropriate ARIA properties.
But I fear that Sturgeon’s Law is going to dominate Web Components. The comparison that’s often cited for Web Components is the creation of jQuery plug-ins. And let’s face it, 90% of jQuery plug-ins are crap.
This wouldn’t matter so much if developers were only shooting themselves in the foot, but because of the wonderful spirit of sharing on the web, we might well end up shooting others in the foot too:
- I make something (to solve a problem).
- I’m excited about it.
- I share it.
- Others copy and paste what I’ve made.
Most of the time, that’s absolutely fantastic. But if the copying and pasting happens without critical appraisal, a lot of questionable decisions can get propagated very quickly.
To give you an example…
When Apple introduced the iPhone, it provided a mechanism to specify that a web page shouldn’t be displayed in a zoomed-out view. That mechanism, which Apple pulled out of their ass without going through any kind of standardisation process, was to use the
meta element with a
name of “viewport”:
<meta name="viewport" value="...">
value attribute of a
meta element takes a comma-separated list of values (think of
name="keywords": you provide a comma-separated list of keywords). But in an early tutorial about the
viewport value, code was provided which showed values separated with semicolons (like CSS declarations). People copied and pasted that code (which actually did work in Mobile Safari) and so every browser must support that usage:
Many other mobile browsers now support this tag, although it is not part of any web standard. Apple’s documentation does a good job explaining how web developers can use this tag, but we had to do some detective work to figure out exactly how to implement it in Fennec. For example, Safari’s documentation says the content is a “comma-delimited list,” but existing browsers and web pages use any mix of commas, semicolons, and spaces as separators.
Anyway, that’s just one illustration of how code gets shared, copied and pasted. It’s especially crucial during the introduction of a new technology to try to make sure that the code getting passed around is of a high quality.
I feel kind of bad saying this because the introductory phase of any new technology should be a time to say “Hey, go crazy! Try stuff out! See what works and what doesn’t!” but because Web Components are so powerful I think that mindset could end up doing a lot of damage.
Web developers have been given powerful features in the past. Vendor prefixes in CSS were a powerful feature that allowed browsers to push the boundaries of CSS without creating a Tower of Babel of propietary properties. But because developers just copied and pasted code, browser makers are now having to support prefixes that were originally scoped to different rendering engines. That’s not the fault of the browser makers. That’s the fault of web developers.
With Web Components, we are being given a lot of rope. We can either hang ourselves with it, or we can make awesome …rope …structures …out of rope this analogy really isn’t working.
I’m not suggesting we have some kind of central authority that gets to sit in judgement on which Web Components pass muster (although Addy’s FIRST principles are a great starting point). Instead I think a web of trust will emerge.
If I see a Web Component published by somebody at Paciello Group, I can be pretty sure that it will be accessible. Likewise, if Christian publishes a Web Component, it’s a good bet that it will use progressive enhancement. And if any of the superhumans at Filament Group share a Web Component, it’s bound to be accessible, performant, and well thought-out.
Because—as is so often the case on the web—it’s not really about technologies at all. It’s about people.
And it’s precisely because it’s about people that I’m so excited about Web Components …and simultaneously so nervous about Web Components.
Monday, July 14th, 2014
My interest in rich client-side apps has almost entirely reversed, and now I’m more interested in doing good ol’ server rendering with the occasional side of progressive enhancement, just like we did it in 2004.
This post resonates with me 100%.
Thursday, September 27th, 2012
When I was writing about browser-developer relations yesterday, I took this little dig at Safari:
Apple, of course, dodges the issue entirely by having absolutely zero developer relations when it comes to their browser.
A friend of mine who works at Apple took me to task about this on Twitter (not in the public timeline, of course, but by direct message). I was told I was being unfair. After all, wasn’t I aware of Vicki Murley, Safari Technologies Evangelist? I had to admit that I wasn’t.
“What’s her URL?” I asked.
“Of her blog.”
“She doesn’t have one.”
The Safari Technologies Evangelist actually does speak at one conference: WWDC. And the videos from that conference are available online …if you sign on the dotted line.
Now, I’m not saying that being in developer relations for a browser vendor means that you must blog or must go to conferences. But some kind of public visibility is surely desirable, right? Not at Apple.
I remember a couple of years back, meeting the Safari evangelist for the UK. He came down to Brighton to have lunch with me and some of the other Clearlefties. I remember telling him that I could put him touch with the organisers of some mobile-focused conferences because he’d be the perfect speaker.
“Yeah,” he said, “I’m not actually allowed to speak at conferences.”
An evangelist who isn’t allowed to evangelise. That seems kind of crazy to me …and I can only assume that it’s immensely frustrating for them. But in the case of Apple, we tend to just shrug our shoulders and say, “Oh, well. That’s Apple. That’s just the way it is.”
Back when I was soliciting questions for this year’s browser panel at Mobilism, Remy left a little rant that began:
When are we, as a web development community, going to stop giving Apple a free fucking pass? They’re consistently lacking in the open discussion in to improving the gateway to the web: the browser.
And he ended:
Even the mighty PPK who tells entire browser vendors “fuck you”, doesn’t call Apple out, allowing them to slither on. Why is it we continue to allow Apple to get away with it? And can this ever change?
When I next saw Remy, I chuckled and said something along the usual lines of “Hey, isn’t that just the way it is at Apple?” And then Remy told me something that made me rethink my defeatist accepting attitude.
But this, I say, waving around at the room, this feels a little odd. I’m getting the presentation from an Apple announcement event without the event. I’ve already been told that I’ll be going home with an early developer preview release of Mountain Lion. I’ve never been at a meeting like this, and I’ve never heard of Apple seeding writers with an as-yet-unannounced major update to an operating system. Apple is not exactly known for sharing details of as-yet-unannounced products, even if only just one week in advance. Why not hold an event to announce Mountain Lion — or make the announcement on apple.com before talking to us?
That’s when Schiller tells me they’re doing some things differently now.
And that, said Remy, is exactly why now is the time to start pushing back against Apple’s opaque developer relations strategy when it comes to Safari: they’re doing some things differently now.
Apple’s culture of secrecy has served them very, very well for some things—like hardware—but it’s completely at odds with the spirit of the web. That culture clash is most evident with Safari; not just a web browser, but a web browser built on the open-source Webkit platform.
I’m sure that Vicki Murley is great at her job. But her job will remain limited as long as she is hampered by the legacy of Apple’s culture.
That culture of secrecy is not written in stone. It can change. It should change. And the time for that change is now.
Monday, April 11th, 2011
I like this way of whittling down potential candidates for the job: “To apply, check the HTTP headers.”
Monday, February 21st, 2011
A beautifully readable subset of the HTML spec, with an emphasis on writing web apps (and with information intended for browser makers has been removed). Very handy indeed!
Wednesday, February 16th, 2011
I love hearing stories like this. Anything that breaks down the perceived designer/developer divide is a good thing, in my opinion.
Friday, December 4th, 2009
A nice resource (built in HTML5) to connect developers and designers who want to Make A Thing.