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 tools.

What is a webapp?

The term webapp, short for web application, was created to distance themselves from 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 are something in-between a browser and a mobile app, with examples like Gmail and Jira. Some webapps are representations 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.

🤓 well 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 has 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 text to form pages that perfectly fit your screen and font size.

This is exactly how webapps are to webpages. If you have a fixed bottom navigation 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 suffering 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 that implements hit detection for us, but is this the right direction to go? That would require training everybody on a whole new third-party framework, whereas all those HTML/CSS hacks and workarounds do 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. Hopefully in the future, CSS container queries is the solution.

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 ourselves 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.