Hacker News Reader

Comment by JoeCortopassi | Hacker News Reader

Very cool library! The one thing all of these type of things lack (e.g. this, dojo.dialog()) is that they are non-blocking to the execution thread, unlike alert()/confirm()/prompt(). I know it's not their fault, javascript doesn't allow this natively, but i feel like that would be immensely useful for general user input, form validation and the like. Yes, I am aware that it can be done currently through workarounds, I'm just saying that allowing certain native objects to be blocking upon further user input, would be immensely useful and save code readability

EDIT: Care to explain why I'm getting downvoted? Said nothing offensive, and I'm clearly on-topic.

View on HN

I don't know why you were being downvoted but I don't think -anything- should ever be able to block the execution thread. I never liked the fact that you could force lock a user by spamming alert/confirm boxes and I saw this effect as a bug of the default behavior of the operating system over a feature of the browser.

I used to work in applications that require you to do -as much as possible- to keep the window open. This isn't for spam reasons, it is because we did assessment and you really, really didn't want someone closing half-way through an assessment, especially one that is timed. You also don't want to freeze the timer because you might leave the user an opportunity to cheat (close window, research, relaunch assessment, repeat).

So this was real example of something that really should be single-execution. However, even with all the popups, checks, refresh-push-forward, launch-window-on-exit hacks we tried we STILL got users lost out of the system. Not only that but we wound up annoying/angering/confusing 1000 users for every 1 user it helped.

shrug

YMMV, but I believe 99.999% of all issues can be solved with user/session caches and clear wording over blocking the execution thread.

I'm not going to down- or up-vote you. But wanting something to block a UI execution thread is...novel. Thousands of man-years have been spent creating non-blocking systems for the simple reason that it opens up a lot of options.

But I guess in some circumstances having a UI-updating callback called when a modal dialog is up might be a little confusing for the user. And setting (and checking!) a global everywhere is rather messy. So I see your pain.

Ha, one way I just thought of to get frozen behavior is to take a snapshot of the screen, then overlay a canvas element with that image. As an added bonus you can do some transform on the image to make the effect look more native. When the dialog box goes away, the canvas goes away, and your updated state is presented as if it just executed.

Looking at the other comments, I think there might be a misunderstanding.

The last thing you want is a UI blocking popup like alert() that, at least in browsers like Firefox and IE, effectively lock the entire browser from doing anything, which is a terrible anti-pattern in multi-tabbed browsers. Chrome did it right, at least with the HTTP authentication prompt, to make the UI block on a per-tab basis and have the prompt window not be a top-level-window-manager-managed-block-the-entire-app modal dialog.

I think a case can be made to have functionality that shows a dialog that is modal within the context of the page it is on, not modal for the entire browser. The former would be useful for the cases you outline, the latter is the bane of users everywhere.

(forgive me if I'm misrepresenting the current state of browsers other than Chrome when it comes to modal dialogs like alert(), I don't use them much; I think everyone can get what I'm saying despite that)

FWIW, Firefox handles alert() much better than Chrome does. In Firefox, you can navigate away from the page, and switch tabs. Chrome won't let me open a new tab, and keeps the alert in front of other pages.

This may be platform dependent. I was just stuck in a FF alert that was a modal top-level window manager managed window the other day on Linux.

There are still a number of types of dialogs that are not tab-modal. See https://bugzilla.mozilla.org/show_bug.cgi?id=616843 and the bugs it depends on. alert() should be tab-modal content, though, and is for me.

IMHO, no modern JS developer should ever need to create a blocking alert or prompt; the reason the native alert or prompt functions block is because, well, they are not designed for what the web is today.

Just out of curiosity, if you had a web app like Gmail, and your user accidentally went to close their browser window with an unsaved email half done, how would you plan on warning them without blocking events?

Save it in drafts and notify them when they come back.

So Facebook and Twitter should also save drafts of posts you were going to make? What if latency is non-trivial, or connection is lost? Do I also want to send ajax posts for drafts every second to ensure that as little as possible is lost? A lot of this is mitigated by a very simple

  confirm("Are you sure you want to leave?");

Twitter actually does save drafts in localStorage.

Yeah but for all the times when I really do want to leave, now I have to annoyingly click "Yes" in a dialog I didn't expect in the first place.

I like the localStorage solution for drafts much better.

You use the onbeforeunload event, which doesn't block the event thread. (EDIT: actually it does, just not while JS code is executing, unlike alert().)

In fact, the HTML5 spec permits browsers to disregard the normal blocking behavior of alert()/confirm()/prompt() (making them no-ops) while this event is being handled: https://developer.mozilla.org/en-US/docs/DOM/window.onbefore... the dialog box is open

I managed to break that link somehow and can no longer edit it, here's the correct one: https://developer.mozilla.org/en-US/docs/DOM/window.onbefore...

Are you saying it would be good for them to block? Why?

When they execute, they run a callback with the input provided. Inside that callback, do whatever you need to do that requires some input.

Confirm and prompt are typically used to indicate a decision by the user. Natively, these functions stop javascript execution to wait for the users input, so that it knows what to do, but do not allow for customization. Non-native libraries do not have this ability to prompt the user for input, then wait for their response, before continuing the execution of that script. Callbacks are one way to circumvent this issue, but introduce new issues with scope and readability.

All I'm trying to say is that allowing custom defined objects to have the ability to block execution can be very handy in certain instances. I by no means was criticizing the alertify.js library

Sometimes it's just easier to have linear code with some blocking than to create an entire state machine. Yes there are libraries that get close to this. No, it's still not the same.

You can have linear code without blocking - it's exceptionally common in the node world.

async.waterfall([ function getInput(){...}, function checkInput(){...}, function submitInput(){...}, ], function finally(){})

Each of the functions takes a callback, and returns err (if any) and output. If a callback returns err, it jumps to finally where you say what failed.

This is odd when you first get started with async, but it's really easy to visualize.

Think of a production line, with a number of different workers doing different stuff. If one of them gets a dud part, it throws it away.

I get it. I do plenty of async programming. But, at the end of the day, no matter how nice you think the async.waterfall mess is, sometimes you just want to block. Sometimes it turns out that that is the right pattern. I've written dozens of async apps, much to the chagrin of co-workers who hate anything resembling async. I think I'm qualified to know that sometimes I get to a bit of code that sure would be nice with a simple blocking call.

What you want isn't blocking the UI thread but a stack of states where each state defines the current behaviour of the elements, with bonus points if states can be composed together.

There is a method called `showModalDialog` in modern browsers that was supposed to be used for exactly that, blocking interaction. Unfortunately it doesn't actually work consistently.

https://developer.mozilla.org/en-US/docs/DOM/window.showModa...

Reply on news.ycombinator.com