![]() ![]() Though it is a small risk, it is one you should be aware of when updating your dependencies. There is some inherent risk in this, as you are manually selecting the files to be automatically deleted, and these files may change as you update your dependencies in the future. Then loop over the junk array to delete them during or after the build. For this I usually end up creating a custom build or post-build script that lists the path to each of these junk files/folders in an array. But what about the stuff you can't? Most of the time each Node Module will come with a lot of extra files that your end user does not need shipped to them ( README.md, src folder, tests folder, etc.). Okay, so simply moving everything you can get away with out of dependencies will do a lot to help. Koa11y requires the dependencies of Pa11y and PhantomJS to test accessibility problems on webpages. Example: Scout-App is a desktop app that processes Sass to CSS, so it needs the node-sass binary files shipped with it. Modules with binaries or other unique files that can't be bundled - These should be listed as dependencies.Libraries your code uses - If these are just code libraries, then ideally, they should be in the devDependencies too, and the relevant code pulled in by an automated bundler/tree-shaking tool (Webpack, Rollup, Gulp, etc.).Things you just need for development - These should be in your devDependencies in package.json and removed when it comes time to build for distribution.So it's likely that your app will have some packages it needs shipped with it. ![]() One of the great features of NW.js is the ability to access Node modules directly from the DOM. The node_modules folder has a reputation for being a beast. That would require twice the manual testing of the application though. A compromise would be to build this version just for legacy OS's but use the latest versions of NW.js for everything else. But you get much wider support for older OS's, and a smaller dist. This savings comes at a trade-off of giving up some developer conveniences, newer features, and most importantly security patches. This can save a cool 63 MB (or 86MB if you're really crazy). Using the Windows releases as a baseline, the latest versions of NW.js (~0.36.x) are around 189 MB, the LTS (0.14.7) version is 126 MB, and the outdated version (0.12.3) is 103 MB (again, not worth it). If you create your app using 0.13.0 or above, then updating to newer versions of NW.js is completely painless and will almost never require any code changes other than if something was deprecated in Chromium or Node themselves (pretty rare outside of experimental features). Meaning that it will be more difficult to update your app to newer versions of NW.js in the future. It is not recommended to use this version as its API has subtle differences from the 0.13.0+ releases. This was the last release of NW.js before it had a major architectural change to allow releases to come out faster and more often. Using this older version will mean a major reduction in the total distribution size of your application, however it also means giving up access to newer features and newer developer tools that come with the latest Node/Chromium releases.Īnother choice for an older version is 0.12.3. This was the last version released that supported legacy OS's (Windows XP+, OSX 10.6+). The go-to version would be 0.14.7, the Long-Term Support (LTS) release. One solution to reduce file size is to use an older version of NW.js. However, for those willing to use older versions of these technologies, this opens the opportunity for some interesting trade-offs. It typically produces a new release within 24 hours of a new Chromium or Node release. NW.js is known for having the latest tech. Since NW.js is built on top of these technologies, it inherits these improvements, but also their growth in file size. So as time goes on, Chromium and Node improve, get new features, and become more secure. NW.js, to oversimplify, is a modified Chromium browser with Node.js built in. ![]() In that time I've found some tricks and best practices for optimizing for the medium of desktop apps, and I'd like to share some of these techniques today. I've been making desktop apps for over 5 years now. NW.js is not exempt from this generality. However, the easier the tooling is to use, and the more powerful it is, the larger your distribution package tends to be. There are a ton of benefits around using tools to build XPDA's (cross-platform desktop apps). ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |