18

Akin to this question, "I'm looking for the pros and cons of each framework and why one is particularly useful over the other" (but mostly what Flatiron has to offer, due to the fact that Express is already detailed pretty well in that question).

From my slight experience with Express, it seems to cover just about what you need and no more. Flatiron seems to do that, but much more minimalistically. If you check their website, you see that they offer around 5-7 main functionalities, compared to the many others included in Express.

Finally, which seems the most promising for a highly-scalable web app(s), and why should I use this or that framework over not using a framework at all?

Community
  • 1
  • 1
chrisdotcode
  • 1,569
  • 2
  • 17
  • 22

3 Answers3

12

Some update after a year and a half after this question was asked:

The first difference that comes to mind when comparing Express to Flatiron is that Express is a server-side framework while Flatiron is advertised as being isomorphic, covering both the server side and the client side and as such should be suitable to develop traditional server-side applications, client-side single-page application and everything in between (much like eg. Derby or Meteor). However, I have failed to find any examples of client-side usage of Flatiron, and not for the lack of trying.

There is an issue on GitHub to provide a simple TODO app example that's been open for over two years and (from what I understand reading the comments there) you cannot build a client-side app using Flatiron alone, without adding things like jQuery, Backbone etc. because the client-side aspect of Flatiron doesn't seem to be ready yet ("We are working on it. We still have a few more steps to go to make it completely isomorphic.") which seems like a real problem for a framework that tried to be isomorphic from the start. (See also a related TodoMVC issue: Add FlatIron example).

The conclusion is that Flatiron is not ready yet. When it is ready it may cover much more areas of Web development than Express does, but it's really hard to tell when it might be, if a simple TODO app example couldn't have been provided for years.

Meanwhile there are tons of Node frameworks and it's really hard to keep track of them so what I'd recommend doing now and in the future would be to see the list of Web frameworks on the Joyent/Node wiki on GitHub and compare them to the client-side frameworks on the TodoMVC project - where those both lists intersect would be frameworks that cover both the server and the client and are capable of writing a simple TODO app in them - which hopefully will include Flatiron one day.

rsp
  • 107,747
  • 29
  • 201
  • 177
  • Thanks! Since this is much more through than the previous answer, I've accepted this as the correct one. – chrisdotcode Sep 03 '13 at 20:44
  • why do we have to have it all, i don't think a front-end coverage is a must-have to flatiron. It's not like NodeJS is trying to build a front-facing website. – windmaomao Dec 22 '15 at 04:25
  • @windmaomao A front-end coverage (or even back-end coverage, for that matter) is not a must-have for any framework, but its promise was the main reason why me and many people got interested in Flatiron in the first place. It was advertised as a full-stack, isomorphic web framework. I don't know why it failed to deliver even a simple TodoMVC example. The question was about a difference of Express (a back-end framework) and Flatiron (a full-stack, isomorphic framework in the development with the front-end part not ready yet) so it seemed like an important characteristic to mention in the answer. – rsp Dec 22 '15 at 13:14
6

my perception is, that express is minimal, while flatiron seems to be more complete/complex. The best for scaling is a hard question, because both don't do anything to increase scale-ability of your app. They make developing an app easier by providing easy ways as exmpl to add routes (instead of yourself going insane with own faulty regexp).

Personally, I've come to love all the little connect and express middleware, as well as dynamicHelpers(for templating), which doesn't seem to be supported by flatiron (yes, they have middleware, but it doesnt seem as if you could use the ones from connect. EDIT; as it turns out, Union, which is flatirons middleware handler is compatible to connect, so you can use connect's middleware).

I'd recommend someone to use express over flatiron, but then again; I'd like to be proven better.

japrescott
  • 4,736
  • 3
  • 25
  • 37
  • I'd also recommend express over flatiron. The only reason we do this is because we've used express (and express works) but have not had the opportunity to battle test flatiron. On face value both should work equally well and flatirons resource manager is nice. – Raynos Jan 30 '12 at 12:17
  • Raynos; yep, I'd love to dig into flatiron, but until I do (or have more complex demands to my app), I'm sticking with express. – japrescott Jan 30 '12 at 12:19
  • @windmaomao `expressjs` is the most and next to `hapi` and `koa` one of the most utilized frameworks in node.js for web/http development. – japrescott Dec 23 '15 at 15:35
  • @japrescott, i understand that, but in my dictionary, i'll call AngularJS a framework, but i won't call jQuery a framework, although they can be frameworks. BTW, I do not know the clear definitions, i just play by guts ;) i know that can be wrong sometimes. – windmaomao Dec 23 '15 at 21:57
1

It looks to me that the battle Express vs. Flatiron is clearly won by Express.

There is no active development for Flatiron framework ATM.

See GitHub repository: https://github.com/flatiron/flatiron. The last release is 0.4.2 from Sep 16, 2014.

The official flatiron website http://flatironjs.org/ is down.

sg7
  • 6,108
  • 2
  • 32
  • 40