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
Related
I am totally new to creating extensions in VS Code, and all the official examples of extensions are written in Typescript/Javascript, which I have no experience with. Is it possible to create VS Code extensions in other languages, such as Python or C++?
If so, could anyone point me to any resources to get me started?
It is possible by creating a C++ module for Node.js, which can then be loaded like any other node module. Of course, some glue code written in JS or TS is necessary to register the extension and translate calls to/from vscode.
I've gone this way in my ANTLR4 extension, but gave up eventually, because of the troubles I had due to incompatible dependencies (you have to make sure the extension uses the exact same V8 version, which was used to build the underlying Node.js used by vscode, on all supported platforms).
This situation might have change, I don't know, but with that in the background I don't recommend it.
If you want to add support for a new language in vscode you can also write a separate language server, as is mentioned in the linked SO answer. For other type of work, I'm afraid, you have no alternative to use.
No, as #rioV8 said, since VSCode is an electron app and runs on Javascript.
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 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.
I'm searching for a tool to generate documentation for coffeescript AND reactJS both together.
I found multiple things for JavaScript, ReactJS or CoffeeScript (eg: codo).
I'm also using brunch to glue files and to use exported modules in separated files. Codo is very good but seems not really adapted for exported module and ReactJS.
Before going futher and after searching existing tools. Does someone knows a magic wand ?
Finally, it seems that nothing exists. Thus I built one very naive implementation here.
https://github.com/kursion/broffeact
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.