I am currently about to embark on a redesign. This requires many scss changes and reloading the website. I would like to take advantage of the ng nerve command that uses live reload.
Does anyone know how I can run the ng serve and have the vendor.js file minified? When I use ng serve --prod it minifies the vendor.js... but it takes 10-15 seconds to build it.
Currently my vendor.js file is 8.9mb unminified and it's taking 2-3 seconds reach reload in development.
Anyone have ideas?
ng serve --prod while it does to minification, takes 2-3 minutes each time.
Note: Currently using Angular 6.X
I had observed the recompilation of angular projects using ng serve with Visual Studio Code. Vendor.js is not recompiled when you make changes to the project. It is only compiled during the first execution of ng serve.
If you wish to improve compile speed in development mode, you might want to consider implementing lazy loading. If lazy loading is implemented, whenever you make changes to a component, only that component's module is recompiled. This can greatly save compilation time in the long run.
This had happened to me in one of my first Angular projects (a school assignment). To cut the long story short, I had read about lazy-loading, implemented it to the admin dashboard module, but my friend refused to implement it to the user module because he would had to shift a lot of code around and restructure the project. As the project became bigger... it became evident how important lazy-loading can be...
First compilation: (I will explain a bit) manage-* modules are feature modules belonging to the admin module. Every component in the user-module: sidebar, navbar, filter, search, etc, all belongs to the user module, hence it's significantly larger, 3.46MB compared to admin and it's feature modules.
E.g. Commenting 3 lines of html in one of the component in user module recompiles the entire user-module and takes 5523ms. If I am running photoshop, or other memory intensive programs, it'd take much much longer!
E.g. Commenting 3 lines of html and recompiling a feature module in admin dashboard module takes < 1s:
I am still new to Angular but lesson learnt: do lazy-loading, it does saves user's bandwidth and your development time =]
The solution to your problem isn't exactly what you think it is, this is a common problem across all front-end frameworks and webpack builds.
Webpack provides an elegant solution to handle this. It's called hot module replacement. I.e. webpack will change your code and styles on the fly without requiring to reload the page. Angular needs a bit of customisation to set this up which is outlined step by step here.
https://github.com/angular/angular-cli/blob/master/docs/documentation/stories/configure-hmr.md
I think you are facing this issue in the wrong way.
I understand you are redesigning an angular app and using ng serve to see your work realtime in the browser, but you are suffering of slow build time as vendor.js is rebuilt on each change.
The problem is not that vendor.js is big (always is) but that is been built on each change. As other answers mentioned, changes on application code should not (usually) trigger the rebuild of vendor.js. This indicates another problem, probably you are messing something with scss imports.
Also, using ng serve --prod probably won't solve your problem at all. Build times are higher than non optimized builds and I don't think you problem was solved by minifying code (Again your problem is on the build time).
In any case, if you want to go ahead with your original question and run the ng serve and have the vendor.js file minified, you will need to create a custom webpack configuration, have a look on these sites:
https://dev.to/meltedspark/customizing-angular-cli-6-buildan-alternative-to-ng-eject-1oc4
https://angular-guru.com/blog/angular-webpack
In this last site, you can find the webpack configuration which corresponds to vendor.js
Hope this helps, I would need more details to provide a better answer.
Firstly, why do you need it so badly? Yes, vendor.js will not be minified, but it will not be re-compiled on SCSS/view-level changes either, right?
So, at the end of the exercise, the advantage you are going to receive is only about first-time loading a ~2MiB file vs an 8.9MiB file, which would be marginal since you can choose to enable the browser's BFcache (by NOT checking "Disable cache" under DevTools>Network)
If you must do it, I guess an approach would be to go with Hot Module Replacement for the Component's module you would be working on.
EDIT:
Personally, I find too many reloads for small visual HTML/CSS changes an overkill. Sometimes I "Inspect" the elements, and change the HTML/CSS via devTools and copy the HTML/CSS to a temp place. Then I make those 5-6 changes to the Components and save and reload to verify.
It's always a better practice to "Inspect" element and make the visual changes (like minor CSS style changes) and check how it looks then and there, instead of making those changes in your real code and waiting for a whole re-build cycle just to see a minor CSS change.
You can use lazy loading in your app to reduce the bundle size . It also increases the speed of the application .
Related
I am a newbie with React.js and just for practice i made a simple counter web app.
But i noticed that the project is more than 120MB.
Is it possible? do i need to do something to shrink it?
120mb can he huge or nothing at all depending on where you get that number. Remember, a modern web app (such as one built with React) needs build tools and often a development server and more. Also, if you are using typescript it will in itself add a compiler that is up towards 40mb.
So if we look at the source directory you'll have your own code plus some build configuration (probably in a webpack configuration file) which totals a few kilobytes. But then we have the node_modules folder which contains all the dependencies for both your own code and the build tools. This isn't a problem and since this folder won't be sent to the client and you shouldn't even commit it to your SCM since it can be restored from your packages.json file.
I did a quick check of the folder size in node_modules in a new dotnet-react project (because that was what I had handy) and this is what I got.
So here we can see that typescript is by far the largest dependency eating up almost 25% of my project and there are still quite a few other large dependencies as well. But this is till just for
If we on other hand look at what is actually delivered to the client that should be a completely different matter. This is what actually matters since this will directly impact the performance of your application. A large app here will be both more code to download and more code to parse for the client.
This same app looks like this when running the project for development and checking network traffic in Chrome Inspector.
So here we can see three script files, but even in development mode only about 520kb is sent to the client even though my node_modules was about 180mb.
If we then go one step further and build this for production we get an even better result.
Now we are down to just about 270kb for the scripts which is just a fraction of the size of the project folder.
So to summarize:
The size is very well possible and kinda expected when working with a modern client side framework such as React (or Angular, Vue, Ember, etc).
The development folder will be large due to all the dependencies needed to build your project.
The final output will be way smaller but in the end depends on what dependencies you decide to use in your own code.
You don't have to do anything to shrink, just make sure that you don't commit node_modules to your SCM.
Also remember that all modern frameworks comes with an overhead to set everything up and making it easy to work with. This is most of the 260kb that my test app is. So if you make a simple counter the overhead will be extreme in comparison and not all projects need a framework such as React.
I'm using Angular 5.2.2 version and when a new user hit my live application first time it take too much time; the reason behind this main.bundle.js size is too much big therefore it take more time than usual.
I applied "ng build --prod" as well as some lazy loading on few component but it didn't work.
as well as I also removed redundant components , assets etc in application but it also not work.
Can anyone suggest me what I can do
Thanks in advance
Yasir
I had the same problem because I was not using lazy loading. Lazy loading is a technique to separate the application in different modules those which are required only when the application needs them. Lazy loading Angular's official documentation.
In my case I created a module per every parent url route (e. g. /car -> create a module, /car/:id -> include it in your car module). With this strategy my loading time now is about 3s. but previously it was around 12s.
First, are sure you that slowness is caused by the main.bundle.js file? What's its size?
Lazy loaded modules should normally help, as pointed out
Independently from angular, make sure that you enable compression on your webserver (nginx or nodejs or whatever you use)
For nodejs
https://github.com/expressjs/compression
For nginx
https://www.nginx.com/resources/admin-guide/compression-and-decompression/
You can try Ahead of Time Compilation which will make your bundle size even smaller.
ng build --prod --aot
This will remove compiler code from the bundle and also any unused features like ngSwitch or ngIf is removed if not used in templates.
Currently I am utilizing the CommonsChunkPlugin to separate my vendor bundle (/node_modules/), from my main application bundle. This works great.
I was originally hoping this would mean that if a change is made to my application code, a 're-packing' would be faster as the vendor bundle is separate and would not re-pack (and rarely changing).
It looks like a change to my application code also creates a new vendor bundle (when I am using watch mode or the dev server). Is there a way to configure things to be smart and detect only application bundle changes were made and not re-pack the vendor bundle?
Please have a look at the configuration in here. Try it out and see if thats what you intend to achieve.
Honestly, there is not much i had to think through. Its very well documented here.
I am learning React and I'm running it using create-react-app, which allows me to edit text in a file named App.js and as I save any changes in that file, the webpage with the address http://localhost:3000/ in browser automatically updates without reloading. Normally, while making html/plain js files, i need to reload the page. So how does it dynamically update itself?
There is a concept of Hot Reloading. The idea behind hot reloading is to keep the app running and to inject new versions of the files that you edited at runtime. It leverages HMR and without reloading the page, replaces changed components in-place, preserving state. That means that, your change will be visible in about half a second; if it was a dialog, you wouldn't need to re-open it, your text inputs remain filled, etc. In short, it's a massive boon to iterative development where you spend much less time waiting for your app to reload. You can find more details here
The cli which you are using uses webpack to achieve this. Webpack is a module bundler it creates a bundle file from all your js/ts/jsx/tsx files which you embed into your index.html file.To achieve live reloading webpack uses webpack-dev-server(a small node.js express server).You can cofigure your webpack to watch for changes on your file and webpack will update your bundle file whenever your code is changed. You can learn more about how it does here.
All the configurations for webpack are written in webpack.config file.You can learn more about webpack here.You can also follow this link
This is actually not a standalone thing.
This happen because react use webpack dev server which reload package if you make any changes.
As if you want to do same , you need to setup a local server and always make editing in same server.
browserSync is also a option but you need to use nodejs then
This may be a dumb question for web guys. But I am a little confused over this. Now, I have an application where I am using a couple of Javascript files to perform different tasks. Now, I am using Javascript bundler to combine and minify all the files. So, at runtime there will be only one app.min.js file. Now, Requirejs is used to load modules or files at runtime. So, the question is if I already have all things in one file, then do I need requirejs? Or what is a use case scenario where I can use requirejs and/or bundler?
Please let me know if any further details are needed.
Generally you only use RequireJS in its loading form during development. Once the site is done and ready for deployment, you minify the code. The advantage here is RequireJS knows exactly what your dependencies are, and thus can easily minify the code in the correct order. Here is what it says on the RequireJS website:
Once you are finished doing development and want to deploy your code for your end users, you can use the optimizer to combine the JavaScript files together and minify it. In the example above, it can combine main.js and helper/util.js into one file and minify the result.
This is a hotly contested issue among many proficient javascript developers. Many other languages have a "compilation" phase where the entire program is bundled up for deployment (JBoss's .WAR files come to mind). Programmers that come from more traditional backgrounds often favor this approach.
Javascript has seen such growth in recent years that it is difficult to chart exact best practices, but those that appreciate the more functional nature of Javascript often prefer the module loading approach (like require.js uses).
I wrote Frame.js which works much like require.js, so my bias is towards the module loader approach.
To answer your question directly, yes, it is one or the other.
Most that argue for packing your scripts into a single file believe it enables more compression and is thus more efficient. I believe the efficiency advantages of packaging are negligible in most cases because: (1) module load times are distributed over the entire session, (2) individual modules can be compressed to nearly the same percentage, (3) individual modules can be cached by the server and routers separately, and (4) loading scripts only when they are needed ultimately allows you load less code for some users and more code overall.
In the long run, if you can see an advantage to dynamic script loading use it. If not, bundle your scripts into a single file.
It depends on your application. If you're making a server-side app with only modest javascript (less than 100kb minified) then go for total bundling, you're probably going to be fine.
But if you're making a javascript app and have a ton of code in it, then your needs are going to be different.
For example, in my app I bundle all the core files. There's jQuery, underscore, backbone, my main app files, my user login system, my layout system, my notifications and chat system, all are part of my big initial file.
But I have many other modules as well that isn't part of the initial bundle, that are loaded after those.
The forums, the wiki, the wysiwyg, color picker, drag/drop, calendar, and some animation files are part of the second category. You need to make reasonable decisions about what's commonly used and needed immediately vs what can be delayed.
If I include everything immediately I can get above a meg of javascript, which would be insane and make the initial boot unacceptably slow.
The second category starts downloading after initSuccess event fires from the initial file.
But the second category is more intelligent than the first in that it loads what's more important first. For example if you're looking at the wiki it'll load the wiki before it loads the color picker.