I'm developing in CoffeeScript and want to start to use Underscore.js. I know that any JS library will work in CoffeeScript.
Online there is the regular UnderscoreJS and also a CoffeScript version. Are there any difference in implication of the two? Is it perfectly ok to use the underscore JS version for my CoffeeScript needs?
You'll want to use the JavaScript version. The CoffeeScript version was likely just the author playing around with CoffeeScript, which makes sense since he is the author for both CoffeeScript and Underscore. Also, the CoffeeScript version introduces a compile step (assuming you are using this in the browser rather than on the server with node.js).
As another option, check out Lodash. It is a drop-in replacement for Underscore and for many reasons is the better option. It just released v1.0 in the past few days.
Usually when you are developing in Coffeescript, you are going to need something to compile your various Coffeescript files together to Javascript so that a browser can run it. How you want to use the library determines which version you will use.
Option 1: Manually add the Underscore library (in JS form) as a <script> tag in your page and also add your compiled coffeescript as a <script> tag. Quick and easy dirty way to get things to work, but results in a buildup of <script> and <meta> tags as you add more libraries/styles to your page, and spaghetti code.
Option 2: Use a tool to compile all your Coffeescript and CSS into a single JS/CSS file, which you then reference in your HTML. Then you would use the Coffeescript form of Underscore and compile that with the rest of your code. This is the approach I use, with the additional advantage of being able to use tools like npm to manage dependencies. Additionally, it allows you to have a test web server that compiles your code in real time as you edit the Coffeescript. Check out my post on using hem, npm, (and Spine).
For option 2, something else you can check out is requireJS.
Related
So the question is may I set yadda for ember tests to generate .coffee files instead of .js for steps?
Js is ok, but I have ember-cli with coffeescript so it'll be easer for team use one language instead of two
The whole Ember ecosystem is based around using JS instead of coffeescript. There were some early discussions about making blueprints easier for teams to change by default, but there is nothing like that right now.
I'd suggest considering shifting to Aja's as a team instead if that's doable, you'll save yourself a lot of headaches long term ...
I am new for ReactJS. Should I go with JSXTransformer or Babel for writing ReactJS code?
I understand that ReactJS implementation is not depend on JSXTransformer / babel. We can use ReactJS without these two too, but still I want about this with respect to ReactJS.
This is opinion based so should probably be closed.
Pretty sure the React team have deprecated the use of the JSX Transformer (outside of in-browser development usage) in favour of Babel. Babel now supports everything that React needs (and more) in a convenient and standard way and should be considered the preferred method of JSX transformation.
More information on React tooling can helpfully be found at their tooling page.
Matt Styles is right, it's beeing deprecated:
from here
JSXTransformer is another tool we built specifically for consuming JSX
in the browser. It was always intended as a quick way to prototype
code before setting up a build process. It would look for
tags with type="text/jsx" and then transform and run. This ran the
same code that react-tools ran on the server. Babel ships with a
nearly identical tool, which has already been integrated into JS Bin.
We'll be deprecating JSXTransformer, however the current version will
still be available from various CDNs and Bower.
However it is great to learn the basic of react, focusing on component methods, passing props, etc.. with a easy integration.
But i believe you won't be able to require any node modules, wich will block you soon or later.
To learn React and the node environnement, I suggest you to make a few tutorials, and to test and read the code of simple boilerplates project like these:
react-hot-boilerplate
react-transform-boilerplate
I mentioned on Twitter that I was moving from es6-shim to babel. Someone else mentioned:
the shims are still needed even with babel. they fix broken builtins, ones babel's output uses.
So:
Does babel need es6-shim or similar?
If it does, why doesn't babel require these things as a dependency?
Answers with references preferred over 'yes / no' with no supporting arguments!
Babel, at its core, does a single thing: convert syntax from one form to another.
Some of Babel's syntax transformations introduce dependencies on ES6 library functionality. It doesn't concern itself with how that functionality got there because:
The system might already provide it
The user might only want to load specific pieces of a library
There are many polyfills and the user might have a specific one it wants to use.
It is the developers job to ensure that the transpiled code is running in an environment where all the functions it needs actually exist.
Babel should work fine with es6-shim if you'd like to keep using it.
Babel also exposes babel/polyfill as a dead simple way to load a polyfill, which loads core-js, another polyfill like es6-shim. Just:
require('babel/polyfill');
Some Babel transformations rely on objects or methods that may not be available in your runtime environment and which you therefore would want to polyfill for those environments. Those dependencies are documented at https://babeljs.io/docs/usage/caveats/.
Babel ships with a polyfill that satisfies all of those requirements that you can opt-in to if you want, and doesn't attempt to automatically insert polyfills for the reasons that #loganfsmyth explained.
If I am going to develop using Coffeescript I will need to know what browsers are supported by the coffeescript JS code - I'm sure there will be a webpage somewhere on the subject :)
CoffeeScript's motto is "It's Just JavaScript." That means that if you write CoffeeScript code that invokes a feature that only exists in newer browsers, the JavaScript output will depend on that feature. CoffeeScript's own syntactic features, such as class inheritance and array comprehensions, generate code that's compatible with all major browsers going back to IE6.
Update: I now realize you were specifically asking for browsers which support the Coffeescript compiler. I have no detailed information about that, but considering the wide usage of Coffeescript my answer would be most of them.
No browsers support Coffeescript directly, although there may be some magic javascript snippets available that could compile Coffeescript to Javascript on the fly when a browser loads the page.
The usual workflow however is to compile Coffeescript to Javascript, and then only feed the browsers the resulting Javascript files. "Compile" may not be the proper word either, as it is more or less translating one set of source code (Coffescript) to another set of source code (Javascript), which is then parsed and sometimes JIT-compiled to execute in the browser (Spidermonkey, V8 etc).
we all agree that when we use GWT, we compile our application on the server, several javascript file are created. Normally, when deploying, we would use the obfuscated mode.
Now modifying a javascript file in obfuscated mode is almost impossible. Now what happens if we want to make some modification in our GWT application.
Do we have to go back again in Java, modify the file, compile, and then deploy again??
I'd say yes... If you use a code generator you should avoid modifying the generated code by hand.
No, no, no.
You don't "go back" to the Java code to modify it. You simply debug, test and modify the Java code. You ignore the code in the compiled javascript files except to deploy it. As far as you are concerned, GWT source code is Java code, not javascript, written within the environmental restriction of the browser.
Your question is like asking, "I have a C application that gets compiled to object code. Do I modify the object code or go back to the C code to modify it?" !!!
You simply treat the generated javascript as "native code".
No doubt you can include javascript using jsni, and so can you include assembly code when using C. So except for those assembly code you inject and similarly except the javascript code you include, you leave the "native code" alone.
When you try to modify the object code generated from C, that is called hacking. Hacking is an interesting hobby but when you wish to create an application and your main task is not "hacking", hacking would only be your extra-curricular activity not connected to your main employment or project.
Go back to the beginning: http://code.google.com/webtoolkit/overview.html
...Write AJAX applications in Java and
then compile the source to highly
optimized JavaScript that runs across
all browsers
When you're ready to deploy, GWT
compiles your Java source code into
optimized, stand-alone JavaScript
files that automatically run on all
major browsers, as well as mobile
browsers for Android and the iPhone.
While debugging: if you are running in development mode you may not even have to redeploy while in dev.
Thanks to the GWT developer plugin,
there's no compiling of code to
JavaScript to view it in the browser.
You can use the same edit-refresh-view
cycle you're used to with JavaScript...