JavaScript

This is one of the best responsive navigation menus I’ve seen, implementing the priority+ pattern while mixing in drop-downs and other features.

Ever get annoyed with carousels and similar widgets that have that sort sticky pause when you swipe and release? Well, Flickity totally fixes that by handling momentum in an intuitive way.

This is a great visual example of why you shouldn’t assume that having a touch screen always equals a phone or tablet.

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:

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[.]

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

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.

This is an excellent and comprehensive list of how to minimize your JavaScript performance impact on a user’s device.

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.

This is an excellent, excellent collection of best practices on how to make your JavaScript more fault-tolerant, by Mathias Schäfer. Several sections deserve their own snippets:

• The browser as a runtime environment
• Failing fast
• NaN is contagious
• Conditional statements and truthy values
• Duck typing
• Strict Mode
• Abstraction libraries
• Error logging