Tags: javascript

1036

sparkline

Wednesday, April 27th, 2022

Trust

I’ve noticed a strange mindset amongst front-end/full-stack developers. At least it seems strange to me. But maybe I’m the one with the strange mindset and everyone else knows something I don’t.

It’s to do with trust and suspicion.

I’ve made no secret of the fact that I’m suspicious of third-party code and dependencies in general. Every dependency you add to a project is one more potential single point of failure. You have to trust that the strangers who wrote that code knew what they were doing. I’m still somewhat flabbergasted that developers regularly add dependencies—via npm or yarn or whatever—that then pull in even more dependencies, all while assuming good faith and competence on the part of every person involved.

It’s a touching expression of faith in your fellow humans, but I’m not keen on the idea of faith-based development.

I’m much more trusting of native browser features—HTML elements, CSS features, and JavaScript APIs. They’re not always perfect, but a lot of thought goes into their development. By the time they land in browsers, a whole lot of smart people have kicked the tyres and considered many different angles. As a bonus, I don’t need to install them. Even better, end users don’t need to install them.

And yet, the mindset I’ve noticed is that many developers are suspicious of browser features but trusting of third-party libraries.

When I write and talk about using service workers, I often come across scepticism from developers about writing the service worker code. “Is there a library I can use?” they ask. “Well, yes” I reply, “but then you’ve got to understand the library, and the time it takes you to do that could be spent understanding the native code.” So even though a library might not offer any new functionality—just a different idion—many developers are more likely to trust the third-party library than they are to trust the underlying code that the third-party library is abstracting!

Developers are more likely to trust, say, Bootstrap than they are to trust CSS grid or custom properties. Developers are more likely to trust React than they are to trust web components.

On the one hand, I get it. Bootstrap and React are very popular. That popularity speaks volumes. If lots of people use a technology, it must be a safe bet, right?

But if we’re talking about popularity, every single browser today ships with support for features like grid, custom properties, service workers and web components. No third-party framework can even come close to that install base.

And the fact that these technologies have shipped in stable browsers means they’re vetted. They’ve been through a rigourous testing phase. They’ve effectively got a seal of approval from each individual browser maker. To me, that seems like a much bigger signal of trustworthiness than the popularity of a third-party library or framework.

So I’m kind of confused by this prevalent mindset of trusting third-party code more than built-in browser features.

Is it because of the job market? When recruiters are looking for developers, their laundry list is usually third-party technologies: React, Vue, Bootstrap, etc. It’s rare to find a job ad that lists native browser technologies: flexbox, grid, service workers, web components.

I would love it if someone could explain why they avoid native browser features but use third-party code.

Until then, I shall remain perplexed.

Wednesday, April 20th, 2022

Tuesday, April 12th, 2022

CSS Quick Tip: Animating in a newly added element | Stephanie Eckles

I can see myself almost certainly needing to use this clever technique at some point so I’m going to squirrel it away now for future me.

Wednesday, March 30th, 2022

Make Beautifully Resilient Apps With Progressive Enhancement

You had me at “beautifully resilient apps with progressive enhancement”.

This is a great clear walkthrough of enhancing a form submission. A lot of this seems like first principles to me, but if you’ve only ever built single page apps, then thinking about a server-submission process first might well be revelatory.

Sunday, March 13th, 2022

Make it boring — jlwagner.net

People are propelled by their interests, and web developers have a lot of space to be interested in all sorts of stuff. For you, it may be JavaScript ‘n Friends, or HTML and CSS. Maybe it’s all that stuff, but put aside your preferences for a moment and answer me this: what are you helping people to do? If the answer involves any remotely routine or crucial purpose, consider putting aside your personal desire for excitement. Instead, make boring things that are usable, accessible, and fast. Ours is a job done by people for people, not a glamorous rockstar gig.

Excellent advice from Jeremy who wants us to build fast, reliable, resilient websites …even if the technologies involved in doing that don’t feel exciting.

Central to that endeavor is recognizing that the browser gives you a ton of stuff for free. Relying on those freebies requires a willingness to not npm install a solution for every problem — especially those that are best solved with CSS and HTML. Those technologies may seem boring, but boring is fast. Boring is usable. Boring is resilient and fault tolerant. Boring is accessible. When we rely wholesale on JavaScript to build for the web, we’re inevitably reinventing things. At worst, our reinventions of rock-solid HTML features — such as client-side form validation  — break in unexpected ways despite our carefully written tests. At best, a flawless reimplementation of those features adds unnecessary code to applications, and depends on a technology less fault-tolerant than CSS and HTML.

Wednesday, March 9th, 2022

When should there be a declarative version of a JavaScript API?

I feel like it’s high time I revived some interest in my proposal for button type="share". Last I left it, I was gathering use cases and they seem to suggest that the most common use case for the Web Share API is sharing the URL of the current page.

If you want to catch up on the history of this proposal, here’s what I’ve previously written:

Remember, my proposal isn’t to replace the JavaScript API, it’s to complement it with a declarative option. The declarative option doesn’t need to be as fully featured as the JavaScript API, but it should be able to cover the majority use case. I think this should hold true of most APIs.

A good example is the Constraint Validation API. For the most common use cases, the required attribute and input types like “email”, “url”, and “number” have you covered. If you need more power, reach for the JavaScript API.

A bad example is the Geolocation API. The most common use case is getting the user’s current location. But there’s no input type="geolocation" (or button type="geolocation"). Your only choice is to use JavaScript. It feels heavy-handed.

I recently got an email from Taylor Hunt who has come up with a good litmus test for JavaScript APIs that should have a complementary declarative option:

I’ve been thinking about how a lot of recently-proposed APIs end up having to deal with what Chrome devrel’s been calling the “user gesture/activation budget”, and wondering if that’s a good indicator of when something should have been HTML in the first place.

I think he’s onto something here!

Think about any API that requires a user gesture. Often the documentation or demo literally shows you how to generate a button in JavaScript in order to add an event handler to it in order to use the API. Surely that’s an indication that a new button type could be minted?

The Web Share API is a classic example. You can’t invoke the API after an event like the page loading. You have to invoke the API after a user-initiated event like, oh, I don’t know …clicking on a button!

The Fullscreen API has the same restriction. You can’t make the browser go fullscreen unless you’re responding to user gesture, like a click. So why not have button type="fullscreen" in HTML to encapsulate that? And again, the fallback in non-supporting browsers is predictable—it behaves like a regular button—so this is trivial to polyfill. I should probably whip up a polyfill to demonstrate this.

I can’t find a list of all the JavaScript APIs that require a user gesture, but I know there’s more that I’m just not thinking of. I’d love to see if they’d all fit this pattern of being candidates for a new button type value.

The only potential flaw in this thinking is that some APIs that require a user gesture might also require a secure context (either being served over HTTPS or localhost). But as far as I know, HTML has never had the concept of features being restricted by context. An element is either supported or it isn’t.

That said, there is some prior art here. If you use input type="password" in a non-secure context—like a page being served over HTTP—the browser updates the interface to provide scary warnings. Perhaps browsers could do something similar for any new button types that complement secure-context JavaScript APIs.

Monday, March 7th, 2022

web-platform-tests dashboard

It’s great to see browsers working together to collectively implement a range of much-needed features.

These scores represent how browser engines are doing in 15 focus areas and 3 joint investigation efforts.

Saturday, March 5th, 2022

Progressive Enhancement, the New Hotness™ | Go Make Things

Here’s a great explanation of progressive enhancement, complete with practical examples and myth-busting. Pass it ‘round!

If you care about quality engineering, you want as much fault tolerance in the things you build as possible.

Thursday, February 24th, 2022

How to make MPAs that are as fast as SPAs | Go Make Things

The headline is a little misleading because if you follow this advice, your multi-page apps will be much much faster than single page apps, especially when you include that initial page load of a single page app.

Here’s a quick high-level summary of what I do…

  1. Serve pre-rendered, mostly static HTML.
  2. Inline everything, including CSS and JavaScript.
  3. Use mostly platform-native JavaScript, and as little of it as possible.
  4. Minify and gzip all the things.
  5. Lean heavily on service workers.

That’s an excellent recipe for success right there!

Tuesday, February 22nd, 2022

SPAs were a mistake | Go Make Things

Browsers give you a ton of stuff for free, built right in, out-of-the-box. SPAs break all that, and force you to recreate it yourself with JavaScript. Most developers do it wrong, and for the ones who do it right, it results in a ton of extra code to recreate features the browser already gave you for free.

Tuesday, February 15th, 2022

Canned web development — Jeremy Wagner

Our mental model for how we build for the web is too reliant on canned solutions to unique problems.

This is very perceptive indeed.

Compounding this problem is that too few boot camps are preparing new web developers to think critically about what problems are best solved by JavaScript and which aren’t — and that those problems that are best solved by JavaScript can be solved without engaging in frivolous framework whataboutism. The question developers should ask more often when grappling with framework shortcomings shouldn’t be “what about that other framework?”, but rather “what’s best for the user experience?”.

Wednesday, February 2nd, 2022

“Evergreen” Does Not Mean Immediately Available | CSS-Tricks - CSS-Tricks

Smart advice on future-proofing and backward-compatibility:

There isn’t a single, specific device, browser, and person we cater to when creating a web experience. Websites and web apps need to adapt to a near-infinite combination of these circumstances to be effective. This adaptability is a large part of what makes the web such a successful medium.

Consider doing the hard work to make it easy and never remove feature queries and @supports statements. This creates a robust approach that can gracefully adapt to the past, as well as the future.

Monday, January 31st, 2022

The baseline for web development in 2022

A thoroughly researched look at what our baseline criteria should be for making websites today:

The baseline for web development in 2022 is:

  • low-spec Android devices in terms of performance,
  • Safari from two years before in terms of Web Standards,
  • and 4G in terms of networks.

The web in general is not answering those needs properly, especially in terms of performance where factors such as an over-dependence on JavaScript are hindering our sites’ performance.

It’s somewhat damning to Safari to see it as a baseline browser, but with Internet Explorer out of the picture, something has to be the lowest common denominator. In this case, Safari is quite literally the new IE.

The Web in 2036: Predictions on a Whim - Jim Nielsen’s Blog

Prompted by the rhetorical question at the end of my post Today, the distant future, Jim casts his gaze into a crystal ball. I like what he sees.

It’s possible the behemoth that is JavaScript in 2022 continues to metastasize as we move towards 2036, especially with technologies like WASM. I wouldn’t rule out the lordship of JavaScript as a possibility of the future.

However, I also think it’s possible—and dare I predict—to say we are peaking in our divergence and are now facing a convergence back towards building with the grain of the web and its native primitives.

Why do I say that? In our quest for progress, we explored so far beyond the standards-based platform that we came to appreciate the modesty of the approach “use the platform”.

He also makes one prediction that lies within his control:

This blog post will still be accessible via its originally published URL in 2036.

Saturday, January 8th, 2022

Ban embed codes

Prompted by my article on third-party code, here’s a recommendation to ditch any embeds on your website.

Monday, January 3rd, 2022

Start at the beginning: the importance of learning the basics - localghost

I’d recommend going in the order HTML, CSS, JS. That way, you can build something in HTML, add CSS to it as you learn it, and finally soup it up with your new-found JS knowledge.

Excellent advice for anyone new to web develoment.

Once you start getting into interactive website territory, with API calls and fancy stuff, that’s where you need JavaScript (JS) knowledge. More specifically, vanilla JS: plain JS with no additional frameworks or plugins. The JS that your browser understands without having to do any pre-processing. It makes working with frameworks a whole lot easier, and it’ll help you to know when not to use a framework (and avoid making users download massive JS bundles when all you need is a tiny bit of code).

Thursday, December 30th, 2021

Add Less | CSS-Tricks - CSS-Tricks

Let the power of the browser work for you, and use less stuff!

Amen!

Your websites start fast until you add too much to make them slow. Do you need any framework at all? Could you do what you want natively in the browser?

Wednesday, December 29th, 2021

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!

Wednesday, December 15th, 2021

Monday, December 13th, 2021

Embrace the Platform - CSS-Tricks

This is a wonderful piece by Bram. Half history lesson, and half practical advice for building resilient websites today:

By embracing what the web platform gives us — instead of trying to fight against it — we can build better websites.

Keep it simple. Apply the Rule of Least Power. Build with progressive enhancement in mind.

HTML, CSS, and JavaScript — in that order.