This is a bold take on a problem that a lot of people have written away as reinventing the wheel. But color me impressed!<p>Unlike almost every other Javascript framework we've so far seen, FOAM makes the data model the primary entity in the system, which is a good idea. In the typical UI-driven development of web applications, the data model often gets modified without much thought and causes cascading complexity across the rest of the system. A lot of the convoluted UI code that I've written could've been kept simple by keeping the data model sane by finding and utilizing equivalences, making implied meaning explicit by extracting names, and normalizing/denormalizing the data appropriately. A data-structure driven development approach should help a lot here.<p>FOAM also implements another item from my wishlist: being able to see all the UI representation of any given piece of data in one place. It achieves this by keeping all possible templates for a piece of data directly in its object. (<a href="http://foam-framework.github.io/foam/tutorial/4-templates/" rel="nofollow">http://foam-framework.github.io/foam/tutorial/4-templates/</a>)<p>In general, this looks like the most declarative (as in, define your business requirements instead of writing imperative code) way of building web applications that I've seen yet. I would like to see what new ideas this library can bring into the 'Perfect UI Framework' conversation, but past experience makes me skeptical of any implementation that overly relies on metaprogramming. Metaprogramming can take us maybe 50% of the way home, but programming unfortunately is often an art in the minutiae. UI code is especially prone to this problem: things that have to deal with humans cannot be absolutely symmetrical all the time, which is where any overly declarative approach to building software breaks down. I often look back to this quote by DHH as a reminder of the dangers in generalization:<p><pre><code> On the surface, the dream of components sounds great
and cursory overviews of new projects also appear to be
"a perfect fit". But they never are. Reuse is hard.
Parameterized reuse is even harder. And in the end,
you're left with all the complexity of a swiss army
knife that does everything for no one at great cost
and pain.
- DHH ca. 2005
</code></pre>
Also, template based UI frameworks are IMO a relic of the past, of which I'm convinced by the way templates are defined imperatively using code in React. In templating, the UI is a String, but UI should be Code because code is awesome.