Alertify.js | Hacker News Reader

Alertify.js

github.com

300 pointsgoogletron75 comments

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.

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.

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...

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.

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.

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.

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...

Since nobody seems to have noticed yet: bonus points for using native methods and not using JQuery.

Indeed, I like the fact that it doesn't have dependencies. And is using html5 tags which is useful too.

Pretty slick, animation-wise. If I could make one design-layman suggestion...the thick, black border belies the unobtrusiveness of the plugin. Maybe a lighter, thinner border would be a better fit for the use-case of this plugin?

Making the border any less obtrusive might make the notification blend into the page too much.

looks like it's using class="alertify alertify-show alertify-prompt"

you should be able to override any of these to your liking

Yeah, I meant for demo, first-impression purposes. I know it's just a easily-changed visual tic once a developer decides to implement it...but might as well entice as many people as people as possible.

You can go into the css and for the .alertify {} selector

Remove the border{...} values and change box shadow to:

box-shadow {box-shadow: 0 0px 60px 30px #666;}

It's rather annoying it's modal but leaves most of the page visible and unresponsive to clicks. Maybe dim the background slightly?

Here's the examples link: http://fabien-d.github.com/alertify.js/

I love that someone already made a pull request to update the readme with it.

One concern is the ordering of buttons. Windows users will be used to OK/Cancel whereas on OS X, etc Cancel/OK is the norm. I wonder if this is something this library should handle?

This looks beautiful. But I'm curious, do users no longer expect/like their platform's native dialogs for these things?

The native alert is very hard to customize and extremely bare boned.

Not to mention that the second I see a native alert my heart rate increases 10 fold.

Only thing worse are those "Are you sure you want to leave this page?" modals. Those cause me to go into fits of ctrl+w- smashing rage!!!

Really nice smooth animation.

It would be nice if the alerts appeared in the centre of the screen though... I find that jerking my eyes up to the top of the screen and then back down to what I was looking at quite intrusive.

Ideally you could specify an HTML element to place the notification near, and then pass whatever element the user activated to trigger the notification. Or you could specify target coordinates, and compute the desired location yourself. Both of those ought to use optional parameters, though; defaulting to center seems reasonable.

If you look on the demo page (http://fabien-d.github.com/alertify.js/), all of the alerts get injected into #alertifylogs.alertify-logs which is positioned by css and therefore should be easy to overwrite:

    .alertify-logs {
        position: fixed;
        z-index: 5000;
        bottom: 10px;
        right: 10px;
        width: 300px;
    }

In the "prompt dialog" the buttons don't get highlighted when I tab over to them ... so instead my browsers buttons get highlighted, and I end up hitting back instead of Ok or Cancel...

Degrades perfectly down to IE7, great example on how to do this - the design and functionality become less and less polished yet it still does the core tasks accurately.

I was literally talking to someone yesterday about how I couldn't believe a plugin like this didn't exist yet. Long overdue. Well done!

Looks great on my iPhone. Thanks for the nice lib!

I love it but I actually don't understand why you decided to put two completely separated features in a single library: the alert/confirm/prompt dialogs and the log/success/error messages.

I think that if you'd split this two things into two different libraries it would be better (e.g.: if i want only dialogs i'd prefer to include just them)

Great work!

I've been using apprise (http://thrivingkings.com/read/Apprise-The-attractive-alert-a...), which is pretty good, but going to switch to this. I really like how Alertify has the growl-like log alerts along with it.

Great work, but one suggestion:

Make the alert notification go away when ESC is pressed, like the Confirmation and Prompt notifications.

I'd also suggest that clicking anywhere on the body should dismiss it, and behave like cancelling.

Submit a pull request then.

Very slick. The only thing I'd add would be Chrome desktop notifications (optional) for plain alerts.

HALP! Does anyone know of a jQuery plugin that has notifications like they do on OSX. For example, when you raise the volume or mute you see that rounded transparent square? Is there something like that for the web?

It's a DIV with a border-radius and a semi-transparent black background. It's just CSS, why use a jQuery plugin? Why not just quickly build it yourself?

Because it is an alert. I need it to fade in and then disappear. I mean I guess I could build it but was wondering if there is a complete library out there to handle the alerting and all the options a modern notification library has.

I found this project that would fit the bill: http://fabien-d.github.com/alertify.js/

See "Customizable Log Messages".

I think http://stanlemon.net/pages/jgrowl is very close.

  jGrowl is a jQuery plugin that raises unobtrusive messages 
  within the browser, similar to the way that OS X's Growl
  Framework works.

It is pretty old by now (4 years), but a benefit of that is that it supports older browsers too.

And this plug-in is also close. Build on top of jQuery UI, so small footprint, but you'd need that library.

http://www.erichynds.com/examples/jquery-notify/

  This is a growl/ubuntu-like notification system built on 
  top of jQuery UI.

Very nice. Thanks for sharing. I think that I'd like to see the ability to <tab> off the dialog onto the underlying document restricted. The concept of 'semi-modal' is pervasive but undefined :)

Great stuff, I think this will take over from jQuery.noty for me.

Very nice! I've used jGrowl for this in the past, but this seems much improved, more feature-rich and with sensible default styles. Alertify FTW!

Stacking up of multiple alerts being triggered is not handled properly. I think it should show latest posted alert on the top. Overall, good job!

Unless it's been updated since you posted, it is. The newest alerts appear at the top of the stack for me.

Sweet, thanks for Sharing. Another lib to add to the list. Not sure how it compares to noty, which has many options.

I like that it doesn't require any JS frameworks and still being lightweight.

Very useful! Thanks! ;)

Very nice work, I will look deep into it today :D

great stuff! i wish prompt dialog auto focused on the textbox. currently i have to click it first to type in. (on windows chrome)

Agreed. Looks like someone reported an issue already: https://github.com/fabien-d/alertify.js/issues/3

works surprisingly great on mobile ----- on a galaxy nexus (cm10) (animations are bit laggy, but thats fine)

Looks awesome! Smooth transitions!

i like it, thanks for making!

This is pretty bad ass.

No examples?

http://fabien-d.github.com/alertify.js/

Edit: I had a good time click on the buttons and filling the page with notifications. The animation is solid, and it's super clean.

They are linked there on the repository.

"No examples on a github repo page?" Classic. Good one.

http://fabien-d.github.com/alertify.js/

Cool library, i'll deep into it today :)

Reply on news.ycombinator.com