Why does the form have to be generated dynamically by JS?
A much better solution would be to generate the markup on the server-side. It should be easy enough to port this to Node, and a bit more of work for other major backend languages like Ruby, Python and PHP.
It could even be implemented as a webapp that takes the input JSON on the left side, and spits out HTML on the right, which I could paste into my site markup directly.
Right now, the trade-off is too big for the developer-time convenience of generating forms dynamically.
It's more to do with separation of concerns. The presentation of data should be the responsibility of the front-end (in this case, the data is a form description and the front-end is in your web browser).
This is very useful for when you have a single API that drives your web, Android, and iOS apps. Your back-end just describes the form in JSON and each front-end is responsible for how that form renders. Alpaca is just a shortcut for your web front-end.
You get the irony though that this was the original purpose of SGML (which admittedly HTML 1.0 thoroughly screwed up). It seems perfectly reasonable to render the page using HTML and have the render logic for browsers or what have you be in the form of style sheets and Javascript.
At a first glance: very cool plugin, I think the core idea of representing forms as JSON is a good one. Two gentle criticisms:
1. From a 'prospective developer' standpoint, I'm worried about the dependencies and general heft of the thing. Does it require jQuery UI? Is there a stripped-down version I can use? As far as I can tell, the landing page doesn't answer these questions.
2. More broadly, I'd argue that there are two types of <form> implementations: barebones forms that use 'value' and 'type' and very little else, and hyper-customized ones that are generated bespoke. This plugin seems to address the middle of that spectrum: people who need a little -- but not too much -- customization. It's hard to tell exactly what options I'm given just from poking through the first few pages.
I'm worried this does not put usability first. In the example Edit form, I noticed two problems: 1) the radio button labels have not been linked using 'for' to the buttons, so clicking on them does nothing. 2) Hovering my mouse over the first address line text box causes it to move down away from my mouse! Errors like these will cause a lot of entry mistakes.
This is really just an awful idea. Every few weeks/months I see some kind of "wouldn't it be great to have users write pseudo-html in json and we can then write loads of javascript to write the html for them!" kind of library and the answer to that is always "why would that have ever seemed like a good idea?".
Good libraries decorate html to provide functionality because, well html is pretty good at the html bit.
The first example renders a form with radio button labels not tied to the appropriate controls, so I can't just click them to select the radio button. Same for the other labels. This is totally unforgivable and such a well known annoyance that I refuse to read anything else. RIP Alpaca.
Love it! The complaints here are usually from people who assume this is good for all situations. If you have a fixed amount of static forms, this wouldn't make sense. BUT, if you had to do dynamic forms that can change drastically with user input, this is wonderful.
During my University coursework this year I had the same idea during one of my assignments, I wrote something similar without using jQuery as a hack for a entry level web development paper.
No labels at all just on the demo form. This isn't 1996 where one can make shitty HTML forms for shits and giggles. People expect high quality forms with labels nowadays.
As others have said: dealbreaker. Not going to use it.
A much better solution would be to generate the markup on the server-side. It should be easy enough to port this to Node, and a bit more of work for other major backend languages like Ruby, Python and PHP.
It could even be implemented as a webapp that takes the input JSON on the left side, and spits out HTML on the right, which I could paste into my site markup directly.
Right now, the trade-off is too big for the developer-time convenience of generating forms dynamically.