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).
Related
I am looking for a way of controlling translation format for Purescript code when target platform is JavaScript.
"spago bundle-app" generates JavaScript code for ES5 version.
spago/pulp/purs --help doesn't tell much.
googling by keywords like "Purescript codegen target ES6" is not helpful either.
Some discussions regarding ES6 and Purescript popped up among results but nothing practically useful.
I've found lebab tool translating ES5 to ES6,
but I guess it is not right way to go.
The PureScript compiler creates mostly ES3 code. This is on purpose because Ecma Script is strictly backwards compatible and ES3 code runs in a ES5-, ES2015-, ES2016- (and so on) environment. This means that code created by the PureScript compiler runs even in older browsers.
If you are coming from TypeScript or Babel, you might be used to being able to choose the target. This is because these compilers work with plugins that run after each other. But the PureScript compiler does not have such a feature (since it is not transforming JS to JS like these specific compilers).
So what can be the benefit of targeting a newer version? Code size, performance and features. If you want to use new ES2015 features in your FFI code there is great news: You can make use of these features now in PureScript 0.13. There are also talks about making the compiler target newer JavaScript environments in the future for the benefits mentioned above. If someone would have to support older environments they could still add Babel to their toolchain. But PureScript is a small community project and neither performance nor code size are of a very high priority for the project (and if they were, there would probably be other optimisations that could yield much greater results).
Is there a page somewhere that allows me to write short snippets in Scala and to check the corresponding (possibly optimised) JavaScript spit out by the Scala.js compiler?
Would be great for short demos to friends and colleagues.
ScalaFiddle supports this feature, although it's hidden. Write your code on the left, then hit Ctrl+J. The optimized generated code appears on the right. Note that it's the code for the entire app, so there's a lot there. Usually a good starting point is to Ctrl+F for function $c_LScalaFiddle$().
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'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.
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...