We know how the binding engine of Aurelia works. Also, we know how to intercept and customize that binding behavior. We know too how to transform data between View-ViewModel layer according to our needs. Just some things are pending, and the aurelia-validation plugin is one of them. When you need data provided by the user, you have to expect anything. The user didn't know your app. He will do anything he wants, and you need to be prepared for that. You need to ensure that data provided by the user is, at least, in the right format your back service is expecting. You need to filter just the right values and send alerts to the user telling which values are wrong and how they can fix it. We often need to put ourselves on the user's side. Software development is more than just programming, more than just creating forms and storing/retrieving data. We need to make our application fault-tolerant and as we said earlier, think always in the worst case. Just imagine something like this—you are developing an application that needs to perform some calculations. You have three inputs: a, b, and c; you need to calculate the sum. Well, that sounds easy, right? We have two users who type the following:

User 1 : value for a)33; b)23; c)32

You press the Submit button and get the correct sum—88. Fine, the application accomplished their purpose. Let's see what second user puts:

User 2: value for a)49 b)34j c)12

As you can see, the last user presses by error the j character. Will it rely on an application error? No. Our operation will be performed, JavaScript is not a typed language, so it will operate in the following way:

49 + "34j" + 12 = "4934j12"

The user will see that value, and we are sure they will never use your application again.