https://www.npmjs.com/package/threads
It seems to me we can use this package in Angular for running threads.
But I feel difficulties on implementing this.
Is there anyway to use threading in Angular?
How can I use thread in Angular?
Angular does not have "threads", which by the way can mean many different things, in different contexts, environments, platforms, CPUs, and operating systems. Threads can be a way to accomplish parallelism; or they can be a way to organize your code as a set of concurrent processes; or they can be a way to manage access to shared resources; or any or all of the above.
Angular works in a browser. Browsers run JavaScript. The closest thing we have to threads in our browser world is web workers. To greatly oversimplify, web workers are not light-weight threads; in other words, you wouldn't want to create 100,000 of them. But if you are looking for a simple way to offload some computation away from the main browser task, so that it does not lock up the browser while you are computing, then you are probably interested in web workers.
Web workers do not really need any special library, or wrapping, or scaffolding. They're easy enough to just write directly. However, if you're interested in some ways to facilitate the process of using web workers within an Angular context, then google for "angular web workers".
I have no special knowledge of the library you mention. At first glance, it appears to be a way to abstract concurrent algorithms over different threading implementations appropriate for the node.js platform vs. the browser. If you're planning on working in Angular, then most likely the node.js platform part is irrelevant, so this entire library is not anything you should be interested in.
Related
I have recently begun working with JavaScript and have learned of the Electron framework. I am very interested in this framework (and the whole web technologies for desktop use concept). My programming capabilities could be best described as hobbyist. I have written a few small games and apps for my own use, and have a number of shell scripts to help me automate some of my workflow in Linux. My question is, is it possible to use an Electron app that is powered by a language other than JavaScript? For example, I have a bunch of Python scripts (and recently, some Haskell and F# ones too) to help me with my statistics, calculus, and accounting courses in school. I don't mind running a bunch of different scripts to do what I want but lately I've gotten the idea of potentially making some of them available for general distribution. But my scripts are, as I mentioned, written in several different languages, most of them functional languages and none of them in JavaScript. Is it possible to wrap these scripts into something like an Electron app? If not, does JavaScript have any features similar to a functional language? How would one go about creating a JavaScript library or framework to fullfil this need?
I am aware of platforms like SageMath and GNU Octave, but the whole point is to create something of my own.
I would appreciate any thoughts or suggestions. Thank you.
The short answer is there's no direct/easy way to do what you want.
But you have some options.
There's a Electron compiler, but it works only with Javascript based languages like TypeScript and CoffeeScript.
You can, of course, develop a local web application and communicate with your Electron UI using HTTP requests, here is an example using Python.
You can also use sockets for interprocess communication: https://www.npmjs.com/package/electron-ipc-socket
And you also has the option to just start a child process directly from your Electron Application.
Hope it helps and don't make you more confuse :)
I asked this (voted to be too broad) Question while working my way through a starter book on node. Reading this book, I'm sure I'll learn the answer to this later, but I'd be more comfortable if I knew this up front:
My Question: Can I (efficiently) continue using a usual webhost such as iPage or GoDaddy to host my web application, building and hosting the front end in a simple, traditional manner through an Apache web server, and communicate with a separate Node.js server (my application back-end) via AJAX for queries and other things that I can more efficiently process via Node?
More specifically, would this be a bad programming practice in terms of efficiency and organization? In other words, would it be likely that a large scale commercial application would ever be handled via this method?
Yes, you can separate the front-end of your web application and the APIs that power it. In fact, this is a very common configuration, especially for "large scale commercial applications".
Where you draw the separation line between the two specifically depends on what you are doing, how you're doing it, and what your needs are. Also, in terms of hosting, remember that if you're accessing something server-side across the internet, you're adding extra latency to everything. Consider getting off Go Daddy and using another host that gives you more flexibility, such as a VPS provider.
It's ok. Actually, this is how things shoud be done. You have a backend API on a separate server and lots of apps which are using the API. Just go with Nginx server, check this Apache vs Nginx.
Yes you can use node js as a part of some big application. It depends on wich type of interaction you would like to get. Is it comfortable to you to mix technologies? Then node is pretty good thing to work over web. I've finished a part of big nodejs-ruby-php-c-flash application (my part was nodejs) for very large data mounts. This application have different levels of interaction. Sometimes I use 2 languages at one time to create each part of my application the best for task I'm working on. There is applications that initiate, run and destroy mutiple OS instances. So using of multi environmental application not so hard.
I am writing an application using JavaScript, HTML5 and AngularJS. It only has to work on pretty recent browsers (for instance, IE10 but not IE9).
At several places in the application, there will be compute-intensive tasks, such as XML parsing, base64 decoding; these could involve fairly big data (a few MB is certainly a possibility).
If I just call things like atob() or DOMParser.parseFromString(), I will get an unresponsive browser for seconds or even minutes. This is clearly not acceptable to a user.
I've used Angular's Q Service to make things like accessing an external Web service asynchronous, and hence avoid hanging up the browser while awaiting a response. But such operations already have an asynchronous API.
What about these compute-intentive tasks, which don't have an asynchronous API of their own?
I can split some of these tasks a bit, chaining promises. Does this help at all? Does the browser message queue get a spin at the end of each task?
I see the existence of "Web Workers", which seem to offer proper multi-threading. But they seem to have rather poor abilities to transfer objects to/from the worker threads. Certainly, it seems that way for someone like me coming from C#.Net! For instance, I'd like to inject Angular services (built-in and my own) into the tasks on the threads. And I don't want to copy massive data between threads either.
Are other people achieving responsive client-side Web apps that include serious computation? If so, what are they using to achieve this?
It sounds like you are looking for the Parallel.js library.
Here is a quick description of the library from their website:
"Parallel.js is a tiny library for multi-core processing in Javascript. It was created to take full advantage of the ever-maturing web-workers API."
I'm not currently aware of any examples specific to usage of Parallel.js in Angular, but I'm sure it wouldn't be too hard to integrate the library as an Angular service.
Based on my understanding, only I/O in NodeJS is non-blocking. If we do, for example, lots of heavy math operations, other users cannot access to the server until it's done.
I was wondering if there is a non-blocking way to do heavy computation in NodeJS? Just curious.
If you have long-running calculations that you want to do with Node, then you will need to start up a separate process to handle those calculations. Generally this would be done by creating some number of separate worker processes and passing the calculations off to them. By doing this, you keep the main Node event loop unblocked.
On the implementation side of things, you have two main options.
The first being that you manually spin off child processes using Node's child-process API functions. This one is nice because your calculations wouldn't even have to be javascript. The child process running the calculations could even be C or something.
Alternatively, the Web Worker specification, has several implementations available through NPM if you search for 'worker'. I can't speak to how well these work since I haven't used any, but they are probably the way to go.
Update
I'd go with option one now. The current child process APIs support sending messages and objects between processes easily in a worker-like way, so there is little reason to use a separate worker module.
You can use Hook.io to run a separate node process for your heavy computation and communicate between the two. Hook.io is particularly useful because it has auto-healing meshes meaning that if one of your hooks (processes) crashes it can be restarted automatically.
Use multiple NodeJS instances and communicate over sockets.
Use multiple node instances and communicate over node-zeromq, HTTP, plain TCP sockets, IPC (e.g. unix domain sockets), JSON-RPC or other means. Or use the web workers API as suggested above.
The multiple instances approach has its advantages and disadvantages. Disadvantages are that there is a burden of starting those instances and implementing own exchange protocols. Advantages are that scaling to many computers (as opposed to many cores/processors within a single computer) is possible.
I think this is way to late, but this is an awesome feature of nodejs you've to know about.
The only way abot multithreading is by spawning new processes, right so far.
But nodejs has an implemented message feature between spawned node-forks.
http://nodejs.org/docs/latest/api/child_processes.html#child_process.fork
Great work from the devs, you can pass objects etc. as message to your childs and backwards
You can use node cluster module.
https://nodejs.org/api/cluster.html
I would use JXCore - it's a polished nodejs based engine which runs your code but has several options including the multi threading you are searching for. Running this in production is a charm!
Project's source: https://github.com/jxcore/jxcore
Features include:
Support for core Node.JS features
Embeddable Interface
Publish to Mobile Platforms (Android, iOS ..)
Supports Multiple JavaScript Engines
Multi-threading Capabilities
Process Configuration & Monitor
In-memory File System
Application Packaging
Support for the latest JavaScript features (ES6, ASM.JS ...)
Support for Universal Windows Platform (uwp) api
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
How to decide when to use Node.js?
Sorry if I'm a bit ambiguous, but I'm trying to understand the real advantages of using Node.js instead of other server-side language.
I'm a JavaScript enthusiast, so I'm probably going to play with Node.js, but I want to know if I should use it in my projects.
It's evented asynchronous non-blocking I/O build ontop of V8.
So we have all the performance gain of V8 which is the Google JavaScript interpreter. Since the JavaScript performance race hasn't ended yet, you can expect Google to constantly update performance on V8 (for free).
We have non-blocking I/O which is simply the correct way to do I/O. This is based on an event loop and using asynchronous callbacks for your I/O.
It gives you useful tools like creating a HTTP server, creating a TCP server, handling file I/O.
It's a low level highly performant platform for doing any kind of I/O without having to write the entire thing in C from scratch. And it scales very well due to the non-blocking I/O.
So you want to use Node.js if you want to write highly scaling and efficient applications using non-blocking I/O whilst still having a high level scripting language available. If needed, you can hand optimise parts of your code by writing extensions in C.
There are plenty of OS libraries for Node.js that will give you abstractions, like Express.js and now.
You don't want to use Node.js if you want (slow) high level abstractions to do everything for you. You don't want to use Node.js if you want RAD. You don't want to use Node.js if you can't afford to trust a young platform, either due to having to write large pieces of code yourself to do things that are build into other frameworks or because you can't use Node.js, because the API isn't stable yet or it's a sub 1.0 release.
The two most oft-quoted advantages are:
JavaScript is both server-side and client-side. There are fewer things to learn, less context switching, and the ability to reuse code across the two sides.
Uses non-blocking I/O, and Chrome's V8 engine, to provide fast, highly scalable servers.
For me though, the most interesting part is the amount of activity happening in this area. There are a lot of very interesting ideas under development for node - be sure to check out the list of Node.js modules.
When you're (or even if you are not) a JavaScript enthusiast you can/should use Node.js for a number of reasons:
It's a low-level, lightweight and standalone framework which brings power of JavaScript to the server-side environment.
If you like more higher level abstraction then there is a large number of modules and the npm package manager where you can find wide range of ready-to-use applications.
Fast/unencumbered development process - for example, you don't need tons of additional tools in order to start writing serious stuff.
Big open source based community full of enthusiasts and very talented people.
Made for creating real-time web oriented applications - that's where the (near) future is.
Personally, I'd most likely use Node.js when:
I want to write a server that doesn't use the HTTP protocol.
I'm prototyping a server implementation.
I'm writing a server that isn't expecting a ton of traffic (although I've never profiled a Node.js implementation next to, say, a matching C++ implementation).
I want to get active in the community (which is apparently growing quite rapidly).