I don't know with web apps if you still have to use Babel if Node 4 is out which supports ES6 so why would I need babel anymore for any web related code? Or maybe I don't?
I see most apps are using babel but I wonder if people are pulling it out now or is there middleware people typically use in web apps that still rely on it, thus you have to keep it and keep using babel?
Node v4 doesn't support the full feature set of ES2015 (aka ES6). For those that aren't supported you still can use Babel. You can find a list of node's support of ES2015 features in this page.
You say "web related code", which is too broad, but I assume you're interested in browser support as well. No browser supports all ES2015 features yet, so you should use a transpiler like Babel. You can find a table of feature compatibility here.
You will also find that no transpiler has full support either, so be careful when introducing new features.
It's not likely that projects will stop using transpilers yet. Even less so if they want to support older versions of node.
Related
Recently I was create react app using vite , it is lightweight , less config and fast then compare with webpack . now my question is , is it required bable configuration in Vite project
No, vite does automatic syntax transforms but it only targets browsers that support es modules (firefox & chrome started supporting it around 2018). If you want to support new js features in older browsers you need to add polyfills though. You can read about the exact behavior and how to support even older browsers here.
I think that question need more information about that topic.
Vite.js uses the built-in JavaScript support of the browser, so you don't need to explicitly configure the JavaScript version in Vite.js itself.
When I said Vite.js uses the built-in JavaScript support of the browser, I meant that Vite.js relies on the JavaScript engine of the browser to interpret and run the JavaScript code in your application. The JavaScript engine is the component of the browser that executes JavaScript code. When you visit a web page that contains JavaScript, the browser runs the JavaScript code using its built-in JavaScript engine. This means that the version of JavaScript that is supported by your application is determined by the version of the JavaScript engine that is built into the browser. In the case of Vite.js, the JavaScript code in your application is not transpiled or otherwise modified before being run by the browser. However, if your application uses modern JavaScript syntax that is not supported by the target browsers, you will need to transpile the code to an older version of the language that is supported. In that case, you can use Babel.
No, it is already setup on the background. However if you'd like to adjust Babel's config you can do it. Read the docs here: https://github.com/vitejs/vite-plugin-react/blob/main/packages/plugin-react/README.md
What module to use in tsconfig, commonjs or es6?
How to make desicion? I need that output module will work in client/back sides.
So here we are talking about the module option that will be used by typescript to determine what is the name of the module that will compile your code to the targeted version of javascript you specified with the option target.
So the underlying question you are asking is, what is my target ? Should I target ES3, ES5, ES6, ES7, ES8 or ... ES42 ?
Answer : the compatibility.
In 2020 you propably target ES5 or ES6 (which is the default value).
(You can ignore CommonJS because it relate to ES3 which is 99% chance irrelevant to you)
some article
If your code is made to be executed on browsers, I would recommand you to look which is the latest version supported by all your targeted browser and take the one that is supported by all.
Ex: Safari ES6, Firefox ES8, Chrome ES8 : so you choose ES6 as target so your code works on every targeted browser.
The website caniuse.com is usefull to know which features are supported and which are not
If your code is made to run on backend (node.js), look at which version of node.js is running. Every version of node have different capabilities.
You can have a look here
Additionnal materials :
What version of Javascript is supported in node.js
I have several backend-only Node.js projects which use a simple TypeScript config.
Before March 2018, I had this in package.json:
"devDependencies": {
"#types/core-js": "^0.9.46",
"#types/node": "^9.6.2"
}
since ~March 2018, I have been omitting "#types/core-js" and everything seems to compile fine. Do we need "#types/core-js" anymore?
I have several Node-based projects written in TypeScript. I never ever used #types/core-js in my projects. So it is definitely not necessary to use #types/core-js in order to write Node-based code. Having #types/node, on the other hand, is a boon if you're going to use Node's API.
The first thing to do if you run into a compilation issue that appears to be caused by the compiler not knowing about features introduced in ES6 is to set lib to load the proper typings you need. For instance, if you decide to target es5 but want to use methods, classes, functions introduced in ES6, you do need to specify "es6" in your lib setting because by default the target es5 loads the lib es5 too. (According to the documentation, a target of es5 sets lib by default to DOM,ES5,ScriptHost, whereas a target of es6 sets lib by default to DOM,ES6,DOM.Iterable,ScriptHost.)
I've run into some very rare cases where there's something missing in the es6 lib. In such cases, I just write a definition to fix that specific problem. Loading #types/core-js might also fix the issue, but it also contains a lot of other things that are not necessary, and it adds a dependency to the project, which then must be managed, etc. Not worth it.
The focus above was Node projects, but even in web-based projects where I have a dependency on core-js I don't use #types/core-js. As I see it, the presence of core-js in a project should be entirely transparent to the project's application code. I'm writing code made to run on any platform providing an API that conforms to ES6 or later, I'm not writing code made to run with core-js specifically.
You should only need #types/core-js if you're using something that is in that declaration that is not available in your TypeScript declarations for your major version. This is useful if you're expecting to use core JavaScript ES6 features that are in core-js but were not implemented in the version of TS you were using at the time. There's more information available on the TS GitHub related to your question but in all reality if you're just using ES stuff that's there now, no you shouldn't need it anymore.
edit: Before I had stated it as node, but in all possibilities since it's TS it probably didn't know how to compile to the target without the declaration. As of TS 2 and NodeJS 6 you shouldn't really need it anymore.
I am going to start a new long-term project and I am responsible of API development.
I decided to use Loopback due to its various features for API rapid development, but it is now built with es5 in contrast of Loopback4
that will come with ES2017 and many modern tools as I see but still in Pre-Beta version.
After some search I found some trials in using ES6 with Loopback3:
This question Loopback models in ES6
and this issue https://github.com/strongloop/loopback/issues/2083#issuecomment-281201056
and no complete/official solution.
Also I think that the feature of upgrade from 3 to 4 will not be available.
The question is: should I use Loopback 3 now with es6 and Babel.
OR use another tool for the current project to avoid refactoring/rebuilding in future, and wait untill Loopback4 is released
When developing front-end code for the browser, I often use the es2017 preset when transpiling down to a distribution bundle, which allows me all the conveniences of the included transformers. For conventional modules, I usually stick to whatever the required node engine I've specified for that particular module supports.
I would like to start developing these "conventional" modules using babel transformers as well, but I can foresee drawbacks to this, including:
It might inhibit the debugging workflow (more specifically when working with an IDE)
The performance of the module might suffer
What's the current state on this matter - would you say it makes sense to use babel in conventional modules given the aforementioned and other trade-offs? What are the pros/cons for your preferred workflow?
Bonus question: What are some reputable modules and/or module authors out there that are already using this technique? I've seen Facebook do it for their react ecosystem but I guess that makes sense since those are mostly modules for the browser.
It is converted back to vanilla JS (babel does that part).
What you get is that you can utilize Classes which I found useful.
Hopefully with time, browsers will support ES6 and we will not need babel.
The only drawback is that when debugging, you have to produce a source map, but that is temporary, see above.
To answer your second question: I'm using React in one of the websites, and most of the modules I needed (from npm) are using ES6.
I believe that the trade-offs or drawbacks that you mention both do not apply to developing nodejs code using babel as ES7 transpiler. Personally, I find using ES7 features with node tremendously productive.
There is source map support for debugging. I use karma for testing and it comes with excellent source map support (I use IntelliJ but I believe most IDEs will do). You can checkout this REST-API repository on github. It's a nice stack for building nodejs data backend. It uses karma for testing - even comes with code coverage support. It also integrates with pm2 for scaling and availability.
Regarding performance: I think transpiled code has been shown to run faster in many scenarios than the code a developer would write when not having advanced language features available. I will post some links later.