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.
One thing you notice right off the bat: Its very slow. It takes about 2s on my machine to load the TodoMVC example. Thats about as long as it takes to load my GMail inbox. Thats pretty horrible for whats supposed to be the "Hello World" of JS frameworks. I didnt dig in what actually takes so long, but it seems like it has still some way to go.<p>I find it interesting that after Angular this would the second (3rd if you count GWT) JS framework released by Google with pretty bad performance characteristics (if it actually is made be Google).
> FOAM is a full-stack Reactive MVC Meta-Programming framework.<p>Inevitably reminds me of this: <a href="http://html9responsiveboilerstrapjs.com/" rel="nofollow">http://html9responsiveboilerstrapjs.com/</a><p>I understand MVC, but what is reactive meta-programming exactly?
It's about time more people starts using ES6 class constructors instead of rolling their class definition hack. This is how it's done in the calculator demo:<p><pre><code> CLASS({
name: 'Calc'
</code></pre>
With babeljs you can use ES6 syntax like this:<p><pre><code> class Calc {
}</code></pre>
On the demos page<p><a href="http://foam-framework.github.io/foam/foam/demos/DemoCat.html" rel="nofollow">http://foam-framework.github.io/foam/foam/demos/DemoCat.html</a><p>All the links to "Source" take me to GitHub 404.<p>I would suggest this is the most important part of showcasing a new project.
It does not seem a new thing, rather an old one just migrated it to Github.<p>It has 8,474 commits. The first commit (and also the first issue on Google code) dates back to Jul 30th 2012. And it was just the first public release, not an empty commit (43 files).<p>(first issue: <a href="https://code.google.com/p/foam-framework/issues/detail?id=1" rel="nofollow">https://code.google.com/p/foam-framework/issues/detail?id=1</a> )
Regardless of how good it is, the presentation could and should be improved. Quick to grasp examples, an explanation telling me <i>which problems this project solves</i> and as a bonus how it compares to other frameworks. All of this should be on the GitHub readme frontpage.
Poor presentation is like a 0.01 multiplier for your amount of potential users. It's easy to avert your eyes from this but it's almost as important as the quality of the product itself.
A first glance of the docs I see the components aspire to a declarative style (being defined entirely in JSON). I'm wondering though, why not use composition[1] instead of inheritance? I need to take a better look to see how view composition would work in FOAM.. But I can tell from experience with Backbone, that using composition instead of inheritance improves code structure and increases maintainability. If composition was a first-class construct (like they made extendsModel), it would get a lot of issues out of the way.<p>[1] <a href="http://en.wikipedia.org/wiki/Composition_over_inheritance" rel="nofollow">http://en.wikipedia.org/wiki/Composition_over_inheritance</a>
They say it's reactive, but this is how they explained "reactive": <a href="https://foam-framework.github.io/foam/foam/apps/overflow/Overflow.html#q12" rel="nofollow">https://foam-framework.github.io/foam/foam/apps/overflow/Ove...</a> and <a href="https://github.com/foam-framework/foam/wiki/KeyConcepts#reactive-programming" rel="nofollow">https://github.com/foam-framework/foam/wiki/KeyConcepts#reac...</a>
looking at the todo example, i was perplexed by the way templates are inlined through comments:<p><a href="https://github.com/foam-framework/foam/blob/master/apps/todo/Todo.js" rel="nofollow">https://github.com/foam-framework/foam/blob/master/apps/todo...</a><p>it led me to discover that the full text of a function can be reflected through .toString() ...<p>i'm not sure i'd be happy to see this approach widely adopted though. it feels like a language hack, like <i>maybe</i> js needs a multiline literal string..
Use of ES6 classes would have been nice and I'd prefer to work with simple javascript objects to hold data vs rich model objects (<a href="http://foam-framework.github.io/foam/tutorial/2-model/" rel="nofollow">http://foam-framework.github.io/foam/tutorial/2-model/</a>).<p>I don't think this is the framework for me.
interesting look, example documentation a bit spotty (pages missing eg: <a href="http://foam-framework.github.io/foam/foam/demos/" rel="nofollow">http://foam-framework.github.io/foam/foam/demos/</a> & others), rest of the docs ok.<p>What do I see? It's language centric, that's good and bad. The good bit is you can with a very small JS lib write code to generate a dynamic page. The bad bit: as the language grows and rusts, you have to chase down the removed features. Much easier to grasp in concept and execution than Angular.<p>Loved this bit in the calc demo source, testing: <a href="https://github.com/foam-framework/foam/blob/master/apps/acalc/Tests.js" rel="nofollow">https://github.com/foam-framework/foam/blob/master/apps/acal...</a><p>Q. Is foam an attempt to create a framework for Mobile Apps?
Video of the FOAM Empire.js presentation is now available at:<p><a href="https://www.youtube.com/watch?v=n699DWb2TUs" rel="nofollow">https://www.youtube.com/watch?v=n699DWb2TUs</a>
> FOAM is a full-stack Reactive MVC Meta-Programming framework.<p>5 years ago I would have thought that this would have been the title of the tech section of Onion article ...