I'm currently coding a project in Java that will use external JavaScript files to read and analyze local files (and thus, also using Node.js for RequireJS). I usually use an application that allows me to package multiple jars (such as libraries) with the main project jar into a .exe for easy distribution, but I'm realizing that this will be significantly more difficult with the JavaScript involved.
Does anyone know how I could convert my .js files into one (or more) .jar files such that I'd be able to reference them in Java and include them in my .exe?
(I'm aware that this may not be possible, but I've seen enough things while researching this that make it seem like it might be possible that I figured it was worth asking)
Related
Project I'm working on
I am starting a webaudio project in a team in which we are making audio effects, audio visualization and audio synthesis. We are now designing a basic folder structure. Each of us is thinking of a structure and in our next meeting we will choose the best one. One of the team-members is really experienced with Javascript, but I'm leaning more to Dart, cause it just feels more familiar and robust. I have a Java background, but I'm not really experienced with web development. Therefore I want to develop the software in both languages: Dart and Javascript, so that I can eventually get to a solid decision whether it is better to use Dart or Javascript for this project.
Directory structure?
I want to subdivide the dart libraries in three main directories: effects, visualization and synthesis. But I don't know yet where to place those main directories. According to the Pub Package Layout Convention the libraries should be located in the lib directory. But since all libraries will strongly depend on the webaudio API, it will only run in a browser, and thus be web application. So my first question is: "Should I place my libraries in the package/libs directory or somewhere in the package/web directory?" And "Should I put the javascript counterparts in the same directory?" For example: both oscillator.js and oscillator.js in the synthesis folder.
Switch between Javascript and Dart?
Once that the directory structure is done I would like to be able to easily switch from the Dart version to the Javascript version and vice-versa, and since I need a browser with an embedded Dart VM that will be Dartium. So here goes my second question: "What would be the best way to easily switch between the Javascript and the Dart version?"
Thanks in advance!
PS: I know that I could just use the generated Javascript from dart2js, but I want actually readable Javascript. And the dart2js Javascript does not exactly meet that requirement. Furthermore I want to have good understanding on the differences between the two languages, and I think that the best way is to try them both.
Edit: I would like to clarify the idea of switching between Javascript and Dart on Günter's demand. I will make a Javascript port of every Dart file manually, just so that I can learn both. Since I will be developing both of them at the same time, I want to be able to test the site with the Dart version, but also with the Javascript version. So I want the HTML to load this if in Dartium:
<script type="application/dart" src="main.dart"></script>
But this if in any other browser:
<script src="main.js"></script>
I reccon that dart.js in the browser package does this to switch between *.dart and *.dart.js, depending on if the browser has a Dart VM or not. But I want it to switch between *.dart and *.js (my own js), without having to make two separate html files.
Question 1: All in lib/ except entry points is fine.
Question 2: You can use pub serve. This allows to access to the app from Dartium or any browser from the same url. Any update in a dart file will be compiled when a *.dart.js file is request instead of a *.dart file.
For your edit: you can have a look at the dart_to_js_script_rewriter package to do a transformer that will rewrite your <script type="application/dart" src="main.dart"></script> to <script src="main.js"></script>. Switching from JS to Dart will be done by adding/removing your created transformer to pubspec.yaml and restarting pub serve or pub build.
I am writing a web server in Node.js, and I want it (among other things) to deliver a single JavaScript file to the client which contains my client SDK. The SDK is basically an object which provides lots of functionality the client can use.
I need to build the SDK from various sources:
3rd party libs, such as AngularJS
Custom code, which is stored in static .js files on the server
Custom code, which is created dynamically in-memory at runtime
For being able to test my custom code (#2) easily, and for being able to share this code with the server-side as well, it would be great if I could write it according to CommonJS.
I do not have too much experience with bundling things up for the client-side, but I know UglifyJS and Browserify.
If it was only about concatenating some files (and perhaps minifying them), I knew what to do with UglifyJS. If it was only about delivering some stuff that is compatible to CommonJS, I also knew what to do with Browserify. What I don't get is their combination, and this in addition with demand #3 - the dynamically generated code.
This essentially means that I am not able to use Grunt for this, but that everything needs to be done at runtime (please let's not discuss why I want to do it like this).
So … I'm somewhat lost. Can anybody help clarify things for me? How do I have to put all these pieces together so that I finally end up with a single deliverable that can be sent to the client, and that the client can use?
Basically, what the client should end up with is a number of global objects such as $, angular and my very own custom object, but all this by only loading one single file.
How could I do this?
PS: I do not have the need to put the result to disk on the server, if it's a pure in-memory solution that's perfectly fine for me (and is even preferred, as then I do not need write access to the file system).
Imho webpack provides all the features you need. It's a bundler like browserify but I find it more flexible and extensible. webpack is agnostic to different module styles (CommonJS, AMD, ES6 or old-school globals) and is able to apply and chain pre-processors on modules. These are called loaders (according to the CommonJS spec) and can be used to generate code dynamically. Usually they transform LESS to CSS or CSS to JavaScript, but they can be used for any dynamic task.
To provide your global $, angular and your custom object you could use the script-loader, which runs the given module classically in a global context.
What you're looking for is called "asset pipeline".
You can use mincer (I didn't try it, but it looks very promising) or asset-pipeline (certainly will do the job, but is kinda deprecated).
What is the simplest way to combine JavaScript files into a single file in a Django project?
Explanation
I want this to work with Ember.js/Backbone where you (usually) have many different JavaScript in multiple directories. Directories would all be in one folder called app/ for example, like: app/views/ app/models/ /app/routers/
Requirements
Work together with the staticfiles app
Still be separated while in development mode for easier debugging (only compile when calling collectstatic?)
Work with Require.js (guess that shouldn't be too hard, but putting it in here to be sure)
Extra credit
Explain a best practices way of combining Django and Ember/Backbone.
I am an happy user of django compressor, it does combine, minify, debug-friendly, you can use it with staticfiles, easy to plug with custom storage backend (eg. S3)
https://github.com/jezdez/django_compressor
The reason you want to combine many files into one is so to minimize latency of setting up and tearing down http requests, the fewer you make the better. However, many newer browsers are downloading JavaScript files in parallel (still executing sequentially). The consequence is that downloading a single 1Mb file may be slower than three 350Kb files.
you can use from CDNs.
As mentioned in the previous answer, django-compressor is nice, but you often get better loading times when using a dedicated javascript loader instead. My tip is to check out Head.js for example (http://headjs.com/) (there are tons other out there as well). Often combining scripts can be contra productive when considering caching, using javascript located on CDN:s etc.
One thing to remember is that Iphone 3/4 will just cache 15/25KB of javascript, so if you have huge scripts and combine them you can run into trouble. http://www.phpied.com/iphone-caching/
Our file structures is pretty good, organizing functionality in separate folders. My question is how do others work on applications that involves upwards of 500 JavaScript files.
We have written a maven plugin to concatenate these files together (also runs YUI compressor). However, this involves 3-10seconds of compiling for every change.
Is this step necessary for organization of a large application, I feel like a well structured HTML file pulling in all these resources would save me 45minutes every day.
For my own framework projects, typically monitoring, testing, or in-page services to orchestrate other toolkits (but not as high as your file count), my approach has been to target the individual and dynamically loaded files during development. For test, I'll run one build to compress and version the individual files, and test the individual files again because, depending on the concatenation order, compression technique, and browser, I may wind up with a script error and it's a pain to dig it out of one monster file. Third, I'll concatenate together and test once more.
In the HTML reference, I'll either target the uncompressed file, which loads specified dependencies, or the compound file. A separate bootstrap file names the dependencies, which are either included in the compound file, or loaded dynamically as needed.
This way I can add or change a file, and start developing and testing without rebuilding.
The solution is likely to concatenate and compress for user testing and production only.
For development, it's probably best to simply import them all into the HTML file. It speeds up the dev process, and also simplifies debugging. It also allows the browser to cache some of those files.
When you can't rely on cached copies (which, with 500 files, I don't think will be very often), it will slow down load times.
You can likely save a lot of time by only running the compressor in production. The YUI compressor is notoriously slow, because it uses Java Rhino interpreter to actually parse the JavaScript and analyze it etc.
I've been using yuicompressor.jar on my test server for on-the-fly minimisation of changed JavaScript files. Now that I have deployed the website to the public server, I noticed that the server's policies forbid the use of exec() or its equivalents, so no more java execution for me.
Is there a decent on-the-fly JS compressor implemented in PHP? The only thing resembling this that I was able to find was Minify, but it's more of a full-blown compression solution with cache and everything. I want to keep the files separate and have the minimised files follow my own naming conventions, so Minify is a bit too complex for this purpose.
The tool, like yuicompressor, should be able to take either a filename or JavaScript as input and should either write to a file or output the compressed JavaScript.
EDIT: To clarify, I'm looking for something that does not have to be used as a standalone (i.e. it can be called from a function, rather than sniffing my GET variables). If I just wanted a compressor, Minify would obviously be a good choice.
EDIT2: A lot has changed in the five years since I asked this question. Today I would strongly recommend separating the front-end workflow from the server code. There are plenty of good tools for JS development around and except for the most trivial jQuery enhancements it's a better idea to have a full workflow with automated bundling, testing and linting in place and just deploy the minified bundles rather than the raw files.
Yes there is, it's called minify.
The only thing in to worry about in the way of complexity is setting up a group, and there's really nothing to it. Edit the groupsConfig.php file if you want multiple JS/CSS in one <script> or <link> statement:
return array(
'js-common' => array('//js/jquery/jquery-1.3.2.min.js', '//js/common.js', '//js/visuals.js',
'//js/jquery/facebox.js'),
'css-common' => array('//css/main.css', '//css/layout.css','//css/facebox.css')
);
To include the above 'js-common' group, do this:
<script type="text/javascript" src="/min/g=js-common"></script>
(i know i was looking for the exact same thing not knowing how to deal directly with the jar file using php - that's how i ended up here so i'm sharing what i found)
Minify is a huge library with tons of functionalities. However the minifying part is a very tiny class : http://code.google.com/p/minify/source/browse/trunk/min/lib/Minify/YUICompressor.php
& very very easy to use :
//set the path to the jar file
Minify_YUIcompressor::$jarFile=_ROOT.'libs/java/yuicompressor.jar';
//set the path to a writable temp folder
Minify_YUIcompressor::$tempDir=_ROOT.'temp/';
//minify
$yourcssminified=Minify_YUIcompressor::minifyCss($yourcssstringnotminified,$youroptions)
same process for js, if you need more functionalities just pick from the library & read the source to see how you can make direct call from your app.
I didn't read the question well, since minify is based on using the jar files, the op can't use it anyway with his server config
Minify also include other minifying methods than yui, for example:
http://code.google.com/p/minify/source/browse/trunk/min/lib/JSMinPlus.php?r=443&spec=svn468
Try Lissa:
Lissa is a generic CSS and JavaScript loading utility. Lissa is an extension of the YUI PHP Loader aimed at solving one of the current loader limitations; combo loading. YUI PHP Loader ships with a combo loader that is capable of reducing HTTP requests and increasing performance by outputting all the YUI JavaScript and/or CSS requirements as a single request per resource type. Meaning even if you needed 8 YUI components which ultimately boil down to say 13 files you would still only make 2 HTTP requests; one for the CSS and another for the JavaScript. That's great, but what about custom non-YUI resources. YUI PHP Loader will load them, but it loads them as separate includes and thus they miss out on benefits of the combo service and the number of HTTP requests for the page increases. Lissa works around this limitation by using the YUI PHP Loader to handle the loading and sort of YUI and/or custom resource dependencies and pairs that functional with Minify.