Link tags: code

456

sparkline

Why I don’t miss React: a story about using the platform - Jack Franklin

This is a great case study of switching from a framework mindset to native browser technologies.

Though this is quite specific to Jack’s own situation, I do feel like there’s something in the air here. The native browser features are now powerful and stable enough to make the framework approach feel outdated.

And if you do want to use third-party dependencies, Jack makes a great case for choosing smaller single-responsibility helpers rather than monolithic frameworks.

Replacing lit-html would be an undertaking but much less so than replacing React: it’s used in our codebase purely for having our components (re)-render HTML. Replacing lit-html would still mean that we can keep our business logic, ultimately maintaining the value they provide to end-users. Lit-Html is one small Lego brick in our system, React (or Angular, or similar) is the entire box.

Trust • Robin Rendle

Robin adds a long-zoom perspective on my recent post:

I am extremely confident that pretty much any HTML I write today will render the same way in 50 years’ time. How confident am I that my CSS will work correctly? Mmmm…70%. Hand-written JavaScript? Way less, maybe 50%. A third-party service I install on a website or link to? 0% confident. Heck, I’m doubtful that any third-party service will survive until next year, let alone 50 years from now.

Trust and suspicion | Keenan Payne

Another thoughtful reponse to my recent post.

Reflections on native browser features and third-party library adoption.

An incoherent rant about design systems • Robin Rendle

No matter how fancy your Figma file is or how beautiful and lovingly well organized that Storybook documentation is; the front-end is always your source of truth. You can hate it as much as you like—all those weird buttons, variables, inaccessible form inputs—but that right there is your design system.

Some tough design system love from Robin.

Here’s my advice: take all that aspirational stuff out of your Figma design system file. Put it somewhere else. Your Figma docs should be a mirror of the front-end (because that’s really the source of truth).

Little Big Updates: dispatches from Quality Week

This is a wonderful piece of writing by Marcin, ostensibly about bug-fixing but really an almost existential examination of the nature of coding.

Bugs are, by definition, a look backward—at past behavior, at code that already exists, at the old work of engineers whom you’ve never met. It can feel more fun to write new code, chart new territories, add new functionality.

But the past can be fun, too. A good bug is a puzzle. A mystery. A whodunit. To solve a bug, sometimes you have to be a scientist: observe and measure, chart out the logic, follow the math. But then, two minutes later, you need to wear a hat of a very particular detective—take your flip notepad and interview different pieces of code to understand not what they claim they do, but what they actually do.

Add a Service Worker to Your Site | CSS-Tricks - CSS-Tricks

Damn, I wish I had thought of giving this answer to the prompt, “What is one thing people can do to make their website better?”

If you do nothing else, this will be a huge boost to your site in 2022.

Chris’s piece is a self-contained tutorial!

Inertia - CSS-Tricks

Here’s a thoughtful response from Chris to my post about Svelte, Astro, and React.

Making Colophon Cards – Baldur Bjarnason

I think Baldur is onto something here with his categorisation of software. There’s the software based on innovation, something truly novel:

Innovation’s the word. Pushing the boundaries. You know the phrases. Usually spouted by that dude at the party.

Then there’s the software based on itertion, making a better version of a proven tool:

We are now in a place where we have entire genres of software that have decades of history, are backed by stacks of new and old research, have dozens of successful, well-made exemplar apps, and a broad enough conceptual space to allow for new variations on the theme.

In short, we have genre software and we have avant-garde software, and I’ve always been more interested in genre fiction than literary fiction.

Aliendscapes - Alien Planet Generator

Generative landscapes made with 2K of vanilla JavaScript.

Click (or refresh) for a new one.

Why We Create Progressive Web Apps: A Conversation with Jeremy Keith

This is a really nice write-up by Sydney of the chat we had on her podcast.

Decoded: The When, Why, and Why Not of Progressive Web Apps

I really enjoyed talking to Sydney Lai about progressive web apps, resilient web design, and all my other hobby horses.

Alas, there’s no transcript and I can’t find a direct link to the RSS feed or the individual audio file on the podcast website so it’s not huffduffable.

Making Reasonable Use of Computer Resources

The paradox of performance:

This era of incredibly fast hardware is also the era of programs that take tens of seconds to start from an SSD or NVMe disk; of bloated web applications that take many seconds to show a simple list, even on a broadband connection; of programs that process data at a thousandth of the speed we should expect. Software is laggy and sluggish — and the situation shows little signs of improvement. Why is that?

Because we prioritise the developer experience over the user experience, that’s why:

Although our job is ostensibly to create programs that let users do stuff with their computers, we place a greater emphasis on the development process and dev-oriented concerns than on the final user product.

We would do well to heed Craig’s observations on Fast Software, the Best Software.

How To Build Resilient JavaScript UIs — Smashing Magazine

The opening paragraphs of this article should be a mantra recited by every web developer before they begin their working day:

Things on the web can break — the odds are stacked against us. Lots can go wrong: a network request fails, a third-party library breaks, a JavaScript feature is unsupported (assuming JavaScript is even available), a CDN goes down, a user behaves unexpectedly (they double-click a submit button), the list goes on.

Fortunately, we as engineers can avoid, or at least mitigate the impact of breakages in the web apps we build. This however requires a conscious effort and mindset shift towards thinking about unhappy scenarios just as much as happy ones.

I love, love, love the emphasis on reducing assumptions:

Taking a more defensive approach when writing code helps reduce programmer errors arising from making assumptions. Pessimism over optimism favours resilience.

Hell, yeah!

Accepting the fragility of the web is a necessary step towards building resilient systems. A more reliable user experience is synonymous with happy customers. Being equipped for the worst (proactive) is better than putting out fires (reactive) from a business, customer, and developer standpoint (less bugs!).

Hacks Are Fine / Matt Hogg FYI

If you employ a hack, don’t be so ashamed. Don’t be too proud, either. Above all, don’t be lazy—be certain and deliberate about why you’re using a hack.

I agree that hacks for prototyping are a-okay:

When it comes to prototypes, A/B tests, and confirming hypotheses about your product the best way to effectively deliver is actually by writing the fastest, shittiest code you can.

I’m not so sure about production code though.

CSS Hell - To Hell with bad CSS!

Collection of common CSS mistakes, and how to fix them.

I like the way this is organised: it’s like “code smells” for CSS. Some of them will probably be familiar, in which case, you can dive in and find out what’s going on.

trapped in the technologist factory

New technologies don’t have power; for that they’d need a community, documentation, and a thriving ecosystem of ancillary technology. What they have is potential, which resonates with the potential within the startup and the early adopter; perhaps they can all, over time, grow together.

This means startups don’t adopt new technologies despite their immaturity, they adopt them because of that immaturity. This drives a constant churn of novelty and obsolescence, which amplifies the importance of a technologist’s skillset, which drives startups to adopt new technologies.

This flywheel has been spinning for a long time, and won’t stop simply because I’ve pointed out that we’re conflating novelty with technological advancement. Hopefully we can slow it down, though, because I believe it’s causing real harm.

Reflecting on My Own Experience Using the Web to Get the Vaccine - Jim Nielsen’s Blog

I click the link. The page loads fast. I navigate the surprisingly sparse yet clear form inputs. And complete the whole thing in less than thirty seconds.

Oh, how I wish this experience weren’t remarkable!

Simple forms with clear labels. Little to no branding being shoved down my throat. No array of colors, big logos, or overly-customized UI components.

Web Browser Engineering

It’s heavy on computer science, but this is a fascinating endeavour. It’s a work-in-progress book that not only describes how browsers work, but invites you to code along too. At the end, you get a minimum viable web browser (and more knowledge than you ever wanted about how browsers work).

As a black box, the browser is either magical or frustrating (depending on whether it is working correctly or not!). But that also make a browser a pretty unusual piece of software, with unique challenges, interesting algorithms, and clever optimizations. Browsers are worth studying for the pure pleasure of it.

See how the sausage is made and make your own sausage!

This book explains, building a basic but complete web browser, from networking to JavaScript, in a thousand lines of Python.

Swipey image grids.

This is how you write up a technique! Cassie takes an SVG pattern she used on the Clearleft “services” page and explains it in step-by-step detail, complete with explanatory animated diagrams.