Live data from Hacker News

Alertify.js

github.com

31–40 of 79 posts

Re: Alertify.js

#32

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,…

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.

Re: Alertify.js

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

Re: Alertify.js

#35
post #32

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,…

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

Re: Alertify.js

#36

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,…

[deleted]

Re: Alertify.js

#37
post #32

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,…

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.

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.

Re: Alertify.js

#39
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!

Re: Alertify.js

#40

Earlier quoted context omitted.

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!!!
Post reply on HN