What framework should I choose to build a web app?
... and 10 reasons why the answer should be "Meteor"

Dan Dascalescu, May 2016

What technology stack should you use to build a new web application? Python + JavaScript? Ruby on Rails + JavaScript? PHP + ... And so on - the choice was never easy. Until now.

JavaScript is the universal scripting language in browsers. This means that any modern web application will need JavaScript on the client. Why not use JavaScript on the backend as well then? This would save time and build expertise - a front-end developer can work on the backend comfortably, and they don't have to switch context between Python/Go/Java/Ruby/PHP/whatnot and JavaScript. Rather, we can use "one language - everywhere."

As of 2016, JavaScript is the most popular programming language for full-stack development as well as backend development. "JavaScript everywhere" is, becoming the de-facto standard for building web apps. The "MEAN" stack (MongoDB, Express, AngularJS, Node.js) is highly popular, and knowledge of "a JS framework like React or AngularJS" is listed as a requirement in many job descriptions.

But the MEAN stack still has many moving parts, is far more difficult to learn and use than Meteor, and offers a lot less out of the box. (Read more: Meteor vs. the MEAN stack).

What are we left with for the server-side then? Actually, why not look at an integrated, client-server, full-stack solution?

There are three such full-stack JavaScript frameworks in existence that I know of: Derby, Wakanda, and Meteor. The one with the largest momentum is, indubitably, Meteor. [2018 update: there is also Vulcan, a framework built on top of Meteor, adding GraphQL and using React by default).

1. The business case for Meteor.js

Meteor is an open-source, production-ready, real-time full-stack web application framework built on top of proven technology, that allows for very rapid prototyping and produces cross-platform code. Meteor apps run on the web, on Android and iOS, can be called from the command line, and work in any JavaScript host environment, such as Adobe extensions or the Internet of Things. Rather than being minimalistic, Meteor offers a lot out of the box, while working with other technologies in the ecosystem. A Tinder-like application has been built from scratch with Meteor in 6 weeks, several startups built with Meteor have already been acquired, the number of companies using Meteor is growing, and more and more companies are hiring developers familiar with Meteor.

Meteor is very well funded, and their Galaxy cloud app hosting platform is revenue-generating. The Meteor Development Group has received $31.2M in funding so far from the prestigious venture capital firm Andressen Horowitz, who has also invested in Twitter, Airbnb, and Foursquare. Founded in 2011, Meteor was a startup incubated by YCombinator, the most successful startup incubator. Meteor founders and early employees include former Googlers, early employees at Asana, and the creator of Etherpad.

Investing in Meteor is indisputably worth it, given the framework's developer base and momentum:

Meteor Day map

By contrast, the next most popular full-stack JavaScript framework, Derby.js, has 1/10th the footprint on StackOverflow, GitHub and Quora. Another worthwhile contender, AngularJS (albeit for the front-end only), is being radically revamped in the upcoming 2.0 version, and "users will need to get to grips with a new kind of architecture. It's also been confirmed that there will be no migration path from Angular 1.X to 2.0". Moreover, the consensus seems to be that Angular 2 won't really be ready for use until a year or two from now. Anyway, since v1.2, Meteor has official support for Angular.

Meteor is what we should have built in 1994 at Netscape
— Marc Andreessen, co-founder Netscape, Ning, Andreessen Horowitz


Meteor's community has been growing rapidly since launch in December 2011 and the Hacker News announcement in April 2012.

Metric Meteor Derby Wakanda Mean.io Mean.js
StackOverflow questions Calculating... Calculating... Calculating... Calculating... Calculating...
GitHub stars Calculating... Calculating... Calculating... Calculating... Calculating...
GitHub commits Calculating... Calculating... Calculating... Calculating... Calculating...
GitHub forks Calculating... Calculating... Calculating... Calculating... Calculating...
Twitter followers Calculating... Calculating... Calculating... Calculating... Calculating...
Tweets about homepage URL Calculating... Calculating... Calculating... Calculating... Calculating...
Homepage URL shares on Facebook Calculating... Calculating... Calculating... Calculating... Calculating...
... shares on LinkedIn Calculating... Calculating... Calculating... Calculating... Calculating...
... shares on Google+ Calculating... Calculating... Calculating... Calculating... Calculating...

The Engineering case for Meteor

Meteor was announced on Hacker News in April 2012 and web application developers stormed to it. Why? Watch the first 90 seconds of this video:

Two things to note here. First, the DOM is updating immediately, all by itself. I changed the data, and the template updates. There's no callbacks, no bindings, and no controllers. It just works.

Second, somehow, I'm using the Mongo API on the client. You've never seen this before. Up until this point in history, database APIs only worked on the server. But in Meteor, there isn't a server API and a client API. There's just the Meteor platform API. And it works everywhere.

The key is at 1:28: "Meteor is a client-server-database framework, written entirely in JavaScript. It takes care of almost all of the plumbing for you, allowing you to concentrate on developing business value.

Meteor works with your existing front-end library (e.g. Famo.us), and its own front-end library Blaze is perfectly integrated in the framework and fulfills the same purpose as Angular, Backbone, Ember, React, Polymer, or Knockout, but is much easier to use (and can be used with any of these libraries if you have to). Blaze is also faster than Angular in high-throughput rendering tests.

Meteor works with your existing back-end via REST APIs if needed, but you're better off using DDP, a simple and powerful publish/subscribe protocol. The server side runs on top of Node.js but eliminates callback hell by using Fibers. The underlying database is MongoDB and Meteor includes real-time and highly efficient monitoring for changes to data via oplog tailing.

While AngularJS is a front-end library and Sails.js is a backend one, Meteor is a full-stack framework, comparable with Derby.js, yet with much more momentum.

2. What makes Meteor easy to learn

Meteor Simple Todo List screenshot
  • Meteor has been called "embarrassingly easy to learn" when compared to AngularJS, which was characterized as being a set of "band-aids over self-inflicted wounds".
  • JavaScript everywhere - on the server (Node.js, Underscore) and on the client (jQuery). You only need to know one language.
  • Same MongoDB interface on the client as well as the server (no need to learn some new model code), via an in-memory MiniMongo instance
  • No esoteric concepts (unlike Angular), clear documentation, well-established coding conventions, and a shallow learning curve. A simple chat app can be built by someone familiar with JavaScript in about an hour.
  • Meteor gets you to your first live deployed web app right away. For beginners, having your own tangible project to hack on is hugely motivating, and that makes you much more likely to succeed in your goal of becoming a developer.
  • There is one book unanimously acknowledged as the best for learning Meteor: Discover Meteor, by the authors of many Meteor packages, including the package repository itself, Atmosphere.

By comparison, Angular is far more popular than it is effective (largely the result of having Google's name behind it), and its learning curve borders on the atrocious. As one developer who evaluated AngularJS has put it,

Angular is... band-aids over self-inflicted wounds


The Meteor community has created an amazingly handy application debugging tool that will automatically detect your collections and display your client-side documents, let you modify them, and control subscriptions - Mongol.

Debugging Meteor apps with Mongol

Besides that, Meteor has server-side debugging support, and the popular IDE WebStorm has released full support for Meteor, including debugging. Chrome DevTools is also an excellent client-side JavaScript debugger.

3. Database

Meteor supports MongoDB natively and future database support is coming, with the acquisition of FathomDB and MySQL support on the roadmap. Redis.io support is in beta. 3rd party packages provide support for MySQL, and PostgreSQL.

The pub/sub architecture makes changes in one client propagate seamlessly to all subscribed clients, without having to write any special code.

MongoDB does have its problems and there are community efforts to improve the support for other databases, or investigate new ones such as HyperDex, a faster and ACID-compliant alternative to MongoDB.

4. View

Meteor supports three view engines: React, Angular, and its own Blaze.

Just like with Backbone, Meteor doesn't depend on stuffing application logic into your HTML. There's no embedded JavaScript, template logic, or binding hookup code in data- or ng- attributes, and no need to invent your own HTML tags.

Better yet, Meteor's declarative templates, Handlebars-like templating system and one-way data binding free you from having to bind your view's render function to the model's "change" event, as you had to with Backbone.

Jade is supported for templating as well.

Thanks to its logic-less templates and automatic website reload on code and CSS changes, Meteor is very easy to use by web designers as well - they don't need any knowledge of the code or custom HTML directives.


When it comes to building custom components, you don't need to automatically use React (in fact, React itself may be a bad idea). You can use the built-in block helpers or one of the several community packages for building reusable UI components:

5. Routing

iron:router was the de facto routing package for Meteor. A powerful solution, it supports client or server-side routes, multiple views with yields, subscription management, plugins, hooks, route controller inheritance etc. In 2015, FlowRouter has gained more and more support in the community, and may become the new leading routing package.

Angular's default routing solution is clearly inferior to that of Ember.js and supports only one view. Thus ui-router was born four years after the release of Angular, and for DOM state preservation, the ui-router-extras addon is required.

6. Security

Meteor has built-in security against many common concerns, and lists framework-independent aspects to watch for.

  1. Meteor security design principles include code vs. data and client vs. server separation, stateful connections that must be deliberately authenticated, and allow/deny rules for database access.

  2. Meteor provides a full-stack authentication solution for logging in and signing up users, with email/password accounts, or using federated identity providers like Google, Facebook, Twitter or GitHub. Doing authentication in Node.js is notoriously tricky, and even in 2018, very easy to screw up. Meteor doesn't just abstract this grunt work (including verification and password reset emails) to let you focus on building your app. Meteor makes it ridiculously easy to add authentication:

    {{> loginButtons}}

Yes, that is one line of code. Once you've added it, you have a wizard that helps you set up all the API keys required to get your authentication system ready to sign up users. It's worth reiterating how easy this is, because well-established Authentication as a Service providers (auth0, Okta) have sample code that's hundreds of lines long.

  1. All user input is HTML-escaped when being displayed back to the client, thanks to the Handlebars-like {{...}} templates - a first defense against XSS. Furthermore, Content Security Policy support is provided by the browser-policy-* core packages. Browser-policy offers a very easy-to-use but powerful mechanism to prevent a large variety of attacks with only a few lines of code. Lastly, Meteor security guidelines advise on how to foil the remaining attack types (sanitize user-entered URLs and CSS).

  2. MongoDB is by its nature more resistant against database injections than SQL because it doesn't parse inputs, but there are still things to watch out for. One example is passing expressions where strings were expected:

    // user_supplied_id is "{$ne: 'nonexistentstring'}"
      id: user_supplied_id

    This returns all users, when the programmer expected one particular id to be passed. Meteor defends against this in multiple ways:

    • Data must be explicitly published by the server in order for a query like the one above to return it in the browser console
    • Operations on client-side collections are restricted. For example, records can be updated only one by one. The client cannot run arbitrary selectors because that would allow sophisticated attacks such as binary searching for credential values.
    • The check package includes pattern checking functions useful for checking the types and structure of variables and an extensible library of patterns to specify which types you are expecting.
    • The audit-argument-checks package ensures that your app has complete check coverage for all arguments to methods and publish functions.
  3. By using browser storage instead of hijackable session cookies, CSRF attacks are impossible.

  4. Meteor uses the best crypto to store hashed passwords - bcrypt.

  5. Meteor provides fine-grained control over method calls and database access -- see Discover Meteor - Setting the Security Record Straight.

  6. For the paranoid, a full-database encryption layer that runs on top of Meteor exists, called Mylar. It stores only encrypted data on the server, and decrypts data only in users' browsers.

There are still securities issues you should be aware of but those apply to any web framework. Meteor takes care automatically of the most common concerns.

7. Tooling

There's no need for Grunt, Gulp or Bower. Meteor includes SASS/LESS compilation, CoffeeScript to JavaScript conversion, and CSS/JS concatenation and minification. All these happen automatically and transparently when you meteor run your application, and when you change your code.

Hot code push means users are seamlessly upgraded when the HTML, CSS or JavaScript changes. Your server app isn't restarted if all that changes is client code. If only CSS changes, only the CSS is reloaded in the client. Also, there is no need to submit updates via the app store. Form fields aren't preserved when the page reloads on the client, but I filed a feature request for that.

Even if you don't use hot code push for your deployed app, it can vastly improve your development experience. When developing for mobile, having immediate updates in your simulator as you change code shortens your code-execute-test loop.

Deployment tools include:

  • automatic restart, process monitoring, load balancing and scaling to multiple CPU core on one server with Phusion Passenger, the most popular application server for Ruby
  • horizontal scaling across multiple machines with Meteor Cluster
  • performance instrumentation with Kadira: CPU and RAM consumption, subscription latency and throughput etc.

8. Testing

Meteor comes with built-in unit and integration testing.

Mocha test results

9. Mobile support

Mobile apps can be generated from the same codebase, using PhoneGap/Cordova. An app built with Meteor + Cordova + Famo.us has real-time data capabilities and can access native APIs, while being cross-platform, self-updating, and native-feeling. Deploying a simple chat app to iOS takes about an hour, assuming you have an Apple Developer account enrolled in the iOS Program ($99/year) - a limitation from Apple. On Android, no registration is necessary to run an app on a connected Android device.

Meteor mobile apps benefit from hot code push as well as web apps, enabling the developer to publish to the market (App Store/Play Store) only once. Subsequent updates will be pushed by the Meteor server to the app's LocalStorage (hot code push), and the app will also reload itself (hot code reload). As long as the app performs essentially the same function, hot updates are permitted by Apple's App Store policies. This enables continuous deployment on mobile without resubmitting to the App Store review process (which can otherwise be painfully slow) and without requiring users to download updates. Supporting new device capabilities still requires updating the app through the app store because access to new native components will be necessary.

In addition to out-of-the-box support for mobile development, Meteor can also be used to develop IoT apps. Thingstud.io is a a real-time user interface platform to the Internet of Things, built with Meteor.

10. Ecosystem

Atmosphere, Meteor's package repository, holds over 10,000 packages. Starting with version 1.3, released in March 2016, Meteor can use npm packages out of the box. This is huge - the Node.js ecosystem is the largest among all programming languages, with more than 250,000 packaged modules.

This makes Meteor a much richer framework than Backbone, which expressly states that, "You can read and understand the source of in an afternoon."

Case in point - while a login system with support for OAuth via Facebook, Twitter or GitHub requires several hundreds of lines of code with Angular, in Meteor all you have to do is add one core package and specify where to place the login button. That's one command and one line of template code. Password reset is included. Even with the most popular token login package, OAuth is far from simple with Angular.

Meteor could be even more open if it allowed using 3rd party packages directly, perhaps by using npm as its package manager (or at least Bower for the client). But there are good reasons why Meteor created a new package system: essentially, "isomorphic JavaScript" - the ability to use the same API on the client as on the server. This ranges from the HTTP package (HTTP/get works everywhere, and you don't need to switch from the request module to jQuery's ajax() call) to Minimongo, which makes it possible to use the same MongoDB queries on the client that you use on the server. An even more powerful consequence is that Meteor's build system ("Isobuild") can target mobile apps too. This is what enables generating mobile apps from the same codebase:

With Isobuild and Cordova, you'll be able to add a camera package to your app and use one simple Camera.takePicture() API to take a photo, and then type one command to build your app not just for the browser, but for the iOS and Android app stores too.

BONUS - Scalability

Scalability is by far the most under-explored area of Meteor. Which is a good thing - it means that other areas are well understood and battle-tested.

"Does Meteor scale" is an often-asked question, and the short answer is yes. The more nuanced answer is as follows:

  1. Meteor's business model (on the basis of which Meteor Development Group has raised $31.2M in venture capital from Andreessen-Horowitz and others) is providing enterprise-grade hosting for Meteor apps - a solution called Galaxy. Galaxy was released on October 5, 2015, and it is expected that it will scale very well. Below are several reasons why this is likely.

  2. Meteor is built on top of Node.js and MongoDB. Node is notoriously scalable - 1 million concurrent connections laughs at C10K and in raw terms, Node is faster than PHP. PayPal rewrote with Node.js their account overview page, one of the most trafficked apps on the website and formerly written in Java. The result: double the requests per second, 35% decrease in the average response time, and built almost twice as fast thanks to engineers being able to work full-stack in JavaScript. IBM wrote a white paper on highly scalable Node.js apps. Node is used at Yahoo!, eBay, Dow Jones, Microsoft, Uber, LinkedIn and other large companies.

    MongoDB is also highly scalable - used to store petabytes of data and perform billions of operations daily at eBay, FIFA, Adobe, Craigslist, McAffee, Foursquare and others.

  3. Meteor is most often used for new ("greenfield") projects. These typically have users in the hundreds, thousands or tens of thousands. By the time your new web app will reach a million users, you'll have resources to scale, and Meteor will have been optimized even further. For example, in December 2013, Meteor 0.7.0 introduced oplog tailing, a MongoDB driver which watches queries much more efficiently, without requerying the database on each update. Subscriptions that before took seconds to return data, now take under 30ms. Then in February 2015, MongoDB launched version 3.0, which brings 7-10x better write performance and an 80% reduction in storage by using compression. Meteor support landed in March 2015, along with a 10x Meteor speedup for write operations applicable to any version of Mongo.

    What's new in MongoDB 3.0
  4. Meteor itself doesn't scale well when processing high-velocity data (over 100 writes per second). Horizontal scaling doesn't help, but moving the high-velocity data into a separate database instance avoids high CPU utilization that Meteor would otherwise cause.

  5. There are powerful tools that help instrument and scale Meteor apps:

Bottom line - Meteor is still relatively new, and there aren't any Facebook-scale web apps built with it yet. The largest known Meteor deployment is ClassCraft, which handles 6400 concurrent users per server.

Unless you're rewriting a project with a very large user base, you can get started with Meteor and scalability won't be a problem down the line. Worrying about it now is like worrying now about reducing your tax rate when you're going to be a billionaire.

When not to use Meteor

Meteor is best suited for Single-Page Apps, and less suited:

  • If you want to build a website, not a web application. Meteor ships all template, CSS and JavaScript code to the client, which means it may take a few seconds for the first page to be rendered. For example, an individual Meteor blog post takes 5+ seconds until DOMContentLoaded and 9+ seconds to complete rendering, on a 3Mbps connection, and about 10 seconds to load on a 4G LTE mobile connection. By contract, StackOverflow.com loads in less than 2 seconds. For a web application, the initial loading time isn't that important (think Gmail). There are also ways to speed up serving the first page, and optimizing the initial page load is on the roadmap for the core as well. docs.meteor.com doesn't have subscriptions on the landing page, and thus loads in 4 seconds. For website SEO, also have in mind server-side rendering and spiderable.

  • When you don't need a backend - for example if a mobile/web application backend service like Firebase or cloud functions like Amazon Lambda satisfy your needs.

  • If you want to build a Progressive Web App. As of May 2017, Meteor still doesn't support Service Worker.

  • When you already have a backend you don't want to rewrite in JavaScript, and all you need is a client library for the front-end. In that case a UI library like Webix would be sufficient.

  • When all you want is to build a web-service / REST API, without a client. In that case, a Sails.js or Hapi might be sufficient, while Meteor could be overkill.

  • When core MySQL support is needed. MySQL support is on the roadmap, and there are 3rd-party packages that integrate MySQL reactively with Meteor to some extent. For reactive PostgreSQL support, there is numtel:pg.

  • When you need to squeeze every last bit of performance from your app.

    • For graphics-heavy mobile games, it may be better to build a native app (though Famo.us enables native-like mobile apps with physics and animation).

    • For applications with very large numbers of concurrent connections, Meteor might require larger amounts of RAM than other solutions. See the Scalability heading above.

      In other words, if you need Facebook-scale now, Meteor is not the best solution. But by the time you need Facebook scale, your app will probably be rewritten a few times, and you'll be able to throw money at the problem. Developer time and rapid iterations are much more valuable until that stage.

  • If you want to build your app using a WYSIWYG GUI designer/architect tool like Wakanda's, the Sencha Architect or the Servoy Developer RAD tool. Meteor does have Meteor kitchen, which is progressing rapidly, but it hasn't reached the level of maturity of vertically-integrated business applications solutions designed for ISVs. See though the Meteor-Webix integration and look into integrating with Sencha's ExtJS, the comprehensive and battle-tested widget library.

  • If your company lawyers are insanely strict about never using AGPL-licensed software such as MongoDB. However, read this post on why 10gen, the makers of MongoDB, won't pursue legal action (unless you fork MongoDB and resell storage as a service), and are even happy to provide a permission slip for your company.

What Meteor lacks

  • A native widget library. This is by design - unlike monolithic frameworks (Wakanda, Servoy etc.), Meteor offers all the plumbing and lets you use any UI components library works best for your project. Meteor "just works" with many client libraries (Bootstrap, Famo.us etc.) suitable for general web application design and UX. Meteor also works with Webix UI, a fast, nicely designed, mobile-friendly set of advanced UI components (tree, table, treetable, tab view etc.) that are great for developing admin and ERP applications, thanks to the meteor-webix integration which I put together with huge help from Maksim Kozhukh, the lead Webix developer.

  • Native support for developing Progressive Web Apps. The PWA architecture combines the best of web and mobile apps, but Meteor doesn't support Service Worker, or HTTP/2 + Server Push. Supporting these technologies would solve the slow first page load problem typical of Meteor apps, and would make lazy loading easy.

  • Native reactive "joins" for MongoDB (which doesn't have joins). There are, however, community packages for this.

  • A native mechanism to load templates dynamically. The feature is on the roadmap as "incremental loading". In the meantime, have a look at numtel:publicsources and numtel:privatesources, which let you create bundles for lazy loading resources, with or without authentication.

  • Blaze lacks two-way data binding as in Angular. This is by design. The Flux team at Facebook criticized how two-way data binding creates a major challenge for scaling applications because views can trigger changes in data, and data changes can trigger cascading changes in views, which makes it very difficult to predict the behavior of the app as a whole. The solution is to use an MVVM pattern, such as the viewmodel package. Of course, you can also use Angular with Meteor.

  • Native server-side rendering (useful for SEO). There is however a server-side rendering package developed by Meteor guru Arunoda Susiripala, and native server-side rendering support is also on the roadmap.

  • Full Windows support. Meteor for Windows has just received a shiny installer and its hot code build performance is as good as on Linux. The only major feature that doesn't work just yet is mobile development. Some packages (e.g. fourseven:scss) may also not install on Windows due to including architecture specific binaries, but that has been addressed with MDG making available Windows build machines. Now packages maintainers need to release new versions including Windows builds.

Meteor Windows installer
  • Easy explicit control over file load ordering. Currently, Meteor loads all .js and .css files essentially in alphabetic order (with some refinements), and if you don't want to rename files, you must add them into packages (which is actually a good way to organize your code). Packages create a load order via their dependency chain, and within the same package, you can also explicitly specify the load order via addFiles Package API calls. Still, an explicit load order mechanism is on the roadmap.

  • One blessed or recommended package for a given 3rd party library you find in its package repository, Atmosphere. The Atmosphere is in need of cleanup, given that there are often several more-or-less-maintained wrappers for some third party libraries. The good news is that starting with version 1.3, Meteor supports npm packages natively, and Meteor wrappers for 3rd party packages will become obsolete.


Only full-stack (client+server) frameworks are directly compatible with Meteor. It's mistaken to compare Meteor to AngularJS or Sails, because Meteor provides both the server and client part of the web app equation, while Angular/Backbone/Ember/React are client libraries, and Sails/Express/Hapi are server frameworks.

Full-stack frameworks

Many think that the MEAN stack is a comparable alternative to Meteor.js. In actuality, the MEAN stack is just a group of technologies used together. It offers far less than Meteor, and you have to do all the wiring between Mongo, Express, Node and Angular yourself. Read more at Meteor vs. the MEAN stack.

  • Derby - real-time framework for building collaborative web apps, with templating and server-side rendering support. Derby's data manipulation layer ("Racer") is built on top of ShareJS, an operational transformation library enabling concurrent editing of documents with eventual consistency between multiple users. "Racer provides a consistent API for managing data on the server and client, and seemlessly [sic] syncs the two with little thought from the user." Only supports MongoDB and Redis.

  • Wakanda - open-source web application framework for developing web and mobile applications in JavaScript. It includes a database server (WakandaDB), a JavaScript framework (WAF), and Wakanda Studio, an integrated development environment. Here's a 3-minute video of what Wakanda can do.

Server frameworks

  • Loopback - an open source Node.js framework built on top of Express optimized for building APIs for mobile, web, and other devices. Connect to multiple data sources, write business logic in Node.js, glue on top of your existing services and data, connect using JS, iOS & Android SDKs. There's also a Client SDK for Android, iOS and the browser (using Angular). Loopback's Juggler component can connect to MySQL, Oracle and Postgres and addition to MongoDB.

  • Sails - front-end agnostic real-time MVC framework for Node.js built on top of Express. Has an ORM that "provides a simple data access layer that just works, no matter what database you're using", "easy WebSocket Support" (wraps socket.io) and can auto-generate REST APIs.

  • Hapi - framework for building applications and services. Low-level API for handling HTTP requests. No database interface.

Client libraries


I hope you found this writeup informative in guiding your decision on a single-page application framework. Please leave any questions in the comments.

And by the way, if you're looking for a Meteor engineer, I'm available for consulting/mentoring - http://meteor.engineer.

My tags:
Popular tags: