TLDR; Meteor is still fun, NPM wrapped packages are bad. Instead of
meteor add obsolete:wrap-everything you can use mainstream NPM packages with Meteor, today. Think about it! Look at meteor-webpack-react.
Is Meteor package system perceived as a lock-in by the NodeJS community and slowing down its adoption as data synchronization layer? Probably yes.
EDIT: Changed the title, added a real world example and a video.*An intro video of Meteor + Webpack by Adam Brodzinski*
Meteor is cool, isn't it?
meteor add whatever and you get a login system, Facebook / Twitter oauth, .. everything work but then the frustration comes.
I want latest Bootstrap. Should I use
obsolete:boostrap ? Ooh Meteor integrates Blaze, Angular, React,.. should I use
Version 0.0.12? WTF? I just want the latest mainstream release! You stop interacting with nodejs community, because you have Meteor wrapped packages, but you also get big headaches.
When Meteor started its package manager was useful, but now, after Babel ES2015 (and beyond), Webpack, React hot loader and NPM 3 browser friendly, it seems obvious that a package manager used mostly to wrap npm packages isn't useful.
Meteor 1.2 will have ecmascript ..
Yes, but it is wrapped :( And it still won't support ES2015 import/export until, maybe, Meteor 1.3 .
If you don't want to depend on obsolete packages, freezed by others, there is an alternative approch.
Say goodbye to:
- global variables to share functions or code among your files
- obsolete mainstream packages
- packages that require code on client and on the server even if you just need it on one side
- Issues with loading code order
How a de-meteorized Meteor world look like?
Clone meteor-webpack-react and start to play with some packages like the other guys or girls.
$ npm install rrule --save
It will download and save it in the
package.json and require it on the server or on the client, where you need it.
import RRule from "rrule"; let rule = new RRule(...);
.jsx files aren't automatically loaded. The files
app/main_server.js are the start points for the respective environments. That's it.
You can still use the Meteor specific packages, a la Meteor way, look inside
meteor_core but you don't have to, and they'll expose the global variables as you are used to.
You can also install private local packages with npm link and take advantage of other "normal" features for NPM users. The isolated meteor community could publish in future Meteor-specific packages on NPM, just adding the tag
meteor-packages, the same of what is happening in the React community with
react-components which is only a tag over NPM.
Real World example: an app I'm developing
It's a Meteor/React app and I'm using as deps:
babel, the original, instead of Meteor packages
grigio:babel. Advantage: I can have latest Babel ES2015 compiler just changing a number in
universe:modulesfor ES2015 import/export, opss no.. I already have it out-of-the-box.
material-uiinstead of wrapped
rruleinstead of the outdated
aramk:rrule, and I can also choose to load it where I need it at application level (client, server or both).
react-headroominstead of ..nothing because there isn't a working wrapped version for Meteor
- I use React Hot Loader for client-side changes which is much faster than Meteor reloads.
Angry, shocked, sad? Here some comments on Crater.io and get a pill.
- Blue pill, You'll download Meteor 1.2 and You'll continue to build as usual NPM wrapped packages for AngularJS (https://atmospherejs.com/?q=angular-) and ReactJS (https://atmospherejs.com/?q=react-) in Meteor. Get the pill, and you'll wake up tomorrow as you never read this post.
- Red pill, You'll start to explore a new world with more than 179k mainstream NPM packages (Meteor just 7k packages), explicit load order of the code, where Meteor will be mainly a data synchronization layer between client and server.