We Keep Coding

ES6 exports/imports use-case, compared to traditional namespacing

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.

JavaScript - What Level of Code Optimization can one expect?

So, I am fairly new to JavaScript coding, though not new to coding in general. When writing source code I generally have in mind the environment my code will run in (e.g. a virtual machine of some sort) - and with it the level of code optimization one can expect. (1)
In Java for example, I might write something like this,
Foo foo = FooFactory.getFoo(Bar.someStaticStuff("qux","gak",42);
blub.doSomethingImportantWithAFooObject(foo);
even if the foo object only used at this very location (thus introducing an needless variable declaration). Firstly it is my opinion that the code above is way better readable than the inlined version
blub.doSomethingImportantWithAFooObject(FooFactory.getFoo(Bar.someStaticStuff("qux","gak",42));
and secondly I know that Java compiler code optimization will take care of this anyway, i.e. the actual Java VM code will end up being inlined - so performance wise, there is no diffence between the two. (2)
Now to my actual Question:
What Level of Code Optimization can I expect in JavaScript in general?
I assume this depends on the JavaScript engine - but as my code will end up running in many different browsers lets just assume the worst and look at the worst case. Can I expect a moderate level of code optimization? What are some cases I still have to worry about?
(1) I do realize that finding good/the best algorithms and writing well organized code is more important and has a bigger impact on performance than a bit of code optimization. But that would be a different question.
(2) Now, I realize that the actual difference were there no optimization is small. But that is beside the point. There are easily features which are optimized quite efficiently, I was just kind of too lazy to write one down. Just imagine the above snippet inside a for loop which is called 100'000 times.

Don't expect much on the optimization, there won't be
the tail-recursive optimization,
loop unfolding,
inline function
etc
As javascript on client is not designed to do heavy CPU work, the optimization won't make a huge difference.
There are some guidelines for writing hi-performance javascript code, most are minor and technics, like:
Not use certain functions like eval(), arguments.callee and etc, which will prevent the js engine from generating hi-performance code.
Use native features over hand writing ones, like don't write your own containers, json parser etc.
Use local variable instead of global ones.
Never use for-each loop for array.
Use parseInt() rather than Math.floor.
AND stay away from jQuery.
All these technics are more like experience things, and may have some reasonable explanations behind. So you will have to spend some time search around or try jsPerf to help you decide which approach is better.
When you release the code, use closure compiler to take care of dead-branch and unnecessary-variable things, which will not boost up your performance a lot, but will make your code smaller.
Generally speaking, the final performance is highly depending on how well your code organized, how carefully your algorithm designed rather than how the optimizer performed.
Take your example above (by assuming FooFactory.getFoo() and Bar.someStaticStuff("qux","gak",42) is always returning the same result, and Bar, FooFactory are stateless, that someStaticStuff() and getFoo() won't change anything.)
for (int i = 0; i < 10000000; i++)
blub.doSomethingImportantWithAFooObject(
FooFactory.getFoo(Bar.someStaticStuff("qux","gak",42));
Even the g++ with -O3 flag can't make that code faster, for compiler can't tell if Bar and FooFactory are stateless or not. So these kind of code should be avoided in any language.

You are right, the level of optimization is different from JS VM to VM. But! there is a way of working around that. There are several tools that will optimize/minimize your code for you. One of the most popular ones is by Google. It's called the Closure-Compiler. You can try out the web-version and there is a cmd-line version for build-script etc. Besides that there is not much I would try about optimization, because after all Javascript is sort of fast enough.

In general, I would posit that unless you're playing really dirty with your code (leaving all your vars at global scope, creating a lot of DOM objects, making expensive AJAX calls to non-optimal datasources, etc.), the real trick with optimizing performance will be in managing all the other things you're loading in at run-time.
Loading dozens on dozens of images, or animating huge background images, and pulling in large numbers of scripts and css files can all have much greater impact on performance than even moderately-complex Javascript that is written well.
That said, a quick Google search turns up several sources on Javascript performance optimization:
http://www.developer.nokia.com/Community/Wiki/JavaScript_Performance_Best_Practices
http://www.nczonline.net/blog/2009/02/03/speed-up-your-javascript-part-4/
http://mir.aculo.us/2010/08/17/when-does-javascript-trigger-reflows-and-rendering/
As two of those links point out, the most expensive operations in a browser are reflows (where the browser has to redraw the interface due to DOM manipulation), so that's where you're going to want to be the most cautious in terms of performance. Some of that can be alleviated by being smart about what you're modifying on the fly (for example, it's less expensive to apply a class than modify inline styles ad hoc,) so separating your concerns (style from data) will be really important.
Making only the modifications you have to, in order to get the job done, (ie. rather than doing the "HULK SMASH (DOM)!" method of replacing entire chunks of pages with AJAX calls to screen-scraping remote sources, instead calling for JSON data to update only the minimum number of elements needed) and other common-sense approaches will get you a lot farther than hours of minor tweaking of a for-loop (though, again, common sense will get you pretty far, there, too).
Good luck!

Is there a way to remove unused lines of a JS Library?

I currently coded something awesome based on a JS Library, and I want to remove every useless line that is doing nothing but take more time to download from the server.
What is the best way to keep track of what piece of code was used/unused when my code executed? (So I can remove the unused code)
My first thoughts are to put "var log += "<br />Function name was used." on every function and remove every function that wasn't called. But I am curious about if there is another way
I want to point out that modifying certain JS Libraries might violate their Licences and possibly cause strong legal issues. So if anyone is reading this and is planning to do the same thing as me, please read carefully the Licence(s) before you even attempt to do this!

In my estimation, the best way to keep track of which code has actually executed would be to use a code coverage measurement tool. There are several available for Javascript, many of which are outlined in a previous question: https://stackoverflow.com/questions/53249/are-there-any-good-javascript-code-coverage-tools .
Of course, this only tracks the code that has executed as a result of the test suite you are running it against, and would not be a foolproof way to find "completely dead" (i.e. unreachable) code. But it's a start...

Is writing your own parser worth the extra runtime it causes?

I am doing work involving a lot of DOM manipulation. I wrote a function to more efficiently change common styles on objects using "hotkeys". It simply interprets this:
styles = parseStyles({p:"absolute",l:"100px",t:"20px",bg:"#CC0000"});
as this:
styles = {position:"absolute",left:"100px",top:"20px",background:"#CC0000"};
This came about mainly to save me from having to read so much, and because I wanted to see if I could do it :) (as well as file sizes). I find these hotkeys easier to look at; I am setting and resetting styles dozens of times for different custom DOM objects.
But, is having a bottleneck like this going to be a significant burden on performance and runtime if my page is using it up to 5,000 times in a session, about 10-25 executions at a time?
function parseStyles(toParse){
var stylesKey =
{h:"height",p:"position",l:"left",t:"top",r:"right",b:"bottom",bg:"background"},
parsedStyles = {};
for (entry in toParse){
if (entry in stylesKey){
parsedStyles[stylesKey[entry]] = toParse[entry];
} else {
parsedStyles[entry] = toParse[entry];
}
}
return parsedStyles;
}

I find that setting non-computed styles is rarely ever needed any more. If you know the styles ahead of time, define a class for that in your CSS and addClass or removeClass from the necessary objects. Your code is a lot more maintainable and all style-specific info is in your CSS files rather than your Javascript files. Pretty much, the only time I set formatting-style info directly on an object anymore is when I'm using computed positions with absolute positioning and even then, if I rack my brain hard enough, the positioning problem can usually be solved with plain CSS/HTML.
The examples you cite in your question look like static styles which could all be done with a CSS rule and simply doing addClass to an object. Besides being cleaner, it should be a lot faster to execute too.
It looks like what you're doing is using run-time parsing in order to save development-time typing. That's fine if you don't notice the performance difference. Only you can know that for sure because only you can test your app in the environments that you need it to run (old browser, old CPU, stress usage). We can't answer that for you. It would certainly be faster not to be doing run-time conversion for something that is known at development time. Whether that speed difference is relevant depends upon a lot of details and app requirements you haven't disclosed (and may not have even seriously thought about) and could only be figured out with configuration testing.
If it were me and I had any thoughts that maybe I was calling this so much that it might impact performance, I'd find it a lot less work to do a little extra typing (or search and replace) and not have to test the potential performance issues.

Memoize your parsing function.
The simple fact is, that over some finite area of time, the number of actual styles, or full style strings that you will process will likely be quite small, and will also, likely, have a reasonable amount of duplication.
So, when you go to parse a style expression, you can do something simple like store the expression in a map, and check if you've seen it before. If you have, return the result that you got before.
This will save you quite a bit of time when reuse is involved, and likely not cost you much time when it's not.

jQuery/JS for different pages - best way of doing this?

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