This is good to hear 
I think it might be similar to the case of a freelance developer working heads down for weeks thinking all is well and the client is freaking out because they haven’t heard any news and assume they’re being billed for little/no work… when in fact a few check in emails solves the issue.
Yeah. I think there are tradeoffs though. For example, it could cause more harm than good if we post all of our new ideas as soon as they come to mind because it would end up with a very fragmented and unstable outlook. It’s definitely about striking a balance, and I completely agree that we should be communicating more than we are.
As soon as we have something concrete to share and discuss, we’ll make sure to make it as public as possible. We’ve been experimenting with stuff like that, but we need to do more of it, and I’m personally disappointed that we haven’t done a better job but very optimistic for the future.
One aspect of things is that we have been working very hard on Galaxy which has taken a little focus off of the framework in the last couple of months, but will be very important to make the whole ecosystem more complete and legitimate. The best thing that can happen to Meteor is to have a strong base of successful businesses built on top of that, and Galaxy is the last significant missing piece of that puzzle.
My goal is that the next few things we announce on the framework side can all be squarely in the realm of “yes! that’s exactly what I needed!” and not something that’s like “wait why are they doing this”.
Why don’t you think of NPM as a great idea? Meteor in JavaScript world is like Ruby on Rails in Ruby world. Ruby has Gems. JavaScript has NPM.
Rails, my friend… has gems that are well - for Rails. And Node.js has NPM (not the entire JS world evolves around Node…). I like packages that will work with Meteor anywhere. And if I need a NPM, there is https://github.com/meteorhacks/npm
You can write NPM package which will work only for Meteor and only Meteor developers will use it.
Yep. It’s a religion. All your base are belong to us. Don’t worry. We won’t ask tithes or offerings every week. We do regular exorcisms.
Meteor is very great for quick start and newbies, but it becomes hard when you write big applications…
Big applications always become hard. Migrations, backward compatibility, deprecated API, naming things, changing things that break things, build tools. Maybe it is not Meteor, but the methodology you are accustomed to. Empty the cup, empty the cup.
I just want meteor to be the part of that all-rest-javascript-world.
I just want a drone that fetches my coffee and plays the StarGate theme when flying.
I think Meteor has a very good package Manager. I know MDG has invested a lot to make a such a good package manager. It’s far more effective than NPM is few ways.
Master Jedi speaks.
I don’t really understand all this hype on React. ERb in the Rails world is not that different from Blaze…
Blasphemy. Erb is dynamic templating. Blaze is reactive dynamic templating. Biggie.
But on its side Rails had applications like Twitter and Github since the beginning. That’s the point.
I still believe that Git had the most major influence for GitHub success. And Twitter because three billion people felt the need to announce their bowel movements from the beginning. Meteor is the cool party at hackathons and in secret batcaves.
Yeah. I think there are tradeoffs though. For example, it could cause more harm than good if we post all of our new ideas as soon as they come to mind because it would end up with a very fragmented and unstable outlook. It’s definitely about striking a balance, and I completely agree that we should be communicating more than we are.
Love.
One aspect of things is that we have been working very hard on Galaxy which has taken a little focus off of the framework in the last couple of months, but will be very important to make the whole ecosystem more complete and legitimate. The best thing that can happen to Meteor is to have a strong base of successful businesses built on top of that, and Galaxy is the last significant missing piece of that puzzle.
Love.
Lots of really great discussion happening on this thread!
I just want to chime in with my two cents, as the person who designed and implemented most of the new compiler API.
For what it’s worth: I mostly agree with you! I’d love to get the Meteor platform to a place where we don’t need our own custom build and packaging system.
The goal of the 1.2 batch build plugin API is to make an incremental and mostly backwards-compatible improvement to the Meteor build system. A large number of bug reports and feature requests over the years for things relating to CSS preprocessing and other build-time operations were not fixable because the design of the pre-1.2 build system did way too much before you ran meteor publish and not nearly enough in the context of an individual app.
The goal of the 1.2 build APIs is to simplify the package and build system by making “publish this package” a lot closer to “put the source files in a tarball”, and “build this app” be where the real processing happens. While it may seem like the point of the change is “look, here are new APIs you can use”… the real important part is that published packages contain source files instead of overly processed files.
But just because this is the incremental improvement we’re making now doesn’t mean we’re not considering more overarching changes later 
We’re using React and need a clear answer to the question: Why use Meteor/Galaxy rather than Firebase? I understand that they are not the same, but my point is that Firebase offers a commercial, scalable and simple solution to our problems.
I’m not sure if you have experience with Firebase but there are two very big problems with building any application to scale in firebase IMO.
Having done a simple proof of concept project with angular+firebase, I would NOT recommend even building out a MVP with it.
I absolutely love Firebase - but you have to know about it’s expected use-cases. Building a real-time fitness tracking service – great. Building a secure, PCI-compliant easy-to-query solution – yea, not so much. I was trying to build a big app on it in the past, and the security rules are very hard to write as mentioned above, I needed advanced querying which was/is unavailable, and adding multitenancy is a p.i.t.a. because of the dbms constraints.
This thread got me thinking about opinionated frameworks vs open ones, especially with respect to how it affects package authors and users.
We have more choice than ever at each layer of the stack now. Iron Router vs FlowRouter. Blaze vs React or Angular.
An open philosophy means ever increasing choice, and we like freedom of choice.
But Atmosphere packages will need to limit what they support, making it harder to find one that fits your customized stack and harder to publish ones that work for most people.
Which do you prefer? Just for fun, here’s a poll:
@pauldowman how do you expect us to participate in a survey that requires
I know, Facebook doesn’t make it easy, but it’s as open as a Facebook group can be, anyone can approve you and it doesn’t usually take long. I know many people won’t bother. But it’s the easiest place for me to post a quick unscientific poll and have a conversation around it.
I think this is a great point. It’s more important now to make packages de-coupled and view independent (and DB independent when SQL comes).
Take FlowRouter for example. It’s very decoupled and doesn’t concern itself with the view. However the author provides blaze layout and react layout to use with it.
Reaktor takes these two packages and makes a react specific implementation with very little code. Think about how much work would be saved if Iron Router packages would have abstracted away the iron router part. They could have updated for FlowRouter in one line. This could be used with autoform and react/blaze/angular/etc…
Haha, that’s hilarious.
Theoretically your idea is good. Practically BIG NO.
You just waste your time. And after you waste much time, most of them aren’t work, especially for newbie.
Then you visit atmospherejs.com, searching packages. Install it. Following instructions and it’s work a minute. And you yell “damn it, why don’t I use meteor packages sooner”
I love meteor, MDG, and community
I’m releasing a new version of AnyDb soon. Using it in production 
Any work with RethinkDB yet? I think that’s what I’m looking forward to most.
you can use it with any… db! and I have a simple rethinkdb driver set up already: ccorcos:rethink. It doesnt use rethink’s changefeeds though because its not powerful enough yet. Its doesnt notify you when the queries change order and doesnt support joins. So you’ll just want to use it as any other non-reactive database with ccorcos:any-db.
You should check out Neo4j though. Its ridiculously awesome
I believe you. I’ve been wishing for Neo4j + Meteor for a long time now. Is there something simple like a todos app, using Neo4j, that we can tinker with to see how they work together? (e.g. Is the source of this chatroom demo available?)
My 2 cents, this is my worry too. I not fond of React. I wish MDG would focus on improving Blaze instead of integrating React/Angular. But facebook has the muscle and mindshare, that’s what’s driving MDG’s reaction to React, not any any real innovations it brings brings to the table from what I’ve seen.
Still, from the tutorials I’ve read React is considerably more preferable then angular since it keeps it’s paws of everything else
But seriously, Blaze is pretty epic in itself and just the fact it plays nice with the rest of the toolbox gives it a leg up as far as i’m concerned. Let’s see where this all ends up.