I'm using React and bundle with Webpack to create my web application.
My simple question is:
My bundling file is only about ~4.5mb, but my overall repo is ~20mb because of pictures and other assets. My question is does the performance(first opening up pages) of application only affected by my bundle size? or the whole repo?
And Also, what's considered an TOO large of repo or bundling? for average enterprise production application?
What your production app will probably use is what you generate inside the build directory. Sometimes this is only a bundle.js file (the images and styles will be inside), other times you can split the bundle.js file's images and styles in different files, so you would have to include that. It all depends on your setup.
4.5mb is not too much, although it will depend on your server performance too. It is completely normal if it contains all the dependencies. If you need to load some pages faster than the rest, you can split the bundle in multiple files so some parts of your app will not require all the bundle files. This is called code-splitting. You read more about it here.
Normally you will want some simple landing pages to load faster, and it would depend if your website is the mainly used by mobile phones (worse network connections) or laptops (normally using Wifi).
Related
My minified bundle size is 246kb. I am seeing if I can getting smaller and I read that extracting vue and jquery using mix.extract(['vue', 'jquery']); can help do this. I added this to webpack.mix.js` and now it created 2 files rather than 1. It made: 1) app.js which is 161kb and 2) vendor.js which is 180kb. What is the benefit of this if both need to be included in the page anyways?
This is mainly abut caching unchanged files. For example: while you developing app you are changing the files, adding your own code to your project and then recompile them all together. But vendors are the core libraries which you are never edit their code again. So there is no need to compile them again and download all source code in app.js file. Thus when you extract vendors which they are unchanged files then your cached content size will increase and it also decrease download time of your application because of less changed files must be downloaded again.
It helps you to optimize the file size of the files that client needed to download. Thus speed up the page loading speed even you have updated your site.
Check the documentation.
One potential downside to bundling all application-specific JavaScript with your vendor libraries is that it makes long-term caching more difficult. For example, a single update to your application code will force the browser to re-download all of your vendor libraries even if they haven't changed.
I'm currently developing a react application using jspm/systemjs.
I've been looking for a way to bundle assets inside of an bundle-sfx (build) file.
I have some images, fonts and potentially svg to add into my application. Currently the build file link those by urls into my sources.
But my goal is to be able to provide a single file to load in the html, which also bundle those assets; or at least package all those assets into a common folder from which I could serve as is.
For now I'm using systemjs/plugin-css, which concatenates all the css into a minified file.
I've looked at those plugins: vuzonp/systemjs-plugin-svg, systemjs/plugin-image, and systemjs/system-font.
But from what i read from that thread, it is not easily doable nor even possible at the moment.
Does anyone know how to do that, or could point me at the right direction ?
Does a plugin exist which would handle assets as undiscriminated files ?
Do I have to process each kind (mime-type) of file differently ?
Fine uploader is 400kb of javascript code and 140kb minified. Since I am not using the UI and only using the API, I would like to build the library without the integrated interface (and hopefully get a smaller lib consequently). Is this possible?
Could not find this in the downloads section.
I've also setup the build environment and built the package myself, but all the files in the _dist dir seem to be bundled with the UI.
Fine Uploader is only 40 kB gzipped, which is compression that pretty much every web server already utilizes. The build is not currently setup to create a bundle without the UI. If you'd like to create such a build, the modules.js file will need to be modified. One place to start would be with a copy of the fuTraditional module sans the #fuSrcUi module. Then, a corresponding entry would need to be added to the concat.js build file. This doesn't seem worth it to save a few kB in my humble opinion, but it's all very possible.
If you're interested in a much more modular upload library where almost every feature is represented as an optional standalone module, take a look at Modern Uploader, which I am slowly developing as time allows. Feel free to open up issues in the repo if you have any questions regarding the future of that product.
Right now, I’m working on a legacy web application that is made up of multiple screens, each one performing a separate function. I’m in the process of converting several of the screens to EXTJS 4 using the MVC approach. In order to isolate the impact of my changes and because we don’t have time to convert the entire app at once, I’ve converted two of the screens into two separate EXTJS 4 apps. Each screen now has its own folder in which I’ve set up an app using the appropriate file structure and app.js file.
My question is this: as I continue developing, I may want to use models from one app (screen) in another app. How do you share models, views and controllers between applications? What’s the best approach?
FYI, I’m using autoloading to pull everything in.
Thanks
I would not use autoload in production, because it generates to many HTTP requests to get all files, which slows down the page load speed. This is well documented at Google's Page Speed and Yahoo's Best Practices for Speeding Up Your Web Site.
The best practice is to preprocess the resources upon deployment of the application and generate a single javascript file with everything in it that is sent in a single (GZIP) compressed response. There are several tools for this job, but it depends heavily on your toolchain. You can for example have a look a the SO question Best JavaScript compressor to get recommendations for various compressors (I use Jammit).
When you have a flexible configurable JavaScript compressor in your toolchain, you can set up a shared folder where you have your common files, like model, stores and some libs. These are now included in the builds for the different projects.
In case you have a good reason to serve single javascript files, you can either use a good version controll system like git and make use of submodules. Which this approach you'll have a separate repository for common files. This gives you the downside of slower page speed and a little overhead with updating the submodules.
As last solution, you can use a symbolic link on the file system to link the common folder to the different other projects.
Here's what Saki said to me on the Sencha Forums:
The multiple applications on one page, or sub-applications of Ext MVC
are not supported yet, however, developers are working on this
functionality, AFAIK. Such implementation would most likely solve also
the problem of re-using models, views and controllers among (sub)
applications, I hope.
More specifically regarding linking multiple applications:
I would just soft-link files of MVC components is this case. There's
no logical or functional connection among them now, only I wanna reuse
already written file, right?
Hi everyone
I would like to know if it's possible to deploy my app assets directly to Isolated Storage once the app get deployed.
I'm currently extracting them from code but this make the app's first launch too slow and it will be declined once it's submitted to the marketplace.
I'm wondering if there is a nice trick to make the process faster
Thanks
There's no way to automatically deploy to IsolatedStorage on app installation.
There are a few things you can do to try and avoid a delay on first start up though:
Refer to files directly in the XAP where possible.
Split the assets into multiple dlls so that only those needed are loaded into memory.
Load content to IS in the background and prioritize this so that the resources are loaded as needed.
You should not need to load image or video files into IS just to view them.
You should only need to copy the XML files if they're going to be updated. If you just want to read some data this doesn't need to be done. Also, if the XML files just hold initial data/state this could be loaded from the assembly directed and only saved to IS when first persisted.