A JavaScript Free Frontend - Slimvoice - A Webapp Without JavaScript is a series where I document how I rebuilt my app, Slimvoice, using as little JavaScript as possible…

I’ve tagged this series with JavaScript to present JavaScript alternatives and encourage those who reach for a SPA for every project to give it a second thought

Prelude

I built the first version of Slimvoice on Angular 1 with a Node.js backend and MongoDB in 2014 (those were all the rage back then). In 2015 I decided to completely revamp the UI and redesigned and rebuilt it in React. In hindsight, all of that was crap. With the new version I wanted to prove that it was possible to deliver an amazing user experience with a great design while drastically reducing the complexity of the code, maximizing reliability, and minimizing the cost to the end user. I’ve got the frontend to a state that I’m really proud of. Here I’ll break down the decisions I made on the frontend and share some JavaScript-free UI tricks I learned along the way.

Single Page Apps

The Website Obesity Problem is not getting any better for the web at large. I’m tired of slow-to-load webapps that are not very reliable. Has anyone tried modifying the description of a card in Asana lately? It’s freaking slow! The UI lags for no good reason as you type. First, I live in a rural area with only 2 Mbit/s down Internet connection. With a warm cache it takes 14 seconds for the Asana UI to become usable. Second, you can see below that the app is comprised of over 10MB of uncompressed JavaScript. That is a huge amount of code to execute. How is this acceptable?

With a “progressive web app” of a moderate level of complexity you need a team of people to make it work. You end up with a massive portion of your codebase being just for the frontend. Seriously. Getting things to load in the right order is a difficult problem that we’re just throwing even more software at (see Redux and friends). What if you could just do away with all of that? The more code you have, the less agile you are. Code is a liability, not an asset. It’s like tar. JavaScript libraries are getting bigger all the time and I don’t think that many people are critically evaluating the actual need for them. People frequently measure JavaScript in KB or MB as if it is just a download cost. But it’s not. You also have to wait for the CPU to parse/execute it. It all adds up.

Alright. Lean in close. I have discovered a secret that I will share with you about frontend development. Very few people know this, so don’t go running your mouth. ***Your frontend can’t crash if you don’t use JavaScript.***HTML doesn’t throw exceptions. Less code is always better.

Shout out to Elm for being pretty dang awesome, however.# Plain Old HTML and CSS

For Slimvoice I wanted to go against the grain of the modern JS hype train and make the app entirely server rendered. You might say “Ah! But Matt! The user must reload every page when using your app, which must be slow!” to which I say phooey. All of my assets are gzipped and cached, which leaves only the HTML to transfer as you interact. I don’t have loading spinners. It’s faster than many PWAs I use by a long shot. Don’t take my word for it, open your dev tools network panel and compare Slimvoice to some popular PWAs. Oh yeah, and I don’t have JavaScript exceptions to debug in the console. Either the page showed up on your screen or it didn’t.

The Checkbox/Label Trick

Of course, there are some interactions in which reloading the page would be unacceptable. Here’s my favorite trick to add interactivity to an otherwise static HTML page. I used this for all dropdowns, modals, and filtering UIs in Slimvoice, all without JavaScript.

1. Create a <div id="myToggledUI"> containing some UI that you would like to show and hide.
2. Immediately above that, create an <input type="checkbox" id="myToggle" style="display: none;">. This will make an invisible checkbox in the DOM.
3. Whatever DOM node you would like to use as the toggle control, wrap it in a <label for="myToggle"></label> tag where the for attribute matches the id of the checkbox.
4. Use this CSS to hook it all up.

#myToggledUI {
    display: none;
}
#myToggle:checked ~ #myToggledUI {
    display: block;
}

This CSS says that the #myToggledUI element immediately preceded by a checked #myToggle element should be shown, otherwise hidden. The ~operator is pretty cool! Here’s a full working example.

Here’s a modal built with a <label>, a <div>, and a checkbox. The “Cancel” button is another <label> for the same checkbox, so clicking it closes the modal. There is a gray overlay behind the modal (position: fixed;) that also happens to be a <label> for the same checkbox, so clicking outside of the modal closes it as well. No React components. No click event listeners. Just plain and simple HTML.

I haven’t done so here, but you can add any CSS transitions that you like to this technique. No ReactCSSTransitionGroup here.

The <details>/<summary> elements

<a href="https://www.w3schools.com/tags/tag_summary.asp" target="_blank"><details></a> and <a href="https://www.w3schools.com/tags/tag_summary.asp" target="_blank"><summary></a> tags are rarely used but perfectly acceptable for many cases. I used them on the Acknowledgements page to show and hide the licenses for the various pieces of open source software I used in Slimvoice. Quick. Easy. No JavaScript. Works everywhere.

It’s a shame that you can’t control much of their appearance, but I do not think that making a small disclosure triangle match your brand standards is worthy of forcing a few megabytes of JavaScript on a user.

Forms & Input Validation

Many inputs have validation options built-in. The Mozilla documentation is comprehensive.

• Don’t forget about the required attribute, that prevents a form from submitting until a particular field is filled out.
• Number inputs have min, max and step.
• Text inputs can be of type email, or a custom pattern.
• Text inputs have minlength and maxlength.
• :valid and :invalid CSS selectors allow for a better UX.

No JavaScript!

Coming Clean

I did actually use some JavaScript on the new Slimvoice, but only when an interaction could not be replicated in any other way. For example, I implemented fuzzy search on the clients list to let you easily filter clients. Take a look at the production code (you might need to copy/paste the URL in a new tab, my server tries to prevent hot-linking). It’s not complex.

I deemed it was critical to have invoice line items be drag-and-drop sortable, so I employed Mithril just for the invoice editing UI. It’s the one and only JS dependency in the whole project (and only on a single page), and when I have some time in the future I would love to remove it altogether. There’s so little JavaScript in the app that it wouldn’t even matter if I minified it, so I didn’t. Go read my sources.

The Future

Plain HTML inputs covered most of my needs, but I found myself wishing for more innovation in the HTML spec to cover more inputs and remove the need for JavaScript altogether.

1. Why can’t we have a standard search element that filters a list on the client side (similar to how ng-repeat | filter: worked on Angular 1)?
2. Wouldn’t a standard HTML element for drag-and-drop sorting be awesome?
3. More advanced validation functionality, like comparing equality of two different form fields.
4. The ability to do the modal/checkbox trick above without it feeling like a hack and writing weird CSS.

Why have the UI options for the HTML spec stagnated and left it up to building custom JavaScript-driven elements? I think having a more robust set of standard UI elements is way more important than WebVR, WebBluetooth, or whatever other insanity they’re cooking up these days.

Conclusion

Did it work? Absolutely. A full reload of the biggest page is 230 KB over the Internet. Since I’m caching and gzipping everything, each subsequent pageview is around 6 KB; far smaller than the SPAs I’ve seen with equivalent functionality. Slimvoice is fast and small but doesn’t compromise on UX. Users are loving it so far. See it for yourself at https://slimvoice.co.

Absolutely nothing is complex about my code. I would feel comfortable handing the entire codebase off to someone else without explaining anything. I don’t know anyone who can realistically say that about a React/Webpack frontend.

I’ve been programming for over a decade and been building web apps full-time for six years of that. In those years the benefits of JavaScript and PWAs have proven themselves to not be that great, but their downsides are huge and often ignored. I’m completely done with JavaScript as a primary language for the foreseeable future.

• You probably don’t need a “Progressive Web App.” Seriously evaluate if your app needs such complexity. The boss/client may demand a PWA because it’s cool and popular and will back it up with a bunch of hand-wavy reasons. Make sure those reasons are legitimate.
• Stop tracking people. Don’t allow other companies to do so on your behalf. You will survive without Google Analytics. You will survive without Intercom. Serve everything from your own domain.
• Don’t be scared. You can build it yourself! You don’t need a framework!
• Don’t follow the hype. Make critical decisions about why one approach is better than another, despite what the marketing page says or what everyone else is doing. The people selling the cool new stuff are typically sweeping the downsides under the rug. Everything has a cost.

I’m extremely happy with how this version of Slimvoice turned out, but of course looking for ways to bring the JavaScript usage down to zero. I’d be happy to answer any questions about the design or development experience.

#javascript