Show HN: Veneer, modal dialogs in 75 lines of JavaScript | Hacker News Reader

Show HN: Veneer, modal dialogs in 75 lines of JavaScript

adeel.github.com

56 pointsadeelk25 comments

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();

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

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.

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

If we want people to make their code public, to create libraries and to share their thoughts about how to make things better, we need to treat them better when they do.

I'm all for constructive criticism, but many of the posts in this thread are purely negative.

We have a responsibility to foster a community that creates, shares, and improves the state of the web for all of us. That won't happen through vicious infighting.

Sorry, it's actually dijit.Dialog({}). My bad.

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.

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.

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.

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.

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.

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?

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

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.

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

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.

I completely agree. I think this problem is rather pervasive in Django (it goes far beyond just the authentication system).

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.

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

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.

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

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.

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.

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

Your landing page should say that this requires Mootools.

Reply on news.ycombinator.com