Show HN: Way.js – Simple, persistent, framework-agnostic two-way databinding

Thanks! Fixed. I added a "way-html" attribute (boolean, false by default) that you can pass to your DOM elements.

> I listed multiple real world examples.

I see no URLs in you text.

> THEN you need code to trigger that

I didnt't say you never need js code that reacts to input. I said: does anybody have real world examples where this type of library is useful?

Because most of the time I get along well with sending input to the server. And in the few cases I needed js to deal with user input I got along nicely with simple event handlers.

Maybe I'm just missing something, but is there no way to deal with arrays? You know, like looping through data and displaying things for each of them? (also related: what about looping through Object.keys()?)

What about dates? And data parsing/formatting in general?

Those are kind of important for a bi-directional bindings library. Remember that the Javascript data is usually the canonical data and the displayed data is derived from it, not the other way around.

If you want to compare w/ Knockout/Angular/etc then there's even more stuff that could be considered as "missing" (e.g. condiditionals, partials/components, how-do-i-use-select2-with-it, etc). One could argue those are out of scope for a lightweight library, but then again, I think this library has too many dependencies for something that advertises itself as "lightweight".

My own framework Mithril ( http://lhorie.github.io/mithril ) for example is ~5kb gzipped, has no dependencies, and allows you to do quite a bit more in terms of templating and data binding.

Incidentally, I wrote a article a while back about how two-way binding isn't even always the best answer to your questions, and that there are often better ways to update javascript data from forms: http://lhorie.github.io/mithril-blog/asymmetrical-data-bindi...

> I didn't say you never need js code that reacts to input.

Actually, you kinda did:

> Im always under the assumption that the old "post data to server, save it there" model still works best.

Whatever you were trying to say with that question, I don't think it was coming through. Anyhow, to answer your actual question:

> I wonder who benefits from this kind of library. You can react to user input with a simple keyup event.

Well, obviously. The use case for two-way data binding is every single place you would ever use a simple keyup event. The two approaches do the same thing in very similar ways; and a two-way data binding library is generally nothing more than some simple boilerplate over the plain event binding. For example, with Knockout you could put this in your HTML:

Or if you like jQuery you could put this:

And then in your JS you could put this:

    $('#field1').keypress(handler);

As far as reacting to user input, they do the exact same thing in the exact same way. The difference is that Knockout example has very slightly less typing, that it's (to my eyes) very slightly clearer what's going on when you look at the HTML.

There's a lot of ways to structure an app. Two-way data binding helps with one of the obvious ways; it's simple and (if you're sane about it), clear. Which is probably why it's a core part of Angular, Knockout, Ember, Mithril, Vue, Ractive, and a bunch more frameworks besides, and provided by popular plugins for Backbone and React.

TL;DR: People who want some boilerplate to hide a bunch of ugly event binding.

Edit: To be clear, two-way data binding is one of many ways of organising an app, and by no means the best way. But if your question is "why not just use some random event bindings", I'm not sure you understand the problem space.

Yeah, sorry, I just fixed it :)