Dan compares the relationship between a designer and developer in the web world to the relationship between an art director and a copywriter in the ad world. He and Brad made a video to demonstrate how they collaborate.
Friday, August 10th, 2018
Very valuable observations from Paul on his travels, talking to developers and business people about progressive web apps—there’s some confusion out there.
My personal feeling is that everyone is really hung up on the A in PWA: ‘App’. It’s the success and failure of the branding of the concept; ‘App’ is in the name, ‘App’ is in the conscious of many users and businesses and so the associations are quite clear.
Saturday, June 23rd, 2018
A good ol’ rant from Robin.
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.”
Monday, June 18th, 2018
Developer happiness is only a benefit if it first does no harm to others. Even better if it genuinely amplifies benefits to those further up chain of priorities.
Tuesday, March 20th, 2018
A Voight-Kampff machine for uncovering infiltrators in the ranks.
Thursday, December 7th, 2017
I like this distinction between coders and developers.
The Coder is characterized by his proficiency in a narrow range of chosen skills.
By contrast the Developer’s single greatest skill is in being an applied learner.
I’m definitely not a coder. Alas, by this criterion, I’m also not a developer (because I do not pick things up fast):
Quite simply the Developer has a knack for grokking new [languages|frameworks|platforms] and becoming proficient very quickly.
I prefer Charlie’s framing. It’s not about speed, it’s about priorities:
I’m not a “developer” in that I’m obsessed with code and frameworks. I’m a “developer” as in I develop the users experience for the better.
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.
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.
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.
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, 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!
Friday, December 4th, 2009
A nice resource (built in HTML5) to connect developers and designers who want to Make A Thing.
Monday, November 23rd, 2009
PPK offers a rebuttal to Paul Graham's attack on Apple's App Store policies by placing the blame firmly at the feet of developers who refuse to embrace web technologies.
Wednesday, April 9th, 2008
David Recordon shares his first impressions of Google App Engine.
Friday, November 10th, 2006
New kids on the block.
Tuesday, March 28th, 2006
Jeremy Zawodny rails against the continuing snobbery towards front-end engineers.
Sunday, March 26th, 2006
Something that became very clear — both at the Carson Workshops Summit and at the many web app panels at South by Southwest — is that websites like these are never finished. Instead, the site evolves, growing (and occasionally dropping) features over time.
Traditionally, the mental model for websites has been architectural. Even the term itself, website, invites a construction site comparison. Plans are drawn up and approved, then the thing gets built, then it’s done.
That approach doesn’t apply to the newer, smarter websites that are dominating the scene today. Heck, it doesn’t even apply to older websites like Amazon and Google who have always been smart about constantly iterating changes.
Steve Balmer was onto something when he said “developers, developers, developers, ad nauseam”. Websites, like Soylent Green, are people. Without the people improving and tweaking things, the edifice of the site structure will crack.
I’m going to make a conscious effort to stop thinking about the work I do on the Web in terms of building and construction: I need to find new analogies from the world of biology.
Update: Paul Hammond told me via IM about a book called “How Buildings Learn: What happens after they’re built”. Maybe I don’t need to abandon the architectural analogies completely.