Front-End and Back-End Development: Removing the Blockers
Traditionally, the biggest blocker to building a great front-end experience has been back-end development. For most web application platforms, you had to have something to shape into an experience before you could move beyond the basic design compositions. This “something” was typically a bunch of rough HTML containers and elements generated by a CMS (using PHP, Django, Ruby, etc). Many web apps are still built this way today, but most CMS applications now have a standardized templating engine. This still pushes most front-end developers toward transforming the CMS output though their chosen templating engine (e.g. Twig, HTL, Mustache, or something proprietary), which creates a dependency on having rendered output from the CMS to “theme” before front-end development can really step in.
Building additional layers between the back-end web application and the front-end experience has been an emerging trend in this space. These architectural shifts are commonly referred to as “decoupled” or “headless” implementations of a CMS. Instead of building templating code directly with the CMS in its native language or chosen template engine, another layer is introduced that is specific to the front-end experience.
This is a step in the right direction. Using a modern front-end framework like Bootstrap, Foundation, AngularJS, etc., you can effectively build front-end experiences without needing any sort of rendered output from a CMS. In this case, the CMS back-end is giving you structured data (e.g. JSON) that feeds your front-end. Awesome! Now we can build experiences without worrying about what’s going on with the scary back-end stuff.
But there is still an issue — front-end developers are still trying to transform pictures into experiences, and there isn’t a clear understanding about how the structure of data coming from a CMS relates to how that data will be displayed.
In terms of front-end developers, the answer lies in a design system that prioritizes modular reuse of experiences, and provides both designers and developers a window into how each of those individual experiences works in the medium that they’re destined for. By providing developers with sample data and a playground for developing their experiences, you can iterate and test what a web page experience will be like in a browser, while back-end developers continue to build back-end code.
This makes a lot of blockers go away. With a library of coded components, it’s easy to construct experiences from a set of known variations, and collaboration and experimentation becomes a shorter process, alleviating the reality of refactoring dozens of components or hundreds of pages. Two teams of developers can work simultaneously to create the back-end business logic and data sources, and at the same time front-end teams can start building experiences. Now a project becomes a lot more about identifying key points for integration conversations and inter-team communication rather than sequencing of dependencies.
It’s a pretty cool thing to be able to have the front-end of an application nearly complete before the data sources that power it are even available, and it’s even cooler to watch parts of the application come fully online without breaking the experience for the parts that aren’t ready yet. All of this makes web development a smoother, faster, and better experience.
