How can I properly use jQuery and CoffeeScript? All of the examples that I have seen thus far compile the CofeeScript at runtime in the browser; this is not ideal. Normally, I'd simply write in plain old JavaScript, but I think CoffeeScript can allow me do get more done with less code, once I know how to get started. I've worked with JQuery before, but I've not used CoffeeScript. I'm not sure where to get started? Should I place $(document).ready in my external CofeeScript/Javascript?
Just have to put the jquery code after $ ->
Here is a small article about it, and if you are starting The Little Book on CoffeeScript is quite useful, it's very clear and goes from scratch
All of the examples that I have seen thus far compile the CoffeeScript at runtime in the browser; this is not ideal.
Agreed. You should look at projects like The Middleman that let you transparently compile your CoffeeScript to JavaScript on a local server for development, then bundle up the minified JS for deployment. (The Middleman also includes support for Haml and Sass, if you're into those, but you can just use HTML and CSS as well.)
The big advantage of The Middleman (or Rails, or any other web framework with CoffeeScript support) over just running coffee -cw is that the latest version of your compiled CoffeeScript is served every time you refresh the page; you never have to worry about waiting for background compilation to finish.
Related
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
If I wanted to port an existing project from Javascript to Coffeescript (in my case, within a Rails application), would I need to convert existing Javascript files? I'm worried about converting really large and CDN hosted files like jQuery and jQueryUI. How would I work around that?
As #asawyer stated, you do not need to port existing JavaScript libraries and such to CoffeeScript.
CoffeeScript exists to add convenience for writing your own custom code. Because the CoffeeScript compiles into JavaScript, it plays nicely with other JavaScript libraries like jQuery without your needing to convert those libraries into CoffeeScript.
If you have your own code that you want to convert into CoffeeScript, I've found js2coffee.org very helpful. It also serves as a great learning tool for "thinking in JavaScript" and seeing how it would be done in CoffeeScript.
Within rails, coffeescript is run through a compiler and into javascript anyway. You can include pure javascript files if you want (.js), or coffeescript (.js.coffee), which is compiled into js. If you're just looking to include legacy files, you won't need to do any conversion at all -- Might not make sense to convert to coffeescript, just to have rails compiler convert back to javascript in the asset pipeline... See http://guides.rubyonrails.org/asset_pipeline.html#coding-links-to-assets for more from the rails team on how to use js in the asset pipeline.
jQuery is already included in newer versions of Rails (3.1 onward), so that shouldn't be an issue. http://weblog.rubyonrails.org/2011/4/21/jquery-new-default/
Also, many other jQuery addons have a gem that you can simply include -- no need to reinvent the wheel there.
Yes, I know that less was in first place written for node.js.
But I really want to use it without adding node.js to my server, or learning how it works.
Is there some implementations of less written in other languages? Or maybe something similar to less?
You could take a look at SCSS. The compilation of files into CSS is done by a Ruby script which is very easy to get set up (even on Windows), and the syntax and feature list is almost identical. I'd even say that the documentation of SCSS is better than LESS.
That said, I have managed to get LESS compilation running locally by running the file in a Javascript engine (in my case, Komodo Edit's macro system is powered by Javascript, but it could work with Rhino or V8). You do have to modify the source a little, to simulate the window object. I got a lot of help by looking at the code of the Less Engine project, which basically allows Less to be executed within a JVM.
There is a Windows LESS compiler for .NET and a standalone version of it as well. I find this latter considerably better (i.e. fewer bugs) than less.js, although both are pretty odd in the way they handle comments: less.js doesn't understand two comments in a row, and lessc.exe doesn't understand comments inside selectors. I really don't see the point of compiling the .less file at the client once per page download per client when you could have done it once for the universe at build time.
There is also a Python implementation of SCSS: http://packages.python.org/scss/. It works quite well and includes a watch folder function.
There is very nice PHP class: http://leafo.net/lessphp/
Looking forward towards excellent javascript ctags support kept me thinking if a project like http://zombie.labnotes.org/ could be used to setup ctags to keep a vim user happy.
Hum, none of the projects you are citing are parsers or have anything to do with ctags.
PhantomJS let's you run your script as if it was run by a webkit-based browser. It won't output an analysis of your code, it will just execute it. You can use it to do a toSource() or a isPrototypeOf() on a function but that would be rather pointless.
JSDOM is an implementation of the DOM to use within your script. It can't be run as an external tool so it can't be used to generate tags or analyse your code.
Zombie.js is a testing framework that simulates a browser for you. Like JSDOM, it can't be run as an external tool and it has no ability to analyse your code.
You can feed your current script to phantomjs with :!phantomjs % or use zombie or jsdom in your script but none of it will help you have a better idea of the structure of your code or jump to the definition of a method.
However, if you use either zombie or jsdom or whatever other library in your project you can generate their respective tags files and add them to your .vimrc like this:
autocmd FileType javascript set tags+=path/to/a/library/tags
autocmd FileType javascript set tags+=path/to/another/library/tags
If what you want is a better/more modern tags generation you can try DoctorJS' jsctags or look at this thread for a more hackish way to make ctags work for you. As far as I know, these are you only options right now.
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