Here’s something to kick off the thread – a request for an official version of qualia:reval - Instant Meteor reloads.
This package allows you to instantly reload files, via either an in-browser editor or an editor plugin.
8 Likes
Cool package, but I think there are more pressing matters. This topic has been discussed to death. I think the biggest and most recent discussion about this is this topic:
Personally for me, it is tighter integration with Apollo, PWA, upgrades to MongoDB packages (and in extensions DDP, especially things that would reduce traffic on Atlas) and other official packages like the accounts system which are great for marketing. After that more features for Galaxy (maybe including cheaper tear for hobby projects and new locations) would be super welcome.
15 Likes
The thing I would like them to do most is to get the word out that Meteor is here to stay. And that under this new leadership team there will be communication about the future direction of the project. I think this will help to reinvigorate the community.
9 Likes
I love the Meteor <-> Cordova integration, and am hoping we can get the same going with Electron.
There have been at least two (failed) open source integrations. However, I’m sure the story on that can be easily turned around.
NPM Downloads (weekly)
Cordova: 96,010
Electron: 215,611
24 Likes
It would be great to see more support for @diaconutheodor’s redis-oplog package. It’s not something that everyone needs, but for companies that are running large deployments, it’s essential.
13 Likes
Finally, in the spirit of assuring everyone that Meteor is stable, as I’ve been saying for years, I would love to see long-term support for current APIs. It would be especially helpful as Meteor transitions to new leadership.
5 Likes
I like the cordova integration too … I’m hoping with additional resources the cordova integration can be kept up to date and will be well supported in the future
10 Likes
Rebuild performance continues to be one of the biggest challenges for our team as we scale!
16 Likes
I think I figured out one of the core causes of Meteor rebuild slowness a while ago but haven’t had time to open a PR.
Essentially, the build system uses LRU caches of insufficient size so for large projects the cache might as well not even exist. I changed one of them locally and it immediately significantly improved rebuild times.
11 Likes
What is the correct way to change the size of the LRU cache locally?
Would this NPM package be relevant – https://github.com/isaacs/node-lru-cache?
We could experiment with setting LRU sizes to Infinity by default (in tools/fs/optimistic.ts), and pay close attention to whether/when large applications start running out of memory (the other side of this double-edged scalpel). Unfortunately I don’t know of any way to pick a reasonable LRU size in advance, since the right size depends on dynamic memory pressure. Maybe a better strategy would be to keep track of cache entries that haven’t been “used” during any recent rebuilds—something akin to generational garbage collection.
7 Likes
@benjamn, would something like qualia:reval - Instant Meteor reloads potentially be feasible for inclusion in Meteor?
I second the motion for additional PWA support as a fantastic feature for Meteor.
Additional SSR support would also be excellent.
6 Likes
- Tree Shaking (at least package import level tree shaking, maybe some of the better stuff @benjamn once mentioned in a feature request ticket). This may be important for Svelte support in particular, as many Svelte libraries are packaged in a way which assumes the use of rollup’s tree shaking to reduce bundle size.
- More support given to Svelte integration in general. I have a pretty good starter though, so maybe it’s not needed.
- A proper service worker build target. Regular Web Workers can be built from a
function.toString()but service-workers require an actual server route. - Galaxy: Better APM for tracking things like memory leaks - a heap-dump function would be nice for example. Better might be a way to inspect the memory in some live way.
12 Likes
What else besides a service worker do you need for PWA? I have actually gotten full PWA support up and running, though I wish the caching system was better (I’m using a mix of deprecated appcache and a static service worker). It’s on my list of TODOs to eventually build that - though I need to find time/funding.
For SSR (using the server-render package), I find the only thing really missing is a way to modify the body tag, and maybe some better management of the order of tags in the head (in particular, I can’t get SSR code from react-helmet or Svelte to come before the meteor css bundle, and have to resort to hacks to move things around client side - this same area of concern is inconsistent during local development, which can create some confusing production issues).
4 Likes
I’m going to echo svelte integration and PWA support.
Although there’s not actually a lot to integrate. Svelte is really accepting of Tracker.
I would like a way to “hydrate” subscription, though. You could technically SSR an entire page with subscriptions, but once the client hydrates, you enter a loading state again. A built in way to hydrate a subscription without entering a loading state would be fantastic.
Not in its current form, as I think @veered would agree, because it only works with Blaze, and relies on short-cuts and assumptions that are not generally valid. For example, it recompiles and reevaluates modules in isolation, which is fine for modules that have not exported any stateful values to other modules—but that’s a very narrow category of modules, since importing and exporting values between modules is kind of the whole point of a module system.
Looking at the wider ecosystem, folks who talk about “hot module reloading” tend to be assuming a particular UI layer, such as Blaze, or React, to the exclusion of other view layers. Almost no one who uses Webpack goes to the trouble of writing module.hot.accept(...) hooks to properly clean up their modules during hot reloading, so the only way you ever end up with a consistent experience is if you rely on React-specific tools that add those hooks to your React-specific modules behind the scenes, under React-specific assumptions, and even then it only works most of the time.
Because Meteor is agnostic about your view layer, and Meteor’s build system has to work for all applications all of the time, short-cuts that cover only certain use cases some of the time are not an option. Instead, we have to take a step back and think really hard about a more general approach that empowers everyone.
As one possible example of a more general approach, perhaps Meteor packages could opt into some sort of restart behavior where they get to keep some of their resources, so that restarting the server is less expensive, because some/most packages can avoid repeating expensive computations.
Why am I going into so much detail here? I want everyone who reads this to appreciate the challenges of adding new functionality to a framework that many, many other developers depend on. Plenty of clever ideas work fine within a single application, but fall apart when you try to integrate them into the framework, because there’s just so much more to think about.
I don’t think I can be honest about this reality without sounding a little discouraging, but I’m always happy to talk about concrete implementation ideas.
22 Likes
@captainn Tree Shaking is very much on my mind for 1.8.3! In fact, that’s one of the motivations for all the work in 1.8.2 to use the “module” field in package.json when possible.
Regarding Svelte, my hope would be that Meteor’s compiler plugin system and build process already enable a reasonable Svelte workflow. If not (and I’m sure there are shortcomings), I see that as an opportunity to improve the build system in general, hopefully without adding any Svelte-specific functionality.
Regarding Galaxy, I can think of a number of relatively easy, extremely high-value ways the Tiny team could improve the Galaxy debugging experience: a secure remote meteor shell that you can attach to any container, the ability to attach the Node inspector to your production server (which would enable breakpoint-based debugging and heap dumps, among many other benefits), and perhaps a complete rewrite of the APM tools.
11 Likes
It works on much more than just Blaze (and can even do server side patches). It also does have a (yet unreleased) way of dealing with live patching module exports.
But yeah it’s hacks-on-hacks-on-hacks. When Reval is used to its full potential (as at Qualia), most client and server reloads can be avoided during development. But this sometimes requires an understanding of how Reval works under the hood. It’s not very complicated but there’s a learning curve.
I think that Reval could be made much, much more robust and generally accessible (especially if certain Meteor build tool changes are made), but I agree with Ben that it can’t work by default 100% of the time.
However, rebuild times are the biggest problem with Meteor for large users. There are frequent incremental improvements, but until there are rebuild performance benchmarks specifically testing really large projects things will never be completely for resolved. For example, the LRU cache issue I found will only really show up for projects with a ton of files.
2 Likes
I think staringatlights:fast-render will do all that subscription hydration even on a per-route basis. I’m not sure if it will recycle the mergebox though - it’d be pretty sweet if it did.
2 Likes