Today I wanted to share a little bit about a side project that I have been working on called Webboard! Webboard is a whiteboarding Progressive Web App meant to be fast, cross platform and with a focus on ease of use. I started building this app as an excuse to dive deep into the Canvas APIs but realized halfway through that this is a good way to experience the full realm of shipping a “production ready” PWA. Today, I would love to share some of that experience with you in the hopes that it helps you with building your next PWA!
Step one, choose a tech stack
The first thing I do when building any app, including PWAs, is decide which tech stack I would like to use. This step is crucial as it can have a big impact down the road in areas like performance and developer experience.
When I am choosing my tech stack I like to keep a few things in mind, namely:
- What are the performance characteristics of my frontend framework? For example, how large is the bundle size of a starter app in this framework, does it support easy lazy loading etc.
- What is the developer experience for this framework like? For example, I prefer templating using JSX or lit-html style templates (and overall prefer a react style dev experience) but others might prefer the Angular style way of doing templates directly in HTML. This really just comes down to personal preference, but can also have impacts on performance.
- How well “supported” is this framework? When I think of support I dont mean just how active that frameworks developers are on Github, but also what technologies that framework uses and how standard they are to the web. Frameworks built using web standards such as web components are normally much more likely to not break because of future browser changes compared to APIs that are entirely custom to a framework. The browser has to be much more conservative with breaking changes, so web standards will be more stable API wise.
With these things in mind I normally find that one of the newer Web Components based frameworks such as Stencil and lit-element fit my requirements really nicely. For Webboard I ended up choosing Stencil, but lit-element would have worked very nicely as well!
Low latency drawing
One of the largest challenges when building an inking experience is latency. Humans are used to seeing a line appear as soon as they drag their pencil/pen across paper, but an inking experience with high latency means that there is a delay between the time a user applies their pen or finger to the screen and that a line actually appears. This degrades the inking experience for the user and therefore traditionally has made it hard to build high quality inking experiences on the web, but this is no longer the situation!
Canvas now supports a
desynchronized option that tells the browser to cut out as much of the normal rendering chain as possible so as to get pixels rendered fast. This greatly reduces any latency that would normally come from the compositing process and therefore improves the inking experience for the user.
Deeper integration with the OS
The most exciting thing for me about PWAs is the opportunity they provide for your web app to deeply integrate with the operating system and provide a richer experience for the user. For Webboard this deeper integration was achieved with a few key features.
The first thing I focused on was the install experience. Traditionally native apps have been published in app stores that provided an app listing to advertise/ introduce your app to users but this is something that is currently lacking from the PWA install experience. Because of this I decided to build out my own install experience using the
beforeInstallPrompt event that provided an app listing type experience:
I am also investigating packaging this install experience as a standalone web component that anyone could use in their app!
The next thing was taking advantage of some more advanced Service Worker APIs to provide a better offline / slow network experience for users. When building a PWA we have to keep in mind that we are building an app experience, not purely a website experience and there are certain things users expect when they are using an app. One of these things is the knowledge that losing a network connection is not going to break the experience for them. To make sure Webboard works well in this scenario I made use of the background sync API to ensure that boards can be saved to the cloud even if they are created while offline. This also ensures that no work is lost if the connection is lost while making a board.
Finally, one user experience advantage that native apps have traditionally had over web apps is the ability to tie into the native file system on the device, but that is now changing with the new Native File System API! The Native File System API enabled me to build a very smooth experience for saving / writing to boards locally without as many prompts as normally required when using files the traditional way on the web, along with greatly simplifying the code.
Note: the file system feature will only be enabled if webboard detects that the API is supported in the browser its running in. Currently this means Chromium based browsers that have a flag turned on, but this will expand once the API has reached the stable point.
Webboard is a PWA which means you can use the app by just visiting this url https://webboard-app.web.app/ ! Webboard can be used on any device with a web browser and works on Windows, Android, Linux, Chrome OS, iOS and macOS. Also, if you are on Android and prefer to get your apps from the Google Play store I have released Webboard as a Trusted Web Activity .
Note: If you have not checked out TWA’s yet I definitely recommend checking them out as they provide a very low friction way to get your PWA in the Google Play Store. PWABuilder makes it really easy to package your PWA as a trusted web activity by clicking the TWA option when downloading the Android package.
Webboard is also completely open source and is available on Github.