Web Application Checklist
Developing web applications can be tricky. There is a lot to consider. Each time I start one I need to decide what is important for this particular application, each will be different and have it's own considerations.
So below, in no order, is my checklist when starting a new application. It includes the most common things to consider. Not all will necessarily be applicable depending on the nature of the application.
Accessibility
It's a good idea to start with accessibility in mind. Some UI libraries have some accessibility features baked in, but when you deviate from library components and think about user interactions it's a good idea to consider these things.
Familiarize yourself with the accessibility features available in your browsers devtools.
There are also linting tools that will help ensure you are on track.
Security
There are always security considerations when developing for the web. Run a security scan on your application, there are a lot of tools that will help with this.
Most frontend frameworks will offer some protections but there is always more that can be done. Think about adding a CSP (Content Security Policy) and take advantage of the relatively new Trusted Type support available in most major browsers.
UX / Interaction Design
Is there someone on the team who will be working on UX exclusively or will it be a team endeavor (yes, if your team size is one :) ). UX doesn't just magically happen and if it's not properly considered it could lead to costly refactoring down the road.
Do less is the best way to keep UX tight and avoid confusing your users. Follow the 80/20 rule. One way to do things, no superfluous content / options.
Design
Are you going to incorporate a Design System like Material Design. Are you going to rely on a library like Tailwindcss or Bootstrap or others.
If you have a decent sized team a Design System should be used to avoid many inconsistencies in the UI.
Storybook is a great utility for building UI components in isolation that will help with testing and documentation. You can also integrate it into your build pipeline via tools like Chromatic.
Server Side Rendering / Partial / Progressive Hydration
Hydration is a hot topic at the moment. SPA vs MPA vs Transitional Apps!! (it's a minefield) Depending on the nature of your application or the tools you are using it is worth considering.
Generally the aim is to achieve faster time to interactive, load times and better SEO support.
Build Tools
Do you need to incorporate specific build tools or will your chosen framework provide everything you need out of the box. Do you want to opt out of some framework specific tooling and incorporate something in it's place. Sometimes frameworks will lag behind the latest shiny tool. Deviating from the out of the box tools may make upgrades trickier.
Continuous Integration
What CI will be used to build the application. Will it work well with your other tools, is there good documentation/blogs covering the tech stack with the CI?
Testing
This is a big one. There are many approaches and a lot depends on the team's size, structure and experience. Do you have anyone dedicated to QA? If so they will generally have an automation framework they use for End to End testing. Does the development team take responsibility for all testing. Do you write unit tests using something like Jest or Vitest, or do you use some like Cypress or Playwright for UI testing and do you use a mock backend or live backend?
Logging
console.log and it's variants console.error, console.debug, console.trace, console.table, console.dir, console.assert, console.time, console.timeEnd, console.group, console.groupEnd are available. Generally, they can be used for small web applications but as complexity increases logging to console is best avoided and replaced with a server push of logs when required which ties in nicely to Error Handling.
Error Handling
Unfortunately it's going to happen, so how are you going to handle it. Some frontend frameworks provide Error Handling capabilities where there an interface or class that can be leveraged to provide a single point for handling errors in you application.
There are plenty of tools (mostly paid) that will allow you to push error stacktraces from your application to a server for inspection, they'll alert you when an error occurs etc.
Routing
Which location strategy will be used, e.g. in Angular you can choose between.
- HashLocationStrategy
Where URL looks like http://localhost:4200/#/product - PathLocationStrategy
Where URL looks like http://localhost:4200/product
The Location Strategy defines how our URL/Request is resolved.
Authentication
Are you going to use a third party SDK / service to handle user authentication or are you going to roll your own. These days it's most likely you'll be relying on a third party like Auth0, OneLogin, Azure, AWS, etc.
Authorization
Do you plan on supporting different roles in your application. If so you need to determine how to integrate this into your application early, adding it later will be harder.
Performance
How will you manage performance expectations of the app. This may be something that is an integral part of the UX or it may be using the Web Performance API to add marks and measures to track performance and performance regressions.
Layout
Desktop or Mobile or both. Will the libraries you use provide responsive functionality or will you manage that via CSS Media Queries and a smattering of flexbox.
Third Party Libraries
Know what dependencies you require up front and try to limit dependency creep. This will make things simpler as the app grows in complexity, upgrades will be more straightforward also. Sometimes it makes sense to pull in a dependency to avoid reinventing the wheel but always ensure it is well maintained and you absolutely need it.
Web Workers
Web Worker - if you are crunching large data sets or have time consuming algorithms putting them into a Web Worker could be the way to go.
Service Worker - if you want to take advantage of some advanced API and asset caching then incorporating a Service Worker to help. Angular has great support for setting this up by running a schematic to convert your app into a Progressive Web Application (PWA).
Shared Worker - if you need to track activity across tabs a Shared Worker will help.
Embedded Worker - if you need to spin up dynamic workers try these.
Storage
localStorage, sessionStorage and indexdb are the main options. Cookies also present possible storage capabilities depending on what you need. Also Cache API but is more for http response data.
localStorage and sessionStorage are limited to approx 5mb and are synchronous so if that is an issue look else where for non blocking solutions.
indexdb is limited to half main disk size so has a lot more storage but is shared between tabs so that needs to be considered also, e.g. if you're app is open in mulitple tabs each tab will be interacting with the same indexdb database. There may be ways around this if it is not an issue such as associating a session id with the db name in use.
Don't store sensitive user data. Be aware of Data Protection laws.
Progressive Web Application
Converting your application into a PWA could be a great idea. You'll get the option for users to "install" your application to their home screen / desktop. You'll get some nice additional features such as offline mode, caching, predictive prefetching all leveraging Service Workers, Web Push Notifications and more.
Some frameworks will allow you to run a script which will add this capability to your application, e.g. Angular has ng add @angular/pwa
Caching
Your application can take advantage of browser caching, by integrating with Service Workers. This can help improve your applications performance with regard to loaded assets and API calls your application makes.
Search Engine Optimization
Do you need your application to work well with SEO? If so investigating SSR might be the best option or a static site generator might be what you need.
UI Library / Component Library
You'll probably want to identify a robust UI library that can provide you with the components you need rather than building your own. If you need a date picker or a stepper find a library that can provide both.
CSS
Are you going to use standard CSS or a preprocessor like SASS? Or are you going to use something like Tailwindcss or vanilla-extract to provide utility classes that you can add to your templates.
Semantic HTML
It's a good idea to begin by using semantic HTML, basically avoid overuse of divs and add proper markup in your templates such as header, footer, main, nav, section, aside, etc. These will make it easier for users relying on assistive technology and will also make it easier for you to maintain as your templates grow in complexity.
Hosting
Where will the application be hosted, will you have a staging option to test updates to your application before pushing them to production. e.g. Firebase allows you to test changes against a local emulator, then share changes on a preview URL and finally deploy live once all is good.
Deploying
Are you going to Dockerize you application? It will make managing and deploying simpler, though you may already be using a cloud provider that takes care of this for you, e.g. Firebase, Netlify, AWS, etc.
Project Structure
When you are choosing a frontend framework or library think about how to best structure your application. You don't want to end up with a poor project structure that makes navigating the project cumbersome. Will you have multiple apps and libraries. nx is a great choice for working with monorepos.
Team Structure
If there are a few or more people contributing the the development you should invest time on setting up good linting, formatting so the team is all on the same page.
Browser Support
Know upfront what browsers will be supported, things have got a little better on desktop with the IE finally being knocked on the head, but you'll need to refer to caniuse.com if you are planning on using newish features to ensure all your target browsers will support them. browserlist is baked into several frameworks or can be added simply to most projects.
Application Architecture
If your application is likely to grow and scale significantly you should invest time upfront in attempting to create an architecture that will allow this. I say attempt as it's likely you won't know how the application will evolve over the years. Change is inevitable, not just in terms of your applications requirements but also in the tools/libs/frameworks you choose. A framework you depend on now may have been superseded by another. As the team tires of using an old / outdated framework there'll be increased pressure to change or risk losing people who want to ensure they are learning relevant skills.
This is where Web Components and Mirco Frontends may help alleviate some of this concern, as you can change the application piecemeal over time as parts of it will be framework agnostic.
Lazy Loading
SPAs are notoriously bad for loading a lot of Javascript. You should aim to chunk your application and lazy load the modules only when they are needed. Most frameworks make this simple enough. Dynamic imports are also supported in vanilla js and in most browsers.
Web Components / Custom Elements
Are you / should you be considering use of Web Components in your application? If so choose tools that will allow you to do this smoothly by integrating with your applications tool chain, e.g. some frameworks have baked in support for creating Web Components.
You should consider using Web Components if you have a relatively complex application where decoupling components makes sense, e.g. you need to re use these components outside your application or you want to allow them to be developed using other frameworks / libs.
Linting
There are many linting options. You should incorporate a tool like lint-staged into you dev process early so you always catch lint issues before they get into you main branch.
You might consider a shared editor config that auto fixes linting issues where possible.
eslint-plugin-compat helps ensure your code is compatible with your target browsers.
stylelint warn about css mistakes.
There are linting plugins for accessibility also so check if there is one for your particular setup and add it.
Check what is already baked into your framework as some will already include some compatibility and style checking.
Formatting
Set up a shared editorconfig file that will ensure everyone is on the same page when it comes to formatting you js, css, and html. All major IDEs will have support or a plugin/extension that will allow this.
Code Optimization
Most frameworks / libraries will supply tools that allow you to build production version of your app that runs optimizations on your js and css. If that's not the case install source map explorer and use it to see if you have any unnecessary bloat.
Team
If you are lucky enough to have dedicated team members consider there skill levels and also how the team may evolve. Tailor your approach with this in mind, by avoiding confusing implementations or incorporating many libraries that have steep learning curves. Simple is better. Easy to read code is better than clever code.
Mobile
Will the application need to run on mobile devices? What mobile browsers are supported? How will you test them? What areas of the application need to be adapted for mobile display? Will you rely on Media Queries or a utility library that has responsiveness baked in?
Internationalization
Do you need to think about i18n? W3C describes it as follows:
Internationalization is the design and development of a product, application or document content that enables easy localization for target audiences that vary in culture, region, or language.
Localization
Do you need to think about l10n? W3C describes it as follows:
Localization refers to the adaptation of a product, application or document content to meet the language, cultural and other requirements of a specific target market (a locale).
Wrap Up
That's all for now. There's a lot to consider and some won't be applicable depending on what you are building but it's good to have an understanding of the options so you can start on the right track.