Help Tiny: Post Your Most-Wanted Features for Meteor

Vue as first class citizen.

20 Likes

Yeah, I’m thinking the same here.

Something like when you’re creating your app, you choose what UI solution you want and it is there for you.

Beyond that though, I think it also would mean more resources in teaching how to integrate both, the gotchas, etc. An up to date tutorial, more content on the guide and things like that?

Official backing of the effort made by Akryum to make meteor-vue maybe?

6 Likes

This is such a great thread, please keep these coming! :slight_smile:

7 Likes

Vue as first class citizen.

6 Likes

Forgot to mention 2FA for Galaxy. That has come up for some of the advance/corporate users as a show stopper in the past.

9 Likes

An a firewall for Galaxy apps

1 Like

Quiet urgent is also a refresh of the Meteor React packages. Something along the lines of:

7 Likes

An officially documented/supported way to re-use Meteor’s websocket connections without it going through the database (i.e., I have a Meteor app and want to use sockets without pub/sub or Mongo getting involved)

9 Likes

Mobile development-react native support

6 Likes

I think an email-only – no password, [no username?] – accounts package would be interesting.

2 Likes

Amen to that - I would love a cheaper teir for hobby/small projects. Many of my hobby apps can fit on a single $5/mo Digital Ocean or AWS instance, including the db. I would love to be sending that money back to Meteor/Tiny instead of DO/AWS. It’s not much, but I think there’s a lot of developers in the same boat - just look at how popular mup has been over the years, which thanks to @zodern it’s still going strong…

Edit: remember how awesome it was back when we could download meteor, hack around with an app for a few hours and deploy it to *.meteor.com for free!!

12 Likes

svelte and keep blaze please.

5 Likes

Make React Native support core/first class citizen - ie robust, works out fo the box, documented, supported for packages (or alternatives) like https://github.com/inProgress-team/react-native-meteor#readme and https://github.com/DesignmanIO/react-native-meteor-offline

While some may think this is not core… I think offline mobile a critical capability that goes with most Meteor implementations

Alternatively, give us another Offline mobile approach it just needs to be rock solid - Cordova won’t cut it.

7 Likes

I think this is an important one and makes a business sense (at least for me). A lot of Meteor projects start as a hobbyist project given the ease of development but they could potentially mature to real business. I think it make sense to at least price match DO so folks would use Galaxy from the start and continue using as the business grows. I think Meteor would be a great fit for the indie hackers culture that is growing.

It is not just Galaxy money was heading to Apollo but I also think a lot of folks using Meteor are heading to other hosts due to the price difference with DO (among others), so Meteor money is going to DO. Fixing this and increasing the Meteor adoption (by pushing on Vue integration/tutorials and even svelte) and injecting some positive energy/marketing should increase the revenue for Galaxy.

In terms of features, I think Ben was doing awesome work (and I really hope he keep supporting Meteor in his spare time). I second the request for tree shaking and HMR (module.hot.accept() api) which I think are the only two features lacking behind webpack at the moment. Any optimizations in refresh/re-build speed (catching etc) are always great. Reducing the initial bundle size and making web sockets (specially account package) opt-in will allow Meteor to scale in stateless manner. Fibers could be deprecated (in backward compatible way) however I personally don’t think it’s a real issue.

For the community, commitment to the long term Meteor support, more active community leadership ( the community has been self managing for the last 3 years or so), perhaps an update to the website/brand and a push to the community packages organization so they can support the core community packages, and blog posts here and there will also be great. The account package did wonders to Meteor, I suggest adding a payment package (with multiple providers including Stripe) because payment is what most entrepreneurs will want after accounts, it is not surprise that Stripe acquired Indie Hackers.

Finally in terms of vision, I think Meteor can be the go-to NodeJS backend framework (similar to rails), given that it support multiple view layers and has accounts and many other packages out of the box. The serverless/graphql/webpack hype will slow down which will be a great opportunity for Meteor to claim the rails position and the king of backend for NodeJS.

I really like the MDG team (especially Ben and Glasser), many smart people. However I’m skeptical that Graphql will be the REST replacement it wants to be, but we keep an open mind. I think Tiny did a great move, it’s perfect timing to get Meteor going and they’ve an amazing opportunity ahead of them.

21 Likes

…and an official AzureAD accounts integration for those enterprise apps that no one realises exist because they are not visible.

6 Likes

Meteor is so perfect for us right now. Since we mostly use Apollo and React, the Meteor layer we still tap into is small but it’s gorgeous and perfect, so basically my wants are in that direction. We’ve said good bye to DDP and Blaze long-time ago.

  1. Have a ultra-thin version of Meteor that does not depend in anyway to mongo
  2. Allow completely shutting down DDP and dependencies on DDP.
  3. Decouple Accounts from DDP.
  4. “Make galaxy great again”

That is really it. We are very content with the stability it offers, we promote it, and we would love to use more of the services it offers such as Galaxy, but currently it has too many limitations that have already been mentioned many times in many threads.

Cheers!

11 Likes
  1. and 2. is already possible, except for hot-reload which is the only one which requires DDP.

See: https://github.com/mitar/meteor-issue10710/tree/b2f5f794d9d4d862ad356bf704c75fbcd7fc2bc4

1 Like

I would say, move as much of the code to NPM as possible.

13 Likes

My preferences would be

  1. Native typescript support
  2. Testing with Jest
  3. Better code splitting
5 Likes

Galaxy was great except for the performance. We left because the speed of a T2/T3 micro (or even nano) blew the equivalent galaxy containers away. If they could improve that and add TFA, a way to store the settings securely, tightly integrate the APM and add the remote shell/debugging that Ben mentions that would be a really compelling platform. I actually really miss the Galaxy dashboard and how well it worked on my phone compared to AWS’s myriad of horrible UIs.

3 Likes