XForms was and/or is an XML markup that supports structured form data. It is a standard evolved from XML and was designed to be easily integrated into other current markup l
I am writing as a former XForms Working Group member, and current XForms Community Group member (see below). The following is a personal opinion.
A lot of information regarding XForms on the W3C site is obsolete, so I wouldn't take everything (if anything at all) you read there as gospel, but it is correct that W3C closed the XForms Working Group (and they did so with quite a bit of disrespect, I might add).
The group had been uncharted for a while, was hoping for a recharter, but that didn't happen. I should say that any XML activity at W3C is very low-priority for the organization at this point, even for the relatively more successful technologies like XSLT and XQuery.
However there is, as of 2016 2019, continued work on XForms 2.0 in the context of the XForms community group. This is a small group, which although hosted by W3C is not an official W3C Working Group. Anybody can join that group. We hold weekly calls and hope to complete the XForms 2.0 specification this year. You can find the current draft specification here:
Once the specification is done, if there is interest, a new Working Group might be recharted, but that is not a given. This would be a necessary path to make XForms 2.0 an official W3C Recommendation.
If that doesn't happen, then the XForms 2.0 draft will still be there for anybody to look at and implement. It doesn't have the force of a Recommendation but that force has always been very relative anyway.
The following is not complete but these are some of the top aspects which, I think, set XForms apart:
In addition, XPath 2.0/3.x makes for a surprisingly flexible language to bind properties, calculations, and controls to data models. I think that it is hard to beat at this point.
There are a few current implementations of XForms out there, including XSLTForms and Orbeon Forms (which I work on).
While back in the early 2000s the avowed goal was for XForms to eventually replace HTML forms, and in this perspective browser plugins and the Firefox implementation were developed, that idea has not been current for a very long time.
For years now, XForms hasn't depended on native browser support at all. All of XForms can be implemented in pure JavaScript, or with a combination of client/server parts, or within native applications.
I am not aware of any close alternatives to XForms based on the points listed above.
The elephant in the room is that XForms is based on the XML stack of technologies, and there is evidence that XML is no longer taking the world by storm (that is an understatement). But XML is still widely used in many contexts, and that's something to keep in mind.
If you deal with XML data, or at least don't mind XML, XForms remains a modern solution in 2016 2019. You might look into existing implementations or into implementing your own (although that is not exactly trivial).
If you do not care about XML at all, or dislike it strongly, then XForms is not a great solution (at least until it provides support for additional data models and binding languages, like JSON / JavaScript). UPDATE: XForms 2.0 has some level of JSON support. Picking one of the current UI frameworks will be the way to go, but they still fall short in many ways.
There are lots of UI frameworks using various underlying technologies (JavaScript being probably number one here, but you can count also TypeScript, Elm, Scala, and more) which are in constant evolution. These can be considered alternatives in that they allow you to build user interfaces and complex forms. Some frameworks have really good support for things like dependencies, some focus on providing nice UI controls, some on the UI update model, etc.
But I have not yet found a framework which covers all the bases as nicely as XForms does, although there is nothing that prevents that from happening in the future.