While I'd actually love to use meteor as the foundation of our company, I feel like the risk of being burned by acqu-hire'd / the team burning out is really great. Raising $11.2mm means you basically have to win, and I'm not familiar with other companies who, as a startup, raised $10mm+ on the potential of their framework. I mean they have to be valued at $100mm already, right? So basically this is a billion or bust kind of company.
And yes, the founders are super talented, and helped build Facebook and Asana's realtime infrastructure, so they know what they're doing... i guess I'm just expressing my overall fear of using a framework with such a funding structure / worried about them getting evil down the line. I understand it's MIT so folks could fork and continue, but something just feels weird.
I'd love others to please come set me straight / offer alternative views of the world.
One of the reasons we raised a large series A (and from Andreessen in particular, who are incredibly skilled and patient) was to create certainty and confidence in the platform.
The round ensures that we can work on Meteor for several years without having worry about building a product or finding another line of revenue to stay alive. It lets us build a core engineering focused on the platform, so we can get to 1.0 as fast as possible. And it takes the risk of an acquihire right off the table -- the round was too big for that to make sense anymore.
We talk about some of this on our blog: http://meteor.com/blog/2012/07/25/meteors-new-112-million-de...
As for the acqu-hire concern, I'd hope that by that point the community would be strong enough to sustain open-source development. I don't have a good sense for the community, and I suspect that the funding affects the culture. But like you said, I definitely wouldn't bet on the project moving past an acqu-hire
I worry about this with Angular too, but given that Google has obvious areas of synergy, I'm way less concerned about its doom.
Is there anyone who has played with both more recently that could give their opinions on the matter?
Here are some cool apps people have built with Meteor so far, there seem to be a lot of collaborative apps. Feel free to add your own: http://madewith.meteor.com/
But I've read through the docs a few times, and the impression I always get at the end is that Meteor isn't embracing the same open DIY culture that made node spread like wildfire. There's a lot of magic in the platform, and while that has its strengths (Rails falls into this camp), it makes me feel like if I actually want to tread off the beaten path, I'm totally at the mercy of the Meteor devs. Yes, it's open source, but it doesn't feel very open. Last I checked, the module system was not only a learning curve (if you're used to node), but third-party modules felt like walking through the Vatican. Look, but don't touch.
Contrast with the node community, where although half of the things you'll find are broken, you probably have 5 choices for anything you might want to do. And all of them are at your fingertips; it's all just HTTP, TCP, and the same protocols everything already works with. Bring your own tools, or mix and match to make interesting new things. With meteor it feels like a lot of keep your hands off my voodoo, or else.
I actually think Meteor is really cool. It looks like they're doing a great job with what they set out to do. But when you get down and dirty like I like to do, it just doesn't feel hackable. And that's why I'm sticking to node.
Strack's book doesn't get deep at all, but it certainly gets you pretty familiar with what Meteor does on the surface as you build apps with it.
Derby is certainly much friendlier to the Node ecosystem, but I don't see a problem with Meteor's approach. If the goal is to make an app as customizable and modular as possible, then Meteor isn't the tool for the job. If the goal is to get an app with reactive data capability, user registration/login functionality up and running as fast as possible, then Meteor is certainly a great option.
Is it something I can host anywhere or only on Meteor servers?
The demo is neat, I get that - but what is it?
Doesn't quite follow the MVC pattern but I would put meteor on par with Ruby On Rails.
Yes. You can host it on your server. It isn't well documented or supported(to me), however.
The demo is neat, I get that - but what is it?
I am not sure what you're trying to ask here.
Runs on handlebars.
For someone like me, who's used to the standard LAMP stack and hasn't played with Node, any of the js frameworks, redis, or handlebars, it took a few days to get acquainted, but once I did I really enjoyed using it.
Again, a little too much magic, which makes me feel like my code is weak.
My only real beef so far has been dealing with errors, many of which offer very general explanations and make it difficult to troubleshoot.
That said, it works so well that I'm almost nervous to use it. Too much magic perhaps?
Sasha, could you elaborate on the quote above a bit more so that we can better understand which use cases are not ideal for Meteor right now? Thanks.
So for sites or apps where loading speed has a direct impact on your bottom line and that don't really benefit from real-time features (such as an e-commerce site) I don't think Meteor is a good match, at least for now.
I also don't think Meteor is needed for purely static content sites. For example, for our own book site we're using Jekyll.
(And yes, I know speed is important for every type of site. But in most cases, I feel there's enough other benefits to building Meteor apps that you can ignore this downside for now).
Afaik, some examples of creative agencies who have used Meteor to build sites for their clients:
- McMillan http://www.mcmillanagency.com/
- Q42 http://www.q42.nl/
Some production apps include:
The way it would transform it is if you could find a way to make it more like a web-app. A good way to think about pushing your site to keep fresh, but isn't necessarily a needed direction to go in.
Will be interesting to see how much it can be optimized (even with perceptual tricks) vs. becoming inherent to the platform.
>all Meteor sites have a fairly substantial loading delay (generally a couple seconds) due to the way Meteor works
Could someone explain to me what these folks mean when they say "real-time"?
Also, obviously the goal is that it should work properly without any package. Meteor is still young, give it time.
There were many advanced distributed data systems on the Internet in the early 90's, the Web won to a big degree because of it's simplicity.
Your analogy of comparing a different technical solution to world peace seems pretty ridiculous, too.