Why you should work with Meteor in 2020

community
1
7 Likes
2

There has been a real surge in activity for the last few months :slight_smile:

3

Just tweeted to spread the word :slight_smile:

4

Good article! However, focusing so much on the death of meteor seems very counter productive. It is a trend for so many articles about meteor to focus several paragraphs on trying to explain away the “death”, but in so doing it sounds very desperate and brigs a lot of focus to that point for new devs who might not even know it has been considered dead by anyone.

It is a bit like repeatedly saying “trust me” and “I am NOT LYING! Really, I am not lying right now, it is the truth. Not lying this time.” It sounds very unconvincing, and would drive me away as a new dev who then starts googling the death of meteor and other negative articles.

I would just focus on the growing community and active development, pointing to a solid development history and that it has been continually developed for years, dropping death altogether.

7 Likes
5

Exactly my thoughts.

1 Like
6

Then in the last paragraph he said:
My company KeenEthics is an early adopter of the Meteor framework and a well-established JavaScript company in general. In case you have a promising project in mind, feel free to request an estimate .
:stuck_out_tongue_winking_eye: with no disclaim

7

Imho Meteor.methods have been very much underrated
There is no easier and faster way to integrate backend and client. I mean, look at that beauty!

Server

Meteor.methods({ 
  someFunction(param) {
    // do something
  }
})

Client

Meteor.call("someFunction", params)

KABOOM!

Compare that to any other JS framework out there. You need something like Axios on client, configure express server routes on the backend, json parsing, deal with server responses, etc. etc. Lots of overhead.

And not to mention that it’s almost as easy to expose your methods as an API for the rest of the world, for example using meteor-rest.

On the other side, imho Publications have been very much overrated. Yes it’s cool but also dangerous tech with lots of performance implications. Sure way to make your app slow and unscalable is to use publications for everything, or publish lots of data.

Third, not sharing the enthusiasm for the Meteor docs. They are ok, but also quite outdated. The more powerful stuff isn’t mentioned in the docs so you need to dive into the code (which is actually well documentation). And the docs have lots of references to packages that haven’t seen updates in years, but are still mentioned as best practices.

But it’s good to see that popularity is going up again and people talk about Meteor again.
The future looks bright!

3 Likes
8

I agree that the Guide and API documentation could use an update.

I think Tiny would be well served to add a full time staff member to maintain the Meteor and Galaxy documentation and serve as the QA lead (so one person to start with, then assuming Meteor is profitable and doing well split the role into a two man job). Over 12 to 18 months they could improve test coverage and the documentation to a point where Meteor would be easier to use and more reliable. And those are huge selling points.

I will be updating the Views section of the Guide to add in a page for Svelte, but that is just adding more to the pile. not improving what we have

2 Likes