News, articles and recipes about SmartFoxServer and multiplayer game development

JavaScript is back!

With the release of SFS2X 2.13 last week we’re happy to reintroduce JavaScript as a server side language. For those familiar with the history of SmartFoxServer, JavaScript has been available since the early days of SFS PRO for writing server side code, and it’s now coming back thanks to the latest improvements in JDK 7 and 8.

In particular the latest Java 8 has brought developers a new, more efficient JavaScript engine (codename Nashorn) that surpasses the limitations of good old Apache Rhino making it possible to write efficient code on par with the most advanced JavaScript VMs found in modern browsers.

» A quick look at server side JavaScript

To give you an idea of how JavaScript Extensions look like here’s a quick example:

This should all look familiar to anyone who is even minimally familiar with SFS2X. We have the usual init() method, which is mandatory, where we can setup global variables and listeners for client requests and events.

Where in Java we have to define a new class for each request/event handler here we can directly point to a locally defined function. Similarly we can declare custom functions to handle specific server side events:

» X-Ray of a JavaScript Extension

To provide a better understanding of how JavaScript server code works here is a simple diagram that exemplifies the basic architecture:

JavaScript code, which can be split in multiple scripts, is loaded with the relative API and compiled on the fly by the Nashorn engine in SmartFoxServer 2X which manages the communication between the Java and JS API calls in both directions.

This allows JavaScript code to access all of the server’s API with no particular restrictions so, effectively making JavaScript a first class citizen in the SFS2X environment.

» Limitations

The main restraint in JavaScript Extensions is threading. Since the language doesn’t provide any support for threads, there is no way to handle concurrency other than using the tools offered by Java. Also none of the native data types in JavaScript (numbers, strings, arrays, objects, etc) are thread safe. For this reason JS Extensions run fully synchronized, all the time.

To unpack this further by “fully synchronized” we mean that two or more concurrent calls to the same Extension will execute serially instead of in parallel which can impact scalability to a certain degree. How much depends on multiple variables such as the amount of concurrent calls and hardware resources available.

» JavaScript over Java, or vice versa?

Obviously the first reason to choose JavaScript is familiarity: if your developers have little or no experience in Java then JavaScript will definitely be the choice to start working with server side code.

If you can choose between the two languages, and you’re looking for the best performance and scalability then Java is the best choice. On the other hand, if you’re willing to compromise a slice of performance for faster development cycles and a simpler language then JS is likely your best bet.

Finally there’s also an interesting middle ground where you can choose to write Extensions using both languages, as they integrate very easily. This approach can offer the best of both worlds, allowing to write only performance critical parts in Java and the remaining logic in JavaScript.

» Resources

To learn more about JavaScript Extension development we highly recommend these three in-depth articles recently added to our documentation website: