0

Some observations. Certain native javascript functions are blocking. Such as the alert box. If browsers allowed users to code other blocking functions they could be no more malicious than breaking their own pages. So I don't believe that this is a security issue.

Enabling blocking functions may introduce bad design patterns. Perhaps the goal is simply to discourage sloppy design, since javascript is decidedly async. But that is a fairly opinionated design concept to build into the language itself.

The question: Is there any historical or technological reason why it is not possible to build another function? Or conversely, am I mistaken, is there some way to make other functions blocking?

Suggested Design Pattern. I think it is worth showing what I mean by a blocking function. The normal design pattern is to do:

doSomethingThatMayTakeTime();
function doSomethingThatMayTakeTime(){
     //Something that takes time
     callback();
}

function callback(){
    //Do something you only want to do once the first function is complete
}

But there are many places in my code where there is no possible code that I want to be executed until the doSomethingThatMayTakeTime function executes. In this use scenario, why can we say:

doSomethingThatMayTakeTime();
//NextLineOfCode

function doSomethingThatMayTakeTime(){
     // Blocking Code -- Prevent execution of any code outside this function until this function returns/executes its last line
     //Something that takes time
}

As you can see in this specific use case one would not be crazy for thinking this is a cleaner approach. And while this may seem specific, I run across this sort of situation relatively frequently. One simple example occurs when replacing the alert box with other modal boxes.

COMisHARD
  • 867
  • 3
  • 13
  • 36
  • I'd say that for the environment javascript was designed for there are nearly always other functions that can be executed, namely event handlers for UI actions. – mrmcgreg Mar 10 '17 at 16:03
  • 2
    "there is no possible code that I want to be executed". Your code - maybe. But browser runs a lot of other JS at the same time. Your code __has__ to play nice. – Sergio Tulentsev Mar 10 '17 at 16:04
  • 2
    [What topics can I ask about here?](https://stackoverflow.com/help/on-topic): "_but if your question generally covers **a specific programming problem**, or a software algorithm, or software tools commonly used by programmers; and is a practical, answerable problem that is unique to software development then you’re in the right place to ask your question!_" ;) – Andreas Mar 10 '17 at 16:05
  • 2
    FWIW, `alert` is not part of JavaScript/ECMAScript. It's an API provided by the browser (which can do anything it wants to do). However, ECMAScript also doesn't explicitly "forbid" blocking functions. And aside from Promises, it doesn't actually specify async functions. The *browser* provides the async API functions (according to the HTML standard). – Felix Kling Mar 10 '17 at 16:07
  • @Andreas. That is being quoted out of context. You are quoting an exception to an exception. "Stack Overflow is for professional and enthusiast programmers, people who write code because they love it. We feel **the best Stack Overflow questions have a bit of source code** in them, **but if your question generally covers**…then you’re in the right place to ask your question!" – COMisHARD Mar 10 '17 at 16:08
  • @SergioTulentsev has the answer. Javascript should be able to be run by an engine that is *also running other things* - again, namely UI and browser-oriented functionality. – Gershom Maes Mar 10 '17 at 16:08
  • So it sounds like the answer is, because it stops all other JS from running in the browser and therefore it is up to the browser to expose API's that allow blocking? – COMisHARD Mar 10 '17 at 16:09
  • 1
    Every quote is out of context. That doesn't mean it's inapplicable. For instance, the [Help Center](https://stackoverflow.com/help/dont-ask) is fairly explicit about what not to ask: _"You should only ask practical, answerable questions based on actual problems that you face. Chatty, open-ended questions diminish the usefulness of our site and push other questions off the front page."_ (Oh, and your quote of the "context" for Andreas's quote is incomplete; the "..." that you omitted starts with _"a specific programming problem"_. Your post is not a good match to any of the categories.) – Ted Hopp Mar 10 '17 at 16:17
  • 1
    A bit of history, read this: http://stackoverflow.com/questions/29883525/i-know-that-callback-function-runs-asynchronously-but-why/29885509#29885509 (scroll down to the part I describe the Event Loop). Then read this for why it's a good idea to keep it that way: http://stackoverflow.com/questions/29981941/why-is-async-programming-faster/30006032#30006032. Also this for how this ends up being popular as a high performance style of programming on the server: http://stackoverflow.com/questions/34855352/how-in-general-does-node-js-handle-10-000-concurrent-requests/34857298#34857298 – slebetman Mar 10 '17 at 16:57

3 Answers3

2

is there some way to make other functions blocking?

The functions themselves, all of them are blocking. Put an infinite loop in and observe your browser hang.

It's the I/O that is async. Don't confuse the two.

Sergio Tulentsev
  • 226,338
  • 43
  • 373
  • 367
1

Do you mean something like this? ANY function that does anything for a long time will freeze your browser (no event handling until it finishes), I think you don't understand the single-threaded behavio(u)r of Javascript:

$('#blocking').click(function() {
  var d= new Date().getTime();
  while(new Date().getTime() - d < 10000) {
    var a=1;
  }
});
<script src="https://ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min.js"></script>
<button id="blocking">Block this tab for 10 seconds</button>
Pablo Lozano
  • 10,122
  • 2
  • 38
  • 59
0

When you run a blocking function, it's not only your code on the page that is blocked. It is the main thread of the entire JavaScript engine. If the user clicks on a button, tries to type into an input field, scrolls the page, or does anything that generates events that the JS engine is supposed to process, nothing will happen until the blocking function returns.

This is a Bad Thing. To the user, it's indistinguishable from the browser crashing.

Note that an alert box isn't blocking in the same way. Yes, the main event handling thread is blocked, but not all event handling. The dialog box takes over all event handling and processes it in a responsive manner. Think of it this way: popping up an alert temporarily changes what's considered an event; it doesn't block events at all.

You say, "javascript is decidedly async". I don't know what you mean by that, but it's decidedly untrue as a blanket statement. (See this thread, for instance.) You need to make a special effort to create asynchronous activity. See this documentation for more info.

Community
  • 1
  • 1
Ted Hopp
  • 232,168
  • 48
  • 399
  • 521