I think Meteor needs to go the other way - rather than supplying various kinds of data layers and all that - just focus on being a better glue between all the parts of the web stack. There’s nothing stopping any of us from creating our own data syncing libraries, etc.
3 Likes
Yes, please improve atmosphere. As long as there is package-able code depending on the Meteor-Env we cannot fully move to NPM and thus Atmosphere remains important in the Meteor ecosystem.
Improving Atmosphere is improving Meteor’s core functionality! Here are some of my points on that:
- Make it easy to detect abandoned packages. Idea: Introducing a
statusfield to the package, similar to https://www.repostatus.org/ and encourage package maintainers to update the status, so it is easier to differentiate between a tiny stable package that does not require further improvement and real abandonware - Replace trend counters with a historical chart that reflects the usage over the last week/month/year
- MDG Packages / official Packages could be marked as such or be listed in a separate tab “official” so beginners can easily start off with “official” supported code
- Support organizations like in Github, so I don’t need 3 accounts to publish under different domains to reflect the same domains (organizations) as the GitHub repos are
7 Likes
SSL support on local dev - that’d be a killer feature for Meteor…
Nice! That will most likely make testing Push Notifications so much easier as those usually demand SSL…
I has changed and we had companies who contributed in the past. But that has basically stopped, which is a sign for Meteor usage has stopped equally and those companies might have moved on to other frameworks.
For our app I can envision that the users would like to have “read-only” offline mode. To check their family tree, see the triangulated groups (meaning those DNA cousins where all inherited a small piece of ancestral DNA) and look at discussions in our various forums.
Then when they eg would like to reply to a question in the forum it would check for connectivity and only then start to send the new data via a remote call to our backend app.
2 Likes
I like this use case, thanks for sharing, I think it’s a good use of offline-support. Please keep me honest here, assuming the main app.js is cached a long with the modules and css, then is it true that we only need to have some sort of client side caching for the data since all the routing is client side only and no request will be triggered to the server? perhaps we can add a plug-in to cache the returned data from Meteor methods and use that when the socket is disconnected. But I’m not 100% if the app.js caching assumption is reliable enough, maybe someone who has more experience with service workers/client caching can share their thoughts.
I don’t think many companies contributed in the past aside from MDG and Kadira. Large companies like to have control (they can afford it) and incremental adoption of a stack and I think this was the main motivation behind Apollo, a company can incrementally adopt the stack unlike Meteor all-or-none approach. Also the NodeJS ecosystem got flooded by boilerplates/scripts since 2015 designed by large companies and some companies pivoted to other framework once they got traction. But I argued in another post that Meteor is the closest thing we’ve to something like Ruby on Rails and entrepreneurs and small to medium size companies should in my opinion embrace and contribute a full-stack NodeJS framework.
Anyway to each his own, I for one really happy with the tech, it helped us to get the job done and I hope it keeps on getting better.
2 Likes
Yes, we do have separate servers for frontend and backend. So remote calls/methods are our preferred data exchange and otherwise we rely on pin/sub for the mini-mongo.
Andreas
1 Like
I have been using Meteor, almost exclusively, on my projects for over 4 years now. Have loved it from the start! So I agree with @msavin, not much needs to change.
One wish list item however: a recent (client only) project I inherited worked with Parcel as a build tool. The build times are really lightning fast (often < 1s), and the client displays the changes right away, without having to reload. I found this was bliss for development speed and experience. It really makes a huge difference. And it’s almost that magic feeling I got the first time I used Meteor 
(although Parcel does have its issues; sometimes I still have to refresh or even restart manually to see my changes).
It would be so awesome to have this kind of tech in Meteor as well! A hot code reload without a refresh. Kind of how style changes already work in Meteor (although even these are still slower than Parcel build times). Normally, I would accept the argument that this is hard/impossible to do in a general-purpose framework like Meteor, or without a lot of configuration like Webpack requires. However, Parcel has 0 configuration, it works with React etc, and even automatically detects and installs build packages that are needed (e.g. it will install and run LESS if it encounters a .less file in your code).
Could this technically be done in the Meteor build tool?
3 Likes
Parcel get its speed from parallelization, the ideas of parallelizing meteor build are as old as Meteor, you can find github issue from 2014 by the legendary glasser, I think most of the recent build improvement in Meteor were achieved by caching and skipping unnecessary steps, I think parallelization value will only be noticed in large projects, fresh Meteor projects are really fast but the magic you’re talking about is achieved via HMR (hot-reload) and the issue with that is that it requires custom code/plug-ins dictated by the view layer, which I think is the reason why we don’t have HMR native to Meteor since it’s front-end agnostic. Also, from my experience with webpack, HMR is not that reliable, many times my projects don’t really refresh but most of the time it works well.
I’d love to see parallelization in package building since we’re using package based architecture and scanning each package for change is taking around 2 seconds. The issue with us is that we’re developing inside the packages and the package rebuilding is not optimized since the assumption is that packages don’t change often.
This was the exact argument I dispelled in my post. Parcel seems to be front end agnostic too, so it is possible. And if for some reason it is not possible to make it agnostic, they could potentially still make a React-only/Vue-only/etc package, which you then manually install. The no-reload is really what does it.
I have to stress, Parcel is really fast (twice as fast as Webpack according to their own website). You should check it out.
1 Like
Ah I just checked their site and yeah it seems to support hot module replacement in front-end agnostic way, thanks for the correction.
As you save files, Parcel rebuilds what changed and sends an update to any running clients containing the new code. The new code then replaces the old version, and is re-evaluated along with all parents.
But it seems different than Webpack HMR in that it replaces the whole file as oppose to component. It’s more like reval for blaze, I’ve to look closer at Parcel code but I don’t see how you can do HMR without knowing which view library you’re using. But parcel has its own issues and lack features.
Yes, but its speed is largely due to parallelization, webpack doesn’t run in parallel, yet. There is even faster bundler than Percel, you can try Pax, and even faster if the bundler was built with Rust, something like swc.
One thing I’d stress out for the Meteor refresh is to make sure you’ve your client files under the client folder, this will trigger client only refresh and skip the server refresh.
1 Like
You can get main js/css bundle and html (and anything in /public) caching with the appcache package. It currently uses the deprecated but still supported appcache API. If you also have dynamic-imports installed, that package puts modules into offline friendly indexedDB. That package will also notice that appcache is enabled, and will prefetch all the modules you need after the application has started (a PR contributed by yours truly).
I also created a Meteor friendly fork of react-loadable to capture and enable preloading react modules split with react-loadable.
All that’s left at that point is having some way to cache your document data, which will depend on your document source. If you are using MongoDB/mini-mongo, you can use something like Ground:DB, or if you use Apollo, you can use an offline apollo package (or heck, even Ground:DB!).
I’d love to see (or even implement/migrate, given the free time) the features of appcache in a service worker, with additional types of caching like optional assets (similar to webpack-offline).
You can also do SSR and additionally, a fast-render like serialization, but you’ll have to glue all that together yourself. I have a solution I created using a connector pattern, that I’m hoping to write about soon, which makes setting up all the different data delivery modes relatively easy (I’ll maybe even release a few helpful packages, again given the time).
If I could figure out the finances (or find someone who loves that stuff to help me out) I’d work on these things more…
6 Likes
Is that still true? I remember that it was the case somewhere around Meteor 1.3 or 1.4, but there have been a few iterations on the build tool since then, and the the Guide suggests a layout that has most of the code outside the client folder.
Yes, it’s true, you can give it a try, create a client folder inside your imports folder and place your pages/components there and you’ll see only the client refresh, I’m using 1.8.
2 Likes
@alawi I followed your recommendation re: putting a client folder inside the imports folder, and it sped up rebuilds dramatically!
3 Likes
Still not nearly as fast as a refresh-less update (‘hot reload’) though