7 years ago, I’ve build my first Meteor app. This application has grown, and evolved into a Saas that’s still running, and being worked on, today. I’ve been trough a few phases of which I believe many of us would recognize one or more:
OMG! Awesome! A realtime app up-and-running in a few minutes!
HELP! It doesn’t scale!
Euh, why are you killing Blaze?
Meteor is DEAD!!1!
I need to migrate away, what should I use now?
Perhaps it’s just stable, and past the hype stage
I’m still a bit concerned about the (lack of) activity in the git repo, and the (lack of) support from MDG. But on the other hand, I’m also still unable to find a platform that could replace what we have with Meteor.
In my current code base, I’ve reduced the number of dependencies on Meteor specific code. But I’m still:
And I’m willing to contribute my 2 cents to strengthen the community.
Something I read quite a lot, is that all meteor books and tutorials are at least 2 years old. And thereby out of date. I believe I can contribute by fixing that.
But for that, I have a question for you.
What are the questions you have? For what scope or for which subject do you wish to see tutorials / documentation? What is it that https://docs.meteor.com/ is lacking?
From what I observed it seems not so much to be the Meteor docs or guide. Of course they need continuous improvement but newcomers should be very well served with the guide and the docs. Many basic questions on Stackoverflow I have answered were covered by references to one or both of these two.
However, what I think is missing is a lot of up-to-date hands-on tutorials of “how to integrate Meteor with XYZ” or vice versa “how to integrate ABC with Meteor” or “how to create a 123-tool using Meteor in under 5 billion years”.
Thanks. That makes some sense. I had some “advanced usage” issues myself along the way. I needed to add a build step, prior to the meteor build process.
I always ran a script .prebuild.sh prior to the meteor build to create a file containing the current git hash. As my code required this file to exist, I decided to create a build package which runs before the building starts. Which isn’t officially supported.
Are you looking at that level? Or more at the level of integrating stuff like auth0, apollo/graphql, redux, sentry?
Since meteor supports native npm modules, I feel like “integrating” modules isn’t that exciting any more.
I think the biggest challenge is to figure out which packages are still well-maintained and which are more or less obsolete (but often not flagged as such). This can be so frustrating, especially for beginners.
If a Meteor book contained a list of “best practice” packages (Atmosphere and npm), that would be awesome. Plus maybe a sample repo that brings all these bits together in one app / boilerplate. Something like pup, but not that opinionated.
As somebody with only a couple of months of experience using MeteorJS, I am building a proof of concept application for fun.
I found the content in this SO post helpful
And i know it can look like people have moved on from MeteorJS because the date/time associated with the best books and blog posts are a bit older ( 2015/2016 seems to be the peak of interest), this information is still relevant and helpful.
I learned what i know about from Meteor in Action (2015), Discover Meteor (i think 2015), Meteor Chef (now defunct but its content is still up for people to read), this forum (which i love thank you to everyone who makes it great).
We as a community have great official documentation, and a bunch of people who love Meteor and want it be amazing. Yea maybe its not as popular as it was, but we could be the Sails community or the Brisket community. So be happy we are in the top ten of relevant JS frameworks with a few years arguably being number 1 or 2 :). And our benefactors seem to have hit another home run with Apollo so they should provide official support for some time to continue letting the community support solidify.
I am encouraged that that the MDG team is rewriting the framework in TS and I am hoping that MeteorJS’s support for coffeescript and less will be swapped or added to by creating a typescript package to replace/augment coffeescript and an scss/sass package to replace/augment the less package.
And then update the documentation to appear to be staying current with modern trends in web development. The appearance of relevance here i think will help keep the “MeteorJS is Dead” idea from forming in people’s minds
I am also a huge fan of being able to create mobile apps from the same codebase as my web project, which is teaching me how import a mobile first design approach really is. I am not a mobile dev but now i kind of want to be cause MeteorJS makes it easy to make an Android and IOS package.
UPDATE
fourseven:scss i didn’t realize this was the de-facto standard package for compliling scss files into css in meteorjs. And that mdg does have a typescript package already. I’m glad i know now tho
Mongo indexing strategies for non-trivial cases. E.g. when there are optional fields and multiple sort options, do I need 1 index with every possible field or 1 index for every possible scenario? Will $in simply work?
Step-by-step guide for redis-oplog. Recommended redis config, recommended platforms, migration guide from “mongo-oplog” to redis-oplog.
How to identify bottlenecks (slow queries, slow methods, etc).
Maybe I don’t see something, but if you don’t overuse pub/sub, you have good indexes and redis-oplog, what can go wrong in terms of scalability? And if these are the “pillars of meteor scalability”, why don’t we have a good guide on this topic?
Yea if you go to Atmosphere and search around for packages the good ones (with a lot of stars) always seem to be from 2015 or 2016.
I am not sure if this is because Atmosphere isn’t really the way meteor will be doing dependency management moving forward. Or is it “meteor npm” that is the more modern way to handle package management?
Where node modules will replace isopacks moving forward?
I didn’t notice Meteor Chef was put in maintenance mode. I wonder where all these good folks went, i.e. which other frameworks they are using now. When I did a research for a new project, I couldn’t find one that was comparable to Meteor.
Meteor Chef is still working with Meteor, they stopped and changed theyre business focus. Meteor Chef is now https://cleverbeagle.com/. It has a full integration Meteor-React-Apollo and has the codebase public for everyone to use.
Yeah atmosphere needs definitely the option to indicate abandoned packages. Some are old but just work well and don’t require further maintenance, while others inhibit fatal security issues and should be flagged as insecure.
I use Meteor for nearly everything, and anything. Heck, I built an irrigation system out of a raspberry pi (and some solenoids) with Meteor on the raspberry pi and a Meteor built iPhone app.
Yeah, they hype may be gone. What I’m left with, is a freaking stable platform I can use to create an entire EC2 fleet, data acquisition and real time streaming weather stations, and my grandmother’s b&b website… for example.
I just aced a masters course in pen testing with the help of meteor, the professor was blown away by how quickly I could create a website to do my masters project on (btw, it’s really easy to f-up security in meteor… be careful).
A meteor book… with usages like mine, and everyone else’s experience with meteor… there should be a book.
A series of guides, best practices, on how to build common application in different categories say data visualization , mobile app with real time notification sms etc. User, data storage, schema ,management with MongoDB and accounts.
Making use of reactjs
The reason why it’s hard to write a modern Meteor book is that there’s in practice two “Meteors”. There’s the “traditional” stack using Blaze, publish/subscribe, DDP, minimongo, etc. and all the other things that made Meteor great.
But that stack is not used by MDG themselves, and it’s obvious that they’re not investing any more time and effort into improving it. So writing a book is a big gamble, and your only audience is pretty much people who are already using Meteor – and to that also subtract people who’ve been using it for so long that they don’t really need a book anymore.
On the other hand there’s also the “modern” Apollo/React/etc. stack but 1) it’s vastly more complex, meaning 2x-3x more work to write a comprehensive book and 2) if you’re going to learn Apollo/React anyway you might as well go the extra mile and use Gatsby, Next.js, or some of the other platforms that have more momentum that Meteor. Meaning the audience for such a book is pretty small.
Btw I should add that Discover Meteor is now completely free so if anybody wants to take the content and update it for a more up to date version of either stack 1 or 2, be our guest
I think with the new useTracker (to be announced?), there might be an opportunity for Meteor to be the reactive data-source that works nicely with the composable, modular, importable (sharable/reusable) frontend framework React (with a nice upgrade to React Router that’s on the horizon).
I also think Meteor has a market with people who want to develop server-side and client-side code in the same repo/process, because you specify a mainModule for your client and your server (or alternatively you eagerly load from your /client and /server directories). It is not apparent how to do this otherwise (unless you’re a big fan of configuration). The Mongo stack is additive to this (but you can write packages that depend on it).
There will always be various newcomers as well as people with vested interests. For starters, there’s students, academics and hobbyists. Add to that professionals-in-charge-of-inventing-something-nobody-else-knows-how-to-do. Add to that professionals-who-evangelize-because-they-want-others-to-like-Meteor.
I think there are still a number of people who use Meteor + React + Mongo/Tracker. I’d love to see some stats from MDG on that if they have that sort of data.
I’d thought of trying to write a book based on the particular way I build apps with Meteor (using my somewhat customized data system).
Of course, now I’m looking pretty hard at Svelte - maybe there’s an opportunity there!
