On my current project we have our gulp build process dropping our Angular application to two Javascript files; one for anything in the app (things we wrote), and one for vendor files (basically anything brought in; e.g. bower included).
Recently a request came from a more abstract influence on the project to consolidate the app.js and vendor.js (and CSS equivalents) into one file to reduce HTTP requests.
Now, I don't really have a lot of experience with gulp, but our original implementation was setup for the two files. My question is: is there actual benefit in consolidating the two, or is there a technical or practical reason for them to be separate? Perhaps this was the way the initial (probably Yeoman) scaffold laid them out, and if so, is there an architectural reason?
Thanks much in advance for any and all advice or experiences you can provide.
Gulp will have no trouble compiling your vendor and app code into a single file. The benefit of this is it would reduce the number of requests your browser needs to make to a single script request.
However, two files are often used to make it more obvious where errors are coming from if they occur. It also means that compiling your app code is faster since it doesn't need to re-compile the vendor code whenever your app code changes. Typically, the vendor code is more stable so it shouldn't need frequent compiling (or even watching).
Additionally, with the advent of HTTP2 and its ability to do multiplex downloads, concatenating your code into one large file is a worse option. This is because even a small change results in the entire concatenated blob needing to be re-downloaded.
Related
I'm sorry if this question has been asked before, but I couldn't find a solid answer.
In essence, I'm building quite a large application in React that has loads of components and javascript files. The manager is pretty much pressing us to use Webpack, which I'm just starting to get my feet wet with right now.
So I suppose the question is, why go through the trouble of bundling loads and loads of already neatly separated javascript files to a few single massive files?
This is more of a larger architecture related QandA it seems.
But in essence, bundling is great if
1) you have complex folder structure where each module is separate file
2) want to deliver only one file to optimize http requests and cache
3) if you utilize some sort of module export syntax.
4) With webpack you can also do hotreloading of JS and CSS with dev server, very neat.
5) also can plug in transpiler and use ES6
The main reason is it's a lot faster to load 1 single file. Let's assume you don't compress the concatenated single file at all, there's still overhead in setting up http connections, as well as maximum concurrent request limitations that prevent simultaneous downloading.
Another reason is that allows a compressor to parse an entire file. Assuming you compress each file in isolation, you could (possibly) run into naming collision issues.
You definitely want to compress your file because you'll be sending less bytes over the wire. Since you'll already need to do some post-processing of your files, compressing isn't much extra.
I've been using a grunt file to concatenate all my JS into a single file which is then sent to the client. What advantage do I have in using require calls then? The dependencies are inherent from the concatenation order and I don't have to muddy all my JS with extra code and another third-party library.
Further, backbone models (for example) clearly state their inheritance in their definitions. Not to mention that they simply wouldn't work if their dependencies weren't included anyway.
Also, wouldn't maintenance be easier if all comments related to dependencies were in one place (the grunt file) to prevent human error and having to open every JS file to understand its dependencies?
EDIT
My (ordered) file list looks something like:
....
files: [
"js/somelib.js",
"js/somelib2.js",
"js/somelib3.js",
"js/models.js",
"js/views.js",
"js/controllers.js",
"js/main.js"
], ...
So perhaps requireJS isn't worth it for small projects anyway.
Using require.js allow you to break down each part of your application into reusable modules (AMD) and to manage those dependencies easily. It is not easy to manage dependencies in a javascript application with 100 classes, for example.
Also, if you don't want all the overhead of require, check this out (developed by the same guy who created require.js): https://github.com/jrburke/almond
The answer depends on the size of your app and the end use case..
A single site.min.js payload for the front end (client) generally aims for small file sizes and simple architectures (1 single file generated from maybe 10).
back end based (server) apps are usually much bigger and complicated and therefore may warrant the use of another tool to help with managing large code libraries and dependencies (50 files for example).
In general, RequireJS is worthwhile but only if you have many files and dependencies. An alternative for use in the client would be almond. Again, using a tool like this must warrant the need (many files and dependencies).
The answer from orourkedd is also worth reading.
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.
I am looking for a JS minimization (maybe CSS as well) tool to use in our website. The site is fairly big and we cant manually minify files individually. We are also planning to use Long term caching for files and need to append like a version number to each file. I am afraid that this is very hard to keep track of when publishing frequently.
I know of tools like YUI Compressor, etc.. is there, but I am not sure how they are used for a big project like I have. Technically, I am looking for a script or an app that can be called after our development is finished to utilize it with the minified versions of files.
What are the common practices big companies use/follow these days ?? Any help is appreciated. I am just not sure what to search for.
Thank you.
I advise you to use a kind of makefile toolchain (there are many, for example ant or maven) to :
concatenate your js files in one file
then minify the resulting files (I use Google Closure Compiler, called with an ant target)
Note that making one file is the most important operation as on modern networks the latency due to the number of requests is much more a burden than the total size. This way you can easily work with dozens or hundreds of js (or css) files and don't hesitate to make a new one as soon as it helps the code source being readable and maintainable.
And this eliminates the need for the (manual or not) management of visible versionning of files for caching reasons.
As said recently in another answer, to help debug, my deployement scripts always make two versions in parallel : one non concatenated/minified and one concatenated/minified. The uncompressed version enables the development/test onsite without any deployement operation.
When dealing with websites with large amount of javascript, i see that these are still usually served to the client as one large javascript file.
In the development phase, are the javascript files usually split up (say there are >300 lines of js) to make things abit more manageable, and then merged when the website is 'put live'? Or do the developers just put up with working in one long large file?
We place different modules/classes/parts in separate files and use a proper build process to
validate the code using eg. jslint
concatenate
instrument (replace, wrap etc)
minify
An example of how to use Ant for this can be found in one of my projects here
http://github.com/oyvindkinsey/easyXDM/blob/master/build.xml.
I also have projects where the webserver automatically merges the files, localizes and then minifies them before serving the client.
So stick with whats manageable, using separate files, but do remember that if you use error reporting then the line numbers will point to the concatenated version.
In my experience — having separate files in development is the norm. It certainly makes life easier when you need to hunt for code or have multiple people working on different parts of the system.
It would be ideal to have multiple javascript files depending on the class and functionality (like you have them for java project ) in development environment.
However when you are deploying the js file in production, you should concatenate all js file in a single file and have them referred by your web application. That will make thing easy
Note: It would also be advisable to use javascript compressor to reduce the actual size and hence saving bandwidth.
Developement differs from company to company and from developer team to developer team.
I for myself am used to the approach of implementing functionality step by step, storing those functionalities in seperate files and merging everything together in most cases - at lease when i am not the only one working on a given project.