There is a recent push to start doing digital design / product prototypes in code. In this post we look at how the landscape has evolved to arrive at this capability.
How we used to do things
Prototypes were previously done in digital design tools (like photoshop, sketch) and then prototyping tools (like InVision, Figma) and more recently code in design tools tools like FramerX.
However there is a push to consider doing design in code. This is fundamentally different from using some custom non-code project files that generate code on export.
A key tool spearheading this approach is mark’s playroom : https://github.com/seek-oss/playroom fundamentally demonstrating that you write JSX and out pops a UI.
Playroom itself is pretty simple (you could argue its responsive addons for a code sandbox https://codesandbox.io/), which makes it worthwhile to appreciate the fact that maintainable Frontend development has reached a level that it hasn’t had in the past.
There are two key principles that enable this: co-location and developer tooling.
Co-location: React
React is the first (and probably the biggest) enabler. Fundamentally React allows you to embed HTML (html — like i.e. JSX) in code. This means you can use the same tooling (we come back to this) for JavaScript and HTML.
Co-location: CSS in JS
The next enabler on this journey is appreciation of component oriented CSS. CSS has always been dependent on the HTML that will utilise it. However this strong tie-in of CSS-HTML was something spearheaded (once again) by the React ecosystem when vjeux openly admitted to wanting CSS in JS. Facebook is even in the process of open sourcing a CSS in JS library:
Great now we could create resuable-isolated HTML-CSS components. That brings us to the next enabler (and recent one).
Co-location: State
Components that contain logic are great (that’s the whole point of using React over raw HTML / CSS). But there was no official React way to hand over complete access to how your components behaves (state) without jumbling it up in a box-of-things, what I call setState(universe).
Hooks change that with useStateallowing you to create higher order reuse quite easily:
// Good handle to control from the get-go
const reusable = useSomething();// Later add water to reusable// I do whatever reusable tells me
<Something reusable={reusable}/>
Hooks even enable more than just re-usable state. They provide you ways to hand over the keys to house over the container, allowing easier reuse in pairs (logic + html), so when the prototypes get handed over to the devs, they add water (business logic) to the stateful portions and are good to go.
Developer Tooling: TypeScript
Powering all this co-location is TypeScript, essentially documentation that computers can understand. TypeScript is that friend keeping you from shooting yourself in the feet. If you’ve ever seen a live code demo go horribly wrong because of a typo, TypeScript is that buddy you might have liked to be in the room.
Code is not user friendly, at least not as friendly as a nice drag and drop UI. But TypeScript just takes away a whole array of code-discoverability issues.
Parent controlled layouts
Browsers have had no good ergonomic support systems to allow containers to reliably place their children. Having this control maintained by containers means that components can focus on their content, instead of a constant parent — child warfare.
FlexBox solved this significantly (control over size of content with flex-grow / flex-shrink). Labotimized owl took this further (whitespace management between children). Both topics part of what I’ve written about (general layout system). They now have common acceptance, in the form of other libraries with examples like Seek and Microsoft Stack components.
Great for both designers and developers
So there we have it.
Designers : A neat way to create quick prototypes and no more arguing about designs not matching component library, or component library not matching design.
Developers: As a developers you are an integrator, a job for life, taking the business requirements and integrating them with your tools of trade. The tools will evolve over time, traditionally lower level and noisy, but now, closer to the business requirements 🌹
Grag and drop code generation continues to be the holy grail and one I’m tackling in DesignTSX — signup for the beta and I’ll see you on the other side 🌹
If you enjoyed this post give it a clap 👏🏼
