A pretty typical beginner dilemma: you’re completely stumped by an issue with your code. You’ve tried multiple solutions, but nothing is working. You’re stumped.

But, you’re also worried about reaching out for help because you don’t want to reach out too often. What can you do?

Well, if you’re in this situation, I hope firstly that you have someone more experienced you can reach out to. That helps tremendously. Mentors can be found at local usergroups (you can check meetup to find usergroups in your area) or even online using coding forums.

If you’ve already secured a mentor, you’re ahead of the curve! But if you’re worried about asking too many questions, it can be tough to know when you should keep working on a problem versus when it’s been long enough and you should ask.

Some people advocate a time-based system. Something like, “don’t spend more than X hours on a problem.” I propose another system – one that isn’t time-based.

A system that has worked for me in the past is to try three things before asking any question. It’s important to also write down what you’re trying and the result you’re getting.

This has multiple benefits. Firstly it gives you an exact template to use if you aren’t sure how to ask your question. You can simply tell your mentor that you tried X and then Y happened, but you were hoping for Z outcome. This will help your mentor because they can review what you’ve been attempting and put themselves into your mindset. They’ll understand better where your confusion lies and be able to explain the issue – and hopefully the solution – in a way you’ll understand.

The other benefit is, in my opinion, even more important and beneficial. I’ve found this method very helpful because usually the act of trying something and documenting the outcome will give you something to search for online. That, in turn, will point you in another direction – quite possibly the direction you need to go! Oftentimes I didn’t even need to ask for help because this method would lead me to an answer, or at the very least a different problem. Often when you’re stuck on one problem, getting a different error will feel like progress!

One last point I want to make is how important your mentor is. A good mentor will be able to tell you to take a break and come back to the issue or tell you to keep working on a problem because you’re close. They won’t belittle your attempts or make you feel stupid because you didn’t come to the answer on your own.

It’s perfectly fine, even encouraged, to be conscientious of someone else’s time. However if you feel like you can’t approach someone because they make you feel less than, go find a new mentor.

I hope this helps. If you have questions, feel free to tweet me!


Service Workers are a super cool bit of tech that allows your user’s browser to cache files and assets. Why is this so cool? Because eventually your user will lose connection. What happens then? Without something to bridge the gap between the time user loses connection and the time they regain connection, your user is just out of luck.

But no more! Service workers are here to help bridge the gap (at least in certain browsers). With the browser caching the files and images you choose, your user can continue using your site until the connection comes back.

Note: Service workers on their own cannot cache AJAX requests. I’ll talk about solutions for caching API requests in a later blog post.

To start using a service worker you’ll need some JavaScript for your application, as well a service worker file. I’ve created a demo Let’s get started!

Step One: Register your service worker

Registering your service work is very simple. The code looks like this:


if(navigator.serviceWorker) {
  navigator.serviceWorker.register('service-worker.js');
}

The above code would go in your application’s JavaScript file. All it’s doing is letting the browser know to go ahead and register that service worker. Be sure to wrap your register function in an if-statement because cross-browser support for service workers isn’t quite there yet.

Step Two: Install your service worker

This code lives in your service-worker.js file:


// service worker
self.oninstall = function() {
  caches.open('cash').then(function(cache) {
    cache.addAll([
      'index.html',
      '/img/my-image-name.jpg'
    ]);
  });
};

Service workers expose certain events, including oninstall and fetch. The method above opens a cache in the browser and adds files to the cache. This way, if your app goes offline, the browser already has files and can load them in. Another benefit of this is speeding up your site’s response time. Since the files are cached, the browser no longer needs to serve files from a remote server. This ends up giving your users a great performance increase.

Step Three: Specify what happens on fetch

This code also lives in your service-worker.js file:


// fetch function
// called when connection is lost
self.onfetch = function(event) {
  // this will grab the very last request
  event.respondWith(caches.match(event.request));
};

This is the function that will be called when your files need to be fetched. When files are cached, they are saved like a stack. Older caches are closer to the bottom, with newest caches being on top. The above function will grab the latest cache and send that to the browser where it can be rendered.

And with that, you’re done! You can grab this code and run it in a server (I like to use https-server). Once you stop the server, you can refresh the page and see your site is still there! Pretty cool, huh?

If you want to learn more about service workers, I hope you’ll head over to serviceworkerbook.com and sign up for my mailing list, and follow me on Twitter! You’ll be the first to know when my book, ‘Let’s Take This Offline’ is out!


The very nice folks who run FreeCodeCampOKC invited me to give a presentation over Intro to JavaScript. I’m so glad they did, and I had a blast! I love talking about, and teaching about, JavaScript. JavaScript is a great programming language to begin with because it’s so accessible to run – all you need is a browser!

I got a question at the end about reference types in JavaScript, and that question got me thinking.

Most types in JavaScript are value types. This means that each variable has it’s own value. Copying variables with value types is a breeze. It just looks like this:


var a = "Hello World";
var b = a + "!";

console.log(a); // Hello World
console.log(b); // Hello World!

JavaScript objects on the other hand are not value types – they are reference types. A reference type means that the variable (in our case, an object) points to a specific place in memory. How is this so different from a value type?

Reference types don’t copy the same way. Because they point to a place in memory when you copy an object (var objB = objA) you end up with two variables pointing to the same place in memory. So changes to either variable will affect both variables.

Well, we know that is true for objects … but what about arrays?

In JavaScript, array is not actually a type, instead array is an object. So it turns out that you’ll have the same problem with arrays.

Check it out!


var objA = {
	name: 'Rey',
  age: '26',
  occupation: 'Jedi'
};

var arrA = ['Anakin', 'Padme', 'Luke', 'Leia', 'Ben'];

function mutateObj(tmpObj) {
	var tmp = tmpObj;
  tmp.name = 'Finn';
  return tmpObj;
}

function mutateArr(tmpArr) {
	var tmp = tmpArr;
  tmp[0] = 'Obi-Wan';
}

var objB = mutateObj(objA); // we now have two matching objects
var arrB = mutateArr(arrA); // we now have two matching arrays

You can check out my demo here.

In my next post, I’ll show you how you can copy arrays and objects into a new variable. This way, you won’t have issues with changes on your new object or array affecting your old one.

Questions? Tweet me!


I was fortunate enough to spend a weekend at Offline Camp in Oregon this month. It was wonderful!

I’ve been really passionate about offline accessibility for a long time, although I’ve only recently learned it has a name: Offline First. Right around the time I learned that, I also had the opportunity to attend Offline Camp and meet a whole bunch of like-minded people. Spending the weekend with lots of socially-conscious individuals and brainstorming ways Offline First can help underprivileged individuals is one of the best ways to spend a weekend.

I’ve talked about the importance of reliable internet access here and here, but I’ll briefly summarize the idea of Offline First.

Offline First is a practice which considers the inevitable – what will happen when your web app goes offline? Offline First knows that your app will at some point go offline, so the idea is to put technology into place to help when that happens.

Additionally, there are many people who live their lives offline. In a world of online services, how can the needs of underprivileged people be met? Offline First attracts many people who are interested in how to help with this problem, and at camp we spent a lot of time talking about what we can do to help.

We talked about using Service Workers to cache online pages in the user’s browser. This would help users move from an online to an offline state, and back again. And we also talked about the future of Electron and Service Workers and how these two technologies work to achieve the same goals. Mesh networks came up in discussion time and again as a potential solution for providing internet access in remote locations.

One of my favorite discussions was talking about the economics of Offline First. I genuinely believe that the only way we’ll get Offline First into the wider consciousness of developers is if we can make a solid business case for it. We focused on making a business case for this and I’m super excited about what comes next from that.

We weren’t focused on Offline all the time though. Some of the best parts were from Passion Talks. Passion Talks are short, five-minute talks about anything you’re passionate about. I really enjoyed getting to know my fellow campers better through hearing about their interests.

Overall, I’d say attending Offline Camp was one of the best decisions I made in 2017. I learned so much, and I’m so hopeful for the future of offline. Many thanks to the organizers who put the camp on: Steven, Gregor, Bradley, and Teri. I know putting camp on was a lot of hard work, but I so appreciate you for doing it.

Note: Offline Camp offers scholarship opportunities for campers. If you’re able to help, it could be life-changing to the scholarship recipient. If you find that you’d like to attend camp, but need assistance, I would highly recommend contacting the organizers.


More than 10 percent of Americans are without home internet. As such, it’s really important to be considerate of users with inconsistent internet. A user is without internet is effectively stuck on an island, unable to communicate with the outside world.

One of the simplest things we can do is check for network connection. To do this we can use: navigator.onLine. This function – which is built into the JS spec and also has great cross-browser compatibility – returns a boolean value based on whether or not the user has a network connection. It might look like this:


if(navigator.onLine) {
  console.log("User is online!");
} else {
  console.log("User is not online. :(");
}

This is really handy because we can test for this before running any ajax calls and offer the user a much nicer experience because they won’t lose connection and suddenly hit a bunch of connection errors.

We can set up an event listener and continuously monitor network connection.


window.addEventListener('offline', function(event) {
  console.log("We are offline! :(");
});

window.addEventListener('online', function(event) {
  console.log("We are online! :)");
});

While no network connection will mean you are not on the internet, a true value can be misleading. Just because you are on a network doesn’t mean you have internet connection – for instance you can be on an internal network but the network doesn’t have an external internet connection. This might return true.

So what can we do to test if our true is actually true? If we get true, we can test if we can access an image.


fetch('some/img/url/here').then(
    function(response) {
      console.log(response);
    })
    .catch(function(err) {
      console.log(err);
    });

And when we look at the response, we can see the status code. If you have no connection, the catch will return your error with something like TypeError: Failed to fetch.

And there you have it! You can check for network connection with navigator.onLine, and to be sure you are truly online, you can use fetch to pull an image and check the status code.

If you want to learn more about offline tech, I hope you’ll head over to serviceworkerbook.com and sign up for my mailing list, and follow me on Twitter! You’ll be the first to know when my book, ‘Let’s Take This Offline’ is out!