The tcomb library seems to do quite a lot, some of which might be sort of useful, but the example supplied here doesn't really seem to support why you might use it. The code in fact just seems weird to me: if you're having to use a try/catch to do some really basic form validation, then obviously that's horribly wrong... but the example below, under "Further Reading", which is (I think?) proposed as the better solution, doesn't really seem any different from how you might go about solving this problem were you not to use any library at all, except you wouldn't have the struct stuff. Very unconvincing, if you ask me.<p>Contracts.js is quite a different approach, maybe even to an orthogonal problem, but perhaps is more interesting: <a href="https://github.com/disnet/contracts.js" rel="nofollow">https://github.com/disnet/contracts.js</a>
I think this looks pretty cool; I like how simple and general the last validation function is. If you're generating the UI from the model all the better (it looks like there's a note on this front at the bottom of the tcomb.js readme). This would be remarkably easy to do with React, and it all could be abstracted into a simple configuration framework.<p>Looks like there's a typo in the last example: you probably want to use the Struct param in the fetch function rather than explicitly creating a User.<p>Seems like the makings of something like Bootstrap for domain models here. Neat.
> What if your domain model could validate the UI for free?<p>Then your domain modeling language will be as detailed and error prone as the UI designing language, and completely unsuitable for the task. As the article exemplifies.<p>Abstraction and detail are at odds against each other. You simply can not have both.<p>Also, why verify the domain description? You must check that the UI fits the problem, not a short description of it.