

Ask HN: Does Meteorjs really lock people in? (Brought up by Feathersjs) - peterhadlaw

I&#x27;ve been thinking about starting a project lately and I can&#x27;t decide which path to take. It&#x27;s going to be a relatively large project and I&#x27;m worried about exactly what the feathersjs website states:<p>(Direct copy pasta http:&#x2F;&#x2F;feathersjs.com&#x2F;):<p>-start-<p>Feathers vs Meteor
&quot;Once you go Meteor, you don&#x27;t go back. And not in a good way.&quot;<p>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&#x27;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.<p>From a feature standpoint Feathers is pretty similar to Meteor. You get real-time API&#x27;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.<p>-end-<p>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&#x27;re building your own stuff]), but the other components too.
======
pan_w
Full disclosure - I develop in Meteor and like it.

When 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](https://SaturnAPI.com)

~~~
ekryski
@pan_w I'm also another Feathers maintainer. I'm curious which part(s) or all
of fFeathers you are finding unfriendly or hard to understand. We're always
looking to improve our site, docs, examples so I'd love to hear your feedback.
If you haven't given it a spin, can I ask what the barrier is?

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!

------
ekryski
Full disclosure - also another Feathers maintainer here.

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.

------
daffl
Full disclosure - I am one of the Feathers developers.

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.

