Is Meteor Dying? State of the Meteor Ecosystem

[shock]

When part of our support teams moved to Manilla, there was too much red in reports.
So they just banned red and started to use orange instead.
They have much friendly looking reports after compared with ours (we had still red for failin) even difference was like 20% better in our team.
So that is also way how to solve things, change quantification metrics and colors

[aldeed]

I guess I’ll comment briefly since this may be referring to some of my packages.

1. I have never thought of Meteor as some monolithic thing that can live or die. It is a build tool and a few useful core packages, that’s it. It sort of became it’s own thing with the addition of the package repo, but even that will just morph into isomorphic npm rather than die. If you are deciding between Node and Go, then yes, make sure Node is not dying. But if Meteor “dies” (which it really can’t do anyway since it is open source), 90% of your code base remains the same and you swap out a few packages. Even with the “partial death” of Blaze, if you still like it, you can still use it. Just fork it and keep it up yourself.
2. Meteor/MDG, the company, can of course live or die, and I hope they figure out the right model to thrive, but that does not necessarily affect the ability of the Meteor codebase and packages to live.
3. A package with few recent releases is not necessarily abandoned. In many cases they are just matured. Some of my package repos have hundreds of issues and I can no longer keep up, but many of the issues are only questions, the packages have stable releases that are used in production, and they are not abandoned. I cannot speak for all package maintainers, but personally I will not abandon a package entirely without clearly stating that at the top of the readme. And if I do that, it is probably because someone else has taken up the torch with a better package that does the same thing.
4. The best thing you can do for package maintainers is help them by answering issues and submitting PRs. Probably half of the issues in the autoform repo are questions that all of you autoform experts could answer for me.

[cliffers]

Why dont we have a worldwide Meteor Package Day with a focus on improving and upgrading exisiting packages. Even non package authors could get involved and help contribute to thier favourite most used packages.

Every developer is always so busy with work and side projects, a event like this could help buy out some time and revisit some of those todos.

[vlasky]

Meteor MySQL support is rapidly improving!

Since April this year, my business has been using Ben Green’s numtel:mysql package in several production systems handling real-time data, performing reactive updates. We have contributed fixes and enhancements to this package and we are about to announce a few more.

MySQL 5.7 was recently released and one of its most exciting additions is support for a JSON datatype. This will make it much easier to give Meteor MySQL support for popular packages like Accounts (accounts-base).

We see a bright future for enterprise apps that leverage the strengths of Meteor and MySQL.

[vonwao]

Things change, everything is evolving. When Meteor started, React wasn’t around, ES6 modules didn’t exist, GraphQL didn’t exist, etc. Meteor has to evolve too. If not it would just become an outdated framework like so many others.

I think Meteor is making the smart choices, even if they are unpopular. Nobody wants things to change, everyone is basically lazy and doesn’t want to have to rewrite or refactor their apps. But that’s not how things work in reality. Everything is changing and evolving.

I would prefer if we stop discussing so much, instead roll up our sleeves and find new things we can contribute to the evolving ecosystem.

[sam]

Sam Hatoum kind of passed Velocity back to Meteor, then built his own testing tools. He went from being a Meteor-only solution to a broader solution.

To the point of the OP, the reason behind this decision was primarily because we are a startup that is low on resources and could no longer deal with the support requests. By pulling out of the core of the problem, we left a gap that the is now being filled with version 1.3. Happy days.

I’d argue that building a testing tool that appeals to wider community is the best way to make sure that the tool is actually good.

This is spot on. Rather than focus our efforts on things that are done exceptionally well elsewhere, like Jasmine and Mocha in their raw form, we’ve instead picked on the very specific problem of end-to-end and acceptance testing which is often done badly.

As an active maintainer, my personal mindset is now this:

1. Build packages primarily for us at Xolv.io
2. Make the packages we find them useful public
3. Deprecate packages we no longer use so others can clone
4. Maintain only one ambitious package

Today we are using Meteor because it still solves problems for us that other frameworks don’t. If tomorrow we no longer use Meteor, I think we’ll still apply the same mindset for making OSS packages.

FWIW, I personally don’t think Meteor is dying, especially since we’re able to grow our app at speed without hitting any limits (though the build times are at a red flag right now). When we start to hit limits that slow us down, or that other technologies out there are better, maybe it’s time to jump ship. Right now, we’re in ship shape!

[aadams]

I’d argue that building a testing tool that appeals to wider community is the best way to make sure that the tool is actually good.

If I’m way off, please correct me:

If the goal is to not just build, but incorporate tech that’s tech that’s so good the community votes “yes” by using it, inversely why is Meteor not incorporating webpack (a tool the wider community has picked as good at what it does) into MeteorNext, but instead reinventing portions of webpack?

[goatic]

why is Meteor not incorporating webpack (a tool the wider community has picked as good at what it does) into MeteorNext, but instead reinventing portions of webpack?

I’m pretty sure @benjamn answered this in his post regarding Meteor 1.3, where it’s boiled down to (on the Github page):

…the difficulty of getting Browserify or Webpack to traverse the dependency graph of a Meteor app outweighed the complexity of implementing that logic within the existing Meteor build process…

[benjamn]

Another serious problem with Webpack is that it assumes we’re going to be using CommonJS forever. Two of Webpack’s shiniest features, code splitting (require.ensure) and hot module reloading (module.hot) depend on CommonJS-isms (require and module) that will and should cease to exist in a fully ES2015 world of import and export, and Webpack has no plan to adapt those techniques to work with a purely native module system.

The more popular Webpack gets, the more it contributes to the entrenchment of CommonJS. Webpack is very much a tool for today, when what we really need is a tool that embraces the future of the language. I gave a talk recently about why it’s so important that we move on from CommonJS to a truly native module system (import and export), in case you’re not yet sold on that vision of the future.

By the same logic, adopting Webpack as a core concept in Meteor would hold the platform back in the long term—and probably in the short term, too, if you read that post of mine.

When Meteor finds a way to support code splitting and hot module reloading, those features will be designed to work with import and export syntax, without any dependencies on CommonJS. Unfortunately, Webpack has no insight to contribute to that still-open design problem. If you have ideas, we’d love to hear them!

[Babak]

Totally agree. I feel people just want faster reloads and Webpack is by and large seen as a pathway for that. I’ve not used it much other than to play around with it. Another thing folks might care about is, like you said, packages and workflow. That is very much about now and not tomorrow. Would it be useful without too much effort to support the needs of now as well?

[aadams]

I’m pretty sure @benjamn answered this in his post regarding Meteor 1.3, where it’s boiled down to (on the Github page):

benjamn:
…the difficulty of getting Browserify or Webpack to traverse the dependency graph of a Meteor app outweighed the complexity of implementing that logic within the existing Meteor build process…

So the answer is, it’s just too hard? Is the build system systemically flawed in Meteor?

So now MDG is going to shy away from takeing on the hard stuff, even when it comes to VERY important tech like Webpack (Read: code-splitting)? How disappointing.

Another serious problem with Webpack is that it assumes we’re going to be using CommonJS forever

So which is it, is it too hard or is Webpack flawed?

If Webpack is not right long term, then what else is used by the community achieves code-splitting and incorporates the ES2015 world of import and export?

I’m weary of taking on proprietary Meteor tech now that I know MDG will drop it like it’s hot when the fancy changes. I want something more widely accepted by the community, thereby insulating us somewhat from a few guy’s ideas about what’s best for us.

[ryanswapp]

So which is it, is it too hard or is Webpack flawed?

I think the real answer is that they are trying to be backwards compatible. If they switch to Webpack then everyone’s apps will instantly break and they’ll have to get rid of all their global variables and start the import/export dance (which may not be a bad thing) among other things. In addition, I assume there are some other major complexities that would make it near impossible to integrate Webpack into the existing build system without heavy modifications. If you’re going to have to rewrite a tool to fit your ecosystem then you might as well start from scratch so you can build exactly what you need. I’d love it if you could drop Webpack right into an existing Meteor app but it doesn’t appear to be a possibility.

[hwillson]

I want something more widely accepted by the community, thereby insulating us somewhat from a few guy’s ideas about what’s best for us.

Yes - just look at how badly having one guy decide what’s best for us has worked out … with Linux.

[aadams]

just look at how badly having one guy decide what’s best for us has worked out

Exactly, just look at how they’re dropping Blaze, Tracker, Publications, Atmosphere and on and on they go…

[benjamn]

So the answer is, it’s just too hard? Is the build system systemically flawed in Meteor?

It’s a question of technical debt. Any system we might build on top of Webpack would be much, much more complicated (and take longer to ship!) than something designed with Meteor’s build system and developer experience in mind. And it would be worse, in addition to being harder to maintain, because design decisions that we could otherwise make freely would be constrained by what Webpack can do.

We’re not shying away from anything. We’ve made a careful decision against using a tool (Webpack) that simply isn’t suitable for our purposes. Read my post (again) if you need further explanation, but don’t insult my intelligence or technical ability with your imagined theories about why we’ve made these decisions.

I’m weary of taking on proprietary Meteor tech now that I know MDG will drop it like it’s hot when the fancy changes. I want something more widely accepted by the community, thereby insulating us somewhat from a few guy’s ideas about what’s best for us.

What have we dropped? If you read the linked post in which I clearly explain why we’re not using Webpack, you’ll see that a big part of the reason we can’t “just use Webpack” is that we have a hard commitment to backwards compatibility. I wish we could ignore whole parts of the system we’ve built over the years, like the various Webpack integrations do, but that’s not an option for us.

Webpack happens to be popular right now among developers who think CommonJS is great, but that doesn’t mean it’s the right tool for the long term. Webpack is also a “few [people]'s ideas about what’s best for us.” That’s all software is, ultimately. I hope the feature set Meteor 1.3 provides will win you over.

I’m spending all my working energy (note: not quite all my energy, especially this time of year) steering Meteor back towards standards and best practices. A big part of that is embracing the npm package ecosystem, and migrating Meteor packages from their current format to the npm format, even though that means giving up some features that npm does not support. As Meteor projects become more and more like plain Node projects, tools like Webpack may become more useful, and I hope Meteor can get out of your way if you choose to use such a tool.

I also hope and expect that tools like Rollup will mature to the point of making Webpack and CommonJS obsolete, because that’s a future that takes full advantage of JavaScript standards, and a future I’m really excited about.

[goatic]

Thank you for taking the time to clear this up. Lets call it a day and have a merry christmas?

[aadams]

We’re not shying away from anything

Indeed MDG is shying away from tackling the hard innovation its been know for. MDG could do a Manhattan Project style Blaze reboot, taking lessons learned from React and the other great UI packages out there – and surpassing them all.

Building on that momentum, they could then focus on a Tracker reboot/update and add code splitting for Blaze+Meteor.

And it would be worse, in addition to being harder to maintain, because design decisions that we could otherwise make freely would be constrained by what Webpack can do.

Why is this logic not applied to the situation of Blaze over React? By building a BlazeNext you would never be constrained by what others cannot do. Blaze done right, and under MDG direct control could be something more than React.

Read my post (again) if you need further explanation

I’ll re-read your post again, thanks.

What have we dropped?

MDG is or will be depreciating the following due to the decision to use React and GraphQL: Blaze, Tracker, Publications, Atmosphere and on and on it goes.

Webpack happens to be popular right now among developers who think CommonJS is great, but that doesn’t mean it’s the right tool …

Gawd I love these quotes, again why doesn’t MDG apply this same logic to Blaze over React? Is React the “right” tool? This seem subjective. And ripping out a lot of tech and replacing it with React supported tech seems drastic to me.

Webpack is also a “few [people]'s ideas about what’s best for us.”

It’s clear that Webpack is what the community has voted “yes” to by using it in greater and greater numbers.

We’ve been listening to what MDG has been saying about the reasons for replacing Blaze with React. One point that’s been hammered home by MDG is that React is the “chosen” tech because it’s being embraced by the community. It seem self serving to apply this logic only where it’s convenient.

I also hope and expect that tools like Rollup will mature to the point of making Webpack and CommonJS obsolete, because that’s a future that takes full advantage of JavaScript standards, and a future I’m really excited about.

Many want code-splitting in Meteor. If MDG has said Webpack doesn’t fit the bill due to technical issues, that’s a fine decision. But pull something else from the community instead of building in-house I say, because at this point it’s hard to trust in house solutions.

---

Also, to be clear, there’s been speculation by myself and others as to the motivations behind some of MDG’s recent technical decisions.

The reasons for this speculation in my opinion is two fold:

• On the surface the recent decisions by MDG seem to not hold water and,

• There has been a lack of communication from MDG proper on the rational behind the recent decisions.

Questions I have are as follows:

• Why doesn’t MDG proper state plainly why they’re making the technical decisions they’ve made as of late to the Meteor developer community?

• Why is MDG choosing React over Blaze and thereby gutting a large portion of existing Meteor tech?

• Is MDG adopting FB tech a strategy to position Meteor for Enterprise adoption, and thereby promoting Galaxy and MDG Support Services?

Many of us have made huge (relative) investments in Meteor tech. I for one have built a company on Meteor tech. I’m very likely a future Galaxy customer too.

The decisions made by the small group at MDG directly affect the Meteor development community and small business people.

Cheers

[Babak]

I have to agree and disagree. @benjamn is saying ES6 has a syntax for that and we should use it. He is right. Webpack and CommonJS dealt with JavaScript short comings. Like Coffeescript did.

React is a front end framework not a standard. If anything, there is a stronger case for not using Webpack moving forward than using React over Blaze. Meteor wants to open itself allowing users to use whatever framework they want. They are simply opinionated or recommend React. What’s wrong with this? We’re free to use Backbone or Riot if we want.

If Meteor didn’t make this change, it would die. This is the way forward. My only complaint that there should be a reactive relational option. I feel that in the long run, it’s the data that’s important. Front ends come and go because both market and technology demand that it change.

Hot code reload and fast compile times should be improved. No debate there. This is a huge issue.

I totally agree about FB. I don’t like their license. Simple as that. I don’t want to use their stack ESPECIALLY in relation to data. I can always throw away a React front end. Back end? Hell nah G.

[trusktr]

npm package registry is weird because they count downloads through parent dependencies, and they count every time it is installed. So if your app uses package X that is depended by 10 modules in your app directly, it can be counted 10 times every time you run npm install.

I like this better. Can you change Atmosphere to that? Or, perhaps have two numbers: one direct app installs, and the other indirect installs (when a dependency for example).

[trusktr]

Would it be useful without too much effort to support the needs of now as well?

Meteor 1.3’s modules packages support now more than ever. Package authors can now write build plugins (as they always have) that will compile to a format compatible with ES2015 modules (for example, you could install some package, let’s pretend it’s called someone:png-modules, that lets you import foo from './foo.png' right in your JavaScript and you’ll get a data URL, or a file handle, etc, depending on what the package does). This is comparable to Webpack’s loaders.