We Keep Coding

Can I use JavaScript instead of PHP, replacing Apache with Node.js?

Can I write my web-site only in JavaScript being sure that my code is concealed from anyone? In this respect, is Node.js, like Apache, can be given access to through an Internet-provider?

The answer to both of your questions is yes.
Node.js can completely replace Apache (assuming you are willing to re-write all of your PHP as JavaScript). If you have your Apache running in reverse-proxy mode between your server and client, you can even handle some requests in Node.JS while handing others in PHP. This will allow you to maintain original functionality while changing the code out, and also allow PHP to handle more mundane tasks.
While you cannot prevent raw JavaScript from being read through any means of obfuscation, you can prevent people from reading your code by note making use of standard JavaScript at all. You can use a NativeExtension for Node to add an extension handler for encrypted JavaScript files:
require.extensions[".jse"] = function (m) {
m.exports = MyNativeExtension.decrypt(fs.readFileSync(m.filename));
};
require("YourCode.jse");
This will convert your JavaScript code to a .jse, which you would then package for production. Considering the encryption is done inside the native extension, the encryption key wouldn't be revealed.
Hope this helps! :)

Yes, you definitely can. It may, however, take a while to transition existing code, and if this is for a corporate institution, you'll have to ask your coworkers and your boss/supervisor. Good luck, and remember, always document your code in JavaScript (no types) all languages.
NodeJS is much faster: http://www.hostingadvice.com/blog/comparing-node-js-vs-php-performance/
Many more libraries: http://npmjs.org
Only need one language for everything

Comparing PHP with another technology like Node.js which is meant for an entirely different type of task, comparer must mention the difference of use-case/context in which one is suitable over others.
Let's talk about in terms of a different area of execution because we can not Disgrace any of them and both have its own priority.
If you talk about in terms of Application Domain.
PHP :
CMS (Content Management Systems) like WordPress, Drupal also use PHP which makes it possible to be used in creating blogs, websites, e-commerce sites, etc.
Used in developing CPU-intensive applications like meteorology applications and scientific applications.
should be used in applications in which the client does not have to interact with the server again and again
PHP 7 is based on the PHPNG engine that speeds up PHP applications more than the previous PHP interpreter (Zend Engine 2.0). Thanks to PHPNG, your apps see up to the 2x faster performance and 50% better memory consumption than PHP 5.6.
NodeJs:
Nodejs is ideal for developing highly scalable server-side solutions because of its non-blocking I/O, and event-driven model.
Used massively in Real-time applications like chat applications, blogs, video streaming applications.
Used in developing single-page applications like resume portfolios, individual websites.
Node.js should be used for the applications which require a lot of interaction between client and server.
For some tasks, Node.js may be faster than the “standard” web server with PHP because it runs as a single thread with non-blocking IO for each connection, hence there is no memory overrun. Due to this, Node.js is useful when there is a need to process data in real-time (chats, games, video, big data streams without logic)
PHP is Still alive and he has learned its lessons from Node.JS
ReactPHP enables developers to write PHP-based socket server to process requests constantly as well as Node.js does it (yes, Node.js is faster, but the fact is that PHP can also do it). The same thing with Workers (the classes responsible for running asynchronous jobs and synchronizing their results) or Amp (libraries that are used for writing non-blocking asynchronous code). Hence, it is easy to create long-running processes using PHP. Additionally, there are a lot of tools for supporting and managing these processes (such as supervisord).
So, the same tasks may be performed either with PHP or with Node.js. The question “what tool to use” is a question of personal preferences. you can use Node.js for tasks involving big data flows and PHP for tasks involving complex logic, high-load tasks, for dealing with external utilities, applications, and OS.
From the scalability perspective, there are no big differences between PHP and Node.js, it is more important to consider the project’s architecture.
Dayle Rees (a Laravel Framework contributor and developer): For a long time PHP was the butt of many language jokes, but I honestly feel that it’s becoming not only a popular language but a powerful one. PHP7 is great. The speed boost is one thing, but having optional support for full type hinting is a game changer. We’ve also got modern tools like Laravel and Composer, breathing new life into the language and its supporting community. With this in mind, I think it’s unlikely that Laravel will move from PHP. I think it’s more likely to gain further integration with front-end tools to provide a complete application building platform. That’s where I see it heading in terms of future expansion. I’m sure the Node will continue to excel when dealing with microservices and threaded applications.
The most important and most awaited News from PHP is, PHP is scheduled to receive a Just In Time (JIT) compiler in its next major version PHP-8 (most probably in sep-2021).This is going to boom the php and it breaks all his limitation due to JIT.
Wrap up
To wrap up Both have some pros, both have some cons but the amazing thing is both are created by intellects to make the web development better. While selecting the technology the question shouldn’t be which one is better but which one can serve your project needs in a better way. Understanding your project and business logic can give you a clear idea about selecting the right technology for your project.Moreover, one more important thing to consider is the skills and proficiency of the developers using the technology, how they use them and apply to the project.

Avoiding writing the same algorithm in multiple different languages

I am a web developer, and I have observed that many times I need the same function on both client and server. So I write it in JS as well as in PHP or whichever server side language. I am fed up with this. If I have to change it then I need to change it in both places. If I want to use it for some hand held devices, then I will have to rewrite that code yet again using objective-C or Java etc. Then if I need to change that function then I will need to change it everywhere.
Is there a solution for this? If I will call some webservice via ajax, then the client will have a delay. If it will be in JS then it can't be accessed from within PHP or Java, etc. If I use some service in PHP from another language then that can also become a performance issue.
It is also possible that some time we need such functions output from some paramters as input using db or without db.
I know there would be some pretty simpler solution but I am not aware of that. Please tell some language independent solution as I don't have VPS always.
I am not sure if my question actually belongs to stackoverflow.com or programmers.stackexchange.com so please transfer it to programmers.stackexchange.com instead of closing this question if it belongs to there.

Typically, the solution to this problem is to write common code in one language and use translators or library linking to allow access from other languages.
Node.js allows you to write server-side code in JavaScript.
Node.js is a platform built on Chrome's JavaScript runtime for easily building fast, scalable network applications. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices.
You can also use JavaScript to write HTML5 apps for mobile devices.
"Building iPhone Apps with HTML, CSS, and JavaScript"
Now web designers and developers can join the iPhone app party without having to learn Cocoa's Objective-C programming language. It's true: You can write iPhone apps quickly and efficiently using your existing skills with HTML, CSS, and JavaScript. This book shows you how with lots of detailed examples, step-by-step instructions, and hands-on exercises.
If you don't want to try to write large complex applications in JavaScript, GWT provides a way to write Java and via-translation, run it on the client.
The GWT SDK contains the Java API libraries, compiler, and development server. It lets you write client-side applications in Java and deploy them as JavaScript.
If you develop in .Net languages: C# -> JavaScript ScriptSharp
Script# is a free tool that enables developers to author C# source code and subsequently compile it into regular script that works across all modern browsers

you could use the spidermonkey extension to translate php into javascript. this way you can write your functions in php then simply convert them to javascript and re-use them at the browser.
here is a good tutorial to show you how this is done

where does node.js fit within the web development context?

I know that node.js is said to be "event-driven I/O" server-side javascript hosted on V8 Javascript engine. I visited the node.js website, and then read the wikipedia entry, but cant quite get the whole idea of where to use it and how it will be useful. "Event-driven I-O"? "V8 Javascript engine"? In some context though, I see that using "server-side" javascript as a little overkill..I take for instance this piece of code in the wikipedia entry of node.js:
var http = require('http');
http.createServer(function (request, response) {
response.writeHead(200, {'Content-Type': 'text/plain'});
response.end('Hello World\n');
}).listen(8000);
console.log('Server running at http://127.0.0.1:8000/');
I have been thinking, is there really a significant purpose in running a server that particularly serves javascript files that are executed in the front-end part of the application?
I also forked the node.js repo in github to learn more about how it works, and it turns out that some of its modules are written in C++. So it is not a javascript after all then?
Can somebody give me a clear explanation about all this? Sorry if the question is not clear or something, I am just a beginner. Will appreciate any input/suggestions. thanks

The node.js server is, in simple terms, a replacement for something like the Apache web server - but it is largely written in JavaScript which runs on the server (executed by the V8 engine) rather than on the client side. It can be extended with 'native code' modules (written in e.g. C++) wrapped in a JavaScript interface to add functionality, but AFAIK most node.js modules are pure JavaScript.
"Event driven I/O" is just a term that describes the normal asynchronous callback mechanisms you're used to in JavaScript. In node.js you supply callbacks for all sorts of things, and your function is called when the relevant event occurs.
Depending on how many modules you add, a node.js server is relatively lightweight compared to something like Apache, and in some ways a lot simpler.
The two main advantages to node.js I see are:
It allows you to write both the server-side and client-side parts of a web application in the same language. In some cases you can use the same code on both sides.
It makes server-side coding accessible to all those web developers out there that know JavaScript without having to learn a more common server-side language like PHP or Java.
Here's an article I just came across that might also shed some light: What is Node.js?

While I can't add much to what #sje said, I will repeat that blog link he shared, as that is the best resource that I've found to explain nodejs quickly:
http://radar.oreilly.com/2011/07/what-is-node.html
Also note that it's from OReilly, who most of us know as being the publisher of the best references for programmers on the market in general ;)
I have been thinking, is there really a significant purpose in running a server that particularly serves javascript files that are executed in the front-end part of the application?
This is totally wrong. This is the most wrong assumption about node you could make. Node runs the javascript on the server much as ruby or php or asp.net code is run. The fact that the browser can also run javascript has no bearing on node.
Granted, you can share modules between the server and the client (for instance, validation routines for form data) but by and large the codebases are different as they are intended for different things.
I also forked the node.js repo in github to learn more about how it works, and it turns out that some of its modules are written in C++. So it is not a javascript after all then?
Yes, node is a server that interprets javascript using the V8 engine. It has to be written in something. I'll give you a comparison: Microsoft .NET code is mostly written in .NET on top of .NET, but the main code that actually does the work, the runtime (the CLR as most people refer to it) that manages the managed-code, that code is written in C. The same thing with node. Yes, most of it (as you saw) is written in javascript, but the core libraries that run everything else are written in C.
Can somebody give me a clear explanation about all this? Sorry if the question is not clear or something, I am just a beginner. Will appreciate any input/suggestions. thanks
I hope this helped clear it up in part. There's a lot to cover, and without going into evented-io (which involves understanding processes and threads and io access and a lot of other stuff) this is pretty much the basic high-level answer to this question. I invite you to the nodejs room on the chat server here if you like, for more random discussions that are fluid. https://chat.stackoverflow.com/rooms/642/node-js
As to the first question you asked:
Where does it fit in?
The same place ruby and php and perl and python and asp.net do. On the server, generating code that the client receives.

I haven't seen anyone give a simple answer to this yet.
Node.js is:
the v8 javascript engine
an event loop
some c++ bindings, among other things, that give v8 IO capabilities (both network and file IO)
It's important to note, Node doesn't necessarily have to be used for web development either. It's purpose is, "evented IO".

Execute javascript on IIS server

I have the following situation. A customer uses JavaScript with jQuery to create a complex website. We would like to use JavaScript and jQuery on the server (IIS) for the following reasons:
Skills transfer - we would like to use JavaScript and jQuery on the server and not have to use eg VB Script. / classic asp. .Net framework/Java etc is ruled out because of this.
Improved options for search/accessibility. We would like to be able to use jQuery as a templating system, but this isn't viable for search engines and users with js turned off - unless we can selectively run this code on the server.
There is significant investment in IIS and Windows Server, so changing that is not an option.
I know you can run jScript on IIS using windows Script host, but am unsure of the scalability and the process surrounding this. I am also unsure whether this would have access to the DOM.
Here is a diagram that hopefully explains the situation. I was wondering if anyone has done anything similar?
EDIT: I am not looking for critic on web architecture, I am simply wanting to know if there are any options for manipulating the DOM of a page before it is sent to the client, using javascript. Jaxer is one such product (no IIS) Thanks.

Have a look at bringing the browser to the server, Rhino, and Use Microsoft's IIS as a Java servlet engine.
The first link is from John Resig's (jQuery's creator) blog.
Update August 2 2011
Node.js is coming to Windows.

The idea to reuse client JS on the server may sound tempting, but I am not sure that jQuery itself would be ready to run in server environment.
You will need to define global context for jQuery somehow by initializing window, document, self, location, etc.. I am not sure it is doable.
Besides, as Cheeso has mentioned, Active Server Pages is a very outdated technology, it was replaced with ASP.Net by Microsoft in the beginning of the century. I used to maintain a legacy system using ASP 3.0 for more than a year and that was pain. The most wonderful pastime was debugging: you will hardly find anything for the purpose today and will have to decript beautiful errors like in IIS log:
error '800a9c68'
Application-defined or object-defined error
Nevertheless, I can confirm that I managed to reuse client and server JScript. But this was code written by me who knew that it was going to be used on the server.
P.S. I would not recommend move that way. There are plenty templating frameworks which are familiar to those who write HTML and JavaScript.

JScript runs on IIS via something called ASP.
Active Server Pages.
It was first available in 1996.
Eventually ASP.NET was introduced as a successor. But ASP is still supported.
There is no DOM for the HTML page, though.
You might need to reconsider your architecture a bit.

I think the only viable solutions you're likely to find anywhere near ready to go involve putting IIS in front of Java. There are two browser-like environments I'm aware of coded for Java:
1) Env-js (see http://groups.google.com/group/envjs and http://github.com/thatcher/env-js )
I believe this one has contributions from jQuery's John Resig and was put together with jQuery testing/support in mind.
2) HTMLUnit (see http://htmlunit.sourceforge.net/ ) This one's older, and wasn't originally conceived around jQuery, but there are reports in the wild of using it to run jQuery's test suite successfully (http://daniel.gredler.net/2007/08/08/htmlunit-taming-jquery/ ).
If you want something pure-IIS/MS, I think your observation about windowsScript host and/or something like the semi-abandoned JScript.NET is probably about as close as you're going to come, along with a port (which you'll probably have to start) of something like Env-js or HTMLUnit.
Also, I don't know if you've seen the Wikipedia list of server-side JavaScript solutions:
http://en.wikipedia.org/wiki/Server-side_JavaScript
Finally... you could probably write a serviceable jQuery-like library in any language that already has some kind of DOM library and first-class functions (or, failing that an eval facility). See, for example pQuery for Perl (http://metacpan.org/pod/pQuery ). This would get you the benefits of the jQuery style of manipulating documents. Skill transfer is great and JavaScript has a wonderful confluence of very nice features, but on the other hand, having developers who care enough to learn multiple languages is also great, and js isn't the only nice language out there.

I think it's mainly a browser based script so probably you are better of using technologies based on VB or .NET to perform or generate HTML from templates. I'm sure there are because in the java world there are a few of these around (like velocity). You'd then use jQuery to create or add client side functionality and usability so it makes the website more usable than it would have been.

What exactly do you mean by
"A customer uses JavaScript with
jQuery to create a complex website"
Half the point of jQuery is to make it easy for the developer to manipulate the DOM, and therefore add interactive enhancements to a web site. By running the Javascript on the server and only rendering HTML you will lose the ability to add these enhancements, without doing a round trip to the server (think WebForms postback model...ugh).
Now if what you really mean is the customer uses a site builder based on jQuery, why not have that tool output flat HTML in the first place?

Take a look at this technology. You can invoke scripts to run at server, at client, or both. Plus, this really implements the firefox engine on the server. Take a look at it.
Aptana's Jaxer is the first AJAX web server so far. I have not tryed it yet, but I will. Looks promising and very powerful.

Server Side Javascript: Why?

Is the use of server side javascript prevalent? Why would one use it as opposed the any other server side scripting? Is there a specific use case(s) that makes it better than other server side languages?
Also, confused on how to get started experimenting with it, I'm on freeBSD, what would I need installed in order to run server side javascript?

It goes like this:
Servers are expensive, but users will give you processing time in their browsers for free. Therefore, server-side code is relatively expensive compared to client-side code on any site big enough to need to run more than one server. However, there are some things you can't leave to the client, like data validation and retrieval. You'd like to do them on the client, because it means faster response times for the users and less server infrastructure for yourself, but security and accessibility concerns mean server-side code is required.
What typically happens is you do both. You write server-side logic because you have to, but you also write the same logic in javascript in hopes of providing faster responses to the user and saving your servers a little extra work in some situations. This is especially effective for validation code; a failed validation check in a browser can save an entire http request/response pair on the server.
Since we're all (mostly) programmers here we should immediately spot the new problem. There's not only the extra work involved in developing two sets of the same logic, but also the work involved in maintaining it, the inevitable bugs resulting from platforms don't match up well, and the bugs introduced as the implementations drift apart over time.
Enter server-side javascript. The idea is you can write code once, so the same code runs on both server and client. This would appear to solve most of the issue: you get the full set of both server and client logic done all at once, there's no drifting, and no double maintenance. It's also nice when your developers only need to know one language for both server and client work.
Unfortunately, in the real world it doesn't work out so well. The problem is four-fold:
The server view of a page is still very different from the client view of a page. The server needs to be able to do things like talk directly to a database that just shouldn't be done from the browser. The browser needs to do things like manipulate a DOM that doesn't match up with the server.
You don't control the javascript engine of the client, meaning there will still be important language differences between your server code and your client code.
The database is normally a bigger bottleneck than the web server, so savings and performance benefit ends up less than expected.
While just about everyone knows a little javascript, not many developers really know and understand javascript well.
These aren't completely unassailable technical problems: you constrain the server-supported language to a sub-set of javascript that's well supported across most browsers, provide an IDE that knows this subset and the server-side extensions, make some rules about page structure to minimize DOM issues, and provide some boiler-plate javascript for inclusion on the client to make the platform a little nicer to use. The result is something like Aptana Studio/Jaxer, or more recently Node.js, which can be pretty nice.
But not perfect. In my opinion, there are just too many pitfalls and little compatibility issues to make this really shine. Ultimately, additional servers are still cheap compared to developer time, and most programmers are able to be much more productive using something other than javascript.
What I'd really like to see is partial server-side javascript. When a page is requested or a form submitted the server platform does request validation in javascript, perhaps as a plugin to the web server that's completely independent from the rest of it, but the response is built using the platform of your choice.

I think a really cool use of server-side Javascript that isn't used nearly often enough is for data validation. With it, you can write one javascript file to validate a form, check it on the client side, then check it again on the server side because we shouldn't trust anything on the client side. It lets you keep your validation rules DRY. Quite handy.
Also see:
Will server-side Javascript take off? Which implementation is most stable?
When and how do you use server side JavaScript?

Javascript is just a language. Because it is just a language, you can use it anywhere you want... in your browser, on the server, embedded in other applications, stand-alone applications, etc.
That being said, I don't know that there is a lot of new development happening with "Server-Side Javascript"

Javascript is a perfectly good language with a self / scheme prototype style base and a C style syntax. There are some problems, see Javascript the Good Parts, but in general it's a first rate language. The problem is that most javascript programmers are terrible programmers because it's very accessible to get started.
One team at google built out Rhino on Rails, which is an MVC framework like Ruby on Rails which is written in javascript and runs on Rhino a javascript interpreter for the Java VM. In this case they had a requirement to use the Java VM, but wanted to get a language which was fast (javascript is fast), supported duck typing, and was flexible.
Another example is something like CouchDB, a document oriented database which uses json as it's transport format and javascript as it's query & index language. They wanted the database to be as web native as possible.
Javascript is good at string and dom (xml) manipulation, being sandboxed, networking, extending itself, etc... Those kind of features are the thing you often do when developing web applications.
All that said, i don't actually develop server side javascript. It's not a bad idea, but definitely less common.

We use javascript on the client because it is there, not because from a list of languages it was our choice. I wouldn't choose it for any chore on the server.
You can run any language you like on the server, in fact, as many as you like.
javascript is reliable and easy to use, but it is just too labor intensive for common tasks on the server.

I have used both Javascript (NodeJS) and compiled languages (such as Java or C#.NET). There are huge discussions on the internet about which is preferable. This question is very old (2009). Since then the Javascript world has changed considerably, whereas honestly the Java world has not changed much (relatively).
There have been huge advancements in the Javascript world with Typescript, amazing frameworks (such as Next.JS), reactive programming, functional programming, GraphQL, SSR etc.
When I look at compiled code, especially Java code it all still seems to be the same old tools - Spring (maybe SpringBoot) and Jackson. .NET has advanced server side, but not to the extent of the JS world.
Sure my list there can be used with several languages, but I believe Javascript has improved the software engineering world considerably.
Server side development with Javascript, Typescript and NodeJs is engaging, fun and productive. Use it and enjoy it. Like millions are today.