Back to basics of website development.

Eleventy, PostCSS and a focus on Accessibility

The World Wide Web (Internet) has come a long way since its inception in 1990. It's time we took advantage.


For a long time I have been moving around the internet focusing on different areas to work in. Most of these have been on the bleeding edge of development using the latest language flavour of the month.

These include, PHP (Wordpress, Laravel, etc), Go, JavaScript (Frameworks like Vue, React, etc), Ruby (Ruby on Rails), the list continues with many experiments. The one thing I didn't settle on early was that I much prefer working with static site generators over dynamic for the speed, security and absolute nature of the final result.

This has led to me messing around with multiple different generators that include, Next, Nuxt, Spike, Hugo, Middleman, and many more. It has only been recently though that I decided to consolidate my development stack and with that figure out where I want to position myself for future projects.

I have also needed to update my site for the longest time with some real effort to getting it right but everything was hidden behind smoke and mirrors and that never really sat well with me, think Webpack, Babel, Sass, Nuxt.JS, etc.

With my recent retirement from company employment in December I sat down and really started to think hard about what I wanted from both my website and my tech stack. More importantly I thought about what I didn't want.


The one thing I knew I needed above everything was simplicity so I decided to start from the ground up and make a list of what I did and didn't want and came up with the following requirements.

  • I want a static site.
  • I want to use modern HTML.
  • I want to use modern CSS.
  • I want to use modern "Vanilla" JavaScript.
  • I want an accessible site.

Each of these comes with its own cravat that can be expanded on further below.

Static Site Generator

Fairly recently I saw a post by Jh3y that mentioned this generator that I had heard a couple of times previously but never explored. The one thing that stood out from his work was how hands off the project is. Perfect time to jump right in and take a look.

11ty is quite simply everything I've been looking for and less. 11ty does a great job of staying out of your way when you want to make things. It doesn't care how you want to display your data or what you're going to use to style it. It simply provides a "Framework" that allows your to generate a static website (Another blog, another time) using one of a number of available template languages (HTML, Nunjucks, Markdown, etc) and compile these in to super fast, pre-compiled, HTML pages.

It is up to you to decide how you'll setup your CSS, Images, JavaScript, Blog posts, etc. There is no excess JavaScript bundled with your website, no webpack configurations (unless you want to) or complicated folder structures to get used to... again, unless you want that. But I certainly don't.

Using 11ty has allowed me to develop a base template that I can rapidly develop in to a starting template within a matter of hours instead of days. I've included only the things I need without anything I don't and the majority of it is using Markdown which is now my document language of choice.

It took some time to get used to just how much work I had to do myself over other "SSGs" (Static Site Generators) but I'm now all in with it. I will use it for the basis of all website development work. No matter how complex. From simple landing pages to front end template development that can be merged in to a more complex system like WordPress or Laravel as an example.

The benefits for taking this approach far outweigh anything else I've used. I can mock up a site in record time, know it is secure by default as it has no dynamic code that can be susceptible to bugs, has no back end that can be attacked by malicious actors and is blazingly fast because it has already been compiled and optimised before being viewed by the visitor.

  • Rapid development
  • Fast.
  • Secure.

Who uses it.

Just to confirm that I'm not on a whim and I'm in good company with choosing this stack, below is a list of some great projects that also use 11ty.

  • a11yproject
  • Foursquare
  • ESLint
  • Chrome Developers

Modern HTML

Out of the three main front-end technologies (HTML, CSS, and JavaScript), HTML has remained the most consistent. If your only concern was creating content, an HTML document from the 1990s would look pretty similar to one created in 2018.

When HTML5 was introduced in 2008, it provided new elements to improve document semantics. These elements include:

  • main
  • section
  • article
  • nav
  • header
  • footer
  • and more.

These help to organise your content which aids with code structure so its easier to understand your site when developing it but also it helps to make your site accessible to, web browsers, search engines and users with screen readers which all depend on semantic HTML to function correctly.

You can read more about this with the article over at medium called Modern HTML explained for dinosaurs

Modern CSS

Along with HTML, CSS has come a long way in recent years. Providing many features that could only be found in languages like SASS or LESS. Now we have this extra functionality I think it is time to ditch the frameworks (Bootstrap, Tailwind, Foundation) and the dynamic pre-processor style sheet languages (SASS, LESS). Instead its time to concentrate of the modernisation of CSS and take advantage of its current and future features and use less boilerplate .

A lot of people use SASS, which was a mind-blowing concept when it first came out. A new language to write advanced CSS with but I simply don't use it enough to warrant really getting to know it.

The features that I used the most (class nesting, imports, variables) are all on the roadmap for CSS as various stages of discussion anyway and can be provided by the use of certain plugins. Based on the actual standards that will become default eventually, I don't have to think about various changes that turn me away from CSS.

An example of this is the SASS change to @import that now requires the @use rule instead. If at some point in the future I wished to move from SASS, I then have to change all my SASS files back to standard CSS and this can cause further breaks in my code.

So that is one less thing to think about while focusing on the core building block

Vanilla Javascript

The final of the three core languages, JavaScript seems to be undergoing the most change and has moved out of the browser on on to desktops, mobile phones and any number of IoT (Internet of Things) devices. This has lead to continuous improvements and features that removes the need to require external libraries to implement certain features.

This becomes a double edged sword as I both like and dislike where front-end development has ended up. Vue, React and Angular as an example, have brought us web apps but I see people reaching for these frameworks as their go-to option for something as simple as writing a blog or even a site generator (I've used a few myself) and I feel we need to draw a line and use the right tool for the job. Use only the JavaScript required. When required. Its simple. We can remove excess complexity, bugs and accessibility issues if only we were more conservative with our desire to use shiny things.

There is another issue with the determined use of JavaScript and that is for people, like myself, who block JavaScript by default on websites because I am a somewhat private person on the internet and we have way too many trackers online these days. The point here is, if you must use JavaScript then I can not see your data and this is a problem.

It is know that content matters for SEO (Search Engine Optimisation) and functionality. So if you can not display your data without JavaScript being used then you are not only blocking access for users like me but also for search engines and screen readers which, as we know, affects both your SEO and accessibility.

Goodbye jQuery, I never really used you anyway. Along with Vue / React / Ember / whatever other framework you want to put here. If I must use JavaScript in production (live website), it will only be after I have full functionality of the site without it and I want to add some metaphorical glitter to the project. There is no other reason for it on a regular website, blog, landing page, etc.

The only option for full JavaScript is if you have a web app and even then I think it's over done.

Conclusion (Accessibility)

From here on, my sole mission will be to make websites look great and function properly using the bare minimum technology to open up sites to as large an audience as possible.

From users who prefer-reduced-motion to the varying degrees of the visually impaired. Users should not be at a disadvantage because I'm too lazy to think about them when I'm building a website.

People forget that we are all curious at the day and information should be readily available to everyone as well as the opportunities to open up our business markets to more users and thus sales if that is the end goal.