Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
Everyone these days is forcing typescript. There are so many fans and articles about it. Angular team is making their framework in TS.
But my experience with migrating ES6 to TS was very disappointing.
I tried to migrate our relatively fresh codebase (writen in ES6) to Typescript last month and faced a ton of pitfalls!
To be clear, we are talking about node.js application with mocha unit tests and ESLint configured (using babel to transpile).
First of all, to empower type checking I set up noImplicitAny option,
got hundreds of errors and fixed it. But after that, I got typing errors due to typescript does not understand some node.js predefined modules, like stream (The problem is actually bigger, due to lack of typings for a lot of modules).
After that, I installed typings - recommended replacement for tsd tool for manage library d.ts files, but it's node typing definition , while resolving stream problem, added a lot of errors because it duplicates some predefined types.
In addition, I found out that typescript actually does not compile many features of ES6 into ES5 actually, such as generators.
It forced me to make complex build process (TS -> (typescript) ES6 -> (babel) ES5), and it means that I have to waste my original source maps.
All above took a lot of time to configure.
So, I'm confused. I really love the idea behind typescript, but implementation seems so rude to me. I hope I'm wrong.
Maybe someone who used Typescript in real project, not HelloWorld one, could explain me what am I doing wrong?
I set up noImplicitAny option
You have very high expectations. For a better experience while migrating a project from ES6, just don't use this option.
I got typing errors due to typescript does not understand some node.js predefined modules, like stream.
The JS libraries that don't have type definitions are a pain. But the implicit type any will save you.
After that, I installed typings […] added a lot of errors because it duplicates some predefined types.
Exclude the browser directory and browser.d.ts from your tsconfig.json.
In addition, i found out that typescript does not compile many features of ES6 to ES5 actually, such as generators. It forces me to made complex build process (TS -> (typescript) ES6 -> (babel) ES5), and it means that I have to waste my original source maps.
It's the design choice that makes TS really robust: the compiled code doesn't need any runtime library.
But why do you use Babel on your generated ES6 code? With Node.js 4 or 5, your ES6 code will work fine.
Is typescript robust enough?
As much as the JavaScript VM are.
TypeScript with the target ES6 on Node.js
Since TS 1.7, the option --module can be used in association with the target es6. Example, in tsconfig.json:
"compilerOptions": {
"module": "commonjs",
"target": "es6",
}
NB: Since TS 1.8, modules are emitted with a "use strict"; prologue.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
I am looking to working on a project using node js addons with C++. I came across two abstract library NAN and N-API that I can use. However I am unable to decide which one I should use. I was not able to find proper comparison between these two libraries.
What are the pros, cons and differences of both? How to choose between them?
So far I have found that NAN has more online tutorials/articles regarding async calls. But N-API is officially supported by Node (and was created after NAN as a better alternative, although not sure.)
My understanding is this:
The Node-API (formerly N-API) was added to the core node.js interface in v8.0.0. "It is intended to insulate Addons from changes in the underlying JavaScript engine…" to quote the documentation. It also provides some other wrappers around things like buffers and asynchronous work (which should help avoid some of the underlying non-stable APIs noted in their Implications of ABI stability section).
nan (Native Abstractions for Node) is indeed older and so also supports older versions of node.js — back to node.js 0.8! Now despite its author claiming back in 2017:
As I mentioned somewhere else, N-API is not meant to be directly used for anything. Where has this notion come from? It is an (effectively internal) low-level infrastructure layer meant to offer ABI stability. There will be another layer on top.
…I do not see much warning to that effect in the official Node.js add-on documentation. Perhaps this other comment is a bit more insightful:
Yes, you should still use NAN for production use. It covers every relevant version of Node.js. Also note that N-API is not intended for end users. You should eventually use https://github.com/nodejs/node-addon-api.
Again, that was in June of 2017 by the maintainer of nan at the time. It seems that node-addon-api has matured in the meantime and remains active. In fact, I found a comment in the -addon-api repo that is only a month old at present:
…part of the goal was to make it easy to transition from nan.
So I think the answer is:
use nan if you want something mature and very backwards-compatible
use node-addon-api if you want something forwards-looking in C++
use Node-API/N-API if you are comfortable working in C and dealing with possible lower-level concerns
You should use the node-addon-API module for new C++ code (or N-API for C code). All supported (non-EOL) versions of Node.js support it, and it makes maintaining and distributing native add-ons much easier: whereas addons using NAN require rebuilding the module for each NODE_MODULE_VERSION (major version of Node.js), modules using N-API/Node-Addon-API are forward-compatible:
A given version n of N-API will be available in the major version of Node.js in which it was published, and in all subsequent versions of Node.js, including subsequent major versions.
There's a somewhat confusing compatibility matrix here. N-API version 3 is compatible with Node.js v8.11.2+, v9.11.0+ and all later major versions (v10+), for example.
On top of that, node-addon-API fixes a lot of the annoying parts of NAN (like Buffers always being char* instead of, say uint8_t*).
NAN still works of course, and there are more learning resources online, but node-addon-API is the way forward.
This question already has an answer here:
Node.js plans to support import/export ES6 (ECMAScript 2015) modules
(1 answer)
Closed 5 years ago.
Just wonder how do we import a module in node.js 8 - are we still using require?
Or do we still need babel for using import?
I have been digging around but seems no answer. If we still have to use require, why can't node implement import yet?
UPDATE-2018.11.15 ↓
Short answer
We're still using require
Long answer
ESM loading has partially landed in node 8.5.0 which was released in September 2017. As such, it has beeen part of the specs as an experimental feature for a little while: see the API documentation here. Caveats include the need for the --experimental-modules flag and the use of a new .mjs extension for modules.
There is still changes that need to happen in V8 before ESM loading is stable and fully featured so as with my original answer, I would still advise on sticking with CommonJS require if you don't already use Babel for other stuff
See this post for a more didactic explanation
PREVIOUS ANSWER ↓
The two implementations are completely different under the hood, so there is more to it than what meets the eyes
The takeaway is that there are still lingering issues/questions over the specifications (all the way to V8), and as such import cannot currently be implemented in Node without a using a transpiler
See this comment (dated February 2017) from one of the contributor:
At the current point in time, there are still a number of specification and implementation issues that need to happen on the ES6 and Virtual Machine side of things before Node.js can even begin working up a supportable implementation of ES6 modules. Work is in progress but it is going to take some time — We’re currently looking at around a year at least.
Keep in mind that transpilers simply converts the ES6 module syntax to the CommonJS module syntax, so there is currently no performance benefits. In other words, if you don't have a Babel pipeline already, there is not much incentives to create one just to use the new proposed import syntax, except from a proactive syntactic perspective
For more details on how the implementation differs, see this write up
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
Firstly I apologise for the long post. I have been asking a few questions about haxe and its suitability as a tool to solve a problem I am facing. I have very limited knowledge of haxe but what I do know is my ideal role for haxe in my project is not the normal use of haxe. So what I'm trying to avoid is wasting time I don't have learning this language (despite it looking really fun and powerful) only to find that it isn't fit for purpose. So I am hoping to get some advice from you haxe seasoned vets on whether it is fit for purpose. I truly hope that it is.
Here is what I am trying to achieve:
I work in the games industry and I need to create a game in both C++ and JS. C++ for an embedded system and JS for online and mobile. I am very experienced in both C++ and JS.
The games I develop I only want to write the once. Now I could use something like emscripten for going from C++ to JS but this will result in compiled JS code that cant be debugged with chrome dev tools easily. I'm converned that I will run into edge case bugs with the compiled JS that I cant easily tace back to the original C++. Plus some platforms for the game would require fairness laboratories to view the source code which would be an issue for compiled JS.
What I really need is a source to source compiler that produces native and human readable c++ and JS code that I can then work with and modify in its native form if necessary, hence haxe. I've looked at the code produced by haxe for C++ and JS. JS looks perfectly easy to understand and work with. C++ not so much but still just about acceptable. I can even stop haxe from compiling and linking C++ which I dont need. I only want the source code.
So far so good.
Now I have a game framework in c++ that uses oxygine 2d engine. It is capable of showing sprites etc as well as a framework I have created for message buses and finite state machines (loads more useful classes too). I also have a similar framework in JS which uses Pixijs for its 2d engine and has its own message bus etc just like the C++ engine.
Now what I want to be able to do is write modules in haxe that when I transpile to both C++ and JS that the code can be included as part of the framework and work with its respected language engine. Each object I create in haxe will be very encapsulated and will just need to subscribe to the message bus, handle messages and send messages back. It may also need to know how to use its engines state machine. So I have no idea if this is even possible with haxe as the message bus (along with other objects) will not be written in haxe but will be supplied to the module after it has been transpiled and built in its native project. Maybe I can write my own haxe library that knows the syntax for my two game engines and can transpile depending on its target language? Not sure it that is possible.
Thanks for taking the time to read, and any advice you can give.
You can use
#if cpp
// c++ implementation
#elseif js
// javascript implementation
#end
to allow some different implementations for different targets, this can go anywhere in your code, so you can pass a Haxe value to different functions for different targets.
To use extern definitions:
http://haxe.org/manual/lf-externs.html
http://old.haxe.org/doc/js/extern_libraries
With c++ specifically it might be more complex you need to look at CFFI or Linc
https://snowkit.github.io/linc/
The complexity is probably getting the types across. Remember Haxe c++ has managed memory your engine might do things differently. Also HL is coming soon and may have some advantages.
Looking at oxygine2d it seems a bit like the Flash API? And I know pixijs is based roughly off the Flash API. I believe that OpenFL now uses pixijs for WebGL rendering. You might want to also look at NME ( has nearly same interface for C++ as OpenFL, but NME has stuff like Cppia setup and is sometimes more stable ). If the JS or C++ is too slow you need to look into shaders and Luxe/Kha for render and you might want to also try Heaps it uses Lime ( openfl ) and some haxe js webgl I think.
If you need 2D physics then use Nape it can be used with any of the Haxe toolkits (Luxe, OpenFL, Kha, Flambe), there is physaxe but that's not used as much. Kha and Nape info eg:
https://github.com/lewislepton/kha-examples/blob/master/NAPE/Sources/Project.hx
I really suspect that your making your life hard by wanting to use different engines for different platforms when probably HaxeFlixel or Punk could give you all you need running with Nape on one of the cross target toolkits, but it's very feasible to do it your way.
Maybe look at Tink or Thx for signals event buses and the like, macros (like used in Tink) allow a lot of structures to be built at compile and so can reduce much of the overhead by doing it before run-time, so tweens can be pre-calculated by the compiler. There is a hxcpp debugger and if you run Haxe in chrome it should give you the Haxe line number via js source mapping.
Hopefully I have covered some aspects of your large question.
Haxe allows you to mix and match with native, but I think to use Pixijs and oxygine 2d is probably not ideal as there is bound to be enough good game tools in pure Haxe with target optimizations built in, you just need to go onto Kha IRC, Luxe gitter, and Haxe IRC and OpenFL forum and ask a few questions.
Node.JS v0.11.3 claims to have support for ECMAScript 6 modules with the flag --harmony_modules.
I have tried various examples, such as the following.
module math {
export var pi = 3.141593;
}
What is the syntax to get modules working in Node.JS?
The modules implementation in V8 is incomplete. There's parsing support when enabled with --harmony-modules, but support of the actual functionality was put on hold. The reason for this is because the specification for how ES6 modules will actually work has been in the works and is still not fully nailed down.
The implementation in Continuum (the linked screenshot from Crazy Train's answer) dates back to an interim spec from November 2012 and is now woefully out of date because of the ongoing changes to the ES6 module's spec. This is why the V8 devs put development of support for modules on hold.
It seems like the modules spec is approaching stability (though I expect we'll see small refinements for a while) and I think (hope at least) that we'll see SpiderMonkey and V8 moving forward with implementations over the next 6 months.
Useful links:
V8 modules bug: https://code.google.com/p/v8/issues/detail?id=1569
SpiderMonkey modules bug: https://bugzilla.mozilla.org/show_bug.cgi?id=harmony%3Amodules
You can use Continuum, which is an ES6 virtual machine written in (current) JavaScript.
This is probably not the best question but I'm still completely new to JS. I'm interested in Typescript (being an AS3 dev), but I keep reading that I need to instal node.js to compile it? why is that?
TypeScript is a language that compiles into JavaScript. The compiler that does this, appears to be written (or at least distributed) in JavaScript. And node.js is the most common way to execute JavaScript outside a browser.
The typescript compiler is simply JavaScript, which is executed by node.js to compile things.
Why is that, you ask? Well, because that's what the developers of the compiler chose to write their compiler in. It could have been any language they wanted really.
The compiler is actually written in TypeScript. Yeah, a compiler written in the language it's supposed to compile, which may seem strange. But how that works is beyond the scope of this question.