Hacker News Reader

Comment by joshowens | Hacker News Reader

Why would the post be business focused? The guy that wrote it doesn't run "Meteor the business", he just loves the framework itself.

I am not even sure how a CMS got mentioned and compared here.

View on HN

Meteor has as a better chance than ever, ESPECIALLY if 90% of what you can do in Meteor you can do in "bare metal" NPM! Meteor doesn't have to provide that many "features" to win over the NPM crowd that it has struggled to acquire thus far. It's so damn complex to implement all this stuff that most developers need help doing it.

Meteor's problem thus far has been it makes it easy but provides no way to "drop down" to a lower level and configure things like you would on "bare metal" NPM!!!! Despite its easiness, this has scared away many developers from Meteor--especially the expert developers who would otherwise evangelize once they joined Meteor.

Therefore, Meteor just needs to provide a way to BOTH do things with sufficiently less boilerplate (like it's always done well), but also allow you to drop down to make lower level tweaks as you would on "bare metal" NPM. And perhaps even an intermediate tier in between for some features.

For example, Relay + GraphQL is great but there should be the "beginner's way to Relay."

So the killer feature in fact isn't a "feature" in the traditional sense, but rather a mechanism that only a full stack framework could provide. Being the only full stack framework that matters (and the only "reactive full stack framework" in existence), Meteor is well positioned to scoop up the entire NPM market if it plays its cards right!

Unless this comment is from SMM team at Meteor, WTF? What is NPM market :)? "Bare metal" npm? Name single sizable project that uses Meteor? You do realise that for 90% of enterprise projects it's a wrong tool. There is no usable universial/isomorphic option, you can't expose API for external consumption, if you have to consume services on the backend the only cool feature that Meteor has is gone. Not to mention long term risks of what will happen to the project when vc funding runs out.

My assumption is that Meteor is moving towards becoming like any other app you can build on NPM. That means Meteor will be the wrong tool anywhere NPM/node/javascript is the wrong tool. That's a fine agreed upon limitation.

Currently Meteor is a layer above NPM, which is why I'm referring to NPM as "bare metal" NPM--you clearly knew exactly what I meant. Meteor needs to become an adjacent resource to thrive.

So my prediction is if Meteor does this correctly they will no longer scare away expert developers and grow more than they ever have.

NPM is a package manager. Expert developers are not scared it's just Meteor is horrible solution to majority of use cases that they need to address. You need to read up on what Meteor actually is and what it's limitations are. Major ones have being outlined above: 1) No usable uinversial/isomorphic option so SEO is gone. 2) you can't expose API for external consumption 3) you are tied to only supported storage backends 4) if you are not talking directly to storage layer it's only cool feature is useless

None of the above is limitation of node (or has anything to do with npm package manager).

Quotes or not, this is the first time I've seen "bare metal" applied to npm. Hah.

yea I made up. But if you've been in any Meteor forum topics about NPM and support for modules etc, it would would make more sense. Meteor exists as a layer on top of NPM. It has done a lot of harm to its marketability. "Bare metal" in this case is a good thing, it's sought after deeper control which the Meteor community has awakened to realizing is a must.

"allow you to drop down to make lower level tweaks as you would on 'bare metal' NPM"

Meteor is entirely open-source and I've had no trouble diving into the lower levels to accomplish what I need to accomplish. Everything is split into reasonable packages and is relatively easy to traverse.

If anything, the Meteor team hasn't done a good enough job showing their true value (realtime via oplog->client updates, etc). Most of the current controversy stems from front-end developers jumping on the React bandwagon, splitting up the community as it stands. Not a big deal IMO.

this. and like most trends, it's shortsighted (and based upon the whims of contemporary front-end web dev fashion and not the needs of the meteor eco-system)

Reply on news.ycombinator.com