Thought I’d throw some spaghetti at the wall, and see what sticks.This is meant in the spirit of dreaming, and brainstorming, rather than some kind of demands. I mentioned elsewhere the idea of releasing a Meteor 2.0 to announce some things that people may not know about Meteor, to dispel some of the left over branding from 1.0.
Here’s what I would suggest trying to promote:
- Rather than full-stack opinionated, parts are opinionated by default, ejectable at scale.
- Zero-Config Ecmascript/module bundling - ecmascript modules through reify, and modern and legacy bundles out of the box, use babel - and completely extensible.
- With tree-shaking (hopefully soon!)
- maybe hooks for HMR? (Ben makes a lot of good points about how flaky HMR is - that people ignore… it would seem people want it, and maybe some hooks could be implemented. That might be needed for platforms like React Native anyway?)
- Built in development environment, and Express.js based server - easy dev-ops.
- Agnostic on the front end - support for React, Vue, Blaze, Svelte- all first class.
- Easy Server Side Rendering
- Perfect code splitting, easy config. (Document npdev:React-Loadable, npdev:Svelte-Loadable, and whatever Blaze/Vue use.)
- Apollo Ready (with SSR)
- Mongo/MiniMongo available! These are still awesome tools!
- Make MiniMongo ejectable - also allow use outside of Meteor, migrate to NPM - I’d love to use that even outside of Meteor.
- Update the documentation and guides to mention all of the above, especially describe meteor-> mainModules, and meteor->nodeModules package.json items, which doesn’t seem to be well documented anywhere.
The idea behind most of that is to get across that Meteor as it is today is not the tightly vertically integrated, highly opinionated thing it used to be. It’s a full solution for building apps, almost zero config to get started, and relatively open ended about how to get there.
Additional items to consider before 2.0:
- Shipping a default configuration for ‘create-meteor-app’ which has Apollo installed and configured for Mongo, without DDP.
- Additional build target support, if no implementation. Specifically, hooks/build targets for React Native, NativeScript (Svelte-Native and Vue Native) and Service Workers/Meteor Offline.
- Some of these may require either browser polyfills like (react-native-meteor-polyfills), or changes to core to remove the need for them.
- Also add some extensibility to the package.json mainModules section, for Cordova, RN, NS, and maybe WS.
- Think about making Meteor a more general front-end tool - why not build front end bundles for other backend products - like Rails - all that would be needed is an implemented module server for perfect code splitting/reify. Meteor group doesn’t need to develop that, just document it, and let someone in the Rails community create a server module. Meteor would become a super easy to set up front end development service, configurable as a proxy to whatever backend. Doable?
In a lot of the above, these things are already possible, we just don’t have great visibility in to the internals through documentation. I think a splashy 2.0 release, after a big documentation push might be all that’s needed to communicate the value of Meteor a sit exists today, rather than the defunct proposals from 5 years ago.