A replacement for JavaScript's “alert” | Hacker News Reader

A replacement for JavaScript's “alert”

github.com

312 pointsthefox107 comments

This is a nice implementation of an alert, but ideally you shouldn't ever need it. Alerts are a pretty horrible feature in a user's experience. Essentially they say "STOP WHAT YOU ARE DOING. THIS IS MORE IMPORTANT."

If something is that important then you'll usually want to give the user a choice from a set of options - e.g. if the user is doing something that can destroy data without the possibility of undoing their actions then you'll want a dialogue that asks them if they're sure. That should block all other interaction because it really is important. When the user has no input though, and there's nothing they can do but click 'ok', there's no need to use an alert. Just put a message on the screen that's high enough up the page's information hierarchy that they've very likely to see it. Make it sticky (so it's there until the user dismisses it, but doesn't block other actions) if it's something that they need to confirm that they've seen.

Don't force the user to do things your way. Guide the user, sure, but let them do things their way.

Generally true, but I work on a system that has to comply with government regulations that basically say "this is the most important thing the user can possibly be doing. PERIOD."

So alerts are pretty much a must for us, and the obnoxious interruptions help us make the regulators happy. Getting a nicer alert like this will make our customers a bit happier while still keeping us in compliance.

But our use case is of course not standard. Usually alerts are like Satan.

True but you can also use it with ok/cancel options, which I think fits the use case you mentioned when you said:

> if the user is doing something that can destroy data without the possibility of undoing their actions then you'll want a dialogue that asks them if they're sure

As far as I can tell, there are no callbacks. With javascript's confirm, you can do:

    if(confirm(....)) { doStuff() } else { cleanup() }

This should at least have a callbacks for the different buttons.

In terms of design, I don't like absolute vertical centering. It should be higher on the page. I use 1:2, or 1:1.6 for the top/bottom margin as my "default" modal centering.

One of the examples shows that they have a single callback function:

http://tristanedwards.me/sweetalert

Unfortunately, there's only one function so this isn't useful if you want to run code when the user cancels the dialog:

https://github.com/t4t5/sweetalert/blob/750a0fd72c3beaa6d4d7...

Oh wow, I just assumed those were tied to callbacks instead of just being a showCancelButton arg. The more I look into it the more underwhelmed I become.

>ok/cancel options,

So, if I click OK am I acknowledging the alert to dismiss it or is performing an action? If I hit cancel am I canceling the alert or canceling the action?

Its still terrible UI. Limiting the options to things like "ok" and "cancel" can be very confusing to the end user.

Don't you agree? {OK} {Cancel}

I wasn't clear enough, but the confirmation button text can be customized. So as a quick example you could do something like this:

Are you sure you want to delete? {Yes, delete thing X} {No, keep it}

Would you still find that insufficient communication with the user? No sarcasm, genuinely interested to get your opinion.

Cancelling the alert? That doesn't even make sense.

Not a replacement really; doesn't mimic the function signature, is not blocking as the alert etc etc

It's not possible for JS code to replicate the native blocking of alert(), prompt() and the like. Plus, if you call this with just one parameter, it does still work:

  sweetAlert('hello')

In which case I think the title is misleading as it is not a drop-in replacement.

With that said, I think it looks great

Yes, is possible! https://github.com/al0p/wow-alert

What I like about Wow Alert:

1. It's less than 5KB.

2. It overrides the existing alert function.

3. It extends the existing alert function.

What I don't like about Sweet Alert:

1. It's bloated for what it does... > 30KB

2. The short-hand swal doesn't make sense or read well.

> [Wow Alert] overrides the existing alert function.

That is an absolutely terrible idea. It overrides alert() but doesn't - and can't - duplicate its blocking behavior.

I'm not criticizing you for liking the idea! I can see its appeal myself. I'm criticizing Wow Alert for letting a nifty idea result in bad sofware design.

https://github.com/al0p/wow-alert/blob/b3224bc34fea6a49aac2d...

Their version of window.alert() returns immediately after setting up the alert window and actions - because that's all it is capable of.

If you just drop this into existing code without inspecting each and every alert() call to make sure it doesn't rely on the blocking - both in your own code and every library you use - you will definitely break things.

Far better to leave alert() alone and make this a separate function with its own name.

> It overrides alert() but doesn't - and can't - duplicate its blocking behavior.

If you really wanted to, I think you could set up an endpoint on your server to be long polled with synchronous XHR in a while loop, while you set up the popup in an iframe. When the popup is clicked, you send a notification to the server so the next synchronous request returns 200 and you dispose of the iframe.

On searching, I discover someone else has had this crazy idea already - http://stackoverflow.com/questions/16934667/what-methods-are...

I like that kind of insane creativity!

I'm surprised that the SO poster got the synchronous XHR approach to work. When I did some tests with Chromium last year they seemed to show that an iframe runs in the same thread as its parent window. I wasn't testing XHR though, just animation.

So if you ever do try this out, I would be interested to hear the results. Thanks!

This reminds me of this SO answer. I never understood what the guy was trying to do but people seem to be happy with it?!

http://stackoverflow.com/a/16758230/318557

Sweet alert is definitely bloated, but Wow Alert also depends on jQuery which is +80KB, so saying it's only 5KB is a bit deceptive.

Chances are you are already have jQuery on your page though, right?

No. Modern sites usually depend on browser native dom methods and a Javascript utility belt, like underscore. Or some other combination of new stuff like angular or backbone whatever. But the "include Jquery in boilerplate" thing is not nearly as common anymore best I can tell.

Anyone who isn't using jQuery because "modern sites usually depend on browser native dom methods" is just being an asshole, honestly. If most big sites are using it, you can use it. I just checked: Twitter, Outlook.com, Stripe, Paypal, Pinterest, GitHub, Amazon, LinkedIn, Ebay, Tumblr, etc. The list goes on pretty much forever.

Those are all sites that have been around for ages though, and jQuery is quite hard to remove from a site once it is embedded in. Anyone creating a serious web-app from scratch now really shouldn't be using jQuery, but one of the alternative set ups mentioned above.

I disagree. AngularJS uses jqlite underneath for lots of stuff it does with the DOM. It can use jQuery if it's included, and if you create your own directives, jQuery is a great tool. No, you shouldn't create a single page app based on bare jQuery. Yes, you should use jQuery for manipulating the DOM vs the native DOM manipulation functions.

They wouldn't remove it even if they had the choice, because recreating what jQuery does with regards to cross-browser compatibility is just wasting everyones time. I'm not saying it has to be jQuery, but since everyone is already familiar with jQuery and it works well - why not jQuery? Eventually yes I think we can drop jQuery in favour of native implementations, but most sites can't afford to lose that compatibility yet.

Because it's not built for complexity? Maybe I'm a jQuery newb, but trying to built a tight app with it seems like a painful process. Sure, it's easy to build some quick tricks with it, but I'd hate to maintain a large project with a lot of it embedded.

I honestly can't see how jQuery dictate how you architect your code. jQuery is a DOM manipulating library and AJAX library. It is not a framework. It doesn't force you to organize your code in any particular way. You know that jQuery is not forcing you to not write everything in a single main function, right?

So I fail to see how using $('#...").foo() in your large project is going to be harder to maintain than rolling your own DOM manipulating library.

If all I'm doing is domConstruct.put() instead of $().append() then of course you're right. Dojo in addition to browser normalization and other good things that jQuery does, suggests a structure that works pretty well. jQuery to my knowledge does not.

This doesn't make one an asshole; native dom methods can handle most of what people normally use jQuery for nowadays (even with the same function signature) so unless someone needs to do something more specialized I am not including an additional dependency.

People are assholes because they prefer and use or don't use other libraries over a popular one? What?

I would always encourage using a library over not using one - if you're not using a library you're just going to end up making your own anyway to "save time" - might as well start with something everyone already knows. If your project is also going to be something that a lot of people touch, you don't want to be using your own solution or a lesser known solution just because it's neater - that would be a waste of time.

So yeah, in my opinion if you opt to use your own solution or a lesser known one, I'd say you're at least a bit of an asshole because 1.) you're assuming you know better than the majority of people (who don't have a problem with using jQuery) or 2.) you're wasting everyone's time by forcing them to learn something new when there's a perfectly fine solution already available.

Do you even have one example of a "modern site" where (1) jQuery is not used and (2) there is a dependency on "browser native dom methods"?

I can think of ways to not use jQuery, like using d3 instead, but somehow, I don't think that's what you're talking about.

Ain't nobody using Backbone without jQuery.

Given the recent abundance of jQuery alternatives, that's a big assumption to make. It's always disappointing when I find some code I want to use and it has a bunch of dependencies that make it not an option.

I'm not aware of any jQuery alternatives. Most things that predate jQuery (prototype, mooTools, YUI) have long since fallen out of favor, and the 'alternatives' to jQuery are mostly API-compatible subsets (jqLite, zepto). What exactly do you mean by 'abundance of jQuery alternatives'?

I might be an edge case, but I use Dojo a lot because it's much better structured for larger JS applications than jQuery which quickly becomes a mess if you start doing a lot in JS.

That said, it does everything jQuery does, and more, and in a very nice way IMHO. If you're used to the jQuery syntax sugar, you probably don't like it, but I never liked sugar.

So yeah, a jQuery dependency is a killer for me.

Is it blocking?

From reading the source code I can say that no, it's not blocking. Although I'm not sure if there is an actual way of achieving that.

There is no way for JavaScript code to implement the blocking behavior of alert().

I think what the parent meant is that it's not possible to make it blocking like the built-in alert function. WOW Alert still needs a callback if you want to do something after the alert is closed. So it's not a drop-in replacement.

It is possible to block JS execution using generators or an eval hack, see my showModalDialog polyfill: https://github.com/niutech/showModalDialog

I know. I wouldn't call it a "replacement" if it's not behaviour compatible with the native function.

I still haven't found a really good use case for blocking UI - what are some?

Any app that allows users to create content that is not stored in persistent storage: this will be lost if they close the window without saving in some manner. An example: an HTML5 audio recorder or photo editor.

I'm not sure there's a great reason to block the UI with an Alert. But I also can't remember the last time I saw one except a really horrible AP tool by GXS which uses an alert to tell me my browser won't work on their site. (which of course it does once I switch my user agent string to one they like).

Now this isn't a great use but its one maybe acceptable use if my browser really didn't work on their site.

Confirm dialogs particularly around destructive actions are decent use cases for UI blocking.

In the year 2014, obnoxious popups are described as "beautiful" and "awesome".

This strikes me as cartoonish rather than beautiful. The animated green line art is semantically confusing, suggesting some sort of continuous process rather than a static situation. I suppose that could be good if you feel people tend to hit OK too fast without reading the text.

In fact, the animation draws attention away from the text, which you are probably supposed to read (otherwise, why bother with an alert). I really don't understand this infatuation with distracting unnecessary animations that people have nowadays...

Like other people here have pointed out, this isn't exactly an alert replacement as much as it is a more limited form of modal dialog. And honestly if that's what you need, there's better solutions out there, even in the form of the HTML dialog element (whenever that comes into mainstream support at least).

Deleted comment

How does this have anything to do with the original post? Does OP use this technique in the library?

It's in the demo

https://camo.githubusercontent.com/3144fa643139adee4eb7d01e2...

Funny to see that when you click the "Yes, delete it!" button in the examples, a regular alert is displayed...

I thought the same thing!

We'll be nice and give the author the benefit of the doubt and say it's juxtaposition :P

- Doesn't work on older browsers.

- Unexpected behavior on mobile devices. (since they usually implement their own alerts)

Just make it backwards-compatible and it will be pretty sweet. Until then it's not serious.

Please do not use this until the authors ensure people using the keyboard alone / screen readers can dismiss the dialog and access elements contained within.

Are you having some difficulty? It works for me with the keyboard.

Apologies, it appears that keyboard handlers have been added since I last tested this a few days ago.

https://github.com/t4t5/sweetalert/commit/2413e5cbcd1fe3d6e1...

Though the alert may look nice, the actual JS behind it is hugely wanting for several reasons: - 690 LOC to produce an alert dialog

- Heavy use of Javascript for what CSS is designed for: https://github.com/t4t5/sweetalert/blob/master/lib/sweet-ale...

- Inconsistent between function spacing followed by mixed tabs and spaces

- Odd use of DOM based attributes to pass configuration options

- Colourspace manipulation on each call where SASS would be effective https://github.com/t4t5/sweetalert/blob/master/lib/sweet-ale...

- Includes jquery, but uses it very little, instead opting to re-invent the wheel in most cases.

- Strange click event firing, gratuitous use of magic key code numbers https://github.com/t4t5/sweetalert/blob/master/lib/sweet-ale...

etc...

what's with the recent surge in use of the word 'beautiful' to describe minimal UI elements

I think it's just another case of language losing its meaning in certain contexts. In the case of front end web development it seems to mean 'flat with large well spaced fonts'. When terms are abused like this they quickly become terms of abuse. Give it another year and it will be an insult to call something beautiful because by that stage it will be clear that beautiful = early 2010s obsessively flat and minimal web design that everyone finds boring and pretentious now.

(As you can probably tell, I do not like this style at all)

The thing that really annoys me about it is that the word 'beautiful' has meaning to me. That meaning is such that it only applies in very few places. By taking that word and associating it with something as mundane as a bloody message box (in this example - there are plenty of others); It feels like a con. The credit the word 'beautiful' has built up is being used to try to raise the calibre of something completely ordinary. It makes the word and the thing it is describing both seem cheap. There's a lot to be said for calling a spade a spade.

It's marketing.

Just a bad trend.

Honestly the native version looks better to me. And it has the desired functionality of blocking the UI thread... I don't think you should encourage anyone to use alerts by making them prettier.

Is the OP the author?

If so, there's a slight typo on the "See it in action!" page (http://tristanedwards.me/sweetalert). For the "A warning message, with a function attached to the "Confirm"-button" demo, the code displayed says 'alert("Booyah!");' but the alert being displayed says 'Deleted!'

No (check the OP's HN profile), but would it matter either way?

edit: Ah, fair enough. The project's github page has issues enabled though.

Thank you. I submitted the 'issue'.

I edited my comment above to include why I cared.

Something I find annoying with this is that on mobile (haven't tried other platforms) it goes back to the top of the page when a sweetalert opens.

What is 'beautiful' about it? There's absolutely nothing beautiful about it at all. I don't think the OP realizes what "beautiful" means.

I recommend using the content in the link itself: it's described as 'awesome' not 'beautiful'.

What's funny is that since this doesn't actually work like a JS Alert, it's actually quite 'ugly'. ;)

As a non-native English speaker, it feels weird seeing phrases like this. In my opinion, a more appropriate word would be 'elegant'.

Looks great, but it seems like positioning it as a beautiful flash message plugin rather than an alert replacement might be more apt.

Hopefully very few JS developers are using alerts in their production code (or dev for that matter!), and if they are they're probably not interested enough in user-friendly design to seek out this replacement.

This could be an interesting discussion.

I notice that even large apps like gmail and google calendar use native alerts (and I've been using them a bit more under certain circumstances—something has gone terribly wrong). What about native alerts in all situations equals unfriendly design—esp. when trying to mimic mobile native apps, but needing to span the gap from OS to OS?

I agree with their use under very particular circumstances, like in your example or (at least in desktop Chrome) for bringing attention to a window that isn't visible. I was referring more to using alerts as they're being used in the SweetAlerts examples (success messages and other "flash messages"). In these cases, UI-thread blocking seems bad, no?

I actually think SweetAlerts looks pretty nice for those kind of in-app notifications, which was the point I was trying to make. (Though seeing comments from people who have dug in further it seems like it has some issues)

https://github.com/al0p/wow-alert

Linked demo would be nice :P

You should be able to click off of the modal and it should disappear.

The only issue I see with doing it that way is if you are in another Window and click to get focus, but you should deal with the alert when it appears since it is a part of completing a task.

Usually people only switch windows when they have completed a task.

Most comments critique the widget, but I'd like to talk about the demo website. It's really well done, I wish more products (especially free and open source) were on top of their game when it comes to presentation, samples and configuration. Good job!

It's no coincidence that frontend developers make good websites :)

There's a bug in your example page:

Click the Confirm example: Click "cancel" to clear the dialogue.

Click the button again: Click "delete me" and you don't get the deleted alert that you normally get.

What about the alert type which contains a text box? something like: http://www.pastemehere.com/34pvxrtc

Animation should augment UI, not steal attention away from what the user should focus on. In case of popup alerts, popup animation itself does what is needed.

Where's prompt?

Also, I suggest optionally only blocking a portion of the DOM and centering over it. This would allow a component to lock without locking the application.

a 20k replacement...

Awesome work. But the contrast on the demo page is causing me health problems. It's a sad song unto my soul. Can you make it more readable?

The only time I use alerts is for debugging purposes

And finding XSS vulnerabilities in the wild.

on IE8 and below.

Finished your sentence for you.

I use blockui for this kind of thing:

http://malsup.com/jquery/block/

looks nice and friendly use. i look forward to using it. But when it comes to replacement, its not blocking. So its not a replacement.

It looks great, but funny that it shows a normal Javascript alert when clicking the confirm button in the example.

But needs more callback functions...

Nice, but I have found the native implementations don't look as bad as they used to, especially on mobile web.

There is one gotcha with native/custom alert messages like these: native alerts block the ui thread of a browser, while custom do not. Sometimes you want to block and sometimes you don't. When you don't - you need something nice and simple.

I think if you don't want block the UI thread you shouldn't be using alerts. That is the whole point of it.

Then there's also smoke.js

http://smoke-js.com/

been using this: https://github.com/fabien-d/alertify.js/pull/173, which can replace alert, prompt and confirm

This is awesome, but it should close when the user clicks out of its bounds.

Like the alert box in browsers?

With alert(), user can copy the content of alert with Ctrl + C.

why does the checkbox line only go part of the way around the circle?

meh.. there is nothing like classical alert in the universe! <3

Sweet.

this looks nice!

asfdasfdasfd

sdfasdfasfd

Does this guarantee that the alert will be on top of the html elements on the current page? Sometimes this is important if you are building a browser plugin and need to show dialog to the user. For example, I use alert instead of a modal html dialog because when you are injecting it on some pages it won't show up properly.

Chrome supports the <dialog> element which is guaranteed to appear on top of whatever page its injected on.

Javsacript's Alert, prompt, also guarantee it will appear on top.

Reply on news.ycombinator.com