Something that bugged me as I moved from one stack to another, was the lack of logical structure in application frontends. While backends were generally, and for good reason, well-endowed in this regard, typically with a dedicated team tasked with its design in furtherance of a coherent and resilient architecture.

What should have amounted to “frontend architecture” were generally an ad hoc structuring process determined by the demands of the moment, often without enough consideration for future ramifications. Suffice to say, no matter how good the user experience, or how fancy the design, things tended to be messy underneath that pretty veneer.

When architecture is not thoroughly thought through in the beginning, working with the average medium to large scale frontend codebase can be an exercise in frustration. For example, there is unlikely to be a definite protocol to follow when adding or modifying assets and source code and it will be left up to the discretion of each respective developer to inadvertently structure the frontend, impromptu style.

This creates a sort of “developer-lock-in”, as navigating and managing the frontend effectively means having to counsel previous contributors in an attempt to synthesize existing notions of what goes where, and why. The reality is that, one seldom has access to the people who originally laid the foundation of a frontend, so it’s generally a matter of reverse-analysing their reasoning and crossing fingers in the hope that the structure conforms to a reasonable degree of sense.

Best practices relating to frontend architecture have recently been gaining more traction, likely in part due to the fact that the ever more complex frontend machinery and its resulting workflows necessitates a more structured approach to frontend development. Micah Godbolt, author of “Front-end Architecture: A Modern Blueprint for Scalable and Sustainable Websites” defines frontend architecture as: “A collection of tools and processes that aim to improve the quality of our front-end code while creating a more efficient and sustainable workflow.” It’s a definition sufficient in scope, yet specific enough to form a banner that serves to lobby the developer community on the benefits of taking frontend architecture seriously.

For years, we have had access to scaffolds that provide a set of common UI components and library of style classes, each with its own conventions on how to manage the presentation layer. Its primary concern however, was style, not structure. While this limitation in scope is understandable for a variety of reasons, there is also room for a type of framework that goes beyond style, providing a resilient platform on which to build your frontend.

We have access to powerful markup and style abstraction languages, as well as ES2015, all offering much greater leniency in how we can structure the code powering our UI’s. Frontend technologies have reached the level of maturity necessary for the creation of a generic architecture that prescribes a coherent structural layout. My suggestion for such an architecture would be that, at its core, the following structural pillars be present:

1. Describes its architecture with a semantic structural vocabulary
2. Ensures structural integrity with rules for asset management
3. Exposes patterns that enable predictive scaling

A framework that adheres to these three structural cornerstones, can then go ahead and mould its operational and design features on a solid foundation. These may include such nifty things as:

• Project workflow support with an integrated asset pipeline
• A smattering of boilerplate styles
• A collection of utility classes
• A component library

Somewhere in 2013 I remember starting to collect snippets of markup, style and scripts, with the goal of improving the reuse of regular patterns – a process I’m sure many of you can relate to. It was also around the time that I became a CSS preprocessor convert and had to pick a flavor. Stylus’s feature set and syntactic flexibility appealed to me, so the choice was made. Yet, back then there were no frameworks that used Stylus, so taking this route meant sacrificing capable, well-vetted options like Twitter’s Bootstrap and Zurb’s Foundation.

Well, at that stage you either modify an existing solution or, roll out your own. I went with the latter. Early in 2014, using the ever-growing collection of snippets as a starting point, I set out to create the scaffold, even wiring all the moving parts up to a basic, but functional multi-page template. It initially ran on HTML 5, Stylus and pre-ES6 logic, and was tested in production on four separate, small-to-medium sized projects.

It worked, but it had no definite structure, couldn’t scale seamlessly, was monolithic rather than modular, didn’t facilitate component reuse and lacked an integrated asset pipeline. As time went on, I would channel my industry experience back into this pet project, steadily grooming it to new insights and the evolving frontend landscape.

As I continued to work on disparate, existing frontends, the absence of proactive architectural planning almost invariably remained a constant phenomenon. Something had to give. That’s when I decided to take my little pet project for a major overhaul. The idea was to furnish it with some incarnation of what a sound architecture may look like, as there was not much industry consensus on this topic at the time. So in mid 2015 I took the plunge and began the task of refactoring the scaffold with a structure that might be able to eventually, and somewhat intuitively, explain itself.

I figured I’ll call it “Platframe” since it would essentially be a structured platform to serve as a foundation for the framework. I replaced HTML with Pug, and adopted ES2015 as it became stable. This stack allowed me to achieve modularity on the structural, presentation as well as the dynamic layer. Grunt is in charge of the asset pipelines, while the whole enchilada is glued together with a humble attempt at a more explicit structural design.

Note that I could have used any other stack-combination, as long as it was endowed with the relevant features to maintain the integrity of the architecture. In the course of working on the refactor, I became convinced that a standard color system might be a swell idea, as well as a model for managing self-contained, reusable components that could be shared among Platframe-based projects. So with no further ado, the end result is a framework that is:

• Structured with a defined architecture
• Able to scale seamlessly with recursive patterns for asset management
• Workflow-optimized, with a baked-in asset pipeline
• DRY-aware, with a recipe for interchangeable components
• Equipped with a color system which supports shareable scheme packages
• Bootstrapped with basic boilerplate styles and a starter template
• Minimally prescriptive on development methodology

I’m going to avoid expanding on the list above for the sake of brevity and refer you to the project’s documentation which covers the particulars.

It took a considerable amount of tinkering to realize the above feature set in one integrated package, but I finally pulled through with the finishing touches in February of 2018. I’ve since decided to open-source my effort as the project’s ultimate value relies on a wide gamut of developer expertise.

Let me state for the record: Platframe is far from complete, and even further from perfect. In its current state, it is an effort to establish some idea of what a structured frontend framework may look like. While its current iteration is ready to be used in production, Platframe can benefit more developers and be of greater use with the following improvements:

• Separation and codification of the architecture. The underlying architecture should be clearly decoupled from specific technologies. It will better serve as a formalized, generic guideline which can be adopted by any stack that satisfies the required feature-set for implementation.
• Greater selection of components. There are currently only a handful of components to illustrate the concept of reusable packages in the framework.
• More color schemes. The framework ships with three standard schemes. Schemes are easy to hook into your project and can cascade through to the finest coloring detail of your UI, including active components.
• Extended utility selection. The current mixin selection is limited and somewhat dated. It needs an update and expansion to include a greater variety of interaction elements.
• A lower-level build system to shrink the overall dependency footprint.
• A native package manager for components (albeit low on the triage).

I’ll continue to work through the list as I have time, although any help would definitely be awesome :-)  Details for contributing can be found on the project's GitHub page.