Actually I've been wanting to write something like that for a long time but didn't get around to it. Nice to see someone else did exactly what I wanted...
If what you're doing is simple enough that "serialise the form, send to server, wait for response, do a full page reload" works for you, then no, you don't need two-way data binding, and in fact wouldn't have any use for it. You only need two-way data binding if you need your client-side code to respond to user input, which a truly basic form doesn't need to do.
Of course, for a good user experience, you probably want to do client-side validation of the form; while you can do that a bunch of ways one of the easier ways (from a developer's point of view) is two-way data binding, and I'm using it on a few contact forms, signup forms, file upload forms, etc., scattered around the web for just that purpose.
And if you're doing something more complicated, then you probably want your client side code to respond to user input. If you're using ANY client-side MVC, or if you're getting real time updates from a server (via websockets or whatever), or if you're basically doing any sort of "app" style functionality in the client, you'll probably need two way data binding or its functional equivalent. I've written a big CRM webapp that uses two-way data binding extensively; the old "every click is a full HTTP round trip" model would deliver a shockingly bad user experience.
That being said, two-way data binding isn't the only way to implement rich client-side functionality, it's just one of the conceptually simplest ways of doing it. Backbone has two-way data binding plugins, but the "default" is to use events instead. Ditto for React. But something needs to tie your client side code to user input, and one of the simple "somethings" is two way data binding.
But again, if your app doesn't have any client side code, obviously you don't need anything to tie user input to the code you don't have. So if your app doesn't need any more client-side functionality than, eg, Hacker News has, then you have no need for two-way data binding (or, hell, any JS code at all). But if you want something a bit more interactive, then you need something.
(That being said, I still have no idea what makes this library better than any of the many popular, mature libraries that already exist. I've used Knockout quite a bit; it works well.)
" I've written a big CRM webapp that uses two-way data binding extensively; the old "every click is a full HTTP round trip" model would deliver a shockingly bad user experience."
Worth noting that, from what I can see, Salesforce largely uses the "every click is a full HTTP round trip" approach and it seems to be quite popular. NB I'm not saying that Salesforce has the best interface ever, just that old-fashioned web applications can still be pretty successful.
Im sceptical. You know why? You wrote all this text instead of giving me a real world example and said "look, this would be shitty without a 2-way-data-binding-library".
> I've written a big CRM webapp that uses two-way data binding extensively; the old "every click is a full HTTP round trip" model would deliver a shockingly bad user experience.
I listed multiple real world examples. Not sure what else you want.
Again, IF you have client side JS code, AND it needs to respond to user input, THEN you need code to trigger that such as two-way data binding, and event bus, dispatchers, whatever. If you do not have client side JS code, or it does not need to respond to user input, then you don't need any of that. Are you asking why you would have client side JS code at all, or...?
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.
> 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:
<input data-bind="event: { keypress: handler}" />
Or if you like jQuery you could put this:
<input id="field1" />
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.
One possible use case is "live editing" of an object. Imagine a form that lets you build an HTML button from various properties: text, color, font, background, border-radius etc.
Using way.js the button can be updated immediately whenever you change one of its properties, without waiting for a server response.
And saving the data to localstorage is very useful when the user is spending a long time filling the form and then accidentally closes the browser / clicks BACK / etc. It's a bit like autosaving a draft version of the form.
Reading all your responses in this thread, it's clear that you want URLs to sites you can go look at rather than descriptions of times when this has been useful to individuals. You can find lots of examples of things built using data binding at the angularjs[0] and ember[1] showcase sites. A particularly well-known example of a nice application that relies heavily on data binding is discourse[2].
Weir thing is, the formData doesn't specify a working .toString(), so if you log it, it looks empty, and you can't see any of the values until you POST. Standards committees are wonderful.
Actually I've been wanting to write something like that for a long time but didn't get around to it. Nice to see someone else did exactly what I wanted...