Ask HN: Does Meteorjs really lock people in? (Brought up by Feathersjs)
(Direct copy pasta http://feathersjs.com/):
-start-
Feathers vs Meteor "Once you go Meteor, you don't go back. And not in a good way."
Meteor has amassed a large community and a lot of venture backed funding. Our biggest complaint is that because of this funding, there is some serious lock in. Meteor has it's own package system, how you use npm modules can be inconsistent and it is a large codebase. There is also the risk that when investors start pushing for a return on their investment, it could negatively impact the community.
From a feature standpoint Feathers is pretty similar to Meteor. You get real-time API's from both. However, we let you use the defacto npm for managing dependencies, we let you choose whether you want to use Webpack, Gulp, Grunt, or any other tool for managing assets, and Feathers is completely client agnostic without any additional overhead. Everything is open, flexible and pluggable. You use only what you need.
-end-
I actually have no clue about the feathersjs project or an opinion on them. I do however like the point that they are addressing. Specifically the npm modules (or lack thereof in Meteor [when you're building your own stuff]), but the other components too.
5 comments
[ 3.7 ms ] story [ 26.0 ms ] threadWhen I'm choosing to be involved with something, I always look to the people I'll have to engage with. It's very much a date.
For a programming framework, it would be the dev community around it. First I see if there is a community forming, that's a really good indicator if the technology is good and if it's here to stay. Then I start building a small app with the technology and interacting with people in the community online and offline. If the technology is meeting my needs and the community members are pleasant and helpful then I'll commit.
Not being able to use NPM modules directly is kind of a bummer, but they can be ported to Meteor Packages.
Looking through Feathers, it does not seem very beginner friendly and there is a lot of configurations needed. I believe one of the reason Meteor gained a lot of traction because it was extremely beginner friendly. As I developed more Meteor apps I have also been able to utilize advance features as well. There was something for everyone.
With regard to the funding, I think that is a good thing. Big name investors won't invest in something they don't think will be at least 10x better than what currently exist. If something is that much better there will definitely be a way to make money without compromising the product. Google is a great example. They display ads based on your search history. If I'm looking to buy some shoes, I wouldn't mind ads about shoe promotions. I believe the lead investor is A16Z and Marc Andressen cofounded Netscape, so I have confidence in them.
Competition is great none the less, so I hope Feathers pressures Meteor to constantly be better.
Here is an example project I'm working on if you need some insight to Meteor's capabilities. It's MATLAB in the cloud, so you could share Fiddles and build APIs that need computational capabilities: https://SaturnAPI.com
We are planning on putting out a more comprehensive walkthrough of building a full typical app (more than just a toy Todo example) so hopefully that will help!
I think part of it is a philosophy difference. If you want a one-stop solution you will very likely always end up more locked in and might be happy with Meteor. But, as cool and advanced as the technology is, eventually investors do want a return on their investment and it is really hard to do that without compromising the identity of an open source project. With so much cash in the bank it is also easy to become over-ambitious instead of focussing on doing one thing well. That is tricky in a field that is changing as quickly as web development. The more you add to the project and the more you try to do yourself the harder it will be to react to the ever-changing landscape and you can see that with the challenges of the Meteor package system.
We wanted to explore an approach that doesn't hide complexity by adding more and then putting some generators and configuration files in front of it to be able to say "look it's super easy". The Node ecosystem thrives on tiny modules that do one thing well and Feathers - as a very small extension to Express - does exactly that: Providing a pattern that allows you to create REST and real-time APIs without trying to tell you how to do everything else.
To add to @daffl's comment...
Inevitably there is always some "lock-in" when you choose a technology and honestly we're trolling Meteor a tiny bit, but I our aim with Feathers is to mitigate lock-in as much as possible by few design choices:
1) What daffl already said about small composable/reusable modules
2) npm module support. You get to leverage all the awesome work others have done (without any additional overhead like porting modules or shimming them).
3) existing Express/Connect middleware just works.
4) a very small codebase over top of another small modular codebase (express, socket.io). The theory being less code, means less to go wrong, which saves devs time writing code and debugging.
Ultimately, you do need to decide whether you want the Meteor sort of approach where it's more of a kitchen sink that gives you all the tools you need but makes it hard to step outside the secure sandbox, or whether you want something that is a bit more flexible. Since, in my experience, all the projects I have worked on inevitably end up with something custom that the framework du jour doesn't handle I prefer more flexibility and small composable modules.
We've tried hard to see if we can strike the balance between offering just enough without getting too much in the way. If you think we're on the right track or not we'd love to hear your feedback.