I am new to es6 and have two questions
Is transpiling really required for backend code (node.js) written in es6 ?
If transpiling is not necessary - is there a disadvantage running plain es6 on server side - can it affect debugging ?
Answer can be debatable. I strongly feel there is no need of transpiling your backend code (NodeJS). Transpiling converts your import/export statements to require, module.exports. Which you can directly use in NodeJs.
Also, on client side, it makes sense to have transpilation for different browser support and also it reduces the bundle size. But for NodeJS side, there is also a disadvantage for debugging.
Related
I'm trying to upgrade an angularJS project and I'm stucked on one question, but let me summerize the project:
We use AngularJS, gulp and node 8.
we currently cannot use the ES6 features, like arrow functions, const/let and so on.
I achieved that by installing babels plugin. But babel transpiles the code, and the company staff doesn't want that, cause it can make it difficult to debug on production(I know we can use sourcemaps, it will be suggested).
We just want to write ES6 code and read(on the browser) the same code as we do now (but with es5)
I upgraded node to 10 and I thought that by upgrading node, the app would accept the new ES6 features. But still crashes when using es6 syntax.
Can someone tell me why? If the browsers accepts, why gulp doesnt?
I was learning babel and webpack and then it turns out I need to install node.js to run them both and I asked myself WHY? Then according to my research, we need node.js for webpack and babel since both of them were written in JS and to run that JS code which transpiles( for babel) and bundles up the code(for webpack). Also, another reason is that since both babel and webpack handles our JS code outside of the browser, this is the reason to use Node.js. Are these reasons true?
According to the Node.js website -
Node.js® is a JavaScript runtime built on Chrome's V8 JavaScript engine.
Webpack and babel (along with many other tools you might use for frontend development) are written in javascript and since they are command line tools, they need a way to run outside of the browser (directly on your machine).
They could have used some other language to write the tools but since they chose to write them in javascript, Node.js is the only feasible options right now.
In case you are interested, the original creator of nodejs
Ryan Dahl has built another secure runtime environment for Javascript/Typescript called Deno
Yes, at the moment the node.js project is non-portable by full open source disclosure nor extension to port node.js commonjs without a just in time transpiler with a service worker on a server.
Definitions: FHC = "from half court"
Babel and webpack
(1) transpile/move (write&read, not ln -s sym...bolic link) & (2) compost/pile onto a JIT target,
like v8 or other browser-javascript-interpreters. v8 on a service worker can compile on the edge just in time for interpretation in a browser v8 environment but still on the cloudflare edge server.
Declare (FHC) Allegedly, rust provides webassembly modules with the lipid [llvm-]wrappings
that nucleic acid exocytosis needs to be a full-blown virus, err I mean
Initiation Routine needs to be a targetable JIT extension!
A compiler/transpiler still requires it's target-scope receivable. Declare (FHC) Emit is to execute as compile is to interpret, even AST.
After stumbling upon the typscript-node starter released by microsoft, i started to get lost.
Can we really replace node with typescript on the server? There are several serverside things that TS does well:
- Creating a web API service with express
- Managing the CRUD queries with mongoDB
And much more...
I am used to generate an api with node and connect angular to that api. Am i wrong?
Should we switch to TS on the backend and forget about writing node code on the server?
Typescript is a (or rather, a superset of) language - not a runtime. It is the equivalent of Javascript except it needs to be compiled to run on the Node.js runtime.
You can write the backend with Typescript if you want, and then run it through ts-node, or just compile down to ES6 via tsc and then run it with standard Node (v8+ is recommended). This is what I do with many projects. It is still "node code", it just has all the benefits (and gimmicks) or Typescript.
I recommend the library meseret to manage your typescript node.js backend code. It has support for Koa, Mongoose and Socket.io, with many builtin configurations. It is a great way to manage things in one place, using TypeScript throughout your project.
Considering that Node v6.x comes with ~93% coverage of the ES2015 spec, is Babel transpiling required anymore?
I am creating a web application with Node v6 and Express. If this were merely a Node app, I wouldn't have thought about Babel, but considering that there is going to be some client side JS as well, I'm thinking I should have the static JS files transpiled. Is this a correct assumption?
If required, what would an example .babelrc be?
Currently, I'm thinking:
{
"presets": [
"node6",
"es2015"
]
}
Your server-side code and your client-side code have nothing to do with each other. The fact that you run Node.js v6 on the server has no bearing on what will be running your code in a browser.
If you want to use ES6 features with broad browser coverage, you need a transpiler for the client-side code.
I setup a website with regular client side RequireJS today. Than I did some research on node, got that installed and setup my first module in node. When I setup the first require, I loaded the Require.JS file and I get all that. The thing that is confusing me is, I created a file called test.js and within that I am including:
var require = require("requirejs");
which is actually including the node require, not the original require library I was using right?
So like are they completely different? Can they used together?
Doesn't Node already have a module loader?
Yes Node does.
That loader uses the CommonJS module format. The
CommonJS module format is non-optimal for the browser, and I do not
agree with some of the trade-offs made in the CommonJS module format.
By using RequireJS on the server, you can use one format for all your
modules, whether they are running server side or in the browser. That
way you can preserve the speed benefits and easy debugging you get
with RequireJS in the browser, and not have to worry about extra
translation costs for moving between two formats. If you want to use
define() for your modules but still run them in Node without needing
to run RequireJS on the server, see the section below about using
amdefine.
Source: http://requirejs.org/docs/node.html#1