I think I might give Meteor a shot. For a long time I have been working with AngularJS and Node.js. Recently I have been working exclusively with React.js + Flux and Node.js to build isomorphic web applications. I like the fact Meteor is isomorphic by default and comes with everything you need. I have always somewhat seen it as this outlier, a great looking framework but lacking the same vocality that Facebook and Google can give their respective libraries and frameworks.
Even seeing Meteor from a prototyping perspective it looks like a great tool. The integration with MongoDB (3.0 is fantastic by the way) and ability to quickly create and work with collections from within your Meteor applications without really needing to glue anything together or configure is something that appeals to me (especially as a front-end developer who is asked to prototype things quite a lot). Coupled with the support for authentication, user accounts and easy deployment, these are definitely key features to a modern web application.
Windows support is definitely an added bonus, especially for me who switches between a MacBook Pro and a PC for .NET development.
The tooling is where Meteor really shines. I must admit I found React to be quite cumbersome to get off the ground, in contrast Meteor is pure bliss.
It hasn't all been roses; I've had plenty of obstacles to overcome as I've learnt the framework, its capabilities and its limitations, but the community has been helpful and I can honestly say that working with Meteor is on the whole very slick.
From what I have seen the tooling is definitely great. I am not the worlds biggest fan of Ruby on Rails, but one aspect I have always liked is the scaffolding. Being able to generate the skeleton of an application from the command line without needing to glue anything together or read documentation on multiple plugins.
Don't get me wrong, I love working with React.js, but it isn't a framework and aspects like dealing with data, API's and other more functional aspects can take a lot of time to get working with React's way of thinking. React also requires a certain degree of glue-fu to get it to the same place something like Angular, Ember or Meteor seems to be. I think Meteor could be a nice down-the-line framework. For my next project, I'll give it a shot. I have a friend who has been building something with it and he seems to absolutely love it.
Having said that, if you want to use React and Meteor after reading through the documentation it seems they make it easy to integrate with other libraries and even frameworks. I even saw they mentioned you can use Meteor with AngularJS (which is crazy), but cool nonetheless.
I agree. Scaffolding and generators to glue things together in code are sorely missing in Meteor. Scaffolding is useful to beginners and experts alike.
With everything in a predictable location and following the same patterns, code is more intuitive to reason out.
There are actually a handful of good scaffolding options for Meteor. But once you understand Meteor's special treatment of some folders & files, and the basic CRUD stuff then you will be hooked and scaffolding will not be a big thing :)
I have a hard time understanding how meteor is comparable to angular or ember given that it appears to be full stack in every way, whereas angular or ember I can add to my existing stack.
Meteor has always seemed interesting but the fact that it is hosted makes it a non starter. There's too many scaling questions that a marketing site will never put me at ease, I'll need to see some solid case studies and ideally a company sponsor of some sort dogfooding it.
Maybe for an MVP? And even then, I have a hard time justifying it over mocking my data and using something like angular to speed up front end. Maybe I'd use it in very narrow use cases.
Meteor is exclusively not hosted by Meteor (company), you are wrong. You -can- use their free hosting because it's useful to just get an MVP online as quickly as possible.
You can host a Meteor app wherever you can host NodeJS.
Is it me or are a lot of the objections seem they come from peeps that have not tried it for more than a day? More assumed opinions and quick conclusions rather than educated and informed. I am stunned at the confidence of these opinions too. Puts the posters in a bad light. The major takeaway... it shows Meteor needs to do a better job educating the developer community.... and .... haters gonna hate ;)
I never claimed to be confident about my objections, I simply stated that the public portion of the site doesn't address the questions/concerns I have.
You can choose to use Meteor's hosting or you can do it yourself. There is a great open source Product Hunt/Hacker News clone application built on Meteor called Telescope - http://www.telesc.pe/ - I am self hosting it for a site that I run about Javascript, I haven't needed to do anything except styling tweaks, but it is running on a simple DigitalOcean VPS quite fine.
If you get lost at any point, I highly recommend https://www.discovermeteor.com/. Definitely much useful than the official documentation if you're looking for any sort of tutorial.
For the sake of shameless self-promotion, I'd also like to suggest my book for anyone who feels Discover Meteor moves a bit too fast: http://meteortips.com/book/ (It's free.)
Thanks so much for this. I finished your book over the weekend and loved how clear and concise the writing was. Discover Meteor was difficult to follow as a beginner but am more confident that I can follow along now. Thanks again!
Discover Meteor is great but it left me wanting for some more, in-depth resources. I found the Meteor in Action book to be of great help. They are about to release the complete version but the Early Access version is pretty much done: http://www.manning.com/hochhaus/
It's not really new, except perhaps it being more indie now. In most (but not all) niches over the years, the paid, formal published for-profit books have provided the best documentation, right back to the 70s, through O'Reilly's catalogue (he got rich for a reason), through MSDN, and right up to now. Indeed, it's possibly better now because a single author can do it all on their own.
I haven't used Meteor too much, and I always seem to find myself a bit mystified as to what it really is. Is it the front-end? Seems like no, if you can swap that out with React. Is it the back-end? Can that be swapped? The real-time communication functionality? The tooling? All of the above, with caveats? I'm very curious!
All of the above seems pretty accurate. Meteor aims to provide pretty much 100% of the things you need to build a real-time web app right out of the box (or package manager). Front-end, back-end, middleware, tooling, DB wrapper, etc.
Meteor is modular enough that you can swap out current pieces if you want to, but you're certainly not expected to do that (and if you're just getting started with Meteor, it's almost discouraged). And there are plenty of benefits to just using Meteor for everything -- e.g. Meteor creates a "minimongo" interface on the client that lets you re-use your MongoDB queries on the client.
One way to grok this is to compare Meteor to Django. Just as you can swap out Django's default homegrown templating system with Jinja, you can swap out Meteor's default homegrown reactive frontend with React. But you certainly don't have to and neither Django's or Meteor's devs expect you to.
Meteor is a full-stack platform. It is made up of a bunch of smaller sub projects that come together to make this awesome project. So, if you don't want to use part of it, you don't necessarily have to.
It's a full stack platform (note the distinction between a framework and a platform). I could explain it further, but I think reading through the tutorial [1] will help you more.
> I like the fact Meteor is isomorphic by default and comes with everything you need.
Meteor is kind of isomorphic, but not in a very useful way. It does not do server-side rendering unless you include the hacky phantomjs module, last I checked.
Isomorphic is the word some Airbnb people picked to mean "web app that can render html on the server and the client". Everybody hated the word, but nobody came up with something better so it stuck :)
Meteor is great, I can't create a web app with other stacks faster than with Meteor.
My record was saving the day with a demo in less than 1 hour.
I'm glad is more mature.
The only thing I miss is Postgres as alternative to MongoDB.
Mongo is really comfortable but some projects needs Postgres badassness.
Should be doable for Meteor's team since Postgres is now super friendly to JSON. I guess the main challenge is in the SQL support because is a beast in itself. But starting small with a MiniSQL API at the frontend would be totally fine.
+1 vote for a relational alternative. I am a fan of NoSQL, and I am a fan of Mongo, but I'd love to have the power of Meteor with a relational backend too.
Meteor and bootstrap combined have made it awesome to prototype new ideas. Everything is very smooth and as a beginner web developer I'm not banging my head against the wall writing large amounts of code to link various frameworks together.
A few hours a day for a week have already generated real progress with a startup idea, which would have taken me weeks using angular/express/mongo/node separately. As someone with a full time job who is trying to work on side projects in my free time after work, it's really nice to see progress every night and definitely motivates me to keep going.
Is the real time nature of Meteor important to your product?
I ask because I'm considering trying Meteor to prototype some ideas none of which particularly need real-time data updates in the client.
Would I be better off with some alternative framework or is meteor still super quick to pick up and get stuff done for 'regular' web apps? Being able to knock an idea out quickly vastly outweighs any kind of scalability concerns and most performance concerns.
(Bearing in mind that I am familiar with JS and Android development, free time for noodling on personal projects is in very short supply and not got the time to learn a totally new language)
That's a good question. I've been learning and using Meteor for a few months and my projects do not require reactivity at their core.
Meteor is built around reactivity, and there is some overhead built in to the platform to make it possible, but it's pretty easy to design things so your app isn't overloaded by trying to "real time all the things".
The simplest step is to structure publications so as to deliver the least amount of reactive data needed at each step of the user experience. Another important approach is to understand what forces re-computations and re-renderings and try to minimize them when you can.
It's also possible to serve non-reactive data (meteor-dumb-collections) and obviate many performance concerns related to reactivity.
The speed and relative ease of working with Meteor makes this approach well worth it to me.
Also worth noting is that many of the production apps built with Meteor are not billed as a "real time solution to x". I suspect they have also spent a good amount of time designing around reactivity so they only take advantage of it where it's useful.
Not really, for me it has been kind of a bonus added on top of an already great framework. So far I have really enjoyed it just for the fact that I can load a bunch of test data into Mongo and instantly see it work with my UI. However since I have read many people complain about performance and scalability in meteor I have tried to minimize the mount of database reads and reactive data I am dealing with for any one page.
The lack of free time was a big incentive for me also. I suggest at least taking the hour or so to go through the tutorial. It was very straightforward and I was able to breeze through it with little to no web developer experience, and instantly be able to use the simple concepts I learned to start working on my own project.
I recently started a moderately large project in Meteor and I must say, although I was a little apprehensive at the start, I am truly amazed at how far Meteor has come.
Built-in reactivity, latency-compensation and the lot makes development really fun. It feels like a mature platform, the community is growing and is extremely helpful. I would recommend anyone who is still wondering, to just try to build an app or two with it and you will know what I am talking about.
Rapid prototyping is all fine and dandy...but what happens if my idea actually does gain traction? This is the part that makes me uneasy about Meteor. It sounds like I'm either going to have to rewrite everything completely, or wait until Meteor matures, if I need to scale.
2500 subscriptions per minutes on a shitty $5 digital ocean droplet (in 2013). Don't put the cart before the horse, 99.99% of applications don't reach even 100 concurrent users on a regular basis.
What good is a scalability if you never launch your product?
I used to shun SaaS web apps due to expense - "Layer messaging, $25/month, I'll build my own. When I get thousands of users it'll be too expensive."
Then I thought - it'll take me more than 6 months to build something which doesn't even scratch the feature set they have. Better use the tools and services available to build rapidly now, get to market and swap it out later.
Been working with Meteor for over a year and loved every minute. Meteor solves the biggest problems facing modern app development: one-language/code base/API for web and mobile, syncing data between client and server, free simple hosting. My intro to Meteor slides have links, etc http://fsto.meteor.com/#/4/5 and I fast-forwarded to GIF that perfectly captures how stoked I was after building a few apps.
This boots a CentOS 6 box running Meteor 1.1. It's also running on Terminal so you can snapshot your progress anytime you want (or resize to a bigger machine without rebooting too).
We picked it because it enabled us to move much faster than anything we had used in the past and while it has issues that I foresee being problematic, it seems premature to optimize for them. The Meteor team is doing a great job maintaining compatibility and not forcing us developers on to make any changes to our apps as they're rolling out exciting new stuff. Granted, I did jump on when the platform was (relatively) mature late last year.
Very happy with decision so far and looking forward to building more stuff on their platform!
Other folks have said this same thing, bascially, earlier in this thread, but bmajz sums it up perfectly here. Can't agree more with this. Fast is best. Meteor drastically lessens the start-from-scratch cruft that makes any other web app framework/stack so daunting to learn. If they can get support for SQL in place, watch out.
If I had to make a bet on the next important web framework, I would pick Meteor. All in.. :)
Edit: They have made another good decision: seduce windows devs. Next one I believe it will be to support SQL.
They have a large and diverse fanbase, probably the most open community for newbies and the new generation of devs - the ones that come from different backgrounds - and I have also the impression that I see a larger percentage of women here than in other frameworks, that might mean something; they use the ubiquitous javascript; they promote ubiquitous computing; they have good funding; they have credible and fresh marketing; technically they are, IMHO, at least good enough. These are some of the reasons make me 'bullish' on Meteor.
My custom packaging startup Packlane (http://packlane.com) uses Meteor. Really grateful for this update since the old Mongo version had some major issues.
The reason your site is taking long to load is because you have multiple >1MB assets. Open up the Chrome inspector and look at the network tab. You're loading 7.7MB, 7.3MB of which are images. There are two gifs that are over 2MB in size. You should reduce the size of them to 200KB at most, and also consider delaying loading images that are below the initial viewport until the user needs to see them. I also recommend compressing all of your jpg's and using a tool like ImageOptim to strip out any extraneous data.
IMHO, one of the often overlooked use cases for Meteor is rapid-prototyping. If anyone remembers DHH's video 10 years ago demonstrating Rails' scaffolding [0], Meteor is the 2015 version.
I used Meteor a number of times a few years ago and was totally blown away by it. Utterly fantastic.
Then went down the route of working in enterprise java for a few years and now, trying to get into full stack javascript based development, I feel totally swamped.
I've been working with meteor since 0.6.3 and I have had only great experiences with it. I've been going to the meetups in my area which has brought me together with a great community of developers from all sorts of backgrounds - and even connected me with people from across the world via webcast. Nothing but good vibes and support in this community. I saw someone commented with the Discover Meteor book link, and that is the perfect place to start - you need literally zero coding experience to build a production quality app within an afternoon. Also be sure to check out the Telescope project (http://www.telescopeapp.org/) put together by one of the co-authors, Sacha Grief - a designer out of Osaka. He is seriously one of the most dedicated, helpful people out there when it comes to Meteor and I can guarantee if you email him he will respond with help :)
Definitely my biggest current beef with Meteor. It seems technically possible and I understand why they would go with Mongo first, so hopefully its just a matter of time.
This looks good with the videos. I'm contemplating building an app that requires SQL. I've built a few apps with meteor but mongo's lock keeps crashing my website down.
The current third party packages with SQL support are very experimental and don't support nearly as much as the native mongo driver.
I assume when Meteor does this or if Arunoda does it would be pretty awesome. Especially with PostgreSQL since it supports native live queries.
Responsive usually mean that if you display info from the database on a web page and the database info changes then the info on the page updates automatically. Meteor does that with Mongodb.
I get an astroturfing vibe from Meteor. Coming from the consulting world, I have seen this too many times from entities with vested commercial interests. For this reason I always withhold any opinion until real world experience checks in from someone trusted.
A little over a year ago I did an experiment. I had coded up a small rich client web app in Clojure + Clojurescript (which I love, and use a lot!). I then spent the same time rewriting in Meteor, except that I ended up spending much less time and got a lot more functionality in the Meteor version.
I really recommend that you try it.
I hope for really good Clojurescript support in Metoer. I tried it last week, the Clojurescript support only supported older Meteor 0.9* versions, and I had problems. It is on my radar to keep checking the Clojurescript support. I also tried the TypeScript Meteor support, but didn't spend much time with it.
Absolutely, I made a comment making a similar point when they hit 1.0
The Meteor marketing team seems to want to entrench themselves in every naive tech company they can and I can't believe that there could be so many Meteor users here with enough experience to comment so stridently on it.
My experience with Meteor was that my current company hired someone (who is/was literally writing a book on Meteor) to be the lead dev and they built a whole dashboard application in Meteor.
I arrived 6 months later and began working with them on that application and another Express app that they flat-out refused to touch.
I found that though Meteor was easy to pickup and figure out at a surface level, that it got very complex very fast when you started down the path of making a large application with lots of moving parts. Performance was terrible and there were always strange quirks and assumptions that Meteor would make that needed to be worked around later (one instance was their use of random string _ids in mongo which weren't valid ObjectIds).
Meteor tries to do everything for you and when you want to do something different, you have to go find some esoteric knowledge to hack around some core architecture or pattern. They don't play well with others and any questions or criticisms I had for this Meteor evangelist usually resulted in abstract arguments that boiled down to me needing to change my entire way of thinking about web apps to work with it effectively.
One of my arguments was "hey, where are all the other meteor devs? what happens if you leave or get hit by a bus?" which was also deflected somehow or made to sound ridiculous...
4 months later they leave to start their own consulting company and try to get themselves hired as an outside consultant for whatever rate.
I rewrote the entire application with a MEAN stack in 6 weeks with more features, better performance and a decoupled architecture and we've never looked back.
Admiral Ackbar would recognize Meteor for what it truly is... but unless you've got a Jedi or 2 on your team you'll want to be double and triple checking your needs before moving forward with Meteor.
Sorry you had a bad experience with the developer.
However, there is no such thing as the "Meteor marketing team". Meteor doesn't employ any marketing people (yet). Anyone talking enthusiastically about Meteor is just genuinely excited about it.
I'm curious to hear specific examples of esoteric concepts that you had a tough time with. In my experience, Meteor is the opposite of esoteric and actually very easy to work with, even as application complexity increases. If you can outline your issues, maybe we can try to address them. Thanks!
I didn't have a bad experience with the developer so much as my company did. They paid the person for a years worth of development that was scrapped because it was in an esoteric framework.
DDP is an esoteric concept, the idea of mini-mongo is an esoteric concept. And the tough time I had with them was in understanding why it was important for our application and how I was supposed to accomplish certain things within the construct.
Here's another example, we had the need to allow users to upload a zipped folder of web content which would then be unzipped to a location on the file system that was acting as our "cdn" until that location was an actual CDN.
Everything about accomplishing this was an enormous headache because it had to be done the "meteor-way" and it wasn't even a dogmatic thing (like some people are about the "angular way")... we literally had to do everything the Meteor way because it's isomorphic and you can't isolate anything outside of it without tremendous pain.
Another example of Meteor problems? How about when it upgraded to 0.9 and I couldn't run `meteor --version` without it trying to automagically upgrade to 0.9, which was a version that broke all a bunch of the 3rd party meteor plugins we were dependent on. We had to essentially just pray that our production application didn't spontaneously upgrade itself and embarrass our company during a fund-raising round.
You can apologize all you want and blame whatever on this particular dev and/or a naive implementation; but the truth is that Meteor over extends itself with its blatant self promotion and cares more about getting entrenching itself in the startup/web-development zeitgeist and than it does on actually being a useful tool.
You know you can always try it out yourself. I am not trying to be condensing, I also hate it when companies promote their product via astroturfing, but at least meteor is open source and Meteor the company has yet to even release their commercial product (its heroku like hosting).
If you're just learning about Meteor or haven't really checked it out yet, I recommend reading the mission page: https://www.meteor.com/about - not only is it inspiring, but it helps frame what they're shooting for. The first paragraph:
"Writing software is too hard and it takes too long. It's time for a new way to write software — especially application software, the user-facing software we use every day to talk to people and keep track of things."
Meteor is great i used it to prototype the live section of www.sportskeeda.com. Then i had to switch to jquery polling to make it faster. Meteor was fast except for the initial load that used to take a couple of extra seconds. This was reduced to large extent on Modulus.
So my suggestion to anyone considering Meteor in production is to deploy on Modulus.
It only support Mongodb because it is built on a specific mongodb feature. Basically, if you update Mongodb outside meteor, meteor can track that change.
I took a look at Meteor pre-1.0 and definitely plan to revisit. I just checked to see if "Mongo package fails to report closure of inactive cursors." [1] is marked resolved. I may be misremembering the issue, but it seemed like a bug with a smell. The sort of subtle bug that might measure the water level, one that could be hard to debug for a beginner if encountered in the wild and one that is essential to have fixed for production apps.
Great! Curious about MongoDB 3.0 and WiredTiger storage engine performance in my meteor apps. Also curious how it performs in comparison with PostgreSQL.
They have forgot to think about deployment. Creating a package for Meteor, for a Linux distro, is a major pain in the ass and discouraged by the Meteor developers.
It accomplishes many things that other frameworks don't, the most important of which are ease of use and dramatic productivity gains. I recommend reading meteor.com/about for a high level overview and then diving into the description of projects at meteor.com/projects to understand how the various components of Meteor function. The original screencast at meteor.com/screencast is also a very useful introduction, and if you want to spend about half an hour building an app to get the basics down, meteor.com/try will do just that.
Using phantomjs to index your site has not caused any problems for most of us building apps in production for the past two years. From an engineering standpoint there are better alternatives such as server-side rendering (btw, there is a Meteor package that does this: https://github.com/meteorhacks/meteor-ssr), so outside of performance considerations this isn't a super big deal. A lot of Meteor apps also aren't Google-facing but instead apps that you use after log in, where Meteor's advantages have the biggest effect on one's productivity.
Meteor works in every evergreen browser and quite a few older ones. It will fall back to polling if there is no support for websockets and the Blaze view library works in IE8+.
I recommend just trying it out. It takes no time to install and get your first app started (<1 min) and you will immediately start to see the benefits. Come tell us more about your situation at forums.meteor.com and maybe we can help!
not sure how ddp works or how to scale a meteor app.
does not work with postgresql or any other db.
The biggest issue for me is the tight coupling to MongoDB.
Background: we used Meteor back in mid 2013. we ended up wasting a lot of time and resources because we had to learn everything. when we did, it did not perform so well, over 1MB going back and forth for what could've been achieved with a simple LAMP or ROR app. I think they've dropped Meteor completely.
Anyways, the windows support is nice. Might give it another go now. Not sure what the deal is with MongoDB 3.0. I've been using postgresql entirely now.
It's not "tightly coupled" to MongoDB; Mongo is simply the only database that livequery (https://www.meteor.com/livequery) has implemented support for at the moment. There are community projects for MySQL and PostgreSQL, as well as partially complete drivers for Redis and Elastic. Official (My)SQL support is on the roadmap and will probably appear later this year.
Even seeing Meteor from a prototyping perspective it looks like a great tool. The integration with MongoDB (3.0 is fantastic by the way) and ability to quickly create and work with collections from within your Meteor applications without really needing to glue anything together or configure is something that appeals to me (especially as a front-end developer who is asked to prototype things quite a lot). Coupled with the support for authentication, user accounts and easy deployment, these are definitely key features to a modern web application.
Windows support is definitely an added bonus, especially for me who switches between a MacBook Pro and a PC for .NET development.