I was really amazed about's meteor.js features and ease of use, im really falling in love with it. I just wanted to know if you expert guys think it is stable enough for using it in production for a medium sized project.
Thanks for your advice!
Update Nov 2014:
Meteor 1.0 was just released, this is the first ready for production version finally, more on meteor check out this link
6 months with Meteor has the best answer to this question I've found so far.
Here are a few excerpts:
Meteor can’t be used for all real-world apps just yet. Meteor doesn’t have server-side rendering yet, so it’s not ideal for sites that need to load very fast (like e-commerce
sites) or work on underpowered devices (like older mobile phones).
...
So I would say right now Meteor will be a perfect choice for a few apps (anything that strongly depends on real-time interactions), a great choice for most of them, and a very bad one for a few specific cases.
It sounds like Meteor is definitely promising and particularly well-suited for real-time essential web apps, however it's not production ready for all web apps at the moment. At the time of writing this meteor is at version 0.7.0.1.
It's hard to answer this, because use cases vary so much.
I have an in-house application running on Meteor, which is basically a web-based SMS client with address book, fully integrated with our custom, in-house CRM. The Meteor app has 25 simultaneous users, and has been used to send or receive 70,000 SMS messages over the past 5 months, with total downtime measurable in minutes (which was due to network outages, not a problem with the application or framework).
There are definitely missing features, but assuming the features you need are implemented, the framework can be stable enough for production.
Really depends on what you're doing and how many users will connect to it. Using the current version 0.6.x you will need to tweak things that maybe Meteor devs are going to tweak, like MongoDB operations. Also, many packages are going to be released in future that will help a lot some work you are going to build yourself right now (for e.g. the IronRouter that C. Mather is building is very complex to build but very useful if you need complex operations in your app, like subscribing automatically in certain views, building forms etc)
Related
TL;DR is it unwise to build a web app using Meteor as our full-stack framework when expecting lots of concurrent users at scale?
We are looking to build a web app that in its first phase, is a product hunt for music (feeding user submitted URL's from Youtube's API for play requests).
The benefits of Meteor seem to how quick it is to develop an MVP/prototype for learning about user behavior, but the risk seems to be in banking on using what is built during this phase throughout the course of the products life.
Wondering if anyone can help my ignorant brain understand in laymen's terms if anything I've asserted above is incorrect/correct, and if so, why? Sincerely grateful for any/all input on this
The communication and CPU overhead for a meteor app without accounts or subscriptions is nearly zero. However, as I point out in the answer to this question, the real resource constraints come from maintaining query result sets between the server and the clients. In other words, scaling becomes hard as subscriptions increase in number, size, and complexity.
Without knowing more about your product and how it works, my general recommendation is this: go for it, because meteor is going to give you a quick MVP. If you find you have a difficult time scaling because of a massive onslaught of users (congrats!), then you can always reduce your subscription expense by using a variety of tricks including non-reactive data (method calls).
Recommended reading: Scaling Meteor: The Challenges of Real-time Apps
Not unwise at all. There's a website called ClassCraft built using Meteor, that I think gets 15,000 logins a day.
Your easiest solution would probably be to go with a Node-based hosting service such as Modulus which will handle scaling automatically for you.
The next step towards a more DIY solution would be to just host your MongoDB on a provider such as Compose or MongoLab, but host the Meteor app itself on your own server(s). Look into mup for a simple deployment script, or Arunoda's newer solution he's working on, mupx, which uses Docker to deploy Meteor apps.
This just scratches the surface, but hopefully gives you a little more confidence that it has been done and it can be done.
I've been working with Node+Express for a while now, and I'd like to start looking for a strong structure for building average to huge web apps, but which could also be used (and not be too much overkill) for simple websites.
I've been taking interest for backbone, but I'm looking for something much more "complete" already. I Know backbone can do everything with the right plugins and by respecting the best practices, but what I'm looking for is something more "strong" as is and from the start, like AngularJS, CanJS or Ember (maybe CanJS is the best compromise between flexibility and conventions althought all of this can be mostly subjective).
Just to be sure to keep into the best practices, even if I must stick to an opinionated FW.
Now, before choosing anything, and because I'll be using Node in the backend, so full JS, I'd like to know if there is a framework which would deliver client+server MVC capabilities, or if I must use Node/Express in the back and something else for the front.
Other info that may be useful, I'd like to code in CoffeeScript/LESS, and keep HTML as is (so no Jade-like stuff). If I'm not asking too much, I'd like to use this technology for all of my projects, which will be targeting also mobile phones, as websites (for sure), and sometimes even as Phonegap-based apps. Maybe this becomes hard (Meteor doesn't support Phonegap for it's client-side part for what I've read, maybe Derby ?).
Also, I must point out that I'm not asking anything subjective like "what is the best between ..." but simply if full client+server MVC JS framework exists, and if yes, which ones meets those needs.
rendr (backbone with server-side support)
meteor (very real-time oriented)
Meteor and DerbyJS seem great but very real-time oriented, I am not going for those.
I think I'll use TowerJS which seems to have really great features (live JS/CSS injection in browser when files updated, live node files reloading without restarting, pre-built development, staging and prod environments, MVC+ORM client+server-side, Redis for temp data and Mongo for DB...).
For Phonegap projects, I'll keep tower server-side and I'll find something else for the client, maybe simple backbone.
Take a look at the ExtJS 4. Also there is Sencha Touch 2 for mobile app development. Both of them has strong support for MVC.
sails.js is the most popular node.js MVC framework nowadays, and has a huge and growing community.
Meteor is also a great tool; my experience with the extjs community is that they are not very welcoming (rtfm noob! type of stuff).
Inspired by John Papa's video at Pluralsight, I started learning SPA. It appears pretty interesting. However, before I fully jump in, I'd like to clarify some of my questions.
From what I learnt, SPA is a lean server, fat client app. I think this should work well for small apps like what John Para demonstrated. Does it scale? How big it can be? Anybody has experience with this?
In SPA, you seem to code all the business logic in JavaScript. Is this a good idea at all? How do you hide the business "secret"?
With my background primarily in C#/WPF/.NET, moving to JavaScript seems to be very difficult (well, I learnt a little JavaScript more than 10 years ago - I hated it and never touched it again). With my limited knowledge, I ran into several problems. Debugging JavaScript seems to be a nightmare to me. The highly praised component Breezejs seems to be still in its early stage (e.g. it doesn't support UOW, doesn't support CascadeDelete, doesn't support enums). So, I'm wondering this is good time to jump in?
Directly to your questions:
Since the server logic is thin you can use some kind of cloud services and they scale pretty good. The most of the logic will be handled by the browsers of your users.
You should be careful if you depend on client. HTTP protocol can be easily manipulated. Don't forget that you should always do the validation logic both on client and server side! Also the "hidden" validation and other "secret" logic should be located only on the server.
Debugging JavaScript isn't so bad at all. You can use the built-in tools (Inspect element in Chrome and FireBug in Firefox, etc.) Also there are a lot of useful third party tools that will help you with the debugging.
If you start a new project just for your own use then I advice you to try the SPA approach. If you are writing production code you should become an expert in this area and then try to use these technologies.
Regarding UoW, take a look at the TempHire sample. It demonstrates using the UoW pattern on the client as well as the server.
https://github.com/IdeaBlade/Breeze/tree/master/Samples/TempHire
I believe SPA's provide a better framework for Business Intensive Applications as well as simpler application workflows such as that of Facebook. I have worked with Multi Page Applications for banking application with complex workflows and it get daunting to handle every thing and still keep up the application performance.
But I do think Knockout Alone wont be able to handle large applications as it is to connected in nature. I would recommend something like Backbone Marionete or Angular for that venture.
I am building a framework for large scale SPA development for the opensource community so I do believe it is the right direction.
Interested parties can go to my demo page at http:\saqibshakil.github.io I have demonstrated some of my work there.
i have been looking into it for months. My conclusion is to use Knockout with a light path.js or sammy.js for your url. I use json with a standard Visual Studio MVC ( which can return Json) as the backend.
I am still not done with the project but so far so good. It's lightning fast, elequent and lightweight.
Stay away from the frameworks. Get a look at the standard libraries: how they are written; You can learn a lot of JavaScript that way. Finally debug with chrome or explorer developer tools.
Good luck
I'm looking to build a rather robust application with NodeJS, however (being new to Node) I'd like some input from more experienced developers.
I've read some good things about flatiron, express / zappa, and others. Sadly it doesn't seem as though anything like http://ruby-toolbox.com exists for Node at the moment to really get a good slice across the spectrum of options.
Two primary things I need to keep in mind is that I'd like to work with CoffeeScript for development and this app will likely have a lot of interaction with a sister Rails app that also accesses the same database.
It seems that some of the projects I've looked at, such as zappa for example, haven't seen some developmental activity for some months.
What frameworks have the most community behind them and meet my hopes? Do you have any frameworks or combinations of libs that you find most useful together?
If you're coming from Rails, I'd recommend taking a look at http://towerjs.org/:
Tower.js is built on top of Node's Connect and Express, modeled after Ruby on Rails. Built for the client and server from the ground up.
Here's the thing: Node.js is less than three years old. It's attracted enormous attention from many exceptionally smart developers, but you can't expect the level of maturity that the Rails ecosystem has. Not everything in the RoR world has a Node.js analogue, and you're going to have to expect to do more low-level coding to get what you need done.
Yes there are a lot of great sounding but now defunct projects out there.
In terms of finding good active projects, this page is a good place to start: https://github.com/joyent/node/wiki/modules
Some of the modules I recommend include
Async
Forever
n
moment
Otherwise, express is virtually universal, and I haven't heard of flatiron or zappa before
I've been working a lot lately with web apps, mostly with javascript and json-rich web UIs.
I have to say I get impressed all the time with what I can achieve through these technologies.
More and more, I ask myself whether I would have preferred to go with a classic GUI to start with (whether it was C#/VB.Net + WinForms, or C/C++ + GTK/QT or Java or anything). I, however, have been able to accomplish everything I wanted in terms of a user interface with web-related technology.
And although I feel I have everything I need, more and more things keep coming in (and will keep coming in forever), like HTML5, new javascript capabilities, and probably even more things.
So, as web apps become even more and more able, I ask you:
How thin is the line between web apps and desktop apps as of now?
What is the future of this line? How capable will web apps be in the distant future? In this sense, is there a definition of what web apps should be, or are they just going to improve it more and more forever?
I would like to know what W3 has to say about it, though I haven't looked into it yet.
In reality we have simply come full circle in the computing world. The web browser of today is simply the green screen terminal of 30 and 40 years ago.
It used to be that you would buy time on a University's computer to run your program and then pay for time it took for your program to process and run. This was inefficient from an end user stand point since it was done in a batch and queue process so your results would have to wait till the next day. From the University's point of view though they had more computing power than they knew what to do with, so farming it out made sense and gave a nice revenue stream.
Flash forward a few years and desktops began to be as powerful if not more powerful than the University's computers and the days of batch and queue processing died off. But desktop centric applications suffer from a single fundamental flaw, multi-user needs. If more than one user needs to use the application at the same time, a server is needed in the mix to handle the multi session data needs.
The client application is useful for doing things such as data validation, but the thicker the client, the larger the risk you run with different versions of the client populating data at the server wrong.
The solution, the "web" client. Using the term web though is actually wrong in my personal opinion. The html/browser based client removes the issues found with multiple versions of a desktop client since all users are using the same version all the time. Gone are the days of deploying an upgrade across thousands of desktops. The browser based client simply needs updating on the server side and all users are instantly getting the new features.
To answer this question about the future, let's look more than a year into the past:
http://www.codinghorror.com/blog/2009/08/all-programming-is-web-programming.html
And in fact, it references an even earlier post from 3 years earlier. The future is Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript.
http://www.codinghorror.com/blog/2007/07/the-principle-of-least-power.html
Apart from some UI issues, web apps are real apps.
What is the future? Wish I had a crystal ball...
However, I would hazard to guess that the trend will go on and web will subsume most if not all of desktop applications.
Both have still their meaning. Webapps will get cover global connected applications, applications that exists because there is the web. They get really more important from day to day or the builder make us thinking they are important.
GUI still will be there because for a lot of people with not so much computer skills it is still easier to operate and understand. And there are really very very complex GUI application that maybe will get never into the web (CAD for example). Their complexity will be always in front of the progress of web development. You cannot catch them.
So I believe this line is notable and will be there for long time. Not all will get into the web.
Having just made the choice of using a "web" API or Desktop API here are the most significant differentiators that I see right now:
Support of native features
For example on the iPhone: Direct access to low level APIs
With the current browser development speed we should be there soon
Offline workflows
First steps done here with offline mode in HTML5
API support for "desktop UIs" (flexible, configurable, fast)
Libraries such as ExtJS are not there yet, but close
With WebGL, Canvas, and more and more powerful CSS features it has become a lot easier to create powerful UIs
All in all there is still quite a bit of work to be done but I think a few years from now there will be no difference between web and desktop applications, some of them will work offline, some won't.
Microsoft had that vision with .hta a long time ago, at that time it just wasn't powerful enough. Google is continuing now with Chrome.
Web apps will get closer to Desktop apps as the time goes. The reason behind this is the requirements. More and more people are hooking into internet and giving time or wasting time on net. So, requirement for browser is increasing. Second, as business are going global (globalization !) It is already global but in future the requirement is much more. Even small shop need to use internet for tax etc. Developing countries are using net in governance so checking for tax is easy. For all these even if a owner has 4 small shops then he need to have a aggregate data for his selling. So, all 4 shops better need interconnection and calculate everything financial every day.
People in a single team are working from remote. So, they need to share documents on regular basis. So, Google docs etc. Google docs has capability for online editing from various user at a same time. and still docs keeps synchronized.
Competition are increasing day by day. So, all business data need to be on one place for analytic. Who will collect all data from desktop application each day and synchronize each day. So, even if company will use Desktop app for speed and reliability then also he need some kind of net connection and synchronization software for those desktop applications. In this way you see that desktop app are getting closer to web app!
So, if you visualize all these scenarios then you will find it very difficult to avoid web applications.
Web app has future. For efficiency and speed, Web app will have a sort of software that will act as a desktop app and get downloaded when you use that.