Why does TypeScript need Node.js? - node.js

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.

Related

Is there any way to compile AssemblyScript without node.js nor npm? Preferrably a standalone compiler that I could call from another program?

I have been searching some way to compile AssemblyScript without node.js. I have not found it and it is a tragedy because I really could use it to dynamically generate some special web assembly from other programs, for example, from a PHP program, in environments where node is not supported (like many shared hostings). I have the intuition that the compiler does not actually require node at all, that it must be written in some other language, but I have not found any way to install the compiler at all.
Do you have any idea of how to use it without node?
There is a way to do what you want, but it does not get rid of node completely.
The AssemblyScript README.md about the asc compiler lists two ways of building the compiler: the usual compilation to JavaScript, and a bootstrapping process, where you compile asc to WebAssembly by compiling it to JavaScript and then using that compiler to compile it to WebAssembly.
The caveat is that, at least initially, you still node to obtain the compiler from sources.
A second caveat is that the frontend for asc is JavaScript only, for now. You can use the WebAssembly binary only as a library, which may be actually what you want, given your use-case.

Using haxe as a transpiler between c++ and JavaScript [closed]

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.

Can I write a CoffeeScript lib the same way for the server and client?

I'm trying to write a modular library in CoffeeScript. I want to write the code once, and use it in the same way on the server (running Node in this case) and on the browser. How can I do this?
My code structure is like this...
src/a.coffee
src/b.coffee
src/c.coffee
And my dependencies are like this...
a depends on b, c depends on a and b.
I've tried Browserify and requirejs, but I couldn't quite get there with it. I've also looked into Traceur but that's no use since I'm using CoffeeScript. I'm really at a loss, the only thing I can think of, is bundling it all up in one file and doing it traditionally as explained in this blog... https://alicoding.com/write-javascript-modules-that-works-both-in-nodejs-and-browser-with-requirejs/. I really don't want to do that, I'd probably just write it in Dart sooner than I would bundle it up like that. CoffeeScript is really letting me down with this particular issue.
I forgot to resolve this. I ended up using https://github.com/jrburke/amdefine.

Haskell to Javascript compilers?

I've recently came across ghcjs haskell-to-javascript compiler, but I am not sure how "ready" it is. It seems to have little activity over the last year.
Is there an equivalent to GWT in Haskell?
Also, more of a discussion question:do you think there will be a gwt haskell equivalent? Why or why not?
There are several such compilers which can be used right away.
Fay (formerly at http://fay-lang.org/, now on https://github.com/faylang/fay) The most popular and the most developed Haskell -> JS compiler. AFAIU, it implements Haskell from scratch and compiles it to JavaScript. It doesn't implement many of GHC's features, especially language extensions.
Haste (https://github.com/valderman/haste-compiler) It uses the backend of GHC to compile to javascript. As a result you can use it to compile extension containing code.
Ji seems relevant, although it doesn't do any Haskell-to-JS compilation; it lets a Haskell server control a browser connected to it via AJAX.
It seems like UHC supports compiling to JavaScript and has some libraries along those lines, but I don't know what UHC's compatibility with GHC extensions is like, or how mature the support is.
I'm not convinced compiling full Haskell to JavaScript is a productive route; the overhead of implementing the likes of lazy evaluation on top of a high-level language is likely to be significant, and all the attempts so far (I haven't checked out UHC's generated code) seem to produce rather huge JavaScript (admittedly, HTTP compression mitigates this).
I don't think ghcjs is being actively developed, but it might be more stable than UHC's support. Yhc's support seems to be the furthest so far, but unfortunately Yhc is a dead project.

The right language for OpenGL UI prototyping. Ditching Python

So, I got this idea that I'd try to prototype an experimental user interface using OpenGL and some physics. I know little about either of the topics, but am pretty experienced with programming languages such as C++, Java and C#. After some initial research, I decided on using Python (with Eclipse/PyDev) and Qt, both new to me, and now have four different topics to learn more or less simultaneously.
I've gotten quite far with both OpenGL and Python, but while Python and its ecosystem initially seemed perfect for the task, I've now discovered some serious drawbacks. Bad API documentation and lacking code completion (due to dynamic typing), having to import every module I use in every other module gets tedious when having one class per module, having to select the correct module to run the program, and having to wait 30 seconds for the program to start and obscure the IDE before being notified of many obvious typos and other mistakes. It gets really annoying really fast. Quite frankly, i don't get what all the fuzz is about. Lambda functions, list comprehensions etc. are nice and all, but there's certainly more important things.
So, unless anyone can resolve at least some of these annoyances, Python is out. C++ is out as well, for obvious reasons, and C# is out, mainly for lack of portability. This leaves Java and JOGL as an attractive option, but I'm also curious about Ruby and Groovy. I'd like your opinion on these and others though, to keep my from making the same mistake again.
The requirements are:
Keeping the hell out of my way.
Good code completion. Complete method signatures, including data types and parameter names.
Good OpenGL support.
Qt support is preferable.
Object Oriented
Suitable for RAD, prototyping
Cross-platform
Preferably Open-Source, but at least free.
It seems you aren't mainly having a problem with Python itself, but instead with the IDE.
"Bad API documentation"
To what API? Python itself, Qt or some other library you are using?
"lacking code completion (due to dynamic typing)"
As long as you are not doing anything magic, I find that PyDev is pretty darn good at figuring these things out. If it gets lost, you can always typehint by doing:
assert isinstance(myObj, MyClass)
Then, PyDev will provide you with code completion even if myObj comes from a dynamic context.
"having to import every module I use in every other module gets tedious when having one class per module"
Install PyDev Extensions, it has auto-import on the fly. Or collect all your imports in a separate module and do:
from mymodulewithallimports import *
"having to select the correct module to run the program"
In Eclipse, you can set up a default startup file, or just check "use last run configuration". Then you never have to select it again.
"before being notified of many obvious typos and other mistakes"
Install PyDev Extensions, it has more advanced syntax checking and will happily notify you about unused imports/variables, uninitialized variables etc.
Looking just at your list I'd recommend C++; especially because Code Completion is so important to you.
About Python: Although I have few experience with OpenGL programming with Python (used C++ for that), the Python community offers a number of interesting modules for OpenGL development: pyopengl, pyglew, pygpu; just to name a few.
BTW, your import issue can be resolved easily by importing the modules in the __init__.py files of the directory the modules are contained in and then just importing the "parent" module. This is not recommended but nonetheless possible.
I don't understand why nobody has heard of the D programing language?
THIS IS THE PERFECT SOLUTION!!!!
The only real alternative if you desire all those things is to use Java, but honestly you're being a bit picky about features. Is code completion really that important a trait? Everything else you've listed is traditionally very well regarded with Python, so I don't see the issue.
The text editor (not even an IDE) which I use lets you import API function definitions. Code completion is not a language feature, especially with OpenGL. Just type gl[Ctrl+I] and you'd get the options.
I tried using Java3D and java once. I realized Java3D is a typical Java API... lots of objects to do simple things, and because it's Java, that translates to a lot of code. I then moved to Jython in Eclipse to which cleaned up the code, leaving me with only the complexity of Java3D.
So in the end, I went in the opposite direction. One advantage this has over pure python is I can use Java with all of Eclipse's benefits like autocomplete and move it over to python when parts get unwieldy in Java.
It seems like Pydev can offer code completion for you in Eclipse.
I started off doing OpenGL programming with GL4Java, which got migrated to JOGL and you should definately give it (JOGL) a try. Java offers most of the features you require (plus Eclipse gives you the code completion) and especially for JOGL there are a lot of tutorials out there to get you started.
Consider Boo -- it has many of Python's advantages while adopting features from elsewhere as well, and its compile-time type inference (when variables are neither explicitly given a specific type or explicitly duck typed) allows the kind of autocompletion support you're asking about.
The Tao.OpenGL library exposes OpenGL to .NET apps (such as those Boo compiles), with explicit support for Mono.
(Personally, I'm mostly a Python developer when not doing C or Java, but couldn't care less about autocompletion... but hey, it's your question; also, the one-class-per-module convention seems like a ridiculous amount of pain you're putting yourself through needlessly).

Resources