[jasim]

This is a bold take on a problem that a lot of people have written away as reinventing the wheel. But color me impressed!

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

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.

[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

[gasping]

Bold, and beautiful!! Quick everyone, scrap all your existing frameworks and jump on the flavor of the week!

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.

[Cshelton]

Isn't that progress though? How else would we figure out a better way to do things if not to see how others are doing it. Many times a framework is, 'Here is how we've been doing things on our team, check it out! It might be useful to you as well."

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.

[narrowrail]

It looks like this framework goes back ~3 years. So, why would you consider it the 'flavor of the week'? Because someone posted it to HN? That doesn't seem to be much of a threshold. Also, it looks like this framework could be of use in other languages aside from javascript.

[kgr]

It was started in 2011, and can be used to target any language. It was first used to generate C++ and JS code in Chrome in early 2012. It is a Framework written in JS, not specifically a JS Framework.

I lead the FOAM project at Google.

[ben336]

It was just publicly announced this week.