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