Forem: Paul Facklam

Are you a good developer already?

Paul Facklam — Tue, 16 Feb 2021 13:09:25 +0000

As a trainer at click solutions, I regularly supervise trainees and students. Through appropriate onboarding and the teaching of technical content they grow from beginners to real developers. Sometimes even really good developers.

What are good developers and what distinguishes them?

Probably not 😉. I think being a good developer it is definitely not related to

typing fast (maybe even faster than this cat),
the number of lines of code per day or
even the theme on your favorite editor.

In my understanding a good developer...

... writes working code

That comes as a surprise, huh? But yes, good developers make sure that their code works. They do this by:

thinking about it in detail - What can go wrong? Beginners are usually too optimistic and think too little about the case of failure.
planning it - Do I have all the information? Are there any side effects? Beginners often start typing immediately to get things done quickly. Not always the best way to write good code.
testing it - Are all requirements met? Does everything work as expected or am I overlooking something? Beginners sometimes don't test their own piece of code.

... has internalized KISS

Just to clarify. When I say KISS I don't mean the hard rock band from the 80s. It's more the demand to strive for the simplest solution possible for a certain problem. So, Keep It Simple, Stupid! Good developers do that (because they are not stupid, right? 😉).

... has understood DRY

Copy & Paste? No, thank you. Rather: Don't Repeat Yourself. Good developers do repeat themselves, they encapsulate functionality - even if time is running out again. This prevents errors or inconsistencies and increases maintainability at the same time.

... never stops learning

Technologies/Frameworks come and go. The IT sector is determined by constantly changing requirements and innovations. State-of-the-art topics of today may already be outdated tomorrow. Good developers are aware of this fact and educate themselves independently. Ideally, they love to learn for life.

... has learned to work in a team

A good developer has understood that working together is faster, better and makes way more fun than being a lone wolf. They share their code & knowledge, ask for help and help others. Lone wolfs may do a good job, but teams do amazing things.

... wants to get better (every day)

Working in a team brings certain advantages. For example, you always have someone you can ask for advice or feedback. Feedback is a very good way to develop yourself further, as it gives you insight into the way others think and see things, especially about your code or the way you got there. A good developer knows that and asks for feedback to get better (maybe even every day).

... communicates (in time and purposefully)

Problems occur from time to time - they are inevitable. But good developers know when they have lost their way without getting ahead on their own and communicate this before reaching a point of no return (e.g. missing an important deadline). But the same applies when there is something that prevent them from being productive or when they have open questions (e.g. unclear requirements from business side).

Conclusion

There are many aspects to being a good developer, but please remember: no one is born a master or is even perfect. Aiming to be a better developer already takes you a big step further. If you take the time and work on yourself, the rest will come naturally.

Maybe one more not so unimportant thought at the end. To become a good developer, however, you have to do one thing above all: practice, practice, practice... Practice makes perfect! 😄

What do you think? What makes a good developer for you? Let's discuss in the comments!

If you liked this post, please give me a ❤️ or even a 🦄 and feel free to follow me on dev.to. Appreciate it! ✌️

Finally a few more articles from me. Check it out!

Native lazy-loading of images with zero Javascript

Paul Facklam ・ Feb 8 '21

#html #webdev #beginners #javascript

The power of Template Literals

Paul Facklam ・ Feb 19 '20

#javascript #webdev #beginners #codenewbie

Native lazy-loading of images with zero Javascript

Paul Facklam — Mon, 08 Feb 2021 12:04:18 +0000

About lazy-loading and why you should use it

The worldwide web has evolved over the past decades and today's websites consist not only of text and color, but also of countless media content. First and foremost images.



<img src="/path/to/your/image.jpg" alt="Awesome image" />

But what does this have to do with lazy-loading?

Lazy-loading is a technique that defers loading of non-critical resources at page load time. Instead, these non-critical resources are loaded at the moment of need. Where images are concerned, "non-critical" is often synonymous with "off-screen".
-- from web.dev/lazy-loading written by Jeremy Wagner and Rachel Andrew

This means by using lazy-loading we achieve the following benefits over the classic embedding in HTML:

Performance Gains - With lazy-loading we can improve loading speed by reducing the number of images that need to be loaded initially.
Cost reduction - A lazy loaded image may never need to load because the user never reaches the image's position on the page.

Ok, sounds good. How can we make that happen? What do we need for this? Let's get started!

The old (Javascript) approach

There are a lot of snippets and scripts like vanilla-lazyload out there that enable lazy-loading via javascript. In almost all cases a data attribute is used to prevent upfront image loading.


 html
<img data-src="/path/to/your/image.jpg" alt="Awesome image" />

But how is the image loaded at all? To achieve this, one of the following two techniques is usually used.

Event listeners

This technique uses event listeners on the scroll, resize and orientationChange events in the browser. If one of the mentioned events is fired and assuming the image enters the viewport the data-src attribute is replaced with the src attribute to trigger the loading call. See it in action:

Intersection Observer API

Unlike the first method, the image is observed (asynchronously) by using the IntersectionObserver API. The image is then loaded by changing the data-src to src attribute as soon as it enters the viewport.

But what if I told you that you don't need Javascript at all? 😲 Yes, you heard right! Zero Javascript.

The new (HTML) approach

So what does this new way of lazy-loading look like? No worries, it's perfectly simple. You just have to add loading="lazy" to your image tag and that's it. 😎



<img src="/path/to/your/image.jpg" loading="lazy" />

With this new loading attribute, you can completely defer the loading of offscreen images (and even iframes in some browsers) to when they enter the viewport. Enough talking, let's see it in action!

The attribute comes with three values:

auto - (Default) equal to not including the attribute.
lazy - Defer loading of resources until it enters the viewport.
eager - Load the resource immediately

What about browser support?

The attribute is supported by almost every popular browser (Chrome, Edge, Opera and Firefox). The implementation for Safari is in progress and almost done. If you need more detailed information on cross-browser support caniuse.com is your friend.

What happens if a browser does not support the attribute?

Browsers that do not support the loading attribute simply ignore it without any side-effects. Fortunately, there is a polyfill at Github available named loading-attribute-polyfill which can be used in those cases.



if ('loading' in HTMLImageElement.prototype) {
    // Cool! The browser supports the loading attribute
} else {
   // Houston... We need a polyfill!
}

Are there any limitations?

Even though it is pretty cool to let the browser do the lazy-loading work, you should be aware of some limitations that come into play when using the attribute:

Unlike the Javascript variants, you do not have any influence on the threshold to load the resource. It is part of the browser code and can't be changed for now.
The attribute can't be used in combination with CSS background images. Maybe it will come in near future but it is definitely not available now.
If printing the webpage is a real usecase for you, then please notice that there is an open bug for the loading attribute.

If you liked this post, please give me a ❤️ or even a 🦄 and feel free to follow me on dev.to. Appreciate it! ✌️

Paul FacklamFollow

The power of Template Literals

Paul Facklam — Wed, 19 Feb 2020 18:33:09 +0000

I'm pretty sure you've come across a template literal before. That's not surprising, since it's been almost 5 years after its release as one of the features of EMCAScript 6 in June 2015 (where they were once called template strings). Reasons enough to remind yourself what template literals are and what makes them so powerful and extremely useful.

Template Literals

Template literals are a perfectly simple way of creating strings and to perform interpolation on them. I guess that you are quite familiar with the syntax.

Template literals are enclosed by the backtick [...] character instead of double or single quotes.
-- Mozilla Developer Network

const double_quoted_string = "This is a common string."; // not a literal
const single_quoted_string = 'Also a common string'; // 
const literal_string = ``; //

I admit there is nothing special about template literals so far compared to normal strings. But there is more. Imagine you want to have a multi-line string. Is this possible with ordinary strings? Sure it is, but it's not fancy.

const multi_line_string = 'This is a common string.\n' +
'with more than one line.';
// "This is a common string.
// with more than one line."

And here is the trick. If we use a template literal instead, we get this feature out of the box without any workarounds. But keep in mind that any whitespace or newline characters are part of the Template Literal.

const multi_line_literal = `This is a common string.
with more than one line.`;
// "This is a common string.
// with more than one line."

Not impressed yet? Ok wait, I'll give you another example of how cool template literals can be. Placeholders!

Template literals can contain placeholders. These are indicated by the dollar sign and curly braces.
-- Mozilla Developer Network

Gone are the days when you had to laboriously concatenate strings by hand. Now it is just defining the placeholder via ${} and providing the values. That's it!

const num = 3;
const str = "square";
const func = (i) => { return i * i };
const output = `The ${str} of ${num} is ${func(num)}`;
// "The square of 3 is 9"

// ES 5 equivalent
var output_es5 = 'The ' + str + ' of ' + num + ' is ' func(num);
// "The square of 3 is 9"

How cool is this? And there is still more! Template Literals give developers the possibility to create complex strings that can be used for templating. Both nested templates and conditional templating are conceivable.

const item = {
  isExpanded: true,
  content: "This text can only be seen when expanded."
};
const cssClasses = (isExpanded) => `collapsible ${isExpanded ? 'is-expanded' : ''}`;
const collapsible = `
  <div class="${cssClasses(item.isExpanded)}">
    ${item.content}
  </div>
`;

And now the grand finale... If I turn my literal for the collapsible into a function (as I did for the CSS classes), I would be able to output a whole list of items instead of a single one with the help of Array.map. Mind blowing!

const items = [{
  isExpanded: true,
  content: "This text can only be seen when expanded."
}];
const cssClasses = (isExpanded) => `collapsible ${isExpanded ? 'is-expanded' : ''}`;
const collapsible = (item) => `
  <div class="${cssClasses(item.isExpanded)}">
    ${item.content}
  </div>
`;
const list = `
  ${items.map((item) => {
    return collapsible(item);
  })}
`;

Tagged Template Literals

I guess you know what's coming... And you are right. There is still more. 😎 Are you ready for this? Then let's dive in!

A very powerful feature of template literals (and I guess most developers are not aware of this) is the possibility to tag them. In this case we talk about tagged template literals. But what does this mean? It means that you can pass a template through a predefined function.

The tag function can then perform whatever operations on these arguments you wish, and return the manipulated string.
-- Mozilla Developer Network

It does not necessarily have to be a string. The result of the function can also be something different. The name of the function is arbitrary and completely up to you.

The first parameter is of type array and contains the strings. The remaining arguments are related to the expressions.


const topic = 'Template Literals';
const rating = 5;

function rate(strings, topicExp, ratingExp) {
  const str0 = strings[0]; // "'"
  const str1 = strings[1]; // "' is an " 
  const str2 = strings[2]; // " topic."

  let ratingStr;
  if (ratingExp > 4){
    ratingStr = 'awesome';
  } else {
    ratingStr = 'average';
  }

  return `${str0}${topicExp}${str1}${ratingStr}${str2}`;
}

const output = rate`'${topic}' is an ${rating} topic.`;

// 'Template Literals' is an awesome topic.

Please note that this is a just very basic example to demonstrate the mechanisms behind the scenes. There are a lot of use cases where it really makes sense to work with tagged template literals:

Escaping HTML tags
Translation and internationalization
Highlighting in texts

Summary

I admit that this was a lot to digest for a basic introduction. Do you remember everything? Time for a recap. Template literals:

are made with backticks
are multi-line-ready
can have placeholders and their values can even be funtions
can be used for conditional and nested templating
can be used for advanced interpolation

Finally, I would like to thank you for your time and interest in this article. I hope that you enjoyed reading it.

Consistent access to browser events with Pointer Events API

Paul Facklam — Tue, 05 Nov 2019 11:03:12 +0000

Thank god it's christmas! 🌲 Ok, it's not. But if you're a web developer nowadays, it's starting to feel like christmas. And it's because of this:

Added support for the Pointer Events API enabling consistent access to mouse, trackpad, touch, and Apple Pencil events.

-- Safari 13 Release Notes

Thus the last resistance against the Pointer Events API has fallen with Safari 13 and it's now available across all major browsers. And this is simply awesome!

But don't thank Apple! Belive it or not, pointer events (which are not to be mixed up with the CSS property pointer-events) were originally introduced for the Internet Explorer 10 by Microsoft for their Surface devices. 😳

How does it work?

Having a single event model for pointers can simplify creating Web sites and applications and provide a good user experience regardless of the user's hardware.

-- Mozilla Developer Network

Roughly speaking, mouse and touch events are summarized by abstracting input devices like mouse and touch pens as pointing devices. So you don't need to specify different event handlers for different device types any longer.

document.addEventListener('mousedown', () => {
  // do something on mousedown
});

document.addEventListener('touchdown', () => {
  // do something on touchdown
});

Instead you can now simply apply one handler to rule them all.

document.addEventListener('pointerdown', () => {
  // do something on mousedown or touchdown
});

You might now ask: "But can I still react to different device types?" Yes, you can! That's what the pointerType property of the event is for.

document.addEventListener('pointerdown', (e) => {
  switch (e.pointerType) {
    case 'mouse': {
      console.log('Pointer type detected: mouse');
      break;
    }
    case 'pen': {
      console.log('Pointer type detected: pen');
      break;
    }
    case 'touch': {
      console.log('Pointer type detected: touch');
      break;
    }
    default: {
      console.log('PointerType is unknown or could not be detected');
    }
  }
});

A look at the API

The PointerEvent interface extends the MouseEvent interface and defines 10 different pointer event types that can be mapped to more or less known mouse or touch events and which are well documented at MDN:

Pointer Event	Mouse Event
`pointerover`	`mouseover`
`pointerover`	`mouseover`
`pointerenter`	`mouseenter`
`pointerdown`	`mousedown`
`pointermove`	`mousemove`
`pointerup`	`mouseup`
`pointercancel`	no equivalent
`pointerout`	`mouseout`
`pointerleave`	`mouseleave`
`gotpointercapture`	no equivalent
`lostpointercapture`	no equivalent

You also have access to the following read-only properties which give you some additional information about the event:

Property	Description
`pointerId`	a unique identifier for the pointer
`width`	magnitude on the X axis in pixels
`height`	magnitude on the Y axis in pixels
`pressure`	normalized pressure of the pointer input
`tangentialPressure`	normalized tangential pressure of the pointer input
`tiltX`	angle between the Y-Z plane and the plane containing both the pointer axis and the Y axis
`tiltY`	angle between the X-Z plane and the plane containing both the pointer axis and the X axis.
`twist`	the clockwise rotation of the pointer
`pointerType`	indicates the device type
`isPrimary`	indicates if the pointer represents the primary pointer of this pointer type

Polyfill

If you have to support browsers that haven't yet implemented the Pointer Events API you can easily use a polyfill maintained by the jQuery team. But you can also do some basic feature detection and go with a fallback solution instead.

if (window.PointerEvent) {
  // Hello Pointer Events
} else {
  // Oh... Hi fallback... it's you.
}

Thanks for reading this article. I hope you'll enjoy using the Pointer Events API like I do. What are your thoughts about this? Tell me in the comments section below!