Some of you may know me, others don’t. As I haven’t posted for a long time, I will take this as a quick presentation. I’m Nacho Codoñer, a former core developer from Pathable platform, which sadly was shutdown as you may already know. I have been developing with Meteor in my entire career, and I have developed much enthusiasm in every part of the software development process.
Currently, I dedicate my time to make to real a dream app, of course using Meteor, but other kind of interesting tooling learned over previous years.
Today I would like to present a straightforward solution that I have on my projects to have Tree shaking, secured code, and other advantages on last compilers features. I am using the best Webpack can offer along with what Meteor delivers.
The solution doesn’t rely on modifying the core or creating any Meteor build package as was a previous solution. Instead it keeps a simple solution of script processes and configuration (a bit hacky maybe). I am working with a more advanced project and it works perfectly with much more stuff integrated on the webpack configuration. So I believe it may be useful for some of you, at least the idea that you can go beyond the limits that Meteor imposes if you need.
Surely, when there are any advantages, it comes with its own set of disadvantages, like I’m not using anymore nested imports and dynamic imports using DDP protocol. But for me this is like what is happening with Fibers, non-standard methodologies will become a problem and drive us to reformulate our solutions at some point.
Just that, I hope it is useful for someone and I will try to get more time to share learnings on my way. I am also using CapacitorJS with a similar kind of solution that I hope to validate soon and share with you my journey.
I’m posting this question to the community, hoping someone can provide a clear answer. I am not experienced in Vite, the only thing I know is that it is “more performant” in theory because it uses browser native capabilities during development. However, I lack practical experience with Vite’s environment, features, and plugins.
In general, I tend to stick with technologies I already know well instead of adopting new ones to cover capabilities that existing technologies already support. My approach is to maximize the advantages of my existing knowledge rather than chasing the latest hype. Of course, this perspective varies for each individual.
In contrast, I can say which are the strong points of Webpack. The ecosystem of Webpack is so mature and widely adopted, a huge community of developers is behind.
It offers an impressive set of core capabilities, including code splitting (aka dynamic imports), tree shaking, asset management, cache, web workers, advanced minification, and much more; all of these with full customization for advanced usage.
One of the standout features of Webpack is its plugin system. There are some built-in plugins like “Define plugin” for generating secure code bundles, the community also offers a wide array of plugins that can handle almost anything you can imagine, before, during, and after compilation.
Here are some additional examples of useful configurations and extensions:
Just a clarification here. Dynamic imports are already supported by Webpack. I have provided additional details on this topic in the repository, available here.
However, the approach Meteor used to apply dynamic imports is not supported so far through this setup. As you suggested, I achieved it through a Webpack’s configuration to ignore import statements and ready on the Webpack’s output for them to be available for Meteor compilation and parsing, but I encountered some issues during production builds. Surely it can be adapted if explored further, but I decided to skip it as the effort required to make it effective didn’t seem justified for my current needs. Webpack’s dynamic imports are enough for my purposes.
Regarding Meteor’s nested imports, I also attempted to replace them with Webpack before and after compilation. However, it didn’t seem worth it for my current needs. I might consider re-attempting this at a later point in time.
I went a different direction with React & Meteor. With react-router-dom@6, and using createBrowserRouter with lazy and loading the component and your data in parallel, I was able to achieve even better performance and the bundle size is in kb not mb.
I have given a quick attempt to enable it since the setup guide seems to be straightforward. However, I realized that millionjs requires node >15 to work (Meteor currently limited to 14 version). I tested by just running the webpack process with a higher node version, however, I run into other issues.
Definitely it is an interesting configuration to try, but it would be really helpful to finally reach the Meteor node upgrade version which is close in order to facilitate the setup and the inclusion of this kind of modern tooling.
Thank you for sharing this tool, it seems promising, maybe when I have some spare time I will continue my attempt on it.