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.
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. (http://foam-framework.github.io/foam/tutorial/4-templates/)
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:
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
My gut feeling is that the 'frameworks are for prototypes, libraries are for production' camp is closest to the money, but (a) I have no actual data and (b) different approaches to frameworks will have different outcomes.
Under that definition, ReactJS is strictly a framework. But we tend to look at it as a library since unlike other monolithic frameworks (Angular, Rails etc.), it is quite small, composes well, and is not overly prescriptive.
While I don't think FOAM is the next-big-thing in Javascript frameworks (that award goes to React's component model), I am happy to see it focusing on the primacy of the data-structure and recognizing that good code flows from a good data structure. We can already use that philosophy in React by ensuring all components are annotated with propTypes, using a statically typed language (TypeScript), and clearly defining the API schema using something like JSON Schema (http://spacetelescope.github.io/understanding-json-schema/ab...).
> a mature app written this way
I've added links a number links to FOAM apps for you at the bottom of http://foamdev.com.
We have a number of mature apps. QuickBug, which is a codesite issue tracker, is about two years old. MBug is a mobile version, is about a year old. The ChromeOS calculator was written last summer as a demo but went into production just recently. There's also a rough but working GMail client. The Chrome App Builder is also in production, but, unlike the other apps, isn't open-sourced. We also have a couple very large internal Google apps that I can't talk about.
> project timeline FOAM was started in 2011, and generated its first production code, in C++ and JS for Chrome, in early 2012.
> war stories
Here's one: https://docs.google.com/presentation/d/139TUw8tLtqRzFSHGoLTQ...
I have several others as well, but I would need to scrub them before making them public.
Seriously though, I think it's borderline negligent to contribute any kind of hype to new javascript frameworks considering they are spraying out into the ecosystem like a broken fire hydrant. New javascript frameworks should be met with extreme skepticism, if not indifference, if we want this industry to be anything more than a joke.
Then others pick up on those ideas and so on and so forth. They don't simply sit there and say.."oh well...we should make our own framework because we don't like the ones that exist and want to make this industry incredibly difficult." No, most frameworks that have been released, especially ones that have been worked on by many people, have a purpose...a way of doing things different, that those team members like. If you don't like the way they have come up with...you don't have to use it. That's the beauty of it. There are many ways to accomplish front end development. Even in my case, if I don't want to use it ever, it is still benificial to see how others are doing things because you can take bits and pieces of their ideas and use them. Id' like to see more well thought out frameworks.
This "we have too many frameworks" crowd always post the same comments every time a framework is announced. It's becoming tiring hearing from you guys. Nobody is forcing you to use a framework... It's literally the same as saying.."we like how we did things 5 years ago, and we never want to change."
Welcome to the wild, wild, west of web innovation. If you don't like constant change, this may not be for you.
Pro Tip: If you learn JavaScript first and not a framework, adopting new frameworks can be done very fast. I find most of the people who post and cry about there being a new framework are the ones who don't really know JavaScript.
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 doesn't require a build step, which is why it can be run directly out of the Git repository, but that method isn't representative of production performance.
Polymer is a library for creating Web Components.
Inevitably reminds me of this: http://html9responsiveboilerstrapjs.com/
I understand MVC, but what is reactive meta-programming exactly?
Reactive:
The display automatically changes when some data changes
eg http://foam-framework.github.io/foam/foam/index.html?model=f...
the one clock moves when you move the other
Meta-programming:
The writing of computer programs with the ability to treat programs as their data. Examples of meta-programming include Lisp-macros and C++ Templates. FOAM does this through code-generation, but for Javascript, it does this mainly by dynamically creating prototypes as maps of functions.
The above is a bit cut and pasted - I have not fully figured what FOAM does
The reactive bit is quite cool in Meteor.js because if you change something in the database then any page displaying it updates on all clients simplifying things like chat apps. I have not figured if FOAM does that of if the "full-stack" bit includes the server side and database code like it does on Meteor. Anyone know?
Everyone should ask himself/herself "would this be newsworthy if they didn't name-drop Google?".
I lead the FOAM team at Google.
CLASS({
name: 'Calc'
class Calc {
}There is so much stuff in the source tree - including what looks like a complete UI layer - that I'm having a hard time grokking it from that direction.
Phrases like "can be used to generate code for any language or platform" and "FOAM is “written in itself”" make me want to understand what's going on first and how it solves whatever problems it sets out to solve rather than trashing it out of hand based on initial aesthetic impressions.
http://foam-framework.github.io/foam/foam/demos/DemoCat.html
All the links to "Source" take me to GitHub 404.
I would suggest this is the most important part of showcasing a new project.
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).
(first issue: https://code.google.com/p/foam-framework/issues/detail?id=1 )
[1] http://en.wikipedia.org/wiki/Composition_over_inheritance
Currently all I see in demos is lonely rendered "f" symbol and slow as hell loading... https://github.com/foam-framework/foam/issues/295
https://github.com/foam-framework/foam/blob/master/apps/todo...
it led me to discover that the full text of a function can be reflected through .toString() ...
i'm not sure i'd be happy to see this approach widely adopted though. it feels like a language hack, like maybe js needs a multiline literal string..
var multiline = `line 1
line 2
line 3`;I don't think this is the framework for me.
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.
Loved this bit in the calc demo source, testing: https://github.com/foam-framework/foam/blob/master/apps/acal...
Q. Is foam an attempt to create a framework for Mobile Apps?
See: https://github.com/foam-framework/foam/blob/master/demos/pho...
Also, load the Empire.js presentation and then press the '+' button on the bottom right. This will load and run all 25 slides at once, at which point you'll have over 20k data-bindings, both one- and two-way, 7k objects, 6k of which are currently being animated.
See: http://foam-framework.github.io/foam/foam/index.html?model=f...
We are capable of handling this many data-bindings efficiently because we don't rely on a digest/diff cycle. Since we generate the JS prototypes from our models, we are able to install hooks into the generated property getters and setters so that we can receive update notifications.
Also notice that our GMail client can perform searches on the keystroke.
I lead the FOAM project at Google.
5 years ago I would have thought that this would have been the title of the tech section of Onion article ...
These links (below) are a bit clearer, imho. The project actually looks pretty interesting, but the readme in the repo isn't as convincing:
http://foam-framework.github.io/foam/about/
http://foam-framework.github.io/foam/tutorial/0-intro/
Edit: formatting
Edit: Also 5 years ago HN was even fuller with snarky one liners and eyebrow dismissals.
Having read the docs now I'm more inclined to subscribe to your initial onion theory.
I lead the FOAM project at Google.
https://docs.google.com/presentation/d/1Ipt0hu2PHDgL8HCxkZN2...
The first part of the slides is on using the apps and the second part has a bit about how we developed it (but without speaker notes, it may not make a lot of sense).
Over on /r/javascript, my plain titled link has 2 points/23 comments while the "from Google" submission has 44 points/65 comments.
Not of much use for direct comparison purposes (GitHub repo links vs. project site links, different times of day, weekend vs. weekday etc.) but mildly interesting.
function constructor(spec) {
let {member} = spec,
{other} = other_constructor(spec),
method = function () {
// accesses member, other, method, spec
};
return Object.freeze({
method,
other,
});
}