I enjoyed Stefan Baumgartner’s 5 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. 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, but it’s not an all-in proposition. We’re maybe 50% converted if I’m being generous, and rarely do we refactor JavaScript into TypeScript just for the sake of it. I like that not only can you turn up the dial on how much of TypeScript you want to use even within TypeScript itself, but you don’t have to use it at all even within the same code base.
Clearly Stefan 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 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.
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” 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 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. 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’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 than it was a decade ago, is still a concern. Especially since new features are a never-ending train on the web. As Mathias Schäfer put it recently:
For web authors, this is daily 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
Mathias does offer some pointed criticism of Google’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’s Baseline initiative oversimplifies the discourse on browser support. Web authors will see “widely supported”, all-green checkmarks and alleged 100% 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 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.
Robb Owen 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 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.
Twenty points awarded to the Fictive Kin 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. 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 favorite quote:
The Nav and Footer are two places where best practices rule the day and innovation should be limited.
A visitor doesn’t want to be impressed by your unique navigation design. They want to understand what your company does and they want to get to where they are trying to go.
The post Chris’ Corner: Considering Code appeared first on CodePen Blog.