SQL. I don’t think we need a full fledged SQL support, because you often end up with custom queries anyway. Just making it easy to connect to an SQL database, eg through Knex. This is my top 1 feature, the one that really prevents me from using Meteor in real life projects.
A decent build time. On an SSD it’s just slow but without an SSD it’s unbearable.
Testing. The testing experience is incredibly awful, full of vaguely maintained 3rd party packages, with an out-of-date documentation…
TypeScript but it seems ready in the latest release
Get closer to Express. See server-rendering for example, to access the request, you need to use the sink object, with a custom (and incomplete) API. This is extremely confusing and it took me days to figure out how to add SSR with Apollo on Meteor, just to get what happens, while it should take only minutes. Same with WebappConnectHandlers, it’s difficult to understand that it is just a Connect app. Instead, you could have an API that is closer to Express or Connect every time it’s possible.
Another example of “get closer to Express”: DDP is scaring. We don’t need real-time all the time, and when we need real-time we want sockets. Meteor technical specificities tends to become liabilities on real life projects.
Allow to Meteor to connect to other apps easily. I’d like to use Meteor as a core monolith, but also to develop microservices or specific interfaces around this main monolith, using other more specific technologies (python, frontend oriented frameworks like Gatsby or Next…). Right now communication with the Meteor app is difficult.
Keep supporting React, Vue, Angular and maybe Svelte. Blaze is fun and all but those kind of specific technologies are a no go in most projects. I don’t say Blaze shouldn’t be supported, it has legitimate use cases and is loved by Meteor users, just that we don’t use this technology to write complex frontends, it is just not doable.
Go toward NPM packages. I think it’s already mentioned in the roadmap.
Modernize the account system. This is the most beloved feature of Meteor, the one that other frameworks never matched. Accounts.js is interesting because it takes Meteor accounts as an inspiration without depending on DDP.
Compatibility with Webpack, at least for Storybook? In Vulcan we have managed to install Storybook, by creating specific Webpack loaders to scrap out Meteor imports (https://github.com/lbke/scrap-meteor-loader). But it was tedious. Storybook is not just a 3rd party fun tool but a visual testing framework, I consider it vital for productivity and maintainability of frontend code.
Kill the bad rep. When I say “Meteor” at a meetup I get horror stories about how “this startup chose Meteor and now they can’t scale”. If this bad rep is fair, make it wrong, if it’s unfair, work on PR. It’s difficult to sell Meteor apps currently.
About Galaxy: the prices are ridiculous, my clients will never ever pay that to host their app. An offer between 10$-40$ a month for small apps would be competitive against Heroku or AWS + mLab, especially if you make database backup easy.
Deploying to Heroku when using METEOR_PACKAGE_DIRS env variable. It’s probably doable but I’ve never managed to do a Git based deployment with packages living in another directory. We probably just lack an official doc.
Invest in Europe. We have a different perception of technologies than in “the States”, especially if you are used to live in “The Bay” or any of those magical places where disrupting technologies and investor cash grow on trees. Meteor is a technology suited to SMEs, non profits, young startups, let them know that. Even if those organizations have a low visibility they do have budget for development and hosting, and they are extremely numerous.
To give context, I own an agency that develop complex SaaS platforms for innovative companies and entrepreneurs, usually targeted at professional (small user base for each app, small to medium apps, but with high complexity feature-wise). So my need is being able to quickly spawn a new app, reuse code where possible, and implement features specific to each app.
I also contribute a bit to @sacha framework Vulcan.js. I’ve worked on the Apollo 2 upgrade and Storybook integration. More broadly I do R&D on the subject of productivity increase through isomorphism and declarative programming with Meteor/Vulcan, I want to see how far we can get within a week of development.
I’ve studied extensively the productivity given by various frameworks, in JS or not. Meteor is the #1, for one simple reason: it is full fledged and it allows isomorphism, which in turns allows declarative programming at the scale of the whole app. Other fullstack JS frameworks like Next.js don’t improve productivity server side, because they are “React” or “Vue” frameworks. They just can’t provide this level of productivity currently.
Note that a few things I’ve listed are probably already doable, but maybe just lack documentation/PR.
I really think the potential of Meteor has been underestimated by MDG and its growth limited by a very few set of technical limitations. It takes time to sell a framework, Meteor is basically just starting to take off here in France. So I wish Tiny the best and that they succeed in unleashing Meteor true potential.
On the note of non-developers using Meteor, I remember few years back we had a visit at Meteor NYC from France where the person presented us an app that tracked traffic and other things in super markets. The person was a mathematician or something along those lines and they didn’t had any developer in their team and were able to build an app for data gathering and analysis with Meteor. So in this way Meteor is amazing with connecting people out of the dev world.
What about making DDP able to send changes to deep-level fields without changing the whole top-level field, using Mongo’s syntax, like: ‘topLevelField.$.deepLevelField’ ?
That would allow skipping all the multiple collections/joins/denormalization stuff to be a lot more straight forward.
But maybe that it is a naive or bad idea: I am quite new to Meteor. That is also why all this multiple collection stuff is a pain .
I make my living from a Blaze/Iron Router project. I wish someone would just go through Atmosphere and tag the packages that don’t work… Im your typical business owner/quasi-Coder who managed to put an app together in 2014… with the help of Meteor. Now I’m stuck in 2014 because I don’t have time to navigate this jungle of updates.
I would love it if Galaxy had integration with gitlab or github for auto deployment. It would be awesome to just connect a repo and deploy a branch of your choosing.
Right now it isn’t possible to publish both doc.a.b and doc.a.c so that the client gets doc.a.{ b, c }. That’s the part I find most surprising.
And with the mergebox, it already does deep diffing (to check equality), the problem is that it only has the ability to send the client top-level fields over DDP. With only the ability to send top-level fields the mergebox is basically useless. If it could send nested fields, there are some places I’d love to use it.
I don’t think this is exactly what you’re after (and it’s not production ready) but we’ve been playing with this for the last few weeks, to allow the same client to separately subscribe to multiple fields within the same top level field.
It’s useful for us with our custom tables (with one set of fields) and table exports (with a different set of fields) when combined with custom document schemas (all custom fields reside in a single top level namespace).
This thread is turning into everyone’s wish list. Tiny is here for business not to make all the dreams of us (lazy) developers come true
If the platform is to become live and vibrant, a feature that is important enough will get developed by contributors (e.g. all those I want Vue or Svelte support). That’s not their job
What we should really want is:
Tiny has to vocalize what is its business intent – How will they make this profitable. Is it via Galaxy, or support, licensing to dev teams, or Apollo-like data services or integration with existing Tiny services. This also will define who the target audience is (entrepreneurs are risky, they fail 99% of the time and want everything for free – don’t want history with MDG to repeat itself)
This translates to improved awareness of the platform – for instance, push success-stories publicly, meetups, etc.
Better integration into the NodeJS ecosystem (Maybe keep important packages but cleanup Atmosphere, looks shabby for any newcomer to see all those unmaintained packages)
My opinion: React is here to stay and is by far the dominant JS view framework (holdouts seem ideological or small / single-dev teams). React HAS to be a first-class citizen to entice corporations. View-layer agnosticism would drive away interest. The React audience is HUGE and are often backed by companies. This is where interest and real money is.
Listening to this podcast episode about SSR in React (they mention Meteor and Apollo a few times), makes me think there still is a big opportunity for Meteor here as well.
I don’t know if it’s possible to make SSR more plug and play, but just fixing someofthegotchas should already go a long way I think. Looking at how Ben aced the dynamic imports, it should be possible to make this a better dev experience as well. You already see community efforts like this package trying to achieve the same thing.
I have the feeling the JS community is still looking for a go-to solution for this, and out of the box SSR could be a USP that makes a lot of sense for Meteor.
Post Your Most-Wanted Features for Meteor seems to be asking for just that.
If the platform is to become live and vibrant, a feature that is important enough will get developed by contributors (e.g. all those I want Vue or Svelte support ). That’s not their job
Vue integration is already a feature that has been developed by contributors. It’s in the official Meteor guide.
View-layer agnosticism would drive away interest.
Why? If developers familiar or partial to a view layer come to Meteor after learning about a first class integration, that is more devs using Meteor and potentially contributing. If a company would like to adopt Meteor progressively, it would be beneficial if they could use their existing front end code base. I’m interested in using a framework where I’m not tied into a view layer or database. Ruby on Rails and Django are view layer agnostic and plenty of people use them.
React HAS to be a first-class citizen
No more than Angular or Vue does.
The React audience is HUGE and are often backed by companies.
Same can be said for Vue (Facebook, Netflix, and Adobe) and Angular (Google, Udemy, MIT).
Not sure what your message is as you seem to agree with me that contributors have carried the torch for Vue. My point is that it’s not up to Tiny to do all this but the community. Let’s make it short and sweet
The post title is ‘Help Tiny’, so we should focus on what is expected from the owning company by the community. First-class view layers other than React should be up to the community (maybe Angular can be up to Tiny as well, not sure)
PS: I wasn’t aware that Facebook was using Vue in any significant way
Core Vue contributors (especially Akryum) have worked on the integrations for Vue. I don’t know the history of how React came to be a part of Meteor and if core React members made it possible or if MDG helped out, but I imagined the community carried the torch for it as well.
First-class view layers other than React should be up to the community (maybe Angular can be up to Tiny as well, not sure)
Still don’t understand why you think they should be maintaining the React integration but leaving everything else up to the community. It’s up to Tiny whether or not they think supporting the existing integrations is important.
It’s been mentioned in here already, but the creator of Vue worked for MDG and it has been argued that it is an even better fit for Meteor than React. My point is that Meteor can be successful while not favoring one view framework over another.
Notice the bolded part, it’s my opinion. React is by far the dominant view layer see proxy chart (Angular not far behind, but it comes with its own full toolkit). If we want Tiny to be a good shepherd, we need to help them focus on where the money is.
.
Based on my ideas there then this package was made by