Meteor is not dead. In fact, it's quite all right

#1

A few weeks ago, we did some research among software companies. The process as we know is quite complex, but the inquiry was very simple. We want to find someone who knows Meteor. Period. In response, we got dozens of emails, but my attention was mainly caught by one of them. The one in which author wrote that - “Meteor is dead”. According to him, this technology died in 2015, when it experienced its apogee, and then there is nothing.

We wrote article about it and published it on our website:
We also published it in some online magazines for devs and the response was huge.
We’ve received hundreds of questions about what has changed in Meteor in last two years.

Developers told us that they left this technology few years ago and had no opportunity to get back.
Of course not all of them, but most of those who wrote back to us. So what happened a few years ago? Why people dropped this amazing technology? Some of them want to go back.

16 Likes
#2

It all started when Meteor developers got an impression that Meteorjs is not owning the main packages (router, frontend, backend). The awesome simplicity of Meteorjs went complicated by dying major packages and by adopting diverse style of coding (Vue, React, Angular…). Learning and unlearning process. And here I am not talking about learning to code but learning the new APIs (learning syntax) and then unlearn it again.
Today, I can more understand what happened and I think that Meteorjs probably made good choices so far. Instead of limiting themselves to Blaze they opened up and let the users choose.
But ,in my opinion, the user got the feeling that Meteorjs is unable to maintain the main crucial libraries that are needed to develop full stack application. Developer from Kadira left, iron router died, news about flow router was emerging…some users speaks React, other Blaze and some Vue and then some who like Polymer will ask why not Polymer? Some will use Iron router, other will use flow router and some will say both are dying use React router…
It became sooo messy world… The resources split into Vue, Angular, React, Blaze, Iron Router, Flow Router React Router… so what is left for Meteorjs?
Meteorjs identity is lost due to this. Instead of solving Javascript fatigue problem, Meteorjs started to seem unable to deal with it. Lazy loading was amazing then React way reined when the application is like 80% React components.
If Meteorjs left Blaze or is not developing Blaze anymore so why it is still considered the default front end? and until when? Why not Vue instead?
In the future, I imagine Meteorjs to have a full solution that developers can trust and rely on (quality, maintainability, scalability ) .
Meteorjs “has over 13100 packages” that is really great but how many are well maintained and really useable?

9 Likes
#3

Thank you for sharing your point of view. You have right.
I also hoper Meteor will be solution that you can trust.

#4

I think it is less than 2-5%. A lot of packages are only very simple wrappers around some NPM libraries. But we have some diamonds, like Simple Schema or Universe packages from Vazco guys. It looks exactly the same like in other environments. A lot of some shitty plugins - and only a few of shiny stars.

That is great! You have a choice and it is really nice to have a lot of options to choose from. Thanks to that, Meteor is friendly for many developers. As a newbie in our world - you could be welcome with open hands.

Remember, that not everyone is using React - so they do not have to install various 3rd party plugins . You have that functionality as part of official Meteor products and you are sure that everything is working well

I am using Meteor since 2015. Personally I think there is no better solution for building SPA app than using Meteor. You have so many great opportunities today - don’t complain, use it! :muscle:

4 Likes
#5

When we were building one of our start-up - our main objective was to quickly transfer data between devices and a lot of powerful features to help in conducting a presentations / conferences.
You need to choose technology to problem, that you need to solve. Without Meteor it would not happened. When we started, we needed to app very fast. We needed to validate our tool and problem that we want to solve.
Meteor give us many features, just out of the box so development vas extremely fast.
We could test our solution and after few pivots we had a fully functional application.
I would never change this technology, in this project (and many more), for anything else.

8 Likes
#6

I believe Meteor could use some PR to set things straight. It changed a lot and more developers should use instead of re-inventing the wheel.

It’s not going to be perfect for every app, as any tool. I believe, showing how open it is now, the control we have and the things that it makes so much easier is key. There always going to projects/devs that will want to create the build script themselves, but for the rest, Meteor could be a great technology to develop on.

4 Likes
#7

We believe Meteor will become a build-tool essentially, a powerful server-side renderer, and it will work alongside Apollo to expose it’s API. Things change, ambitious ideas get squashed when faced with large teams and scalability.

The futuristic stack in our vision is:

  • Typescript
  • Meteor
  • MongoDB & Grapher & RedisOplog
  • Apollo
  • React or Vue as frontend

This approach is so versatile, it’s incredible.

The only things missing are that proper integration from Apollo and Meteor reactivity, problem which I’m actively solving now.

8 Likes
#8

One important thing is now we can build a very good SEO website with Meteor.

  • It has server side rendering
  • It has dynamic import (work well with react components) to make the page load time very good.
2 Likes
#9

Did you disable websockets ? :slight_smile:

#10

I don’t. I tested with google search console and it looks pretty good.

#11

My business has been developing reactive Meteor webapps with Blaze and Iron Router since April 2015, but with MySQL instead of MongoDB.

The only thing that has changed since 2015 is that Meteor has gotten a whole lot better thanks to the work of the MDG and lots of other contributors. Meteor 1.6.1 is the best version yet!

The only problem we have is that Meteor users aren’t sharing their success stories widely enough.

17 Likes
#12

Opss, the chosen title sounded to me like a news headline from a propagandist TV channel during cold war days… Anyway, I believe, Meteor deserves much more popularity in SW Engineering community, especially when I see how newer and maybe less mature JS frameworks/libraries like Vue.js has rapidly became accepted and popular.

#13

Do you really have this kind of thoughts? :smiley:

#14

Don’t get me wrong, I forgot the finish the sentence with “at first sight” :flushed::relaxed:

1 Like
#15

We’ve been happily building internal business apps for clients with Meteor for ~3 years now. It’s an excellent fit for this space, but doesn’t result in anything to attach a splashy announcement to.

As a side note, we recently started a project where we were looking at a standard MERN stack (we don’t need reactivity, and thought it might be simpler to keep things stripped down). But by the time you set that up and pull in a bunch of things you get for free with Meteor, it really didn’t seem worth the effort.

Not that the tool chain was the only reason, but I’ve been hearing a lot of “Meteor is just a build tool” floating around, and that really shouldn’t be underestimated. Tool chains are hard, and Meteor is absolutely excellent there.

15 Likes
#16

Almost the same stack as Vulcan. We call it the GRAM stack :slight_smile: (GraphQL, React, Apollo, Meteor)

Why do you need Grapher if you use Apollo/GraphQL though? Are you still using Meteor’s own datalayer in parallel?

4 Likes
#17

This is in my view exactly the sweet-spot for Meteor / Blaze / MongoDB! New internal business apps need to be built very quickly, sometimes a very narrow functional spread. No need for SEO. No need for flashy UI. Flexible DB to evolve as required after initial rollout without having to bring out the DBAs. The simpler and to the point the better. No need to scale to consumer level (how many users in total in most companies? Even at Google or Apple scale, how many would be using a specific business app simultaneously?)
:smile:

6 Likes
#18

Meteorjs is perfect for me right now. I can get all the help I need for my Blaze/mdl (meteor forum) and Vue/Vuetify (meteor forum, vuejs forum and vuetify discord channel) apps and everything works great :slight_smile:

2 Likes
#19

Meteor’s data layer is no longer used.

Grapher is composed of 3 modules

  • Linking
  • Query (Hypernova / Publish Composite Bridge)
  • Exposure (The client-server bridge (publication and methods))

Because of Apollo, the 3rd module Exposure is no longer needed. However, where Grapher shines is in it’s way to modularise links, how fast it performs fetching nested links, and the security offered by named queries or global queries.

Let’s take the example, where you want, all posts, all comments, and the users that commented. With GraphQL, after you setup the resolvers, you would simply bombard the database with requests 1 for posts , length(posts) for comments, lenght(allComments) for users.

When you’re dealing with a remote database, the time to do that increases dramatically (you’ll be doing something along 100 db requests). While Grapher can do this in 3 requests using the Hypernova technology. My initial tests with a local database, showed improvements up to 40x, which is crazy.

And your resolvers can look like this:

{
   Post: {
       comments: (root, args, context) {
            if (root.comments) return root.comments;
            return Posts.getLink(root._id, 'comments').fetch(); // optional
       }
   }
}

Now, here’s the interesting part, we’ve checked that if we already have comments than we just return them from the parent, (because resolver takes precedence over field)

I’ve build a quick function that transforms the ATS into a Grapher Query, meaning:

posts(root, args, context, ast) {
   return Posts.createQuery(toGrapherQuery(ast)).fetch()
}

toGrapherQuery transforms the AST into the default format that Grapher accepts with keys and 1s. This is not exposed yet to the public, I plan on releasing a full Reactive Apollo Implementation that works hand-in-hand with Meteor/Grapher/Redis-Oplog, and in next release have Reactive Graphs (like we have with Grapher leveraging publishComposite). I have already blueprints stored and technical specs, it’s just a matter of time.

Another problem that this solves is that you don’t get from the db ALL THE FIELDS, you get only the fields you need, lowering bandwidth and ultimately increasing performance.

Apollo is still behind in terms of security, meaning that the amount of code to restrict some fields or links is just too much code to write. I plan on helping on that part as well, to use the technologies innovated in Grapher for that.

Hope this was helpful, cheers!

6 Likes
#20

Oh so it’s similar to Dataloader. Nice, I didn’t know it could handle that too.

2 Likes