6 ms·

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 lik

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.

deleted 12y ago
[deleted]
level 12y ago
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 12y ago
  Chances are you are already have jQuery on your page though, right?
  - teleclimber 12y ago
    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 12y ago
      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.
      - zackboe 12y ago
        People are assholes because they prefer and use or don't use other libraries over a popular one? What?
        iLoch 12y ago
        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.
      - jblok 12y ago
        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.
        iLoch 12y ago
        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.
        warble 12y ago
        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.
    - joshkpeterson 12y ago
      Ain't nobody using Backbone without jQuery.
    - saraid216 12y ago
      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.
  - level 12y ago
    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 12y ago
      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 12y ago
        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.
Stratoscope 12y ago
> [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/b3224bc34fea6a49aac2dfb18707120790828c98/wow-alert.js#L60 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 12y ago
  > 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-blocking-in-javascript http://stackoverflow.com/questions/16934667/what-methods-are...
  - Stratoscope 12y ago
    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 12y ago
    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 http://stackoverflow.com/a/16758230/318557

deleted 12y ago

[deleted]

level 12y ago

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 12y ago
Chances are you are already have jQuery on your page though, right?
- teleclimber 12y ago
  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 12y ago
    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.
    - zackboe 12y ago
      People are assholes because they prefer and use or don't use other libraries over a popular one? What?
      - iLoch 12y ago
        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.
    - jblok 12y ago
      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.
      - iLoch 12y ago
        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.
        warble 12y ago
        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.
  - joshkpeterson 12y ago
    Ain't nobody using Backbone without jQuery.
  - saraid216 12y ago
    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.
- level 12y ago
  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 12y ago
    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 12y ago
      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.

Stratoscope 12y ago

> [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/b3224bc34fea6a49aac2dfb18707120790828c98/wow-alert.js#L60 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 12y ago
> 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-blocking-in-javascript http://stackoverflow.com/questions/16934667/what-methods-are...
- Stratoscope 12y ago
  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 12y ago
  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 http://stackoverflow.com/a/16758230/318557