A blog in 2023

It feels weird. Not wrong… just classic.

With a particular social media platform now owned by a fascist I felt it prudent to get this figured out again. I may not write, I may write a ton. I thought I might actually start posting pictures on my website instead of Instagram.

It is really amusing to me that in 2005 I was so excited about social media. I mean, who wasn’t?! MySpace let you put your favorite song on your profile, and everyone HAD to listen to it (or at least the first few seconds while they tried to scroll down the page to hit pause). You could pick your top eight friends, which honestly was a lot harder than it should have been. It felt innocent. It felt fun. But that really only lasted like a year or two… three tops.

I was on Facebook for 14 years. A lot longer than I was ever on MySpace. Facebook, for a while there, felt like a constant stream of thoughts and feelings.

• Updating my status at the bar when I’m sad I don’t have a date? Yup.
  
• Agonizing on whether or not to friend that cute friend-of-a-friend on Facebook? Yep.
  
• But is it Facebook Official? It honestly strikes me a little weird that I’ve never been friends with my wife on Facebook. Like, I don’t even think I’ve looked her up.

What a time to be alive. We’ve come full circle. From blogs to social media and now back to blogs. Remember Blogger? It still exists. Blogger, a really old Google product, still exists! Maybe they knew all along…

I digress. This is what this will be. Me typing and hitting “Publish”… “Yes, I really want to publish” and finally, “Publish now.” Safeguards are good to have in place. No agonizing here!

Why can’t we solve accessibility with a one line script tag?

This is a good question. There are some companies that’d like to beg to differ (such as AccessiBe, which is rubbish). This post is not for them. It’s for you. They know what they’re doing (and not doing).

To start: the web is (generally) accessible by default.

We break it. Me, you, companies, capitalism, you name it - that’s what breaks the web from being accessible.

<div> tags with an onClick event when the <button> element is right there, modals that don’t trap focus, and other examples are rampant throughout the Internet.

Let’s think about this from the angle of how your code is interpreted by the browser and accessibility software:

1. Write some HTML.
   
2. Load that HTML into a browser.
   
3. The browser interprets that HTML, and creates an accessibility tree out of it (among rendering it, etc)
   
4. The browser exposes an API that accessibility technology accesses, and a browser interprets the HTML as if it was written to standards.
   

• If this HTML is not up to spec, such as being used improperly (looking at a <div> with an onClick event, for example), the browser cannot infer what exactly that is for.
  
• This affects the accessibility technology, as it can only do with what the browser provides.

If we use web technologies improperly, do we expect a browser to somehow perform heuristics to get what we mean? After all, programming is literally telling a computer what to do in a language it understands. If we do not tell it what to do in a way it understands, it will generally take the safest path.

An example of this is correcting for when a closing HTML tag is missing. In older browser days, the standard allowed for certain tags to omit a closing tag and that was valid HTML. That’s not the case anymore (except for certain exceptions, like <input>!).

Take this code:

<div>  
  <span>Hello!  
</div>  

In any modern browser, the <span> above will be automatically closed in the DOM if you inspect it.

Screenshot from Firefox’s Inspector showing the DOM with a span that has a closing span tag, yet the source does not have that closing tag

In the source above, there’s not even an HTML tag, HEAD tag, or BODY tag, yet Firefox assumes it anyway. The browser can help us in many ways, but it cannot get our intent out of our badly formed code.

Sometimes, the standards aren’t all we need

In other instances, we can correctly use all HTML tags and still not make an accessible interface. This is where the nuance comes into play. For example, a modal. By definition, a modal is simply a dialog over top other elements. The user experience dictates that this is treated as a separate “document”, and there’s no standard way to do this. Modals in general break the way the web was created. A page is a “document”, yet a modal is a “document within a document.”

If a document is to really behave like a document, then it must be the sole document “in focus.” With modals, we generally add a “focus trap” to make sure that users cannot get out of it unwillingly. A bolt-on script will not know this is what you intended.

There are some instances where we need JavaScript in order to make the web accessible. Stephanie Eckles wrote a really good Smashing Magazine article that expands on this.

How does someone’s JavaScript know this nuance?

It doesn’t. It can’t. It won’t. And users that need accessible interfaces and experts in the field have said time and time again that it doesn’t work.

Don’t resort to bolt-on fixes

AccessiBe isn’t the first company to do this, but it’s making big promises and being slimy in the process. There are others named in the Overlay Fact Sheet - they should all be avoided.

Accessibility is not a bolt-on.

Front-end development is not automatically easy. Project timelines should reflect that.

I’ve had the title of “front-end engineer” in some sort of capacity for almost 9 years now. In these 9 years, one thing has not changed:

This could be true, but it is not usually true. We see this in discourse on Twitter, in meetings throughout our workplaces, and in general the vibe that front-end is not really “development”, “engineering”, or “programming”.

Why do questions / statements like this matter?

This sentiment towards a craft really “grind my gears” so to speak. It emboldens the following assumptions:

• That front-end (HTML, CSS, and JavaScript) languages are easy.
  
• That there is no lead time to “getting things ready”
  
• That there is no lead time to really get a project into a “let’s go” state.
  
• That there is nothing to clean up (if it’s an existing project)
  
• That you can write code once and it works and it’s good to go (browser testing across devices is a thing!)
  
• That organization and writing clean, maintainable code takes no time at all.

These assumptions are harmful to any craft - but we see it all the time with front-end engineering.

What is a better response?

Timelines are important to any project - I’m definitely not disputing that. Front-end engineers are usually sandwiched between design and back-end engineers - both of whom are usually given a bit of lead time to really understand the problem. Many front-end engineers want to be and need to be part of that lead time / discussion.

• Ask the ones writing the code
  This might sound wild, but ask the people who are making the changes and adjust your business priorities accordingly. They may waffle on an answer, but their waffling is also a good indication it may take a bit more time than you realize.

• If you allow time for design, allow time for development
  It is not unfathomable that the time it took to research / come up with finessed designs might be around the same time a developer needs to execute the designs.

• Give front-end engineers the respect they deserve
  Front-end engineers have to support a wide range of clients, deal with languages that are constantly changing (like, literally, every 4-6 weeks a browser might support something new), and constantly have to watch out for themselves by not painting themselves into a corner when a new design comes across the table.

Design is not easy.

This applies to the actual creation of designs (UX, visual, content, etc) but also architectural design of a codebase. Companies all the time find themselves in a situation where a codebase is not “feasible” to be upgraded because things weren’t thought of when it was designed.

How do you overcome this problem?

Slow down. Take a bit more time to create a scalable system, no matter the language, that can take you from small to large. I’m not advocating for perfection - I’m advocating for sensible and pragmatic development.

Invest in what you’re making - whether you’re a small startup or a company that can throw tens of millions of dollars at a project on a whim.

Allow your engineers this time. It will help you (and your team) later.

Use a (Code) Style Guide

Being a developer doesn’t mean you’re just coding all the time. You code, but you also communicate, interact with other people’s code, maybe even get on a zoom call. Whatever it might be that you do, being on the same page is probably a good idea.

In my various development experiences, I’ve found that setting expectations of what “good code” or “clean code” looks like is a great way to help folks who do not necessarily know what questions to ask or if they even have any questions.

What is good code?

Well, honestly, good code is what you make it to be. As long as it works / compiles / whatever, it’s code. You can show your fellow coworkers / cohorts what good code looks like, but until you write down or codify (giggle) what that is, folks are going to write what they want to get the job done.

Why is this necessary?

For a lack of better jokes: so that everyone is speaking the same language. If everyone writes code similarly then it helps code reviews, discovering bugs and pairing in general. I find myself doing at least two things before I really can start thinking about the problem being presented to me when I am pairing with someone:

1. Adjusting to the style of the code, whether that is the organization of the CSS rules or how abstracted the JS is.
   
2. Re-reading through everything before making sense of it and making recommendations.

I feel like this goes faster when everyone kinda does things similarly.

Style guides help do the following:

• Ensure everyone is writing similar code
  
• Ensure readability
  
• Ramp up new developers to the “expectations” of “good code” or “clean code”
  
• Clears up any issues regarding the above otherwise vague terms.

What does a good style guide look like?

Well, again, that’s up to you! I have some recommendations, though:

CSS

• Airbnb’s CSS Style Guide
  
• Harry Roberts’ CSS Guidelines
  
• Andy Bell’s CUBE CSS

Javascript

• Airbnb’s Javascript Style Guide
  
• Google’s Javascript Style Guide
  
• StandardJS (an enforced style guide)

There are many others out there, and some of those out there come with their own tooling, such as Airbnb’s banel-preset-airbnb or even StandardJS’ npm install standard.

Being on the same page with your team with regard to “good code” not only improves communication and team dynamics, but it reduces the “omg who wrote this?” reaction you might have before you pull out git blame :)

Reusability: It’s good!

“Reusability”, “Reusable Components”… we’ve all heard it before.

In my last post, I spoke about the Single Responsibility Principle. Now, if we take this idea and apply it to “reusable components” or “reusability” it makes total sense. But aside from reusable components, what other ways can we make our code more modular and reusable?

Let’s put it in the context of the code below:

This is a very rudimentary example, but I have found a lot in my experience as a front-end engineer that when writing code, sometimes there is not a thought to abstract something that could be calculated / used somewhere else.

How might we make the above code a bit more abstract? Or how might we break out some functionality to be able to be used elsewhere?

Take this modified code sample for example:

The above takes the hard-to-read bit in the console.log() from the first script block and makes it easier to read and makes it so we can call it anywhere.

Writing code in a way that is very easy to read is caring for your fellow developer, and it makes it easier for you to come back to in a few months and not want to pull your hair out!

Happy abstracting!

Single Responsibility

Single responsibility is a concept that has been around for a while.

Wikipedia defines it as:

…a computer programming principle that states that every module or class should have responsibility over a single part of the functionality provided by the software, and that responsibility should be entirely encapsulated by the class.

This helps your codebase be easier to maintain, easier to debug, and easier to learn.

Do one thing, and do it well

Whether you’re building something for yourself, you’re the only one on the team, or you’re part of a giant development team - there’s a certain need for having an “orderly” way of “doing things”.

In my intro post, I started off the introduction to this topic by saying:

script.js is so 2014

Think about having all of your current JavaScript code in one file. It used to happen! It still does happen. It’s daunting for anyone coming into a project. Sure, you can help supplement the knowledge you’ve dumped into it by annotating with comments or naming your functions properly, but it’s still a daunting thing to look at.

Imagine coming into a project for the first time. You’ve been tasked with updating this function on a website:

The above creates an event handler via jQuery (don’t get me started on jQuery), but doesn’t really infer why it exists.

The switch to component-based architecture in the front-end world and really just the transformation of JavaScript from being simply a DOM manipulation tool to a complex infrastructure language (thanks Node) has brought about a lot of change to the ways we write it.

In an Angular 2+ world with TypeScript (when written according to John Papa’s Angular Style Guide), the above code would be written in at least three different files, like so:

There would probably be another file to act as a state class across modules (another Angular Service) to change the CSS as in the first example as well, but I think you get the idea of what I’m going for here.

Writing more code isn’t necessarily a bad thing

I find myself being verbose in my writing of JavaScript / TypeScript nowadays, and I don’t view that as a bad thing.

Verbosity in code isn’t inherently inefficient. It isn’t going to slow down my application, at least in a way that’d really matter. Tree shaking and whatnot exist now! Let things be singletons. Let things do exactly what they should do and not a thing more. There was a time when we didn’t compile our JavaScript code, and it made sense to not be verbose. But now, now that we can compile our code means we can be verbose too. The front-end world gains access to a lot of things back-end / compiled languages have enjoyed for a while with these new tools.

I’m of the opinion that it doesn’t go against the idea of pragmatism to be a bit verbose. Writing a bit more meaningful code than would be necessary for the now makes my job of maintaining / adding / scaling the thing I’m doing now easier for me (or someone else!) in the future.

Of course the jQuery code listed first above would work for the purpose we’d want. It did back then! It would do so still. But there’s a way, and then there’s a better way (for all those involved).

My codebase isn’t built with this in mind. Do I have to scratch it all?

Codebases are always changing. We’re always adding to them, deleting from them, and manipulating in between. Start on the path toward single responsibility.

I’ve encountered this in the past. I came into a codebase that had several different frameworks within it. One was used in one part of the app, another in another part. No real rhyme or reason for any of it. I made it my duty to go through and bring everything under the same umbrella.

Developing with empathy means that you keep the following in mind:

• the person before you may not have had the time to think about the bigger picture.
  
• the person before you may not have had the technical know-how to always think about the most common denominator.
  
• you should leave the codebase in a better state than it was before you arrived.
  
• the people you work with now are likely to need your help in keeping the codebase healthy.
  
• you can’t solve everything.
  
• the person after you could very well be in the same position you are in right now if you don’t fix what you can.

I made my aspirations for the codebase part of the expected work and not just “outside” the realm of the project work.

This meant bringing items that did similar or even the same thing into one hunk of code by introducing reusable components.

I’ve already employed this strategy. I’m good to go.

Is it? This isn’t a “we built it with this in mind” kind of topic. Quite the contrary - what you wrote on Friday, was it built with this principle in mind? This is an always on principle, and without it always on, you can get lost from it pretty quickly.

At a previous job, my team and I for the most part maintained this principle. This was a codebase I led for a while and I still let some of this slip. It came back to haunt us! When asked about x being a reusable component, I had to admit that it wasn’t, that it was built specifically for a particular purpose because we didn’t have enough time to generalize it and merge it into our existing patterns. It’s not a failure - but it shows that it requires constant communication with project leaders, designers, and everyone else on the team to maintain a codebase in the most optimal way.

This doesn’t just apply to JavaScript / TypeScript

Single responsibility makes its way into CSS too. OOCSS, BEM, and all the other “ways” of doing CSS make some part of this part of their schema too. I’ll expand on this in another post.

tl;dr

Writing a codebase with single responsibility in mind is hard work. It takes a lot of thinking and planning to be comfortable breaking complex ideas up into small bits that all do “their own thing” and can be reused. However, it allows developers and teams alike to work quicker, increase speed and efficiency, and helps onboard new developers and instills good heuristics on what should be “new” and what can be reused.