Deno uses v8 to execute javascript but considering the fact that it directly runs typescript, I'm wondering if there is a performance penalty because of it or not.
It seems it compiles the code only for the first time. So is it possible to compile as a deployment step and avoid the startup overhead related to compilation?
Is there any other aspect in performance comparison between node.js and Deno?
Deno keeps track of some key performance metrics here: https://deno.land/benchmarks
As far as pre-compilation, it's on the roadmap and tracked in this issue: https://github.com/denoland/deno/issues/986
(an answer to the 2nd paragraph)
Deno stores the compiled assets in DENO_DIR. You can check it with the command "deno info". If you deploy the entire DENO_DIR as well as your source code, you can avoid the TypeScript compilation at the startup time.
You can also change the location of DENO_DIR by setting the DENO_DIR environmental variable.
DENO_DIR=/path/to/your_deno_dir deno run entrypoint.ts
Deno performance was and still better than Nodejs in excellent way since it's was using both JavaScript and TypeScript in it's code.
Deno as a secure TypeScript runtime built on V8, the Google runtime engine for JavaScript, is a good hope for back-end devs in future as It was built with Rust which I think is better than C++ which gave a life to Nodejs (Deno’s core was written in Rust, Node’s in C++).
I've not yet started to use deno fully but It's undoubtedly sure that it will be the best alternative to Nodejs as it includes almost everything Nodejs has with additional modern features needed in new dev world.
I'm trying to make it's tutorial on my site #Donnekt
Related
There are more and more references in the Node.js community to "CrankShaftScript" (and "CrankShaftJS") on Twitter, GitHub, and Facebook group discussions. I thought Node.js was written in C++ and JavaScript, so what is CrankShaftScript referring to in performance regression bugs like this one:
https://github.com/nodejs/CTC/issues/146#issue-237435588
CrankShaftScript is the name given by the community to JS idioms (such as certain types of loops) that run faster(est?) on V8's CrankShaft engine.
CrankShaft is being replaced by an engine named TurboFan. Lots of JS code written by devs over the years has been written specifically to run fast on CrankShaft (e.g. written in "CrankShaftScript") using the known idioms that run fast on CrankShaft - this is no longer necessarily the case because the V8 engine is now different and the code that ran fastest on CrankShaft is not necessarily guaranteed to run fastest on TurboFan.
In case my answer is too verbose, here's a great comment on the NodeJS Benchmarks thread that may detail it better:
...I noticed that some parts of Node core are sort-of written in
CrankshaftScript, i.e. carefully tuned towards stuff that works
extremely well in Crankshaft.
CrankShaftScript is a community-adopted term used for non-idiomatic and/or non-standard compliant JavaScript that will only execute and/or perform well in the specific versions of the v8 JavaScript runtime that employ the CrankShaft JIT compiler. Specific examples include: loops written in a difficult-to-maintain fashion to work around JIT optimization deficiencies in v8, and use of v8-specific built-in functions/globals.
This term was originally coined to describe some root performance issues in node-chakracore and spidernode, which are Node.js distributions that employ the ChakraCore and SpiderMonkey runtimes instead of v8.
It is now being used as shorthand to explain why the Node.js 8.1 release series, which updated to a newer version of v8, has several performance regressions in micro- and macro-benchmarks due to v8's CrankShaft JIT being superseded by TurboFan (sometimes referred to as "TF"). As in these issues:
https://github.com/nodejs/node/issues/11851#issuecomment-287253082
https://github.com/nodejs/CTC/issues/146#issuecomment-310229393
https://twitter.com/matteocollina/status/870580613266501632
For these reasons, the Node.js community is actively working on excising instances of CrankShaftScript in Node.js core code, as well as in common npm packages. This should help alternative Node.js distributions like node-chakracore perform better and ease the risk of future upgrades to the JavaScript runtime in Node.js.
CrankShaft is the compilation infrastructure for V8, Node.js' Javascript runtime (details).
It's now being replaced by TurboFan.
I spent a lot of time to build a webtemplate (front-end) with a grunt file to "compile" the whole project and have an efficient code in production.
Now that I am working on a back-end project (with node/express) i was wondering if it make sense to "compile" a node project ?
I'm using ES6 syntax with Babel so i imagine that everytime i launch the project (node index.js or nodemon index.js) Babel transpile it in ES5 and then run it.
I don't care if it's done at the beginning of the project and there is no impact once it has been launched. But i'm not sure.
Does node read the whole program and "save" it into ram ? If so i imagine that it's not useful to concat/compile javascript file like we're used to with front-end.
Yes, at least it's not a bad idea.
However:
nodemon is not meant for production
when you run babel as a runtime, you introduce it as additional layer of possible failures, on top of your code.
reading only from transpiled js would probably be easier for older node platforms or be more efficient when you make it available as a module.
So better:
use rather NODE_ENV=production
Yes, it does save it to the RAM. parsing will be faster, but only marginally.
there will be better compile time for your js, indeed, when you minify your code. But the side effects (e.g. worse debugability) are the trade-off.
OH: there can be performance optimizations of V8 for functions that don't exceed a certain char count. But the effect is probably really low, since only the real hot functions benefit from it.
compiling and uglifying would be good for obfuscation, if you need to ship you code. npm shrinkwrap is a good tool for this also.
Concluding: Don't do it, since it rather feels like premature optimization, which is generally a bad idea. You will meet heavy problems of node debugability, which will be a problem at dev-time.
Rather follow general Node.js performance guide, and if you don't target other platforms than your production environment, choose the newest Node.js version with all the ES6 features you need.
Is there a way to precompile node.js scripts and distribute the binary files instead of source files?
Node already does this.
By "this" I mean creating machine-executable binary code. It does this using the JIT pattern though. More on that after I cover what others Googling for this may be searching for...
OS-native binary executable...
If by binary file instead of source, you mean a native-OS executable, yes. NW.JS and Electron both do a stellar job.
Use binaries in your node.js scripts...
If by binary file instead of source, you mean the ability to compile part of your script into binary, so it's difficult or impossible to utilize, or you want something with machine-native speed, yes.
They are called C/C++ Addons. You can distribute a binary (for your particular OS) and call it just like you would with any other var n = require("blah");
Node uses binaries "Just In Time"
Out of the box, Node pre-compiles your scripts on it's own and creates cached V8 machine code (think "executable" - it uses real machine code native to the CPU Node is running on) it then executes with each event it processes.
Here is a Google reference explaining that the V8 engine actually compiles to real machine code, and not a VM.
Google V8 JavaScript Engine Design
This compiling takes place when your application is first loaded.
It caches these bits of code as "modules" as soon as you invoke a "require('module')" instruction.
It does not wait for your entire application to be processed, but pre-compiles each module as each "require" is encountered.
Everything inside the require is compiled and introduced into memory, including it's variables and active state. Again, contrary to many popular blog articles, this is executed as individual machine-code processes. There is no VM, and nothing is interpreted. The JavaScript source is essentially compiled into an executable in memory.
This is why each module can just reference the same require and not create a bunch of overhead; it's just referencing a pre-compiled and existing object in memory, not "re-requiring" the entire module.
You can force it to recompile any module at any time. It's lesser-known that you actually have control of re-compiling these objects very easily, enabling you to "hot-reload" pieces of your application without reloading the entire thing.
A great use-case for this is creating self-modifying code, i.e. a strategy pattern that loads strategies from folders, for example, and as soon as a new folder is added, your own code can re-compile the folders into an in-line strategy pattern, create a "strategyRouter.js" file, and then invalidate the Node cache for your router which forces Node to recompile only that module, which is then utilized on future client requests.
The end result: Node can hot-reload routes or strategies as soon as you drop a new file or folder into your application. No need to restart your app, no need to separate stateless and stateful operations: Just write responses as regular Node modules and have them recompile when they change.
Note: Before people tell me self-modifying code is as bad or worse than eval, terrible for debugging and impossible to maintain, please note that Node itself does this, and so do many popular Node frameworks. I am not explaining original research, I am explaining the abilities of Google's V8 Engine (and hence Node) by design, as this question asks us to do. Please don't shoot people who R the FM, or people will stop R'ing it and keep to themselves.
"Unix was not designed to stop its users from doing stupid things, as
that would also stop them from doing clever things." – Doug Gwyn
Angular 2, Meteor, the new opensource Node-based Light table IDE and a bunch of other frameworks are headed in this direction in order to further remove the developer from the code and bring them closer to the application.
How do I recompile (hot-reload) a required Node module?
It's actually really easy... Here is a hot-reloading npm, for alternatives just Google "node require hot-reload"
https://www.npmjs.com/package/hot-reload
What if I want to build my own framework and hot-reload in an amazing new way?
That, like many things in Node, is surprisingly easy too. Node is like jQuery for servers! ;D
stackoverflow - invalidating Node's require cache
My understanding of the technology is that it is compiled on the fly into assembly. On the speed spectrum it is slower than Java but faster than Ruby and Python. On the client side an interpreter makes sense but on the server side my first thought is that compilation prior to running, or at least having the option to do so, is an optimal architecture. If the JavaScript was pre compiled in this way would it run faster than Java? Or is it something to do with weakly typed languages which means that JavaScript will always be slower than Java?
Some of Node.js is C++ and is pre-compiled. My understanding though is that there was an effort to keep as much of it in Javascript as possible, but where performance was poor then C++ was used.
Node.js would not be possible without the V8 JavaScript Engine, which is what compiles the javascript. This engine is well-known for being extremely fast. It was built for the Chrome browser, but the performance pays off in Node.js too.
Regarding performance of Node.js, as a web server it is at least on a par with the other leading web servers like Apache+PHP. So performance is not an issue in the common use case. That said, there are faster technologies. Erlang based servers are known for being faster under concurrent loads (interestingly, Erlang is also a dynamically typed language).
For pure number crunching cpu/gpu intensive tasks, Node.js is not a good choice, unless you temper it with Fabric Engine, in which case it can be on a par with C++.
There are a couple of projects that are currently exploring speed issues with JavaScript:
Dart - http://www.dartlang.org/support/faq.html. (Its not just about speed but that is part of it).
Node Native - https://github.com/d5/node.native/
As stated in the title, I would like to know if it's safe to develop a website using one of the actuals "omg" platforms that are Node.js and Ringo.js at their actual version.
Also, I would like to know if they support cookies/sessions and how do they deals with multi-fields post (fieldname[] in PHP).
Thank you
--Edit--
Thanks for all the links guys.
What can you tell me about Ringojs ?
Since I haven't figured which platform to start playing with. I must admit that the fact it can use Java seamlessly really impress me. The only available XSLT 2.0 library is in Java. I could use it as a templating system.
Is there anyone who had the chance to play with Ringojs?
From my experience using both, Ringo is more stable and "safer" for production use but you can comfortably deploy both. In addition to the ability to wrap existing Java libraries that you mention, you also get the benefit of being able to run it in an existing webapp container which manages the lifecycle of the application for you and ensures its availability.
That being said, it doesn't have to be an either or decision. By using my common-node package and assuming you don't use any Java libraries, it's perfectly feasible to maintain a project that runs on both without any changes to the code.
I've also included benchmarks that test the performance of Node.js vs. RingoJS the results of which you can find in the common-node/README.md. To summarize: RingoJS has slightly lower throughput than Node.js, but much lower variance in response times while using six times the RAM with default Java settings. The latter can be tweaked and brought down to as little as twice the memory usage of Node with e.g. my ringo-sunserver but at the expense of decreased performance.
Node.js is stable, so yes it's safe to use. Node.js is capable of handling cookies, sessions, and multiple fields but are not as easy to manage. Web frameworks solve this problem.
I recommend Express.js, it's an open-source web framework for Node.js which handles all of this and more.
You can download it here:
https://github.com/visionmedia/express
I hope this helped!
Examples of some of the bigger sites running Node.js
https://www.learnboost.com/
http://ge.tt/
https://gomockingbird.com/
https://secured.milewise.com/
http://voxer.com/
https://www.yammer.com/
http://cloud9ide.com/
http://beta.etherpad.org/
http://loggly.com/
http://wordsquared.com/
Yes. It is. https://github.com/joyent/node/wiki/Projects,-Applications,-and-Companies-Using-Node and https://github.com/joyent/node/wiki/modules
cookies/sessions/forms etc http://expressjs.com/ makes it easier
Ringojs is a framework developed by Hannes Wallnöver and uses rhino as it's scripting framework. There are webframeworks, templating-engines, orm-packages and many many more things already available. Have a look at the tutorial featuring a good subset of packages you may use for a simple web-application. It's not too long and straightforward.
Even thought some of those packages used within the tutorial (e.g. ringo-sqlstore]) are marked as 0.8 and come with the hint "consider this being beta" they are already very stable and bugs - if you find one - get fixed or commented on very fast.
And the power of uncountable java-libraries out there is at your fingertips - so if you already have java-knowledge this knowledge isn't wasted. Rhino - the scripting-engine - even enables you to implement interfaces and extend classes. It is possible a little more advanced but i've done it and i know of packages taking advantage of such features (like ringo-ftpserver which is a wrapper around Apache FtpServer written in java)
Another pro for me is - because ringojs is based on java - it works fairly well with multithreading with ringo/worker for example.