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.
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.
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).
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…
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.
Yes it will preclude them, they won’t be accessible from the server files.
I only use the client folder for the UI pages/components to speed things up, I think the only case you need to access the UI pages from the server is for SSR, but for me I only needed that for few pages (home/login etc) and the rest are all dynamically imported pages from client folders.
Here is an example of a folder structure that uses this technique:
During dev, when I change anything in the client folder, only the client will refresh. Anything in the API will cause server to refresh.
Yeah, I am a bit bummed about this as well. It seems we lost @abernix and @benjamn to the new shiny object And for me I don’t really see the benefit of Apollo since my whole app lives in the Meteor ecosystem (Mongo, DDP, and the likes). Are you feeling the same way or am I missing something about Apollo?
Yeah, if Mongo fits your needs and you rely a lot on reactivity, then Meteor’s livedata mechanism is hard to beat in terms of speed of development. The only complaint I have is that it’s not stateless and doesn’t support joins. Because it’s not stateless it’s hard to scale and it’s not resilient to container/vm crashes/disconnections. Because it doesn’t support joins the data structure is usually heavily determined by the presentation layer, which makes it hard to change your presentation layer without touching your data layer.
GraphQL might prove to solve these 2 complaints. https://github.com/hasura/graphql-engine seems interesting in this regard. But it’s all still very young and fast-changing.
It’s my understanding Apollo is best for very large apps, otherwise, it’s not really worth migrating to. Most things can be done with Meteor Methods. Just my opinion of course.
I’ve the same feeling as @methodx I think Meteor’s pub/sub and RPC methods are great for small to medium size apps and GraphQL/Apollo shine when you want to have flexible API coming from multiple data sources.
With that said, a lot of the ideas from Meteor data layer are being applied to Apollo. The Apollo Client 2.5 that was announced yesterday aims to make GraphQL the one source of truth (used in both client/server) which is kind similar to mini-mongo.
That’s the assumption indeed. Although websockets on their own aren’t necessarily the problem. But Meteor’s mergebox system makes that the server has to keep track of a lot of the client state, which makes the problem harder.
The section about code splitting would have been a great opportunity to promote Meteor’s great code splitting system. The fact that they don’t try to piggyback Meteor on the Apollo hype (if anything it looks like they try to distantiate Apollo from Meteor) makes me worried for the future of Meteor.
And for me I don’t really see the benefit of Apollo since my whole app lives in the Meteor ecosystem (Mongo, DDP, and the likes). Are you feeling the same way or am I missing something about Apollo?