Fore — programming with HTML tags but WHY?
‘Fore’ is a framework for building user interfaces in the browser just by using HTML5.
I almost hear some of you groaning — really, just another framework? Why? What sets it apart and why does it fill a gap?
Frameworks — now or never?
Giorgio Di Falco recently wrote a nice article about why you should think twice before adapting a framework and i almost got a headache from nodding to his statements.
But the world isn’t just black and white as the following discussion revealed. Often there’s not the budget or time to do things from scratch to stay with the platform and avoid the pitfalls of using a framework. I hold myself back from listing these out again though i’ve had my own traumata.
There’s just one point that stands out for my colleagues and me — our customers often require a long-term technological perspective. Many of them come from academic projects that either have no huge budgets and/or deal with knowledge topics they want to preserve over a long period of time. To address those needs we bet on open source and open standards that offer at least a perspective to survive decades and not just the next 3- 5 years ( — deleted rant on current frameworks — ).
As a small company we are challenged to deliver complete solutions from back-end to front-end. The user interface part is often just one side of the medal and we need efficient ways to provide them quickly without limiting their long-term preservation. As much as we would like to stay with vanilla HTML and JavaScript, it just isn’t realistic under budget constraints. We also can’t afford to pay an expert for each separate task.
Standards, Standards, Standards
Standards evolve and stay valid over a much longer period of time than frameworks that build upon them. Of course there are two sides to that: on one side you may argue that standards can’t keep pace with innovation. Sometimes they are overly complex and ‘academic’. But they are developed in an arduous democratic process where many experts take part. That doesn’t guarantee perfection but gives us at least some stable foundation to build upon.
We are dealing with a lot of standards like HTML, Web Components, XML, XPath, XQuery, JavaScript, JSON, CSS to name just a few and all of our tools is grounded on one of these.
This small excurse into our work just leads to the point of this article — why should one want to build user interfaces with just HTML tags?
Programming with tags
To sum it up we needed a way to cover complex user interface requirements but building upon a standard ideally. Happens to be that ‘XForms is the only standard-based framework for the web’ as Steven Pemberton (chair of W3C XForms working group) stated it once.
XForms? Many of you (especially younger script jockeys that made it until here) might not even heard of. Yes, it’s an W3C standard though it’s admittedly not prominent at all though it’s used in very serious applications reaching from eHealth to aviation.
As someone who believes that popularity does not relate with smartness i still fancy the architecture it gives us. It’s a Turing-complete MVC architecture that allows to use markup to build even very complex applications using a declarative syntax.
One of the reasons why it might not have become more popular is its foundation on XML. XML and HTML have always been like 2 brothers which each have their own group of friends that rarely (or if at all) meet each other.
And — honestly — it always felt a bit awkward to have all the namespaces and prefixes and stuff. That can become a bit chatty and due to the harshness of XML a foregiving HTML parser is a relief for the stressed front-ender. Also — who uses XML data nowadays (beware irony here)?
But the power the authors put into the XForms architecture and given the innovations in HTML5 (namely Web Components) have led us to roll our own xformish framework and implement it as plain HTML5.
‘Fore’ adopts the XForms architecture and implements it as a set of vanilla Web Components allowing to write complete applications without even touching a line of JavaScript (but you still can).
‘why’ and ‘when’?
Still — why should i use tags instead of proper scripting? There are different aspects to it.
The ‘why’s
- there’s no tooling needed. Let that sink in. No npm and no build tool needed to develop and roll out apps to customers. Build procedures and ever-changing dependencies need to be eye-balled and mastered and eat up precious hours of your budgets. Fore is just one script and one CSS to import. This is already a huge time-saver.
- You don’t need to be a JavaScript wizard to write apps. Of course this requires to learn how to solve problems with Fore but there’s a long list of demos to learn from and it can be mastered by everyone that masters HTML.
- The XForms architecture gives you a generic set of features to handle every requirement that might pop up: from data-binding, loading/sending data in various formats, handling multiple data sources, doing calculations to events, actions and custom functions.
The ‘when’s
First and maybe foremost Fore helps out when there’s no front-end department or specialist around that can donate exclusive time on building the front-end. Without diving into the pecularities of JavaScript you can still deliver user interfaces in time.
Further Fore is especially usefull for handling XML data as it allows to edit XML in a browser environment. Think of form-driven applications that need a lot of calculations and validations and potential ‘business-logic’. When dealing with standards like HL7/FHIR (eHealth) or AIXM (Air Information Exchange Model) or document formats like Docbook, TEI, JATS, you name it … Fore might well be the easiest approach to edit such data. — but still, it does also work with JSON.
A recent application we’ve realized implements an scientific editor for historical inscriptions in TEI which loads about a dozen of data-sources in either XML and JSON, uses third-party components in nested repeating sections in a quite complex user interface. It still loads in under one second without using any build step.
We’re also using it for our own time-tracking solution with reporting and managing projects, clients, users and roles.
Pros and Cons
On the pro side:
- generic and complete — applicable to any web application problem
- does not require any tooling
- easy to adapt if JavaScript skills are missing or limited
- based upon a standard
- when dealing with big, complex schemas the user interface markup can be generated much easier than building a code generator.
On the Cons side:
- ‘programming with tags’ breaks quite harshly with established practices and might not be for everyone.
- you need to adopt some different kind of thinking and be willing to learn new solution patterns.
Summary
Fore was not started to rule the world but from our concrete customer needs plus our own limited ability (and willingness) to cover each new fancy framework and worry about how to take that to the future.
For those who ask why an unpopular standard is a better foundation than the latest uber-fancy framework i can just say: bigger minds than me have thrown their ideas together for more than a decade and put that in a specification that covers problems that are not easily detected when rolling your own solution.
Though still young Fore already covers our current needs well and expands more and more into many of our projects. It’s easily extensible to support more data types, actions and functions and is open to community input.
Though made as our own dogfood we still hope Fore will be useful for others. Feedback welcome.