JavaScript

Container-Adapting Tabs With "More" Button

A non-wrapping horizontal menu, with a "More" button on the end, which reveals a vertical list of menu items that overflow the limited horizontal space.

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

Tags: 

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

Ian Feather standing on a stage in front of a graphic that reads "13 million JavaScript requests will fail".

More evidence that we don’t fully control our web pages, nor is it a safe assumption that the only way that JavaScript doesn’t run is if it’s explicitly disabled.

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

Tags: 

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.

Tags: 

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.

Tags: 

Robust Client-Side JavaScript - A Developer's Guide

Immediately-Invoked Function Expression (IIFE), a.k.a. self-executing anonymous functions

Javascript

(function () {
	// Safely declare your names inside this function.
	var variabl1 = 1;
	let variable2 = 2;
	const constant = 3;
	function someFunction() {}
	class SomeClass {}
})();

At the heart of this pattern, there is an anonymous function function () {…}. This is a function expression that simply creates a function and returns it as a value, in contrast to a function declaration that creates a function and inevitably binds it to a name.

The braces around the anonymous function, ( function() {…} ), allow the parser to recognize the function expression correctly. Finally, the braces at the end () call the function immediately. That is why it is called immediately-invoked function expression.

Quoted content is licensed under CC BY-SA.

Tags: 

A love letter to jQuery

It hurts me when I hear them say things like “you don’t need jQuery”. They don’t remember how dark it was before your light. We needed you then and we still need you now. I like the way you do things and although the years have passed, for certain tasks, you still do what you do better than anyone else could. I trust you. I know you and you know me. There will always be other ways we could do things, but I know I can rely on you and you’re always there when I need you to be.

Tags: 

Pages