
[The supreme court is currently deciding a case](https://www.npr.org/2022/12/05/1140824371/supreme-court-gay-marriage-colorado) regarding a website designer. One of the concerns for the case that caught my eye was whether websites should be considered art.

As someone that spends their days in front of this screen trying to think up new and interesting ways to layout text and images, I sure like to imagine that there is a degree of artistry here. Now, I'm more on the JavaScripty side of things but I do find beauty in code all the time. A simple and clear solution to a problem is thought provoking and inspiring. To me, that's art.

## A More Beautiful Web

I believe we should be bringing _more_ artistry to the web. The problem is often a lack of vision. Websites aren't movies, there's no director to guide the show. There's a spectrum between craftsmanship and artistry varied by their degree of self-determination. Those furthest reaches are hard to find, a painting is limited marginally by cost and practicalities of the material. On the other end, we could imagine a furniture-maker is substantially limited by having specifications to follow but the details of their carving or fabric choices could represent a level of artistry too. Websites seem an awful lot closer to furniture, don't they?

All that space in the middle is occupied by corporate art. These are products made with care but rather diffuse direction and a distinct lack of vision. We are dealing with a [functionalist](<https://en.wikipedia.org/wiki/Functionalism_(architecture)>) approach in the web. Design to the purpose and no further.

For as much as we talk about the _experience_, it is not remotely important. In fact, what we mean is just a laundry list of features. Even when the customer isn't paying for the site itself that's what the conversation revolves around. I can say from experience that eCommerce development is not a question of how to make a pleasant shopping experience but an _effective_ one. And that is defined by all the ways that we cross-sell, up-sell, increase average order value, attribute sales, convert... In truth, our users can be seen as an obstacle to accessing their wallet but this myopic approach avoids the mutually fulfilling possibility of a beautiful or interesting or engaging application.

I propose 3 avenues for improvement.

- Treat the web like a movie, find a director
- Give instructions like you would to an artist
- Build partnerships, not assembly lines

## Building Artistic Vision

Many companies are already here but if you haven't heard there's a new C-level on the scene - the CXO. The chief experience officer is responsible for being the voice of the user but I want to elevate that a bit. This person needs to provide the vision that guides the feel of our application. What emotions should our user feel? Why are they invested in what we're doing. While some of the more mundane enterprise apps may lack the flair that warrants such discussion, a strong step in the direction of emotional appeal is always merited.

A task tracking app could just feature the status of a given item but we all know how it feels to get something hard done. Why should our application unceremoniously flip from "In Progress" to "Done" when it can celebrate with us? Animation is an often neglected aspect, consider embellishing and embracing the meaning of the moment. Confetti might be a bit over the top for the business-minded but a simple flourish can create a connection for the user.

## Communicate Intention

The dreaded user story. I won't wax poetic about the perfect formulation of some templated sentence, that's not the point at all! What I mean to say is that when we build our backlog, we need to strike a balance between achievable and aspirational. Creating enough breathing space to allow expression can me the difference between a wrote UI and an exciting one.

The backlog isn't the only place either, too often our product owners and managers of many breeds like to step in and flex their design muscles. A level of restraint here will allow our well-trained designers to identify the more unconventional possibilities. A little bit of trust and self-control could be the difference between an obvious implementation and an innovative one.

## Feedback, Feedback, Feedback

Part of what we're experiencing here is the magical division of labor. It's certainly efficient at breaking down the work but a website is not a widget. It's not as simple as sending everything downstream from customer to design to development. Cycles of feedback cultivate quality and hone in on the vision. Building an understanding between disciplines breeds efficiency too, even if discussions and meeting don't look immediately productive.

In particular, I would call out to developer for a closer relationship with designers. We are champions for the technology and the user, we need to communicate the practicalities and problems with a design. We can't expect the nuances of screen readers and responsive implementations to be top of mind for our designers who must work in the abstract, attempting to reach near infinite compromises between the seemingly endless conflicting needs of our users. Not only do we need to provide feedback but we need to take it as well. [Storybook](https://storybook.js.org/) is a great tool for building and documenting UIs but it's also a great place for designers to understand the many implications of a given implementation and take issue before things crystalize.

## An Artistic Mindset

The number one thing that needs to change is our thinking. We have endless outlets for inspiration - games in particular show how emotionally invested people are willing to be in digital experiences. If we trust in our abilities and strive for more, we can make something that users want in a truly meaningful way.



Static site generators are all the rage now but in the beginning there were only static sites. It was difficult to compare native applications to the web, the limitations were obvious to users and difficult to build around. (This seems like a good spot to talk about DHTML but it really doesn't matter too much to the point. Those static pages became sorta kinda dynamic by making the underlying static systems _able_ to be dynamic.) Enter jQuery, Ajax and the whole business of client-side logic. Add some years of growth in functionality (and expectations!) and you get the single page app and modern frameworks. Performance optimization inevitably led to AOT compilation, server side rendering, and DOM hydration to reduce the real and apparent load speed.

So why would we want to go back? There's a couple key distinctions here, the static sites we make now are radically different. In the past a static site lacked any dynamic content and interaction was fairly lackluster. In order to be highly dynamic and interactive you needed to trade off for performance with a thick client. We don't need to make that trade anymore.

Content can be dynamic to varying degrees. If you want content changing daily or even hourly its entirely possible to push out fresh builds in SSG. Following best practices of atomic deploys creates a seamless experience. If your content is changing by the minute or second, you're still in luck. Every imaginable service has been commoditized into an API, often free. We couldn't access content in this way for a long while and even when we could it certainly wasn't easy. Ajax has become `fetch`, `async`, and `await`.

What was once the 50k inclusion of the [Prototype library](http://prototypejs.org/learn/introduction-to-ajax.html)

```js
new Ajax.Request("/some_url", {
  method: "get",
  onSuccess: function (transport) {
    var response = transport.responseText || "no response text";
    alert("Success! \n\n" + response);
  },
  onFailure: function () {
    alert("Something went wrong...");
  },
});
```

Is now the native (and beautifully flat):

```js
try {
  const response = await fetch('some url);
} catch(e) {
  // Handle error
}
```

We haven't lost or forgotten Ajax. It was such a fantastic idea that it has become a part of the foundation of the web.

One of the (less and less) frequent criticisms of static site generation is that it loses interactivity. I think this largely comes from the growth out of blog-style generators like Jekyll that requires some gymnastics to get interesting things to happen. If you work inside a framework aware system like [gridsome](https://gridsome.org/) you can absolutely create interesting highly interactive sites even though they are statically rendered. Static refers to the artifacts, not the outcome. The interactivity is built up inside the client instead of the server. We don't need to through away all that SPA technology that we've built up. We only have to utilize the SSR technology we already have, albeit for different reasons originally, to introduce them into this space.

I hope I've convinced you that the JAMstack is not a hamstrung version of what we've been doing for the past few years. In fact I hope you find these notions and approaches to content and interactivity to feel fairly natural. Why bother though? This is the magic of static, CDN super powers. CDNs are fantastic at caching static content but if you turn that idea on its ear, they're also fantastic at _hosting_ that content. If you can manage to bake your entire site down into static files, you don't need to manage a server to host it. Pop it up on a service like [Zeit](https://zeit.co) and get incredible performance for _free._

When you use the JAMstack you're not spending your time figuring out how to do the same things every other site is doing. You spend your time thinking about what yours can be doing next.



Recently I saw [this talk](https://www.youtube.com/watch?v=Jhe-BXdQHl8) by [Mark Ferlatte](https://twitter.com/ferlatte) about getting the Healthcare.gov up and running back when it was struggling to serve its users. It's a great talk that gets its point across quickly (<5 minutes!) but to summarize, you can't do everything first, you have to have to prioritize. That's not a new concept, if you've even been in a sprint planning session where tech debt is competing with new features, you know how difficult it can be to argue about which should be the priority. The part of this talk that I want to focus on is how it frames the conversation, it presents those needs as a hierarchy.

The classic challenge with priority conversations is that each piece of work is a _need_ from a certain perspective. The site _needs_ accessibility updates for legal and the site _needs_ to be more performant for digging deeper into the mobile consumer segment and the site _needs_ these new features to support the upcoming marketing campaign but it also _needs_ the new button styles to keep up with the new branding initiative. All these requests truly are needs.They have substantial value and there are real consequences if they aren't met.

This conversation boils down to what might not get done, what's less important. That's not directly stated of course but when your initiative lands at the bottom of the list or even the middle of the list, it can be painful. People get invested in their work and this moment can feel like others don't value what we do. If you went ahead and watched the video you probably see where this is going. If we take Mr. Ferlatte's approach and frame this as a hierarchy rather than a sequence, the needs become interconnected. We _can't_ work on the new button styles until the site is accessible because it is foundational, it _supports_ the new buttons. We can become jointly invested in that work because its supportive rather than in the way.

I believe there is an important rule to add to this system. Work should be given priority by its height in the hierarchy. It seems implicit but I think it's worth calling out. Work should not eternally focus on the foundational levels but should strive to reach the highest heights. This is important not just to ensure there's a good spread of work but psychologically it makes all pieces of the pyramid important. The foundation is _needed_ to support the upper levels, the top and middle are explicitly the goal and therefore clearly _needed_. Making all the concerns feel needed is an important step to making all the team members feel valued.

There are challenges with this method still, it's not all sunshine and roses. The breadth of work that needs completed for the foundation to be "ready" is up to debate, it is not something easily measured. The priority in the hierarchy becomes more contentious than the priority of the tasks because it becomes the framework for future decision-making. While these are challenges, I want to call attention to how these problems look paired with the benefits offered and provide a method for managing them as well.

Without the hierarchy, we are forced to have the same conversations over and over. "Should we build this new type of page first or work on site performance" transforms into "Are we ready to expand site flexibility or do we need further stability?" It becomes more removed and thus easier to argue and come to agreement.

The priority in the hierarchy is essentially front-loading the conversation. Good and bad with that, you're putting a question to bed for good but it can be painful. To make that hierarchy a bit less contentious, try delineating the concerns in cross-cutting ways. Instead of "security" which will be be of little interest outside the technical circles, consider "stability" which highlights the impact to business. This will avoid creating a hierarchy of departments instead of needs.

Much credit is due to Mr. Ferlatte for his fantastic talk and for presenting the wonderful core of this idea. I believe that this expansion approach provides value and when correctly managed can make priority conversations much easier.



Imagine that you get a new job as a messenger for your local neighborhood. Every day you get a list messages to share from Charlie the news man. He's a nice guy but boy does he have a lot of messages for you to share. From 8 am to 4 pm every day you go door to door in the neighborhood to inform people of an incoming storm or a sale at the local butcher shop. People enjoy them... for the most part.

## Polling

```javascript
// Don't worry how he gets his messages,
// we'll focus on delivery for now
const charlie = {
  getMessages: () => [
    `Kite flying contest tomorrow at noon`,
    `The butcher has a sale on steaks!`,
  ],
};

class Messenger {
  _messages = [];
  getMessages() {
    return this._messages;
  }
  addMessages(newMessages) {
    this._messages = [...this._messages, ...newMessages];
  }
  emptyMessages() {
    this._messages = [];
  }
}

// Welcome to your new job!
const you = new Messenger();

// Called at 8 am
function start() {
  you.addMessages(charlie.getMessages());
}

// Called for each delivery
function deliverMessages() {
  neighborhood.forEach((resident) => {
    resident.giveMessage(you.getMessages());
  });
}

// Called at 4 pm
function end() {
  you.emptyMessages();
}
```

There's some problems though. When you told Sal about the fun at the butcher shop he was less than interested. _He's a vegetarian._ Also, Stanley is very sour on the whole kite thing and he does not want to talk about it. It was alright for a first day but you wonder if there's room for improvement so you sit down and think about the problems you've seen:

You decide to visit your boss's office after work to make some suggestions.

## Pub Sub

You've figured out that many people in your neighborhood only care about certain kinds of messages. Rather than giving them every message you can ask which topics they're interested in and give only messages under those topics. You pitch the following proposal:

```javascript
const messageTypes = {
  EVENT: "event",
  SALE: "sale",
};

// We ask Charlie to mark up the envelopes
// with the message type
const charlie = {
  getMessages: () => [
    {
      type: messageTypes.EVENT,
      body: `Kite flying contest tomorrow at noon.`,
    },
    {
      type: messageTypes.SALE,
      body: `Info: The butcher has a sale on steaks!`,
    },
  ],
};

class Messenger {
  // Only give the messages matching the given type
  getMessages(type) {
    return this._messages.filter((m) => m.type === type);
  }
}

// Our recipients now tell us what kinds
// of messages they would like
function deliverMessages(types) {
  return types.flatMap((type) => you.getMessages(type));
}
```

You boss is intrigued but has some feedback for you. She points out that you're adding some cost to the department as now you and Charlie need to coordinate about what kinds of messages there are. She also notes that residents have offloaded the filtering to you so now you're slowing down and wonders if you'll be able to move as fast. She says that you're introducing complexity without a meaningful optimization.

What a weird thing to say.

You have an idea though. What if residents submitted subscriptions to you so that you only visit houses that you have messages for?

You make the following amendments:

```javascript
class SubscriptionBox {
  _subscriptions = [];
  _messageTypes = {
    WEATHER: "weather",
    SALE: "sale",
  };

  // Residents come at any time and subscribe to topics they would like
  // These come into effect the following day
  subscribe(resident, messageType) {
    this._subscriptions.push({ residence, messageType });
  }

  unsubscribe(resident, messageType) {
    this._subscriptions.splice(
      this._subscriptions.findIndex((sub) => sub === { resident, messageType }),
      1
    );
  }

  getSubscribedTypes(resident) {
    return this._subscriptions.filter((sub) => sub.resident === resident);
  }

  getSubscriptionsByResident() {
    return this._subscriptions.reduce((acc, cur) => {
      const subs = acc[cur.resident] || [];
      subs.push(cur.messageType);
      acc[cur.resident] = curArray;
      return acc;
    }, {});
  }
}

class Messenger {
  todaysRoute = {};
}

// A lovely addition to your town!
const coolBox = new SubscriptionBox();

function start() {
  you.todaysRoute = getSubscriptionsByResident();
}

function deliverMessages() {
  neighborhood
    .filter(you.todaysRoute.hasOwnProperty) // We'll skip any residents that don't have mail!
    .forEach((resident) => {
      resident.giveMessage(you.getMessages());
    });
}
```

It's a wonderful success! People are getting their mail earlier because you're moving faster and they have less junk mail to go through. Everyone is happy except Charlie who now has to categorize all the messages. He's grumbles something about how you could figure out who to deliver to based on content instead of making him mark all the topics himself but that's for another day.



_Alas, many of these do indeed now live in Chrome. My personal favorite, the JSON viewer, seems to be a long-standing holdout for reasons I can't quite figure. My comments regarding source mapping have sadly aged just fine however. I imagine it will get fixed in due time of course._

_Regardless of the many changes over the year, I would still encourage you to discover if Firefox is a better fit for your development. It has been my on-going experience that all the coolest devtools innovations besides the nitty-gritty of js debugging happen over on the fox side._

Whenever one of the browsers has a really good feature it's not too long until the rest co-opt it and we're all the better for it. There's a number of new(ish) features in Firefox that I've taken a strong liking to and I won't be surprised if they make their way over to Chrome one of these days.

I won't lie, I think that JS debugging is much easier in Chrome. When I'm working with TypeScript I find Chrome's source mapping works better, more reliably and faster. When I have to navigate the source directory to add a breakpoint to some file, Chrome does a better job of constructing a sensible structure. But these things that Chrome excels in like performance profiling, inspecting network traffic and JS debugging aren't what I find myself doing all day. When you work inside frameworks, performance is a question of correct structure and optimizing how data is shared. And network traffic is a very small portion of the broader scope of what the frontend needs to do.

I still use Firefox because it beats Chrome in all the things I need to regularly. That may sound silly as it seems all of front-end development today is about JS but we have layers on layers of tools for that already. The JS tooling is sufficient, what can pose a challenge is the lack of tooling for everything else. That's where Firefox really shines.

## Accessibility Inspector

![Accessibility panel](./images/accessibility-inspector.png)_Accessibility tree inspector, a companion to the page inspector_

The accessibility panel was fully un-veiled about this time last year. It's matured quite a bit since then, especially in performance. It used to get bogged down very easily but it's become quite usable. I used to run it all the time to check what kinds of issues I might be able to fix but I quickly found that it just wasn't hard to head them off! Using native solutions often provides accessibility for free. Now, I mostly check in on this panel when I need to make sure that sub-optimal workarounds like extra wrapping html or pseudo-elements aren't costing us.

## JSON Viewer

One of my favorite little Firefox "bonuses" is the JSON viewer found when accessing a JSON API. It's not much more than a prettified syntax highlighted version but I find that's plenty! When I'm looking for a specific property there's the search at the top and a convenient "copy" button for when I want to use my favorite JSON to TS interface [VS Code extension](https://github.com/MariusAlch/vscode-json-to-ts).

![JSON from an API shown through a viewing tool](./images/JSON-viewer.png)_Accessing a JSON API directly makes it easy to identify its struture_
(Note, the JSON viewer is only enabled by default on Developer Edition)

## Flexbox and Grid Inspection

When you're confused layout there's nothing like a visual to get you out of that hole. I _love_ the flexbox inspector. It does a fantastic job of explaining how an element ending up getting the size it did. Here's where it started, here's how much extra space it was given, here's where it ended up. Click the flex button in the html inspector and you'll see the flex children in the page highlighted.

![Flexbox inspector button](./images/flex-html-button.png)_Button to trigger the flex inspector_

Click one of the children and look at their layout panel to find how the browser is divvying up that space. So many times I've gone here to slap my head, say "DOH" and go back to apply that `flex-grow` property.

![Flexbox layout panel](./images/flex-layout-panel.png)_Flexbox calculations that lead to the final size_

## Syntax highlighting

Not quite a feature like the rest but I appreciate the HTML highlighting in Firefox. I find that it does a better job of differentiating between the different kinds of information. Overall it's just easier to read and scan. Definitely a matter of personal taste though.

![Chrome inspector](./images/chrome-inspector.png)_Chrome inspector_

Notice how attributes, their values and text nodes have almost the same color in Chrome but very different ones in Firefox.

![Firefox inspector](./images/firefox-inspector.png)_Firefox inspector_

## Finding DOM Event Listeners

Last but not least, I find myself stepping through the event handlers on my UI from time to time and the easier way is definitely through the DOM event buttons. You can view a snippet of the handler or even click through to the file itself.

![An event listener in the HTML panel of the page inspector](./images/DOM-events.png)_A click event handler shown in the HTML panel_



_Note - If you're in Angular reactive or template forms are a much better option. This is just an exploration of typescript._

It can be quite tempting to modify a class or interface when implementing new features. I first noticed this habit when I was mapping some objects that I found to have a lot extraneous data. I went looking to see if I could pare it down at all, maybe making my life a little easier. Nearly every property on this object was deeply nested and looked unrelated to the rest. There was no pivotal moment though that made this object bloated, I could see they were added one at a time by different authors. It made sense, each developer felt it was not the time to refactor and _surely_ someone after them would.

I wondered how this could be prevented, I knew there was some logic to the construction. Some data related to different view states while others got transformed completely away into other values. I attempted an experiment to factor away the portions that related to the view. I found some time later that I had inadvertently recreated parts of Angular's forms library. I wasn't intent on using it, why bother instead of using a more robust and better tested library. However, I was interested in what came out of it so I wanted to share.

So, here's an angular service that creates view-model objects for building forms out of more abstract model objects. It provides some utilities for using the form objects, very strong typing and transformational function to switch between the given object's type and its corresponding form object.

```typescript
import { Injectable } from "@angular/core";

@Injectable({ providedIn: "root" })
export class FormService {
  createForm<T>(
    initialValues: T,
    validators?: { [P in keyof T]: Validator<T[P]>[] }
  ): Form<T> {
    return Array.from(Object.entries(initialValues)).reduce(
      (acc, [key, val]) => {
        acc[key] = {
          value: val,
          touched: false,
          valid: false,
          validate: !!validators ? validators[key] || [] : [],
        };
        return acc;
      },
      <Form<T>>{}
    );
  }

  validateForm<T>(form: Form<T>): ValidationReport<T> {
    const report: ValidationReport<T> = [];
    for (const key in form) {
      if (form.hasOwnProperty(key)) {
        report.push({
          key,
          valid: this.validateField(form[key]),
        });
      }
    }
    return report;
  }

  validateField<T>(field: Field<T>): boolean {
    return field.validation.every((v) => v(field.value));
  }

  extractData<T>(form: Form<T>): T {
    return Array.from(Object.entries(form)).reduce((acc, [key, val]) => {
      acc[key] = val;
      return acc;
    }, <T>{});
  }
}

// This is the magic. For each key [Property in base type], there's a Field of the type of the property in the base type.
// T[P] accesses the type of P rather that using just P which would give its key instead
export type Form<T> = {
  [P in keyof T]: Field<T[P]>;
};

export interface Field<T> {
  valid: boolean;
  value: FieldValue;
  touched: boolean;
  validation: Validator<T>[];
}

export type ValidationReport<T> = {
  key: keyof T;
  valid: boolean;
}[];

export type FieldValue = string | number;
export type Validator<T> = (value: T) => boolean;
```

Notice that while these generics make all this logic reusable, they also encourage passing around a smaller object and only creating this Form extended object when it's actually needed. To implement a system like this you really have to get out ahead of the idea though. I think it would be challenging to lay this kind of groundwork unless you're creating one of the first-of-its-kind properties. You really have to keep your head on a swivel to create something like this that's actually usedul, after all I never got to use it!

Just for the sake of completeness, he's what using that functionality would look like.

```typescript
example() {
  const form = this.formService.createForm<Test>({
    something: 'Test',
    someOtherThing: 12
  }, {
    something: [v => !!v, v => v.length > 0],
    someOtherThing: [v => v > 10]
  });


  const readyToContinue = this.formService.validateForm(form).valid;
}

interface Test {
  something: string;
  someOtherThing: number;
}
```
