Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Smoke.js - A framework-agnostic styled alert/confirm system for javascript

ssssnakes.com

Post reply on HN
Print view View original

1–10 of 28 posts

Re: Smoke.js - A framework-agnostic styled alert/confirm system for javascript

#6

Post by wulczer »

georgefox wrote: post #5
wulczer wrote: post #2

Looks useful, but why make smoke.confirm work differently from plain confirm? It uglifies the API for no gain, IMHO.

How would you make it return true/false immediately when the user has to click OK or Cancel?

Oh, good point. I clearly need more caffeine in my system.

Re: Smoke.js - A framework-agnostic styled alert/confirm system for javascript

#7

Post by padolsey »

I like its simplicity.

But, I thought this was dead:

  onClick="javascript:smoke.alert('this is a normal alert');"
... apparently, not.

The 'javascript:' (attempted psuedo protocol), is just acting as a pointless label here.

I also thought we said goodbye to obtrusive JS altogether.

Also, the API isn't great. There's no instance to work with... It doesn't work in IE7 (probably because it doesn't cater for non-W3C events APIs). The source is littered with getElementById calls, and non configurable HTML IDs and classes. And it uses the window's 'load' event to initiate itself, when there's absolutely no need to. There's also 'smoketimeout' polluting the global scope when it could just be a property of the 'smoke' object itself.

Re: Smoke.js - A framework-agnostic styled alert/confirm system for javascript

#8

Post by JangoSteve »

padolsey wrote: post #7

I like its simplicity. But, I thought this was dead: onClick="javascript:smoke.alert('this is a normal alert');" ... apparently, not. The 'javascript:' (attempted psuedo protocol), is just acting as a pointless label here. I also thought we said goodbye to obtrusive JS altogether. Also, the API isn't great. There's no instance to work with... It doesn't work in IE7 (probably because it doesn't cater for non-W3C event…

Most of that is no doubt due to the fact that it's framework-agnostic, meaning it can't rely on all the things frameworks like jquery do to make it easy to create reliable, unobtrusive javascript.

I don't so much have a problem with the getElementById calls, as that really is the best and quickest way to do things. Even jQuery's $('#some-element') selector is simply calling getElementById('some-element') under the hood and then wrapping it in a jQuery object.

And technically the onClick stuff can still be unobtrusive, as long as the link still works as intended with javascript disabled (i.e. it's a normal link and doesn't have something like href="#".

But all technicalities aside, I totally agree with your sentiment. Almost every site I build now is using jQuery or some other framewor; I'd prefer not to use some library that has to re-implement all the bindings and selectors and browser-specific hacks and work-arounds that are already being included elsewhere in my framework.

Furthermore, if my site is so low-level or small that it can't easily include jQuery, I doubt I'll be worried about replacing or trying to spruce up the standard javascript confirm dialog.

Re: Smoke.js - A framework-agnostic styled alert/confirm system for javascript

#9

Post by jsavimbi »

Sorry, but this is the latest entry in obsolete and obtrusive functionality. It's useless for mobile (just tested iOS Safari and Opera), which is the platform you should start with, and it's been proven out to be an annoying hindrance to the user on the desktop.

Don't interrupt CRUD. If you can't trust the user to not perform an irreversible action, then you're doing it wrong.

Re: Smoke.js - A framework-agnostic styled alert/confirm system for javascript

#10

Post by oinksoft »

JangoSteve wrote: post #8
padolsey wrote: post #7

I like its simplicity. But, I thought this was dead: onClick="javascript:smoke.alert('this is a normal alert');" ... apparently, not. The 'javascript:' (attempted psuedo protocol), is just acting as a pointless label here. I also thought we said goodbye to obtrusive JS altogether. Also, the API isn't great. There's no instance to work with... It doesn't work in IE7 (probably because it doesn't cater for non-W3C event…

Most of that is no doubt due to the fact that it's framework-agnostic, meaning it can't rely on all the things frameworks like jquery do to make it easy to create reliable, unobtrusive javascript. I don't so much have a problem with the getElementById calls, as that really is the best and quickest way to do things. Even jQuery's $('#some-element') selector is simply calling getElementById('some-element') under the ho…

  var listen = function(el, evt, cbk) {
      if (el.addEventListener) {
          el.addEventListener(evt, cbk, false);
      } else {
          el.attachEvent('on' + evt, cbk);
      }
  };
No jQuery or whatever necessary ... if all you're doing is basic event handling and you know how the DOM works for other things, it really isn't much trouble to include this and a couple other small functions in a one-off, and is far preferable to including a hefty all-purpose DOM abstraction library like jQuery or MooTools.

Their example including an ugly onclick attribute doesn't imply that that is the only way to do things, it merely demonstrates the absolute simplest way to use the library. Of course any fool can use a script that includes the function above and locates the element manually.

Post reply on HN