Develop Reference

Android and Web App sharing Kotlin code

One of the major “selling” points of Kotlin appears to be its ability to compile both to JVM or Android and to JavaScript for the web. To make use of this, it should be possible to have a code base where some files are shared between an Android App and a browser Web App.
However, so far I found little details on how such a thing would be set up, in particularly when working with Android Studio and its underlying Gradle setup, starting from a a run of the Android Studio New Project Wizard. I don't mind if I can only build the Web App on the command line, but I'd like to maintain the Android debugging hookups that Android Studio provides. So far I know very little about Gradle and typical idioms for its use.
I'm sure that I'm not the first person to have this idea, so I'd like to know some best practices on how to set this up. Questions that come to my mind include the following:
Do I mix the kotlin2js and the kotlin-android plugin in a single build file, or do I need to have multiple build files (perhaps I should say “modules” or “projects” except I don't know which)?
If I have multiple build files, should that be two (one Android one Web) or three (one more for shared things)?
If it is two build files, how do I reference the shared sources?
If it is three build files, which plugin(s) do I use for the shared one?
Do I need to split my sources over three different source trees? Are there any conventions how these should be called?
Do I need to split my classes into three groups of packages, or can code for different targets coexist in the same package?
What configuration settings do I need to tweak to make the IDE aware of the layout of my project?
I've read the following relevant documentation, among other:
https://kotlinlang.org/docs/reference/using-gradle.html
https://docs.gradle.org/current/userguide/intro_multi_project_builds.html
https://docs.gradle.org/current/userguide/composite_builds.html
https://kotlinlang.org/docs/tutorials/kotlin-android.html

I would recommend using IDEA wizard to create a simple multiplatfrom project for you (File -> New -> Project -> Kotlin -> Kotlin (Multiplatform - experimental) ). Community edition should suffice.
Answering your questions:
You don't mix plugins. You create a separate module for your common code and use 'kotlin-platform-common' plugin for it.
Three modules, special plugin 'kotlin-platform-common'
Use common sense for source splitting. Put whatever you want/able to reuse in the common code. Put platform-specific code in platform modules.
No package restrictions. You can put everything in the same package if you so desire =)
Pretty sure it should just work. If not, try re-importing.

Browserify for production, and something else for development

Browserify great and all, and makes it really sweet (even compared to require.js), but the idea of bundling everything into one minified file although sounds great for final version of the app, feels like something I would like to avoid during development. Wouldn't it make difficult to debug stuff?
Is it possible to use browserify and still keep all javascript files and make it more transparent for the browser during development? And when you ready to ship it run browserify bundler and minify everything into one file?
Or maybe there's better approach - like keeping all scripts listed in a partial that gets included to the main page for development or something like that?
Upd: I just found that there's an option:
--debug -d Enable source maps that allow you to debug your files separately.
Is that helpful? I guess it is. But I suppose it still makes it difficult if want to use coffeescript source maps

Indeed you shouldn't use minified/concatenated Javascript in development. Luckly there are a myriad of ways of solving this particular issue, I recommend taking a look into an automated build process like Grunt.

OpalRb with MeteorJS?

I have been intrigued by the power and elegance that Opal offers in the way of using pure Ruby vs CoffeeScript or, of course, JS.
How would one go about leveraging Opal for Meteor as the primary language for development?
UPDATE: just wanted to share that we have shifted focus over to Volt for our realtime needs in an isomorphic environment that offers Ruby from bottom to top. It has been a fantastic experience and even Matz has tweeted about it a few times now.

I just released an initial version.
This will compile Ruby files to Javascript, but there is nothing meteor specific (yet).
I plan on porting Meteor to a Ruby class at some point, stay tuned or even better submit pull requests...

Yes, check out how the coffeescript package is implemented in Meteor in order to compile .coffee to .js. Specifically, the following
https://github.com/meteor/meteor/blob/devel/packages/coffeescript/package.js - The undocumented _transitional_registerBuildPlugin function which tells meteor how to turn coffeescript files into js files
https://github.com/meteor/meteor/blob/devel/packages/coffeescript/plugin/compile-coffeescript.js - The script that compiles files and generates source maps.
https://github.com/meteor/meteor/blob/devel/tools/bundler.js for how compiled files are served.
If everything is super well designed, you probably shouldn't have to touch the bundler to create a smart package that will build OpalRb files. However, I'm guessing that you are probably going to have to fire off a pull request or two to core in the bundler area in order to get it to play well with your package. Right now, the preprocessor treats all files individually, which may not be possible with your language (I'm not sure.) In the process, however, you'll be contributing to make Meteor's support of other JS dialects and compilers even better!
I'll reiterate my point that Coffeescript seems ideal if you want some sort of high level language for writing JS, especially since it supports in-browser source maps for debugging now.

Maybe a little late on the boat: I wrote a build plugin for Opal in Meteor.
You can find it on atmosphere https://atmospherejs.com/massimoronca/opal https://atmospherejs.com/mikamai/opal
You can install the plugin using
meteor add massimoronca:opal
meteor add mikamai:opal
Every file ending in .rb or .js.rb will be automatically compiled.
You'll have to wrap Meteor builtin Objects, until I'll release a package that does that, you can find a small example on how to do it in this gist https://gist.github.com/wstucco/42392ee21b76dfa3ef83
For example the Meteor global Object can be wrapped in Opal like this
class Meteor
def self.server?
`Meteor.isServer`
end
def self.client?
`Meteor.isClient`
end
def self.cordova?
`Meteor.isCordova`
end
def self.startup(&block)
`#{block.call if block_given?}`
end
end
and used this way
puts "Hello from server" if Meteor.server?
EDIT: moved the plugin under the Mikamai account

What do you do to your JavaScript code before deployment?

Do you have a step in your deployment process that minifies JS? Do you have any sort of preprocessor for your JavaScript that allows you to leave in comments and console.logs and then have them automatically stripped out? Is your JavaScript machine generated by GWT or Script#? Do you use ANT or another tool to automate deployment?
I see a lot of JavaScript that looks like it comes right out of the editor, complete with lots of white space and comments. How much of that is due to not caring about the state of the deployed code, and how much is due to the spirit of the open web?

I usually check it out with JSLint to make sure it is bug-free, then pack it/encode it with YUI compressor.

My steps include:
I write Javascript using TextMate with the Javascript Tools bundle installed. This JSLint's my files on every save and notifies me when errors occur.
I use Sprockets to automatically concatenate my various Javascript files.
I run the resulting concatenation through jsmin to generate a minified version.
I end up with a concatenated lib.js file and a minified lib.min.js file. One I use for development, one for production. TextMate commands help automate it all.
I'm still looking for a good solution to actually (unit) test my scripts.

Check out YUI Compressor its a console app that you can use to minify (strip out comments, whitespace etc..) and also obfuscate your javascript files.

JSMin it from Douglas Crockford. We've got it hooked up as a macro in Studio as well as a post build item for some of our larger projects

FWIW, here's an interesting mini-benchmark on various ways you can minimize your Javascript source:
http://www.ericmmartin.com/comparison-of-javascript-compression-methods/
In short:
gzip compression in HTTP protocol really makes a difference (although you need to pay a CPU cost at the server side)
minification (removal of whitespace/comments, change of variable names etc.) also helps, and if you want best result, use it together with gzip compression
js-based decompressors are most likely useless - while you might get smaller size, the CPU overhead on the client is significant.

For one of our products, we concatenate all Javascript files together (most files are used on most pages, so this makes sense for us) and use Javascript::Minifier. This has given us a pretty nice speed boost.

A lot of it is probably due to not caring about people that might be viewing your pages on slower machines with slower connections and assuming that everyone has a 50Mbps line and three Gigs of RAM.
We are minifying our (hand-written + plugins, jQuery, etc.) JS as a part of the build process in .NET environment. No preprocessor, this is something we should definitely be doing once time permits.
P.S. By the way, we're not using console.log, as this will break IE. Instead we have a simple wrapper function, something like:
function log(stuff) {
if (window.console && window.console.log) {
console.log(stuff);
}
};

I have a PHP script that does it on the server side and keeps a cache of whatever it pulls from the source folder(s).

One word- packer

Light a candle, whisper a prayer against IE6 errors, and click "go". Does that count? :)

I don't minify my own javascript code since text tends to gzip/compress well.
I would minify a very large (say > 100 kb) javascript library (but then again I probably would not want to be using such a large library (or just ship what i use)).
I tend to believe that a lot of the javascript-minification is (in reality) done to achieve some sort of (futile) obfuscation of javascript code instead of the proclaimed end-user performance gain.

There's also a .NET port of YUI Compressor which allows you to:-
intergrate the minification/file combining into Visual Studio post-build events
intergrate into a TFS Build (including CI)
if you wish to just use the dll's in your own code (eg. on the fly minification).

I thought I would share my approach to js deployments. Have a look at this blog post:
http://www.picnet.com.au/blogs/Guido/post/2009/12/10/Javascript-runtime-compilation-using-AspNet-and-Googles-Closure-Compiler.aspx
This also includes code to compile (using google's closure compiler) at runtime (when needed).
Thanks Guido

Javascript for command line utilities

Given a need to write command line utilities to do common tasks like uploading files to a remote FTP site, downloading data from a remote MySQL database etc.
Is it practical to use JavaScript for this sort of thing? I know there are JavaScript interpreters that can be run from the command line, but are there libraries for things like FTP and database access the way there are for e.g. Java? If so, what's the best place to look for them? (Google searches with JavaScript in the keywords always seem to return many pages of browser specific things.)
And is there a way to package a JavaScript program up as a standalone executable on Windows?
Update: I've decided Python is a better tool for this kind of job, but the answers to the original question are still good ones.

Standalone executable?
By the way you ask the question, I'm not sure if you are aware, but the Windows Script Host - included in Windows - allows you to run .js files from the command-line. Your javascript will not be an executable, it will remain a script, a text file. The script runs within cscript.exe, which is provided by WSH. There's no compilation required. Maybe you knew all that.
I use Javascript this way for various utilities on Windows.
I think your instinct is right on the availability of libraries. You are sort of on your own to find all those things. Although, once you find them, it's not hard to package Javascript libraries as COM components and allow re-use from anywhere. See here for an example of packaging the Google Diff/Patch/Match Javascript library in COM.
Addendum: Once a bit of code is available within COM, it can be consumed by any Javascript running on the machine. Some examples of COM objects available to Javascript scripts running in WSH:
MSXML2.XMLHTTP object - used in AJAX, but can be used for any HTTP communication. There also an object for the XSLT engine so you can do transforms from script.
Excel.Application - allows you to open up Excel spreadsheets and automate them from Javascript.
Communicator.UIAutomation - automate MS Communicator (send IM's via script)
COM objects for Google Earth.
SlowAES - an all-Javascript implementation of AES encryption.

You can use Rhino to compile Javascript into Java byte code, and get access to all Java libraries.
Or you could use JScript.net, and get access to the .net libraries. .net includes a jsc.exe that produces exe-files.
Both of these requires the respective framework to be installed to be able to run.

Node.js is by far the best environment for running non-browser JS. I've used Rhino and SpiderMonkey, and there's a pretty huge difference in everything from the basics like how errors are handled to the size of the community using the tool. Node is pitched for "server-side" JS - building server apps in JS. It's great for this. But it works equally well for building command line tools.
The NPM package manager (bundled with Node) provides a nice global directory for finding and installing packages. It works much better than other language equivalents like PECL / Pear / CPAN / etc. Several high quality tools like JSHint, The Jade templating language, and the CoffeeScript compiler are all already available through NPM/Node:
npm install -g jshint, coffee-script, jade
jshint my_code.js
jade < my.jade > my.html
For args parsing, there are packages like commander.js. I currently use a heavily extended version of Commander in my underscore-cli command-line tool.
For messing with JSON or for doing command-line JS work (similar to "perl -pe"), check out underscore-cli - It's a really powerful tool for processing JSON data, processing underscore templates, and running JS expressions from the command-line. I use it for 1001 different things that would otherwise be really annoying to accomplish.

Rhino is bundled with JDK 1.6, jrunscript.exe in the bin directory will allow you to run any Javascript you want. Since it runs under Java you get access to any Java libraries that you may have.
We use it from the command line extensively. It's very good at that.

One way is to write these utilities as AIR applications - They can be written in JavaScript and need not have a UI. They have access to the command line, and there are existing ActionScript 3 libraries that can handle FTP etc. These ActionScript APIs can be called from JS, in AIR applications. AIR applications also have access to a sqlite database.

jslibs is a good standalone JavaScript runtime that support many 3rd party open source libraries like zlib, SQLite, NSPR, libiconv, libTomCrypt, OpenGL, ...