As the ES6 spec is nearing completion, I'm investigating get a jump start on ES6 syntax and leveraging traceur compiler to do so.
My question is that I see that tracuer requires a 'runtime' file to be included on the page, is this a shim for some lacking 'core' features like Array/etc OR is this a runtime converter and then the build is just for deploying?
If its just a 'shim' per say, how do you deal with always compiling during development? I know you could do a watch in grunt but for large applications that seems very slow. I also saw you could use a node compiler, but node is not my backend/server tech ( I use IIS, ya i know ).
Thoughts/suggestions?
Related
I'm working with V8 in C++ and was asked about supporting TypeScript, which I'm unfamiliar with. After poking around, it looks like TypeScript runs as JavaScript but seems pretty tied to Node (e.g., for accessing the filesystem). There is no O/S filesystem in my project, which doesn't bother V8 because it isolates itself from such things and lets me translate things like "module names" into database calls rather than filesystem reads.
I see Deno also embeds TypeScript, but since its the same guy that wrote Node, I'm guessing that was a big leg up in providing TypeScript all the Node-cruft it has its hooks into. Seems a shame that TypeScript runs as JavaScript but ends up tied to a particular project rather than being embeddable in any JavaScript environment.
Has anybody written a neat shim for insulating TypeScript from Node to reduce the work of embedding it in a different product? Any ideas/pointers/thoughts welcome...
To be clear: I mean to say "separate the TypeScript compiler from Node". And by embed Typescript, I mean "embed the TypeScript compiler", which I believe is (in its compiled form) a bunch of JavaScript with serious dependencies on Node.
TypeScript already is separated from Node. In fact, it has nothing whatsoever to do with Node.
As an example, see the TypeScript Playground, which is an online IDE written in TypeScript that runs in the browser (no Node in sight), including embedding the entire TypeScript toolchain (compiler etc.) which is also written in TypeScript and also runs in the browser (again, no Node in sight).
In fact, I wouldn't be surprised if while you were writing this question, there was actually TypeScript code running in your browser without Node. (Stack Overflow, Inc. is known to use TypeScript.)
You already mentioned Deno yourself, which includes the TypeScript compiler. No Node in sight.
Many, many web companies all over the world are using TypeScript to do browser-side scripting. Again, no Node in sight.
There is exactly one Node-specific thing in TypeScript, and that is that TypeScript knows how the Node.js module-lookup algorithm works. The only reason this exists is to ensure that if you use Node-style module lookup in your code, TypeScript will use the same algorithm to find the module for type-checking at compile time that Node.js will later use at runtime. Otherwise, it could lead to the situation that TypeScript will at compile-time find a module, type-check it and determine that is type-safe, but then at runtime, Node.js would actually load a different module.
This is undesirable, and that's why TypeScript knows about the Node.js module lookup algorithm. If and when another module lookup algorithm becomes popular, TypeScript will probably also implement that one. It doesn't seem likely, though, since e.g. the ECMAScript committee and the Denon developers have deliberately chosen to design much simpler module lookup. (In fact, ECMAScript and Denon arguably don't have "module lookup" at all, you always need to specify a URI resolving to the exact location of the module file.)
!!! NOTE !!! Whenever I wrote about "running TypeScript code" above, that was a simplification. As far as I know, there does not exist an interpreted TypeScript implementation, so you actually can't "run TypeScript" (in the same sense that you can't "run Go"). You have to compile it first. There are currently two compilers for TypeScript, tsc from Microsoft, and the TypeScript plugin for Babel. Both of those compilers compile TypeScript to ECMAScript. Also, both are delivered in ECMAScript (although tsc is written in TypeScript).
So, as long as you have some way of running ECMAScript, you can also run TypeScript.
There was a project to implement a native TypeScript implementation on top of the Rubinius Language Framework, but that project literally never produced more than a README stating the intention of implementing a native TypeScript implementation on top of the Rubinius Language Framework. I still think it would be nice to have a TypeScript runtime that isn't tied to ECMAScript, though.
I have a question regarding following TypeScript plugin for SystemJS :
https://github.com/frankwallis/plugin-typescript/
Here is its description
A plugin for SystemJS which enables you to System.import TypeScript files directly. The files are compiled in the browser and compilation errors written to the console.
I wonder what would be the use cases of such plugin.
Why would developers import directly ts files and compile them in the browser instead of compiling them during development and import js files ?
Won't it reduce performance and load time to do it in browser ?
Is it supposed to be used only in development environment ?
plugin-typescript author here. In-browser compilation is strictly a development tool, in production you would use systemjs-builder (in combination with plugin-typescript) to create a single file containing all of the transpiled javascript.
Since the plugin was originally developed, a number of new workflows have become available when using typescript & systemjs (typescript single-file transpilation, vscode, systemjs hot-reloading, typescript system.register output, to name a few...) - Which one is right for you will depend on the size of your application, the platform/server you are using, and your own personal preferences.
No one in their right mind would compile/transpile in the browser for production; it's the equivalent of sending a turtle to get your mail because you don't like walking.
This is strictly a development tool for helping TypeScript devs avoid having to constantly compile after every change, with the added benefit of providing features like hot reloading.
I was attempting to use Traceur for a few small client-side micro libraries that I maintain. I would like to refactor them to use "classes" and a few other ES6 features and then compile an es5 version for production.
However, once I add classes the compiled out requires the runtime which is really big for all I need (just extending constructor functions). Is there a way to configure it so that it puts just what it needs to run into one file like CoffeeScript?
You can build your own runtime by following the recipe in the Makefile and omitting the files you don't need. traceur is 'self-hosted' so you use the ./traceur command with inputs and flags to create an output file which is the runtime source. Start with make bin/traceur-runtime.js then whittle down the files until you have what you need.
We are working on an automated way to do this, but it's not likely to be done soon.
Is there any software that I can use to compile nodejs program?
The reason I want to compile nodejs code is to make it safely distributable.
For example for a desktop application,etc.
And also I want to know whether nodejs will execute faster if compiled as it is asynchronous already?
Javascript is not a compiled language and Node.js is Javascript. It will be executed and interpreted at runtime. You can process your javascript with tool like grunt.js for example lint-test and uglify it, but be careful so that do not break the npm system since it is based on certain conventions.
To package your javascript for distribution in the node.js context build an npm module.
https://www.npmjs.org/doc/developers.html
For distributing javascript to the desktop client: Remember it's Javascript an it need to be executed in the Javascript VM. So to have some UI you need to run it in the browser or you need to have some webkit compiled dll to run your code...
something like this...
http://www.tidesdk.org/
You can also use: http://github.com/rogerwang/node-webkit (Thanks to #edi9999)
There is no way to do that with v8, it has only JIT option. It possible to make a "snapshot" with v8, but it's not exactly the same as compilation and node.js doesn't have support for this feature (also it might produce slower code). Also all your code will be available with toString() of functions.
You might be interested in JXcore project. It is a fork of node and as far as I know has some solution to code protection. Also one of the project goals is to develop javascript-to-LLVM compiler. Of course it can't have full support for ES specification (eval, new Function etc).
There's no way to 'compile' a nodejs program, as the javascript is interpreted at run time.
However, if you want to protect your code, you could maybe use something like Uglify JS to make the javascript less readable. However, this won't hinder people to change around your code.
The closest you might get to acheiving your goal is to create a self-executing Javascript bytecode wrapper.
A project that does this is pkg
It somehow creates a self-contained binary executable from Javascript, including module dependencies and asset files and produces a self-contained executable.
Installation and use is easy:
$ npm install -g pkg
$ pkg index.js -o my-program
$ ./my-program
It seems the resulting binary contains nodejs bytecode. It appears that you can cross-compile.
I'm creating a javascript library, and i want it to be environment agnostic (It will not use DOM, AJAX, or NodeJS api. It will be vanilla javascript). So, it's supposed to run in any javascript environment (browsers, npm, meteor smart packages, V8 C bindings...).
My currently approach is creating git repo with the library, with all the library inside a single global variable, without thinking about patterns like CommonJS or AMD.
Later, i'll create another git repo, using my library as a git submodule, and create what is needed to release it as a npm module. I'm concerned if it's a good approach, i didn't found anyone doing this way.
Pros: code will be vanilla javascript, without awareness of environment patterns. It will not bind itself to CommonJS. It will be repackable (copy and paste or git submodule) to any javascript environment. It will be as small as needed to be sent to browsers.
Cons: I'll have to maintain as many git as environments i want to support. At least a second git repo to deliver on npm.
Taking jQuery as example, it runs in both browser and nodejs, with just one git repo. There is some code to be aware of the "exports" variable to run on nodejs or other CommonJS compatible enviroment.
Pros: Just one git repo to mantain.
Cons: It will be binded to CommonJS pattern (to achieve npm compatibility)
My question is: Am i following a correct (or acceptable) approach? Or should i follow jquery's path, and try to create a single git repo?
Update 1:
Browserify and other require() libraries are not valid answers. My question is not how to use require() on the browser, instead, it's about the architecture pattern to achieve enviroment agnosticism.
Update 2:
Create a browser/nodejs module is not the question, it's known. The question is: can make a real enviroment agnostic library? This example is binded to CommonJS pattern, used in NodeJS.
If you are looking for design recommendation for your future library work then in my opinion you can think-future and just use usual Object Oriented Practices well proven in other languages, systems and libraries.
Mainly concentrate on the UML view of your design.
Forget the "one variable" requirement.
Use features proposed in the planned next version of JavaScript.
http://wiki.ecmascript.org/doku.php?id=strawman:maximally_minimal_classes
http://wiki.ecmascript.org/doku.php?id=harmony:modules_rationale
There is an experimental compiler available that allows you to write ES6-style code even today (see https://www.npmjs.org/package/es6-module-transpiler-rewrite).
Node.js has a --harmony command line switch that allows for the same (see What does `node --harmony` do?)
So in my opinion correct approach is to follow best practices and "think future"
"Use a build tool" is the answer for this question. With a build tool, you can develop with the best code pratices, without accopling your code to some enviroment standard of today (AMD, commonjs...) and still publish your code to these kind of enviroments.
For example, I'm using Grunt.js to run some tasks, like build, lint, test, etc.
It perform tedious operations (minification, compilation...) like Make, Maven, Gulp.js, and various others.
The build task can handle standards (like commonjs) for the compiled code. So, the library can be totally enviroment agnostic, and the build process handle enviroment adaptations.
Note that i'm not talking about compiling to binaries. It's compiling source to another source, like CoffeScript to JavaScript. In my case, it's compilation of JavaScript without enviroment standard to JavaScript with commonjs standard (to run as a Node.js module).
The final result is that i can compile my project to various standards without messing with my code.
Aditionally, with a build phase i can "think-future", like xmojmr answered and use the EcmaScript 6 features on my JavaScript code, using Grunt plugins like grunt-es6-transpiler or grunt-traceur to compile JavaScript code from ES 6 to 5 (so it can run on enviroments of today)
According to modular your library (if you need modules). Read this question Relation between CommonJS, AMD and RequireJS?
Take bootstrap for example, it uses npm to manage project dependencies and use bower to publish as static content for other web apps.
Take a look at browserify as reference, it's a little heavy because it provides the capability to bundle dependent npm modules as resource for browsers.