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.

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.

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.

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?

I lead the FOAM team at Google.

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.

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

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

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.

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

Ironically, it's exactly on stories like these --- new Javascript frameworks, CSS templates, and the like --- where in-depth HN comments are most useful. I clicked the story, read it for 2 minutes, thought "you know, the top comment on the HN thread for this is probably going to tell me all I need to know about this framework", and instead found your comment.

You're not really contributing much here, and it's a frustrating attitude to see. We're still in the relatively early days of building the kind of apps that these frameworks are targeted at; the idea that any time spent on incremental improvement or experimentation is a waste, and instead we should; 'redefine how we write web programs' is just nonsense. It's extremely rare that things evolve in that fashion.

Yes, programming probably should be accessible to everyone. That's a gigantic, fuzzy challenge that's totally orthogonal to spending time developing tools that are useful in the immediate present.

And it's not like it's never been tried before. What about Hypercard, or more recently Scratch? Or Swift's playgrounds? All of these are looking at ways to make development more visual and accessible.

Your time would be much better spent contributing to those efforts than rubbishing the attempts of other people to deal with other problems.

There have been plenty of GUI programming tools, but most of them are pretty crap (the ones I have tried). MS Access had an OK query builder, but at the end of the day it didn't gain you anything over SQL. Java beans were touted as t a hot topic back when I was at university, but nothing ever came of them.

Syntax is rarely the difficult part in programming (except with CSS maybe). The way I see it, plugging parts as you describe together relies on a number of assumptions being made for you. The easier it is to plug things together, the less flexible each unit becomes. The difficult bit is choosing what assumptions are appropriate.

There are many solutions (e.g. Simulink, GUI builders, the "connected nodes" approach of Blender) for that, but they only tackle specific areas. I don't see that changing, either. And they usually don't address anything except very small programs (say < 5000 lines of code), while the exact purpose of these JavaScript frameworks is to deal with the larger ones.

I find it very strange that programmers seem to think their trade has artificial entry barriers. For some reason, mathematicians are not concerned with that. It's already fairly easy to get started with programming. Languages have come a long way, there are good IDEs and you can get started using just freely available software.

You should try React with JSX though. It's a tool like jQuery, but much more sane and structured, and as opposed to frameworks, it becomes more likable the more you use it.

Always baffles me how HN crowd can at the same time revere Lean/Agile mindset, and at the same time despise the same principles applied to the tools ecosystem. To me it's obvious that to make progress of any kind multiple attempts are needed. Naturally only few of all those experiments will survive, the thing is nobody knows which ones.

I am glad there are others who are looking into this same approach to build software. We are currently building just this. http://www.dhi.io

We want building web ui's to be as simple as having a conversation with another developer about the requirement.

This already exists, its called UML, and UML code generation tools. Wait, Have I just fed the troll?

That said - having frameworks emerge from the community rather than dictated is a good thing, it helps create a healthy ecosystem. Whenever a new "fad" takes over we actually _do_ learn something.

It could happen, but I suppose it would need very different architecture compared to CPU.

Do you want to help build a system that is universally distributed and allows creation by everybody? I want to build something that will allow every person to create software on their touch screens without having to fiddle with complex interfaces or text-based commands. Do you want to make this vision a reality?

Email me sethjgore@gmail.com.

It seems we aren't very good at catering for people who aren't like ourselves.