Meteor Needs Long Term Support

meta
19

Your suggestion to structure the ‘journey-discussion’ via slices or however this shall be named is important. Ideally, each slice with some back-up or plan B option (which could be somewhat secured on specification/interface level only, also avoiding to divert effort but structure alternative discussions a bit better and be able to have some leveraged strategy).

Anticipation remains key, not for speculation but to be able to act on time (be able to read various signs/trends); in case one ‘slice’ is under fire, lost traction or support; a replacement initiative could be timely engaged. Anticipation and flexibility: if some ‘slice-architecture’ is not established a fire or crisis in one key area may drag the whole full stack down ('ships have still compartments to lock full flooding / draining).

Also, having only Apollo as efficient hosting is a nogo for most larger companies (lock-in risks are much to high; here there must be two redunant ‘slices’ companies / services at least if this should scale up and sustain, this competition is also requied to scale-up Apollo).

FYI: This input is based on 43 years IT experience - Meteor encounter some 3 years ago during regular IT evolution/evaluation tracking (so far mainly checked performance on deep lists via JSON MongoDB imports), browsers perf. vs. Angular /React and follow re-run on new versions. Yes 1.5 seems pretty good (no regression seen yet).

Then, Meteor was/is a great full stack I recommended to check for (architecture / process - UX cycle speed) learning or to start some pilots (large company).

Consider, each slice will get under fire periodically or will encounter the better solution and needs to be replaced (reason I put my years IT exp.). On the positive flip-side the decision may come from the Meteor community to replace (for a better solution) a slide. Dependencies (License) are also becoming more and more complex, obscure to manage (e.g. React).

Congratulations to core team and contributors , Hope you will stay engaged and motivated.

1 Like
20

Probably some typo Apollo vs Galaxy in my previous comment :wink:

21

I think the main thing holding them back is the amount of service. The minute you give somebody an account (even if for free) they assume you’re giving them unlimited customer service (which in tech probably ends up being more akin to free consulting). Maybe a $5/month account that’s enough for 10-15 people to beta test an app? And they can be explicit that support is limited-to-none-existent?

But I agree he $30/month is a good size hurdle for people.

22

I started using Meteor in 2015. I really enjoyed the fast learning curve, and the simple Blaze templating system. I was unhappy when I learned about Blaze being sidelined in favour of React and others. But since then, I have learned React, I have learned ES2015, I have learned unidirectional data flow patterns for the front end, I have adopted the frankly awesome mobx library as my state management tool, and I am delighted with how well all these things work together. I find Meteor is pushing me to learn great things, and am happy to be along for the ride - thanks Meteor!

7 Likes
23

I’ve never had difficulty with trusting the platform from the technical side. I did and still do dislike the “you should jump ship, because we should jump ship”. But you know I was part of that infamous thread, so I’ll just stop right here.

I can imagine. From a tool easy for everyone, became a platform for the experienced. Your tool is a commercial one, but oh boy, the open source community around Meteor has become very unstable. I think somewhere around last year, most packages just collapsed. But, I think this is a sum of all things.

Totally multiplied the sum.

I still enjoy Meteor. It is still my first tool of choice and I just like its ease of use and batteries included methodology. In honesty, I do no longer use it for developing large audiences, but it is amazingly flexible for integration things. Currently I use Meteor for game development; and since Meteor, I’ve not touched Rails at all (which used to be my comfort zone).

The only thing that would impact my choice to use Meteor is when they cut out Blaze entirely or it wouldn’t be available for install anymore. However, I doubt that would happen. However, no matter who supports it, IBM or anyone - with the departure of awesome people in certain areas, its days of glory are over for old sports like me.

PS.
Still love Toys.

24

This. But to get those developers to show up to use the hobby level, I think somebody is going to have to do (bleh) more marketing. Tons of effort is going into the development of this platform, but good software is never enough. No matter how good your product is, if you can’t build name recognition and hype in the development community, you’re going to fizzle and disappear.

Forgive my ignorance, but is there somebody in MDG whose job this is?

25

There had been many. I think MDG is the kind of company that doesn’t like to hype things up.

26

Okay, I have a big response to this:

  1. To be honest, I don’t really see the need for these major marketing overhauls you’re proposing. While I’m not entirely sure what MDG’s bottom line looks like, I think the primary concern is making great software and keeping a framework as complex and wide-ranging as Meteor up with the accelerated evolution of web development technologies. Galaxy is a fantastic tool, and Meteor does a great job of promoting it to both new and veteran Meteor users. As far as Meteor Toys are concerned, I’ve never heard of them in 2+ years of Meteor development, so that might indicate the root of your problem @msavin.

  2. As for breaking things down into separate components, this has been happening already. I’ve been using Meteor for years, and I’ve never had to touch Blaze. Pub/sub, methods, and DDP have all worked the same for years as well, they’ve been perfectly backwards compatible in my experience. Atmosphere packages are slowly going away, it’s inevitable. Migrating Meteor away from a monolithic ecosystem of its own, and integrating it with the rest of the web-dev world, such as npm, only makes Meteor more appealing to the broader web-dev community, not the other way around. One day, I think Meteor won’t even need it’s own package system, anymore.

  3. True, we always need to put more effort in keeping Meteor dependencies up with the times, such as MongoDB and Node, as well as refactoring core Meteor functionality to be fully supportive of ES6. I definitely agree with @robfallows that if we can ditch Fibers for async/await then it should be a high priority. This goes into the broader sentiment that whatever can be either separated from the core software, or refactored to a solution with less or no external dependencies to make Meteor less bloated, the better and more attractive it will be.

  4. I disagree the with notion that Apollo is Meteor’s direct competitor. Meteor is far easier to use, does more out of the box, and has a larger community from what I’ve seen. If you’re worried about Meteor not appealing to newbies, then Apollo and writing a GraphQL server would be even less appealing to them. Until Meteor is less monolithic and is implementing support for GraphQL and other key Apollo features, I don’t think they should be compared too much. True, some key Meteor community members like Uri Goldshtein and Arunoda have moved on to “the hot new things” like Apollo and Next.js but that doesn’t mean Meteor is any less relevant or is in direct competition with these frameworks.

1 Like
27

Why long term support if backwards compatibility is there? You’re asking for ben to spend less time on project.

1 Like
28

I mostly agree with what you’re saying, except for point #1. I’ve met far too many devs that haven’t even heard of Meteor — and that’s a shame. That said, perhaps it’s not MDG’s concern to promote it to more devs, but rather, the community as a whole.

1 Like
29

I just checked out the Google Trends on Meteor, and see for yourselves: the trend drops on November 2015, the same time as the infamous Blaze thread, and it never recovers.

56%20PM
56%20PM2800×2578 445 KB

1 Like
30

That is very unfortunate.

31

Not surprising given that there is almost zero marketing and whoever searches Meteor got hunted by the maby FUD articles generated in 2015.

However, the framework is mature and way better then what it was in 2015. I also really enjoy the Meteor community and learned a lot from the folks on this forum, more like a kinship community. But yeah I do think it should get more recognition/marketing. Maybe we need a community app that showcase what got built on top of Meteor.

2 Likes
32

That was one of the selling points indeed. I was browsing this forum really often. But it became very quiet here.

Regarding the “infamous Blaze thread”. I just read the first paragraph again:

Continuing the discussion from Next steps on Blaze and the view layer:

Then checking his stats (3 years later!): https://forums.meteor.com/u/gschmidt

              Geoff          Sashko
Joined:       Feb 27, '15    Feb 24, '15
Last Post:    Feb 22, '16    May 1,  '18 
Seen          May 10, '16    Jul 12, '18

STATS
visited:         86 days       807 days
read time:        7 hours      240 hours

topics viewd:    51          5 900
posts read:     638         35 100
topics created:   6             71 
posts created:   22          3 000

He hasn’t been here for over 2 years. Only three months after the post mentioned above, right in the rural times of Meteor. He decided not to come back to the forums and listen to or get involved with the community.

Sashko, still noted as “MDG Staff” on the forum, did a great job though. He listened and got involved. He has a lot of great topics and replies on this forum. Unfortunately, he decided to move on, and leave Meteor as well. Stats in the second column for comparison with Geoff.

Yes, the framework is better than it was in 2015. But on the other hand, it doesn’t have the velocity that other frameworks are getting. It doesn’t move forward.

Most of my publications are killed, due to fiber spikes. “Every” branch switch, requires a ctrl + c > npm install > meteor cycle. Hot module reloading is not available. Babel is giving headaches since MDG decided to depend on beta releases. Babel is giving headaches, by not having full control over .babelrc. Testing is giving headaches by having meteor/owner:package namespacing.

The community has moved on. Arunoda moved on, Sashko moved on, Geoff came by, and never looked back. The forums are dead silent.

I think if Meteor want’s to relive, it needs be something like create-react-app. Have the option to eject and be left with a normal node + npm project. But also; go back to the roots. Be opinionated. Don’t try to make everyone happy. Because that’s simply unmaintainable.

“Meteor has Blaze and Sockets”, became “Meteor + Vue || React || Angular || … , and can use Apollo || react-meteor-data || globals”. And we can use npm, but it doesn’t really work as nice as meteor packages.

1 Like
33

For us Meteor is doing great technically, if I learnt anything from the JS ecosystem is to ignore the hype and keep and eye on GitHub and the customers.

Anyway people have different priorities, I will get back to my work :slight_smile:

2 Likes
34

I would love to do more. I have in work a starter project that will showcase socialize packages, sadly I don’t have much time to put into it as I would like (another app that could be pushed forward is Vulcan). I’m currently helping in restarting Meteor meetups in Prague, but we are forced to re-brand as fullstack meetups.
On that note, from what we heard there has been general decrease of need for fullstack developers as things have gotten too complicated for one person to be truly fullstack and hence companies are looking for specialists. I think this might have a bit to do with the downturn as many developers have specialized and focused in one area and hence they don’t have need for Meteor in general.

That said I do agree that a marketing push and development or major update of a Meteor feature outside of the build tool could be helpful.

Maybe it is time to start talking about Meteor 2?

1 Like
35

I actually prefer the focus to be on the build tool, package system, bundling etc. Also bejamin did a great work in modernizing the core code base and adding new features. Maybe MDG can rename the minimal build to Apollo Build so it fits with the rest of their Apollo ecosystem.

36

Rephrasing Freddie, “Too much pivot will kill you”. On that day, Meteor has left free niche and very low-hanging fruit occupied by overpriced and monstrous Sencha/ExtJS.

37

I like this idea. A rebuild of Meteor. Taking out the good stuff like the build system and some other things. I personally still enjoy the pub/sub system and minimongo

38

I love Meteor and stick to it because it’s really all I know. I started an app six years ago with a CS-background but not much knowledge on Node.js or JS app development. That app is now in production, has good revenue, has thousands of customers (including most top tier companies you’ve heard of), handles crazy volatile client loads going from 25 to up to ~5000 users in a just few seconds, and we spend about $750 on Galaxy a month. And we still use Blaze, still use Meteor 1.3-era app structure, and run on Meteor 1.5.x (working on upgrading, but our app moves slowly).

We would definitely support any LTS in any way, as Meteor is our livelihood, but I think they’ve done a fantastic job over the years and all the releases have always been welcome features. Indeed, the backwards compatibility has been pretty great so far.

For the bootstrapper… Meteor rules. Thank you Meteor and the team.

16 Likes