Thingking about Meteor 2.0 🤔

sacha · October 24, 2018, 7:47am

The Meteor team would love to know, too…

cloudspider · October 24, 2018, 8:55am

SSR is a big thing and Next + Nuxt developers understand that

I think that the momentum of NextJS is purely based on the fact that it provides a bit of abstraction over the SSR part, which is relatively complex compared to other things. The same goes for file structure. Though Meteor recommends it in the guide, its not as clear as the project already being in a structure like Next and Nuxt do.

The api as USP is not that valueable for 90% of the developers

Mostly a lack of knowledge about existing tools like Meteor’s DDP api or Apollo. People also underestimate building their own API, because REST (most used) seems deceptively easy at first. Its only further down a project’s process where people start to realize that their API implementation and standards are crap. By that time the decision to go ‘not meteor’ has already been taken and people will be reluctant to switch to any other platform, because of dependencies and lack of business value to do a rewrite. This ofcourse hurts Meteor, because Meteor should be that first choice when it comes to its powerfull DDP based API.

People still think that Meteor is an island

The bad experiences of expert beginners really hurts Meteor. Ofcourse there were some issues, but most of them are now completely obsilete. I hear this as the motivation for a lot of developers to not choose Meteor.

People forget that Meteor just runs node in the end. There should be no issue in switching. Tell that to those people that don’t understand it.

Lack of momentum and publications about the platform hurt Meteor

Momentum has been mentioned already. But here in the Netherlands for example, the community and meetup groups seem stale. Because of that, people are afraid that when they need help, there won’t be any or that Meteor will cease to exist soon (again lack of good news and company related stories in the Media)

I’m trying to reach out to the meetup.com Meteor group co-owners for Amsterdam, but unfortunatly no response yet. @benjamn any chance you can help me bring the Meteor Meetup group for Amsterdam back to life? Me and my company Passionate People organize a lot of Frontend meetups including Vue, Angular and React with speakers like Evan You (Vue creator) and @akryum (core developer and creator of the Meteor Vue integration packages). We are eager to help and spread the word here!

robfallows · October 24, 2018, 9:01am

Great post .

That link about expert beginners was awesome - thanks for sharing that.

I fully agree about momentum. There was an incredible commitment to Meteor back in the early days by MDG - does anyone remember the 1.0 release event? I would love to see even 20% of that come back again - and why not? Meteor still does many things so much better than other frameworks/platforms. That’s something we should continue to shout about.

waldgeist · October 24, 2018, 9:45am

I agree. I still love Meteor, but for me, one of its biggest downsides is that MDG started to neglect the mobile side of it. Plus the upgrade issues. Though many people insist they do not exist, at least for me I am having a lot of troubles each time I upgrade. Maybe it’s because I am focusing on mobile, maybe it’s because I am using SCSS which nearly always breaks to some extent. Dunno. This, combined with the neglect of mobile support, caused a lot of frustration and increased interest in other frameworks.

Still, I haven’t found a good alternative, so Meteor is probably the best out there. I tried NextJS, but it was more for pure frontend / web page development and did not come close to what I could do with Meteor. It’s been a while since I had a look at it, though, maybe this has changed in the meantime.

cloudspider · October 24, 2018, 9:56am

I found Nuxt to be quite good and more complete and better documented then Next, but still. Heavily web focussed. No api, no mobile support like Meteor has.

simonsimcity · October 25, 2018, 8:06am

Just my ideas and cents in here - and stories of things I saw in other parts of the programming world. It picks up quite something from the current roadmap, but defines some ideas for the long run:

That @cloudspider pointed out that people think that Meteor is an island in my opinion could and should be focussed on in the switch to an NPM package.

I still remember this from my PHP days when Symfony2 came out and revolutionized the community by embracing the idea of bundling your code into packages (and sharing it via composer) and make it all modular. Despite of being a complete rewrite of their earlier system, they also managed to get away from being a big monolithic project to being rather a community with tons of small projects, each fulfilling a small part but doing it perfect - and they took this idea (and a lot others) from the Linux eco-system.

In fact, they ended up with a structure that rather reminded of LEGO, which made the community very flexible and open. Other systems quickly started realizing the potential and kicked in and made use of these packages (https://symfony.com/projects).

I see that the community on JavaScript is quite different from the PHP world and also at a different state.
But seeing Meteor being quite monolithic and creating wrappers (and I do not mean those created to support Fibers), which even go beyond by getting up to a new major version having breaking changes but still keeping e.g. their old naming convention (yes, I’m talking about you mongo) is quite a blocker.

Please don’t misunderstand me here. I want to give out a huge thanks for those keeping the Meteor platform in such a good backwards-compatible state. At the same time I don’t know if this is the right way to go in the future because it adds a new stone of stumbling - and you can’t move as fast as the original package does. On the one side we agree that we should keep the packages updated, on the other side we don’t want the breaking changes they introduce, which brings a huge burden and slows down the development (in my opinion).

I know that the mongo package isn’t trivial - specially because we also need to make it work on the client-side (where only a subset is supported) - and this only is a sharing of my impression.

And this is exactly where the thought of Linux comes into play. Any distribution of Linux decides which program to update when and some setup-scripts just need an update when updating the packages.

I would LOVE if a version 2.0 of Meteor would:

Drops Fibers - which removes the necessity of creating a wrapper for a package to make it look “fit for the environment” (which in itself would qualify to call it a 2.0 from a developers perspective)
Have the courage to remain upstream with other packages and break when things should break (up for discussion and personal taste …)
Be more modular by publishing more npm packages, embrace the usage of them
Take a look at other commonly used libs and define interfaces. Let the main meteor-stack (Symfony called it the standard-distribution) use the previously used package but let the users build a bridge for other libraries which then easily could become the new standard by replacing the self-maintained package with it.

If some of you have worked with PHP and a Symfony project before, you don’t feel bound by anything but you have the impression that everything is so modular that you can just take out the package responsible for the task and write a bridge which makes your favorite package compatible with it.

Pretty long … but I hope you get the point

alawi · October 25, 2018, 9:18am

How does those changes improve the development experience? I’ve been using Meteor for some time now and I can’t see how those 4 items will add any value to the end user? say I’m new dev using Meteor how does those items improve my experience?

Also, where would the development resources come from? sounds like a huge refactoring effort and I’ve not seen any PR coming out of this thread aside from the Vue guide/tutorial (thanks Chris !), is this something that you or someone in this thread have the knowledge/time to help with? The project has been modernizing for some time now, but JS language and ecosystem changed radically in 2015 and this is a heavy and specialized code base to refactor. Yet huge progress has been made by decoupling the view layer, support ES6, dynamic imports, improving build time, serving modern bundles, and support for node modules.

Personally I’m happy with where Meteor is now, my minimum requirement is that it stays up to date with node LTS & mongo, Github issues resolved, new JS syntax supported and the build time doesn’t regress (or ideally improve), essentially Meteor LTS. Also little marketing is always good, it deserves it since there is still nothing in the ecosystem currently match what Meteor is offering as far as I can see, other frameworks seem to try challenge a piece of the stack leaving developers to glue and maintain the rest. Also, it’s worth noting that Meteor packaging system is really unique and it’s enabling architecture styles that currently seem unachievable (or at least without a lot of effort) in a typical webpack setup.

So to sum up, for Meteor 2.0 I vote for (1) An official Meteor LTS statement from MDG (to counter all those 2015 FUD posts and increase consumer trust/confidence) and (2) Tutorial/guide for Vue coupled with little marketing.

nparrott · October 25, 2018, 12:11pm

Support for Blaze, React and Angular is awesome. Blaze is so simple to use and lowers the barrier to entry for a lot of developers.

illustreets · October 25, 2018, 4:32pm

I’d +1 your post over and over if I could

hluz · October 26, 2018, 1:39am

+100!

On (2), and because this does rely on his work, maybe we could rekindle @akryum enthusiasm on Meteor Vue? Couldn’t be bad for Vue itself, could it?

larry · October 26, 2018, 3:26am

I want to be able to make an Apple Watch app

just kidding

Things that are bothering me today:

HTTP.call() is still using callbacks. You have to wrap it as a promise to use it with async / await.

Things that would make me go crazy in love:

I think Meteor was spot on with the cross-platform focus. So with that being said:

Right to repair is officially legal as of next week. Jailbreak a tesla and be the first platform to allow people to build tesla apps
Make it easy for people to build apps for Alexa and also IOT
Cross-platform deployment. Not having to use third party tools to deploy onto cloud hosting (seriously deployment kind of sucks still). Meteor deploy AWS. Meteor deploy digitalOcean. Meteor deploy Zeit. Let’s get it. I mean come on.
can you build clients / servers for Magic Leap apps?

michaelcbrook · October 28, 2018, 3:53am

KISS: Keep it simple, stupid. This is Meteor’s main advantage and what is severely lacking in most other frameworks. Other frameworks grow and get more complex. But if you can figure out a way to make Meteor more flexible but maintain its simplicity, you’re golden.

In my opinion, it feels like many developers that got distracted with those “shiny” things are now taking a second look at Meteor because of its simplicity. I have talked to several who have heard of Meteor and didn’t invest in it on the first go around, but they are interested in it now or are waiting for an impetus to use it. There is also a lack of understanding how simple it really is, but when you start describing all of the things Meteor does, people get excited and become very interested.

So, speaking as someone who has built products that have reached millions around the world, here is my free advice, if you REALLY want to see Meteor on top.

Treat Meteor as a first class citizen. It has not been one with Apollo. Meteor docs are always the last to get updated. If you want people to believe it’s the best, treat it like it’s the best.
Do something unique between Apollo and Meteor that only Meteor can do or is best at. Maybe combine the power of MiniMongo with Apollo so you can read/write to a GraphQL endpoint simply by declaring the GraphQL server in the Mongo constructor. I’m just spit balling, but point is: make it so Meteor is the best to work with while using Apollo. You will take advantage of your growing Apollo user base and “upsell” them to a tool that will make them even more productive. And make it simple enough to especially attract the early adopters who are looking to get started quickly versus those who have already chosen a framework.
Revamp your case studies and testimonials to include larger, more progressive companies and use cases. People don’t want to use Meteor because Kia used it for a small project once. They want to use it because million dollar companies have been built on it. (This point wasn’t meant to pitch you my business to include in said testimonials, but we happen to be one of those companies that has raised millions with a product completely built in Meteor. You guys should really be talking to us and people like us.)

I won’t dedicate an entire point to this, but better education on the value proposition of Meteor will also help. And this really comes down to a marketing problem. I only realized how powerful Meteor was after I started using it and went through some of the examples. But there are key snippets that are really worth emphasizing right out the gate: 1) isomorphic code between server and client (then explain how the line is blurred between backend and frontend - but reinforce the security aspect), 2) everything is real time, 3) easily convert to mobile apps. There are more but try to be concise and precise as much as possible. Remember, people are coming to you because you’re supposed to be simpler than the competitors.

Would be happy to talk more about this - DM me if you would like to talk directly.

marklynch · October 30, 2018, 12:34pm

I’m in total agreement with @alawi & @michaelcbrook but particularly with both of your first points. MDG gave us something great, which we’re still really happy with, but you can’t help feeling a little abandoned. A little bit of PR effort on their part would go a long way. Maybe a commitment to giving Meteor a few developer hours a day (be it Ben or Jesse) so things keep moving. All too often things go quiet for a couple of weeks.

cloudspider · October 30, 2018, 4:46pm

I must honoustly say that i’m not pleased with how MDG operates. If it does at all. All career links on the meteor.com site link to apollo. Now news has come out about the company for 2 years now. No clear roadmap besides a technical one on github. There is no mdg staff member actively making statements on the forums and the spcial media accounts are totally silent. Pull request about even the most trivial things like the guide take more then 2 weeks to even get a response… .

I’ve sent a mail to mdg in which I share my worries. This is a week ago and I have yet to receive a reply. I cant help but feeling that I’m trying to poke a dead horse here. What is going on here!

Is someone able to rech them and get a good statement from MDG? Something that takes away this feeling?

sabativi · October 30, 2018, 5:27pm

Yes, what you point out it the worst.
We all have a feeling that MDG is just ignoring meteor, even if benjamin did a great job recently ( 1.7 and 1.8 ), but we have no clue about where they are heading as a company.
Today, I would be happier to have a word that say “We will not contribute on meteor anymore” than nothing.
Because 2.0 version can also be the version maintained by the community only and not MDG.

gaurav7 · October 30, 2018, 5:59pm

Not having to think differently for Fibers would be big improvement in DX (developer experience). One may not realize it if the only Node.js code they write is in Meteor, but for those coming from non-Meteor Node.js background it’s quite a bumpy ride.

And perhaps even more importantly, the usage of other npm packages can be very problematic. See my previous comment.

A related change would be to convert the APIs to be promise based.

Removing the “unique” but incompatible feature/innovation that Fiber is, would likely make Meteor more appealing to the more “mainstream” Node.js developers. That would increase the chances of big contributions coming in from the community itself. See my earlier comment

I remember MDG making some big changes in Meteor’s governance a couple of years ago. But somehow the ratio of contributors to Github stars still seems pretty low in my subjective view. Practically it’s just one person doing development work on a framework that’s arguably larger than even Rails in terms of the feature surface area.

martineboh · October 30, 2018, 9:27pm

I have said this before that MDG knows Meteor has great potentials and easy to pickup than GraphQL when integrated properly. MDG is focusing more on Apollo right now - business reasons and totally ignored releasing or even promoting community efforts aim at making Meteor Great Again. The major issue with Meteor which is Scaling has been fixed with redis-oplog, yet it took MDG awhile to finally mention it in the Guide/Docs. GraphQL is great - yeah no doubt…it still doesn’t match Meteor realtime capability. MDG should have just carve a niche for itself by continuing serious development of Meteor along with other great community contributors. Nothing is wrong with Meteor; something is definitely wrong with MDG for abandoning something this great.

simonsimcity · November 1, 2018, 1:00pm

Well, most of the comments here are not (only) about major functionality for the end-user but also a complain about the lack of commitment and guidance by MDG.

What I’ve contributed to Meteor so far has always been accepted with open hands, so I shew out how other frameworks got more hackable and thereby attractive for a bigger community.

Having decoupled components gives the developers a chance to hack on them without feeling that there’s something heavy going on and they first would have to understand the full framework before being confident on doing small changes to the code-base.

As much as I agree with what you mentioned here (LTS, Vue support, marketing strategies), but to keep this project suitable for future projects we need someone driven by a vision. We’re talking about the next major version …

alawi · November 1, 2018, 2:12pm

I stand correct, both you and @gaurav7 echoed the importance of dropping fibre for future contribution and maintainability, so I guess it’s important.

Here is my attempt to consolidate a meaningful list from the discussion so far.

storyteller items from here.

Technology:

Get rid of fibers and convert all core APIs (including core packages) to be promise-based. (from here and here
Source maps support
Do something unique between Apollo and Meteor that only Meteor can do or is best at
More front-end agnostic, meaning no Minimongo, DDP
Hot module reloading and SSR
Improvements to listen internal events not just by hacking and wrapping some methods. (from here)

Support & Strategy

Official Meteor 2.0 LTS
Make Meteor first class citizen
Better communication especially form upper management

Documentation:

Vue Guide/Tutorial

There is a lot of good stuff in this thread, I think a good doc can be created from it. Also it’d be nice if we can have this somewhere that we can vote on.

doctorpangloss · November 2, 2018, 12:34am

There’s 1 full time developer on meteor/meteor from MDG. That’s not as bad as it seems, considering that React, from an organization that has maybe 10,000x the resources, only commits 4 full time developers.. It’s not like it was in the past, for sure.

I guess in light of the desired features, you should consider more carefully what it means if the project only had community contributions.