Prototyping Webapps in HTML

Every once in a while you are inspired and have a few hours to burn. An ideal time to start building a quick little prototype. It’s a nice break from the usual work. A productive prototyping session may help you remember why you’ve chosen software development as a profession. Our prototype should probably be interactive and demonstrate something useful, so we’ll need some modern javascript tools and techniques. Luckily those are abundant nowadays. We open our terminal, discover a lot of things we didn’t know and the hours fly by. After a while we look at our progress and are shocked: we finished setting up the development environment and our time to prototype is running out. Maybe next time we’ll get to work on the actual prototype.

If we had just stuck with HTML and Javascript we would have had a lot more time to make progress on the prototype. We already have all the tools we need to build and execute such a program. Sharing and distributing is straight-forward. Send someone the file, put the file on a server, or copy/paste it to an online playground. HTML and Javascript should be our weapons of choice when building simple and quick prototypes, yet they aren't. Why do we rather struggle with our tools and techniques instead of struggling with the problems at hand and what can be done about this?

Big problems are solved by breaking them down into smaller solvable problems. Likewise, a big application is broken down into discrete units or building blocks (or components). The building blocks of a web application ultimately consist of HTML, Javascript, and CSS. At the level of the HTML document, there exists only HTML, Javascript, and CSS. HTML has no notion of the building blocks we invent (yes web components, but no). We cannot map our mental model of an application onto the model HTML provides. We are forced to split our building blocks into their constituent parts (the HTML, CSS, and Javascript) and scatter these throughout the HTML document. You may have noticed that this gets messy rather quickly.

Frameworks got this part right, they understand this gap between what HTML provides and how a developer likes to look at an application. Frameworks allow us to express an application in a language and vocabulary that is much better suited to our thinking. That is power right there. Who will ever want to go back after you’ve experienced that power? I think this explains the immense popularity of frameworks. At the same time, it also explains why these frameworks come and go: the way we mentally model (or would like to model) our applications evolves with time and experience.

A productive prototyping session should be about producing a quick (set of possible) solution(s) to a problem and demonstrating these at the end of the allotted time. These sessions can be intensely rewarding and may remind you of exactly why you’ve chosen this profession. This is not the time to be learning, troubleshooting, and struggling with the potentially powerful tools you’ve brought to the game. It’s time-consuming, it’s frustrating, you may lose your focus and your inspiration and ultimately miss out on an opportunity to experience the absolute joy of programming. So only use tools you’ve mastered and techniques you are fluent in.

For me, Vue.js is most compatible with the way I’d like to express an application. Even though I’m pretty comfortable with the suite of external tools that come with Vue I still find the mental overhead to be too great for quick prototyping. Setting up a quick little project takes more than 30 seconds which is too big a barrier to even get started. I prefer to stay as close to a simple HTML document as possible. Even though Vue can be used without tools in a simple HTML document, it will not get you as far as it might. The best part of Vue, it's Vue Single File Components allow you to express a single building block with the HTML, CSS, and Javascript in a single file, but unfortunately requires external tooling. To be a suitable solution to prototyping web apps in HTML it should provide us the ability to define many building blocks inside our HTML file.

That’s why I wrote Vue Blocks. A small layer that extracts Vue’s building blocks from the HTML document and hands them over to Vue. These building blocks are usually components and routes and I want to be able to write them all inside the HTML document as follows:

<template component=”my-component”>
    <div> <h1>My awesome component </h1> </div>
    <style> h1 { font-size: 1000px; } </style>
    <script> 
        ...
    </script>
</template>

<template url=”/path/to/route”>
    <div> <h1>My awesome page </h1> </div>
    ...
</template> 

Each time Vue Blocks encounters a template tag it will check if it’s either a component definition or a route/component definition and registers it with Vue. This allows me to write many (small) components in one document spares me the mental overhead of switching between files and contexts. It allows me to focus fully on my idea, proof-of-concept, or mockup. When a prototype is successful I may extract the building blocks from my prototype and organize the project as a more formal Vue application, including all the external tooling. To aid in this conversion process I've also written an Online Vue Converter.

To demonstrate how easy it is to get started on an HTML + Vue Blocks prototype I’ll provide this full HTML example. It is how all my prototypes currently start like.

<html>
<head>
    <script src=”https://unpkg.com/vue-blocks/dist/vue-blocks.js”></script>
</head>
<body>
    <!-- vue mounting point -->

    <app></app>

    <template component="app">
        <div>
            Hello {{name}}<br>
            <button @click="doSomething()">Click here</button>
        </div>
        <style scoped>
            div { color: red; }
        </style>
        <script>
        return class vue { 
            name = 'World';

            doSomething() {
                alert("You’ve clicked");
            }
        }
        </script>
    </template>
</body>
</html>

There is also a working example available on jsfiddle: https://jsfiddle.net/jangnoe/b29p7tek/3/.

In this article, we uncovered the gap between how we think about our applications and how 'simple' technologies like HTML and Javascript allow us to express our applications. Frameworks fill in this gap but come with costs in the form of external tooling. Having a productive prototyping session requires utmost focus and concentration and you don't want to be struggling with your tools. Even though Vue can be used without tools it would be so much better if it would just extract the component definitions from the document, so I've created a small layer called Vue Blocks to fill in that gap and have been using it quite productively the last 4 years.

To learn more about Vue Blocks check out: https://fluxfx.nl/vue-blocks/examples/

The online editor experience allows you to try out Vue Blocks online: https://fluxfx.nl/vue-blocks/examples/try-it.html

Photo by iMattSmart on Unsplash