What is meteor or Life cycle stage

[mickaelb]

This post is intended for those who, like me, have doubts, questions, or
wish to understand few things about meteor that are written nowhere.

This is just a sincere testimonial, which I hope will help to get
doubts out of minds.

=================== ===================

I met meteor at v1.0.
I had never build any web app at this time.

So I started picking up tutos here and there, but what really got me off the ground
was the fabulous Discovermeteor (@sacha/@tmeasday) book:

• Clear,
• Accurate,
• Just the right level of information.

I mean, when you’re a beginner, the first thing that kills you is
the huge mountain of information that comes at you, and, as a beginner,
you don’t have the perspective to sort out what is important from what is
less important.
Discovermeteor literally takes you by the hand to get you building web app,
with meteor.

So I build 3 applications that ran for few years, for tens of thousands
of users, without any problems.

At that time, my only big problem, not sufficiently covered by discovermeteor,
was deployment. I had a bit of trouble with mup and mupX, but I managed that.

After several years without coding, I’m back to work on some new projects.
Naturally, I turn to meteor.

At the time of this writing, the current version is v1.10.

The first thing I did is deploy simple-todos, the default application in meteor.
Indeed, the deployment is what caused me problems when I first used meteor
several years ago.

Unbelievable: thanks to meteor forum, and especially with the help of @cloudspider,
I succeed to deploy application in less than 30min, on Heroku + Atlas
(understanding Heroku and Atlas included in this 30min ).
Simple and magical… just like meteor !

So I was very confident for the further building of my application… Error !!!

Starting with meteor doc, I discovered a lot of new features that completely
frozen me:

• React, Vue, Angular, Svelte where I only knew Blaze in v1.0
• Imports folder to manually manage the files load,
  where everything was magical in v1.0
• Import/export, let etc… where you were just coding in v1.0
• npm modules where Atmosphere was just too cool in v1.0
• Appolo, etc…

All these things froze my minds. I was in the dark.
Understanding nothing. Full of doubt.

• Why all this, when it worked so well with v1.0?
• Why so many different elements, for the same purpose: simply build a web app!

I already have to solve several questions for my application
(which design, UI, UX? Which datas? Which functions?..),
but now, I also have to be interested in questions like:

• Is it better to use React or Vue or Angular…Or stay on Blaze?
• How to use this new imports folder
  (and surcharging my attention with hundreds of import lines) ?
• Should I be interested in Appolo or stay with DDP
  and what comes by default in meteor ?

Not to mention flow-router-extra which replaces flow-router…which itself replaces iron-router.

In short, hundreds of new questions (that have nothing to do with my application),
for which I didn’t have time nor want to face. That’s why I choose/trust a framework :
to delegate these unwanted questions.

So I put my application aside and I studied these different tracks:

• I read everything that was available on React, Vue, Svelte and Angular…
  And comparisons between them!
• I made a few tutos with each of them
• I played with import and imports directory.
• I played with flow-router-extra
• I used npm modules
• I discovered Appolo (theoretically, no tuto realized)

In short, it tooks me 15 days to pull out my hair understanding “the why”
of each new element, when meteor’s v1.0 was just magic to me.

My understanding is as follow:
Apart from political and commercial considerations,
it is mainly a question of NEEDS and RESOURCES (time, people, money…).
These needs and resources evolve according to application life cycle.
For example:

• AT THE BEGINNING, “birth of the application” :
  I have few time and resources for the application, and my needs are just to
  put my app online for few users, as soon as possible !
  So I need simplicity and all users know that my app is in its “infancy”:
  ==> they are ready to wait 10 seconds until ALL files/datas are loaded.
  ==> I don’t have to bother with imports or with questions about
  optimizing the rendering of my UI.

• AT THE EXTREME OPPOSITE, when my application is consumed
  by millions/billions of users,
  I have huge resources (employee, money, etc…) like facebook for example,
  and I can go out and get more complex tools, to save me load time at startup, for example.

So, all this comes down to the application’s life stage:

• At each stage, needs evolve and resources to implement must evolve too.

That’s why, at the beginning of my projects, I choose to keep Blaze + DDP,
without shooting my head with imports, because I need simplicity and efficiency
to quickly launch my application.
And when my application will succeed, as Facebook for example, well I’ll use
React because I’ll probably have the same problems as Facebook…but also the
same resources (financial, human, etc…).
Because for me, using react for a “small” application is like building a rocket,
when one kite is enough.

So, what is meteor ?
For me, meteor is a scalable framework that allows to meet the needs of
an application, depending on its life’s stage.

But much more than a framework, meteor is a community.
A community that has gone through highs and lows,
that has been under tremendous strain, but that is still here and moving forward.

Realizing that, I am much more confident in my choices and in the community.

So for all this confidence, I have only one word to say to the meteor community:

THANK YOU - MERCI - GRACIAS - DANKE - OBRIGADO - GRAZIE - СПАСИБО - ありがとうございます - 谢谢你啊 - شكرا

[znewsham]

There’s rather a lot to unpack here - but I’ll do my best to hit all your points, without adding too much of my own opinion. It isn’t super clear if you’re asking a question about meteor and it’s decisions, or stating that you liked the decisions made or didn’t understand them? I’m going to treat the post as a question about the decisions/options available, as that’s how it reads.

Back in Meteor 1.0 (and before) Meteor was very opinionated about it’s stack. Mongo + Blaze + DDP over websockets. There’s nothing wrong with this stack, it is now kinda referred to as “Meteor classic”, I know of at least 2 relatively large companies using this exact stack who are extremely happy with it - and I guarantee there are more I don’t know of!

However, there are those who, for whatever reason, do not want to use Mongo, or do not want to use websockets (some would say it’s easier to reason about HTTP requests from a security/scalability/reliability point of view). This is where GraphQL came in - it opened up the stack to allow any data source (Mongo, MySQL, external REST service, whatever). More power = More configuration.

At the same time, React (and later Vue and Svelte) built up large communities, and with them came community packages for building common functionality. Meteor decided to decouple it’s UI from it’s core - you can still use Blaze, but now you can use essentially any other UI framework too. I won’t get into the pros/cons of each - but it is entirely up to you which you use.

Similarly, at the same time (or possibly a little later) NPM became the defacto standard for package management within Javascript. Many of the packages that had previously been deployed to atmosphere were no longer required. Also, the entire Javascript community embraced ES6 (and later 7) which allowed for many new features, and vastly cleaner code. You can still make a meteor app using auto-imports by excluding the meteor key from your package.json. There are downsides to using auto-importing, you lose the ability to have dynamic imports (to reduce your initial bundle size) and it is hard to reason about. You’ll see applications that name things like 0common or 00loadfirst to try and force the load order of components that must be available first.

In regards to the packages available, Meteor has suffered from a bit of “churn” some of the commonly used packages were no longer maintained and so replacements sprung up that did “the same thing + X”. Similarly, as with all communities - it’s members have their own needs and chose to build similar packages to accomplish the same job. Flow Router isn’t really a “version” of Iron Router. It accomplishes the same goals, but in a different way. flow-router-extra is an extension though. Recently things have improved due to efforts to have community maintained packages: https://github.com/Meteor-Community-Packages/

I’m sure there will be many posts to follow that will talk about the selling points of all the different options. But ultimately they are very specific to your application/business needs. Do you need to have reactive data from MySQL? Do you need to use third party react plugins? Do you need server side rendering, or to support truly native apps (e.g., with React Native).

[alawi]

@mickaelb

In short, it tooks me 15 days to pull out my hair understanding "the why"
of each new element, when meteor’s v1.0 was just magic to me.

In addition to @znewsham said. The short answer is that the web development ecosystem in 2012 is very different than what we’ve today in 2020, there are more view layers and data layer protocols and Meteor managed to adapt those changes while maintaining backward compatibility. Meteor classic is still available and a good option if that is what you prefer. You’ll still need to make those design decisions (the view, data layer and db) with any node framework you pick.

I for one started to use Meteor heavily when it added React and now we’ve Svelte as well, so I think the flexibility at the view layer made Meteor richer.

[rjdavid]

Flexibility always come with the additional cognitive load of choosing options. This is a tough balance on minimizing the flexibility allowed to be user-friendly for new comers, but at the same time flexible enough as you improve your skills and knowledge.

[cloudspider]

One of the learnings I got out of this experience is that we need to improve the guide, improve the way we communicate to the community about the different choices and what the best practices are in these choices.

Most people choose certain tools to start with - not because they must be convinced that this is the shortest route, but because they are used to these tools and are confident to make deadlines with these tools. If people don’t know Blaze or DDP, they will not use Blaze or DDP for their new project and instead choose something that they are familiar with - like React Angular, Svelte, Vue, Apollo, etc.

People don’t like new stuff if it doesn’t promise them awesome powers. But when it does, most fall for it and go all in.

It used to be easy. Blaze was light-years ahead of anything you could find. It made the choice easy for people to build UI’s, but its upside was pretty much also the main downside. It’s coupling with Tracker and Meteor. Then React, Angular and Vue came in - an independent tool to build modular UI’s and one of Meteor’s main selling points degraded into “one of the many UI tools”, but with the same downsides.

However, Meteor is way more than just the UI. It has so many advantages that it would be weird not to use it. The new Meteor should be communicated as a full-stack platform that allows people to build any UI and API using their own favorite tools in a way that works best for their favorite tools. If you want to use Vue and Apollo, great, follow these steps and you will have the benefits of your own tools with the power of Meteor, its community with best practices, its guidance and some awesome hosting providers like Galaxy.

[mickaelb]

Lots of good things here. Thx !

As a new comer, 2 mains things :

1. Flexibility is a great things for expert, but a real big problem for newcomer.
   As new comer, I can’t decide which tools is appropriate to which things. I just want a kind of “simplest path” to build and run something. Then, once I learned all big principles, by experiencing them, I can go and try an other way, gaining more control, dig deeper to become an expert…
   But at first, too much complexity and too much choice, slow me in my goal to build and run something. It kills my brain, kills my motivation and can rebute more than once.
2. Completely agreed that guides, docs and tutorials should be improved.
   When using them as newbie, I often don’t understand because not “practical” with lots of new concept/word. But when I gain experience, I can read them and I understand them.
   These constat make me thing that guides, docs and tutorials should be “level tagged” with something like “basics”, “intermediate” or “expert”. Even best, if possible, tags should be something operational, like “need to be known for basic project”, “deeper knowledge” or “to optimize database”.
   Like that, new comer and people that don’t need to optimize their database, don’t care about this information and they don’t have to try to understand and waste their energy and motivation on that.
   As a newbie, for a basic app, I don’t have to know about DDP, writing npm package or webapp.
   Just like I don’t have to be a car mechanics to drive a car. I’m pretty sure that if everyone has to know all the mechanics stuff of a car before driving one, few people will get a driver licence and majority will drop.

Filtering guides, tutorials and docs in “levels” is hard to do, but it’s really valuable and allow people to feel secure in their learning way.
I just need one way to do things. And later, I could go for deeper knowledge to find my own way.

Meteor is a powerful framework, with an extraordinary community. I hope this will be improved to make people love it at their first use

[alawi]

@mickaelb

Filtering guides, tutorials and docs in “levels” is hard to do, but it’s really valuable and allow people to feel secure in their learning way.

I was a newcomer at some point as well and I started with React. You need to a pick a view layer and then get going, this is a subject choice at the end of the day, you can’t please everyone. If you everyone to use X, or Y, then you’ll lose a huge chunk of the community.

But once you made up your mind, your mind you just start from here

Which is really straight forward, and this is giving you a full-stack end-to-end. If you go with other frameworks, you won’t even have a backend or you have a backend without front-end, or you won’t know where to deploy, so the complexity of choice will be much greater.

@mickaelb

Completely agreed that guides, docs and tutorials should be improved .

This is an open source project, and there are folks currently improving it, you can join the slack #doc channel and help to improve it.

[mickaelb]

Thx @alawi, I’ll join the slack

I did the tutorial you pointed and take it as example when building my app. It’s really a good entry point.
The app I’m working on is a basic app too, but I have to add simpl-schema, collection2 and autoform in my building process. For now I am trying to know more about Grapher and Apollo to choose (or not) one of them.

Don’t you think we could add to this tutorial the use of these package to show an easy complete way to build the “To Do App” without digging in each package?

Or maybe there is an other simple way without using those package for a basic app ?

I can’t figure out what are “basic” packages that can help me reach my goals as faster as I can to build and run an app, with a moderate security level. I had to study simpl-schema, collection2, autoform and now I have to look at Grapher and Apollo. All these frustrate me because It “slow” me from reaching my goal and make me decide on tools that I feel are “out of my business”.

[alawi]

@mickaelb

For now I am trying to know more about Grapher and Apollo to choose (or not) one of them.

You don’t need to use them, it really dependents on the team size, the use case, your personal preference. The todo list didn’t mention them, the Meteor data section in guide doesn’t use them, it uses Method RPC which is much simpler.

Why do you think you need to start with them?

@mickaelb

simpl-schema, collection2 and autoform

You also don’t need those but simple-schema and collections help to make dealing with collections easier and enforce some structure.

I’d suggest to keep things simple and only add things when needed, specailly when getting started, if you follow the tutorial + guide, you should be able to get a full app working, this is how I started as well.

[mickaelb]

@alawi Thx for your advice, it really help to move forward

@alawi

Why do you think you need to start with them?

Because of that : https://forums.meteor.com/t/grapher-apollo-or-pub-sub/53335
Mainly because of normalized mongo database. Am I wrong ?

Once again, ths @alawi

[alawi]

The project has already 5 mongo databases? so you’re not starting with a greenfield project?

[mullojo]

Very nice story @mickaelb , I think it is not an uncommon one for many people who started using Meteor in the Blaze only days. And I think as a community we appreciate the gratitude and Thank you for sticking with Meteor, there really is not a replacement for everything that Meteor does, so most web app developers are in a massive mess of choices, much greater than one would ever experience with Meteor, and that’s even before they get to the thinking about the back-end, haha.

I built my 1st Meteor app with Blaze and now my go-to front-end (view layer) is Vue. I’ve sometimes had some of the same frustrations trying to learn while needing to build fast at the same time, but I think that is just part of the progress of becoming an experienced developer.

Meteor’s tightly coupled “classic stack” with only Blaze was super magical in it’s time and should probably be considered more magical today than how most of the developer community sees it yet today.

I’ve gone from only building my app, to really enjoying the contributions to an open source project and community in addition. I think open source is the future and Meteor is the best hub to build around in my opinion if you like to build full-featured apps. A bunch of us, including me, have been trying to think about solutions to the frustrations you experience, because really all you needed was guidance & confidence during your exporation.

In the JS world today, there is no way to avoid running into ALL THE THINGS that make for questions & curiosity, and yes some of those things will suck some of your time, but try to enjoy the process as much as you can! I think that is life in general, we all have to navigate it.

I really like your idea of “beginner”, “intermediate”, and “expert” levels of docs. What @sacha did in the early days of Meteor was make Meteor even easier to understand, at that was all because of his ability & passion to write a hand holding path for new devs. I invite you to join us in making this a possibility! My main tip is to enjoy what you can contribution/give vs. trying to get/take, this makes all the difference in life, and it’s what makes open source communities hum. Imagine what thousands of us can do together, it will always be greater than what any 1 company or person can do alone.

Before Meteor I thought it was just not possible for 1 person to build & manage an entire full-stack app, after Meteor, I realized that possibility. And most people not using Meteor today, have not gained the full set of skills to build & maintain beautiful multi-user, realtime, secure apps at scale without needing a bigger team.

The productivity with Meteor is insane and recently I just got mobile & desktop versions of my app thanks to some PWA magic added into Meteor too! I would not have even discovered these possibilities without the Meteor Community. @alawi kept talking about PWAs and @jkuester wrote a really easy guide to implement them. I still did many days worth of my own research & learning, but now I’d consider myself a PWA expert, so in the end we all share & gain and I hope I can help make it easier for others!

[mickaelb]

Related to my answer here, meteor is really incredible : one newbie like me can easily build, deploy and run a newborn app and get more ressources as soon as the app grow.
The only thing I need “is guidance & confidence during exploration”, like said by @mullojo, and not being harassed by “potential future questions” that will come when the app will grow.

Understanding WHAT meteor tool I need, WHEN to use it and HOW to use it, clarify the process of building and running an app. I don’t have to doubt or to be confused with lots of questions. I can just focus on my app logic, standing on the shoulders of a giant : meteor.