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.
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.
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.
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
spanand how they differ from block ones like
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.
‘[I]f you’re building something for public consumption, you have a duty of care to the end users.’ adactio.com/journal/14562
20 years arguing this point suggests it is evergreen.adactio.com/journal/14562 For those who started dev in the last 10 years, prototype ≈ MVP.
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..
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.
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.
as usual, @adactio totally nails it and here’s me nodding vigorously.
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.
I’d happily take a jank back button to never again “compile” markup. And hey if v2 fixed back even better.
Fair. I think an in-tag navigation event would tie the whole thing together
Know we discussed before tpac. Will prototype; not super hard.
A slide from my latest talk about strategies for content (blog) sites:
onhashchange for this kind of thing. Something that works like that but not tied to fragments would be good.
I don’t think that (or pushstate) play well with portals, which are already a navigation
Excuse me for butting in - but what are portals in this context?
“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
Proč rozlišovat kódování prototypů a produkčních věcí a proč prototypy raději zahazovat: adactio.com/journal/14562
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
“Prototypes and production” great read on 2 different mindsets. Of course it should go without saying that you should never, ever release prototype code into production. Of course… But so many people still do that mistake adactio.com/journal/14562
Prototypes and production (Jeremy Keith) adactio.com/journal/14562
adactio.com/journal/14562 Prototypes and production
Prototypes and production - adactio.com/journal/14562