Develop Reference

Do I use Node.js to build a whole website? [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 3 years ago.
Improve this question
The last couple of days I began to teach myself how to create a Website from scratch.
I bought a webspace and fooled around with html, css and javascript and when I wanted to build a online chess game I learned about Node.js
But I don't understand what Node.js is used for because the documentation shows how to install and create a fresh server(!) with Node.js and handle requests.
Do I don't have to use a apache installation on my server anymore?
Do I create the whole website and all it's pages with Node.js like the index or about page?
If I use Node.js just for a web application, how can I add the web app to an already existing Apache website's page?
I think I really got confused and need some help to understand Node.js better since so many are using it.

Do I don't have to use a apache installation on my server anymore?
Correct. You create your whole web server in node.js. You generally don't use or need Apache with it.
Do I create the whole website and all it's pages with Node.js like the index or about page?
Yes, you create the whole web server in node.js and use it to serve all your web pages. Typically one might use a number of libraries with node.js such as Express for mapping all the routes in your web app and your favorite template engine to help with filling in data in HTML pages before serving them to the client. At very high scale, one might consider using some other infrastructure (like nginx) to offload static resources from your node.js server to increase scalability, but that is not necessary at small or medium scale as node.js scales really well.
If I use Node.js just for a web application, how can I add the web app to an already existing Apache website's page?
You can run one of the two web servers on a different port and have two web servers that are part of your web-site liking to each as needed. But, typically you would move everything you currently have in Apache over to your node.js app. You don't have to do that, but most people wouldn't start out with an objective to build a web-site out of both node.js and Apache.
One thing to keep in mind is that node.js/Express are conceptually a bit different from Apache in how you build a simple web-site. A node.js/Express web server serves NO content at all by default. So, you don't just drop a directory hierarchy of web pages on your node.js server and expect it to serve those pages by default. You can do that pretty easily with express.static() (a feature of the Express library) if that's part of your site design, but you have to consciously configure that in node.js (it takes just two lines of code to do so).

If you want to write a "simple" chess game, you're best bet is to start learning Canvas. This tutorial by the Mozilla Foundation is one I personally used and enjoyed a lot. If you want the computer to play as CPU opponent, then you would likely need to use a server(node.js!).
You can use Node.js to build a simple website, but that would be like using a screwdriver as a hammer. Node.js is used for making desktop apps and for programming servers. Servers(backend) analyze user inputs and provide some sort of feedback. Let's use StackOverflow as an example. The frontend(HTML, CSS, Javascript) is what you see. All of that is done in the browser. The way you get that code to someone's computer so they can render your website is via a server. Servers do other cool things. When you do a search on a website or save a post, the server is dealing with storing that data or finding you the right results. If you want to build an API, like the one used for Google maps, or for Yahoo Finance, you'd use a server.
If you want to make your own server using Node.js, I'd recommend using Digital Ocean or Heroku. They are beginner-friendly and are respected in the industry. Heroku is free and owned by Salesforce if that makes a difference. However, this is unnecessary, for beginners. I recommend using a free or low-cost hosting platform that deals with that for you.
The thing about Node.js is you can use it to create websites via template engines, but I wouldn't recommend that. You are essentially writing server-side javascript to create HTML. That's foolish most of the time when you can just write the HTML itself. Just have node.js deploy it.

Can Node.js replace java as server side technology in web app

I am planning to start making my first big web project. I am currently at the point where I am trying to visualize everything but some of the technologies will be learned on the run. I recently picked up JavaScript and learned a bit of Node.js.
I wanted to make a rest API in java, that connects to a Mysql database. After doing some unwanted research, I came across a statement which to me seem bold. That node.js can in some way completely replace java as a backend?
For what i know Node.js is a runtime envioronment based of chromes JavaScript engine, with some libraries like NPM. (which I yet have to look into some more)
That was a long introduction, the core of my question is: Can Node.js replace Java in my case, and if so why and how?

Some personal thoughts:
Can Node.js replace Java in my case, and if so why and how?
Definetly. Nodejs is not just V8 with some libraries, but also ships with a lot of ways to interact with the IO, which means you can run http(s) servers, connect to databases and other servers, spawn threads, write/read files among others. If there is some low-level thing that the JVM supports that Nodejs doesn't, you can just write a native binding in C++ (or take one from NPM, there is probably already one for your exact usecase).
The main benefit of Nodejs is that you just write JavaScript, and you don't have to change languages. That makes development more easy and faster (at least for me).

Performance-wise: Is a WPF application better than an Electron one coded wisely? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Recently, I have been reading about Electron and I got curious about its potential when compared to something already established in the market of building Windows 7 desktop applications (i.e., WPF).
So far, I noticed that those who lean towards Electron discuss the fact that it provides:
fast-development cycles: one familiar with HTML5, CSS3, JS, and some Node.js, is all set to jump right into building a desktop application.
cross-platform compatibility: being based on Chromium and Node.js, both cross-platform, the application can run anywhere where these two are supported.
beautiful and interactive GUI design: the combination of HTML5, CSS3 and JS has proven what is capable of achieving over the years.
straightforward and cost-effective web recycling: a web application can be relatively easy converted to a desktop application by the same developers who created it in the first place (i.e., saving costs).
When it comes to WPF, its supporters discuss the following favoring arguments:
access to native APIs: WPF fits well into the .NET framework giving the developer access to all native Windows functionality.
powerful XAML markup language: it is argued that the XAML allows efficient rendering of sophisticated UI elements, supports two-way data binding, and knowing it may be useful in other contexts (i.e., with appropriate adjustments, e.g., Android development).
high-performance and memory-efficiency: mainly due to the compiled nature of the language and, perhaps, other JIT idiosyncrasies.
If we take these arguments separately, we can agree that both technologies are respectable. However, when you ask developers for help choosing the right framework for your the project, things get a bit biased. I assume that the bias may be either because the questions are too unspecific, or because some are more familiar with one framework than the other and, thus, the comfort zone kicks in.
Hence, keeping in mind that both are just means to an end, and not life philosophies, when compared, it usually boils down to the following ideas. Please note that these are not my ideas, but what I collected from various discussion groups around the web.
DOM manipulation is an expensive operation, whereas XAML rendering is blazingly fast.
Electron gives you access to just a few native OS functionality through its APIs, whereas WPF gives you access to all since it lives on the .NET.
Electron is slower compared to WPF because JS is interpreted, whereas, say C#, is compiled.
WPF works well with the MVVM pattern, whereas something similar is harder to achieve in Electron.
Electron is fast to get started with, whereas WPF has a steep learning curve (but it looks more professional they say).
Electron is cross-platform, whereas WPF is tied to the .NET. Not sure whether the Xamarin/ .NET Core was taken into account.
Electron application size is large as it has to ship with Chromium and Node.js to accomplish its goals.
WPF is less actively improved compared to Electron (i.e., Electron is an open-source project).
Electron handles the application updates for you, whereas the same thing requires more work in WPF.
On one side, it seems that software engineers (i.e., especially those who work in the corporate world) tend to favor WPF. On the other side, web developers are excited about what Electron brings to the table. In my opinion, this is bias, and the fact that you work more with a technology than the other does not say anything about how suitable the technology is in itself.
Therefore, to avoid this bias and, perhaps, other nagging answers, I want to provide you with the following case study.
Let us say one is interested in building a Windows 7 desktop application with Electron. The goal of the application is to allow the users to configure and run an extremely computational-intensive statistical analysis on a large XLSX file (i.e., 1e5 rows). In short, the user fills in a form, a special syntax file is generated (i.e., json, xml, or txt), the application reads that file and performs the analysis with the parameters specified there. At the end, a pdf file with graphs and tables is provided to the user. Now, let us assume the following about this project:
the DOM is not directly manipulated. Rather, Vue.js or React are used because they implement a virtual DOM which is faster.
the application does not need access to all the native OS functionality. The application only requires to read/ write files to disk and, perhaps, send some notifications.
because JS is too slow to run the statistical analysis, a C++-based Node.js addon is written and called from JS. Behind the scenes, the C++ code constructs the objects and makes the computations. At the end, the resulting matrices and vectors are be exposed to the JS.
the developer cares to structure the application properly and separates the concerns as much as possible. To avoid unnecessary renderings, Vue.js or React components may be used.
the developer does not consider problematic the additional ~50MB in size added to the package by the Chromium and Node.js.
the application is hosted on a central repository and the updates are pushed to the end users.
Keeping these assumptions in mind, my questions to you are:
To what extent is a WPF application more efficient than an Electron application, given that the heavy computations are implemented in C++ or C# and packaged as a .dll? If it is, what causes these differences?
Is XAML more efficient for rendering interactive UI elements compared to Vue.js or React in combination with HTML5 and CSS3?
Disclaimer: I am bias towards Electron because I think it enables me to build the GUI faster than XAML. I may be wrong because I am not entirely familiar with what XAML has to offer.
Note: Please do not mark this question as inappropriate. It is specific enough and well documented, and it might help others facing the same decision.
Edit 1. Please provide arguments for downvoting/ flagging the question for closing. Perhaps, if you offer some constructive feedback the question can be improved.

Using NodeJS for a big project [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
Is NodeJS a good framework/codebase for a large server-side application? What I am looking to develop is a large application that will require HTTP transactions (states) and large amounts of concurrent users.
From what I've read online, NodeJS is not the best tool to use when it comes to large programs. What I've come across is as follows:
NodeJS runs on JavaScript which runs on event loops which are not very efficient when used in bulk.
NodeJS may be non-blocking, but all the requests are handled within a single thread so this can cause a bit of a bottleneck when many requests are handled.
NodeJS is built atop its own HTTP server so future maintenance will require its own sysadmin/developer hybrid to take care of the application.
There isn't as much well-tested and diverse software available for NodeJS that helps you build a bigger application.
Is there something I'm missing? Is NodeJS really as powerful as it can be?

Is NodeJS a good framework/codebase for a large server-side application?
That question is a bit subjective but I'm including actual objective points which solve real problems when working with node in a large project.
Update after working on project for awhile:
It is best as a front end / API server which is I/O bound (most front end/api servers are). If you have backend compute needs (processing etc...) it can be paired which other technologies (C# net core, go, Java etc... worker nodes)
I created this project as a sample illustrating most points - Sane Node Development:
https://github.com/bryanmacfarlane/sanenode
NodeJS is not built atop its own http server. It's built atop the V8 chrome javascript engine and doesn't assume an http server. There is a built in http module as well as the popular express web server but there's also socket modules (as well as socket.io). It's not just an http server.
The single thread does not cause a bottleneck because all I/O is evented and asynchronous. This link explains it well: http://blog.mixu.net/2011/02/01/understanding-the-node-js-event-loop/
As far as the software module, you can search at the npm registry. Always look at how many other folks use it (downloads) and visit the github repo to see if it's actively being maintained (or is there a bunch of issue never getting attention).
Regarding "large project" what I've found critical for sane development is:
Compile time support (and intellisense): Find issues when you compile. If you didn't think you needed this like I did when I started, you will change your mind after that first big refactor.
Eliminate Callback Hell: Keep performance which is critical (noted above) but eliminate callback code. Use async / await to write linear code and keep async perf. Integrates with promises but much better than solely using promises.
Tooling: Lots of options but I've found best is Typescript (ES6/7 today), VS Code (intellisense), Mocha (unit testing).
Instrumentation/Logging: Getting insights into your app with tracing and instrumentation is critical.
Build on well vetted frameworks: I use express as an example but that's a preference and there's others.

Node.js is a very good tool to build distributed network services. What is your large scale application design is more than a question 'which tools to use'. A lot of people use node.js in a very heterogeneous way together with ruby, php, erlang, apache & nginx & HAproxy. If you don't know why you need node you probably don't need it. Possible reasons to consider node:
you want to share common Javascript code between server and client
you expect highly concurrent load (thousands to hundreds of thousands simultaneous connections per server)
you (or your team) is much more proficient with JavaScript than with any other available language/framework
if one of 7600+ modules is implementing large portion of required functionality

One "issue" with NodeJS, is that building a large application requires discipline on the part of the developer / team.
This is particularly true with multiple teams within the same company. Existing frameworks are a bit loose, and different teams will come up with different approaches to solving an issue.
KrakenJS is a framework, built on top of express. It adds a layer of convention and configuration that should make it easy(er) to build large projects, involving multiple teams.

Really NodeJs is powerful in its own way, Some more information,
You can run multiple instance of your app under load balance to handle massive request.
Choose NodeJs to read 2000 files instead calculating 20th prime number.
Put NodeJs busy with reading/writing in files or ports.
Very useful when you need to broadcast your response to multiple client.
Don't care about dead lock in NodeJs, But care about how frequent you are doing same operation.
Most important thing is, the values live in V8 engine until the process is terminated. Be sure how much lines of code, you are going to feed in NodeJs.

I find the most important thing is to use CPU time as least as possible. If your application needs to use CPU intensively, event loop latency would increase and the application would fail to respond any other requests.

So far as I have learned, It's the raw speed and async await that makes the biggest difference.
For those who are moderately skilled in Javascript and particularly understand REST as well as the above mentioned aspects, node.js is one of the best solutions for big enterprise applications.
Correct me if I am wrong, but even using raw express (without those frameworks built on top of it ) is actually good enough if teams agree on certain conventions and standards to follow.

RIA application development on linux platform [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 7 years ago.
Improve this question
I am building a web based RIA application using web technologies including Rails based server side code, and client side based on HTML,CSS,JQuery and plugins etc.
I am looking forward to creating a standalone cross platform application using the same code-base (I do not want to rewrite the application UI in Qt or some other language/library).
Also, I dont want that clients should have to set up a web server to view the content. The application is heavily ajax based and communicates with the restful backend. The desktop client should be able to have exactly the same functionality with additional provision of local storage and synchronization of data.
I wish to carry out the entire development process on linux. Now that Adobe has stopped supporting AIR on linux, I am not taking that as a viable candidate.
I have been looking into Mozilla prism, its almost what I am looking for, except for the fact that it does not seem to have any provision for local storage or interaction with local filesystem.
It would be preferable if the solution is open source. My entire codebase from bottom up is based on open source technologies and as far as possible I would like to keep it that way.
Also, I am comfortable hand-coding my application and features like, integration with existing IDEs, GUI development environment, powerful application builder wizards etc. are not necessary requirements.
I have been suggested that it is possible to have a webkit component embedded in a Qt application and carry out what I want, but I am unable to locate proper resources that can help me do that. I am familiar with Java and C plus plus, so writing additional wrapper code in some other language is not a major hurdle.
If somehow local storage facility can be added to prism, that would be a highly preferred solution.
Also creating a plugin for google-chrome/chromium is a possible alternative. How does it compare to above options.
Any help would be highly appreciated.

At the moment AppJS ( http://appjs.org ) seems to be the most robust contender designed exactly around these same principles.
Another alternative might be a GTK-webkit based solution ( http://webkitgtk.org ) .
[Update:Aug 2013]
Multiple other alternatives are available as well :
TideSDK
TideSDK is community based offshoot of the immensely popular Titanium SDK. While the project is very promising, last I checked there were major hiccups running the developer tools on linux.
Node-webkit
This interesting project provides seamless interoperability between Node.js and Webkit. The end result is that you can start developing an application just like you would write a web-page with the additional ability to call any built-in or third-party node-modules. CommonJS modules just work in the browser context. The project is intel sponsored and I have personally found it very simple to use and productive.