I’m in the early design phases of an application and trying to reason about expectations and requirements, to make sure I don’t spend substantial time down a dead-end. I’ve never worked with V8 or node native add-ons, so bear with me.
Suppose I were building an Electron application. For performance reasons some functionality would be written in native code in an independent library, which would be invoked from a native Node add-on. The native library needs to execute JavaScript. So:
Electron App -> Native add-on -> Native library -> V8
First, is this feasible? For example, will trying to construct/run a V8 context fail due to its execution inside an Electron V8 context? I’m thinking deadlocks, aborts, etc.
I've come up with my plan-of-action from comments to the main question. Unfortunately that makes it hard to credit any specific user or comment for the answer. Specifically:
Restructure the data flow. Allow the Native Add-on to use its copy of V8 to execute any necessary JavaScript, instead of introducing it as a dependency to the Native Library. (comment)
Entering a separate V8 Isolate within another is supported. (comment) (docs)
The Native Library component was conceived because the document type to be supported is large (file-size) and needs JavaScript processing and expensive rendering. Initially I had conceived this to be one large monolithic library for supporting the document type, but in actuality it can be (and probably should be) broken up.
Parsing the binary file. Due to V8's speed, this can probably be done in my Node.js app itself, and may be faster than marshaling data across language barriers. If not, I may consider an N-API Native Add-on for parsing the document and returning a JS object representing the parsed data. (comment)
Executing document-level JavaScript. This should be doable in a Native Add-on by entering a separate V8 Isolate. (See above.)
Rendering the document to a canvas/bitmap. This is an unknown as it is dictated by drawing performance consisting of complex paths, etc. I will probably try to do this directly in the Node.js app first, and if it isn't performant enough then I will consider something like an N-API Native Add-On with e.g. Skia as a dependency to render the data.
Related
Kotlin vs Node JS for REST Api's
I couldn't find any proper explanation regarding the differences b/w Kotlin and Node JS for REST APIs
Which is better in performance wise?
Let me set the context. Its Kotlin/JVM vs JS/Node.js. We cannot blindly say that this language is better. In general Kotlin is supposed to be faster since it compiled language compared to JS which is interpreted language.
Irrespective of the language used, we will discuss on the API architecture. Serving the APIs can be implemented in either blocking or non-blocking way (I am not going to explain about what it is). Traditionally before a few of years Java/Kotlin with Spring have been using the blocking architecture which delivered performance X. On a contrary, Node.js is based on non-blocking architecture which gave us better performance than the blocking architecture and architecture style is the only reason why Node.js performed better. Later Spring released a newer version of the framework to support non-blocking architecture. The non-blocking style is called as Reactive programming/Spring Webflux.
So now both of the languages support non-blocking architecture. In terms of raw language performance, Kotlin will be better since its compiled language. Also in theory interpreted languages are supposed to be slower. But we cannot say which is better without any testing.
Personally I am fan of Java/Spring because of OOPS and later at one point I started using TS/Node.js. TS eliminates most of the runtime issues with its type checking. But still we cannot compare it with the type system available in Java/Kotlin. As a language I feel Java/Kotlin is superior and one thing I like most in JavaScript is handling objects/JSON. Checkout "Kotlin for JavaScript" as well which lets you write in Kotlin and transpile to JS. Ignore this "Kotlin for JavaScript" feature, I am planning to try Kotlin/Spring in non-blocking architecture for my future projects. If you have usecases with WebSockets, I think Node.js will perform better and I am not sure If there are any libraries in Java/Kotlin since I havn't explored it.
One disadvantage in non-blocking style is that I need to pass the login context object to almost all the methods in the project. In blocking architecture we will add the login context information in thread local so that we can access it anywhere until the request is completed.
I am sure that I did not answer your question completely. But I hope that the information what I have give is useful.
Correct me If I am wrong in any of the aspects.
In Node, does it make sense to port some logic to wasm for json manipulation operations in order for the algorithm to be quicker?
tl;dr Don't use WASM for JSON manipulation.
Setting up the WASM tooling is no small thing, and will likely require more ongoing troubleshooting and maintenance than lighter-weight solutions.
Wasm generally comes into its own when you need to do truly compute-intensive stuff like customized signal (image/video/audio) processing for your browser users or natively inside server-size Javascript environments.
If your purpose in doing this is avoiding overhead in JSON processing, you might consider looking for fast JSON packages on npm. fast-json-stable-stringify is an example.
You should also keep this in mind: V8 -- the open-source Javascript engine in nodejs, deno, and chromium -- is under active development by a large and highly competent team at Google. That engine includes the JSON. functions. Performance improvements show up in every release, and they're highly motivated to keep making things faster. JSON handling is one of those areas. If you roll your own, your code won't get any faster with the next release of V8/nodejs. If you use the stuff in V8, it might.
Take a look at this dev summit presentation, for example. Maybe you can outsmart the V8 team. If so you should join them.
So, if you want to learn WASM, do something that will add interesting new capabilities to your personal toolbox.
Unlikely. The V8 engine has a pretty good JIT compiler. If it is a hot path and properly written, it will become machine code anyway.
What would be the advantages, if any, of using a node.js addon written in C/C++ compared to calling a binary with arguments through child_process?
More specifically, I have a small program, which accepts possibly up to a few hundred arguments and returns a boolean.
There is a huge difference.
C++ Addon is native code which is running as part of main application (on the same level as JS does). But if you use child_process, node will start new process and there is a huge overhead (spawning processes is much more complicated than running native code in one thread).
If you are deciding, which approach to use, it heavily depends on your situation. If you are familiar with C++ and you want to handle thousands of requests, you probably should consider writing an addon. But if you are writing a small app for personal use and your additional program is already functional as stand-alone app, I would use child_process and it can also provide great results with less effort.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I'm feeling a bit confused, there are so many frameworks out there for Node.js related 'stuff'. Would someone be able to give me an overview of What are the differences between Backbone.js and Node.js? And which is best? Thanks in advance.
I am quoting it from a couple of sources here:
Firstly, to quote from the stack overflow question here:
Most of the things you listed are related only because they are
written in or otherwise use JavaScript. Comparing them is much like
comparing apples to oranges. It's like asking what the difference is
between a Toyota Camry and a V6 engine. They are related, but do
different things.
Node
Also known as Node.js, Node is the JavaScript environment on which we
run our server-side JavaScript code. It is based on the V8 JavaScript
engine. All of the JavaScript code you write, or install and run
from packages from NPM, GitHub, etc. is executed by the Node runtime
environment.
Backbone
Backbone can be likened to as a Model-View-Controller
framework for JavaScript. I believe it was originally written for the
browser; it helps keep your client-side JavaScript clean by
implementing most common MVC patterns (as well as a couple other
things), allowing you to more easily connect your client-side
JavaScript to your server-side code.
Also, this is from an answer for the same question on Quora. Credit goes to Drew Harry:
They're almost completely unrelated. Traditionally, Backbone.js is a
client library and Node.js is a way to write server-side applications
in Javascript. Backbone aims to be a model + view system for binding
data models with DOM elements that represent that model visually in a
web page. Backbone also provides Collections of Models, as well as a
bunch of utility functions for synchronizing those models with their
server-side representations.
Node.js is just the v8 Javascript run-time environment packaged with a
standard library to do useful server-side things with Javascript.
There are lots of packages designed for Node (check out npm for ways
to easily install those packages, Backbone included) that extend it to
do all sorts of interesting things. It's possible to use Backbone.js
with Node.js, but Backbone isn't particularly designed with use on the
server in mind.
Go and upvote the above answer(s) if you find the material helpful.
Pretty much the only things those two have in common is that they're Javascript based and have a lot of hype surrounding them (not undeserved though).
node.js is a framework for Javascript server applications. It includes the V8 Javascript engine developed for Chrome. It's asynchronous and event-driven, so it's ideal for serving large numbers of small requests.
backbone.js is a framework for client-side web applications, specifically for so-called "single page web applications" where only a single HTML page is sent to the browser at the beginning, and every interaction thereafter is handled by AJAX requests and Javascript logic that transforms the page.
This means that the two can also work effectively together: an app implemented using backbone.js for the frontend could have its AJAX requests handled by a server part using node.js - a rather popular combination since it allows you to have an entire web app using only Javascript.
Backbone.js is a javascript library, similar to jQuery or YUI but addressing different needs.
Node.js is a javascript interpreter, similar to Internet Explorer or Firefox or Safari but addressing different needs.
I don't know much about backbone.js but I believe you can use it with Node.js since it uses regular javascript. You may need a DOM emulation layer for the DOM related stuff though.
Additional answer:
A bit of googling reveals that there are people out there using Backbone on Node.js. The advantage of this is obviously you'll be able to use the same framework and reuse code on both client and server.
See: http://nerds.airbnb.com/weve-launched-our-first-nodejs-app-to-product
More additional answer:
With regards to semantics I see that some people disagree what some terms in computing means. While the terms are loosely used, and while they are somewhat interchangeable, they do have fairly well defined meanings.
In general, an interpreter is an executable, that is, a program that takes as input some data and executes it as a program. V8 is not this. It cannot take javascript by itself and run it. It needs to be compiled into another program, an interpreter in order to run javascript.
V8 does ship with example code to build an interpreter though. That interpreter shipped with V8 is called V8-shell.
An engine is a library that implements an interpreter. This is exactly what V8 is.
The two terms above are somewhat interchangeable because the word "interpreter" can also validly be used in place of "engine" to describe what a library implements. But that usage of the word is similar to the usage of "MVC framework" or "UI toolkit" in that it is used as an adjective. So it is correct to say that an "interpreter" is a kind of library.
But the word was originally used to mean the binary that executes a programming language. When used this way one uses it as a noun as it refers to something on the file system. Used this way is similar to the usage of the "compiler". For example one would call clang a compiler in this sense and one would call llvm, the library used by clang, a compiler in the previous sense.
Lets take a look at something that is not javascript as an example:
tcl is a programming language
tcl is also the library that implements the interpreter for tcl. In other words the engine.
tclsh is the tcl interpreter
Let's take a look at another example:
ruby is a programming language
RubyC is one of the many engines for ruby
ruby is the interpreter that uses RubyC
Nobody uses the word "framework" when referring to the binary executable interpreter for the above two languages. It just sounds silly.
But wait you say, Node.js refers to more than just node.exe. It truly provides a bunch of additional features that can be used as a good foundation to write great programs. In other words a framework.
Well, yes. That being true does not make the usage of the word "interpreter" to refer to node.exe automatically invalid. Just as using the word "earth" to refer to the planet does not make using the word to refer to soil automatically invalid.
Besides, those extra functionality? That's true for tcl and ruby as well. It's also true for C. Those extra functionality like fs and http on Node.js are traditionally called standard library. While the Node.js project calls it a framework that's their choice. Almost nobody else calls their interpreter + standard library a framework. PHP for example is distributed exactly like Node.js with a bunch of very high level standard libraries but nobody would call PHP a framework. It's also a bit silly when people write actual frameworks on top of node - frameworks for a framework. But I'm not going to say they are wrong because they choose to call it that. It's just their way to describe what they've created. More power to them.
What I am saying is that people who say that node.js is not an interpreter is ignoring the usage of the word throughout the history of computing. I don't know. Coming from an asian background it's natural to me to assume that everything belongs to multiple categories. Maybe it's a western idea that things belong strictly to specific categories that I don't quite get.
So here are the facts:
Node.js is not simply a javascript library. You need node.exe to use the standard libraries that node ships with.
Backbone.js is on the other hand a standard javascript library. It is not an executable.
Node.js is the only example where an interpreter + library is called a framework so far. All other examples of framework I know of in programming refer to libraries that implement a design pattern.
Calling something "B" does not automatically make calling it "A" invalid.
One final thing: web browsers also come with a very large high level standard library for javascript. It's called the DOM (there's also a bunch of other stuff like Math and XMLHttpRequest but the DOM is the biggest). Accordingly one should call Internet Explorer and Firefox javascript frameworks but nobody does that.
Node.js :
Javascript for backend side. ( like : php, ruby on rails, python, etc. )
Backbone.js :
Javascript for frontend side ( running on the browser of your client )
backbone.js also uses jquery , more frameworks of javascript for client side are :
1. mootools
2. ExtJS
3. dojo
4. prototype
and many more ...
Both are javascript related but totally different.
Node is a interpreter/platform to execute javascript code in the server such as JDK or Ruby. To put it simple, you need NodeJS installed to interpret Backbone based script on the server.
When it comes to server side MVC., Geddy, RailwayJS, Express etc., considered to be serving the purpose better than Backbone.
Whereas Backbone is a champion MVC framework in the client side.
Node.js is a server-side platform designated for building network applications. It is built on Google's V8 Javascript Engine and uses asynchronous event-driven approach for building applications. Backbone.js is a simply javascript client library that makes it easier to create and maintain client-side code and comply with MVC pattern. Hence, they cannot be compared.
Backbone.js has a lot of alternatives that use slightly different approach to achieve the same goal. Most known are: knockout, ember.js and others. And it also can be plugged into node.js application.
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