Snippets

These snippets are my attempt to save and organize various bits of code, best practices, and resources relating to web development and design. They also function as a to do list of sorts, for things I want to implement in my own code, but haven't yet. The concept is inspired by Jeremy Keith's links and CSS-Tricks, among other things. Enjoy.

Stimulus: A modest JavaScript framework for the HTML you already have

Stimulus is a JavaScript framework with modest ambitions. It doesn’t seek to take over your entire front-end—in fact, it’s not concerned with rendering HTML at all. Instead, it’s designed to augment your HTML with just enough behavior to make it shine. Stimulus pairs beautifully with Turbolinks to provide a complete solution for fast, compelling applications with a minimal amount of effort.

[…]

Sprinkle your HTML with controller, target, and action attributes:

HTML

<!--HTML from anywhere-->
<div data-controller="hello">
  <input data-target="hello.name" type="text">
 
  <button data-action="click->hello#greet">
    Greet
  </button>
 
  <span data-target="hello.output">
  </span>
</div>

Write a compatible controller and watch Stimulus bring it to life:

JavaScript

// hello_controller.js
import { Controller } from "stimulus"
 
export default class extends Controller {
  static targets = [ "name", "output" ]
 
  greet() {
    this.outputTarget.textContent =
      `Hello, ${this.nameTarget.value}!`
  }
}
Source link
https://stimulusjs.org/
Tags
JavaScript - Libraries
Progressive enhancement
Resiliency

Turbolinks

Turbolinks® makes navigating your web application faster. Get the performance benefits of a single-page application without the added complexity of a client-side JavaScript framework. Use HTML to render your views on the server side and link to pages as usual. When you follow a link, Turbolinks automatically fetches the page, swaps in its <body>, and merges its <head>, all without incurring the cost of a full page load.

  • Optimizes navigation automatically. No need to annotate links or specify which parts of the page should change.
  • No server-side cooperation necessary. Respond with full HTML pages, not partial page fragments or JSON.
  • Respects the web. The Back and Reload buttons work just as you’d expect. Search engine-friendly by design.
  • Supports mobile apps. Adapters for iOS and Android let you build hybrid applications using native navigation controls.
Source link
https://github.com/turbolinks/turbolinks
Tags
JavaScript - Libraries
Progressive enhancement
Ajax

Spoiler: server-rendered HTML can work offline

The architecture astronauts who, for the past decade, have been selling us on the necessity of React, Redux, and megabytes of JS, cannot comprehend the possibility of building an email app in 2020 with server-rendered HTML 😴

[…]

The effects are truly toxic. Last decade’s obsession with SPAs has poisoned the minds of even the brightest teachers in our industry.

Like, there’s no way this stuff can work offline, right?!

Briefly read up on how HEY is implemented. Is this a correct summary of the pros and cons of its [server]-centric approach?
– Pro: Works fast on older devices.
– Con: Can’t be used offline.

Source link
https://twitter.com/sstephenson/status/1274750706537369601
Tags
JavaScript
JavaScript - Libraries
Service Workers
Progressive enhancement
Single page apps
Resiliency

Hey now

Progressive enhancement is at the heart of everything I do on the web. It’s the bedrock of my speaking and writing too. Whether I’m writing about JavaScript, Ajax, HTML, or service workers, it’s always through the lens of progressive enhancement. Sometimes I explicitly bang the drum, like with Resilient Web Design. Other times I don’t mention it by name at all, and instead talk only about its benefits.

I sometimes get asked to name some examples of sites that still offer their core functionality even when JavaScript fails. I usually mention Amazon.com, although that has other issues. But quite often I find that a lot of the examples I might mention are dismissed as not being “web apps” (whatever that means).

The pushback I get usually takes the form of “Well, that approach is fine for websites, but it wouldn’t work something like Gmail.”

It’s always Gmail. Which is odd. Because if you really wanted to flummox me with a product or service that defies progressive enhancement, I’d have a hard time with something like, say, a game (although it would be pretty cool to build a text adventure that’s progressively enhanced into a first-person shooter). But an email client? That would work.

[…]

Can you build something that works just like Gmail without using any JavaScript? No. But that’s not what progressive enhancement is about. It’s about providing the core functionality (reading and writing emails) with the simplest possible technology (HTML) and then enhancing using more powerful technologies (like JavaScript).

Progressive enhancement isn’t about making a choice between using simpler more robust technologies or using more advanced features; it’s about using simpler more robust technologies and then using more advanced features. Have your cake and eat it.

Fortunately I no longer need to run this thought experiment to imagine what it would be like if something like Gmail were built with a progressive enhancement approach. That’s what HEY is.

Sam Stephenson describes the approach they took:

HEY’s UI is 100% HTML over the wire. We render plain-old HTML pages on the server and send them to your browser encoded as text/html. No JSON APIs, no GraphQL, no React—just form submissions and links.

If you think that sounds like the web of 25 years ago, you’re right! Except the HEY front-end stack progressively enhances the “classic web” to work like the “2020 web,” with all the fidelity you’d expect from a well-built SPA.

See? It’s not either resilient or modern—it’s resilient and modern. Have your cake and eat it.

And yet this supremely sensible approach is not considered “modern” web development:

The architecture astronauts who, for the past decade, have been selling us on the necessity of React, Redux, and megabytes of JS, cannot comprehend the possibility of building an email app in 2020 with server-rendered HTML.

[…]

Their focus is very much on people above technology. They’ve taken a human-centric approach to their product and a human-centric approach to web development …because ultimately, that’s what progressive enhancement is.

Source link
Adactio: Journal — Hey now
Tags
Resiliency
JavaScript
JavaScript - Libraries
Progressive enhancement
Single page apps
Best practices

Always bet on HTML

In September of 2019, Zach Leatherman tweeted

Which has a better First Meaningful Paint time?

  1. a raw 8.5MB HTML file with the full text of every single one of my 27,506 tweets
  2. a client rendered React site with exactly one tweet on it

(Spoiler: @____lighthouse reports 8.5MB of HTML wins by about 200ms)

Take a moment to wrap your head around that.

It’s perceivably faster to load 8.5 megabytes of HTML than it is to load a single tweet with a client-side React app.

[…]

Real companies can and do build apps with HTML first

The folks at Basecamp just released a new email product, Hey, that tries to address a lot of the stuff that people find frustrating about email.

Neither product is really my cup of tea, but what I find super interesting is how Hey is built.

It’s core is server-rendered HTML. Basecamp is a Ruby on Rails shop (their CTO created Rails). Almost every view in the app is created on a server.

Then, they sprinkle just a little vanilla JS on top to turn things up to 11.

Basecamp uses a project they open sourced called Turbolinks. This JavaScript plugin intercepts link clicks and progressively enhances a server-side app into a single-page app (or SPA) by fetching additional pages with Ajax and only replacing the stuff that needs updating.

By using this approach, if the JS fails or isn’t supported, the app still loads and works and gives people the full experience. It also means you don’t have to wait for the full JS package to load before you can start using the app.

You still get the benefits of faster page loading that SPAs sometimes give you, but you don’t have to maintain two code bases or do complicated server-to-client hand offs (“rehydration” as they call it in the React world).

Source link
Always bet on HTML | Go Make Things
Tags
JavaScript
JavaScript - Libraries
Resiliency
Progressive enhancement
Best practices
Single page apps

Hello subgrid!

We have had Grid Layout in browsers for two years. Long enough for us to start to find the edges, and discover things we really wish it could do. The biggest missing feature from Level 1 was subgrid, which has become the main feature for Level 2 of the specification. In this talk I’ll introduce subgrid, with use cases, example code and some thoughts on where we might see Grid going in the future.

[…]

Resources

The following resources were mentioned during the presentation or are useful additional information.

Slides and code examples can be found in the source link.

Source link
https://noti.st/rachelandrew/i6gUcF/hello-subgrid
Tags
CSS - Grid
CSS - Layout

Don't Get Clever with Login Forms

As time goes on I find myself increasingly annoyed with login forms. As password managers like 1Password (which is what I use) and Chrome’s password manager (which I also sorta use) become more popular, it’s important for websites to be aware of how users go about logging into their sites.

Let’s walk through some login patterns and why I think they’re not ideal. And then let’s look at some better ways of tackling login. TL;DR; create login forms that are simple, linkable, predictable, and play nicely with password managers.

[…]

I think this may have started with Slack, but I’m seeing other digital products like Notion (which I love by the way) send users a temporary password to their email in order to login. I can appreciate the cleverness of this pattern as it avoids the rigamarole of users having to remember yet another password and building out all the “Forgot password” flow stuff. But.

  • This pattern is incredibly tedious. 1. Enter email into login form. 2. Open new tab or switch programs. 3. Open your inbox. 4. Find message from service (if you don’t get distracted by other emails first). 5. Open message. 6. Copy gobbledygook password. 7. Go back to website. 8. Paste in gobbledygook password. 9. Submit login form. Holy shit.
  • This doesn’t work at all with password managers, which is incredibly annoying as I want to lean on password managers to, uh, manage my passwords. With the advent of design systems we talk a lot about consistency. But it’s not just about creating consistency within your own ecosystem, it’s about being consistent with the rest of the internet.

[…]

Shopify (another service I love) annoyingly splits its login across three separate screens. Again, I can appreciate the intention here: they’re not trying to overload a user with too much info at once. And while I agree with this pattern for certain contexts (like in an e-commerce flow you typically see billing information, shipping method and address, credit card info, etc chunked out into discrete steps), this is overkill for what’s essentially a three-field form.

  • Adds unnecessary steps to login – Again this is a three-field form, but now users have to slog through three screens to log in. This no doubt slows users down.
  • Doesn’t work with password managers – While they sort of work, password managers are only able to fill in the one field on the page.

Do

So what should web designers do instead? I think having a boring old predictable login form is just fine. Here’s Harvest:

A screenshot of the getharvest.com login form.

Simple, concise, predictable. Works with password managers. Good stuff. Here’s some considerations:

  • Have a dedicated page for login – Customer support people can direct people to a URL (domain.com/login) rather than having to spell out a bunch of instructions on where to find the login form on the page. Password managers can store that login page and with a click of a button open that page and pre-fill the form.
  • Expose all required fields – If you need to enter your last name in order to log in, expose that field!
  • Keep all fields on one page – login should be a swift process, not an unnecessary slog through multiple pages.
  • Don’t get fancy – There may be something to the whole magic link thing and other inventive login patterns, but I think it’s important to recognize how users are used to logging in across the internet. Lean into that boring, predictable settled science.
Source link
https://bradfrost.com/blog/post/dont-get-clever-with-login-forms/
Tags
UX
Passwords