I don't understand WHY and in what scenario this would be used..
My current web setup consists of lots of components, which are just functions or factory functions, each in their own file, and each function "rides" the app namespace, like : app.component.breadcrumbs = function(){... and so on.
Then GULP just combines all the files, and I end up with a single file, so a page controller (each "page" has a controller which loads the components the page needs) can just load it's components, like: app.component.breadcrumbs(data).
All the components can be easily accessed on demand, and the single javascript file is well cached and everything. This way of work seems extremely good, never saw any problem with this way of work. of course, this can (and is) be scaled nicely.
So how are ES6 imports for functions any better than what I described?
what's the deal with importing functions instead of just attaching them to the App's namespace? it makes much more sense for them to be "attached".
Files structure
/dist/app.js // web app namespace and so on
/dist/components/breadcrumbs.js // some component
/dist/components/header.js // some component
/dist/components/sidemenu.js // some component
/dist/pages/homepage.js // home page controller
// GULP concat all above to
/js/app.js // this file is what is downloaded
Then inside homepage.js it can look like this:
app.routes.homepage = function(){
"use strict";
var DOM = { page : $('#page') };
// append whatever components I want to this page
DOM.page.append(
app.component.header(),
app.component.sidemenu(),
app.component.breadcrumbs({a:1, b:2, c:3})
)
};
This is an extremely simplified code example but you get the point
Answers to this are probably a little subjective, but I'm going to do my best.
At the end of the day, both methods allow support creating a namespace for a piece of functionality so that it does not conflict with other things. Both work, but in my view, modules, ES6 or any other, provide a few extra benefits.
Explicit dependencies
Your example seems very bias toward a "load everything" approach, but you'll generally find that to be uncommon. If your components/header.js needs to use components/breadcrumbs.js, assumptions must be made. Has that file been bundled into the overall JS file? You have no way of knowing. You're two options are
Load everything
Maintain a file somewhere that explicitly lists what needs to be loaded.
The first option is easy and in the short term is probably fine. The second is complicated for maintainability because it would be maintained as an external list, it would be very easy to stop needing one of your component file but forget to remove it.
It also means that you are essentially defining your own syntax for dependencies when again, one has now been defined in the language/community.
What happens when you want to start splitting your application into pieces? Say you have an application that is a single large file that drives 5 pages on your site, because they started out simple and it wasn't big enough to matter. Now the application has grown and should be served with a separate JS file per-page. You have now lost the ability to use option #1, and some poor soul would need to build this new list of dependencies for each end file.
What if you start using a file in a new places? How do you know which JS target files actually need it? What if you have twenty target files?
What if you have a library of components that are used across your whole company, and one of they starts relying on something new? How would that information be propagated to any number of the developers using these?
Modules allow you to know with 100% certainty what is used where, with automated tooling. You only need to package the files you actually use.
Ordering
Related to dependency listing is dependency ordering. If your library needs to create a special subclass of your header.js component, you are no longer only accessing app.component.header() from app.routes.homepage(), which would presumable be running at DOMContentLoaded. Instead you need to access it during the initial application execution. Simple concatenation offers no guarantees that it will have run yet. If you are concatenating alphabetically and your new things is app.component.blueHeader() then it would fail.
This applies to anything that you might want to do immediately at execution time. If you have a module that immediately looks at the page when it runs, or sends an AJAX request or anything, what if it depends on some library to do that?
This is another argument agains #1 (Load everything) so you start having to maintain a list again. That list is again going to be a custom things you'll have come up with instead of a standardized system.
How do you train new employees to use all of this custom stuff you've built?
Modules execute files in order based on their dependencies, so you know for sure that the stuff you depend on will have executed and will be available.
Scoping
Your solution treats everything as a standard script file. That's fine, but it means that you need to be extremely careful to not accidentally create global variables by placing them in the top-level scope of a file. This can be solved by manually adding (function(){ ... })(); around file content, but again, it's one more things you need to know to do instead of having it provided for you by the language.
Conflicts
app.component.* is something you've chosen, but there is nothing special about it, and it is global. What if you wanted to pull in a new library from Github for instance, and it also used that same name? Do you refactor your whole application to avoid conflicts?
What if you need to load two versions of a library? That has obvious downsides if it's big, but there are plenty of cases where you'll still want to trade big for non-functional. If you rely on a global object, it is now up to that library to make sure it also exposes an API like jQuery's noConflict. What if it doesn't? Do you have to add it yourself?
Encouraging smaller modules
This one may be more debatable, but I've certainly observed it within my own codebase. With modules, and the lack of boilerplate necessary to write modular code with them, developers are encouraged to look closely on how things get grouped. It is very easy to end up making "utils" files that are giant bags of functions thousands of lines long because it is easier to add to an existing file that it is to make a new one.
Dependency webs
Having explicit imports and exports makes it very clear what depends on what, which is great, but the side-effect of that is that it is much easier to think critically about dependencies. If you have a giant file with 100 helper functions, that means that if any one of those helpers needs to depend on something from another file, it needs to be loaded, even if nothing is ever using that helper function at the moment. This can easily lead to a large web of unclear dependencies, and being aware of dependencies is a huge step toward thwarting that.
Standardization
There is a lot to be said for standardization. The JavaScript community has moved heavily in the direction of reusable modules. This means that if you hope into a new codebase, you don't need to start off by figuring out how things relate to eachother. Your first step, at least in the long run, won't be to wonder whether something is AMD, CommonJS, System.register or what. By having a syntax in the language, it's one less decision to have to make.
The long and short of it is, modules offer a standard way for code to interoperate, whether that be your own code, or third-party code.
Your current process is to concatenate everything always into a single large file, only ever execute things after the whole file has loaded and you have 100% control over all code that you are executing, then you've essentially defined your own module specification based on your own assumptions about your specific codebase. That is totally fine, and no-one is forcing you to change that.
No such assumptions can be made for the general case of JavaScript code however. It is precisely the objective of modules to provide a standard in such a way as to not break existing code, but to also provide the community with a way forward. What modules offer is another approach to that, which is one that is standardized, and one that offers clearer paths for interoperability between your own code and third-party code.
Related
Thanks to this post I've become aware, for modules (not regular scripts & without async attribute) that import/export (from each other), one of the only simple rules that determines the order in which they're executed is that a module that imports from another module will not execute before the module it imports from.
I'm worried we can't always control the complete order in which modules execute (I've put some examples of this at the bottom of the post). For example, what if I want a timeout to start as soon as the page is loaded? Is it okay for a setTimeout to occur on a module (at the end of a very long list of modules) as the time to execute the initial modules will be negligible?
P.s. Am I safe to assume modules that don't import or export (from each other) always execute in the order they appear in?
Examples: ModuleA imports from ModuleB. ModuleC imports from ModuleD. Only rule is that D or B executes first (sometimes DB or BD executes first; sometimes DC or BA executes first).
I personally find that assuming something will happen before something else without enforcing that explicitly will result in a dangerous situation. Even if your modules would always execute in the correct order, you have created an implicit dependency between two modules that will make the code more difficult understand.
Will another developer working on your project be able to understand that certain modules need to execute first? Will you remember this when you revisit this code a few months down the line? What about when you leave the project and someone else inherits it?
Working on code like this can create spaghetti situations where making a change in one place creates cascading changes in other, unexpected places.
Alleviating this can really depend on what framework you're using, or if you're not using any framework at all. If you need certain dependencies loaded before executing certain code, use a dependency loader to ensure that dependencies are always available when they are needed. If you need a certain function to be executed before executing a function in a different module, create an event system. Redux/flux and Ngrx are really nice solutions for situations like this.
I'm working within a Javascript + BackboneJS (an MVC framework) + RequireJS framework, but this question is somewhat OO generic.
Let me start by explaining that in Backbone, your Views are a mix of traditional Views and Controllers, and your HTML Templates are the traditional MVC Views
Been racking my head about this for a while and I'm not sure what the right/pragmatic approach should be.
I have a User object that contains user preferences (like unit system, language selection, anything else) that a lot of code depends on.
Some of my Views do most of the work without the use of templates (by using 3rd party libs, like Mapping and Graphing libs), and as such they have a dependency on the User object to take care of unit conversion, for example. I'm currently using RequireJS to manage that dependency without breaking encapsulation too much.
Some of my Views do very little work themselves, and only pass on Model data to my templating engine / templates, which do the work and DO have a dependency on the User object, again, for things like units conversion. The only way to pass this dependency into the template is by injecting it into the Model, and passing the model into the template engine.
My question is, how to best handle such a widely needed dependency?
- Create an App-wide reference/global object that is accessible everywhere? (YUK)
- Use RequireJS managed dependencies, even though it's generally only recommended to use managed dependency loading for class/object definitions rather than concrete objects.
- Or, only ever use dependency injection, and manually pass that dependency into everything that needs it?
From a purely technical point of view, I would argue that commutable globals (globals that may change), especially in javascript, are dangerous and wrong. Especially since javascript is full of parts of code that get executed asynchronously. Consider the following code:
window.loggedinuser = Users.get("Paul");
addSomeStuffToLoggedinUser();
window.loggedinuser = Users.get("Sam");
doSomeOtherStuffToLoggedinUser();
Now if addSomeStuffToLoggedinUser() executes asynchronously somewhere (e.g. it does an ajax call, and then another ajax call when the first one finishes), it may very well be adding stuff to the new loggedinuser ("Sam"), by the time it gets to the second ajax call. Clearly not what you want.
Having said that, I'm even less of a supporter of having some user object that we hand around all the time from function to function, ad infinitum.
Personally, having to choose between these two evils, I would choose a global scope for things that "very rarely change" --- unless perhaps I was building a nuclear powerstation or something. So, I tend to make the logged in user available globally in my app, taking the risk that if somehow for some reason some call runs very late, and I have a situation where one user logs out and directly the other one logs in, something strange may happen. (then again, if a meteor crashes into the datacenter that hosts my app, something strange may happen as well... I'm not protecting against that either). Actually a possible solution would be to reload the whole app as soon as someone logs out.
So, I guess it all depends on your app. One thing that makes it better (and makes you feel like you're still getting some OO karma points) is to hide your data in some namespaced singleton:
var myuser = MyApp.domain.LoggedinDomain.getLoggedinUser();
doSomethingCoolWith(myuser);
in stead of
doSomethingCoolWith(window.loggedinuser);
although it's pretty much the same thing in the end...
I think you already answered your own question, you just want someone else to say it for you : ) Use DI, but you aren't really "manually" passing that dependency into everything since you need to reference it to use it anyways.
Considering the TDD approach, how would you test this? DI is best for a new project, but JS gives you flexible options to deal with concrete global dependencies when testing, ie: context construction. Going way back, Yahoo laid out a module pattern where all modules were loosely coupled and not dependent on each other, but that it was ok to have global context. That global context can make your app construction more pragmatic for things that are constantly reused. Its just that you need to apply that judiciously/sparingly and there need be very strong cases for those things being dynamic.
Let's say I have a rails app with a resource - User. I have javascript that should be available for any page that is served. I have javascript that should be available for any page that is served under User. And I have javascript that should be available for each specific action under User. In Rails 3.1 and higher, is there an easy way to make sure that my Javascript is only available to the pages that require it? What about coffeescript?
I think the linked item from Bob is relevant (there's a comment relating to trade-off of performance to number of files loaded), but I saw the question as being more about name spacing, scoping and structure.
To specifically answer the question (and assuming you're using jQuery), consider the following CoffeeScript:
$ ->
doSomething()
doSomethingElse("#some-element")
doSomething = ->
alert("I'm doing something")
doSomethingElse = (selector) ->
alert("I'm hiding something")
$(selector).hide()
The CoffeeScript compiler will wrap all of this within an anonymous function, and thus will only be available within a context from which the page is loaded (a script tag, or a controller-specific file, or the application.js for global visibility).
There are a couple of models to consider. A straightforward one is to follow the pattern of having "things" that are specific to a model, and those that are generally useful (global). So if I want a javascript function that's specific to User, then it goes in app/assets/javascripts/users.js.coffee, otherwise it needs to be global (in application.js.coffee).
A much more complete and complex solution is suggested by the rails-backbone gem, which has generators that create CoffeeScript models, views, templates and routers that replace a lot of what we would get with regular rails generate scaffold foo -- the same kinds of CRUD operations are done in an entirely different way, and the templates (embedded javascript) in particular are quite similar to ERB templates. This is more of a leap of faith, for me.
Whether in an application-wide file, or a controller-specific one or ones, in either case, the Asset Pipeline will glom all of the code together and send it all to the user (assuming you retain the default configuration), but that's a separate topic.
Not sure if this answers the question, you had, but I think it's important to distinguish between the delivery of assets, which Asset Pipeline does, and the execution of javascript, which is a matter of scoping, something CoffeeScript does a very nice job of, and which backbone.js takes even further.
Apologies if this is a silly question, and I'm not even sure of the best way of wording it...
At the moment I have a site with maybe 20+ different uses of jQuery, all varying from page to page. I'm just wondering what the best way is to store this code?
Everything in one big jquery.myfunctions.js file? And check if the element exists for each statement?
Embed script tags into each individual page?
Use PHP to deliver different content into script tags kinda like the above?
Separate .js files per page? ims I don't like the sound of this at all
To be honest, I'm not even sure if jQuery does this for you, so it's okay to have multiple $('#whatever').function() loaded onto each page without any noticeable performance issues?
Any advice on this would be fantastic, probably a silly question but I want to do things the 'proper' way you know?
Thanks :-)
Personnally I like to have one file with all the things needed in it. It's better because once loaded, the browser can cache it and you don't care anymore.
As for coding, I may write pieces of code in different files, which I build as a single file for production.
This way, all your code is accessible anytime.
Nevertheless, you may include tags in your views/templates, so that you can trigger certain functions only on particular views/pages.
For example :
myObject = {
myFunctionForArticles : function(){ $('.article').each(...); },
myFunctionForCategories : function(){ ... }
};
And within the Article view :
<script type="text/javascript">
myObject.myFunctionForArticles();
</script>
Make sure your included javascript keeps very thin and general though. More than one liners calling a general function can lead to trouble. In theory it is not something you might call a best-practise. Choose what you feel is the right balance between tidyness and easiness to maintain (if you have few views, maybe you can make, along with the one big file containing all the heavy stuff, some short and specific js files, which are called only by the right view to trigger the right functions at load time ; if you have a lot of views, maybe including one-liner inline js tags will save you the burden to maintain a lot of short files).
I've recently grappled with this problem when re-starting development of a very involved web app. I decided on several patterns:
do not put inline javascript on pages in general - it prevents caching and defeats the point of separating functionality from presentation
create your own namespace - I like the DOD approach to it (http://www.dustindiaz.com/namespace-your-javascript/) So, my namespace is DG, thus all of my code is part of a single global variable called DG - which is an object, containing all of the subclasses
Create a class prototype structure, where if you're doing common things with a bit of difference between implementations
for example, logging into different sites - you're doing logins, but, some may do it differently than others - so, create a prototype class than handles generic functionality, and then implement site-specific login functionality in classes that inherit from the prototype)
Use the Yahoo Module pattern for singletons, but don't fall in love with it - it's not useful if you have more than one instance per page of a class (http://www.yuiblog.com/blog/2007/06/12/module-pattern/)
use a require/import function to do dynamic imports of javascript
this one is an optional but great. I really like doing dependencies for javascript, so I don't have to include a ton of script tags in my code, and, it really does help with performance, as most require/import frameworks load JS on demand, not at first.
My thoughts:
Never put anything on the individual
pages themselves, always use .js
files
One big file doesn't take advantage of the browser's ability to load a larger JS file as lets say 3 smaller files on 3 different concurrent connections during that critical initial page load when people enter your website
Logically group functions in
different files such as files for
validation, presentation and calculations as this makes it easier to maintain as file sizes increase
Use JSMIn (Javascript Minifier) to reduce file sizes http://www.crockford.com/javascript/jsmin.html
I've got a collection of javascript files from a 3rd party, and I'd like to remove all the unused methods to get size down to a more reasonable level.
Does anyone know of a tool that does this for Javascript? At the very least give a list of unused/used methods, so I could do the manually trimming? This would be in addition to running something like the YUI Javascript compressor tool...
Otherwise my thought is to write a perl script to attempt to help me do this.
No. Because you can "use" methods in insanely dynamic ways like this.
obj[prompt("Gimme a method name.")]();
Check out JSCoverage . Generates code coverage statistics that show which lines of a program have been executed (and which have been missed).
I'd like to remove all the unused methods to get size down to a more reasonable level.
There are a couple of tools available:
npm install -g fixmyjs
fixmyjs <filename or folder>
A configurable module that uses JSHint (Github, docs) to flag functions that are unused and perform clean up as well.
I'm not sure that it removes undefined functions as opposed to flagging them. though it is a great tool for cleanup, it appears to lack compatibility with later versions of ECMAScript (more info below).
There is also the Google Closure Compiler which claims to remove dead JS but this is more of a build tool.
Updated
If you are using something like Babel, consider adding ESLint to your text editor, which can trigger a warning on unused methods and even variables and has a --fix CLI option for autofixing some errors and style issues.
I like ESLint because it contains multiple plugins for alternate libs (like React warnings if you're missing a prop), allowing you to catch bugs in advance. They have a solid ecosystem.
As an example: on my NodeJS projects, the config I use is based off of the Airbnb Style Guide.
You'll have to write a perl script. Take no notice of the nay-sayers above.
Such a tool could work with libraries that are designed to only make function calls explicitly. That means no delegates or pointers to functions would be allowed, the use of which in any case only results in unreadable "spaghetti code" and is not best practice. Even if it removes some of these hidden functions you'll discover most if not all of them in testing. The ones you dont discover will be so infrequently used that they will not be worth your time fixing them. Dont obsess with perfection. People go mad doing that.
So applying this one restriction to JavaScript (and libraries) will result in incredible reductions in page size and therefore load times, not to mention readability and maintainability. This is already the case for tools that remove unused CSS such as grunt_CSS and unCSS (see http://addyosmani.com/blog/removing-unused-css/) and which report typical reductions down to one tenth the original size.
Its a win/win situation.
Its noteworthy that all interpreters must address this issue of how to manage self modifying code. For the life of me I dont understand why people want to persist with unrestrained freedom. As noted by Triptych above Javascript functions can be called in ways that are literally "insane". This insane fexibility corrupts the fundamental doctrine of separation of code and data, enables real-time code injection, and invalidates any attempt to maintain code integrity. The result is always unreadable code that is impossible to debug and the side effect to JavaScript - removing the ability to run automatic code pre-optimisation and validation - is much much worse than any possible benefit.
AND - you'd have to feel pretty insecure about your work to want to deliberately obsficate it from both your collegues and yourself. Browser clients that do work extremely well take the "less is more" approach and the best example I've seeen to date is Microsoft Office combination of Access Web Forms paired with SharePoint Access Servcies. The productivity of having a ubiquitous heavy tightly managed runtime interpreter client and its server side clone is absolutely phenomenal.
The future of JavaScript self modifying code technologies therfore is bringing them back into line to respect the...
KISS principle of code and data: Keep It Seperate, Stupid.
Unless the library author kept track of dependencies and provided a way to download the minimal code [e.g. MooTools Core download], it will be hard to to identify 'unused' functions.
The problem is that JS is a dynamic language and there are several ways to call a function.
E.g. you may have a method like
function test()
{
//
}
You can call it like
test();
var i = 10;
var hello = i > 1 ? 'test' : 'xyz';
window[hello]();
I know this is an old question by UglifyJS2 supports removing unused code which may be what you are looking for.
Also worth noting that eslint supports an option called no-unused-vars which actually does some basic handling of detecting if functions are being used or not. It definitely detects it if you make the function anonymous and store it as a variable (but just be aware that as a variable the function declaration doesn't get hoisted immediately)
In the context of detecting unused functions, while extreme, you can consider breaking up a majority of your functions into separate modules because there are packages and tools to help detect unused modules. There is a little segment of sindreshorus's thoughts on tiny modules which might be relevant to that philosophy but that may be extreme for your use case.
Following would help:
If you have fully covered test cases, running Code Coverage tool like istanbul (https://github.com/gotwarlost/istanbul) or nyc (https://github.com/istanbuljs/nyc), would give a hint of untouched functions.
At least the above will help find the covered functions, that you may thought unused.