I've got a simple Javascript application with a JSON API. Currently it runs in the client, but I'd like to move it from the client to the server. I am accustomed to learning new platforms, but in this case, my time is very limited - so I need to find the absolute simplest way possible.
This should be an easy task, but all I'm finding are solutions that are way overcomplicated:
The application is currently hosted on an extremely basic server. Node.js is not available, and I do not have install privileges. I'll eventually move it to a different server, but I really don't know what will be available there.
Many solutions require installing and running a standalone server. Really? Just to evaluate Javascript server-side and spit out some data?
I can run Python and PHP, and I see that it's possible to call Javascript from inside a Python or PHP script. However, the specific Python solution that I've found also require installing some Python support via pip or easy-install, so probably not an option. Also, this just feels overcomplicated, and I'm concerned about setting myself up for errors such as data conversion or permissions, etc.
Any help?
#Quentin is correct. There is no way to run javascript on a server without a javascript interpreter on the server.
Node.js is not only the most robust and widely used one, it's also the simplest. It is certainly possible to write your own javascript interpreter in PHP or Python, but that would be much more complicated than using Node.js.
Try really hard to find a server solution that allows you to use Node. In the end, it's going to save you (and any other stakeholders interested in the project) a lot of time and money.
Related
I am working on an audio editing prototype. At the moment it is very simple, so it currently works as a Web App using JavaScript, HTML and CSS. This makes it possible to build as an Electron app, using Node.js to access the file system.
However, it makes heavy use of a Python program called Gentle, particularly the file align.py. I was wondering if it was possible to integrate this program somehow, given how frequently it is used.
I am not familiar with Python, but I have tried to work out if this can be done. I have read about child_process, python-shell and zerorpc. However, if possible, I do not want to force the user to install Python along with all the dependencies required for Gentle, as it is a difficult process with lots of room for error.
This is where I have become stuck. Ultimately I am looking for a way to use Gentle in a way which gives the appearance of it being part of the functionality as a single self-contained program, rather than butchered on with duct tape.
I realize Gentle includes the option for a REST API and a Python server, but I am more interested in using Gentle offline for faster functionality. I am also too broke to afford hosting.
I realize I am kind of working backwards, as the front-end normally comes after the back-end. If it is easier I can try to rewrite the code base in Python or a lower-level language, but I am trying to avoid this if possible.
Any help or suggestions would be greatly appreciated!
You can compile the Python program and include the resulting binary file into your Electron app and just run the binary via child_process. There are several ways to create executables from Python programs.
There's a lot of mixed results when I search around for emulating a browser. Long story short, I need my Node server to do get & post requests. Usually I'd just do this with the http package. However, there is some anti-scripting things in place on the other side. Namely javascripts that let the server know it's a real browser. So, I need these to be executed.
I actually solved this problem like 5 years ago, but my site was only using PHP then. The solution involved using a Qt webkit widget, and a fake X-server. Not elegant, but it was pretty easy to do. The only javascript engines I found available in Perl, PHP, or Python at the time were crazy slow.
As NodeJS is built on V8, I gotta think there's an easy way to do this. For the record, I'm hoping to get something a la the following.
// Omitting some callbacks
http.get('http://remote.site', function(res) {
res.on('end', function() {
// previously accumulated data is the page returned by
// the request. Any thing found in a <script> tag would have
// been executed.
});
});
As NodeJS is built on V8, I gotta think there's an easy way to do this.
Actually, no! There's a lot more to running in the context of a browser than simply being able to execute JavaScript. All of the DOM stuff and what not is no present in Node.js. Node.js has the JavaScript engine only.
Without the browser engine, you won't know what scripts to load, in what order, or be able to provide everything that comes with the document or window, which is likely a required part of what you're trying to do.
The solution involved using a Qt webkit widget, and a fake X-server. Not elegant, but it was pretty easy to do.
This is actually the right solution... mostly. Fortunately these days there are existing tools which have optimized this reasonably well.
Take a look at PhantomJS. http://phantomjs.org/ You can write scripts for it much in the same way you do Node.js. (It supports require() and what not, and most of the NPM packages you'd want work.) PhantomJS will allow you to run the page and pull the DOM contents out easily.
In the event PhantomJS' built in JavaScript environment doesn't contain some Node.js component you need (for filesystem or network access for example), you can always control PhantomJS from your Node.js application. https://github.com/amir20/phantomjs-node
I'm thinking of switching from PHP to using Node.js for developing my website. However, after researching Node.js for a little while, I can't seem to find exactly how to write a webpage with Node. I see that you use response.write() in Node to write html to your webpage, but that seems like a tedious thing to do, having your entire webpage as a string literal in your node file. How does web development work in Node as opposed to PHP's method of embedding the script into the HTML file?
You don't necessarily need to use response.write for each line of the view, you can use template engines as well. Search for "node.js template engines". At first impression it could seem tedious, but a similar approach prevents you from writing bad code.
PHP is a scripting language, node is a platform built on javascript.
To start web development using node.js, at first you have to understand what makes node different. Node gives you a way to make async calls to your database (which is a very simplified explanation), which you can then wrap in nice html and send (route) it to the browser. Alternatively, you can use something like angular.js in the frontend and use node.js to make db requests and response which is picked up by angular.js which updates the front html. If you like the idea of Single page app with async calls to fetch data, use node with angular. The tutorial that I like is https://scotch.io/tutorials/creating-a-single-page-todo-app-with-node-and-angular Hope this helps!
As others have answered, there exist templating engines for Node. With the current trends in web development, most modern web frameworks encourage the separation of code from the view (or the HTML you deliver to the client). For instance, Ruby's ERB templates, Jinja2 in Python, Handlebars/Jade for Node, and now a lot of modern PHP frameworks support this as well (Zend/Slim).
Another main difference is in how they work and how the languages are designed. PHP is an object oriented language supporting classes, inheritance, member visibility, interfaces, etc. Node.js is Javascript, so using prototypical inheritance.
The communities and ecosystems are different as well. Modern PHP tends to embrace the use of the Composer package manager, and that came after PEAR. However, npm is the official node package manager and it is deeply integrated with the platform. It is trivial to search for new packages and then use them in your projects.
The main architectural difference is that Node is also asynchronous by design, meaning it runs in a single thread and can potentially handle much more connections than PHP on systems with limited memory. When a request comes in to a PHP application, all the services/controllers and everything you defined have to be reinstatiated, you define PHP files and let Apache/Nginx process them. In Node you have a node process which you can proxy outside requests to.
Node.js Provides so many modules to do these things there is framework called express for node.js http://expressjs.com/ You can use a templating engine and create views. some examples are like ejs or jade. It doesnt have to be a string.
PHP is very strongly orientated towards creating web pages from a template, while Node.js is lower-level and broader in scope. A very rough overview of the differences between PHP and Node.js:
In PHP, you'd start a web server (almost certainly Apache), and then put a PHP file in a directory where you want to serve something from. You might use some fancy .htaccess directives to make URLs nicer, etc.
In Node.js you create a script, in which you use the http module to start a web server, and then you supply a callback for whenever a request is made to your server. Deciding which page to respond to the request with, etc, is all your work to do.
In PHP, things like routing a request to a particular PHP file, compression, decoding POST and GET variables, are all done by using Apache - your PHP files are sort of just like templates which Apache runs whenever a request is received. In Node.js, everything, from starting the server to sending HTML, is all done within your Node.js script - you have to do everything.
HTML isn't the first class citizen in Node.js that it is PHP. Generally, in Node.js you are just sending strings to the client. There are plenty of third party templating tools for Node.js - but they will be dependencies, not builtin functions.
The company I'm working at uses Perl for all "backend related" stuff. However, we would like to use some real-time communication between server-processes and connected clients via browser.
We are also using Apache as Webserver with mod.perl. So that is my first question, I don't see any practical way to combine a WebSocket-Server in that constelation. Maybe there is one I didn't found yet?
The only thing which really works serious about that topic, is Mojolicious. However I'm not that experienced with that yet, so I'd be happy if someone could state if I can use that in my current mod-perl environment. I think I also would have to let this run as standalone webserver process, No?
Which brings me to my second question. What is the best practice, if you have multiple perl files, which do certain things running on Apache/modperl, but you want to keep all your connected users informed about things. What I mean is, all these scripts are accessed via XHR, but some actions require other users to get informed. Currently, we do a classic ajax polling.
The problem I'm struggling around with is, that if there is a dedicated websocket server, which runs independently, all those scripts would need to somehow communicate with this process as well right ? How would one do that? Pipes? Sockets? Shared memory ?
Theoretically, if I would choose to go with such an independent ws server solution, I could write it in any language right? Could even be Ruby or Node. I'm just wondering if that is the best way or if there is a good solution which is more integrated in existing perl/modperl constructs.
TL;DR
Is it best practice to have a standalone, independent web-socket server which communicates with the rest of your Apache/modperl scripts aswell as with its connected clients ?
You could look on AnyEvent CPAN module:
http://metacpan.org/pod/AnyEvent
With it you can write your own standalone event-driven WebSocket-server, also you could find a lot of examples in google or in AnyEvent's perldoc.
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.