Is it me, or should the description read: "This form is bound to the 'formData' property" instead of "This form is binded to the 'formData' property"
Show HN: Way.js – Simple, persistent, framework-agnostic two-way databinding
21–30 of 62 posts
Re: Show HN: Way.js – Simple, persistent, framework-agnostic two-way databinding
#22Is it me, or should the description read: "This form is bound to the 'formData' property" instead of "This form is binded to the 'formData' property"
it should, but it doesn't benefit the conversation to point out grammatical errors - plenty of HN users are not natively english-speaking so it's probably best to just let it slide.
Re: Show HN: Way.js – Simple, persistent, framework-agnostic two-way databinding
#23Earlier quoted context omitted.
Does anybody have real world examples of websites that use this kind of thing? Im always under the assumption that the old "post data to server, save it there" model still works best. Am I missing something?
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 an…
> One possible use case
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.
Re: Show HN: Way.js – Simple, persistent, framework-agnostic two-way databinding
#24Might be worth benchmarking against the others: http://jsperf.com/angular-vs-knockout-vs-ember/351 For me personally I am loving VueJS right now.
I'm entirely in love with VueJS. It's just amazing. I only wish I could use it with IE8 so I could replace our old version of Angular that we're stuck with at work, but hey, somethings got to give to get that nice an API.
Re: Show HN: Way.js – Simple, persistent, framework-agnostic two-way databinding
#25Earlier quoted context omitted.
Is it really more painless to add way.js and its dependencies (jquery.js, underscore.js, underscore.json.js, form2js.js and js2form.js) to your page then to simply add a plain javascript eventhandler to the field you want to validate?
That depends. How many forms and how many fields do you need to validate? jQuery is pretty much standard on most websites, so I don't count that against the author. The total minified dependency file is 123 kb. I will agree that is pretty large if all you are using it for is a single field, but again, a large portion of that is jquery. Also compared to just core angular, which is 104 kb, I would say this is a viable…
Well, you can argue if 5 dependencies and 123 kilobytes of code is much or not. But what does it bring to the table? Your "sub-total" example would just need a normal javascript event handler. Lets say we are uber lazy and use jquery. Then it looks like this:
How does the way.js version look like? Im sceptical it makes it more elegant.
Re: Show HN: Way.js – Simple, persistent, framework-agnostic two-way databinding
#26Looks very straight-forward. Good job! OT: After building a couple of large applications in Angular I've come to realize that I seldom need two-way bindings. The school example where you enter something in an input box and it shows up somewhere else in real-time is not really used in the real world. Or is it? Why do we need two-way data binding?
Two-way data binding is needed for audio hardware controls that are linked to multiple inputs or to other controls (e.g. a volume control with both a text input and a slider, possibly linked to another volume control from a different channel).
Re: Show HN: Way.js – Simple, persistent, framework-agnostic two-way databinding
#27I applied to the example here the first test I always make of any things like this: HTML injection. Result: failure. ☹
Re: Show HN: Way.js – Simple, persistent, framework-agnostic two-way databinding
#28Why use invalid 'way-data'-attributes when there is data-attributes?
Re: Show HN: Way.js – Simple, persistent, framework-agnostic two-way databinding
#29I've been working on something pretty similar, but on the server side. It's called 'Neurons', and it's a pre-alpha Python library. It's built on Spyne[3], an RPC framework which is another side project of mine that I've been working on for ~4 years now.
The aim with neurons initially is to let you generate a html form (e.g. [1]) and related services from just a model definition and an instance of this model (e.g. [2]), making it a breeze to publish CRUD pages. It currently handles complex stuff like dates, times, arrays and nested objects just fine.
In Spyne terms, that's "serializing a model instance using the HtmlForm protocol". The same object definition can be used to for other protocols like json as well as for persisting data to a relational database (via SQLAlchemy). You can play with the code generator at http://spyne.io to get a better feel about how it works.
One could even write a Spyne protocol that renders a given model instance to way.js code.
Help is welcome!
[1]: https://github.com/plq/neurons/blob/test_output/html/test_si...
[2]: https://github.com/plq/neurons/blob/fccab8fee4c1795f65ac3f9b...
[3]: http://spyne.io
Re: Show HN: Way.js – Simple, persistent, framework-agnostic two-way databinding
#30That'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...
Does anybody have real world examples of websites that use this kind of thing? Im always under the assumption that the old "post data to server, save it there" model still works best. Am I missing something?
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.)