build with purpose

No Javascript on the Web

Being a web developer seems to be increasingly popular as we reach “critical web” where creating a website is a introductory activity for many. Entry Level Bootcamps mostly teach students to become web developers.

The considerations when developing are vast and confusing for even experienced developers to traverse. One consideration involves the use of Javascript entirely. Or, should I say, it's abandonment.

No Javascript Web

Many have adopted the concept that websites should render without enabling Javascript. This means that all of the content should be accessible by the user without running any Javascript. Consequently, developers are able to deliver pages that render more quickly and pages that target users without Javascript enabled.

No Javascript

This seems like an impossible feat considering popular frameworks like Angular and React that support Single Page Applications (SPAs) where content is rendered with a Javascript engine. SPAs basically don't work without Javascript since links can't be routed by manipulating the DOM.

Understanding Business Needs

Business needs generally come first when a webpage is being built. But, there may also be exceptions to rules of thumb simply because the business needs dictates it.

For example, if my business is creating a news site with the goal of reaching millions of people, I shouldn't limit my pages to only those who enable Javascript. I should strive for improved loading times wherever I can find them. Other businesses that deliver complicated in-browser interaction, the No-Javascript approach probably isn't a good one. User Experience should still be strived for and this loss is acceptable.

Accomplishing No-Javascript Websites

There are three ways that I've discovered for delivering websites to the user without Javascript.

Option 1: Use Static Site Generators

A static site generator takes in content files with a set of attributes that it uses to construct a website. Any additional functionality to be added can be done in Javascript with the understanding that some users may not get this functionality.

My favorite example of a static site generator is Hugo which I used to make this blog. I really like Hugo for this because it's crazy fast, written with Go, and it's got great hot-reloading to see changes as they are made. Themes seem very customizable and their documentation is really exceptional.

Option 2: Server Side Rendering

Server rendered websites are built from templates and the resulting HTML code is sent to the frontend user. One advantage of server side rendering is that users familiar with Javascript can still build their sites with Javascript on the server. Another benefit is that backend requests for data can go right into a template before it even reaches the user. Frontend frameworks would build the template on the client side and request for data as needed.

Server side rendering is generally slower than static site rendering because the server spends time building the webpage. It also requires a dedicated server rather than a Content Delivery Network (CDN) where the site can be served from. Dedicated servers generally cost more and require maintenance.

Option 3: Blunt Force

Every page has it's own separate files and I'm OK with repeating myself. This is not a good path and it leads to significant tech debt. Look up the DRY Principle.

What does Ben use?

Static Site generation seems like a good tool for me to use because it's simple to host and update. I'm working on spinning up a documentation website for web developers and I find a lot of advantages to making the documentation as easy to consume as possible.

I have another project to make a mobile app using web technologies that benefits from using Javascript. For this project I think working with Javascript is going to improve my productivity and add functionality that I wouldn't be able to support otherwise.

Ultimately it depends on what I'm building.

You'll have to decide if it's important for you to include Javascript in your applications. I encourage you to think about what kind of application you're developing and ask yourself why you're including Javascript.

I'd like to add that I improved this article by following guidelines found in Scott Adam's article “The Day You Became a Better Writter”. I suggest you give it a read

Make my day and share this post:

Other posts to peak your interest:

  • Posts
  • Web Audio API for Media and Games
  • I Made and Released a Game
  • Seeking Change
  • Shipping Software in Japan
  • Understanding Visual Testing
  • comments powered by Disqus