[scottcanoni]

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.

[Stratoscope]

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

[aidanhs]

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

[Stratoscope]

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!

[MasterScrat]

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

[level]

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.

[fro]

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

[teleclimber]

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.

[iLoch]

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.

[jblok]

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.

[IgorPartola]

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.

[iLoch]

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.

[BinaryIdiot]

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.

[zackboe]

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

[iLoch]

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.

[saraid216]

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.

[joshkpeterson]

Ain't nobody using Backbone without jQuery.

[level]

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.

[grumblestumble]

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'?

[warble]

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.