Thank you! Agree with you here on the learning tools and accessibility.
Appreciate you sharing your thoughts here!
Thank you! Agree with you here on the learning tools and accessibility.
Appreciate you sharing your thoughts here!
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):
autopublishpackages 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).
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!
Thank you again!
I started with Meteor shortly after the 1.0 release. I came from the LAMP stack world so it was quiet new to me, but compare to every other solution I was trying at that time Meteor just worked with just one command install, this was super awesome especially compare to the other solutions which were more difficult to setup and even if I followed their guides it often did not work. The next thing that attracted me was the account system and data on the wire. Account system remains for me the most powerful feature of Meteor to this day (would be nice to see it updated and possibly extended).
I then grew together with Meteor. When the time came I switched to React, when I needed hosting Galaxy was there and as with Meteor it was super easy to use. Same with other improvements. I occasionally try other technologies, but compare to the ease of Meteor I find them cumbersome at best.
The pricing on Galaxy (especially once I combine it with MongoDB Atlas) is more than I would like to, but I see it as a donation to the whole ecosystem and is manageable at my size (we’ll see in the future). Currently I’m missing 2-factor authentication from Galaxy and more down the road a setup for any AWS regions (something akin to what Atlas has), ie. one deploy that then gets implemented in all regions.
Perhaps not quite the format requested, but I do have some comments on how Meteor might progress. So hopefully it’s ok to post this here in free form. In no particular order.
Communicate Meteor as a set of tools that can be mixed and matched, not as a “take it or leave it” monolith. Don’t want to use DDP? Sure, you don’t have to. Use Meteor as a build tool and get data via REST or Apollo. Don’t want to use Mongo? Add a package from npm and use PostgreSQL. Want to use Meteor on the server but have React Native on the client side? Sure, connect your mobile device to the server with SimpleDDP. The possibilites are there, especially once Meteor became compatible with npm, but are not very well communicated. This would go a long way to alleviate fears of vendor lock-in, or in this case, framework lock in. Maybe Meteor’s guide might have a section dedicated to examples on different ways to use Meteor.
Don’t over-emphasize simplicity. Like @rijk said, this implies that Meteor is not for skilled programmers. Rather communicate that Meteor provides you with sane defaults, but in most cases does not limit your options to configure things yourself if needed.
Don’t get too caught up in view libraries. Let React/Vue/Svelte/… duke it out by themselves and just keep Meteor open to any view library out there. I’ve said it a number of times before, but it’s worth repeating - the semi-official Vue integration for Meteor is only about 2.5k lines of code (going by memory here, I might be off by about 500 LOC). And at least for me, it gets the job done very well, though I don’t use SSR. Given this, Meteor should be open to any view library that gets enough traction to warrant some skilled dev to write those 2.5k lines. This should alleviate worries that a view library gets left behind.
I think an interesting possibility for Meteor to generate interest is the current rise of PWAs. PWAs might finally deliver what nothing else has before - single codebase, installable on all devices, completely circumvents all App/Play store masochism and enables true continuous delivery. But the somewhat difficult part of it is the offline capability. It would be interesting to see if somebody could come up with robust offline capability for the default Meteor setup with DDP. Caching assets and handling method calls while offline. I have not thought about it too much, and there might be technical issues stopping this. But an out of the box setup for PWAs with offline capability would be very nice.
I agree, specailly with point 4, PWA are picking up and Meteor is very well positioned to take advantage of this trend, I think it’s natural evolution of the Meteor ecosystem to embrace PWA given that Meteor premise was single code base for multiple platforms.
All that is needed to have a PWA scaffolding that brings the tech together.
P.S we are using Meteor to power a PWA app connected to Meteor server using SimpleDDP (which is really nice to work with, perhaps it an be extended to have offline support) and it’s working very well, I believe it’s the fastest way to get an app to the market, our next step is to explore the offline support.
I am still a Big fan of Meteor. I think that what there was Two major things that made Meteor gain so much adoption at the beginning:
Meteor SHOULD be the platform of choice for the beginner ! But not only that… It does have ALL the technology and efficiency to hold the beginner into the platform . There is simply NO NEED TO LEAVE as it is possible to develop the most complex app with it and get not performance penalties anymore.
Thank you! We’ll be in touch
I have been working with Meteor for 4 years and build and entire companies echo system around it, its a home automation product made for builders not consumers Home Otto were based in Alberta, Canada. All our own hardware fully integrated under one home account, lights locks, thermostat and camera is in development. All run with real-time meteor, adjust a light slider and it updates with sub-second changes.
Our Android/IOS app is a meteor app hosted thru galaxy, our builder tools for reading blueprints and quoting a home automation system is meteor, our internal monitoring and administration tools are meteor as well. We have tied in Alexa, slack, firebase, stripe and other 3rd party integrations.
For Zeotec I creates a lab test management app for maintaining ice rink chillers with field service tech’s, to keep them running efficiently and the hockey games going.
We build IOT systems for monitoring environments and have them report back to a dash board and reporting system all running in real-time, which is what meteor is great for.
Meteor has had its challenges some are harder to work thru than others but I think the long term gains are worth any issues the environment provides.
For smaller projects I have started to use NodeChef which is lower cost with a database, I can host static landing pages, use s3 storage, update and add to the container. its a different beast with a more shared environment but for lesser needs works great.
right now I am working to stream a video camera to a meteor site to drive a remote drive a robot to deliver groceries, streaming is good now I just need to learn to drive
Thank you! This is interesting. Appreciate the thoughtful response here.
Hi everyone, it was a pleasure to read all those memories and experiences with Meteor, so I want to share mine as well
I’ve started playing with Meteor around version 0.4. People at my software house Vazco.eu (cheers to @cristo @michalwanat @radekmie) loved it as well, and it gained such internal popularity and acceptance that we released our first Meteor production app soon after, using version 0.6. Back then, lots of things were rough. Still, the framework already gives us advantages over alternatives we were using back then.
For what we love Meteor then and over the years?
Currently, at Vazco.eu, we have several apps running in production using Meteor. Most of them are walled-garden internal apps, but we have products like aleno.me, which is happily running on Galaxy. This is why we are glad that there is now a Galaxy roadmap and some attention. We can’t wait for the autoscaling feature
And while we didn’t start a greenfield project in Meteor for a while now, seeing the direction Meteor is heading after Tiny’s acquisition, this may change soon.
Hi @matthollingsworth! I’m late to noticing this forum post, but I’d like to invite you over to the Meteor Community Slack if you are interested to talk more about some ways we could all work together to revitalize Meteor’s reputation on the web and among various developer communities.
Before I knew this post was up, I made a pretty authentic case for what I love about Meteor, and specifically what I love about Meteor + Vue over here.
One tip I would offer is for the Meteor team / devs to reach out to leaders of other open-source communities that directly impact developers awareness and knowledge of Meteor. Front-end frameworks are where new developers learn to build things these days, and Vue stole the show for the new easiest place to START building a web app. To the millions of Vue developers, Meteor is mostly an unknown choice for a backend (this is from their perspective). I’m hoping to change this perception by helping Vue developers learn & get started with Meteor.
We’re glad to have you as support to get devs excited about Meteor again!
Thank you so much! Looking forward to working together
Hi Matt @matthollingsworth
I am 67yo and a non-coder. Classic Meteor has made complex apps accessible to an Average Joe, just like me. Hey, when Biden tells a steel worker he needs to learn to code, he is clearly referring to Meteor
Here’s my little offering…
I pipe EEGs around the planet using Arunoda’s Streams. No more Classic Meteor than that.
Happily hosted on Galaxy.
I use meteor on google servers with haproxy and hosted mongo for iot platform. Meteor is simple thats it. Though our platform has other components - mqtt, redis queues, node based event handlers, seperate analytice platfotm etc… from a mere dashboard that offers a view into operational data and interact with field devices . This JuST works!!! At the end iy ie all about decoupled architcture
I used to build with Meteor (wrote a long advocacy post in 2015), and ~5 years later, I’m semi-regretting not sticking with it. The main reasons that drove me away were: sense of abandonment, lack of support for PWAs and GraphQL, and team/community split (Apollo? Blaze vs. React?).
As others have said, it may be worth de-emphasizing “easy”, and emphasizing the serious time savings that Meteor offers. I estimate that at the start of a project, Meteor easily saves a man-month worth of coding time not spent reinventing the wheel (accounts, data sync, bundling etc.) with the “build your own car” approach.
What do others think? As long as it’s also emphasized how you can “graduate” from the initial setup (e.g. opting out of realtime data when and where it no longer make sense), I think Meteor has a winning story.
That’s true, for myself included. But I recognize there my OCD tendencies, However, when you step back and honestly ask yourself what benefits you’ve got after spending hours or days tweaking and testing and debugging your tweak, over the tried & true approach that a framework offers, the answer is often, “not much”. And it tends to be “not worth the time you’ve spent, which you could’ve spent building an actual feature”, when you ask your customers and business stakeholders, rather than your inner developer geek.
I’m totally new to Meteor and this community. I have a background in Drupal, PHP, MySQL, JS, TypeScript, Vue etc but I’m a generalist, dabbling in a lot of design/creative stuff as well. I’d honestly never heard of Meteor, or if I had I’d forgotten or written it off due to my own ignorance or just “framework overload”.
I have a largish, non-trivial app in mind and had started building a Nest backend and Nuxt TS Vue composition API frontend with MongoDB and GraphQL, I suppose because I was caught up in bleeding edge “best practice” (or my misconception of it). Then I stumbled across Svelte, saw how much faster, smaller, simpler and more rational it was than React/Vue/Angular and fell in love with it almost instantly. Then I found Meteor, I think through the new Level Up Tutorials Svelte + Meteor series, read up the docs and philosophy and I’m hooked. This Svelte + Meteor combo seems to be exactly what I’ve been looking for to achieve my goals as painlessly as possible, and Galaxy looks like a great solution for me as I don’t want to be messing about with server provisioning, config, maintenance and complex deployment. I wish Galaxy also provided MongoDB hosting as an option (even if just a convenient UI to a specialised third-party MongoDB cloud host) but it’s not a deal-breaker.
Thanks for this! I agree, we shouldn’t pushing the “easiness” of building with Meteor. What’s more important, I think, is emphasizing flexibility and efficiency.
What it’s about for me, when working for a startup, is getting to market faster. When building an MVP for a startup, there is always a limited amount of time and budget, meaning you have a limited amount of work you can put in. So, the less work you have to spend wiring up Webpack, rolling Authentication, setting up APIs, managing data, etc, the more time you have to spend on your actual product. Thus significantly improving your chances of it finding product market fit. For a business owner, this is a no-brainer, really. Even if there are concerns about ‘scaling’, it is really irrelevant if you consider that you won’t even get to that point if you spent 4 out of 8 weeks toying around with flashy tech and then come out with a crappy product. Another way to put it: when you do run into scale issues, it really is a good problem to have and you should thank Meteor for helping you get to that point.