HTML forms were defined such that the only reasonable way to implement the technology was in a client-side browser. XForms, on the other hand, defines things such as validation rules and declarative actions, which can be processed on either a client or a server. This gives a lot of flexibility in the architecture of an XForms engine and, in many cases, allows XForms to be layered on top of existing browser technologies.
One common strategy for XForms engines is to divide processing between the client and server. The dividing line between client and server can be in several different places:
The client side requires almost no intelligence, serving only as a viewer application, while the server handles all of the logic and processing. Frequent server round trips are needed in order to coordinate the display with the internal state of the engine. The open source Chiba project (http://chiba.sourceforge.net) falls into this category.
The client side includes a scripting engine or some limited ability to do local processing, which can perform some of the logic and calculations. Only the most sophisticated operations require a server round trip, improving the user experience.
One major benefit of XForms split architectures is that they are readily adaptable to various supported languages in the client, including HTML, SVG, and VoiceML, among other possibilities. In particular, HTML translation is a popular option for supporting XForms in existing clients.
Another way to work with XForms today is to take advantage of the plug-in architecture of modern browsers. Two of the most popular options are the DENG engine (http://mozquito.markuplanguage.net), which works with any Flash 6 enabled browser, and FormsPlayer (http://www.formsplayer.com), which turns the most popular browser, IE6 for Windows, into a full-fledged XForms engine.