<i>No matter what else happens in the world, the core team will be able to focus entirely on Meteor for several years, without taking on consulting work or trying to create some other application on top of Meteor to sell</i><p>Does that raise any red flags for anybody?<p>Do development frameworks built for their own sake ever really work in the wild?<p>I think of successful ways to build web apps, and the names that spring to mind are rails, django, php, etc. that evolved by developers who were using them to build stuff. In some cases (rails, django especially), they were the side product of a single application.<p>I think of overarchitected nightmares such as Fusebox and some of the magic frameworks that would be Meteor's competition, and they tend to share the quality of having been built as the Ultimate Solution to Everybody's problem (with the conspicuous exception of the developers themselves, who aren't actually dogfooding it for anything).<p>To be clear, I'm impressed by Meteor and I'm looking forward to seeing where it goes. But it makes me a bit uncomfortable to see a declaration like "we're <i>definitely</i> not going to try building anything with it!" tacked onto their funding announcement.
I will take Meteor seriously when it is acknowledged and supported by the existing node.js community and the leadership. There is a large group of module authors who are cranking out beautiful, useful modules for both the browser and server at 1000x the rate of a normal human being. I am not going to list names here but check github or npm repository, etc. It is this team that makes node.js special, not simply 'javascript on the server'. If Meteor can gain support from this _established_ community I will start taking it more seriously.<p>Why not use the 11M in funding to hire one of these node.js leaders full-time? Outside of Meteor, what contributions has the Meteor team made to node.js and the ecosystem of modules? The founding team has no presence in the development community and yet their technology stack is built on top of it. I need to see that people I trust in the node.js community are driving and influencing the direction Meteor is headed. In fact, its almost a warning sign if Meteor can't staff any of the node.js leadership full-time as they certainly have the cash to do so. I will be watching who they are hire next very closely.<p>The lack of node.js leadership in their organization is already evident in the product decisions they are making which wouldn't stand a chance if they had a true representative of the node.js community on their team. A glaring example is the decision to build their own package management solution instead of adopting npm or working with npm to drive it forward if its missing useful features. Meteor is leveraging the output of the node.js ecosystem yet not recognizing its existence in their own product. They seem to be segregating themselves.
At Throne of JS last weekend, Meteor stole the show in my opinion. The other frameworks (Backbone, Ember, Angular, etc) were about how to build rich JavaScript web apps on top of current backend technology, whereas Meteor is envisioning something new.<p>I'm not sure I want to write JavaScript everywhere but what they are able to demonstrate was super cool.
First Github, then Meteor. As Peter Levine pointed out in his blog (<a href="http://peter.a16z.com/2012/07/25/meteor-magic/" rel="nofollow">http://peter.a16z.com/2012/07/25/meteor-magic/</a>) Andreessen Horowitz is making strides towards "help[ing] developers build the next generation of applications."<p>Are there any other VC firms that have had such a stong foothold on the foundation of application development?
$11m (implying a valuation of of over $20mm) is a lot of money. (Although in a world of $7 rent, $150k developers, etc, it isn't as much as you'd think).<p>However, Meteor looks like it has some chance of being a huge platform, maybe the next big one. Even if it just dominates a niche, that is more than enough to justify the investment. A bigger series a reduces risk for the company, and a lot of the other interesting hard tech companies out there raise that amount of funding early (eg Bromium).<p>Red Hat does a pretty good job of demonstrating how open source companies can make a lot of money.
Some naivety being thrown around in this thread:<p>Andressen Horowitz doesn't need to see a direct return from meteor. If they think that the <i>existence</i> of meteor is a good thing for their other investments, then the indirect return they see from those projects is a good thing.
I've been leaning towards DerbyJS because pages are also rendered in html (SEO, no-js)and it uses npm instead of making it's own repository... <a href="http://blog.derbyjs.com/2012/04/14/our-take-on-derby-vs-meteor/" rel="nofollow">http://blog.derbyjs.com/2012/04/14/our-take-on-derby-vs-mete...</a><p>But Meteor has the advantage now, looking forward to what they do with it. Congrats to them!
I love the idea of Meteor and want to use it on some projects, the only thing I don't like is how language-centric it is on the back-end. node.js is okay, I'm not <i>completely</i> adverse to coding server stuff in JavaScript, but I'd prefer having a choice of languages, for instance most of my server-side code is in Python. I wonder how friendly its architecture would be to supporting multiple language back-ends eventually.
So far it seems like Meteor is focused on data syncing and live UI elements. That's neat when done well, but the main pain points for client-side heavy apps is the mismatch between the server and client and between the traditional URLs structure of web pages and the MVC structure of apps.<p>I'm looking for:<p>* Complete parity between server and client-side rendering for content. This is required both for first-page performance, caching, and SEO.<p>* URLs as the foundational organizing principle of the app. The mismatch between clicks, back buttons and external links makes code hard to organize and apps behave strangely without serious work.<p>* Database agnostic. Relational datastores remain incredibly productive and proven for the vast majority of apps.
From my cursory review Meteor a few months ago, I got the sense that it could be a game-changer like Rails. However, by raising this money they're going a very different route than DHH and company.<p>It will be interesting to see how this plays out over the next few years.
So, as I write Node.js and Socket.io based applications, lots of my code(on the server at least) focuses almost completely on protecting myself from bad data/malicious users. I know it works this way for almost any application, but how does Meteor handle this? I saw in the screencast someone opening their chrome console and touching the database directly. This seems like an absolute nightmare to protect! Currently, I only need to protect the individual web address that gets, puts, posts, etc. It's a single query with clear attack vectors that can be guarded against. How in the world do you protect a server and data using this framework?
Interesting idea.<p>I have questions about the following:<p><pre><code> > Database Everywhere. Use the same transparent API to
> access your database from the client or the server.
</code></pre>
Is this a good thing? I have been always under impression that separating data management and application logic is a good idea - basically a must.
Meaning lets think about more complex way to look at the database (temporal, stream, event processing, etc.). How this can be then possible?
Congratulations! Talk at Throneofjs for Meteor was excellent, especially liked the<p><pre><code> meteor remove insecure
</code></pre>
that was a great touch
After their recent shocking Github investment and now Meteor, a16z are, IMHO, the most impressive VC firm in the US.<p>They have a very long-term vision, they put their money where their vision is, and that's the best thing founders can wish themselves when raising funds, may my investor will look as far as I and ever further.<p>Congrats!
What is their mobile native app story (if one has been announced)? -- I'm not sure how I'd integrate the meteor backend with a native client (can't use a phonegap-like sdk in my case).
"we've arranged $11.2 million in funding for Meteor's continued development."<p>That's a nice arrangement. Do anyone know about other open-source web frameworks that have managed to get so much funding?
I expect to see some of this money used to purchase actual meteors: <a href="http://www.ebay.com/itm/CANYON-DIABLO-IRON-METEORITE-140-gr-METEOR-CRATER-AZ-FORMER-UNM-MUSEUM-PIECE-/221080520933" rel="nofollow">http://www.ebay.com/itm/CANYON-DIABLO-IRON-METEORITE-140-gr-...</a>
Let's come back to this when Meteor is actually deployed in a real production environment handling 200 requests a second. Until then it seems like a lot of hot air.
"$11.2 million is a lot of money. What it gives us is certainty. No matter what else happens in the world, the core team will be able to focus entirely on Meteor for several years"<p>Assuming you're not targeted with any software patent suits.