What I Expect from a Front-end Architecture

As a developer, in simpler times you merrily coded away on your web app. Well, you did have to use someone with CSS skills for this annoying thing called styling, but CSS was broken anyway, right? Over the years, your company had been forced to adopt an ‘add only’ policy for CSS, because anyone trying to clean up a stylesheet would likely break something. You inherited a giant CSS that everyone, including you, was loath to touch.

Then, something totally unexpected happened: CSS preprocessors like SASS fixed CSS and made stylesheets actually manageable. Almost overnight it became possible to create a working design system or front-end architecture. Still, programmers continue to see graphic design and styling as something outside their domain, and for good reason: designers are simply better at it. Writing good code is hard enough.

And then there are web frameworks. In simpler times, you could see your current web framework as the magic solution to most, if not all your front-end design issues. In addition, the web framework would ensure that you create apps that are maintainable and future-safe. However, the sad reality is that web frameworks have had a short half-life. The last years have seen a rapid succession of candidates to be considered ‘the best’: Backbone, Knockout, Ember, Angular, Angular 2, React, Vue, Riot and Polymer. History shows that what you would pick today is likely not what you would pick eighteen months from now.

Assuming you don’t want to start from scratch and rewrite everything every eighteen months, that presents your organization with a great architectural challenge. Is there a front-end architecture that helps developers create apps that are visually attractive, maintainable and future-safe? If this architecture exists, what do I want and need from it? As I go though this wishlist, you may ask yourself how well your favorite web framework, forcibly invented by coders for coders, actually addresses these items.

I want the CSS to be maintainable.

I want the designers, not the developers, to be able to create and maintain the CSS. To provide that maintainability is the hard part. A designer should be able to edit styles as an application evolves over the years. He shouldn’t have to wrestle with a developer to get the changes implemented. Without naming any specific web frameworks, I am not convinced that wrapping CSS in JavaScript helps meet that objective. It should be easy to apply design guidelines over time, in the actual place where the CSS meets the code. A more appealing UI has never hurt customer adoption or satisfaction.

I want the HTML to be maintainable.

The same applies to HTML: I want designers to be able to create and maintain HTML. Most developers don’t really think of HTML as their favorite thing either. I prefer web frameworks whose HTML actually looks like, well, HTML. But even if I don’t have a choice, I certainly would not like the HTML markup intricately woven into JavaScript code. HTML is simply more accessible and editable by the designer if it is located in a separate (yes, HTML!) file. Also, I look for non-framework utilities like Pug to help create and maintain well-structured HTML.

I want a maximum of HTML (and all CSS) to be static.

Static means it can be cached at the edge, in a content delivery network (CDN). UI performance is just better that way. Users prefer a more performant UI, and are more likely to stay around. I prefer JavaScript to fetch dynamic data, not dynamic HTML (Exception: server-side rendering). Access to the dynamic data can still be password-protected. Moustache-style libraries help render data on the fly, but the HTML templates they use can still be comprehensible to designers. I like the UI to be defined declaratively, with HTML. It’s just easier to understand (and maintain) that way. I want the new developer on the project to have a shorter learning curve and be more productive faster.

I want the solution to allow SEO.

Whether the app is public and requires SEO, or private and would benefit from fulltext-search, SEO too often comes as an afterthought. A front-end architecture should make SEO easier rather than hinder it. The developer should not need to create a whole additional app just to make the content indexable or searchable. Of course, some data is just too structured to be worthy of full-text search, such as charts rendered client-side in JavaScript. The web framework should support rendering textual information on the server-side, so that crawlers can find it in the rendered page HTML. A lot of web components should be hybrid, with initial HTML (and possibly relevant CSS fragments) rendered on the server, while additional interactivity can be provided in the client. More searchable apps improve adoption and user satisfaction.

I want the solution to provide a ‘rich client feel’.

Both web apps and web sites should be able to provide a ‘rich client feel’. Just like in a native app, on page transitions I only want to see the content replaced that actually changes, and the ‘App-Shell’ (menu and such) to remain, without page flash. A front-end architecture should allow for these kinds of smooth page and content transitions. CSS transitions should be part of the solution. Again, a richer, more appealing UI helps capture and retain users.

I don’t want to be married to a specific web framework.

It should be easy for the app developer to apply the front-end architecture and use it with the web framework at hand. The developer should also be able to use more than one web framework per app at a time: to add new functionality with a newer, more popular framework, the developer shouldn’t have to recreate the entire app from scratch. This requires some careful architecting: it likely means to stay away from the two features that most commonly create web-framework lock-in: custom navigation mechanisms (routers) and framework-specific component communication mechanisms. The front-end architecture itself must be web framework-agnostic.

I want to reuse the same architecture for web, mobile web and apps installed on a mobile device.

Using responsive design is a no-brainer. In addition, apps installed on a smartphone can use an in-app browser to render the same HTML as a web app does. If we use page or content transitions (to be provided by the front-end architecture), we can get the same smooth UI feel as a native app. We use development resources better if we refocus advanced Android SDK/iOS development skills on using APIs rather than on achieving the same UI effects through different means.

I want it to handle Accelerated Mobile Pages (AMP).

AMP fulfills a business need and is here to stay, so I want it to be supported. It helps provide faster responses to web and mobile users. Luckily, AMP allows me full access to the power of CSS, but it requires me to keep CSS size small. If parts of my UI need advanced JavaScript functionalities which AMP itself prohibits, I can put them in an <amp-iframe>.

I want the architecture to last at least 5 years.

It’s not an architecture if you have to scrap it every year. Web frameworks are particularly guilty in that field. It is almost like there is a new ‘flavor of the month’. The differences between Angular 1 and Angular 2 are striking; the same is true for Polymer 1, Polymer 2 and even Polymer 3. I am not arguing that they don’t benefit from the changes… Structurally, the front-end architecture should be a rock in the sea of ever-evolving web frameworks. But UI is the face of the app, it is what users see and like or dislike. That face should be as attractive as ever possible. In an evolving landscape of web frameworks the front-end architecture must be solid AND designed for change. That will help meet the business needs and the bottom line for years to come.

Summary: To date, the places where design and code intersect remain points of friction. With a focus on the business objectives, the front-end architect needs to understand the needs of programmers and their code to be able to provide efficient means for great design to pervade the solution.

About the author: His name has always been Wolfgang. You can find pieces of his work at webcomponents.org.