Ask HN: Is Meteor.js dead?

Could you describe the issues you've had with Phoenix and why you would have preferred something else? I am about to commit to Elixir and Phoenix for a project, perhaps a long-term one, and I would love to hear stories about how it doesn't work out.

So, I think that Elixir/Phoenix for a new project, if you're careful, is totally great.

Make sure you do happy-path integration tests first before screwing around with unit tests. Don't use Mongo, use Postgres + Ecto. Don't put changesets/business logic into controllers, call out to a dedicated business app. Don't use Mongo. Switch away from Brunch to Webpack early. Don't use Mongo. Don't do everything in maps, only use that at the edges of the web logic until you parse things into normal business objects. Don't use Mongo. Use a linter like Credo, customize the settings for your project early on. Don't use Mongo. Think about the "community standards" and make sure they actually apply to your problem.

Don't use Mongo.

No. I released Wekan v0.81 today: https://wekan.github.io https://github.com/wekan/wekan/releases

Currently using Meteor 1.6.0.1 with Node 8.9.3 and MongoDB 3.2.19. Planning to upgrade to newer version of Meteor, add new platforms, etc. Wekan is in use at companies that have thousands of users.

We are still using Meteor and haven't stopped. How else can you deploy a scalable reactive production (might I add 'huge') application on Web, Chromebook, Android and iPad with 99% reuse and 1% sweat. Instead of focusing on the nitty-gritty of node.

Everytime we look out there for replacement we have a hard time finding a better platform. When it comes along, we'll switch. But we are not there yet.

All the negativity around the platform has to do with bad communication by the platform developer (after all, they are developers not marketers).

We have been using Meteor at my company https://pitchly.net for a little over two years now with great success. I've used to to develop over half a dozen projects and have really pushed it to the limit. While some things are harder in Meteor, we were able to build and launch a product in a few months that would have otherwise taken most teams with multiple programmers a year or more. I'm not a member of the Meteor team, just a consumer, but I recently gave a talk on Meteor this week to introduce it to my community (http://slides.com/michaelcbrook/rapid-development-meteor) and I plan on teaching it at Des Moines' first code school (http://iowacodeschool.com).

As for advantages of Meteor over Node, I see many. Meteor is not this monolithic framework but rather a collection of sensible and well-intergrated tools. You don't need to mess around with Babel or Webpack or write a bunch of boilerplate config or code. You can start running out the gate and write the code for your app exactly and only where it needs to be written. No cumbersome boilerplate or maintaining a million different tools and checking compatibility between versions. It just works.

Now, I'll speak to why I think Meteor has lost some of its luster the last year or two, despite its advantages.

1) Meteor was way ahead of its time when it came out in 2012 - 6 years ago! Reactive programming wasn't really a thing then, but they found a narrow pathway between several different tools that would allow for rapid development, combining the capabilities of websockets, MongoDB, and did some novel things that made development seamless between all these different tools. But in more recent years, we're seeing more reactive frameworks rise up, like React and Vue, and in a way the rest of the world is only just now catching up. At the same time, we've got a phenomenon of framework fatigue going on, with developers just trying to catch up and understand this world of a million frameworks. It's very easy for newcomers to think Meteor and React are the same thing. But they're not. Meteor is a full-stack framework whereas React is only a frontend framework. React would only replace the Blaze portion of Meteor, and in fact many people do replace that part and use both together. But the fallacy continues.

2) Since the rise of React and GraphQL, Meteor Development Group has diversified. They are now behind the #1 GraphQL client for Node-based apps, Apollo. It happens to fit well with Meteor too. A common complaint of Meteor used to be that you couldn't use it with data stores other than MongoDB, but with GraphQL and Apollo, that is no longer the case. It's a welcome complement to the Meteor stack, however, it has its downsides. While it makes Meteor more flexible and highly compatible, it also makes it harder to use for newcomers. Working with Apollo and GraphQL can be a headache even for experienced developers, and if you're still only using MongoDB, you actually lose functionality with it, like automatic pub/sub. More confusion and less function for those who want to make apps quickly kinda kills it for newcomers who came to Meteor for its simplicity in the first place. And Meteor's simplicity was its main selling point. Not to say, though, that you can't still use Meteor without Apollo. You definitely still can, and in fact, I recommend newcomers do not use Apollo until they've bolstered their skills. It will just make everything more confusing. But all of this has muddied the water and undermined the simplicity that was once so lucrative to creating Meteor apps.

To conclude, Meteor is stronger than ever and is a very capable and powerful framework on which to build your product. The things that once made it sexy are not quite as new and shiny anymore, but I think it's because we're coming to this convergence of JavaScript frameworks and tools that are doing more of what Meteor has done over the last 6 years. At the same time, Meteor is trying to place themselves in the larger community and accommodate a wider ecosystem, sometimes at the cost of increasing complexity. Overall, though, I still believe Meteor is ahead of its time, and I have yet to find any other framework that does everything Meteor offers. And it is still more convenient for me to use Meteor than use a million independent tools. It's quite an impressive tool and is a pleasure to use.