Help Tiny: Post Your Most-Wanted Features for Meteor

hluz · October 3, 2019, 10:01pm

Vue as first class citizen.

ackzell · October 3, 2019, 10:24pm

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?

awilkinson · October 3, 2019, 11:42pm

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

mahadoang · October 4, 2019, 12:00am

Vue as first class citizen.

storyteller · October 4, 2019, 12:10am

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

drew · October 4, 2019, 12:14am

An a firewall for Galaxy apps

storyteller · October 4, 2019, 12:43am

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

github.com/meteor/react-packages

Optimized useTracker hook

meteor:devel ← CaptainN:hooks-plus-ultra

opened 04:07PM - 26 Jul 19 UTC

CaptainN

+1503 -240

This PR is a roundup of the discussion (and builds on the work) in #262 and #271…, and supersedes: #242, #252, #256, #263, #266, #267, #268. It does the following: - Create a base hook, `useTracker` to for use as an alternative to withTracker in hooks based projects. Rewrites `withTracker` on top of `useTracker` (issues #256, #252, #242 / PR #261) - Updates docs! - Removes deprecated createContainer. - Above #262, this PR retains the synchronous rendering behavior in `withTracker` and in `useTracker` if no deps are specified, but also allows asynchronous reactivity after `firstRun` if deps are supplied, and properly responds to deps changes. This implementation is [compatible with Concurrent Mode, React Suspense and Error Boundaries](https://github.com/meteor/react-packages/pull/271#issuecomment-518414448). - I wrote new TinyTests for the hook, and ported back the old ones. - Above #271, this PR fixes a number of issues raised in that PR. - It also switches the underlying deps compare functionality from a fork of React internals to using `useRef`. There was some concern that results from that may be randomly tossed, but for now (react 16.8.6) they are stable. Even if they are tossed, the only effect this will have on our implementation is that it'll recreate the computation on the next render. - This PR also adds a third param to the hook, which is a computation lifecycle hook. This method is structured like the method passed to `useEffect`. The main function runs when a new computation is created (before `reactiveFn`) and then if it returns a function, that function is run right before the computation is destroyed. I don't know if this is really all that useful in real world use cases, but it is useful for testing some internal behaviors. I left it undocumented for now. - This PR also now passes a reference to the current computation to the `reactiveFn`. - Compatible with SSR. Since this bumps the react version requirement to 16.8, there has been some discussion about how to properly release this with a major version bump. One suggestion was to bump the old version to 1.0.0 which can receive updates separately, then release this update as 2.0.0. I believe this is ready for review. (Third time's a charm!) CC @hwillson @menelike @yched

menewman · October 4, 2019, 12:50am

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)

digitalx778 · October 4, 2019, 1:06am

Mobile development-react native support

jonlachlan · October 4, 2019, 2:40am

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

wildhart · October 4, 2019, 2:48am

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!!

htchd7 · October 4, 2019, 3:36am

svelte and keep blaze please.

adamginsburg · October 4, 2019, 4:40am

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.

alawi · October 4, 2019, 6:00am

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.

hluz · October 4, 2019, 7:30am

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

diaconutheodor · October 4, 2019, 7:39am

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.

Have a ultra-thin version of Meteor that does not depend in anyway to mongo
Allow completely shutting down DDP and dependencies on DDP.
Decouple Accounts from DDP.
“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!

mitar · October 4, 2019, 7:53am

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

mitar · October 4, 2019, 7:54am

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

vbelolapotkov · October 4, 2019, 8:11am

My preferences would be

Native typescript support
Testing with Jest
Better code splitting

marklynch · October 4, 2019, 9:15am

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.