Ryan Morr

Somewhere along the way, the web quietly stopped being a stack of pages you read and became a place where you do things — book a flight, split a bill, run a whole business from a browser tab. That shift is the entire story of web applications. They look like websites but behave like software, and building one well asks for a different frame of mind than publishing a page ever did. Here is how I think about them after years of building the things, with the jargon left at the door.

Every week, someone messages me a version of the same question: how do I actually break into this field? They have watched a few tutorials, built a to-do app or two, and now they are stuck in the gap between learning and getting hired. That gap is real, and nobody hands you a map across it. So here is the honest walkthrough I wish someone had given me — what the work really involves, the ways in, and how to show what you can do so people take you seriously.

A friend asked me this again last week: is web development still worth getting into? Fair thing to wonder. The tooling never sits still, the headlines can't decide whether we're doomed or unstoppable, and there seems to be a new job title every time I blink. My take hasn't really budged, though. Companies still need this work, it still pays a living wage, and there are more ways in than most people expect. So here is the unvarnished version — what web developer jobs involve, what they pay, and which way the wind seems to be blowing.

Ask ten people what separates web design from web development, and you will likely get ten different answers. Some treat the terms as synonyms. Others draw a hard line, as if a designer and a developer speak entirely different languages. The truth sits somewhere in between, and after enough years building things for the web, that boundary starts to feel both real and wonderfully blurry.

Using an object literal as a simple means to storing key-value pairs is common place within JavaScript. However, an object literal is not a true hash map and therefore poses potential liabilities if used in the wrong manner. While JavaScript may not offer native hash maps (at least not cross-browser), there is a superior alternative to object literals to capture the desired functionality without the pitfalls.

Many developers have become accustomed to using some variant of a DOM ready method to signify when they can begin to traverse and manipulate the DOM. Or, better yet, placing the scripts at the bottom of the HTML to avoid blocking render while ensuring the DOM is loaded when the JavaScript is executed. However, in this day and age of dynamic web applications, it seems like a rather antiquated approach. The DOM is not static, it is alive and subject to manipulation long after the initial page load. Simply knowing when the DOM is ready, while still useful, does not encompass the entirely of the desired functionality. Instead, how about watching for when specific elements become available throughout the course of runtime? Well, I intend to offer a solution to support exactly that kind of functionality using mutation observers as the means to a more modern approach.

With the introduction of the Selectors API in HTML5, developers finally got a native means to selecting specific nodes without the need to traverse the DOM in tedious loops. The two new methods, querySelector and querySelectorAll, facilitate this functionality by querying the DOM via CSS selector strings. However, these new methods lack the performance of their closely related functions: getElementById, getElementsByTagName, and getElementsByClassName. This paired with the fact that effective CSS design should translate into an abundance of simple selectors that could be leveraged by one of these functions, and the unnecessary performance loss becomes much more apparent. For this article, I will be discussing the performance considerations for querying the DOM and interacting with the results, and offer a simple abstraction for an all-encompassing solution.

Low specificity is key to good fundamental CSS design. Avoiding overly specific selectors and grouping similar characteristics helps to modularize your stylesheets resulting in greater portability and reusability of declaration blocks. This serves as an effective means to decoupling your CSS from your HTML. For this article, I will be focusing on some useful project agnostic declaration blocks, many of which form the basis of my CSS boilerplate given the ease in which they can be applied to any project without being too specific to any one project.

Responsiveness is critical for modern client-side applications. When a user clicks on something, they expect a result and some are not too keen on waiting. At the very least, a user’s actions should be acknowledged via a loading indicator or the like. The absolute worse case scenario is having nothing happen at all. This is often the case pre-initialization. The user interacts with a component without any effect or even error message because, unbeknownst to the user, the page is still in the process of initialization and event handlers had yet to be bound to their correlative elements. It’s an issue I have encountered on numerous occasions. A less technically inclined user may assume the site is broken, that makes for a bad first impression. For this article, I will be exploring a solution to this problem by way of capturing user triggered action events pre-initialization to maintain responsiveness.