Seven Reasons Why Meteor is Loved by Developers

community
1

Catchy title? I hope so! (If not let me know, but first, please continue)

Dear community, I want to prepare my first dev.to article and my intention is to provide an article about why Meteor is not dead at all.

Why? Give me some background!

I started to gather some intel about how the dev-community thinks about Meteor in 2019 with the result of having failed totally :laughing:

In my original dev.to article (posted at 25th Aug), I asked the following:

This somewhat of a short survey. Please comment first before you start researching the web, no matter if you love it, dropped it, came back to it or never heard of it.

I will not only wrap it up in a follow-up article but also will give you an overview about itā€™s journey (or better the last four years of it) and current state (the tech, the framework, the community, the company behind it).

The ā€œsurveyā€ will last one month and ends on 2019/09/25.

The article received below 100 views, one ā€œloveā€, two ā€œunicornsā€ and only one comment so far, stating

a dead framework

Now this is a hard one and I know, that the reasons of this poor perception has already been discussed a thousand times in this forum.

My intend is instead to push on the framework on the dev.to website with a well-structured and sexy article with seven (or 1000?) reasons, why Meteor is not dead and has never been.

I have already some basic structure in mind but I think that asking the community what would be the best to present could result in a much higher content quality.

////////////////////////////////////////////////////////////////////////////////////////
Edit
I forgot to mention, that my initial idea is first to go through seven (or all :-D) of the great milestones of the recent years, based on the Meteor blog articles to show, that the framework and MDG always pioneered the technologies. From there I want to show that there is since the beginning an active and welcoming community and then I want to show examples of where it is in production use.
////////////////////////////////////////////////////////////////////////////////////////

What do you guys think?

9 Likes
2

are you asking for examples of sites, mobile apps that are in production built on top of meteor? or reasons why people that use Meteor in 2019 choose to do so?

I dont know how a framework dies when there are still releases on a regular basis and an active community around it ā€¦ i mean we have Ben moving the framework forward each and every day. We have a group of people around the world making use of this framework, architectural style, and build tools and continue to support it through open source contributions and writing blog posts to inform people of the popular approaches to solving problems.

I use Meteor because it is easy to get something up and running fast (once you have ramped up on how to do things the Meteor way). And with a single code base you can target a browser, ios and android devices. That alone makes it something that has supreme utility in my mind. I had never deployed an apk file to an android device until i started using Meteor 4 months ago. And on top of all that the community is awesome. inviting and friendly and talkative :slight_smile: this and the Perl communities are the ones i am most proud of being a part of.

6 Likes
3

I never thought it to be dead but as discussed a lot here people outside this community have just not really the impression, that itā€™s alive either. This is basically my motivation to write the article.

What Iā€™m asking for is input on how the framework and the community will best be represented.

4

my experience using Meteor to date has started with me using Mongo and Blaze on the front end. But I am now moving to using React (and strongly considered using Vue as well) on the front end and exploring what it would mean to use Apollo (i.e. GraphQL as my back end). So that flexibility to grow as my needs or vision for my application changes is really great.

I am able to find packages on Atmopshere that fill my needs for routing, push notifications, accounts mgmt, roles mgmt, validation, google maps integrations, etc.

And if I have problems with what I am doing the documentation is great and the forum has lots of people to help you out. Its a complete solution IMO. And with a full time developer committed to moving the project forward we are assured at least incremental progress and long term support (where long can be debated, but its been five years to this point so iā€™d say that is a good start)

3 Likes
5

I would change the article title to, ā€œSeven Reasons Why Meteor is Loved by Developersā€ or something positive like that. :slight_smile:

13 Likes
6

Now weā€™re talking. I wouldnā€™t lead with the ā€œMeteor is deadā€ -assumption, even if the point is to prove otherwise.

7

Totally agree with that!

8

I cannot stress enough how much I appreciate the smooth upgrades and backwards compatibility of Meteor. This comes from someone who uses many other frameworks besides Meteor - which is unparalleled in this regard.

4 Likes
9

Meteor does feel very much like a cohesive unit ā€¦as opposed to a jumbled collection of components where its up to you to manage. So i agree with this comment. Alot of Node new comers really struggle managing their dependencies without headaches, Meteor helped make my transition to Node much easier in this respect and now 4 months in I am able to understand more and not get caught in the weeds as often. But like anything new it took time to get me to his point so Meteor helped make the first month or two easier to get through

5 Likes
10

I meant not only that Meteor does the job of assembling the foundations for your app to build upon, so you donā€™t have to research, install & stitch together 100+ libraries manually, but this:

With Meteor I donā€™t have to refactor my entire app, rewrite a thousand lines of mysterious config files or fiddle with package versions and incompatibility issues every time there is a new release or a new enticing feature I want to use.

For example, dynamic imports: just start using await import('my-module') and thatā€™s it.

5 Likes
11

I advocate meteor/apollo-server on the backend and a create-react-app for the frontend. You can use meteor-apollo-accounts to connect the two. Then you have a frontend that can connect to any backend (it has no idea about meteor).

1 Like
12

That doesnā€™t sound like a strong case for choosing Meteor :confused:

2 Likes
13

Well, the possibility to use only the parts of Meteor that you want is a strong selling point.

2 Likes
14

The Blaze is about to get to its clinical death, it is still breathing, but not that much. And understandably so, because they have promised SSR for years and it never came.

However, the Meteor itself is alive and kicking. I still believe it is the best framework to get your MVP fast and cheap.

On occasion I have to deal with Chrome ext, man, it is a torture to switch from reactive data to oldie goodie REST with its ā€œcallback hellā€.

And this is the last Meteor-based product we have shipped https://www.hundredgraphs.com

1 Like
15

We use Blaze in our chrome extensions too, its pretty awesome there, though it doesnā€™t require server side data

16

I think meteor is a great backend.

It is nice to have your client separate from your api, imo. Although meteor has some nice frontend features now too.

It can be easier to find react-related answers when youā€™re on a slightly more popular tool like CRA.

1 Like
17

Huh what? I just code Wekan with Meteor, and make new release nearly every day.


https://wekan.github.io

2 Likes
18

That ā€œis some programming language or web framework deadā€ is just insane.

What do you think, if someone builds a house, usually the plan is to get it finished, and then live in that house. Does it make any sense to all the time tear house down and change something that is below the house? Itā€™s really not a way to make any progress, when the plan is to add more features.

Or if someone builds a train, like ā€œRuby on Railsā€, compared to ā€œMeteor on Railsā€, is there really someone that really has time to rebuild all same functionality with some other web framework or programming language, when there is most likely millions of lines of code, like for example GitHub and other Ruby on Rails web framework users have?

What actually happens, if there is any bottlenect, that gets optimized. For example, if too much data is loaded to frontend, then infinite scroll is added.

Or, if there is too much frontend javascript, there there is REST API in Meteor app, and new lighter frontend uses it as backend.

When there is big Meteor app like Wekan, it did take many years to get it working and add enough features that it is usable. When some indexes are added to database, or some bug fixed like requesting less data from database, Wekan becomes faster.

Infinite scrolling, showing only visible cards, has made it possible to load huge big boards that have been imported from Trello.

There is many years of work done to fix bugs so that Wekan works in newest browsers. Sometimes new Chrome version broke scrolling card down.

All the Wekan code is very interconnected. When new feature is added to Wekan, it takes some time to fix all related bugs. And when there is so many huge features, how to really do the rewrite? Iā€™m just asking.

4 Likes
19

I think that question is the root cause of all the FUD that surrounds any open source technology. My hope is that people like yourself who have invested alot of time and effort into an existing application will continue to see Meteor as a technology that you donā€™t need to worry about that kind of stuff because of its continued support from MDG and an active community of developers willing to commit time and effort to its continued success.

And Meteor is still attracting new people that are excited about using it, the hype stage is over but its not dead. not even close.

2 Likes
20

Itā€™s just that I am not able to rewrite Wekan. Wekan is not originally designed by me. Wekan is result of huge amount of commits and pull requests from 136 contributors from all over the world. I donā€™t know how all those features work.

Making some single feature or fix can take many weeks or even 6 months. I still have not figured out how to code all those new features. I just try to read some code here and there in this labyrinth and sometimes when Iā€™m in flow I get it how to make it working.

I donā€™t even know what those React etc things are. Iā€™m still using Blaze very successfully. Some have proposed all various alternatives, Iā€™m just not familiar with them, and they did not send PRs to make required changes.

I figured out that even when default meteor is mostly x64 only, itā€™s possible to run generated bundle on all CPU architectures where Node.js and MongoDB exists.

Newest Meteor PRā€™s have progress for Node.js 12 etc.

I have used a lot of time to keep Wekan running on all these platforms.

I donā€™t know any other web framework so well that I would have any possibily to rewrite Wekan, with all parts of Wekan.

2 Likes