Meteor 1.1 Released – Now Supporting Microsoft Windows and MongoDB 3.0
meteor.com
meteor.com
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.
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.
https://atmospherejs.com/ is your close friend. Iron Router is a very, very close friend.
Good luck!
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.
A talk demoing it: https://youtu.be/puoD7b4Ow7k
Here's how to integrate AngularJS with Meteor: https://github.com/Urigo/angular-meteor
A talk demoing it: https://youtu.be/s6IgKYsZAyI
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 :)
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.
What do you mean?
:)
The source code is very well annotated also.
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.
There's a more thorough discussion of Meteor's various parts here: http://joshowens.me/what-is-meteor-js/
You can read more about that here: https://www.meteor.com/projects
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.
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.
anyone tried something similar?
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.
Keep it up!
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)
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.
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.
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.
PS. If you are in the Bay Area, they have Dev Shops at their HQ in SF every 4th Thursday: http://www.meetup.com/Meteor-SFBay/events/221409952/
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.
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.
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).
https://www.quora.com/Which-startups-use-Meteor-in-productio...
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!
1. We will probably eventually need SQL
2. It might not make sense to be so JS heavy, especially since we are enterprise focused and may have to support older browsers for extended periods
3. General performance issues at scale that I would have with any new framework
Planning on solving these problems when we hit them - for now, fast is best.
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.
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.
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'm hoping with better VS support for Node.js, there will be more MS shops playing around with Meteor and Node.
https://www.youtube.com/watch?v=EJzulpXZn6g
Here's a follow-up talk he did:
https://www.youtube.com/watch?v=zSI68J9wNJ0
Also, there's prototype-grade support for Redis:
https://github.com/meteor/redis-livedata
And that's just the beginning. There are lots more databases that will follow: https://www.meteor.com/full-stack-db-drivers
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.
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.
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.
</dissent>
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!
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.
"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."
So my suggestion to anyone considering Meteor in production is to deploy on Modulus.
what does it accomplish for you that normal server rendered framework doesn't do for you?
when you build a meteor.js app you need phantomjs to get it indexed...it won't work on older browsers....the list goes on
I just have trouble justifying why I would need to write my next app using meteor.js
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.
(Check out my other posts on this page for links to Ben's talks about this work.)
https://github.com/numtel/meteor-mysql https://github.com/nothingisdead/pg-live-query