Chris’ Corner: Considering Code

By admin
I enjoyed

Stefan Baumgartner
PERSON

’s

5
CARDINAL

Inconvenient Truths about TypeScript. I like some philosophical hard-truths from someone who is clearly pretty close to the technology. It doesn’t “fix JavaScript”, it’s complicated, and ironically, it’s not truly type-safe. Every team is going to have to do their own math on whether they find it worth it or not, and clearly a lot of teams choose the way of

TypeScript
ORG

. Despite the complexities and limitations, they find it worth it. Among other things, it’s likely you’re writing code that saves you from your own stupid mistakes, and you almost certainly get an enhanced code editor experience.

At CodePen we’ve decided to go for

TypeScript
ORG

, but it’s not an all-in proposition. We’re

maybe 50%
PERCENT

converted if I’m being generous, and rarely do we refactor JavaScript into

TypeScript
ORG

just for the sake of it. I like that not only can you turn up the dial on how much of

TypeScript
ORG

you want to use even within

TypeScript
ORG

itself, but you don’t have to use it at all even within the same code base.

Clearly

Stefan
PERSON

is a fan. And I’ve heard from so many others that there is some metaphorical hump you get over where you strongly prefer it.

And you know what, then it becomes fun! TypeScript is here to make your life and the life of your team easier. And it succeeds! Try going back to a project after

6 months
DATE

of time and try to recreate the mental model you had from your application. Or look at well-crafted types that tell you a story. I’d always go for

TypeScript
ORG

.

I’ll tell ya: I’m not there yet. I don’t disagree it’s a net gain for us, but I don’t actually like it.

Do you know what this is?

In case of conflict, consider users over authors over implementors over specifiers over theoretical purity.

(It goes on a bit to elaborate.) It’s called “

The Priority of Consituencies
WORK_OF_ART

” and it’s not some random dude’s philophy, it’s part of the HTML specs. Most people have never heard of it, well, at least from a tiny survey

Megan Notarte
PERSON

did. She also thinks it could use a rewrite, because it’s a little, uhhh, speccy-sounding? Her cleaner take:

When you aren’t sure what to do, always prioritize end users

first
ORDINAL

. Once the user’s needs are met, consider the authors next. When the author’s needs are met, you can consider developer needs.

Only after all those are considered should you worry about specification writers. Never prioritize theoretical purity unless all the other needs are met.

It’s always best to improve things for everyone if possible. I might be putting a little bit more oomph behind the original words, but I think it’s warranted.

I like it.

And it really can help guide decisions. It can help you not do things. Like if you think you should use some particular element or use some special aria attribute, but it’s not doing what you hope, for users, you shouldn’t do it. That’s prioritizing theoretical purity over users which is about as far away in priority as you can get. Or the other way around, like using some code that isn’t specced or doesn’t validate, but it helps users, well, users win. As long as, you know, it actually does help users, and doesn’t harm other users.

I’m curious what’s going on with

Google
ORG

’s baseline thing. I think the big idea was that it’s a pretty small widget that goes at the top of writing about specific bits of web tech, so readers get an idea of support really quickly.

I just don’t see it all that often. Not negative criticism really — this is a pretty ambitious thing and rollouts take time. It would just be good to know if it’s still the plan and who’s all on board. If it was a Web Component I’d probably use it when relevant.

Browser support, while leaps and bounds better

today
DATE

than it was

a decade ago
DATE

, is still a concern. Especially since new features are a never-ending train on the web. As Mat​hia⁠s S​chäf⁠er put it recently:

For web authors, this is

daily
DATE

business. A large part of a web author’s work is dealing with browser compatibility and website interoperability. The situation improved thanks to evergreen browsers. But fundamentally, this is the essence of authoring for the web. On browser compatibility and support baselines

Mat​hia⁠s does offer some pointed criticism of

Google
ORG

’s baseline as well. It might be a little too simplified when it comes to making an actual decision to use a technology or not.

My fear is that

Google
ORG

’s

Baseline
ORG

initiative oversimplifies the discourse on browser support. Web authors will see “widely supported”, all-green checkmarks and alleged

100%
PERCENT

browser support and use the feature without further examination.

Whether or not a feature can be polyfilled, for example, is a pretty important distinction.

I’ll always remember

David Khourshid
PERSON

once saying that he doesn’t call it “legacy” code he calls it “legendary” code. A bit tongue in cheek, but a real sentiment that that code has been out there in production doing work, probably for a long time, so should be treated with dignity rather than disgust.

We’re often lucky if our code stays around at all. Websites have a bad habit of just going away. Perhaps we can learn from that: all code is temporary, treat it that way. But it’s also kind of

a bummer
DATE

.


Robb Owen
PERSON

has a story about his dad’s career as an electrical engineer who works on lasers.

After dad passed away, I stumbled across a box in my parent’s garage containing prototypes and product specimens for many of the laser modules that he’d built throughout his career. That box now serves as a tangible legacy of a long and varied career. Flash forward to

a few months ago
DATE

when I was chatting with a potential client. They asked me to show some of my past work, so I duly shared my screen and hopped over to the URL of a humanitarian campaign site that I was particularly proud of having worked on…

Can you guess what? Just an error page. The site is gone, wiped from the internet. Little different than the lasers eh? Thank heavens for

the Wayback Machine
ORG

.


Twenty
CARDINAL

points awarded to the

Fictive Kin
ORG

team for the naming in their handbook. It’s kind of a like a marketing website showcasing how they work and how they think and how that can translate into success for clients. I appreciate that kind of clarity. I can imagine it’s hard to know what you’re getting into when hiring an agency just by looking at some portfolio stuff.

But yeah those names. The handbook is title Your Website Owes You Money which is great and the start it with some hard truths in a letter titled I Say This With

Love
WORK_OF_ART

. They are proving they are good copywriters without having to tell you they are good copywriters, which is really just a bonus.

I’ll pick

one
CARDINAL

favorite quote: