

Show HN: Veneer, modal dialogs in 75 lines of JavaScript - adeelk
http://adeel.github.com/veneer/

======
chrisacky
Have I misunderstood your source?.. But when your first line of your README
says that it depends on Mootools, which is shipping at like 40kb~, doesn't it
kind of defeat the purpose of having a line count?

Heck, here is a modal dialog in one line.

var d = new dojo.Dialog({ title: "Pretty Awesome huh?", content: "And in just
one line" }).show();

~~~
adeelk
Yeah, I did mention the line count in the title but the real point is that it
doesn’t come with extra features that you’ll have to customize anyway. For
example, there are a million ways to present next and previous buttons when
you’re showing a group of dialogs, and if you want to use a different way than
the one your library comes with, it’s going to be frustrating. I looked at
five or six different libraries before deciding that just putting buttons
where required in the DOM and attaching onclick handlers would be a lot easier
(see the third example).

~~~
tar
I don't really understand what's the point of using your 75 line script for
creating modal dialogs instead of the one line solution mentioned by
chrisacky.

~~~
adeelk
If you're not trolling, can you show me how to reproduce my third example in
one line?

------
perlgeek
As a user, I find modal dialogs very annoying, independently of whether they
appear in the browser or in any other GUI application. Nice JS and all, but
please think twice (or better thrice) before using a modal dialog.

~~~
adeelk
There are usability concerns that you should consider, but that doesn’t mean
there are no appropriate use cases. Anyway, you don’t have a choice when it’s
a feature a client asks for.

~~~
perlgeek
I'm curious, can you name an appropriate use case for a modal dialog? The
first few uses cases I know of that came to my mind didn't turn out to be so
great after I thought a bit about them.

~~~
adeelk
I think there’s a usability concern only when the dialog presented is in some
way dependent on the main page, e.g. if it provides some information that
requires the original context. If you’re just showing zoomed-in photographs
from a gallery, for example, I don’t see a problem.

------
ricardobeat
We've worked with ColorBox (<http://jacklmoore.com/colorbox/>) for the past
couple years and it does the job well, just have to clean up the IE6 cruft.

3rd example would be just

    
    
        $('.stuff').colorbox({ rel: 'stuff' })
    

When you're creating one of these everyday you really don't want to setup the
events and logic everytime.

~~~
adeelk
Great, now how many more lines to move the arrows from the top of the image
(as in <http://jacklmoore.com/colorbox/example2/>) to the sides of the window
as in my example?

~~~
ricardobeat
They're positioned via CSS, so probably 2 or 3 line changes.

~~~
adeelk
We’re still quite far from my example. The next and previous buttons are
images instead of text, and I don’t want the close button or the caption above
the image. If you still don’t get my point, you can try actually reproducing
my example.

------
phzbOx
I wish more "library" would be written that way. I.e. make the 80% use case as
simple and clear as possible, and let the programmer change it if needed..
instead of providing hundreds of useless configuration (knowing exactly that
you'll encounter a case where you'll have to hack your way in the code anyway
because it wasn't part of the "configuration").

I'm not bitching in any way on the existing jQuery plugins. I used (and keep
using them) again and over again.. but for good javascript developers, simple
plugins easily hackable is most often than not the easiest way to get the
thing done.

For instance, Django provides a good authentication system.. and then lot of
different ways to customize it. It's good.. but it happened to me lots of time
to hack my own solution as what I wanted to do wasn't part of their initial
"configuration" thingy. Some django plugins were created for that, but then
again, they were hard to hack as 80% of the code base was to handle all the
possible "configurations". So, basically, sometime the easiest way to get
something done is just to find a snippet of code that does the minimum and
code the missing part.. instead of using a huge plugin that does _everything_
but still need to be hacked (Which is way harder the more the plugin is
complex).

~~~
ricardobeat
Most plugins are so small that, if you're going to let everything to the user,
they don't need to exist at all. Their value is in the convention.

------
audionerd
I like what you did here. It's common for new developers to rely heavily on
complicated Lightbox scripts, because it seems daunting to implement one on
their own. Your script would be good for a beginner to review. It covers the
80% case. You don't say anything about mobile support or browser support, a
note on that might be helpful to add.

I've got to say though, the underscores (while more readable) are not the
"house style" for JavaScript (at least, not the native functions of the
language), where everyThingIsCamelCase.

~~~
tar
He is still relying on Mootools which is around 40kB in size.

------
debaserab2
It's great that you've written a modal dialog library but what differentiates
it from the other popular options out there?

A 75 line modal dialog library (+mootools) isn't a huge achievement by itself
-- I usually write my own dialog modals until I need a feature or
compatibility that is more easily attainable using one of the more well-
written options out there.

~~~
adeelk
Every modal dialog plugin I’ve seen takes the following approach: try to
anticipate the ways people will use it and provide configuration options
accordingly. The problem is that as soon as you require anything the developer
didn’t anticipate, the plugin becomes useless (or you start messing with the
source). If you’ve read Spolsky’s essay, you’ll recognize this as a leaky
abstraction.

Veneer tries to minimize leakiness by doing the absolute minimum while making
it simple to add anything you need (as in my third example).

~~~
debaserab2
I'm not following how or why this is a leaky abstraction. My understanding of
leaky abstraction is an interface or API that fails to mask the implementation
details of it's functionality.

A library that does more than you want, without addressing your specific (and
probably custom) application needs seems inevitable. I don't think that's a
bad thing and I don't see how this library is any more insulated from that
problem.

~~~
adeelk
I’m referring to leakage in the other direction. Think of a lightbox library
as a layer over JavaScript’s API. When working with a library you can either
use the configuration options provided or just go back down a layer. The space
spanned by the configuration options is inevitably smaller than the full space
of possibilities you have when working at the JavaScript level, so it’s likely
that you have to go back down to JavaScript anyway. That’s why I prefer
working with libraries with less friction between the layers over those that
try to anticipate a use case but are useless as soon as you need something
different. As phzbOx mentioned the Django authentication system is another
example.

------
epikur
I like it. Would it be very complicated to add left/right arrow key support?

------
dylanhassinger
Your landing page should say that this requires Mootools.

