[Video] Where is Meteor.js Heading?

announce
1

We did a special edition hybrid Crater Podcast/Spacedojo Show to talk about the future of Meteor.js. Big thanks to Chris Pena and @deanius for taking the time to talk on the show!

Video - https://www.youtube.com/watch?v=llbmLZH370w

Audio - http://podcast.crater.io/episode-115-where-is-meteor-js-heading

Given the recent roadmap updates, I’m not sure I feel any differently than I expressed in the show.

5 Likes
2

I listened to the podcast and really enjoyed it. Thank you for your contribution, efforts, and time!

3 Likes
3

Thanks for listening to it :smiley:

2 Likes
4

I have to say, it was painful to watch – a whole hour! (thank goodness I could play it on my iphone on the side while I work or I wouldn’t have gone through it).

As an engineer, I am used to structured conversations, this seemed more like rambling on anything that comes along in the conversation. I definitely like more the format of Transmissions where the conversation agenda is organized in advance and adhered to by the moderator. At some point the guest on the top left was left to his devices for a long time, completely ignored :slight_smile:

My notes:

  1. Seemed like the guest at the bottom was much more aware of what is happening with Meteor (and had a lot more value to add), sadly more so than the moderator.
  2. I was very happy bottom guest mentioned redis-oplog by @diaconutheodor and saw in it a path forward for the community (which the moderator ignored, likely due to personal predisposition and / or ignorance of recent updates in Meteor)
  3. The moderator ignored some of the great work done by the community, for example, @vlasky has been using SQL in production for a while now including livequery (and we even tried it and worked great, we decided against SQL for reasons solely related to SQL)
  4. Good points mentioned: hard to get PR’s in, reduced build time (acknowledged as a core strength of Meteor), seems like single developer working on Meteor repo (fairly disputed by @sashko, however, and it seems hiring is on the rise for Meteor, and ignores great community work)
  5. Since the moderator is decidedly against Meteor ignoring good arguments from the guests, not sure of the critical value of this video.
  6. Finally, the topic is ‘Where is Meteor.js Heading?’ … what’s the answer? Seems the video is more of a critique of the platform, which is fine in itself as a topic, but the title implied something else.

Given the low number of likes which speak for themselves, maybe I am too frank :slight_smile:

Can’t wait for the next Transmission!

9 Likes
5

Well, all educated and reasonably founded opinions are, imho, worth listening even if they don’t foresee a good future for the framework, so I think @joshowens has done a good job being frank about his opinion regardless of how many likes he gets( And I have nothing to do with him or his projects)

However you are right in that the structure of the conversation is too erratic. I get it, it is suposed to be an informal chat, but to me, it seems like there’s no control on what to talk about (so the order is mixed) and not everyone has knowledge of what is being talked about (why not letting them have a look before instead of typing during the talk?)

And after saying that, I think that the video is interesting but just too long for the amount of information given about the future of meteor. The actual sentences talking about that can be summarized in 2 minutes (for those who don’t want to listent to it completely):

  • Chris Pena : Only using it for prototyping and quick projects -> No banking or serious apps in Meteor

  • @joshowens : Meteor is loosing “traction” and it’s evolving too slow for the amount of time that has passed since 1.3. This could be mainly because mdg has priorized rebuild times instead of npm/apollo which is/should be the long term bet of the company. Real time is not enough to keep meteor cool forever, and devs should embrace the npm ecosystem as soon as possible.

  • @deanius : Meteor community has proposed some interesting packages/libs to solve some important missing parts, and if they become reliable and battle tested, they could give Meteor more opportunities to become trendy in the future, since it is the best framework to get easy realtime data fetched.

  • There are different alternatives to Meteor like featherjs and next.js but all of them agree in that every project is different and while Meteor could work on some, many frameworks could fit the requirements more easily (This is like the global summary and I think is basic common sense).

And after this summary (excuse me if it’s not exactly 100% what you meant) I must say I agree and disagree with all of them to some sort of degree:

  • It is true that Meteor outshines for quick prototyping and not so much for biggers apps because of many things (like not having HMR or being stuck to Mongo until Apollo becomes deadly simple to integrate) but I still thing is a very solid framework for large projects(even for banking), and it will become much more interesting once we get 1.4.3 I’m sure :slight_smile:

  • Besides embracing npm which is something quite obvious, and that I also would recommend, I still think that mdg’s movements have been right in terms of development. I just think that one or two more @benjamn 's :laughing: would have made Meteor evolve much faster and thus the traction would have been kept. It is true that maybe realtime is not necessary for all the apps, but it opens a lot of opportunities for future developments in any place, so I think staying and waiting for full Apollo integration and npm decoupling is worth the wait.

  • Meteor community has indeed provided very interesting projects during the last couple of months, and I really hope that projects like experimental code splitting from @klaussner , redis-oplog from @diaconutheodor, meteor-vue from @akryum, etc end being part of the core/official guide since the benefits of those contributitions are enough to make Meteor recover a lot of the “frustrated” developers back to the community.

8 Likes
6

Too many business misdirections by MDG has prevented it from maintaining trust with it’s customers - us. Meteor is an EXCELLENT prototyping tool though, but that makes it disposable and you can’t charge premium hosting sevice for disposal business model.

1 Like
7

I listened to the podcast and agree that it lacks structure but I think that Josh is pretty openly disappointed in the current Meteor state. A lot of that disappointment seems to be an interpretation of the current MDG priorities as an abandonment of Meteor.

I really appreciated the perspective of the 3 participants because they work day-to-day selling technologies to their customers so they have some battle scars.

I would like to discuss another interpretation of the MDG priorities.

I am relatively new to web development so I am sorry if I do not have all of the background… but I will wade in anyway :blush:.

I believe that we are seeing a classic “strategy pivot” on the part of meteor.

History

My interpretation of the background:

  • Meteor jumped ahead of the “javascript everywhere” phenomenon when they started.
  • One framework available on both the server and the client is great!
  • They ran with reactivity everywhere.
  • Made it work on mobile devices via Cordova.

MDG made some compromises to move fast:

  • Stuck with an old version of node for quite a while (too much work to move it ahead I assume).
  • Chose Mongo as the DB that could satisfy the largest number of demands.

MDG made some bets on things that thought might gain traction:

  • Went with some in house solutions where others were not available at the start: e.g. Tracker and DDP.
  • Invented Atmosphere and their packaging system.

The Pivot

As of 2016, I believe that MDG made a strategy pivot to embrace the rest of the JS community more fully and to support their users with the largest applications. What has this implied:

  • Fully embrace React (angular too)
  • Tear into the guts of Meteor to enable easier integration with fast moving JS technologies. e.g. make node easier to upgrade, make npm packages work.
  • Address the Mongo only database problem by creating Apollo that can be integrated with Meteor core but has appeal beyond Meteor’s shores. Kind of the best of both worlds and embraces the JS community.

I believe they were fully aware that they were going to be sidetracked for a while rearchitecting the guts and decided to take that risk.

Interpretation

From the outside this might look like slow progress or abandonment. When you are making changes to the guts, fundamentally, nothing new is visible (e.g. paddling in place). I am going to guess that enabling node upgrades took a fair amount of work.

I think these moves are fully aligned with the Meteor vision:

971×412 18.5 KB

You could argue that early on “Integrate with technologies you already use” was not well supported. But the moves they are making now clearly look like most of their investments are going into this category. Look at the roadmap update. They are doing the next appropriate steps:

  • Node v6. Integrate technologies.
  • page improvements, maybe this means webpack? Integrate technologies.
  • full transition to NPM, figure out how to replace Atmosphere. Integrate technologies.
  • integration sugar for Apollo. Integrate technologies.

I believe that we are in for some more paddling in place feature updates to really light up the best technologies that the JS community has to offer.

What am I doing?

I am still on Blaze. It works fine and I have not encountered perf issues for my application. I anticipate that I will switch to Vue and I would not be surprised if Meteor made Vue a 1st class framework because of Vue’s performance advantages (even compared to react) after V2.

I am anticipating a server side penalty for the DB reactivity, but I will invest there when the problem starts to hurt and I will move to Apollo.

So for now, I am R-E-L-A-X-E-D. I believe that MDG will stay on their vision and will pivot the project where it needs to be for me and the rest of their community.

17 Likes
8

@brucejo thanks for the great summary, I’m glad that you see it in the same way we do - that we are putting in a lot of work into Meteor in the direction that we have heard from top users and important customers.

@joshowens I’m curious what your goals are. I understand the need for constructive feedback and more involvement from a variety of people to define the future of Meteor. Do you think content of this form will improve the community or the state of the project?

Edit: I messaged Josh to talk privately so hopefully I’ll learn from that.

5 Likes
9

Same boat as you. Still on Blaze, would like to switch to Vue. I’m even thinking of breaking a portion of my application off and rewriting it in Vue. But for this portion, I don’t know if I’ll use GraphQL, Apollo, or Meteor. I’d like to continue with with Meteor, but support for Vue is anemic at the moment.

1 Like
10

but support for Vue is anemic at the moment.

Not really, you just need two packages.

meteor-vue-component to build .vue component files and get hot reload

vue-meteor-tracker for using Tracker data inside Vue components reactively. There are some other packages that do Tracker integration as well.

Vue support is totally viable, I’ve been using it for awhile now.

2 Likes
11

Thanks @efrancis, do you need to wrap vue up in blaze templates using the libs you listed? If you respond, could you please respond in a thread I created on this topic here? Init: Meteor & Blaze + VueJS

Thanks!