FOAM: New JavaScript Framework by Google Engineers | Hacker News Reader

FOAM: New JavaScript Framework by Google Engineers

github.com

145 pointsoscarfr109 comments

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.

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.

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

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.

Thanks for the pointer to Immediate Mode UI libraries.

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.

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

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

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

That's data on opinion, not data on success

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.

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.

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.

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.

It was just publicly announced this week.

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.

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

If you load it off of the TodoMVC site, it loads much faster than the AngularJS version. If you load it from GitHub then it is slow because that isn't a packaged/built version (it's just loading directly from the repository) and is loading all of the individual models separately. We have a 'BuildApp' tool which can package applications for production, which doesn't happen when you load directly from GitHub.

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.

It reminded me a lot of R shiny clunky apps. But the goal is "fast apps fast" so yeh.

Try it over SPDY/HTTP2 and you'll have a very different experience.

Yeah, based on the Chrome network panel it is loading all the unminified view files separately. They should definitely combine and minify all the files to prevent a bad first impression.

I use Google's Javascript framework. GWT? No, the other one. Polymer? No, the other one! AngularJS? No, the other one!!

Closure Library?

No, the other one!

Google Gears?

Google Dart?

GWT is a set of tools which allows you to write JS front-end applications in Java.

Polymer is a library for creating Web Components.

> FOAM is a full-stack Reactive MVC Meta-Programming framework.

Inevitably reminds me of this: http://html9responsiveboilerstrapjs.com/

I understand MVC, but what is reactive meta-programming exactly?

Simplifying -

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?

It is very 'batteries included'. The demos use data islands and localstorage. You'd hook your DAO to something like Firebase instead. The Tutorial has a bug where it refers to DetailView it should be foam.ui.DetailView or something like that.

Doesn't seem to actually be by Google. Perhaps the title could be changed to "by a Google Engineer"?

I was at EmpireJS where this was announced and they said they had a team of Googlers working on it, and showed a few production Google apps built using it.

Interesting. Can you offer any details on which production Google apps were presented?

They probably have rights to the project under the respective contracts they have with the employees. That aside, having "<new project> by ((Google(|rs))|<$big_corp>)" in the title has generally been a reliable filter for projects that do not stand on their own merit, and this one seems to be no exception.

Exactly.

Everyone should ask himself/herself "would this be newsworthy if they didn't name-drop Google?".

As an experiment, I deliberately avoided adding "by Google" or similar when first submitting FOAM to HN while it was being tweeted about after yesterday's EmpireJS talk: https://news.ycombinator.com/item?id=9442943

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.

FOAM is built by five Google engineers who are paid by Google to work on it full time. It is a Google "project" but not a Google "product".

I lead the FOAM team at Google.

Check the COPYRIGHT file in the repo.

Just today I was thinking "there's not enough ajavaScript frameworks.", and BANG! Google solves my problem. Nice.

I'm not sure this framework is endorsed by Google. I can't find "by Google" on the home page nor about page.

Two of the authors work at Google. I think you are right though, this doesn't look like an 'official' framework.

https://github.com/foam-framework/foam/blob/master/core/Boot...

Curiouser: https://github.com/foam-framework/foam/blob/b75af78303f15826...

2012?

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:

   CLASS({
      name: 'Calc'

With babeljs you can use ES6 syntax like this:

   class Calc {
   }

Crockford talks about the bad features added to ES6, one of them class which he said is most requested by Java developers programming javascript.At the end of the talk he show way how to move out of classes/new in javascript https://www.youtube.com/watch?v=PSGEjv3Tqo0&feature=youtu.be...

Can you give a short gist of why they're bad and why should one move out of classes/new? What is the alternative?

From the video:

    function constructor(spec) {
      let {member} = spec,
          {other}  = other_constructor(spec),
          method   = function () {
            // accesses member, other, method, spec
          };

      return Object.freeze({
          method,
          other,
      });
    }

That looks pretty interesting and flexible on one hand, on the other, I don't see why it's better than classes. Is it just more explicit?

Doesn't support inheritance.

its mostly because of 'this' . as per the example above, you can prevent this by doing something like that.. freeze/seal

Five clicks in and I'm still not sure what it really is/does...

This presentation might help a bit: https://docs.google.com/presentation/d/1KQkRJOiEBDktgFSa3qle...

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.

On the demos page

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.

Until this is fixed, the source files for the demos are available here: https://github.com/foam-framework/foam/tree/master/demos

It does not seem a new thing, rather an old one just migrated it to Github.

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 )

Regardless of how good it is, the presentation could and should be improved. Quick to grasp examples, an explanation telling me which problems this project solves 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.

[1] http://en.wikipedia.org/wiki/Composition_over_inheritance

Actually it's one of their principles: http://foam-framework.github.io/foam/principles/#composition...

Currently all I see in demos is lonely rendered "f" symbol and slow as hell loading... https://github.com/foam-framework/foam/issues/295

They say it's reactive, but this is how they explained "reactive": https://foam-framework.github.io/foam/foam/apps/overflow/Ove... and https://github.com/foam-framework/foam/wiki/KeyConcepts#reac...

looking at the todo example, i was perplexed by the way templates are inlined through comments:

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

In case this is not already widely known, ES6 has that:

    var multiline = `line 1
    line 2
    line 3`;

EcmaScript 6 has got us covered: https://developer.mozilla.org/de/docs/Web/JavaScript/Referen...

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 (http://foam-framework.github.io/foam/tutorial/2-model/).

I don't think this is the framework for me.

interesting look, example documentation a bit spotty (pages missing eg: http://foam-framework.github.io/foam/foam/demos/ & others), rest of the docs ok.

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?

Another "higher performance" framework! At least dont throw these phrases around.

We have benchmarks (using queries extracted from real Google apps) that show that our query-optimizing caching layer speeds up IndexedDB performance by a factor of 100.

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.

Video of the FOAM Empire.js presentation is now available at:

https://www.youtube.com/watch?v=n699DWb2TUs

Seems similar to this: http://jsblocks.com

Would someone mind very simply explaining how this relates to (or differs from) Angular?

It seems every week there is a new javascript framework.

http://xkcd.com/927/

This sounds a lot like Microsoft's TypeScript.

Good God it's beautiful

> FOAM is a full-stack Reactive MVC Meta-Programming framework.

5 years ago I would have thought that this would have been the title of the tech section of Onion article ...

heh. I had a similar reaction.

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

Deleted comment

What I'm wondering is if it's better to be reactive or responsive.

Deleted comment

Well I'll sheepishly raise my hand and say I don't have a bloody clue what the sentence is trying to say.

Individually, the words make sense, but after trying to parse the combination I feel like I have less information than when I started.

This read like something From THGTTG

And hackernews wasn't full of snarky one liners. Did you even read further than that before you just had to get your comedy 'out there'?

I did. After reading the whole page I was not able to determine what it does ...

Edit: Also 5 years ago HN was even fuller with snarky one liners and eyebrow dismissals.

My apologies. I had a knee jerk reaction to what I though was wanton pessimism.

Having read the docs now I'm more inclined to subscribe to your initial onion theory.

It's been like 5 seconds since last new JavaScript framework was released. I really started to worry, so thanks for this post.

Reply on news.ycombinator.com