I'm still a bit unclear on what the target market for Meteor is. Is this just for small to medium sized projects, or is it intended to be used for large-scale projects as well?
Since it seems like everyone wants to think of themselves as doing something huge, I'm sure the answer can't be 'no' to the second question — but I don't see any examples of significant projects being built on the platform. Actually, with that in mind, what happened to the gallery of projects built on top of Meteor? Perhaps I'm missing it.
All that being said, congratulations on reaching 1.0. There's clearly a lot of great energy and thought that went in to the project.
Meteor just hit 1.0 and is not the type of framework you can just start including in your stack.
You really have to build a meteor app from the ground up, so it is hard for established tech companies to get into Meteor when they already have spent years coding on another stack.
As new startups who use Meteor grow you will see those large-scale projects come about.
No, not at all. It's the other way around, really. Those who don't use Meteor for their projects may not be able to without trashing existing codebases.
What I'm hearing is that Meteor doesn't play well with others and that you should make the decision to go with Meteor carefully since changing your mind later will require a ground-up refactor.
This is pretty much my experience as someone who started working on a project where the lead dev had decided to use Meteor and then quit leaving a wonky prototype with "reactive data", poor performance and missing functionality.
Now, some would say "it's not Meteors fault the UI wasn't made well!" and then I'd reply "sure, but if Meteor didn't encourage (and it seems, require) tight coupling of the data access and presentation layers, then maybe we wouldn't have spent the last 3 weeks rebuilding the entire app from the ground up just to add some missing functionality and fix UI bugs".
Honestly, I really can't figure out the lack criticism I see of Meteor around here. All these comments to congratulate on an arbitrary step in version number? I see other articles of accomplishment with a fraction of the positive encouragement and many times the criticisms. Is there a silent majority, or did I spend the last few months being underwhelmed by Meteor because I'm missing something?
Meteor embodies, for me, a tool that makes things 'easy', rather than one that makes things 'simple'.
Meteor does make things easier, by making things simpler.
It is much simpler dealing with Meteor's API's then working with documentation from 3 or 4 different frameworks that you need to accomplish the same kind of stuff Meteor does.
Meteor gives you a set of clean coherent APIS to work with to get stuff done.
A lot of criticism of "new shiny tech" gets downvoted/flagged on HN so people don't even bother anymore, while another useless library in Go/Javascript gets pushed to the top of the front page.
Actually, you can use Meteor as a frontend-only framework. Just have the Meteor server be the client for a standard REST API. I've built an app using this approach.
No, it's a full-stack framework, using Node.js on the server and sending down a client app bundle containing all HTML templates and JS. The client and server then communicate exclusively with JSON through a purpose-invented pubsub WebSockets/SockJS protocol they call DDP. The client has a simulated MongoDB database and thus much of the API is isomorphic, so the client will simulate the server's code while it awaits the actual server response. Client changes to the data are immediately effected in the browser DB, while the change is authorized on the server, synced to other server instances with MongoDB oplog, and then pushed down to all clients subscribed to that data. The templating engine is then reactively informed of the data change, and the DOM is updated at the lowest level possible such as modifying an individual text node.
You need to be running the Node.js Meteor application. The client relies on DDP rather than REST and right now Meteor is the only server framework using DDP. There is, however, an isomorphic HTTP library which makes it easy to communicate with third party REST APIs on both the client and server. It is also easy to create REST endpoints for your Meteor collections, so that third party services which don't support DDP can communicate with your app.
It is very possible to use other client side frameworks such as Angular or Polymer, rather than just using Meteor's Blaze UI engine. However I find that Blaze's Template<--Helper<--Data<--Event system is extremely easy to understand and reason about.
Edit: Actually, they do seem to have a decoupled version of the Blaze UI that you could use just for your reactive DOM code and hook into a REST API. You just won't get any of the server-dependent features like full-stack automated data synchronization, hot-reload, live CSS injection, or Meteor's build chain. You just get a simple reactive template/helper/events system. http://meteor.github.io/blaze/
It seems like too much magic until you've been exposed to it a bit. It's actually pretty simple to visualize what's going on under the hood, but it takes a bit to click. Reading the DDP spec and the tracker package definitely helped me grasp the concepts. The new subprojects page is also great at explaining the major Meteor components: https://www.meteor.com/projects
We've built a huge meteor app that has scaled to 1000s of concurrent users and still growing -- there have been some sticky points along the way, but overall, we're extremely pleased. Meteor is an amazing engineering feat.
We will be sharing more soon. We've been developing with Meteor since the winter of 2012 and two main scaling issues have crept up: (1) the web tier was a bottleneck prior to 0.7.0's implementation of oplog tailing; and (2) post oplog tailing, mongo actually became our bottleneck with the write locks. We were able to get to about 3300 concurrent users (in our very data-intensive application) against a single beefy mongo primary before the database started choking, and at that point, we could set our readPreference to the secondary in order to further scale horizontally.
"We" are providing a large scale application in the education space, with more details to follow. I am not able to give much more now, but I can say that given the contractual nature of our application, we've been fortunate to start out with a HUGE user base that has taxed Meteor and exposed its scalability issues more than most typical Meteor apps at this time. It's still young, and there are some significant advances that can be made to its oplog driver, but overall Meteor is incredibly forward-thinking compared to other full-stack implementations. Philosophically speaking, you must be all-in, however, otherwise you will always kick against the goads. As everyone's favorite theologian would say.
"Apparently, "to kick against the goads" was a common expression found in both Greek and Latin literature—a rural image, which rose from the practice of farmers goading their oxen in the fields. Though unfamiliar to us, everyone in that day understood its meaning.
Goads were typically made from slender pieces of timber, blunt on one end and pointed on the other. Farmers used the pointed end to urge a stubborn ox into motion. Occasionally, the beast would kick at the goad. The more the ox kicked, the more likely the goad would stab into the flesh of its leg, causing greater pain."
It's definitely a win for hackathons and getting a MVP out there that needs real time features. I can't speak much for large scale projects since I haven't had the fortune of reaching that scale yet with meteor, but I'd imagine it will be ideal for that eventually simply by extrapolating the current growth and improvement trends of the framework.
At last months devshop in SF a speaker discussed straining the system and reaching the limits of Meteor with just hundreds of simultaneous connections:
Hundreds isn't really exactly "webscale", but I'm sure they'll iron it out, or it could have just been the application that was at fault. It's one data point however on how meteor scales.
[I work at Meteor and contributed to the MongoDB realtime driver]
Scaling low-latency data synchronization is a challenge for scalability for sure! We are gradually building better and better drivers with persistence to MongoDB.
The scalability can vary greatly depending on your application's data schema, usage patterns and amount of writes.
If you watch the mentioned talk carefully, the speaker describes a collaboration tool with log replay with a lot of actions and running from a single box.
The "running from a single box" at the end seems like it could be the most important part of the equation. Would you agree? Or rather, would that be the recommended place to start optimizing if your app runs into scaling problems?
I don't know how you could load balance meteor easily, but you could put your mongodb instance anywhere and pass in its location to meteor. This doubles your risk for downtime because of hardware failure though, your uptime is no longer as good as a system that depends on the uptime of a single machine.
In terms of complexity, the software I'm developing in Meteor has a lot of moving parts (animation, physics, artificial intelligence, and hardware integrations) and Meteor has handled it all tremendously well. In terms of user scale, I haven't had much experience, due to the nature of the project. It has made our development team tremendously happy, and provided a tremendous amount of flexibility compared to other approaches we've tried in the past including Objective-C and Java.
What would concern me is if you ever reach a scale where you need to optimize in ways that Meteor can't support. But, that probably falls into the 'problems you want to have' bucket.
I'm wondering if it's true usefullness is potentially in an Enterprise supplemental tool to cobble together some quick apps, maybe like what MS Access was used for a long time ago, except this time you get nice browser-based, reactive applications.
I'm not sure you'd use it to build the infrastructure of your startup on. Or a content heavy site. But I see building tools like for managing a lot of developer instances, internal tools for config, etc to possibly be pretty sweet for this.
Congratulations on 1.0 but these kinds of buzzwordy lines
Accomplish in 10 lines what would otherwise take 1000,
thanks to a reactive programming model that extends all
the way from the database to the user's screen.
Really bother me.
Show me where you eliminated 1000 lines of code and how it was beneficial. Each line of code, to me, is placed with purpose and intent.
Are you eliminating thousands of lines of boilerplate? Or are you making best guess assumptions that fit the common need, and we still end up with those 1000 lines for something truly custom?
(Disclaimer: I work at Meteor) That box is referring to the data syncing, event handling, and view rendering code that you don't have to write when you use Meteor, compared to some of the previous generation frameworks.
If you put together the right list of cutting-edge components like React, Firebase, Bootstrap, and some build tools, you might get a similar improvement in code simplicity. Our goal at Meteor is to give you the same benefits without making you write code to plumb between several different frameworks.
I'm doing a rebuild of a personal project over the holidays and I spent some time looking into binding together React, Airbnb's Rendr, and JSX through Browserify and Grunt. It's possible, but it's a nightmare. Meteor definitely succeeds and just delivering that.
(Not that that is the only requirement you might have.)
I'm using React. My server-side rendering is essentially `React.renderComponentToString(App(data))`. The only difference between how I invoke my app on the server vs on the client is that instead of `React.renderComponent` I use `React.renderComponentToString`. On the client, React just uses the pre-rendered HTML and binds itself to that without re-rendering a single DOM node.
All my scripts are in `package.json`. I don't use Grunt or Gulp. If I want to re-bundle my client, I invoke a script that essentially does `browserify -g uglifyify lib/browser.js > dist/main.min.js`. My JSX build script and the bundler script are automatically invoked by a watcher.
This[0] is my entire build script and the only reason it's verbose is because I like to be able to execute each task separately if I want to.
The only problem with React is that it is only a view library. It only does components. The blessed solution is a Flux-like architecture as implemented by Fluxxor or Reflux, but you can integrate React into nearly anything you already have. I like the immutable/unidirectional approach React and Flux share and ended up writing my own library[1] because there were things I didn't like about the existing Flux implementations, but you don't have to do that.
I have to admit that Flux has a steep learning curve. And if you've never dealt with immutability before it can really melt your brain. But I don't see how Meteor is any easier to pick up, especially considering that it comes with its own entirely separate ecosystem (the only non-node library I use in my React app is an XHR-wrapper that replaces `request` on the client).
I agree with you that it probably is not easy to pick up, but I have to admit, there is significantly less to deal with. Meteor is the fullstack, and it even has sockets built into it. You definitely have to buy into one ecosystem, and that's convenient because you don't have to know a serverside ecosystem (e.g. Rails) and a frontend ecosystem (e.g. Angular, React, and Ember).
Sure, but my current ecosystem is npm. For browser-specific substitutes to node-specific code I simply use browserify. If I decide React is boring, I can switch to an entirely different front-end without changing anything else. For stuff that isn't on npm I have to work with bower or something else, but that (i.e. ecosystem-external dependencies) is a problem in any application, not specific to npm.
With Meteor, you're developing Meteor apps. Sure, you can put a different front-end in it or replace its server-side with an API compatible equivalent, but that's like saying you can use Django without its template system or ORM (if you don't know anything about Django: you can, but Django's built-ins provide a lot of synergy that you can only get from tight coupling).
There's a lot to like about Meteor. Just compare setting up some kind of "dream team" of JavaScript: Rendr + React + Grunt + JSX = OMG WHERE DID MY FRIDAY NIGHT GO.
Meter out of the box "just works," but it only works with Mongo for now, and it only works if you are all-in with the platform — on both the client and the server side. Those are two pretty big bets to make.
I would say Meteor is ideal for learning, except that it's important to learn what the request-response lifecycle is all about, and I think it can be detrimental when a "magical" framework does so much for you.
And one thing I just can't get over -- page loads in Meteor.com feel super fast. Until you realize it actually downloaded the contents (not the unseen images, of course) of the entire website! DPP is doing some interesting things, but some of Meteor is some nice magic tricks that we've seen before. 600kb+ of JS on page load is certainly an interesting concept.
Huge amount of work by a talented team. A super nice community. As for the framework itself, give it some time, let it grow, but most importantly, understand objectively its strengths and risks. It has both!
First of all, why is JSX in that list? It's essentially an ES6 transpiler with syntactic sugar for nested function calls. If you mean the additional build step it requires, that doesn't really make sense either: you should be bundling and minifying your client assets already and JSX is just another (fully transparent) link in the build chain.
Secondly, why Rendr? Rendr was built for Backbone. The most recent info I can find that suggests using Rendr with React is over a year old. React can be rendered on the server just fine. The only thing you need to solve outside React is routing, getting the data and making it available to your React components. Either use stores or pass all the data as `props`.
Thirdly, why Grunt? If you talk about a "dream team", I'd think Gulp is the current hotness, not Grunt. And you don't need either of them anyway, there is so little to configure that you don't even need a full-blown build tool.
I don't have a single line of database code in my React app. All the API calls are handled by a small wrapper around my database's domain-specific HTTP API. I could use the same API with zero changes for a native mobile app or a new web app that doesn't use any of the existing code. My web server is a dumb proxy for the database API and a pre-rendered for React (the pre-renderer essentially consists of a single line of JavaScript).
I can understand the appeal of Meteor, but it's not like anything you complain about has to do with React.
(Now Angular on the other hand... let's hope you don't need any prerendering ever.)
I switched from Grunt to Gulp because I never liked Grunt's focus on configuration over code. But that's entirely a matter of taste. It's not "better" or "worse" than Grunt, it's just a different approach.
Gulp is pretty neat, until you try to integrate watch tasks. Want to run a transpiler whenever a file changes? Better don't have any compile-time errors or your stream will choke and die (without necessarily killing the process, mind you).
There are some workarounds (e.g. gulp-plumber), but depending on the actual tool you're trying to use they may not actually work -- or only work sometimes, which can be just as bad as not working at all.
Personally I've switched from Gulp to just putting scripts in my package.json file as god (or Isaac) intended. Every tool I want to use has a CLI anyway, and supports stdin/stdout, so it's all just Unix legos anyway. Except for browserify, which I replace with watchify in development for performance reasons (browserify in a large project can take a few seconds, watchify only updates the diffs).
Yeah, one of the common critique is that "Meteor" does too much and doesn't integrate well with other stuff.
For me it's a main advantage, I don't need to use "other" stuff to get the final effect.
I wrote few projects and it's the best framework if you start from scratch. Though it's hard to swell if you need to add it later to some existing project.
I absolutely agree, but I don't understand why Meteor is frequently seen as a competitor to React or AngularJS or Ember. It's a competitor to combinations like node/browserify and full-stack solutions like Wakanda.
Meteor doesn't integrate with anything, but that was never a design goal. If you switch from Meteor, you can likely discard your entire stack (well, except the database obviously). It's based on node, sure, but that's an implementation detail.
Meteor is not a node-based stack. That's why it now has its won package manager instead of npm. It's a competitor to node with its own ecosystem. And that's fine.
Well, you can compare it as a fullstack too. It is mainly compared with React, Angular, and Ember as a reactive framework which isn't an incorrect comparison and is very valid.
Sure, but good luck replacing React/Angular/Ember in your Rails/Django/Node/What-have-you app with Meteor.
It's not really a relevant option unless you are at liberty to swap out the entire stack. It makes more sense to compare Meteor with MEAN rather than simply AngularJS itself.
I wonder if the criticism that the Flux team at Facebook has directed at two-way data binding is also applicable to Meteor. Jing Chen is her intro of Flux (https://www.youtube.com/watch?v=nYkdrAPrdcw&list=PLb0IAmt7-G...) says that 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. Wouldn't Meteor face the same challenges?
In other words, if you believe that the Flux design pattern (which involves a central dispatcher as the only entity capable of updating the data) is sound, shouldn't you stay away from Meteor's model when building large applications? Or am I missing something?
Meteor doesn't use two-way data binding. You have template instances, which are wrapped domranges based on handlebars templates that call helper functions (one way binding). You then have event handlers for templates that you assign to class selectors, which will be delegated to each template instance that is created. You then manually change the data within event handlers.
That's an interesting point. I find two-way binding to be very convenient, but I wonder if the industry is moving towards a one-way bind solution (at least it seems like a common theme with most front-end frameworks).
This is quite surprising to me. I know that Pete Hunt -- one of the authors of ReactJS -- and one of the main proponents of using it in conjunction with Flux, gave a talk at Meteor Devshop 11 earlier this year (http://youtu.be/Lqcs6hPOcFw?t=48m7s), and didn't say a word about the problems associated with two-way data binding. To me that would seem to be the elephant in the room. Is that because he treats Meteor as a framework for prototyping and smaller scale apps?
I've read somewhere that a use-case of Meteor is to let you write your server-side logic in javascript, and then run the server-side logic on the client. Wouldn't that be clearly insecure, to trust the client with running server logic?
Also, this was accomplished years ago with Google Web Toolkit, which lets you write both the server & client in Java, and compiles the client-side java to very efficient, optimized javascript. That has the added advantage of letting you use a sane, strongly typed language, with all the productivity tools available for Java, and none of the quirks of javascript. http://www.gwtproject.org/overview.html
The logic runs on the client only for optimistic UI changes (getting to the right state and displaying the right data w/o waiting for a server to reply). In Meteor this is called "latency compensation" and you can read more about it here: https://www.meteor.com/full-stack-db-drivers.
Meteor implements it in such a way, that app developer decides what logic is latency compensated and what is not. Furthermore all the actions validation rules still apply on this executed logic and if clients disagree with the server (the privileged environment), clients cannot harm the server state.
Querying your database from client javascript seems like a bad idea. Even if they're not real queries, you are exposing the internals of your system, db column names / queries, etc.
This is something that I've wrestled with when working with meteor, how do you execute privileged queries from the client? You can do a 'Meteor.call' to execute code on the server, but there is no way to shield the user from accessing the parameters used in the query.
Traditionally, you would use a cookie on the client to authenticate and trigger the 'privileged' query during the http request cycle. As far as I can tell there is no way to do this with Meteor. Another way to phrase it is there is no authenticated server-side state modeling the client.
In the same vein, there's no way to shield the user from accessing the parameters of a REST request. Which incidentally is easier to replay outside the browser than a Meteor.call().
After doing some poking it looks like you can access `this.userId` in the server-side publish and Meteor.methods functions. That's enough to prevent a lot of client-side tampering
Trusting the client with all things is a bad idea. Running stuff like presentation/layout/gui on the client makes sense. For some things, it makes sense to run the same code first on the client, but the again on the server (so not really trusting the client). Example: form validation. You want to run it on the client, to give early feedback. You need to run it on the server, because you can't trust client-supplied data. Makes your life a lot simpler, if you only need to implement the validation code once, even though you use it both on the client and on the server.
If you read the docs you will see it's not implemented in an insecure way. The core meteor devs are pretty brilliant people, creator of etherpad, svn core contributer, early asana employee, these people aren't dummies they wouldn't do something that silly. Such a dumb thing would have been called out way before 1.0 wouldn't you think? Maybe give it a moment of thought before you comment.
Well to be fair, even smart people can make mistakes and miss things. But Meteor is open source, so if the person you responded to is going to question the security model, they can look at the actual code and see if there is an issue. That's the best way to prevent security issues, looking at the code for bugs, mistakes, and assumptions.
> Such a dumb thing would have been called out way before 1.0 wouldn't you think? Maybe give it a moment of thought before you comment.
To be fair, I'm pretty sure the previous versions did have this issue -- it was just supposed to be ultimately fixed. I could be recalling incorrectly though.
It was fixed about two years ago in October of 2012, when they added the accounts system and allow/deny rules. Since then they've added additional security features such as the browser policy package.
I haven't looked at Meteor in a while, but am really impressed with how the vision of Meteor and the code (and of course the website) have evolved.
Meteor looks extremely simple to get up and started with, and I was thoroughly impressed by the implicit modularity of it all ("meteor create" makes like 3 files, I think that's awesome)
They really try (and succeed) to rid ourselves of the duplication on server and client. And if the android/ios support is as easy as it looks, this is an insanely useful framework.
I'm going to use it in my next project for sure now, just need to see how template/module composition works
Phonegap development is still phonegap development, even with Meteor. That said, I built a prototype chat app and deployed to iOS in about an hour. It really was that easy, and the app runs terrifically well. The "write once, run anywhere" mantra is a little more real with Meteor than with other approaches I've used before.
Thanks for sharing -- that's awesome to hear, yeah, Phonegap definitely has it's warts, but I like the idea of being able to at least get SOMETHING up so quick (to match the web interface
While I do enjoy the bleeding edge on which we live. I'd love to wait to have the discussion about the new Meteor features until their site and newsletter tells us about the release.
Sure the git commit is a landmark, but there's nothing to offer other than 'kudos' with this link as the discussion point.
When the first release of meteor came out, I was really impressed by the product.
The real time update of the web page with zero code was an amazing feature.
Today why I need of Meter?
Server side I have multiple choices that guarantee me heigh scalability, performance, and real time.
Also the mongodb solo option, without sql is very restrictive.
Client side, there are great js frameworks like React, Ember and Angular
that are great modular libraries.
SQL support is on the roadmap [1], along with other great features [2]. By the way, it is also possible to use Meteor mostly for the backend and use a framework like React or Angular for the frontend, although I don't know if there are big advantages with such a setup.
I think Meteor is a great concept because of their seven principles [3], which I haven't seen in any other framework. I haven't worked with Meteor yet but will start a project in short term which uses Meteor, so I'm very excited to see how this works out.
I'm not really confident about new version the releasing of version 1 was too long.
Also I do not see a strong open community that support them like Rails, Django o Node.
Of course I wish them to grow in terms of contributors
There is a pretty distinct and active Meteor community, though from the outside it's hard to tell how much of that is just people who are interested in it because of the hype (kinda the problem MongoDB had) vs people who actually use it and know what they are doing.
I wouldn't say the wait for 1.0 is a good indicator of stability or success, though. Node.js is still at 0.x and so is React. AngularJS took a long while to get to 1.x but is now actively working on 2.0.
Many developers are cautious about when they dare calling a product 1.0. Until the idea that "if your code is in production, it's already 1.0" gained some ground, there was barely any code on npm that wasn't stuck in pre-1.0 land.
The real indicator is how much time passes between minor or bugfix releases. Ideally the latter should happen fairly regularly and the former not too often. If Meteor hits 2.0 anytime soon, that could be a worse sign than if it sticks with 1.0.x for "too long".
For everyone looking to learn Meteor the first 8 chapters of Discover Meteor are available for free for the next week. It is probably the starting book for everyone :)
https://book.discovermeteor.com/starter
Also the Manning book Meteor in Action is 50% off the next week with the code jiafinal50
The book is in heavy development with updates every couple of weeks. However it is still not finished and lacks some advanced chapters still.
http://manning.com/hochhaus/?a_aid=yauh&a_bid=aeff5509
Apress also has a book called Beginning Meteor but it has almost no relevant content as of yet and no updates in the last months.
http://www.apress.com/9781430268369
All Packt titles are hopelessly outdated for version 1.0, so you better stay away from them.
This is really awesome, I just checked out the new website and docs. Everything is so much more clear, I love the new docs. Stuff is laid out really well, people new to Meteor are gonna really like this.
Great job, Meteor has really helped me develop my programming skills as a beginner. It allows me to get instant feedback on the code I write. To see a real world prototype keeps me going!
How does one start a project like this and get paid? What are the revenue sources for the team? It's a great product, and the fact that it's open source is amazing.
Create an awesome framework that people want to use (Meteor started out as a travel guide site, I believe, and other YC batchmates wanted to use their web framework)
Step number two:
Keep building the web framework
Step number three:
Raise money to keep building that framework, with a partner who believes for the long term
Step number four:
Keep being awesome, and become the tool that a ton of devs want to use
Step number five:
Monetize with your own enterprise support and hosting
Meteor is already easy to setup, but for those of you on Windows or who want a clean sandbox to develop meteor apps, we launched a custom Meteor template on Nitrous today. We also increased the free resources:
Meteor hit 1.0 b/c their APIs are stable. I'd also guess that the software has hit a level of maturity where the Meteor team is comfortable with a supported release.
As for Node, there are some within the Node community who would like to bump it to 1.0 as it is clearly production ready. In Node's case, .1 vs. 1. is a just a numbering scheme issue, not a production ready issue.
Congratulations to the Meteor Development Group! I've been using Meteor for 16 months now and it's amazing how much it has changed/improved. It is a great tool to learn for any beginner web developer.
Also check out a catalog of the best Meteor learning resources at http://MeteorHelp.com
I just went through the tutorial on meteor.com, and I'm impressed with the speed of getting results.
When I were to build another online app, I'd split that in building the frontend and the API composed from microservices, so that I'd be able to offer access through the UI and the web API. Is Meteor a good choice for this approach?
First of all - absolutely love meteor. Couchbase/CouchDB support would be fantastic! More (NoSQL) database support would be fantastic. I worry that it's so MongoDB specific now and the "scale" technologies are MongoDB specific (Oplog tailing only) that adding other databases in the future will become a lot more difficult.
Congrats to the team - maybe it's just me, but it seems like you guys to to 1.0 pretty quickly
edit: random aside, I literally just saw the transition from the preview website to the 1.0 website as it was hotswapped in, and I have to say it looks _much_ nicer!
Wow that was fast, I can't believe Meteor is already at 1.0! This is really exciting times, so much progress has been made with Meteor. Ill upgrade my meteor app as soon as the official release is out.
The data isn't reactively loaded in realtime, but Meteor itself is still reactive. What I mean to point out is that even if you're depending on say classic JSON APIs, the meteor app within itself can still do reactive-features (templates, local collections, etc). And depending how you implement things, you could still take advantage of push capabilities for your data from a legacy endpoint.
But yes, I agree, it's not ideal until a SQL adapter is available.
Meteor is awesome, congrats to the Meteor team for their 1.0 release! I've been using Meteor for over a year now, and it is staggering how far it has come. They've addressed and continue to address just about any concerns the community has brought up, from security to speed to tools, etc. And where they haven't, the community has stepped up huge. Seriously, Meteor is amazing, but what makes it even better is the awesome community surrounding it. Congrats again.
seems like their selling point is data binding + client syncing. Considering I can do that with Ractive/React + Firebase, what's the advantage of using Meteor?
seems like their selling point is data binding + client syncing. Considering I can do that with Meteor, what's the advantage of using Ractive/React + Firebase?
The reasons I prefer Meteor (in no particular order):
* Fully automated build chain. No matter what kind of preprocessors I use, all my code is compiled, bundled, and hot reloaded into the application. CSS updates are automatically live injected into running applications without a browser refresh. I don't have to write any build chain code, just application code.
* Isomorphic client/server APIs, with code sharing built into the build chain. I'm using the same language with the same APIs in both environments, drastically decreasing redundant code. Clients can simulate server RPCs using the same function as the server while it waits for the server's response. If I want, I can easily make the client's simulation code different from the server's such as when I want to obfuscate something, or simply disable client simulation for certain RPCs. The package system incorporates both server and client assets, allowing drop-in full-stack components, such as...
* The Accounts UI component. A drop-in, automated SRP+OAuth authentication system that's easy to customize and restyle, or build from scratch using the simple JS authentication APIs. It takes minutes to make a web application with a fully-featured and secure authentication system with password-based and 3rd party OAuth login methods. And logging in never requires a refresh.
* Already glued together. Endpoints don't have to be hooked up; they're hooked up from default. Publish data on the server. Subscribe on the client. Add authorization rules, and I have a fully functional web application with realtime data updates, with virtually no glue code.
You still need JavaScript on the client, so you have to switch context between Python and JS if you're a single dev, or have different team members work on the client vs. the server. Meteor is JavaScript everywhere.
The way they handle client syncing is a bit different though. Meteor actually hosts a mini-mongo instance on the client allowing for better offline support.
I imagine it's just using localStorage under the hood, and it's selling point is that it exposes the mongo api you'd use for interacting with the db, or is there something else that I missed?
More that it fully simulates the mongo api. When you perform an insert/update on the client, the following will happen:
1. The command will be sent to the server.
2. The command will be performed on the local database, but backing up the original local DB state so that it can be reverted if needed.
3. Immediately, any helper functions used by templates which rely on data from the DB will react to the change in the local DB and inform their template instances to update just the relevant part of the DOM.
4. The server will eventually get the request, and authorize it based on allow/deny rules.
5. If the command was allowed, the server will update the actual DB, and use MongoDB's oplog to notify all other server instances that the data has changed.
6. Server instances will send the changed data down to all subscribed clients, which update the state of their local DBs, causing the templates to re-render the relevant parts of the DOM.
7. If the request was denied on the server, the server informs the requesting client, and the client patches up its local DB to the actual DB's state, also reverting the DOM state.
So you have built-in latency compensation and full-stack reactivity by default. The client anticipates the server's response, making the application feel extremely responsive. But if something goes wrong, the client patches itself up with the actual result. Of course you can avoid latency compensation altogether where you don't want it - just avoid using the isomorphic API on the client and use RPCs instead. The servers will still inform the other server instances and push the changed data down to all the subscribed clients, but the requesting client has to wait like everyone else before the DOM is updated.
Another point to add is Meteor's EJSON, which is a simple spec for defining how any complex, constructed or factory-made JavaScript objects should be serialized to JSON, and then deserialized back into a full JS object with behavior. Objects inserted/retrieved to/from the MongoDB or Session variables are automatically serialized/deserialized if you have made them EJSON compatible (quite easy to do, and built-in for Date and binary objects). By sharing EJSON definitions on the client and server, you have a flexible basis on which you can build an isomorphic model layer to your liking. The constructed model objects you're working with can easily be made identical (truly or superficially, depending on your needs) on both the client and server code.
It's a bit light on details. I wouldn't say Meteor is 1.0 yet, but preparing for it. Also Worldwide Meteor day is Nov 6th, I anticipate a more formal announcement then.
The importance of JavaScript as a Platform is not abt billions of browsers running JS, but abt how each one of them is also a JS IDE. If we could click the fork button, and start editing, testing and deploying right away, all within the browser, we'd probably get programmers to contribute to open source web apps in a way never seen before.
A sea change in how web software gets built and consumed, in the same way Britannica yielded (had to) to Wikipedia.
Amazing :D Great work, and hats off to the meteor team! I just finished a hackathon this weekend with a meteor app, and absolutely loved the framework.
For an unbiased overview of Meteor, including what it offers and how it differs from typical JavaScript frameworks (like Angular.js and Backbone.js) and ecosystems (like Mean.js and Yeoman), read this article:
http://javascriptissexy.com/learn-meteor-js-properly/
When I saw a link to an "Atmosphere" page I was curious what did meteor had to do with the Atmosphere project [1], a "real Time Client Server Framework for the JVM, supporting WebSockets and Cross-Browser Fallbacks Support". The answer: nothing.
It uses a database, specifically MongoDB. But as I understand it, Meteor manages this for you itself, and abstracts the orchestration of those things into the Meteor platform itself.
It's just a higher level of abstraction, not a new technology. And certainly not flat files.
Meteor uses mongodb. They have plans to support additional types of databases but they wanted to use something that was popular with developers and they wanted to do a good job on it.
Well, as a Meteor developer, I think they could make this clearer, since obviously your data has to go somewhere, and you do need to design the schema and manage the data.
Currently it uses MongoDB, though (last I heard) there are plans for Postgres and possibly more, but it will have to work like MiniMongo on the client (i.e., no ORM, and mostly the same on server and client).
It's pretty much hassle-free though, especially with some of the community packages, such as collection2 and simple-schema.
By default, Meteor spawns a Mongo instance, with its own DB stored in the app directory, and your data is stored there. No database configuration necessary. Of course, if you have an existing Mongo DB, you can point your Meteor app to it.
Hi meteor.com team. I've scanned the home page and even looked at some other links on the site. I still don't know what this does. Is it a javascript library? Or template maker? A project packager? I have a lot to do and very little time. Can you make a quick video that describes why I should use Meteor and what it does for me? Thanks!
It is a full stack web framework, where you write in 100% JavaScript on the client and server, sharing much of the code with isomorphic APIs. It is not meant to be used on top of Rails, but rather as a full replacement for the combination of, say, Rails+Ember.
I used my meteor developer account to get the free discover meteor book (via the limited time 1.0 promotion I guess), but I thought I did something wrong, tried again and ended up with two copies/purchases. It was free, but seems like a bug. Maybe detect if someone already got a book?
At this point, what percentage of web development can't/shouldn't be done with Meteor? It seems like everything else is obsolete in comparison. The only non-Meteor cases I can think of involve especially large scale.
Because Meteor hides much of what's really going on, it's sometimes hard to understand just how the app is working. At least that was my impression of it when I tried it about 9 months ago.
Choosing a stack on your own means more time is spent making things work, but then you know how it works. That's why I went for a MEAN stack instead of Meteor. But I'm going to try Meteor again soon!
While Meteor does do a lot for you out of the box, it doesn't really prevent you from seeing what's going on. There are some good resources for seeing what Meteor is doing behind the scenes (meteorhacks.com and eventedmind.com) if one does want to dig in.
Even at "especially large scale" there are things that can be done to support unique scale cases, including swapping out database drivers and other components that don't work as well as you might need.
Although this may be corrected in 1.0, single page applications in Javascript like this (whether in Angular or other tools) tend to underperform in SEO (Or not perform at all). Meteor has a sort of hack that handles SEO at the moment, but it's not particularly terrific.
Meteor's database support is presently focused on MongoDB exclusively. Expect relational and other data stores to have improved support in the near future. If you were starting a project that depended on a relational database (Postgres, MySQL, MS SQL, Oracle, etc.), Meteor would probably be a poor choice today. For many use cases, however, Meteor is terrific in my experience.
Basically, if you need native MySQL support (some support already exists, but it's not in core), or if you need a web-site (SEO), not web-app.
Regarding scalability, by the time your app becomes so popular to exceed thousands of concurrent users, Meteor will have improved scalability again. They've done it a few times already with Mongo oplog tailing support and whatnot. If you already have a highly popular app, it will take you time to port it to Meteor too. So scalability may seem like a problem right now, but likely won't be one in, say, half a year.
This site takes about 15 seconds to load on my iPad in Europe, which is so slow someone is likely to tab away.
I haven't looked into fast-render mentioned elsewhere, but initial load time has always been a issue, and it seemingly gets worse as you add more functionality to your 'app'.
Personally, I'd only consider betting on Meteor for anything non-trivial once some form of incremental/optional loading of functionality was included.
On the contrary, I think that is a good sign. It means there is an active community that is opening and contributing to issues. If you check out Rails' repo (https://github.com/rails/rails) you'll see the same thing. If you've ever been an open source maintainer, you'll know that you'll inevitably write bugs and so you'll always have open issues. The scary thing would be if no one filed any issues or had any pull requests.
This is pretty normal. The community is creating enough issues/questions/possible improvements but the project can't possibly fix or incorporate all of them right away. Many of them are probably even bad, or just not the right approach. This stuff is hard and is something we've been dealing with at Ionic. No great solution yet, and I'm coming to terms with the fact that successful OSS projects have a high volume of issue and pr traffic.
We've built an enterprise/b2b app on meteor, and even through all of the hard yards, it's been a success & the right choice for us.
When I first heard about meteor, back at v0.5 or v0.6 - I watched the video from their home page, and thought it was full of buzzword bullshit. I didn't have a clue what it did.
I then ended up reading about how their latency-compensation API system worked [Meteor Methods]; And instantly knew that it was for me.
Having an API that simulates itself on the client, while simultaneously performing the same work on the server, is freaking awesome. (And then rolls back automatically if they don't agree).
If you are building a real-time, collaborative tool. Meteor is the framework.
That being said, there are a few questions about integration & scalability.
Opportunities to use Meteor:
* If you can make something small, eg. an internal tool [Free mobile app with cordova!]
* If it matches a certain feature of your app - and you can segment it based on URL (eg, it's a separate app)
* You're a sadist, and you're going to port your whole app to meteor...
* You're writing an MVP and you're going to scrap it later
* You're product has realtime/ collaborative elements that are a SELLING feature [not just for your personal enjoyment].
Scalability:
* Client are always connected via websocket. Great for realtime data (no polling), crap for a website.
* As meteor instances are single threads, you can run multiple instances on the one server. Design you code for this (eg, don't store state in regular JS variables on the server - all has to be in the database). Load balance between them.
* Once the "client" has booted up. You can then connect to as many other DDP servers [backed by their own mongo instance, or the same mongo instance] as you like. This gives you the ability to segment your application based on your core feature. EG; if you're a monitoring app, shard your data by client, if you're a document app, shard by project. Have a central listing which tells them which server to connect to.
* Perform heavy lifting somewhere else. Plenty of "web workers" out there, or roll your own using Celery & Meteor-Celery package [shameless plug].
All in all. Meteor is great at what it does; and what it does, is going to be the next generation of web apps.
I'm working on Google's Governance, Risk and Compliance management system.[1] Porting it to Meteor would accomplish several goals:
* clean and much simpler code base
* automatically (reactively) updated status reports on compliance across various systems depending on numerous components throughout Google in continuous flux
* ease of onboarding new developers in the team given the simplicity and ease of learning of Meteor
Low latency (real-time) can be an important part of effective and engaging communication.
Sure, it's not for everything; I wouldn't want my email communicating word by word to my recipients as I typed.
However, enterprises usually involve a lot of communication - with team members, stakeholders, and clients. - there are many opportunities to spice things up and make them more engaging & effective.
There's also the opportunity to instantly communicate non-prose - manipulating datasets, images, graphs and charts in real time.
Could you elaborate on why it is a pain to deploy? I've never used Meteor but I thought one of the selling points is ease of deploy, hot code pushes, stuff like that.
Never really had an issue - I can't say the same about rails! Obviously Meteor has the advantage of being younger and so less cruft has built up, but I'd bet on it still being insanely easy to deploy 4 years from now.
The Meteor team is doing an awesome job spending the VC money on making an experience that is fantastic for devs. Major props to Geoff et al.
Deployment depends on where you want to run it. Builds into tarballs that can be deployed pretty directly onto EC2 or other hosting services. It does require a VPS or equivalent system (LAMP hosts won't run Meteor). I understand Heroku can be a little more complicated as well. That said, Meteor's self-hosting option is pretty good for getting started, and Amazon instances run it very well.
Also +1 on the Major Props to the Meteor team. They are a model team.
In production in bundles and minifies all JS and HTML into one file that is sent to the client. Then all further communication happens with JSON over WebSockets/SockJS. If changes are made to the JS/HTML, the server will send down a new application bundle and hot-reload the app without interrupting the user if you are storing the user's app state in the Session.
The CSS is also bundled in production. When further changes are made to the CSS, the new stylesheet is live-injected into the running apps without reloading the browser.
Client-side, you have Chrome DevTools, the best JS debugger there is. Meteor has extensive debugging support. See https://github.com/meteor/meteor/blob/devel/History.md#v094. Also, the popular IDE WebStorm has just released full support for Meteor, including debugging.
Not unless you want to. Anything in a `server/` or `private/` directory is not sent to the client. This pattern is sometimes used to group similar functions in a single file.
If you use browserify for your "isomorphic" code (i.e. JS that runs on client and server), you may have situations in which you need to run different code depending on whether the code executes on the client and server (think XMLHttpRequest vs `require('http')`).
In node you do that by extracting the code in a separate module and telling browserify to use the browser-specific module via your package.json.
In Meteor you can just check whether you're running in the client or server at runtime and execute different code accordingly. That's what `Meteor.isClient` is for.
It has seamless support for hashes and strings, miniredis, latency compensation, user input validations - similar features to MongoDB integration.
Right now you need to start the Redis server and set up the KV observations manually once for every Redis server you intend to use.
This support was experimental and we didn't develop it further from there. We told our community about it on a Meteor Devshop but there wasn't much interest. If there will be more interest, we will continue developing it.
Since it seems like everyone wants to think of themselves as doing something huge, I'm sure the answer can't be 'no' to the second question — but I don't see any examples of significant projects being built on the platform. Actually, with that in mind, what happened to the gallery of projects built on top of Meteor? Perhaps I'm missing it.
All that being said, congratulations on reaching 1.0. There's clearly a lot of great energy and thought that went in to the project.
edit: The videos on the site weren't obvious to me at first, but after finding them I think this one is a good counterpoint: https://www.youtube.com/watch?v=QzhtQzAX_6k