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