Intro
Recently, I have came across a book called Resilient Web Design by Jeremy Keith. If you are working with web and frontend technologies I’ll definitely recommended this unique handbook to you. A rather interesting point about this book is it doesn’t contain much technical details, but takes you through the history of World Wide Web and learn from the past. I have also found this service manual from GOV.UK very helpful and I would suggest you also take a look.
My main takeaways from this book summarised into:
- Resilience is not just about infrastructures, communications, and recoverability.
- Build core features with simplest technologies, enhance UX progressively.
- Accessibility is important than consistency.
- Let each technology do its own thing.
Thoughts
The process of building a resilient web application should involving user experience and assess whether it has meet the minimum requirements of the users. Web is complex - due to many historic reasons, browsers implemented features in different ways so developers would need to test applications on different browser engines to ensure cross-browser compatibility. The application development will become tricky if the app is heavily rely on CSS and JavaScript where most features would work on some browsers but not on the others. Out of the three main components (HTML, CSS, JavaScript) of the Web, HTML is the most resilient layer - it works on all browsers (though some markup might not work in older, deprecated browsers) and is the foundation of websites. Without CSS or JavaScript, users would still be able to see websites in a less attractive way, provided that the HTML document is filled with contents on the server side.
Frontend frameworks
Before frontend libraries/frameworks like React and Angular was introduced about
a decade ago, many websites are multi-page applications (MPA) where
the HTML is built on the server side and get sent to client’s
browser (aka, server side rendering). A new HTML document will be sent on each
subsequent request from the user unless it is a AJAX request. Then React and other
frameworks adopt the concept of single-page application (SPA) and shift the focus
towards rendering pages directly on the client side using JavaScript and
an small index.html document. SPAs allows developers to build interactive
applications (like Twitter, Gmail, and Google Maps) offering great user experience,
but it generally resulted in longer initial loading
(due to the large JavaScript bundle size and the time which browser need to execute them),
poor search engine optimisation, and higher requirements on user’s bandwidth and
browsers. But what if the user has poor network bandwidth, or they have disabled
or unable to run JavaScript on browser? This left the user with an empty screen
and there’s nothing to fallback on.
Does that means we should not use SPAs at all? Simple answer is it depends. If it is a content focus website, then you might want to consider SSR frameworks, or even just a static site generator if there is no requirements on databases. On the other hand, one should definitely consider tools like React and Angular for a highly-interactive application. Regardless the route to go down, user experience should be placed on top of developer experience.
Back to SSR
There has been some new frameworks coming out in recent years claiming better performance, productivity, and developer experiences, despite the fundamental rendering strategy remains the same. However, there are some frameworks to watch for:
A common strategy of all these frameworks are HTML-first (and less JavaScript!), meaning we’re back to server side rendering again. In addition, Remix also adopted progressive enhancement approach, which emphasis on accessibility of core features for all users, then focus on enhanced features which may only be to users with good network bandwidth and addition browser features.
Takeaways
Every user on the web should be able to access the web application, even if their browser might not support some features that have implemented in the app.
Build things with simplest and most suitable tech. Rather than building a
button using a div element with a bunch of ARIA labels, CSS and JavaScript,
it is preferable to use the native HTML button element with some simple CSS.
Let each technology do its own thing - HTML is for rendering contents, CSS is for enhanced presentation, and Javascript is for additional cool features!