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?
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.
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.
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.
Related
I wanted to know if anyone has been using AirBnB Rendr and is it stable and ok to use in commercial projects or is it still changing a lot?
I'm developing a website which can run both client and server based, this mean I need to be able to render pages and widgets server and client based.
The server is running Node.js, dust.js and has custom server based code to render the pages and widgets on the server side. I need to pick how to handle it on the client side.
Naturally I want to try and not repeat code, but obviously the client is different I can:
Keep my current page based server rendering and develop custom
client side code.
Use backbone.js on client side and keep my server based code the
same.
Use AirBnB rendr that is based on Node.js and backbone to use the
same code on client and o server. AirBnB Rendr Library
I like the 3rd idea very much, but I'm looking for some input from you guys.
Has anyone used it? any experience with it in terms of stability and/or how often their api changes etc?
I've just started playing around with Rendr. If I ignore the learning curve and oboarding friction, I like it a lot and I plan to write my next large production app using Rendr.
Unfortunately, as bababa listed above, the documentation needs a lot of work. There is an explanation of how Rendr works in its README and the example app's README but beyond that you'll need to source dive in order to figure out how the gears are turning. Currently, there is no forum for questions (other than stack overflow :D) and I've had a hard time figuring out its idioms on my own.
Despite all the struggles, I finally see the light and I'm starting to understand why Rendr is so powerful.
tl;dr - If you're willing to source dive and figure out your own workflow, I would suggest using Rendr. Otherwise, I would recommend going old school by writing a traditional client app with a more mature library. (is it too early to say that? =X)
Well given AirBnb is a successful commercial enterprise, there's some validation that the library works well enough for them. This question is probably best answered by watching their github commit log for breaking changes. Given backbone is 1.0 and essentially stable at this point, rendr will probably quickly stabilize, but honestly your fear of instability is probably unjustified. I think rendr looks compelling and although my current project is using a very similar home-grown solution, I would consider using rendr in a future project or even porting our code to rendr. "Stability" per say is much less important to the web development community compared to other situations like packaged or embedded software.
I used (tried to use) and Rendr on a project and gave up. There are just to many limitations (currently) and the lack of documentation doesn't help. I ended up need to rewrite the source code to accomplish some things I would consider trivial with other frameworks, such as passing multiple collections to a view. It just wasn't possible (at the time I used it) and that was a deal breaker. Not being able to pass a collection of categories and results to a page was to much of a limitation.
I have no doubt it will eventually be ready for production use, but right now I would say unless you are an engineer at AirBnb and know how to hack the source then no, it's not ready.
If you really want to know if it will work for your needs, take a look at the issue list on github. That will give you a good idea where the projects at.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am really confused with everybody in JS community using Node.js and NPM with their JS libraries. Why do we have to resort to such extreme measures? What problems is this solving for us?
[Edit]
I think my question wasn't to the point.
Frameworks like Ember.js, Batman.js and more recently Yahoo's Mojito require me to use node.js - why this dependency on Node.js and NPM?
Why are we making things complex? "If you haven't already, you'll need to install node.js..." You read messages like this and you're turned off.
Why? There is already a problem of plenty in JS - far too many active JS libs/frameworks to choose from - going by the record of JS libs most will become inactive soon. There are just too many things to look for that often result in multiple frameworks in an app - dependency management, routers, MVC, templating, etc. On top of this we are using Node.js to use these libs/frameworks... How will this push usage of these libraries to new JS developers? JS was meant to easy!
"If you haven't already, you'll need to install node.js..." You read messages like this and you're turned off. Why?
NodeJS is Google's V8 "running on it's own". It's a JS engine with additional low-level API (Network,I/O,etc.). NodeJS provides "the missing platform" for JS developers, who were just limited to working on a browser.
why this dependency on Node.js and NPM?
Node.js, aside from using it as an app (servers, proxies, bots etc.), it can also be used as a tool build and aid development. Take for example Grunt which is a scriptable automation tool which is similar to Make. Scripting in just plain JS, you need not learn another tool or language to do automation. Another tool is Bower, which is a front-end package management tool. All you need to do is a bower install jquery and it installs jquery with that single command. No need for manual download, copy and paste.
NPM, on the other hand, is Node.js' package manager. It's a program that manages the modules you use on NodeJS. No need to list down your modules manually, and no need to remember them when you develop somewhere else. As long as you have the package list NPM made for you, reinstalling is just a matter of npm install.
Why are we making things complex?
We're not. In fact, we're making them easy for developers. Instead of worrying on your workflow, managing your libraries, or doing stuff manually, you can off-load these tasks to some of the modules that exist on NPM. Then you can just focus on what you are actually doing.
On top of this we are using Node.js to use these libs/frameworks... How will this push usage of these libraries to new JS developers? JS was meant to easy!
Like mentioned above, NodeJS is a versatile platform. It can be used as a server (Connect, Express), an automation tool (Grunt), a package management system (using NPM, Bower etc.), a testing platform (QUnit, Mocha), a proxy, game server, chat bot.
And it's beneficial, especially to the JS developer, since these weren't possible in JS.
There is already a problem of plenty in JS - far too many active JS libs/frameworks to choose from - going by the record of JS libs most will become inactive soon. There are just too many things to look for that often result in multiple frameworks in an app - dependency management, routers, MVC, templating, etc.
Well, it's good to have an abundant set of frameworks. Your work will be cut in half after learning some of them. Implementation diversity is also good, to address different styles of coding and different approaches of implementation. Some libraries rise from differing approaches, while others rise from the incompatibilities and/or incompleteness of others.
The developers are hard at work to make life easier for other developers by normalizing JS quirks (because browser vendors just can't seem to do the right thing of following standards) and most of them are done voluntarily, like free beer - you should be happy for that. Besides, nobody's forcing you to use one anyway.
The CommonJS standard (best implemented, in my opinion, by Node.js and NPM) introduces the concept of modules to Javascript. For years, the Perl and Python communities have demonstrated why modules are awesome:
Unix-style "do one thing and do it well" libraries that are small and heavily tested against bugs, that can be combined easily (with no namespace issues) to solve your particular task.
Central repository of open source modules (CPAN, NPM, etc) that you can easily pull the modules from (NPM takes it one level higher by keeping all of the versions available, so you can specify that your code uses the last known "good" version rather than hope that nothing broke when you redeploy a la CPAN).
Greater peer review of the code (since they are more easily composable, they're used in more varied situations, so this is what helps reduce the bugs, but also what helps improve the modules to be more generalized).
Greater variety of tasks solved. Since the libraries are short, pretty much anyone can write one. That does mean there's a lot more crap to filter through (articles about widely-used libraries help with this), but it also means a library that solves some very specific problem (such as localizing strings and dates ) probably also exists.
And then a Node module called browserify makes the actual build process for your client-side code incredibly simple, and you can use just about any piece of code you find on NPM.
This breaks away from the "kitchen sink" mentality of libraries like jQuery (who have developed their own custom build system so they can start modularizing their code, too) that believe they need to solve every problem their user might have, rather than just produce results that can be used by other libraries.
Very often you needs different builds of your javascript. Usually it is spread out in different files, sometimes its in coffeescript.
You often want a build AMD compatible build, as well as CommonJS one, plus regular minimized and unminimized builds.
There's also the potential for dependency resolution.
I've even seen a library that had a build for jQuery and protoype...
Edit: noticed I was answering the question as worded in the question body, but missed the compilation question in the title.
What criteria do you have for considering this an "extreme measure"? This has been done for years, for the sake of writing clean, easy to read/write code, but precompiled to be optimized for on-the-wire transfer (and perhaps other optimizations as well). Node.js makes a nice solution for this, simply because it's also using JavaScript and therefore familiar to people using it to compile their JavaScript code. Previously this was typically done in something like Python, which, though working, seems less sensical to me than sticking with a common language.
In reference to the mobile web app newsreader seen in: http://www.youtube.com/watch?v=vV85dNeGRhY
I'm making something similar, and I'm enthused by the growing buzz around Node. It's just that I can't wrap my head around it. I'm very close to abandoning ideals of a server running Node entirely until I have much more experience with JS under my belt, but I feel bad doing it.
On one hand, it's critical to have a quick and responsive app and apparently Node helps in that department, but on the other hand, I'm not going to have an app at all if I keep getting stuck reading tutorial after tutorial. I've come across a few decent copy/pasteable installation guides, but I feel bad doing stuff like that because I have no idea what is actually taking place, and I feel like I'll just end up creating an insecure application while also guaranteeing maintenance nightmares down the line that I have no idea how to deal with.
If Google didn't feel the need to use Node on their reader app, it would make me feel a lot better in my decision.
I want to rewrite a complete community website in nodejs,express and
nowjs with mongodb. Its currently in php using the codeigniter
framework. It includes functionality such as your own profile page,
photoalbum, guestbook, internal messages, contacts and more. And im
going to add an im to it and some other things like a forum and so on.
Its a pretty big project.
I have to make a decision about which techniques to use in the
webapplication. So i did a little research and found, node, Expess and
nowjs.
Should i stick to finish the application in php( codeigniter ), mysql
and ajax, or can i do this in express, mongodb and nowjs?
Can anyone recommend this for use on a live production site? And if
so, are there any security issues one should know about? General
guidelines?
Help would be really appreciated so i can make up my mind and finish
the project
Regards
George
The problem with Nodejs being young is not that it's a half baked product or something but infact it's growing very fast and new developments are being done at breath taking place. So you need to keep up with them while developing.
Otherwise there are huge projects out there developed totally with node and express. Take a look at expressjs.com/applications to see what kind of commericial projects are built using it.
As far as security, sessions etc. are concerned. Unlike ASP/PHP , you don't get most of the features out of the box. You'll need to either write them yourselves or using open source frameworks. Both ways you and only you have to ensure that your application has all bases covered. With flexibility, comes complexity.
It should be noted that Nodejs is optimum for real time I/O. If you think this is something which is required at your end then I highly recommend to go for it.
What you describe does sound like a big project.
If you have the time to spare, I would suggest picking a small portion of it that deals with managing secure sessions (e.g. the profile page). Implement that in Express to get a sense of how it compares to the existing PHP. If you like it, keep going.
Particularly when security is at stake, always try to use existing components when they are available. Node's minimalism makes it tempting to 'roll your own,' but it's very easy to make a security mistake with anything less than expert knowledge.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
So I finished watching Douglas Crockford's excellent series on Javascript, and in the final episode (so far), loopage he lays out why Node.js is a near perfect solution for server side code.
He talks about keeping state, not in the database, but in closures running in Node.js, he also states that templating systems (like JSP, PHP, and ASP) are a poor abstraction for more complicated Web Applications and that node.js provides a solution to this.
And I am ready to buy in, but I can't find any examples of Web Applications using this pattern, or any books or tutorials about how to go about doing this. I am not talking about a simple application, but something that would use the patterns that Crockford spoke of in his talk. Anyone know where I can find some tutorials/examples of Web Applications written in Node.js (and yes I know about Geddy and ExpressJs, but they don't seem to follow the radically different patterns that Crockford was speaking of, and were more like getting a Railsy experience on Node.js).
[Note from 3 years in the future: It seems like Express, Geddy, Sails, Kraken et all are re-implementations of the Rails/Symfony/Spring frameworks from Ruby/PHP/Java. Whereas things like Hoodie and Meteor are attempts at a whole new paradigm. KOA looks interesting, but is a ways away from being usable, but looks like it is building on the strengths of javascript with the history of MVC applications of the past. 3 years on and it is still exciting times for Nodejs, even if it is no longer the new hotness. At least there are a lot of real world examples of Node in use now...
I would suggest you check out the various tutorials that are coming out lately. My current fav is:
http://nodetuts.com/
Hope this helps.
The Node Knockout competition wrapped up recently, and many of the submissions are available on github. The competition site doesn't appear to be working right now, but I'm sure you could Google up a few entries to check out.
DailyJS has a good tutorial (long series of 24 posts) that walks you through all the aspects of building a notepad app (including all the possible extras).
Heres an overview of the tutorial: http://dailyjs.com/2010/11/01/node-tutorial/
And heres a link to all the posts: http://dailyjs.com/tags.html#nodepad
Update
Dav Glass from Yahoo has given a talk at YuiConf2010 in November which is now available in Video from.
He shows to great extend how one can use YUI3 to render out widgets on the server side an make them work with GET requests when JS is disabled, or just make them work normally when it's active.
He also shows examples of how to use server side DOM to apply style sheets before rendering and other cool stuff.
The demos can be found on his GitHub Account.
The part that's missing IMO to make this really awesome, is some kind of underlying storage of the widget state. So that one can visit the page without JavaScript and everything works as expected, then they turn JS on and now the widget have the same state as before but work without page reloading, then throw in some saving to the server + WebSockets to sync between multiple open browser.... and the next generation of unobtrusive and gracefully degrading ARIA's is born.
Original Answer
Well go ahead and built it yourself then.
Seriously, 90% of all WebApps out there work fine with a REST approach, of course you could do magical things like superior user tracking, tracking of downloads in real time, checking which parts of videos are being watched etc.
One problem is scalability, as soon as you have more then 1 Node process, many (but not all) of the benefits of having the data stored between requests go away, so you have to make sure that clients always hit the same process. And even then, bigger things will yet again need a database layer.
Node.js isn't the solution to everything, I'm sure people will build really great stuff in the future, but that needs some time, right now many are just porting stuff over to Node to get things going.
What (IMHO) makes Node.js so great, is the fact that it streamlines the Development process, you have to write less code, it works perfectly with JSON, you loose all that context switching.
I mainly did gaming experiments so far, but I can for sure say that there will be many cool multi player (or even MMO) things in the future, that use both HTML5 and Node.js.
Node.js is still gaining traction, it's not even near to the RoR Hype some years ago (just take a look at the Node.js tag here on SO, hardly 4-5 questions a day).
Rome (or RoR) wasn't built over night, and neither will Node.js be.
Node.js has all the potential it needs, but people are still trying things out, so I'd suggest you to join them :)
The closest thing is likely Dav Glass's experimental work using node.js, express and YUI3. Basically, he explains how YUI3 is used to render markup on the server side, then sent to the client where binding to event and data occurs. The beauty is YUI3 is used as-is on both the client and the server. Makes a lot of sense. The one big issue is there is not yet a production ready server-side DOM library.
screencast