The biggest challenge when building webapps
Me: Mom, can I have tools to build webapps?
Mom: No, we have tools to build webapps at home.
Tools to build webapps at home: Tools to build webpages
Webapps are not webpages. In this blogpost I’ll go over the differences, the tools used to build them and my thoughts on some missing some tools.
What is a webapp even?
The term webapp, short for web application, which was created to distinguish websites that were just a bunch of webpages. Webapps are more like desktop applications that just happen to be used in the browser.
Some webapps are literal clones of their desktop counterparts like Slack and Discord. Some webapps have a mix between browser and mobile app, with examples like Gmail and Jira. Some webapps are representation of other things, such as GitHub (representation of git repositories) and AWS console (representation of AWS services).
Then what about webpages?
Webpages are what we traditionally mean when talking about the Internet. It is mainly static content, interconnected with links. Think MDN Web Docs and IMDb.
Ackchyually, it’s a spectrum
Then there are some websites like Reddit that don’t seem to fit the mold of one or the other. That’s because webapps and webpages fall on a spectrum.
Applications are interactive, where as documents are passive. The way we build each have different design paradigms.
Application vs. document design paradigm
Consider a video game for a moment, most have elements affixed to the edges of the screen. Things like scores, ammo count, and mini-maps. These elements are responsive to screen resolution and aspect ratio but are fixed to a single viewport. You can only have so many elements as there is finite screen space. Adding additional elements cannot be automatic, a designer needs to decide where to put it.
In comparison to a book, if you wanted to add more content, it just pushes the rest of the content to later lines. Adding text reflows paragraphs. An ebook reader doesn’t even need to adhere to the original page numbers. It can reflow the text and form pages that perfectly fit your screen and font size.
This is exactly how webapps are to webpages. If you have a fixed bottom nav in a webapp, you may run into trouble when trying to add more items, where as if you add more content to webpages, the page just gets longer.
Webapps need to deal with finite space, webpages just scroll.
Crux of the issue
HTML/CSS was designed to build webpages and has many sensible defaults, such as overflow-y: scroll
on the main element and HTML content flow, which determines the default positioning of HTML elements.
Building webapps with HTML/CSS is swimming upstream and requires a combination of various hacks and workarounds:
- use
overflow-y: hidden
on main element, and deliberately deciding on scrollable areas (and suffer performance penalties) - use
position: absolute
to manually position all elements - use media queries or vw/vh units to scale all elements to viewport
- use
event.preventDefault()
all over the place in order to prevent normal webpage behaviour - use
history.pushState(..)
to make webapp urls deep linkable (typically handled by single page application routing libraries)
But what about <canvas>
? Couldn’t we use that to render our webapp to avoid those issues? Sure, but then we would need to reimplement all the hit detection for interactive elements like buttons. And don’t even get me started on the code required in order to restore the basic functionality of being able to select and copy text rendered on a <canvas>
.
We could reach for a <canvas>
framework and that would implement hit detection for us, but is this the right direction to go? That would require training everybody on a whole new third-party framework, where as all those HTML/CSS hacks and workaround does have one benefit; the thing the team would need to learn is just more standard HTML/CSS.
At the end of the day, what would make building webapps easier is a set of HTML/CSS layout components for the purpose of building fixed viewport UIs.
Is Battlefy a webapp or webpage?
We’re a little bit of both. We have landing pages which are webpages. But we also have full screen wizard UIs and tournament management screens, which are webapps.
Ultimately, we’ve decided to align with the expectations of our users. In esports, our users are video game players and are used to applications, not webpages.
We have not fully solved all the problems with building webapps, it's an ongoing journey. Do you want to help us solve these webapp design issues? You’re in luck, Battlefy is hiring.