I got emscripten working, but it generates huge self executing files. Is it possible to make emscripten generate small functions that I want to optimize so I can copy paste them into my existing application easily?
Thanks!
I would advise against a copy/paste of some generated function from the inside of the Emscripten-generated output unless you have identified that bandwidth / compiling of the ASM/Javascript in the browser is a limiting factor that affects the performance of the application. Going down that route I suspect makes would make updates full of pain that I would avoid unless necessary.
What I think is better is to use the techniques in the Code Size section of the Emscripten docs
Some of the fairly straightforward ways are:
Using NO_FILESYTEM to prod Emscripten to not include some standard libraries (assuming you don't need them).
Using NO_BROWSER if you can
Using NO_EXIT_RUNTIME to not include some functions required when exiting.
Tinkering with the optimization flags, but according to the docs -O2 offers
the smallest and fastest output.
It is possible, but not well documented yet: you can use the --separate-asm flag. See
https://gist.github.com/wycats/4845049dcf0f6571387a
and
https://gist.github.com/kripken/910bfe8524bdaeb7df9a
for examples.
Related
The Chrome Dev Tools JavaScript and CSS Coverage Drawer is pretty neat, except for one thing... It would be nice if it could be left on, and not reinitiate its analysis between pages.
I would like to be able to analyze an entire site, a subset of pages, or a set of websites, and find what is unused amongst them.
I get that it would mean browsing entire projects and using every feature (or setting up tests) to be thorough/precise, but that's not as tedious as what I have to do entirely without such a utility/feature. (And it doesn't seem like you would need to be meticulous to obtain usable or initial observations from a sub-thorough audit. The DevTools utility doesn't facilitate automated tests on its own either.)
The codebase at issue is huge (1.9mb uncompressed on the front end), and (possibly) contributed to by many developers who may or may not have left relics, legacy code, or abandoned dependencies. There is possibly also code that is only relevant in parts of projects, which could reveal opportunities for reducing dependency scope.
Is there a way to begin to crack into code use without a laborious manual deep dive?
It was one of the first things that came to mind when learned about the Google's coverage utility, and I assumed it would be capable of analyzing multiple pages collectively, but it doesn't.
Is there anything else that does this? Does any utility exist that can search an entire site or multiple pages and find unused JS and CSS?
Side note: The CSS is in SASS. For that and other reasons I may need to manually analyze the results and improve the code, which is trivial comparatively, so I'm not looking for a feature to automate code improvements. It's a similar situation with the JS which is minified.
This is not a request for a recommendation on poduct/software. It is asking if task X is possible, which is technically answerable with a yes or no.
UPDATE: It does seem like there are utilities for CSS, but still nothing found for JS.
For Static Analysis:
Try unusedcss.com to analyse unused CSS code across the entire website. More - Helium CSS
Try deadfile which is a simple util to find deadcode and unused files in any JavaScript project.
For Dead-code Removal:
Try purgecss to remove unused CSS code from your project.
Try Google's closure compiler which parses your JavaScript, analyzes it, removes dead code and rewrites and minimizes what's left.
That being said, detecting unused code is a hard problem to solve, because there are countless ways to invoke a given piece of code. Hence, these tools wisely and with your best judgement.
I need to compile / compact an "ever-growing" javascript app (round abouts 40k LoC, currently).
I don't have the time to integrate the "appropriate" tool for what I'm trying to do, something like require.js, as it requires modification of said code.
I was planning to just manually pile everything together to do a compact/compile routine, but at this point, I think that will make it quite difficult to maintain. (Ultimately, I'd like to keep the file structure broken down into its current hierarchy.)
That being said, I've been using a tool called Winless for .less compilation, andI really like its functionality:
add a folder set
note the files you want to include
watch for changes in those files and recompile when that happens
I'm wondering if an analogous tool exists for js?
The Closure Compiler does a top notch job, and I hear that Uglifyjs is good too. I might end up using Closure's REST api to manually manage file sets, but I'm wondering if anything exists that abstracts the process a little bit - into a standalone windows gui?
I've been poking around for a couple weeks, but have not come up with anything solid.
Cheers -
Have a look at http://gruntjs.com/ - "The JavaScript Task Runner". It becomes dead easy to script tasks, which would be along the lines of
a) run JSHint (for spotting errors in your code)
b) Run any QUnit tests
c) and finally call Uglify.js to compress your source in to a compressed, deployable file (I include a version number in mine to avoid caching issues).
I'm new to JavaScript.
How should I split my functions across external scripts? What is considered good practice? should all my functions be crammed into one external .js file or should I group like functions together?
I would guess more files mean more HTTP requests to obtain the script and that could slow down performance? However more files keep things organized: for example, onload.js initializes things on load, data.js retrieves data from the server, ui.js refer to UI handlers...
What's the pros advice on this?
Thanks!
As Pointy mentioned, you should try a tool. Try Grunt of Brunch, both are meant to help you in the build process, and you can configure them to combine all your files when you are ready for prod (also, minify, etc), while keeping separate files when you are developing.
When releasing a product, you generally want as little HTTP requests as possible to load a page (Hence image sprites, for example)
So I'd suggest concatenating your .js's for release, but keeping them separated in a way that works well for you, during development.
Keep in mind that if you "use strict", concatenating scripts might be a source of errors.
(more info on js strict mode here)
It depends on the size, count of your scripts and how many of them you use at any time.
Many performance good practices claim (and there's good logic in this) that it's good to inline your JavaScript if it's small enough. This leads to lower count of HTTP requests but it also prevents the browser from caching the JavaScript so you should be very careful. That's why there're a practices even to inline your images (using base64 encoding) in some special cases (for example look at Bing.com, all their JavaScript is inline).
If you have a lot of JavaScript files and you're using just a little part of them at any time (not only as count but as size) you can load them asynchronously (for example using require.js). But this will require a lot of changes in your application design if you haven't considered it at the beginning (and also make your application complexity bigger).
There are practices even to cache your CSS/JavaScript into the localStorage. For further information you can read the Web Performance Daybook
So let's make something like a short retrospection.
If you have your JavaScript inline this will reduce the first load of the page. The inline JavaScript won't be cached by the browser so every next load of your page will be slower that if you have used external files.
If you are using different external files make sure that you're using all of them or at least big part of them because you can have redundant HTTP requests for files which actually are unnecessary loaded. This will lead to better organization of your code but probably greater load time (still don't forget the browser cache which will help you).
To put everything in at single file will reduce your HTTP requests but you'll have one big file which will block your page loading (if you're using synchronous loading of the JS file) until the file have been loaded completely. In such case I can recommend you to put this big file in the end of the body.
For performance tracking you can use tools like YSlow.
When I think about good practice, then I think of MVC patterns. One might argue if this is the way to go in development, but many people use it to structure what the want to achieve. Usually it is not advisable to use MVC at all if the project is just too small - just like creating a full C++ windows app if you just needed a simple C program with a for loop.
In any case, MVC or MV* in javascript will help you structure your code to the extent that all the actions are part of the controllers, while object properties are just stored in the model. The views then are just for showing purposes and are rendered for the user via special requests or rendinering engines. When I stared using MV*, I stared with BackboneJS and the Guide "Developing BackboneJS Applications" from Addy Osmani. Of course there are a multitude of other frameworks that you can use to structure your code. They can be found on the TodoMVC website.
What you can also do is derive your own structure from their apps and then use the directory structure for your development (but without the MV* framework).
I do not agree to your concern that using such a structure lead to more files, which mean more HTTP requests. Of course this is true during development, BUT remember, the user should get a performance enhanced (i.e. compiled) and minified version as a script. Therefore even if you are developing in such an organized way, it makes more sense to minify/uglify and compile your scripts with closure compiler from Google.
Let's say you are building a large application, and you expect to have tons of javascript on the site. Even if you separated the javascript into 1 file per page where javascript is used, you'd still have about 100 javascript files.
What is the best way to keep the file system organized, include these files on the page, and keep the code structure itself organized as well? All the while, having the option to keep things minified for production is important too.
Personally I prefer the module pattern for structuring the code, and I think this article gives a great introduction:
http://www.adequatelygood.com/2010/3/JavaScript-Module-Pattern-In-Depth
It keeps my global scope clean, enables namespacing and provides a nice way to seperate public and private methods and fields.
I'd structure the code in separate files, and seek to keep coupling low and cohesion high. Although multiple files are bad for client performance (you should minimize the number of requests), you'll easily get the best from both worlds using a compression utility.
I've some experience with YUI Compressor (for which there is a Maven plugin:
http://alchim.sourceforge.net/yuicompressor-maven-plugin/compress-mojo.html - I haven't used this myself). If you need to order the javascript files in a certain way (also applies for CSS), you could make a shell script, concatenating the files in a given order in advance (Tip: YUI Compressor defaults to STDIN).
Besides, either way you decide to minify your files will probably do just fine. Your focus should instead be on how you structure your code, so that it performs well on the client (should be highest priority in order to satisfy a good UX), and is maintainable in a way that works for you.
You mention namespaces, which is a good idea, but I'd be careful to adopt too many concepts from the traditional object oriented domain, and instead learn to utilize many of the excellent features of the javascript language :)
If the overall size is not too big, i'd use a script to compile all files into a single file and minify this file. Then I'd use aggressive caching plus the mtime in the url so people load that file only once but get the new one as soon as one is available.
Use:
jslint - to keep checks on code quality.
require.js - to get just the code you need for each page (or equivalent).
Organise your js as you would any other software project, break it up by roles, responsibilities and separating concerns.
I have just been asked to describe the architecture for a large scale dashbaord style project that i will be working on.
I have bever worked on a application of this size and am a bit lost as to what to say.
Could i be pointed in the direction of any articles that may help me get started and hopefully finished.
I have gleaned the following information thus far but i am not really sure that it describes the architecture.
1) Use classes instead of seperate functions and each class or group should be contained within their own JS file
2) Prior to production there should be a compile step where said JS files are compiled and minified
3) Step2 does not have to contain all the files. Jsut the common ones to start
4) Use a classloader to load classes, plugins etc when they are needed. On research could jQuery's getScript function be used for this or even a jQuery plugin loader:
http://api.jquery.com/jQuery.getScript/
http://www.unwrongest.com/projects/lazy/
Am feeling way out of my depth at the mo so any help would be massively appreciated. Be honest, if the above is competely irrelevant then i guess i am in the wrong job :(
Everything you need to know can be found here:
http://addyosmani.com/largescalejavascript/
Create a library of loosely couple components that communicate through an application controller (e.g. event bus).
I would recommend looking at using ExtJS 4 for this. Its APIs and development methodology closely track what you would expect from .NET or Java for developing a large-scale desktop app.
Version four answers all four of your points. It has...
1) A system for defining Java/C#-like classes in Javascript that work almost exactly the way a Java or C# developer would expect.
2) Dynamic resource loading.
3) The ability to create a final product from the SDK which is a neat, compressed version which contains just what you need.
If you are to do this with pure Javascript, ensure you use some reference architecture in the job. What HDave pointed above is really good material. If you want a ready-made reference architecture as a project startup code, have a look at BoilerplateJS:
http://boilerplatejs.org
After some large-scale projects, I have compiled some of the learnings in to this framework. Look at the samples too. Some of the concerns you raised are already addressed in this codebase such as use of OO concepts, minification and optimizations, decoupled moduler design and many more too.