JavaScript

Allow Ctrl- and Shift-clicking links in event handlers

I just recently updated a bunch of my click handlers to not act when the Ctrl or Shift keys are pressed during the click, so that links can be opened in new tabs or windows by the user if so wanted:

Code language: JavaScript

// Don't do anything and defer to the default action if a modifier key
// was pressed during the click (to open the link in a new tab, window,
// etc.) - note that this is a truthy check rather than a strict check
// for the existence of and boolean true value of the various event
// properties:
// * https://ambientimpact.com/web/snippets/conditional-statements-and-truthy-values-robust-client-side-javascript
// * https://developer.mozilla.org/en-US/docs/Web/API/MouseEvent/ctrlKey
// * https://developer.mozilla.org/en-US/docs/Web/API/MouseEvent/shiftKey
if (event.ctrlKey || event.shiftKey) {
	return;
}

Container-Adapting Tabs With "More" Button

Image

This looks like an excellent, accessible starting point for the priority navigation pattern:

Or the priority navigation pattern, or progressively collapsing navigation menu. We can name it in at least three ways.

There are multiple UX solutions for tabs and menus and each of them have their own advantages over another, you just need to pick the best for the case you are trying to solve. At design and development agency Kollegorna we were debating on the most appropriate UX technique for tabs for our client’s website…

We agreed it should be a one-liner because the amount of tab items is unknown and narrowed our options down to two: horizontal scroll and adaptive with “more” button. Firstly, the problem with the former one is that horizontal scroll as a feature is not always visually obvious for users (especially for narrow elements like tabs) whereas what else can be more obvious than a button (“more”), right? Secondly, scrolling horizontally using a mouse-controlled device isn’t a very comfortable thing to do, so we might need to make our UI more complex with additional arrow buttons. All considered, we ended up choosing the later option[.]

1% or 13 million JavaScript requests per month to BuzzFeed time out

Image

More evidence that we don’t fully control our web pages and that a non-zero number of page views don’t execute JavaScript fully or correctly, despite it being enabled.

Says @ianfeather at #AllDayHey — “our monitoring tells us that around 1% of requests for JavaScript on BuzzFeed timeout. That’s around 13 million requests per month.” A reminder if one were needed that we should design for resilience

Taming huge collections of DOM nodes

Hajime Yamasaki Vukelic has come to the conclusion that, if you’re dealing with a really big number of DOM nodes that need to be updated in real time, frameworks are usually incredibly slow on top of the already-slow DOM operations you have to do. The solution they settled on is to avoid frameworks altogether for these scenarios and use vanilla JavaScript. Also of note are that repaints and reflows are going to be big bottlenecks regardless of what you use.

  • If you are looking for performance, don’t use frameworks. Period.
  • At the end of the day, DOM is slow.
  • Repaints and reflows are even slower.
  • Whatever performance you get out of your app, repaints and reflows are still going to be the last remaining bottleneck.
  • Keep the number of DOM nodes down.
  • Cache created DOM nodes, and use them as a pool of pre-assembled elements you can put back in the page as needed.
  • Logging the timings in IE/Edge console is unreliable because the developer tools have a noticeable performance hit.
  • Measure! Always measure performance first, then only fix the issues you’ve reliably identified.

The browser as a runtime environment - Robust Client-Side JavaScript

There are several relevant browsers in numerous versions running on different operating systems on devices with different hardware abilities, internet connectivity, etc. The fact that the web client is not under their control maddens developers from other domains. They see the web as the most hostile software runtime environment. They understand the diversity of web clients as a weakness.

Proponents of the web counter that this heterogeneity and inconsistency is in fact a strength of the web. The web is open, it is everywhere, it has a low access threshold. The web is adaptive and keeps on absorbing new technologies and fields of applications. No other software environment so far has demonstrated this degree of flexibility.

Quoted content by Mathias Schäfer is licensed under CC BY-SA. See the other snippets from Robust Client-Side JavaScript.