i can't find any definitive answer on the boilerplate docs, but can someone clarify the difference between plugins.js, and script.js? i'm a javascript newbie, and am tempted to just put all my scripts in one file... is there a good reason not to do this?
From the FAQ:
Script.js should hold your primary application script. It might make sense to store it in an object literal and execute it based on body classes.
Plugins I use for jQuery plugins and other 3rd party scripts myself. I put the jQuery plugins inside of the (function($){ ... })(jQuery); closure to make sure they're in the jQuery namespace safety blanket, especially if they were written by more amateur developers. See also jQuery Plugin Authoring.
in plugins.js file you get few helpers bundled, it's probably meant to include stuff you won't modify at all (or at least not so often), while script.js is a file ready for your... yes, scripts. ;)
what you said is true - in production, it's usually better to serve the browser one file instead of many. however in development it's easier to keep things separated.
that's the reason why boilerplate comes with a build script, which combines all your scripts into one so you don't have to worry about this.
in scripts -> your custom scripts
in plugings -> don't touch it!
In build process both files unite into one unique and compressed file...
Related
I'm building a project in javascript, using paper.js in some features.
Most of my project is built in vanilla Javascript, just some minimum but important features are built with paper.js
The problem is that the library (.min library) is 200kb.
The normal library is 300kb, I was wondering if there is an automatic way to see which functions are being used in the main paper.js library, in order to delete the useless functions.
If there is no program or automatic way to do this, maybe some advice of how to do it manually, or which tools you recommend for me and my team in order to delete useless functions, then minify the file and run it smaller.
Thank you all guys, I did not added any specific code because I want this anwser to be global.
Greetings
You have to do it manually but it's not an easy (and certainly not quick) process. You'll have to find which functions you're using and then find whatever classes or functions those functions reference. You would probably have an easier time creating a new script then copy/pasting what you're using (and any referenced content) then running it with your script, log errors, and repeat.
When you're done there's many minify libraries and services online you can use to minify the new script.
I used the paper-core version and then minified.
I saved 140kb by doing this.
There's still no way to see useless functions in this library
I am using requirejs so that I don't have every single script in the head tag for every page. The main motive behind switching to use requirejs is that we have plugins such as CodeMirror, with like 15 plugins to extend that too.
What I want to avoid is having for example:
require(["cm", "cmxml", "cmcss", "cmcodefold", "cmfoldgutter", "cmbracefold", "cmcommentfold" ....], fn);
I'd like to have this as just require(["cm"], fn); and automatically include all of the plugins with this. I'd also like to keep the plugins separate, so combining all the files into CodeMirror.js is not an option.
What I am wondering, before I go creating my own functions or modifying 3rd party code for this, is whether requirejs allows this kind of loading in any case? I have looked at the docs a lot and can't find anything, but that doesn't mean I haven't missed it or that it isn't documented. Thanks in advance.
Well I've managed to get this working using a shim for a script called cminit.js - the deps array simply lists all of the plugins for CodeMirror, which in turn have a dependency on CodeMirror which in turn has a dependency on jQuery. So one call to require for cminit.js automagically means that jQuery exists.
It works, but I'm not sure how much of this is best practice. Feel free to comment if you have a better way to do this.
I'm wondering if I can use CoffeeScript to include other standard JS files (as a simple way to do some combining of files).
I have a client-side minification tool I'm using (an app called Live Reload) which is working just fine.
<!-- Some jQuery plugins I'm using. -->
<script src="/js/libs/some-plugin.js"></script>
<script src="/js/libs/another-plugin.js"></script>
<!-- The output of my /js/script.coffee file: -->
<script src="/js/script.js"></script>
What I'd like to do, is just combine those plugins into output of my coffeescript file. I've looked high and low and I've only seen articles on server methods for this as well as a lot of articles on things like requirejs.org. I'm not trying to do anything that complex- I just want to get rid of a couple round trips for js files I know I'm never going to touch.
Does CoffeeScript have an "include" function to speak of?
There are ways you can achieve this by creating a more complex Cakefile, in which you will read the contents of js-files and append them with CS compiler output than write it into the single target js file. You can even create a fake global require function which will mimic its behaviour in the bundled file.
If you were looking for a standard tool or at least an approach to that problem, unfortunately, since CS is very young, there's none yet. There are some attempts though: https://github.com/jashkenas/coffeescript/wiki/%5BIntegrations%5D-Build-Tools.
I'm currently working on such a tool myself and am planning to publish it within a month. I'll post back then.
Basically, the answer seems to be no. This is not something CoffeeScript is capable of.
I have some javascript files that I want to live independently of each other. Each of these files reference other files for some library functionality.
Finally, there are times when all of this code can be used at the same time. I know that referencing a javascript file is not equivalent to a c++ include or java import. Is there a way to achieve that kind of behavior?
For performance reasons you probably should concatenate them all into one. Compress that one using Google Closure and then serve it as a single and cacheable file.
I don't know about any native interface specification in Javascript. You "only" need to make sure the things you reference/access are already loaded. This may become messy if there are lots of dependencies.
That's why big JS-frameworks have some code for module loading and dependency specification.
Libraries I would name here are head.js and RequireJS.
But think what size of tool you really need.
When building a jQuery plugin, do you think it's bad practice to embed the source of another plugin or library that it depends on?
It seems to me that it's a better way to go than requiring users to do multiple <script src="..."> calls or compressing the multiple source files themselves.
I would stay away from embedded in most cases, especially if you're depending on another jQuery plugin. Some cases to consider:
What if I'm already using that plugin, a newer version, an older one?
At best you're adding the download weight twice, possibly a different version
At worst you're breaking my code :)
What if I'm trying to debug, is a bug in your plugin?, the other?, still yours because you included it?
Which author do I contact?
There are few upsides to this besides saving a few <script> tags, which should be cached on the client anyway...and in my case as well as many others (like SO) the scripts get compressed into one or a few requests.
Most jQuery plugins require dependencies to be added with their own <script> tags, in this case by not going with what most do serves more to confuse or complicate rather than save time. Personally, I'd stay away from the embedding, but to each their own.
Personally, as a potential plugin user, I'd prefer the multiple <script src='...'> way. First, it gives me more flexibility and control and second, if I already have some of the plugins in my own code, having them in your plugin as well means they'll be included twice.
Imagine what would happen if every plugin author included all dependencies in the source. What you think is convenient now will turn out to be a maintenance nightmare later.