The Challenges And Rewards Of Teaching Web Design

Just over four years ago, I decided to take a part-time position teaching website design and front-end development at a local university. My time in the classroom has been one of the most challenging as well as one of the most rewarding experiences in my career, and I believe that other Web professionals would greatly benefit from spending some time in an educational setting teaching others their craft.
In this article, we will look at some of the challenges to prepare for if you are considering taking on a teaching position. I will also present some of my personal experiences and insights, including the benefits and rewards I’ve enjoyed as a teacher, to help you consider such a move for your own career.

Challenges

Let’s start by looking at some of those aforementioned challenges as well as the solutions I’ve used to meet them over the years.

Not Everyone Learns The Same Way

Where you teach, as well as the variety of students in your classroom, will have a dramatic impact on your overall experience. Over the years, students from all walks of life, age groups and experience levels have taken my course. The only constant is that every one of them is completely different — which poses quite a challenge when preparing materials and exercises for the class.
Ultimately, your job is to do what you feel would help the students understand the concepts best. Yet, no matter how well you prepare, the reality is that your materials will work great for some students and not so well for others. You will not be able to reach all students equally because everyone learns differently.

Everyone learns differently, and your responsibility as the teacher is to respond to those different needs. (Image credit: opensourceway)
As you receive feedback from students and realize which ones get it and which ones are lost, you will need to adjust your lesson plans to make sure that you reach all students, not just best and brightest who understood the concepts right away. Of course, part of the challenge is that you must strike a balance here. You’ve spent time carefully considering and building your lesson plans, and you don’t want to blow it up and redo everything because a particular student did not respond well to them. Instead, find ways to get those slower-paced learners up to speed.
I had one student a few years ago who found it difficult to keep up. He was always falling behind, and he felt bad about asking too many questions and holding up the rest of the class — but by asking fewer questions, he fell further behind, and the problem just worsened. Eventually, I suggested that he bring in a digital camera to record the lessons so that he could go over them again later at his own pace. I wasn’t thrilled about the idea of being recorded, but I felt it would help him, so I was open to the idea.
The change was immediate. Watching the recordings at home and going through the lab exercises for a second time at his own pace, he found that the lessons began to make sense and that he was able to keep up in class. His final project ended up being one of the best of the group — a dramatic turnaround from where he started in the course.

Not Everyone Is Cut Out To Be A Web Designer

That being said, the reality is that some students, no matter how much extra attention you give them or how responsive you are to their learning needs, will just never get the material. Unfortunately, I’ve had to drop a number of students from my class over the years. Despite my best efforts, including extra materials developed specifically for these students and extra class time to answer their questions and tutor them, they simply didn’t understand the concepts being taught.
In most cases, these students tried incredibly hard. They put in the effort required, but the results weren’t there and the rest of the class was held up because of their struggle. Having to sit down with those students and explain that I didn’t think they were right for the class is easily the most uncomfortable thing I have had to do as a teacher.

Failing to get through to a student does not necessarily mean that your material or teaching approach is bad. In many cases, it’s not you, it’s the student. (Image credit: D Sharon Pruitt)
If you are going to take on a teaching role, be prepared to make difficult decisions. As uncomfortable as these conversations are, they are sometimes necessary for the good of the class.

Rewriting Lesson Plans

The Web is constantly changing. Lesson plans and exercises that were relevant one semester may be woefully outdated the next. As the Web evolves, so too must your lesson plans.
When I began teaching over four years ago, responsive design hadn’t yet become the best practice it is today. Now, it is one of the most important aspects of my course. Despite all of the work I had put into the class materials, I had to pretty much start from scratch when I decided to introduce responsive Web design into the lessons.
Make sure to teach skills that are relevant to the industry today, revisiting your lessons after each semester and making changes as needed. Most of the time, I need to make only minor changes to course materials; I rarely have to start from scratch. Either way, though, prepare to revise your lesson plans regularly if you hope to keep the course relevant and up to date. Furthermore, understand that your time in the classroom is just a fraction of the time you will have to spend preparing for the class.

The Constraints Of Time

Speaking of time, another challenge is that you have only so much time with the students. So, you need to pick and choose exactly what to present according to what you feel will serve them best. If your classes are like mine and many of your students have no previous experience with Web design, HTML or CSS, then you’ll need to start with the basics. Giving students an understanding of basic design principles and introducing HTML and CSS all the way up to the most current best practices is a tall order. In the end, you have to leave some things out and accept that you can’t teach students everything.
Take support for Internet Explorer (IE) 6. Finding ways to support that old browser has consumed countless hours for those of us who have been in the industry for years, but we don’t struggle with it much these days because use of IE 6 is now so low. Among most of the websites I have worked on lately, IE 6 does not even factor in the user base. Because of this, I have decided not to discuss the challenges of IE 6 because I do not feel it is relevant to the work the students will do once they leave the classroom. If we covered IE 6 support, it would mean we have that much less time to cover something else. The challenge is to decide what is more (and most) important and to make the best use of the time available to present those concepts.
As a side note, websites like Smashing Magazine and other online sources that have built an archive of articles about Web design topics over the years are an invaluable resource for those of us who are teaching the next generation of designers and developers. So much of what we do today is built on the practices of the past. The history of our industry is important, but finding time to present all of that history in the classroom is hard. So, referring students to topics and articles to read is an important strategy for teachers. This is why these archives of articles, which might not seem relevant to today’s best practices, are so important and why decisions to drop thousands of old articles when it resigned its website is such a problem.
As Andy Clarke states in his article “Preserving the History of Web Design,” we need to ensure that new professionals in our industry learn this history, “to learn about the progress we made so they don’t undo it.” Unfortunately, we cannot cover all of that history in the classroom, so the challenge is to figure out how much of it to present and how much to refer them to for review outside of the classroom.

You Represent The Industry

You will be the first Web professional who most of your students have ever met or been able to speak with at length. To them, you represent the industry. The stories you tell and the opinions you share will shape their own understanding and opinions of the industry. That is a pretty big responsibility.

Always keep in mind that you play a major role in shaping your students’ understanding and opinions of the Web industry. (Image credit: Dell Inc.)
We all have bad days, but taking negativity from the office into the classroom will absolutely affect how your students see the industry. You don’t have to present the job as being all rainbows and gumdrops, but be mindful of what you say to students and avoid using the classroom as a place to blow off steam, regardless of how bad your day is or how frustrating an exchange with a client has been. Complaining about clients is never productive or appropriate, and too many in our industry relish the opportunity to share bad stories. Doing this with students gives them the wrong impression and trains them not to respect clients.
You have an opportunity to set these new Web professionals off on the right path. By maintaining a positive outlook and by exposing the students to the best parts of our industry, you can help to cultivate designers and developers who will help our industry continue to grow, instead of hold it back.

You Are Responsible For What You Put Into This World

Building on this theme of responsibility, you are absolutely responsible for what you put into the world. I have heard many Web designers echo this sentiment as they look to do work that has meaning and that makes a difference. The projects and clients we take on and the websites we launch into the world are our responsibility — and that responsibility is multiplied many times over when you decide to become a teacher.
As a teacher, you are at least partially responsible for the work your students will do. When your students go on to do great things, it is awesome. One of my students a few years ago took a position with an important non-profit organization in our area. Seeing her work make a difference for that organization and the people it helps was extremely gratifying.
Unfortunately, not all interactions with former students end as positively as this one did. Other former students of mine have done really bad work as freelancers. I remember one former student contacting me and asking me to look at the most recent website he had designed and developed for a client. There is no way to sugarcoat it — the website was bad. The design was unattractive, the user experience confusing, and the code sloppy and poorly written. This put me in an uncomfortable position.
He was obviously very excited about his work and was asking for feedback, but any feedback I could give would be negative. In the end, I told him that I was happy to see him working on the skills we had covered in class, and I suggested a few improvements to the website. The student thanked me for my input and made a few changes to the website. Since that time, I have followed his work and seen other mediocre websites that he has designed for clients, but he never again asked for my feedback, nor have I offered it.
This experience was not confined to this one student. Over the years, other former students have taken on freelance work and subsequently launched poor websites into the world. I would be lying if I told you I didn’t feel some responsibility for these poorly done websites, but in the end, you cannot police every student once they leave the class. All you can do is give them the best information and show them the right way to design and develop a website. What they do with that information, for better or for worse, is something you have no real control over.

Rewards And Benefits

So far, we’ve looked only at the challenges of teaching in this industry. Those challenges are real and substantial, but if you can meet them, then you’ll also find a number of rewards and benefits from taking on this responsibility. Let’s now turn to some of those rewards.

Helping Others

Helping others can be a powerful experience. Spending time in the classroom to teach others your craft is one way to use the knowledge you have gained to improve the lives of others.
Many of the students I teach are unemployed or underemployed. Their tuition for my class is paid for by a grant set up to give them skills relevant to today’s workforce. Helping these unemployed individuals to better themselves and learn new skills is important work, and seeing students go on to find good entry-level jobs in the industry is incredibly rewarding. Hearing from those students later on that the lessons and conversations in the class helped to prepare them for success really makes all of my hard work worthwhile.
I have always loved the giving, collaborative nature of the Web industry. Teaching students is one way to contribute to the Web community while having a real impact on the lives of others.

Learning By Teaching

One of the best ways to truly understand something is by teaching it to others. While my time in the classroom is dedicated to teaching website design, I would be lying if I said that I didn’t learn quite a bit from the experience as well.
Try to explain the CSS box model or the difference between relative and absolute positioning to a new student, and I guarantee you will understand the concept better than before. This greater understanding and the experience of explaining these technical concepts to students will also help you speak with clients.

Teaching forces you to find ways to explain concepts in a way that others who do not have the benefit of your experience will grasp. (Image credit: opensourceway)
Being able to communicate with clients without being too technical or intimidating, and in a way that helps them to grasp the concepts enough to be able to make informed decisions about their business and their website, is an important skill. The lessons you prepare and your conversations with students can and will equip you for these client interactions and make you better at what you do.

Generating Business

Speaking of clients, I wouldn’t have expected this when I began teaching, but my time in the classroom has led to a number of projects outside of the classroom. Multiple students have passed along solid leads to me because they could not handle the projects themselves with their level of experience. Former students have also invited the agency I work for to bid on projects initiated by the organizations they’ve joined.
Over the years, a number of people have asked me whether I realize that, by being a teacher, I am training professionals who will one day replace me or, at the very least, take work away from me. I’ve honestly never felt that way. I’ve always felt that there is more than enough work to go around. And, as my experience shows, being a teacher and making a positive impression on your students will not only not lose you clients, but could actually generate business for you and your agency.

How Do I Get Started?

Hopefully, this article has given you some points to think about as you consider whether a teaching position is right for you at this point in your career. If you’d like to explore this possibility, how should you begin?
My opportunity came when I began telling others of my desire to speak more about our industry and the work that I do. A fellow Web developer who had taught at the university for many years heard me one day and, knowing of an opening at the school, referred me. Within a few weeks, I was in front of my first group of students.
While my experience might not be typical, there is a lesson in it. Spreading the word about your interest in a teaching position could open doors. Do not be shy to let others know that you’d like to explore this move.
Other strategies are to contact your local universities, colleges, and business centers to see whether they have any openings. Sometimes, a little outreach turns up an amazing opportunity.
If you can’t find an opening at an institution of higher education or you feel you are not yet ready for that level and would like to start smaller, consider giving small workshops or classes at a local library or even as a private tutor.
Whatever path you choose to get started, consider what you can offer to students who are interested in learning more about our industry. I assure you that the students will not be the only ones who get something positive from the experience.

At present, jQuery is the de facto library for working with the document object model (DOM). It can be used with popular client-side MV* frameworks (such as Backbone), and it has a ton of plugins and a very large community. As developers’ interest in JavaScript increases by the minute, a lot of people are becoming curious about how native APIs really work and about when we can just use them instead of including an extra library.
Lately, I have started to see more and more problems with jQuery, at least my use of it. Most of the problems are with jQuery’s core and can’t be fixed without breaking backwards compatibility — which is very important. I, like many others, continued using the library for a while, navigating all of the pesky quirks every day.
Then, Daniel Buchner created SelectorListener, and the idea of “live extensions” manifested. I started to think about creating a set of functions that would enable us to build unobtrusive DOM components using a better approach than what we have used so far. The objective was to review existing APIs and solutions and to build a clearer, testable and lightweight library.

Adding Useful Features To The Library

The idea of live extensions encouraged me to develop the better-dom project, although other interesting features make the library unique. Let’s review them quickly:

• live extensions
• native animations
• embedded microtemplating
• internationalization support

Live Extensions

jQuery has a concept called “live events.” Drawing on the idea of event delegation, it enables developers to handle existing and future elements. But more flexibility is required in a lot of cases. For example, delegated events fall short when the DOM needs to be mutated in order to initialize a widget. Hence, live extensions.
The goal is to define an extension once and have any future elements run through the initialization function, regardless of the widget’s complexity. This is important because it enables us to write Web pages declaratively; so, it works great with AJAX applications.

Live extensions enable you to handle any future elements without the need to invoke the initialization function. (Image credits)
Let’s look at a simple example. Let’s say our task is to implement a fully customizable tooltip. The :hover pseudo-selector won’t help us here because the position of the tooltip changes with the mouse cursor. Event delegation doesn’t fit well either; listening to mouseover and mouseleave for all elements in the document tree is very expensive. Live extensions to the rescue!

DOM.extend("[title]", {
  constructor: function() {
    var tooltip = DOM.create("span.custom-title");

    // set the title's textContent and hide it initially
    tooltip.set("textContent", this.get("title")).hide();

    this
      // remove legacy title
      .set("title", null)
      // store reference for quicker access
      .data("tooltip", tooltip)
      // register event handlers
      .on("mouseenter", this.onMouseEnter, ["clientX", "clientY"])
      .on("mouseleave", this.onMouseLeave)
      // insert the title element into DOM
      .append(tooltip);
  },
  onMouseEnter: function(x, y) {
    this.data("tooltip").style({left: x, top: y}).show();
  },
  onMouseLeave: function() {
    this.data("tooltip").hide();
  }
});

We can style the .custom-title element in CSS:

.custom-title {
  position: fixed; /* required */
  border: 1px solid #faebcc;
  background: #faf8f0;
}

The most interesting part happens when you insert a new element with a title attribute in the page. The custom tooltip will work without any initialization call.
Live extensions are self-contained; thus, they don’t require you to invoke an initialization function in order to work with future content. So, they can be combined with any DOM library and will simplify your application logic by separating the UI code into many small independent pieces.
Last but not least, a few words on Web components. A section of the specification, “Decorators,” aims to solve a similar problem. Currently, it uses a markup-based implementation with a special syntax for attaching event listeners to child elements. But it’s still an early draft:

“Decorators, unlike other parts of Web Components, do not have a specification yet.”

Native Animations

Thanks to Apple, CSS has good animation support now. In the past, animations were usually implemented in JavaScript via setInterval and setTimeout. It was a cool feature — but now it’s more like a bad practice. Native animations will always be smoother: They are usually faster, take less energy and degrade well if not supported by the browser.
In better-dom, there is no animate method: just show, hide and toggle. To capture a hidden element state in CSS, the library uses the standards-based aria-hidden attribute.
To illustrate how it works, let’s add a simple animation effect to the custom tooltip that we introduced earlier:

.custom-title {
  position: fixed; /* required */
  border: 1px solid #faebcc;
  background: #faf8f0;
  /* animation code */
  opacity: 1;
  -webkit-transition: opacity 0.5s;
  transition: opacity 0.5s;
}

.custom-title[aria-hidden=true] {
  opacity: 0;
}

Internally, show() and hide() set the aria-hidden attribute value to be false and true. It enables the CSS to handle the animations and transitions.
You can see a demo with more animation examples that use better-dom.

Embedded Microtemplating

HTML strings are annoyingly verbose. Looking for a replacement, I found the excellent Emmet. Today, Emmet is quite a popular plugin for text editors, and it has a nice and compact syntax. Take this HTML:

body.append("<ul><li class='list-item'></li><li class='list-item'></li><li class='list-item'></li></ul>");

And compare it to the equivalent microtemplate:

body.append("ul>li.list-item*3");

In better-dom, any method that accepts HTML may use Emmet expressions as well. The abbreviation parser is fast, so no need to worry about a performance penalty. A template precompilation function also exists to be used on demand.

Internationalization Support

Developing a UI widget often requires localization — not an easy task. Over the years, many have tackled this in different ways. With better-dom, I believe that changing the state of a CSS selector is like switching languages.
Conceptually speaking, switching a language is like changing the “representation” of content. In CSS2, several pseudo-selectors help to describe such a model: :lang and :before. Take the code below:

[data-i18n="hello"]:before {
  content: "Hello Maksim!";
}

[data-i18n="hello"]:lang(ru):before {
  content: "Привет Максим!";
}

The trick is simple: The value of the content property changes according to the current language, which is determined by the lang attribute of the html element. By using data attributes such as data-i18n, we can maintain the textual content in HTML:

[data-i18n]:before {
  content: attr(data-i18n);
}

[data-i18n="Hello Maksim!"]:lang(ru):before {
  content: "Привет Максим!";
}

Of course, such CSS isn’t exactly attractive, so better-dom has two helpers: i18n and DOM.importStrings. The first is used to update the data-i18n attribute with the appropriate value, and the second localizes strings for a particular language.

label.i18n("Hello Maksim!");
// the label displays "Hello Maksim!"
DOM.importStrings("ru",  "Hello Maksim!", "Привет Максим!");
// now if the page is set to ru language,
// the label will display "Привет Максим!"
label.set("lang", "ru");
// now the label will display "Привет Максим!"
// despite the web page's language

Parameterized strings can be used as well. Just add ${param} variables to a key string:

label.i18n("Hello ${user}!", {user: "Maksim"});
// the label will display "Hello Maksim!"

Making Native APIs More Elegant

Generally, we want to stick to standards. But sometimes the standards aren’t exactly user-friendly. The DOM is a total mess, and to make it bearable, we have to wrap it in a convenient API. Despite all of the improvements made by open-source libraries, some parts could still be done better:

• getter and setter,
• event handling,
• functional methods support.

Getter and Setter

The native DOM has the concept of attributes and properties of elements that could behave differently. Assume we have the markup below on a Web page:

<a href="/chemerisuk/better-dom" id="foo" data-test="test">better-dom</a>

To explain why “the DOM is a total mess,” let’s look at this:

var link = document.getElementById("foo");

link.href; // => "https://github.com/chemerisuk/better-dom"
link.getAttribute("href"); // => "/chemerisuk/better-dom"
link["data-test"]; // => undefined
link.getAttribute("data-test"); // => "test"

link.href = "abc";
link.href; // => "https://github.com/abc"
link.getAttribute("href"); // => "abc"

An attribute value is equal to the appropriate string in HTML, while the element property with the same name could have some special behavior, such as generating the fully qualified URL in the listing above. These differences can be confusing.
In practice, it’s hard to imagine a practical situation in which such a distinction would be useful. Moreover, the developer should always keep in mind which value (attribute or property) is being used that introduces unnecessary complexity.
In better-dom, things are clearer. Every element has only smart getters and setters.

var link = DOM.find("#foo");

link.get("href"); // => "https://github.com/chemerisuk/better-dom"
link.set("href", "abc");
link.get("href"); // => "https://github.com/abc"
link.get("data-attr"); // => "test"

In the first step, it does a property lookup, and if it’s defined, then it’s used for manipulation. Otherwise, getter and setter work with the appropriate attribute of the element. For booleans (checked, selected, etc.), you could just use true or false to update the value: Changing such a property on an element would trigger the appropriate attribute (native behavior) to be updated.

Improved Event Handling

Event handling is a big part of the DOM, however, I’ve discovered one fundamental problem: Having an event object in element listeners forces a developer who cares about testability to mock the first argument, or to create an extra function that passes only event properties used in the handler.

var button = document.getElementById("foo");

button.addEventListener("click", function(e) {
  handleButtonClick(e.button);
}, false);

This is really annoying. What if we extracted the changing part as an argument? This would allow us to get rid of the extra function:

var button = DOM.find("#foo");

button.on("click", handleButtonClick, ["button"]);

By default, the event handler passes the ["target", "defaultPrevented"] array, so no need to add the last argument to get access to these properties:

button.on("click", function(target, canceled) {
  // handle button click here
});

Late binding is supported as well (I’d recommend reading Peter Michaux’s review of the topic). It’s a more flexible alternative to the regular event handlers that exist in the W3C’s standard. It could be useful when you need frequent on and off method calls.

button._handleButtonClick = function() { alert("click!"); };

button.on("click", "_handleButtonClick");
button.fire("click"); // shows "clicked" message
button._handleButtonClick = null;
button.fire("click"); // shows nothing

Last but not least, better-dom has none of the shortcuts that exist in legacy APIs and that behave inconsistently across browsers, like click(), focus() and submit(). The only way to call them is to use the fire method, which executes the default action when no listener has returned false:

link.fire("click"); // clicks on the link
link.on("click", function() { return false; });
link.fire("click"); // triggers the handler above but doesn't do a click

Functional Methods Support

ES5 standardized a couple of useful methods for arrays, including map, filter and some. They allow us to use common collection operations in a standards-based way. As a result, today we have projects like Underscore and Lo-Dash, which polyfill these methods for old browsers.
Each element (or collection) in better-dom has the methods below built in:

• each (which differs from forEach by returning this instead of undefined)
• some
• every
• map
• filter
• reduce[Right]

var urls, activeLi, linkText; 

urls = menu.findAll("a").map(function(el) {
  return el.get("href");
});
activeLi = menu.children().filter(function(el) {
  return el.hasClass("active");
});
linkText = menu.children().reduce(function(memo, el) {
  return memo || el.hasClass("active") && el.find("a").get()
}, false);

Avoiding jQuery Problems

Most of the following issues can’t be fixed in jQuery without breaking backwards compatibility. That’s why creating a new library seemed like the logical way out.

• the “magical” $ function
• the value of the [] operator
• issues with return false
• find and findAll

The “Magical” $ Function

Everyone has heard at some point that the $ (dollar) function is kind of like magic. A single-character name is not very descriptive, so it looks like a built-in language operator. That’s why inexperienced developers call it inline everywhere.
Behind the scenes, the dollar is quite a complex function. Executing it too often, especially in frequent events such as mousemove and scroll, could cause poor UI performance.
Despite so many articles recommending jQuery objects to be cached, developers continue to insert the dollar function inline, because the library’s syntax encourages them to use this coding style.
Another issue with the dollar function is that it allows us to do two completely different things. People have gotten used to such a syntax, but it’s a bad practice of a function design in general:

$("a"); // => searches all elements that match “a” selector
$("<a>"); // => creates a <a> element with jQuery wrapper

In better-dom, several methods cover the responsibilities of the dollar function in jQuery: find[All] and DOM.create. find[All] is used to search element(s) according to the CSS selector. DOM.create makes a new elements tree in memory. Their names make it very clear what they are responsible for.

Value of the [] Operator

Another reason for the problem of frequent dollar function calls is the brackets operator. When a new jQuery object is created, all associated nodes are stored in numeric properties. But note that the value of such a property contains a native element instance (not a jQuery wrapper):

var links = $("a");

links[0].on("click", function() { ... }); // throws an error
$(links[0]).on("click", function() { ... }); // works fine

Because of such a feature, every functional method in jQuery or another library (like Underscore) requires the current element to be wrapped with $() inside of a callback function. Therefore, developers must always keep in mind the type of object they are working with — a native element or a wrapper — despite the fact that they are using a library to work with the DOM.
In better-dom, the brackets operator returns a library’s object, so developers can forget about native elements. There is only one acceptable way to access them: by using a special legacy method.

var foo = DOM.find("#foo");

foo.legacy(function(node) {
  // use Hammer library to bind a swipe listener
  Hammer(node).on("swipe", function(e) {
    // handle swipe gesture here
  }); 
});

In reality, this method is required in very rare cases, such as to be compatible with a native function or with another DOM library (like Hammer in the example above).

Issues With return false

One thing that really blows my mind is the strange return false interception in jQuery’s event handlers. According to the W3C’s standards, it should in most cases cancel the default behavior. In jQuery, return false also stops event delegation.
Such interception creates problems:

1. Invoking stopPropagation() by itself could lead to compatibility problems, because it prevents listeners that are related to some other task from doing their work.
2. Most developers (even experienced ones) are not aware of such behavior.

It’s unclear why the jQuery community decided to go cross-standards. But better-dom is not going to repeat the same mistake. Thus, return false in an event handler only prevents the browser’s default action, without messing with event propagation, as everyone would expect.

find and findAll

Element search is one of the most expensive operations in the browser. Two native methods could be used to implement it: querySelector and querySelectorAll. The difference is that the first one stops searching on the first match.
This feature enables us to decrease the iterations count dramatically in certain cases. In my tests, the speed was up to 20 times faster! Also, you can expect that the improvement will grow according to the size of the document tree.
jQuery has a find method that uses querySelectorAll for general cases. Currently, no function uses querySelector to fetch only the first matched element.
The better-dom library has two separate methods: find and findAll. They allow us to use querySelector optimization. To estimate the potential improvement in performance, I searched for the usage of these methods in all of the source code of my last commercial project:

• find
  103 matches across 11 files
• findAll
  14 matches across 4 files

The find method is definitely much more popular. It means that querySelector optimization makes sense in most use cases and could give a major performance boost.

Conclusion

Live extensions really make solving front-end problems much easier. Splitting the UI in many small pieces leads to more independent and maintainable solutions. But as we’ve shown, a framework is not only about them (although it is the main goal).
One thing I’ve learned in the development process is that if you don’t like a standard or you have a different opinion of how things should work, then just implement it and prove that your approach works. It’s really fun, too!