Prototypes and production

When we do front-end development at Clearleft, we’re usually delivering production code, often in the form of a component library. That means our priorities are performance, accessibility, robustness, and other markers of quality when it comes to web development.

But every so often, we use the materials of front-end development—HTML, CSS, and JavaScript—to produce something that isn’t intended for production. I’m talking about prototyping.

There are plenty of non-code prototyping tools out there, and our designers often reach for them to communicate subtleties like motion design. But when it comes to testing a prototype with real users, it’s hard to beat the flexibility of HTML, CSS, and JavaScript. Load it up in a browser and away you go.

We do a lot of design sprints, where time is of the essence. The prototype we produce on the penultimate day of the sprint definitely won’t be production quality, but it will be good enough to test.

What’s interesting is that—when it comes to prototyping—our usual front-end priorities can and should go out the window. The priority now is speed. If that means sacrificing semantics or performance, then so be it. If I’m building a prototype and I find myself thinking “now, what’s the right class name for this component?”, then I know I’m in the wrong mindset. That question might be valid for production code, but it’s a waste of time for prototypes.

So these two kinds of work require very different attitudes. For production work, quality is key. For prototyping, making something quickly is what matters.

Whereas I would think long and hard about the performance impacts of third-party libraries and frameworks on a public project, I won’t give it a second thought when it comes to a prototype. Throw all the JavaScript frameworks and CSS libraries you want at it (although I would argue that in-browser technologies like CSS Grid have made CSS libraries like Bootstrap less necessary, even for prototyping).

Alternating between production projects and prototyping projects can be quite fun, if a little disorienting. It’s almost like I have to flip a switch in my brain to change tracks.

When a prototype is successful, works great, and tests well, there’s a real temptation to use the prototype code as the basis for the final product. Don’t do this! I’ve made that mistake in the past and it always ends badly. I ended up spending far more time trying to wrangle prototype code to a production level than if I had just started from a clean slate.

Build prototypes to test ideas, designs, interactions, and interfaces …and then throw the code away. The value of a prototype is in answering questions and testing hypotheses. Don’t fall for the sunk cost fallacy when it’s time to switch over into production mode.

Of course it should go without saying that you should never, ever release prototype code into production.

And yet…

More and more live sites seem to be built with a prototyping mindset. Weighty JavaScript frameworks are used regardless of appropriateness. Accessibility, if it’s even considered at all, is relegated to an afterthought. Fragile architectures are employed that rely on first loading and then executing JavaScript in order to render basic content. Developer experience is prioritised over user experience.

Heydon recently highlighted an article that offered this tip for aspiring web developers:

As for HTML, there’s not much to learn right away and you can kind of learn as you go, but before making your first templates, know the difference between in-line elements like span and how they differ from block ones like div.

That’s perfectly reasonable advice …if you’re building a prototype. But if you’re building something for public consumption, you have a duty of care to the end users.

Have you published a response to this? :

Responses

Roger Johansson

“More and more live sites seem to be built with a prototyping mindset. Weighty JavaScript frameworks are used regardless of appropriateness. Accessibility, if it’s even considered at all, is relegated to an afterthought.”adactio.com/journal/14562

Amanda CAARSON

I don’t think I’m too far off base to suggest that so many of the problems we face on the web could be avoided if the prototype mindset discussed in this article were limited to the prototype phase by developers and designers, and kept completely separate from the production process.

xnoɹǝʃ uɐıɹq 🦌

Interesting. I wonder. Could we sell “classical” separation of concerns including, gasp, full page reloads.. as prototyping. Just a way to get started until the A Team shows us all how it’s done..

Alex Russell

I’d take full page reloads (and minus the JS) over much of what I’m seeing. With enough JS bloat, server think time + RTTs and wild variance beats reliably broken-feeling SPA experiences. Current tools put the latter in easy reach of too many teams.

xnoɹǝʃ uɐıɹq 🦌

SPA primarily, ironically, to achieve jank-free state transitions. If portals land I probably wouldn’t write one again. Think most would not because opting out has way better outcomes. Esp true if transitions are declarative.

getify

as usual, @adactio totally nails it and here’s me nodding vigorously.

# Posted by getify on Tuesday, December 4th, 2018 at 8:47am

Jake Archibald

I’m not sure portals is enough on its own. Eg, it doesn’t seem to enable hooking into navigations caused by the back button.

Jake Archibald

Fair. I think an in-tag navigation event would tie the whole thing together

Alex Russell

Know we discussed before tpac. Will prototype; not super hard.

Jake Archibald

I don’t think that (or pushstate) play well with portals, which are already a navigation

@heydon@mastodon.social

Oh no, I mean to generally fix the ‘instant’ navigation thing that currently relies on author JavaScript (watchers) in things like Gatsby. But I may be going off-topic.

Dan Claydon

Excuse me for butting in - but what are portals in this context?

# Posted by Dan Claydon on Tuesday, December 4th, 2018 at 1:39pm

Joe Lanman

“What’s interesting is that—when it comes to prototyping—our usual front-end priorities can and should go out the window. The priority now is speed.”adactio.com/journal/14562

# Posted by Joe Lanman on Wednesday, December 5th, 2018 at 11:38am

Ted Goas

“When it comes to prototyping—our usual front-end priorities can and should go out the window. The priority now is speed. If that means sacrificing semantics or performance, then so be it.” Sound advice from @adactio: adactio.com/journal/14562

# Posted by Ted Goas on Wednesday, December 5th, 2018 at 2:03pm

Chris

Maybe it’s just me, but I almost never write prototype code, because production-quality doing is what gets complete, correct, maintainable results. adactio.com/journal/14562

# Posted by Chris on Wednesday, December 12th, 2018 at 7:25am

theAdhocracy

“More live sites [employ] a prototyping mindset. Weighty [JS] frameworks [&] fragile architecture… to render basic content. If you’re building for public consumption, you have a duty of care” 👏 Wise words by @adactio on prototype vs production code. 💻buff.ly/2RXnOod

# Posted by theAdhocracy on Wednesday, December 12th, 2018 at 1:37pm

Val Head

“The value of a prototype is in answering questions and testing hypotheses.” A helpful read from @adactio on the difference between the prototype and production mindsets: adactio.com/journal/14562

# Posted by Val Head on Monday, December 17th, 2018 at 9:04pm

4 Shares

# Shared by @heydon@mastodon.social on Tuesday, December 4th, 2018 at 9:26am

# Shared by Sheila Morrissey on Tuesday, December 4th, 2018 at 9:51am

# Shared by Adam Silver on Tuesday, December 4th, 2018 at 11:08am

# Shared by Sam Richard on Tuesday, December 4th, 2018 at 1:12pm

20 Likes

# Liked by Chris Taylor on Monday, November 26th, 2018 at 6:36pm

# Liked by @heydon@mastodon.social on Tuesday, December 4th, 2018 at 8:24am

# Liked by william j. moner on Tuesday, December 4th, 2018 at 8:57am

# Liked by ConFrontJS on Tuesday, December 4th, 2018 at 8:57am

# Liked by sarah joy on Tuesday, December 4th, 2018 at 9:23am

# Liked by Spinninti on Tuesday, December 4th, 2018 at 9:56am

# Liked by Samuel Snopko on Tuesday, December 4th, 2018 at 9:56am

# Liked by ge ricci on Tuesday, December 4th, 2018 at 9:56am

# Liked by Morris Nye on Tuesday, December 4th, 2018 at 11:02am

# Liked by Adam Silver on Tuesday, December 4th, 2018 at 11:49am

# Liked by Hubert SABLONNIÈRE 😎 on Tuesday, December 4th, 2018 at 11:49am

# Liked by Erick Patrick on Tuesday, December 4th, 2018 at 11:49am

# Liked by Brandon Schmittling on Tuesday, December 4th, 2018 at 11:50am

# Liked by Mike Aparicio on Tuesday, December 4th, 2018 at 2:46pm

# Liked by Marko on Tuesday, December 4th, 2018 at 6:12pm

# Liked by вкαя∂εℓℓ on Tuesday, December 4th, 2018 at 7:15pm

# Liked by negi4a on Wednesday, December 5th, 2018 at 6:05am

# Liked by Jonathan Dallas on Wednesday, December 5th, 2018 at 8:37am

# Liked by Jeremy Wynn on Saturday, December 8th, 2018 at 10:45pm

# Liked by Simon Willison on Tuesday, April 28th, 2020 at 2:33pm

Related posts

Coding prototypes

Write what you need to test a hypothesis. Then throw that code away.

Performative performance

When it comes to sustainable web design, the hard work is invisible.

The intersectionality of web performance

Business, sustainability, and inclusivity.

Lists

Do websites need to sound the same in every screen reader?

Performance and people

When it comes to web performance, there are technical issues and then there are human issues.

Related links

Prototypes, production & fidelity layers | Trys Mudford

I’ve always maintained that prototyping and production require different mindsets. Trys suggests it’s not as simple as that.

I agree with much of what he says about back-end decisions (make it manual ‘till it hurts—avoid premature optimisation), but as soon as you’re delivering HTML, CSS, and JavaScript to real people, I think you need to meet certain standards when it comes to accessibility, performance, etc.

Tagged with

We’re still not innovating with AI-generated UI.

Prototypes and production:

It looks like it will be a great tool for prototyping. A tool to help developers that don’t have experience with CSS and layout to have a starting point. As someone who spent some time building smoke and mirrors prototypes for UX research, I welcome tools like this.

What concerns me is the assertion that this is production-grade code when it simply is not.

Tagged with

Faster Connectivity !== Faster Websites - Jim Nielsen’s Blog

The bar to overriding browser defaults should be way higher than it is.

Amen!

Tagged with

Care

I know that the number one cause of jank and breakage is another developer having messed with the browser’s default way of doing things.

THIS!!! A thousand times, THIS!

Tagged with

Cameron Dutro on ruby.social

Here’s the inside scoop on why Github is making a bizarre move from working web components to a legacy React stack.

Most of what I heard in favor of React was a) it’s got a good DX, b) it’s easy to hire for, and c) we only want to use it for a couple of features, not the entire website.

It’s all depressingly familiar, but it’s very weird to come across this kind of outdated thinking in 2023.

My personal prediction is that, eventually, the company (and many other companies) will realize how bad React is for most things, and abandon it. I guess we’ll see.

Tagged with

Previously on this day

22 years ago I wrote whoRepresents . .?

That is one unfortunate choice for a domain name.