I also have read the article from DHH and I have a few comments on it.
About HTTP2 and sending modules individually, Meteor dynamic imports are very superior than other solutions for dynamic imports as we already do exactly as he explains, we already send the modules individually and invalidate the modules only when they have changes, the same idea explained by him to use with all files is already applied by Meteor in all dynamic modules.
Most of my personal apps everything except the home page, login page and main feature page are imported dynamically because of that so the initial bundle is pretty small and every dynamic module is cached individually exactly as explained by DHH.
This article is a nice wrap up for the future but Meteor already has features that we could expose better, like dynamic imports, that shows how ahead we were and we still are in some directions.
He also highlighted Webpack as the solution back in the days and Meteor was solving the same problems at the same time and without requiring any configuration at all, and we continue to offer many features without configurations.
And the part he explains about import maps we don’t need these as Reify interprets the imports already any way so we don’t need to worry about this part.
Meteor also handles the cases for old browser and new browsers, without any configuration, that will always allow Meteor developers to use latest features of ECMAScript event when they are not supported in all the browsers yet and avoiding polyfills when they do. What he said in the article is true for old features of ECMAScript but not for every new feature introduced in ECMAScript in early stages as each browser will always implement in a different timing and it’s very hard for developers to keep track of everything as we usually use only one browser personally.
Now responding to your comment specifically, I don’t see where SPA is going against individual modules, as I said above, Meteor is already doing this for SPAs for years.
I don’t have strong opinions worth sharing about module federation yet so I prefer to wait here. But it seems to be very similar to our dynamic imports as well, the only different is sharing between apps what I’m not so sure it’s a good idea.
And I don’t want to say by any means that Meteor is perfect and ready for all these cases mentioned in the articles and in your comment but I’m just highlighting many things that Meteor already has to solve the same problems.
The last optimizations made on Reify are probably going to open many doors for explorations.
We are also studying many tools to use in our bundle/build process, we are probably going to share some of that soon.