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.
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.
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!
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.
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.
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.
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.
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.
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.
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
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?
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.
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.
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.
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.
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.
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
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.
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."
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.
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.
249 comments
[ 3.1 ms ] story [ 248 ms ] threadquick feedback: this scares me off a bit:
200 open issues / 150 stale branches / 42 open pull requests
might be normal for open source projects of that size though
cycle times might be better indications
It is not done yet :)
But yes, I agree, it's not ideal until a SQL adapter is available.
[1] http://quantpapers.com
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!
Sure the git commit is a landmark, but there's nothing to offer other than 'kudos' with this link as the discussion point.
We merged the stories (in our ghetto way) and moved the comments over here.
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.
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.
[1] - http://techcrunch.com/2012/07/25/andreessen-horowitz-keeps-e...
https://news.ycombinator.com/item?id=8522381
is interesting with regards to your questions.
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
http://i.imgur.com/uvulagb.jpg
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
https://www.youtube.com/watch?v=cJbGNpmE7f0&t=8m30s
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.
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.
edit: posted too soon they talk about it here https://meteorhacks.com/does-meteor-scale.html
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.
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'.
http://www.infoq.com/presentations/Simple-Made-Easy
Anyways, that's just one developers experience and opinion, take if for whatever you feel it's worth.
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.
Because if you started a small project in something else, it is not easy to change it to Metero later.
What he said was quite clear.
Meteor spans both the front-end and back-end to offer a seamless API experience when building your application.
Does it have to use Node.js on the server can the client side framework work with any server side JSON service?
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/
Src: http://www.jesus.org/early-church-history/the-apostle-paul/h...
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.
> No longer do you need to provision server resources, or deploy API endpoints in the cloud, or manage a database
So you don't manage a database, but what happens to the data.
Can anyone trace an example, I don't, order or cart update from client code to persisting it on the back-end somehow? Does it use flat files...?
It's just a higher level of abstraction, not a new technology. And certainly not flat files.
* http://blogs.enterprisedb.com/2014/09/24/postgres-outperform...
That said: There's nothing intrinsic in meteor that ties it to Mongo. No reason why, say, a Postgres or Memcache or whatever backend couldn't exist.
B: It is possible, perhaps even common, to write apps without server side storage at all - imagine API frontends or data aggregators.
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.