Meteor has the proposal to be able to write the same code that is used in the backend and frontend, but when I look at its organization, I think that the ideal would be if meteor was separate folders backend and frontend, with npm packages like mini mongo client and many others, letting the frontend side choosing between which bundler to use and which frontend technology to choose, but being able to use the same code by sharing a folder by symbolic link or npm package path reference
an example of what shows me that meteor would be even better if it were a series of npm packages is when I try to configure babel
the advantage i see in Meteor (frontend + backend) is nice use / integration with DDP.
Does any other frontend / backends support DDP besides Meteor? if so, then splitting might make sense.
Having Meteor just on backend without anyone using DDP wouldn’t make much sense. Also what would be the advantage of Meteor on client without Meteor backend?
For me, separating Meteor as npm and between frontend and backend projects would allow us to customize projects more efficiently. I had a lot of headache to integrate Meteor with Svelte and ESLint, besides, I see that Meteor has a specific version of NodeJS, separating projects and packages would make us also have this control
the simpleddp package is interesting, but how to start the server in backend only mode? And it would be interesting if the mini mongo client was an npm package and so on
The authentication token is in localStorage, I don’t know if this is much discussed, but it would be interesting if the backend was separate and could also implement HTTP endpoints and finally put the authentication token in a secure cookie
If everything was split between npm packages, we could test them with Jest for example
it could also make the Meteor.js project simpler by taking integration tasks out of a project as a whole
but needs lots of code to run as you know it in Meteor client style
That’s the spirit, I think if meteor was like this backend you showed in the video, plus a folder with the frontend using any bundler like webpack, vite or parcel and one more shared folder to be used by both the backend and the frontend
There are many great frameworks as you suggest. What will be the benefit to the community? I couldn’t understand what will differentiate Meteor from them.
Meteor is great because it’s a full stack. You do not need to maintain two code bases. You could but you don’t need it. You will get the optimistic UI for free. State management is incredibly easy. When async/await migration is completed as planned the future is bright for Meteor.
Making Meteor more customizable: frontend agnostic, node version agnostic, being able to customize frontend build
You do not need to maintain two code bases
That’s great, although how could we keep one single codebase working with react native for example? The ideia is to have many npm kind like we have in react native for now but still being able to share a common folder between a frontend project, a react native project and a webserver project, maybe with symbolic links
I had a lot of headache to integrate Meteor with Svelte and ESLint
That’s also an example of a big problem I’m trying to solve here
I don’t quite understand why you’re suggesting changing Meteor to match lots of other frameworks out there? The whole point about Meteor’s original design was to be fullstack. That being said, over the years it has been redeveloped to work with a wide range of frontend systems. Blaze, React, Angular, Vue and Svelte all work. Some work better than others, but it would be impossible for the Meteor team to cater for absolutely every frontend framework available.
I appreciate that this tends to make Meteor come across as an all-or-nothing proposition, but that is its greatest strength. The more modular you make software, the harder it becomes to maintain, because the number of module combinations increases exponentially.
However, if you search these forums you can find examples of people’s projects that do only use Meteor as a backend, especially for mobile apps, so it is possible.
I’m suggesting splitting Meteor.js into npm packages to allow other stacks that were evolving to integrate with Meteor.js
Meteor works fine with React, but if we would like to use Next.js it would be difficult again, so I would suggest having many npm packages so the integration would be possible and graceful
I understand. I guess the question I would ask is if you’ve decided to use Nextjs for the frontend of a project, why not choose a backend framework that already plays nicely with it? What is it about Meteor that makes you want to choose it as the backend over other frameworks, even though it doesn’t currently work well (or at all) with Nextjs?
Mainly the fact of being able to work with the backend and frontend together
But I believe that the best answer to your question is the fact that I could start a project without knowing the ideal direction and I believe that the credibility of Meteor.js can fall due to the fact that it compiles the frontend and backend together (ideally frontend and backend should be compiled separately in my opinion)
Today I took a look at the monorepo approach, in my opinion it would be the ideal future for Meteor
I would also like to see something along these lines.
It doesn’t mean it can’t have the same out-of-box experience as it currently has. It definitely would be possible.
But the benefit I can see would be that for applications which find themselves having outgrown meteor, have a better way of breaking away parts of the application that don’t want to be meteor based anymore.
I think we are hitting this point at work, and the best way I found to break the ui out of meteor was to spend a couple of hours copying all the needed ddp/minimongo code out of meteor and get it everything building with webpack. We don’t want to replace everything ddp/minimongo all at once, but would rather do it slowly.
Personally I am not a fan of meteor using its own package manager (atmosphere), and would like to see more things moved to npm instead. In my experience using packages from npm is unavoidable, which results in there being two package managers in use. And because of this, any npm dependencies of atmosphere packages are installed separately to the rest, and can result in being duplicated.
And because of how meteor does things, trying to use a different test runner (eg jest) requires writing a ton of mocks (for anything builtin and from atmosphere). I have not been able to find a sufficient external package when I first tried to look. For some packages, (eg meteor/check) it was easier to copy the code from github to use for the mocks. Additionally other configuration is required to get fibers to work correctly.
So to me, going the way the rest of the javascript ecosystem is and using npm feels like a good choice that could actually make some things smoother.
I remember there was a big push to retire atmosphere and move everything to npm packages. Unfortunately, there’s some features of Meteor packages that are essential to the transparent isomorphism that defines Meteor.
Instead of extending package.json to support meteor features, they kept Meteor packages around. What I’m sure was the right decision at the time has held back the platform from the benefits of interoperability
