That's the only javascript framework one needs.
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...
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...
Im always under the assumption that the old "post data to server, save it there" model still works best. Am I missing something?
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.
Sure, one can think up use cases. But I never had one. Thats why I asked for real world examples where 2-way-binding libraries are used.
Welcome to your very own filter bubble.
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.)
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 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.
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}" />
<input id="field1" />
$('#field1').keypress(handler);
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.
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.
https://developer.mozilla.org/en-US/docs/Web/API/FormData
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.
[0]: https://builtwith.angularjs.org/ [1]: http://emberjs.com/ember-users/ [2]: http://www.discourse.org/
Some people prefer to do things your way, but lots of us really do like this sort of data binding and find it to be very useful.
Tank: "It's a single celled protein combined with synthetic aminos, vitamins, and minerals. Everything the body needs."