Here’s a tailored answer to your question. It will still be 90% long explanation why you can’t get around async, but bear with me — it will help you in general. I promise there is something pertinent to chrome.storage in the end.

Before we even begin, I will reiterate canonical links for this:

• After calling chrome.tabs.query, the results are not available
  (Chrome specific, excellent answer by RobW, probably easiest to understand)
• Why is my variable unaltered after I modify it inside of a function? – Asynchronous code reference (General canonical reference on what you’re asking for)
• How do I return the response from an asynchronous call?
  (an older but no less respected canonical question on asynchronous JS)
• You Don’t Know JS: Async & Performance (ebook on JS asynchronicity)

So, let’s discuss JS asynchonicity.

Section 1: What is it?

First concept to cover is runtime environment. JavaScript is, in a way, embedded in another program that controls its execution flow – in this case, Chrome. All events that happen (timers, clicks, etc.) come from the runtime environment. JavaScript code registers handlers for events, which are remembered by the runtime and are called as appropriate.

Second, it’s important to understand that JavaScript is single-threaded. There is a single event loop maintained by the runtime environment; if there is some other code executing when an event happens, that event is put into a queue to be processed when the current code terminates.

Take a look at this code:

var clicks = 0;

someCode();
element.addEventListener("click", function(e) {
  console.log("Oh hey, I'm clicked!");
  clicks += 1;
});
someMoreCode();

So, what is happening here? As this code executes, when the execution reaches .addEventListener, the following happens: the runtime environment is notified that when the event happens (element is clicked), it should call the handler function.

It’s important to understand (though in this particular case it’s fairly obvious) that the function is not run at this point. It will only run later, when that event happens. The execution continues as soon as the runtime acknowledges ‘I will run (or “call back”, hence the name “callback”) this when that happens.’ If someMoreCode() tries to access clicks, it will be 0, not 1.

This is what called asynchronicity, as this is something that will happen outside the current execution flow.

Section 2: Why is it needed, or why synchronous APIs are dying out?

Now, an important consideration. Suppose that someMoreCode() is actually a very long-running piece of code. What will happen if a click event happened while it’s still running?

JavaScript has no concept of interrupts. Runtime will see that there is code executing, and will put the event handler call into the queue. The handler will not execute before someMoreCode() finishes completely.

While a click event handler is extreme in the sense that the click is not guaranteed to occur, this explains why you cannot wait for the result of an asynchronous operation. Here’s an example that won’t work:

element.addEventListener("click", function(e) {
  console.log("Oh hey, I'm clicked!");
  clicks += 1;
});
while(1) {
  if(clicks > 0) {
    console.log("Oh, hey, we clicked indeed!");
    break;
  }
}

You can click to your heart’s content, but the code that would increment clicks is patiently waiting for the (non-terminating) loop to terminate. Oops.

Note that this piece of code doesn’t only freeze this piece of code: every single event is no longer handled while we wait, because there is only one event queue / thread. There is only one way in JavaScript to let other handlers do their job: terminate current code, and let the runtime know what to call when something we want occurs.

---

This is why asynchronous treatment is applied to another class of calls that:

• require the runtime, and not JS, to do something (disk/network access for example)
• are guaranteed to terminate (whether in success or failure)

Let’s go with a classic example: AJAX calls. Suppose we want to load a file from a URL.

• Let’s say that on our current connection, the runtime can request, download, and process the file in the form that can be used in JS in 100ms.
• On another connection, that’s kinda worse, it would take 500ms.
• And sometimes the connection is really bad, so runtime will wait for 1000ms and give up with a timeout.

If we were to wait until this completes, we would have a variable, unpredictable, and relatively long delay. Because of how JS waiting works, all other handlers (e.g. UI) would not do their job for this delay, leading to a frozen page.

Sounds familiar? Yes, that’s exactly how synchronous XMLHttpRequest works. Instead of a while(1) loop in JS code, it essentially happens in the runtime code – since JavaScript cannot let other code execute while it’s waiting.

Yes, this allows for a familiar form of code:

var file = get("http://example.com/cat_video.mp4");

But at a terrible, terrible cost of everything freezing. A cost so terrible that, in fact, the modern browsers consider this deprecated. Here’s a discussion on the topic on MDN.

---

Now let’s look at localStorage. It matches the description of “terminating call to the runtime”, and yet it is synchronous. Why?

To put it simply: historical reasons (it’s a very old specification).

While it’s certainly more predictable than a network request, localStorage still needs the following chain:

JS code <-> Runtime <-> Storage DB <-> Cache <-> File storage on disk

It’s a complex chain of events, and the whole JS engine needs to be paused for it. This leads to what is considered unacceptable performance.

---

Now, Chrome APIs are, from ground up, designed for performance. You can still see some synchronous calls in older APIs like chrome.extension, and there are calls that are handled in JS (and therefore make sense as synchronous) but chrome.storage is (relatively) new.

As such, it embraces the paradigm “I acknowledge your call and will be back with results, now do something useful meanwhile” if there’s a delay involved with doing something with runtime. There are no synchronous versions of those calls, unlike XMLHttpRequest.

Quoting the docs:

It’s [chrome.storage] asynchronous with bulk read and write operations, and therefore faster than the blocking and serial localStorage API.

Section 3: How to embrace asynchronicity?

The classic way to deal with asynchronicity are callback chains.

Suppose you have the following synchronous code:

var result = doSomething();
doSomethingElse(result);

Suppose that, now, doSomething is asynchronous. Then this becomes:

doSomething(function(result) {
  doSomethingElse(result);
});

But what if it’s even more complex? Say it was:

function doABunchOfThings() {
  var intermediate = doSomething();
  return doSomethingElse(intermediate);
}

if (doABunchOfThings() == 42) {
  andNowForSomethingCompletelyDifferent()
}

Well.. In this case you need to move all this in the callback. return must become a call instead.

function doABunchOfThings(callback) {
  doSomething(function(intermediate) {
    callback(doSomethingElse(intermediate));
  });
}

doABunchOfThings(function(result) {
  if (result == 42) {
    andNowForSomethingCompletelyDifferent();
  }
});

Here you have a chain of callbacks: doABunchOfThings calls doSomething immediately, which terminates, but sometime later calls doSomethingElse, the result of which is fed to if through another callback.

Obviously, the layering of this can get messy. Well, nobody said that JavaScript is a good language.. Welcome to Callback Hell.

There are tools to make it more manageable, for example Promises and async/await. I will not discuss them here (running out of space), but they do not change the fundamental “this code will only run later” part.

Section TL;DR: I absolutely must have the storage synchronous, halp!

Sometimes there are legitimate reasons to have a synchronous storage. For instance, webRequest API blocking calls can’t wait. Or Callback Hell is going to cost you dearly.

What you can do is have a synchronous cache of the asynchronous chrome.storage. It comes with some costs, but it’s not impossible.

Consider:

var storageCache = {};
chrome.storage.sync.get(null, function(data) {
  storageCache = data;
  // Now you have a synchronous snapshot!
});
// Not HERE, though, not until "inner" code runs

If you can put ALL your initialization code in one function init(), then you have this:

var storageCache = {};
chrome.storage.sync.get(null, function(data) {
  storageCache = data;
  init(); // All your code is contained here, or executes later that this
});

By the time code in init() executes, and afterwards when any event that was assigned handlers in init() happens, storageCache will be populated. You have reduced the asynchronicity to ONE callback.

Of course, this is only a snapshot of what storage looks at the time of executing get(). If you want to maintain coherency with storage, you need to set up updates to storageCache via chrome.storage.onChanged events. Because of the single-event-loop nature of JS, this means the cache will only be updated while your code doesn’t run, but in many cases that’s acceptable.

Similarly, if you want to propagate changes to storageCache to the real storage, just setting storageCache['key'] is not enough. You would need to write a set(key, value) shim that BOTH writes to storageCache and schedules an (asynchronous) chrome.storage.sync.set.

Implementing those is left as an exercise.