[richmarr]

I'd love to see a mature app written this way (and I mean that genuinely, without sarcasm) and look at their project timeline, war stories, etc.

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.

[jasim]

I think UI programming almost always need a framework than a library, under these definitions of Library and Framework: Library = independent objects and methods that your code invokes; Framework = entry point to the app, controls the event loop that calls your code, and lets you hook into its lifecycle methods.

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...).

[orbifold]

Actually it can be feasible and quite convenient to have control over the event loop yourself, this is what immediate mode ui libraries and computer games are doing, in a way facebook's flux architecture plus react facilitates that kind of UI programming for the browser.

[jasim]

Thanks for the pointer to Immediate Mode UI libraries.

[kgr]

My name is Kevin Greer, and I lead the FOAM project at Google. Answers in-lined below:

> 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.

[kgr]

Sorry, that link is broken. Here's a working one:

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).

[aflinik]

Just compare number of well-known production apps written using React & Angular.

[sanderjd]

How? Where can I see such a comparison? Is it obvious to you which there are more of? It isn't to me.

[richmarr]

That's data on opinion, not data on success