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.
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.
As a Director of Market Research, I’d like to know the quantitative specifics of how Meteor is perceived among the broad node.js developer community, to find out:
• What strengths of Meteor are largely unknown?
• What strengths of Meteor would have the most impact on developer desire to use Meteor, if they were more broadly known?
@filipenevola, if I can assist - no charge - please DM me.
So, we published something that’s sort of similar to what you’re describing.
Opinionated WordPress style core, with plugin architecture for private/proprietary custom workflows.
Ecmascript/module bundling; yarn rollup for publishing NPM packages
Express.js based HTTP server @asymmetrik/node-fhir-server-core
Agnostic on the front end, defaults to React, supports Vue, Blaze, Svelte, etc.
Code splitting via npdev:React-Loadable
Mongo/MiniMongo
Meteor Cookbook Redux?
So, I get what you’re describing. It’s the release track functionality, and the build tools, and build pipelines, and device architecture support, and the isomorphic code types. You can build semantic web apps, microservices, DApp infrastructure, blockchains, all sorts of stuff with that kind of base architecture.
To your point though… yes, we need to differentiate Meteor-the-build-tool from Meteor-the-tech-stack.
And, honestly, nowadays I think of Meteor as the XCode of Javascript/Node. As more of a compiler/build tool than a tech stack.
And if people want to promote the notion of Meteor being able to publish different tech stacks, I’d encourage them to register those release tracks or custom stacks over at StackShare. It’s a tool built with the notion of documenting tech stacks, and giving people an idea of what the stack is for and the trade offs of one architecture from the next. Which has been a hangup within the Meteor community in the past; but which maybe some new tools and rebranding could provide a work around for.
Thank you for this and I think today our main weakness is the lack of knowledge about what Meteor does, then I agree with you in the part that we need to document and expose better many parts of Meteor.
If you think about the proposed roadmap it has many items for documentation updates and new technologies as first-class citizens and a big part of the work is in documenting it.
Another important aspect is to have the major integrations up-to-date and that is already in progress (NodeJS, Cordova, MongoDB).
@vikr00001 I would be glad to have your insights here. I believe Meteor users have to worry about fewer pieces than other JS-based projects, like we don’t need to worry (most of the time) about how to build code, how to connect client and server, how to install the correct Node version, etc. and also we have many integrations already built-in or easy to add via packages. What I want to see in the next months are Meteor apps using up-to-date technologies and also companies success cases.
To wrap up, a good way to keep this conversation moving forward is to incorporate into the roadmap parts that are still missing there as actionable items
