I'm scared of meteor, no offense, partly because of its funding structure. It's a startup, but I think one thing I haven't been clear on is their licensing scheme, and how to deal with them if they die, etc.
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.
I fully agree with your mentality. When dealing with any technology for a business venture, you have to worry about the landscape a few years out. This happens to large companies too: for example, Microsoft axing Silverlight or Apple axing Xserve. All of these thoughts are compounded by the fact that they haven't reached critical mass (lower resistance).
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
Maybe, but they probably have 5 years of cash, so I personally wouldn't worry about it. There can be a new BFDL should the unthinkable happen, so long as the code is open source.
I played with Meteor and with Derby (http://derbyjs.com/) six months ago and found the latter to be lighter and more interoperable with the node ecosystem.
Is there anyone who has played with both more recently that could give their opinions on the matter?
I just started toying around with them recently, and I have the same feelings as you. In general, it seems like Derby's choice of using straight up npm makes it a bit more inter-orperable. Other than that I haven't dived in far enough.
My biggest hurdle with Meteor so far has been how hard it makes testing and test-driven development. Built-in testing support is pretty much absent from the core framework and has been marked a "post 1.0" feature on the roadmap. If you know your way around Node, you can kind of isolate out most of the global state that the framework uses and write unit tests, but it's pretty ugly (you can refer to my stack overflow question for a sample of the difficulties I've had: http://stackoverflow.com/questions/15191257#15314384)
You hit my opinion exactly. I love to hate/hate to love meteor because of how easy it is, but I just can't come up with an easy testing scheme outside of full out integration test, or making some separate modules that are injected. Thanks for the link.
I really like the way you can just push your test app on the meteor servers and share it with a few friends, it is just so easy to build and deploy in it.
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/
Agreed, Meteor is now my go-to language for one-off projects and hack-days at work. My most recent one with PagerDuty integration [1] took half as long as I was expecting. I can't remember the last project I did that too less time than I expected.
I've been hacking around with node for years, and I still haven't touched meteor. So that's my disclaimer.
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.
I tried Django for one app (and never for a second one). There are so many assumptions built-in that if you build a real app and find out you need to handle a case that isn't well-supported by those assumptions, it's a painfully uphill battle. (In my experience, Django is also slow/heavy.) I know there are a lot of real apps built on Django, so maybe it's matured in the past few years, but I'd much rather use something like CherryPy or Flask that handles the common cases for me, but doesn't limit the directions my app can grow in.
I really enjoyed using Meteor. I'm looking forward to the author's book, and would recommend to anyone who wants to very quickly jump in and start playing around to check out this book:
Getting Started with Meteor.js JavaScript Framework by Isaac Strack
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.
Eh, it's pretty easy to host it on your own server. Just run "meteor bundle myapp.tar.gz", extract the .tar.gz on your server, run "node main.js". It's documented on "meteor help".
It's a full stack framework. Node js backend, choice of db extensions (starts with redis I believe), and js front end.
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.
I wouldn't really put it like that, but sure. You really aren't exposed to node.js at all except for when you bundle up the app to run it on your server. It's a framework that happens to use node.js, a particular mongo library, a particular templating library, a particular library for http requests, etc. (Of course, a lot of those libraries can be disabled, swapped out, etc.)
What I've come to understand is it's a stack (it uses mongoDB and something called "mini Mongo" and the front end uses a templating system called handlebars) that takes advantage of Javascript async nature allowing for the creation of applications that otherwise would be considered "AJAX"ish but within meteor these are just "normal" and don't require AJAX code, hence why it's unique. It isn't MVC it's "MVVM" as JPKab mentioned
Slowly the "web" seems to be rediscovering desktop UI development techniques from 15 years ago or re-implenting things Adobe had elegantly working in Flex 5-10 years ago.
Binding UI to the state of a data structure seems like magic in Javascript land until you realize Flex had it and Java had it and a bunch of native platforms had it... probably even GEOS had it in 1986. Javascript still has to bend over backwards to make this work it seems.
Author here. What I meant is that as of now, all Meteor sites have a fairly substantial loading delay (generally a couple seconds) due to the way Meteor works.
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).
When a template subscribes to data in a server collection, there is a delay between the moment the subscription begins and the moment the client displays the data it receives from the server. On page load you really notice the delay because there is nothing else for the user to see while the client waits to receive the data from the publish action. The way around this is to show something else on the page so that the user doesn't notice the delay. One way to do that is to show only static assets during that time, another way is to use local (client-only) collections.
Presumably he doesn't specifically mean e-commerce sites, just sites that are required to be highly responsive - where you don't want to send the JavaScript, then the JSON, then do the rendering. You want to start with the static, rendered HTML then decorate that with JavaScript for subsequent interactions.
I'd like to see how more traditional websites (i.e., not web apps but more like company web sites) are being/could be transformed by meteor. I'd like an excuse to work with it at my company (a creative agency) but we don't build web apps and it seems like meteor.js would be overkill for such a thing (also, what is the state of CMS' built with meteor?)
The ability to provide a better, more 'slick' user experience, even if it's not an 'app' using fewer developer hours could be a pretty good excuse for a creative agency, especially as the average Internet user is growing more accustomed to the reactive elements in fb and twitter.
Afaik, some examples of creative agencies who have used Meteor to build sites for their clients:
Not sure how real-time web applies when your content (company websites) does not require it.
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.
Meteor is just another framework for delivering thick client apps in js which cannot be part of the World-Wide Web, because it doesn't ship semantically described data at a stable URL which can be rendered and repurposed in unanticipated ways. Try
curl http://demo.telesc.pe/
and you'll see a DOM with literally no content beyond "Loading...", completely broken unless you trust their code and want the only rendering it supports.
Note that you could make curl http://demo.telesc.pe/ work just fine with Meteor's Spiderable package, which is simply not installed for the Telescope demo.
Also, obviously the goal is that it should work properly without any package. Meteor is still young, give it time.
A quick search turned up http://spiderable.meteor.com/ and a couple of blog links, and none of those have any content either. This seems like an afterthought to the people behind Meteor, and I wouldn't describe them as having an obvious goal of avoiding damage to the Web.
Man, the earth would suck with 300 million people. We'd lose 80% of our culture and technology. Imagine a world where the only settled country was the USA.
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.