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