First and foremost, I hope you and the folks around you are safe and healthy. My name is Matt, and I’ve been helping with Meteor over the past few months on the marketing/ops side. It’s been a fascinating run so far. Working with Filipe and the rest of the team has been a real treat. I feel very fortunate to be able to work on a product that’s so well loved, and we have more coming that is really exciting.
Part of what I’m currently doing at Meteor is communicating the value of the framework and Galaxy to a new audience. I know we have a great product in both Meteor and Galaxy Hosting, but the public perception and onsite communication of that value has deteriorated over the years. We’re going to bring it back.
So I figured, who better to ask than the folks who work with it? That’s where I’m hoping you can help me out.
I would love to hear from you on a few things: if you’re currently building with Meteor, why? What do you think is the key value that it’s providing, relative to other frameworks out there?
Same question for Galaxy Hosting – why are you using Galaxy? What’s the key feature, set of features or functionality that keeps you a customer?
Thanks so much in advance for any insight you can give me. Again, very excited to be here and work with you on making Meteor and Galaxy better.
I have been working with Meteor since v1.0 and it has been a nice journey. I came from a PHP, JS (jquery mainly), java and objective-c background and using Meteor was awesome to start my path on fullstack JS.
I started using Meteor because it was easy, I remember checking out ember, angular and some other frameworks but those needed to be paired to an independent server. Meteor made things so much easier at that point, I had everything in one place. That is almost still true and that’s why we still use Meteor. Is easy and fast to build apps with it.
So the main value for me is speed and ease of use. There are some things that could be greatly improved to make the value not only speed and ease of development, but also speed and performance on the bundle size (I know that is in the roadmap, just saying) so that we can have very fast and realiable apps for our clients even when they have slow connections and not very powerful devices.
Unfortunately we dont use galaxy, mainly because of the pricing and because we have had since the start of our company free AWS credits. I have found that there are many services that have similar offerings, being the main differentiation of galaxy (in my point of view) having almost all the services needed in one place. Almost, because you dont have mongo and redis. Instead of galaxy we choose to use waves and mup to manage our different deployments, monti for monitoring and AWS for servers, lambdas, mongo, redis, S3 storage, SQS, SES and other services.
Hope this helps you not only to undestand why we use and love Meteor, but also how is galaxy value proposition and princing not a good fit for a startup like us at Propiedata.
Awesome, thanks for your thoughtful response. Very helpful. Happy that some of the asks here are already on the roadmap. Speed, ease of use and reliability are things we’ll continue to improve on.
The Galaxy piece is interesting. You’re right - the goal here for us is to have everything in house and continue to improve the offering so users don’t have to rely on auxiliary products to augment. I totally understand where you’re at with costs in your current stage of development, and we’re working on adding to it so that the time saved makes Galaxy the best option for Meteor users
Meteor has had excellent support for ECMAcript and ES2015 modules since Meteor 1.2 in 2016. It also includes zero-config support for JSX syntax for React.
Meteor is a great ECMAscript build tool which can be deployed using meteor deploy or mup.
Comparing Meteor with other build and bundling tools, I think the scariest thing about Meteor is its package system, which is Meteor-specific and so if you use Meteor packages your code can’t be bundled using other tools. Similarly, if you use Meteor packages you must use the meteor test command to test your code.
I tried removing all Meteor packages, and it turned out that webapp was the one and only package that Meteor could not run without.
However, if you don’t use Meteor packages except for webapp and ecmascript (and other packages that don’t need an import { Foo } from 'meteor/package-name', e.g. static-html, standard-minifier-js and es5-shim), then you are writing JavaScript using the latest ECMAscript specs. And while other build and bundling tools might or might not support that code (depending on what plugin(s)?), Meteor does.
I think it would be a good idea to promote that Meteor has
1.) Great support for React, Vue and Svelte. (for people that dont want to use Blaze)
2.) Easy to use accounts system out of the box
3.) Real Time functionality out of the box
4.) Makes testing your local atmosphere packages easy
I think a big hang up is Mongodb being seen as “part of the package”. And in 2012-2014 when mongo was at the peak of its hype that was a plus. But now its kind of negative almost and you have to sell people on using Mongo instead of SQL, or using offering to them as an alternative apollo.
I think Grapher might be a part of the solution to that problem. And just leveraging places like Cult of Coders experience in building apps in Meteor to help explain that those hurdles can be overcome and how they can be overcome
I started using Meteor around 1.0. I think I read an article somewhere about how easy it made it to write reactive UI’s seamlessly tied to the database - and that’s still the same reason why I use it today.
For me it’s Optimistic UI and pub/sub. Coming from a PHP/jQuery background it eliminated having to think about client vs server - now the client just subscribes to the data it needs and interacts with it as if the server wasn’t there. So time saving - no more having to write API’s in PHP on the server to send data to AJAX calls on the client, then using jQuery to update the UI.
And the fact that Meteor had accounts and even accounts UI built in made it super easy to get started. Within one evening of playing I had a proof-of-concept MVP working for an app my workplace wanted - just as experiment to try this new toy.
Free hosting at *.meteor.com was also essential to me getting started with node.js. I could learn Meteor and get the app actually working and useful for my colleagues, and then figure out the deployment bit later.
For our little toy apps at the start Galaxy was just way to expensive when AWS was giving away a free 12 months. Then I stuck with AWS after the free period, then moved to Digital Ocean when it was cheaper. Meteor Up made deployment easy, so why use Galaxy?
I eventually moved from Blaze to React and then to Vue.js (which I love). These days I think React and Vue really need to be 1st class citizens, including default accounts-ui packages, so that new users who already know React or Vue can get started with Meteor just as quickly as I did with Blaze back then.
To me it’s still the best zero-config bundler for any JS project. Nothing gets me faster done things that matter.
This also makes managing large codebases easier, because the project code focuses on the stuff the software should get done and not the environment code.
At the same time integration for nearly any “outside” JS technology is possible or even well supported (see 1st class citizen).
The community is great.
There were always ECMA bleeding-edge technologies stable included. This slowed down a bit but we all know that the train is speeding up again
Live-data is a real thing for us (e-learning, gamification, sometimes browser games, sometimes real-time visualizations) and there is no competition to Meteor when it comes to this, especially none without complex setup
Inclusion of classic HTTP based functionality (connect, express) is super easy and does not interfere with DDP
OAuth2 workflows out of the box, no further configs required, just add the accounts packages
Flexible enough to write only backend apps, only client apps or microservices (we have all done it, it was hard sometimes but still way easier than starting by zero)
Package system is seen as weakness but it is not IMO because it is close to the Meteor environment, so less integration-errors and fast results (the only real weakness is that there are no security alerts or deprecation markers as like GitHub does with the NPM packages but that could be fixed since .version are integrated with every package making it easy to implement)
Deployment is with Galaxy or mup on custom servers as easy as it could be
Edit
super out-of-the-box and no-config support for Mongo!
There are still many improvements but this should be only about the good sides
@jkuester’s answer made mine almost redundant, but I would like to insist on the most amazing parts of it:
Zero-config bundling.
Fully stack real-time + reactive. One of the best value propositions in my view and still without serious competition out there. In the age of IoT, Meteor must capitalise on this core strength. Perhaps some examples with the likes of Pusher, PubNub, perhaps combined with storing data in somehting like TimescaleDB (also a good opportunity to show that one needs not be married to MongoDB for everything).
Out-of-the box accounts package.
Truly pluggable and extendable via packages. NPM, while convenient and widely used, cannot extend a meteor app in a way the Atmosphere packages do. Perhaps the packages should not be marketed anymore as such, as people see them as a failed competitor to NPM, but named something like, say, “custom bundler modules”, “Meteor extensions”, etc. Webpack has something called plugins (admittedly fulfilling a different role), so the packages could be regarded as Meteor plugins.
Last but not least: as a result of the above, Meteor helps to quickly build from prototype to product on a shoestring. Testimonials and interviews from owners/developers of successful products (be they even internal) are key.
Just to add my two cents, it’s pretty much just agreeing with the prevailing sentiment here. But just wanted affirm the above reasons why Meteor is great.
I’ve been using Meteor as my exclusive development environment since the summer of 2013 when our startup decided to use it to build our product.
I’d say the greatest selling point of Meteor has always been it’s clarity in getting from 0 to prototype. The pieces which make things straightforward and clear are:
The Build tool
Meteor Accounts
The docs and guides
The learning tools (such as discover meteor and the level up tuts videos)
Over the years I’ve moved to using React and Apollo GraphQL for my new projects. Keeping up with the latest technologies has also been a strong selling point for me.
I have always used Galaxy because of how easy it is to use Meteor Deploy and I always wanted to support Meteor so that development would continue; and with the new plans, i’ll use it for even more projects. Having a free sandbox as we had in the past would be nice, but I also understand if that is not financially viable.
Finally, the things that I believe would help to communicate the value of Meteor. Would be to update the guide and docs, and to add more official support for Apollo. I think this is the easiest way to communicate the flexibility of Meteor on the data side, to show that you can use any database you prefer. I also think an updating of the Meteor accounts with React components, and an official Apollo version, would be a big step in really leaning into one of Meteors best features, it’s easy to use out of the box accounts feature.
Let me preface this by saying I love Meteor, just like you. Been using it since 2014, and still do. While I fully agree with all of the great points listed above, I think from a marketing point of view it is also important to acknowledge the ways in which Meteor has gotten a bad rep over the years. As these are the things that are keeping people away, not the lack of shiny features in my opinion.
In my experience trying to convince agencies or other devs on using Meteor, these are the pushbacks I often get (directly or between the lines):
Meteor is just a toy framework, nice for prototypes but not a solid base to build on
Meteor is for people that are not really skilled programmers (this will only be amplified if we keep focusing on how “easy” everything is)
Meteor doesn’t follow best practices (like not using NPM for installation, it just looks weird compared to other tools/frameworks)
Meteor does not scale (I know we’ve beaten this to death, but it’s still a perception — and also a reason why focusing on the real time live data without acknowledging this concern I think will only backfire)
It’s better to build it yourself (while I, as I think everyone on this forum, love the zero config and the fact that I don’t have to spend any time on bundling, deploying, devops, etc, I also think we are a rare breed among developers. A lot of devs like tweaking with this stuff, and feel that it’s the only way to get the best setup. So you will not convince those by focusing on the ‘magic’ of the zero-config setup. Maybe the solution here is to instead have detailed explanations of what the setup actually is, what choices were made and why. Like the specs section of a MacBook page; you can expand it or skip it, so people who want to can get into the nitty gritty, but they don’t have to.)
Meteor is not secure (also a very old story, we all know the insecure and autopublish packages were there purposefully for ease of use and speed to get started, this decision has damaged Meteor’s image badly (comes back to the “toy framework, not for serious apps” perception). This is also why I insist we should not again focus on how “easy” and “fast” everything is, at least not without giving a lot more technical insights because it will only reinforce this existing perception).
Meteor ties you to Mongo which I’m not sure is a good database (often I have to work to sell Mongo as well, especially if other devs are more familiar with relational DBs).
Meteor is hard to customize; it’s great as long as you’re using it as intended, but if you want to do something differently it gets really difficult
You cannot/It’s difficult to host Meteor where you want (like in your own Docker container)
Meteor requires you to buy in to their whole stack (this could be fixed by a “Make it your own” section on the website: choose your fav front end framework, Postgres instead of Mongo, connect a custom backend to DDP, … — by the way, there are a lot of the people doing very cool stuff like this here on the forums . A cool way to reinforce this could be with cases; “Read why Company swapped X for Y to support use case Z”)
Also, I think it’s good to realize that the speed and ease of use apply to us in part, because we are used and familiar with the framework and its ins and outs. For newcomers, there will be a learning curve, likely making it less fast and easy to get started than what they’d normally use. Most devs probably also already have a set of tools they take from project to project (components, packages, Webpack configs, …), which already gives them a similar dev experience.
Please don’t hate me :), I am genuinely writing this to help, not to attack Meteor. It is also just based on my experiences, so it might not be representative. But do keep in mind, and I’ve said this elsewhere, that here in the forums is quite a bit of Survivorship Bias. Of course we are all convinced by Meteor’s features and benefits, but this is about convincing people who are not on the train yet, and everyone that left to come back.
Certainly don’t hate you! Quite the opposite in fact – this is very valuable. Really appreciate this. Lots of food for thought about ways we can improve and bring more people to Meteor!
. A cool way to reinforce this could be with cases; “Read why Company swapped X for Y to support use case Z”)