DEV Community: Nathan Pasko

I'm Making a New V. Pet

Nathan Pasko — Mon, 12 Jul 2021 18:50:02 +0000

The rumors are true.... I'm making a new virtual pet! Last time around, I made S. Pet, a retro v. pet inspired by Tamagotchi, Digimon, and the v. pets of my childhood. Someday I'd love to make a pet that's a physical, pocket-sized toy, but S. Pet was native to Android, and my new pet, called G. Pet, is in development for Mac, Windows, and Linux.

G. Pet, like its predecessor, is inspired by old toys and rendered in a retro video game style. G. Pet uses a PSX-style pipeline and features 3D graphics and even physics. Watch your pet walk around the stage, drop in a boombox with five original tracks, plus push it all around with Unity physics (you can push your pet's poop, too). Another big distinction for G. Pet is that each pet will be sold as an individual adoption. Everybody will have a pet unique to them (DRM-free, of course). For now, G. Pet is in free alpha, and everybody can get a behind-the-scenes peek via George the giraffe/tortoise thing.

I've already pushed a few rounds of updates on itch.io. You can read more about the early development on the devlog over there. Now I'm starting a new series for G. Pet stuff here on Dev; it might turn into reposts of the devlog at itch.io, or it might be more like digests or ruminations on the process. Not sure yet! Thanks for tuning in though, and don't forget to download the G. Pet alpha here.

My First Year with React

Nathan Pasko — Sun, 16 May 2021 14:55:00 +0000

Around this time last year, I was focused more on JavaScript and HTML than any front end framework. I had spent some time learning Angular, but I was also several months removed from working on any Angular project.

Learning React

So around this time I finally gave in and started learning React. My first impression was actually less related to the framework and more to the quality of the React introductory tutorial. I was surprised how easy it was to read and understand.

As I toured through the different areas of the framework, that feeling just expanded to encapsulate how I felt about React on the whole. I love the straightforwardness that seems to permeate React's design.

Class Components

One thing I was reading about in the documentation but not quite understanding: Hooks. Maybe it was the terminology, the explanation, or maybe I just needed more time to wrap my head around everything, but I wasn't sure exactly what I was looking at with Hooks. So I started writing class components. This was great in and of itself because even though the docs made it clear that Hooks were the new thing, the docs made it just as clear that they were an optional enhancement to the React framework. I was simply encouraged to come back and check out Hooks when I was ready.

Instead I focused on what seemed the older, more stable core of React. I got my footing and then shipped my first React app about four months later.

Learning Hooks

Sometime after the launch that project, after I'd had some time to rest, I found myself getting ready to start a new side project (built on React, since I was fascinated). Checking something on Stack Overflow, I saw a comment that reminded me of React Hooks. Finally I doubled back to the React docs to get a clear idea of what those durn Hooks were.

What can I say? I love em. Writing all functional components and using a retooled State save me code (and clutter). Everything feels lighter on its feet; more streamlined. Maybe I can't truly wish that I'd employed Hooks from the beginning—since their depiction as optional was part of the welcoming, practical air that drew me in—but I do feel that Hooks have been a huge improvement to the way I work with React.

One Year Anniversary

It's been about a year since I started messing around with React, and I like the framework quite a lot. Its popularity led to the release of so many helpful packages, and that goes a long way. Its popularity also makes it easier to learn because there are more people asking and answering questions online, more people creating more learning resources for more people of different learning styles. Today I'm still maintaining React apps for a couple clients, but if I were to start a new side project right now, I might reach for a more lightweight framework. That'd be more out of curiosity than anything else. Like anything you practice regularly for a year, it's easy for me write with React brain right now. Maybe in another year's time, I'll be hooked on a different framework.

Should only the app toolbar use h1?

Nathan Pasko — Fri, 12 Mar 2021 14:01:21 +0000

Every day I ask myself.

Pokémon + Dev ?

Nathan Pasko — Sun, 28 Feb 2021 18:24:56 +0000

Any other devs out there celebrating the 25th anniversary of the Pokémon games? A little bit of childhood nostalgia is going a long way for me this weekend.

So what’s your favorite Pokémon-related dev tool? Mine’s gotta be this Node package pokemon. I like to use it to generate text when I get tired of lorem ipsum. No, it’s not coherent, but it makes me chuckle during those prototyping long hauls.

Discovering the WebAudio API & Making a Simple Synth

Nathan Pasko — Sun, 21 Feb 2021 17:54:07 +0000

I work primarily as a web developer, but you might not know that I'm also a musician. I have a special appreciation for the creativity found in experimental electronic music. Recently I was curious about where audio tools for the web were at, and I was impressed by the HTML <audio> element, though I ran up against what I considered a pretty big shortcoming: it can't loop seamlessly.

That's what led me the WebAudio API. It's an API intended for people like me who have a little background in messing with sound and I had no idea it was out there. I quickly learned how to repeat an audio clip without the interruption in the loop provided by the standard <audio> element, and in the process I did some reading about WebAudio's other capabilities.

A Few WebAudio Offerings

WebAudio features a number of different types of audio sources; in the documentation I noticed an oscillator type and I was inspired to see what kind of web-based synthesizer I could make with the WebAudio API. My goal wasn't to make something with a keyboard for playing pop music, but something simpler, more suited to creating atmosphere or sound effects.

WebAudio uses a metaphor carried over from physical sound equipment that describes the flow of audio through a number of nodes connected in a designated order. In JavaScript, I set up a couple oscillator nodes and connected them to the WebAudio destination; it felt like the JavaScript equivalent of plugging instruments and effects units into a mixer. I added some other nodes like gain nodes to control volume at different points in the "circuit", and convolution nodes to add reverb.

The controls for the synth? Simple HTML <input> elements. I was absolutely tickled to learn that a range input would stand in for a potentiometer in this WebAudio world. One of the reasons I left my synth visually unstyled is to emphasize the webbiness of it all—playing sounds involves yanking a bunch of browser-default sliders around and selecting from dropdown menus. It brings a smile to my face.

Introducing Dulce Baby

The final features of my synth, the Dulce Baby, include one oscillator with variable waveform, coarse tone control, and volume control, another oscillator that plays a drone and fine tone control, and a master gain for overall volume. The drone options are frequencies borrowed from Cousto's The Cosmic Octave: they're the frequencies of the planets in our solar system.

Time to Explore

Overall the WebAudio API is a very exciting discovery for me. It's inspired this start to a new series about experimenting with WebAudio. Today I haven't shown much process or code, but in the future this series will delve more into the nitty gritty. Read along for some creative coding and non-visual web design!

Happy Valentines Day

Nathan Pasko — Sun, 14 Feb 2021 14:41:35 +0000

Happy Valentines Day, devs!

I’m taking this week off from blogging because it’s been a busy one. Got a big project to announce soon, so see you then!

How to Check Whether a Device Supports Hover with a CSS Media Query

Nathan Pasko — Sun, 07 Feb 2021 19:00:02 +0000

This series is all about expanding our definition of responsive web design beyond the commonly-held starting point of handling different screen sizes. Similar to our discussion of automatically responding to devices' light/dark display settings, today we'll once again use a CSS media query to respond to the context presented by client devices.

Interactivity & Hover

Hover effects are important! We know we should never hijack the cursor icon to highlight interactive UI elements like buttons. That compromises the spec and has snowballing accessibility complications. Finding another way to communicate interactivity will help users navigate our interfaces effortlessly, so let's use CSS to make our hover effects smarter.

The Problem

What makes hover effects tricky is the difference between devices with traditional mouse-like pointers, and devices with touch input like smart phones. We don't really have the same continuous pointer input on a touch device that we do when using a mouse, but a site's design should still communicate what elements are interactive.

A Solution

Today let's solve this problem by communicating interactivity with color. Users with a mouse-like pointer will be able to test an element's interactivity by hovering over it. When they hover, interactive elements will be highlighted with a bright background color. Touch device users won't have that opportunity to hover, so we'll set interactive elements to have the highlighted background color at all times.

How to Detect Hover Support in CSS

Let's build a basic example to test our solution. We can start with a blank HTML page. We'll add some CSS styles shortly, but first we'll give ourselves an interactive element to play with: a button.

<button>Button</button>

Buttons are familiar in function but they take many different forms, so it's important to communicate visually that they're interactive. We'll use a yellow background to indicate interactivity.

Like usual, we'll write our stylesheet to default to mobile device styles, and use media queries to make changes in styles for other devices. So let's start by styling button to have the yellow background associated with interactivity.

button {
  background: yellow;
}

We'll use the hover media feature in a query to test whether hover is supported by the client device. Let's add this media query to our stylesheet so that we can apply styles for hover-capable devices.

@media (hover: hover) {
  button {
    background: white;
  }
  button:hover {
    background: yellow;
  }
}

Now the capability to hover over buttons will override the default button styles and allow users to test interactivity by hovering. It's that easy! Sad to say I went years without using this helpful media query and was stymied by my hover styles predicament the whole time.

Note!
The `hover` media feature can report either `hover` or `none`. Devices capable of hover report `hover`, and devices incapable of hover report `none`.

Get Out There and Use It

This kind of responsiveness is a big deal. I think it's the highest priority responsiveness technique we've talked about in this series. It's tied into the rampant misuse of the cursor icon reserved for hovering over hyperlinks 👆 and results in a spec-friendly fix to the problem of communicating interactivity. Oh, @media (hover), where have you been all my life?

How to Check the Current Time with JavaScript

Nathan Pasko — Sun, 31 Jan 2021 19:22:08 +0000

This series is all about expanding our definition of responsive design. At its core, responsiveness is all about adapting a design to its context, but that context can mean a lot more than a device's screen size; we're brainstorming to respond to light & dark display modes, location, and now, the current time and date.

The Date Object

JavaScript has a built-in type called Date that encapsulates a moment in time. Date objects also have built-in methods to manipulate them, but even so, the JavaScript Date object is considered a bit broken by our community. It can be difficult to use, but I've seen promising alternatives on the horizon, and for our purposes today we can stick to Date's most basic features.

Let's build up an example web page to demonstrate how to make a design respond to the current time. All we need to start is a fresh HTML page.

How to Check the Current Time and Date in JavaScript

In JavaScript a constructor is a special function that creates a new instance of a class. By using the basic Date constructor, we can get a Date object representing the current time. We can use console.log() to try it out; we'll log the time that we refresh the page.

// Use Date constructor to get current time
var now = new Date();
console.log(now);

Since a Date object encapsulates so much data, all describing a single moment, Date provides a number of functions that we can use to grab a single slice of that data. For example, Date.getMinutes() and Date.getHours() will return just the minutes or hours values of the Date object respectively.

// Get just the hours or just the minutes
console.log(now.getHours());
console.log(now.getMinutes());

// Use a colon to log a clock-like readout
console.log(now.getHours(), ':', now.getMinutes());

We'll make use of Date.getHours() in particular to demonstrate a time-based responsive design.

How to Write a Simple Responsive Design Using Time

Let's use JavaScript and CSS together to create a responsive design using Date. We'll change the background color of the page in accordance with he current time of day. First things first: let's give ourselves a <div> called #container to ensure we have control over the page background. We'll add some CSS styles to the container in a moment.

<div id="container"></div>

Morning, afternoon, evening, and night will each have their own corresponding background color. Our approach will be to check the current time upon page load, use Date.getHours() to infer which time period we're currently in, and then set the answer to a data attribute in order to apply the correct styles.

In our stylesheet, we'll first guarantee the container fills the page for visual effect, and then we'll write style rules that hinge on an attribute called data-time.

#container {
  height: 100vh;
  width: 100%;
}
#container[data-time="morning"] {
  background: pink;
}
#container[data-time="afternoon"] {
  background: aqua;
}
#container[data-time="evening"] {
  background: blue;
}
#container[data-time="night"] {
  background: black;
}

Back in our JavaScript, we need a reference to our container element, so we'll declare that. Now we'll add a small array of data that describes the four times of day that we want to work with, including their start and end.

// Grab container element
const container = document.getElementById('container');
// Times of day data
const times = [
  { name: 'morning', start: 4, end: 12 },
  { name: 'afternoon', start: 12, end: 17 },
  { name: 'evening', start: 17, end: 20 },
  { name: 'night', start: 20, end: 23 }
];

That array of times of day will help us figure out what time we're currently in. Let's use a variable called currentTime to hold the current time of day. Because of the way night wraps around multiple days, complicating the logic, let's set the default value for currentTime to night.

// Use times array to default time to night
var currentTime = times[3];

Using night as our default value will let us write simpler code checking just the other three times of day.

Finally, we'll write a for loop to complete the example. Since we have night set as our default time, we only need to iterate through the first three objects in our times array. To find the correct time of day we'll compare the hours value of our Date object to the start and end times of each time of day. The hours value will be greater than or equal to the start value of the current time of day, and less than its end value. Our for loop will iterate through the data in our array, and when it reaches the correct time of day, it will store the answer in currentTime and set our container div's data-time attribute accordingly.

// Grab hours from Date object
const hours = now.getHours();

// Iterate through times of day
for (var i = 0; i < 3; i++) {
  // If this time of day matches
  if (hours >= times[i].start && hours < times[i].end) {
    // Store correct time of day
    currentTime = times[i];
    // Communicate time of day to styles via data attribute
    container.dataset.time = currentTime.name;
  }
}

Now we have a basic responsive design that reflects the time of day! When we reload the page, the container's background color sets itself accordingly.

Final Thoughts

The example above proves how simple it can be to respond to current time in our designs. Responsiveness based on screen size is everywhere now, but other kinds of responsive design are more scarce. Let's take our expanded definition of responsiveness out into the world and create more interactive designs!

A note about the JavaScript Date object before we go. The Date object was sufficient for today's example, but it can be difficult to work with when we get more in depth. There are alternatives out there; moment has proven to be a mainstay and it's so easy to use that I think it's worth a look. I think there's great value in familiarizing oneself with vanilla JavaScript's many features (I recently penned a series of examples of jQuery operations written in vanilla JS), but Date is often the first exception to that rule that I make in any project. Sometime last year I read about a promising proposal for a replacement for Date called Temporal which probably deserves some attention. All of this is to say that Date can be tricky, and while I usually prefer to paint JavaScript as a forgiving language for beginners, Date is a place where I don't think there's any shame in acknowledging the off-putting implementation provided by vanilla JavaScript.

Though the state of date and time in JavaScript is complicated, the main idea behind this article is to expand what we think about when we consider the term "responsive." If you were following along with the code, you felt how quick and easy it is to tap into the current time and date. Let these ideas percolate and see what new kinds of responsive designs you're able to create!

How to Check a User's Location with JavaScript

Nathan Pasko — Sun, 24 Jan 2021 17:35:41 +0000

This little series is all about expanding our definition of "responsive design" to consider more than just screen size. Last time we talked about using CSS media queries to automatically shift between light and dark display modes. Today, let's talk about another part of the environment we can respond to: the user's location.

Location-Based Responsiveness

Responsiveness is all about embracing the context that surrounds our users and their devices. The most urgent responsive concerns are undoubtedly the wide variety of screen sizes that those devices might employ, but there's a lot more context beyond screen size that designers can respond to. What if our responsive designs could respond not just to screen size, but to the user's location as well?

Geolocation

To achieve this, we can use the Geolocation API. This API is available only in secure contexts—HTTPS—in some supporting browsers, and yet it provides a super easy way to read a device's location. Today we'll look at two different geolocation approaches: one to check location a single time, and one to watch location continuously.

How to Get the User's Location Once

Let's start with a blank HTML page to try getting device location. We'll just add a button that will trigger the location check. Something like this:

<button id="get-location">Get Location</button>

We want to be able to click this button and get location data in the console. To achieve this, we'll write three JavaScript functions. The first is the function we'll stick to our button via event listener. We can access the Geolocation API at navigator.geolocation. Inside our first function, we'll check whether the Geolocation API is supported by testing navigator.geolocation, and if it is supported, we can get our location data using navigator.geolocation.getCurrentPosition().

function getLocation() {
  if (!navigator.geolocation) {
    console.log('Geolocation API not supported by this browser.');
  } else {
    console.log('Checking location...');
    navigator.geolocation.getCurrentPosition(success, error);
  }
}

The Geolocation API provides getCurrentPosition() so we can quickly locate users. This function will get the job done quite easily, but you might have noticed that it expects two arguments, called success and error in this example. These are the two other functions we need to write.

The first argument should be a function to call if geolocation is successful. We need to carve out an argument in this function, too; this argument is called position and it's how the browser will pass the geolocation results back to us.

function success(position) {
  console.log(position);
}

The error() function will only be called if the geolocation fails. Hopefully we won't even hit this function.

function error() {
  console.log('Geolocation error!');
}

Don't forget to attach getLocation() to the button by adding a click event listener!

document.getElementById('get-location').addEventListener('click', getLocation);

Now we have all the JavaScript we need to grab some location data. If we try it out by clicking the Get Location button, it'll ultimately result in a GeolocationPosition object being printed in the console. This object is a packet of the results from our geolocation check. Its keys include a timestamp and another object called coords that contains data like latitude, longitude, and so on. The data found in coords is what we can work with to create a responsive design that consider's the user's location.

We can use the console to poke around the coords object or we can directly log values from coords to the console in success().

function success(position) {
  console.log('Latitude:', position.coords.latitude);
  console.log('Longitude:', position.coords.longitude);
}

Note!
Latitude traditionally precedes longitude. If you explore location APIs on the web you might see latitude and longitude out of order, but just remember they should usually appear in alphabetical order!

How to Continuously Watch the User's Location

Instead of getting the user's location once, we can also watch their location continuously. Using the watchPosition() function we can set up a handler function that will be called each time geolocation updates. We need to pass in a function to call when a new location is successfully returned, so let's reuse our success() function.

This example is pretty easy to set up for our purposes. We can just add one line of JavaScript:

navigator.geolocation.watchPosition(success);

Now we can continuously get location data! This comes with the processing, data, and energy overhead that you'd expect, but maybe you're as pleased as I was to learn how simple it is to start working with the Geolocation API.

A Word of Caution

This series offers practical examples illustrating how to add different kinds of responsiveness, but it's also a conversation starter; a brain teaser. It's worthwhile to look at a user's location as part of the context they bring to our app or website, especially as a mental exercise, but devices will need to get permission to check location, and this will prove a UX wrinkle.

It's really not a good idea for our users to be faced with a dialog in the browser immediately upon arriving at our site, however the kind of location-based responsiveness that we used as an example above will trigger those dialogs to get permissions for the location check. That's not ideal. Putting this stuff into practice will require a more thoughtful approach, or at least the deferral of location responsiveness away from the initial landing experience. Nevertheless, I think you'll find the expansion of the commonly held definition of responsiveness to include location is an exciting addition to your web design playbook.

Is Angular Dead?

Nathan Pasko — Sun, 17 Jan 2021 21:55:56 +0000

It's been almost two years since I've used Angular. The last thing I used it for is a web app that is likely to be revived this year. It feels like I haven't heard much about Angular these past couple years, and I know I've seen complaints about the latest updates to the framework slide across my feed.

So is Angular still in the ring? Should I polish up my ng skills and bring old projects up to speed? Or should I keep learning React like I was throughout 2020 and let Angular drift away?

How to Write CSS for Both Light & Dark Display Modes

Nathan Pasko — Sun, 10 Jan 2021 21:52:30 +0000

This is the beginning of a little series about responsive design and some cool new ways to make your web projects—sites, apps, games—more responsive. In this article we'll check out a quick and easy way to use CSS media queries to check if the client device is using light or dark display mode, and set different styles for light and dark.

Why Light/Dark Mode Shifting is Cool

Responsive web design has accelerated to meet the needs of an ecosystem full of different web-capable devices. Designers no longer take screen sizes for granted, so the web has become more fluid as designers create sites that adapt to context. Responsiveness dovetails with the industry standardization of "Dark Mode"—that is, the capability of your OS to switch between a light- or dark-toned UI.

I was converted to Dark Mode fandom when I discovered I could set my phone and laptop to switch automatically from light to dark at sunset (and back to light at sunrise).

Tapping into users' light/dark mode setting and presenting a version of our site to match is another powerful form of responsiveness. From a design standpoint, an OS with these display features is an invitation to create more fluid images and brand identities; the proliferation of these features encourages designers to express the same identity using multiple color schemes, where in the past they might've stopped at one. This makes media more comfortable for users and helps images, websites, apps, and brands feel more intelligent and less static.

We can use a CSS media query to set up alternate styles for when users switch their client device between light and dark display modes. Now our site is responsive not only on a basis of screen size, but a basis of color scheme as well. Remember, responsiveness is all about responding to the context that different users and situations bring to our site.

How to Use `prefers-color-scheme` to Set Styles Specific to Light or Dark Mode

Here's the media query that we can use to tap into the display color scheme, light or dark:

@media (prefers-color-scheme: dark) {
  /* These styles will be applied only in dark mode */
}

@media (prefers-color-scheme: light) {
  /* These styles will be applied only in light mode */
}

As you can see, CSS gives us everything we need with media queries. Let's whip up a very basic example to test it out.

Let's start by making a blank HTML page. We just need to add some text to demonstrate the change from light to dark.

<h1>Light vs. Dark</h1>
<h2>Testing</h2>
<h2>Testing</h2>

Similar to the way, in working with screen width, we write base styles assuming a very narrow breakpoint and use media queries to adapt to progressively wider breakpoints, we will write some CSS assuming light mode to start. Then we use the prefers-color-scheme: dark media query to write corrective styles for dark mode.

/* Default styles */
html {
  /* Black text on a white background */
  color: black;
  background: white;
}

/* Style changes to use in dark mode */
@media (prefers-color-scheme: dark) {
  html {
    /* White text on a black background */
    color: white;
    background: black;
  }
}

If we use that CSS on our page and then switch between light and dark display modes... voilà!

This example just inverts text color and background color on our page. That's a basic and pretty common application of light/dark mode responsiveness, but it's pretty useful. Like the other building blocks of CSS, the possibilities this provides are endless.

Go Make Something More Responsive

The changes between light and dark mode can be subtle if diluting a brand or aesthetic is too risky, or they can be drastic, putting full emphasis on readability or low-light operation. Responsive design is all about expanding a design's preparedness and creating opportunities for a more specific and intuitive user experience. Using the prefers-color-scheme query will help you invest more in your designs and serve users a more engaging experience.

Any advice on how to get the most out of wireframing?

Nathan Pasko — Mon, 04 Jan 2021 16:06:20 +0000

Does anybody have some advice to share on the wireframing process? What are your tips and tricks to get the most out of wireframing and keep the process focused? I work with a small team of designers and developers and it's time we took more advantage of this practice.

Thanks devs!