{"id":657,"date":"2017-05-09T08:36:31","date_gmt":"2017-05-09T08:36:31","guid":{"rendered":"http:\/\/smartfoxserver.com\/blog\/?p=657"},"modified":"2017-05-15T14:54:06","modified_gmt":"2017-05-15T14:54:06","slug":"javascript-is-back","status":"publish","type":"post","link":"https:\/\/smartfoxserver.com\/blog\/javascript-is-back\/","title":{"rendered":"JavaScript is back!"},"content":{"rendered":"

With the release of SFS2X 2.13\u00a0<\/strong>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.<\/p>\n

<\/p>\n

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.<\/p>\n

\u00bb\u00a0A quick look at server side JavaScript<\/h3>\n

To give you an idea of how JavaScript Extensions look like here’s a quick\u00a0example:<\/p>\n

\r\nfunction init()\r\n{\r\n    addRequestHandler("sum", onSumRequest);\r\n\r\n    trace("Simple JS Example inited");\r\n}\r\n\r\nfunction destroy()\r\n{\r\n    trace("Simple JS Example destroyed");\r\n}\r\n\r\nfunction onSumRequest(params, sender)\r\n{\r\n    var a = params.getInt("a");\r\n    var b = params.getInt("b");\r\n\r\n    var response = new SFSObject();\r\n    response.putInt("res", a + b);\r\n\r\n    send("sum", response, [sender]);\r\n}\r\n<\/pre>\n
This should all look familiar to anyone who is even minimally familiar with SFS2X. We have the usual init()<\/strong> method, which is mandatory, where we can setup global variables and listeners for client requests and events.<\/p>\n
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:<\/p>\n
\r\nfunction init()\r\n{\r\n    addEventHandler(SFSEventType.USER_JOIN_ZONE, onNewUser);\r\n    trace("Simple JS Example inited");\r\n}\r\n\r\nfunction destroy()\r\n{\r\n    trace("Simple JS Example destroyed");\r\n}\r\n\r\nfunction onNewUser(event)\r\n{\r\n    user = event.getParameter(SFSEventParam.USER);\r\n    trace("Welcome new user: " + user.getName());\r\n}\r\n<\/pre>\n
\u00bb X-Ray of a JavaScript Extension<\/h3>\n
To provide\u00a0a better understanding of how JavaScript server code works here is a simple diagram that exemplifies the basic architecture:<\/p>\n
\"JS<\/a><\/p>\n
 <\/p>\n
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.<\/p>\n
This allows JavaScript code to access all of the server’s API with no particular restrictions so, effectively making JavaScript \u00a0a first class citizen in the SFS2X environment.<\/p>\n
\u00bb\u00a0Limitations<\/h3>\n
The main restraint\u00a0in JavaScript Extensions is threading.\u00a0Since the language\u00a0doesn’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\u00a0Extensions run fully synchronized, all the time.<\/p>\n
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\u00a0scalability\u00a0to a certain degree. How much depends on multiple variables such as the amount of concurrent calls and hardware resources available.<\/p>\n
\u00bb \u00a0JavaScript over Java, or vice versa?<\/h3>\n
Obviously the first reason to choose JavaScript is familiarity: if your developers have little or\u00a0no experience\u00a0in Java then JavaScript\u00a0will definitely be the\u00a0choice to start working with server side code.<\/p>\n
If you can choose between the two languages, and you’re looking for the best performance and scalability then Java is the best choice<\/strong>. On the other hand, if you’re willing to compromise a slice of performance for faster development cycles and a simpler language then JS\u00a0is likely your best bet.<\/p>\n
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\u00a0in Java\u00a0and the remaining\u00a0logic\u00a0in JavaScript.<\/p>\n
\u00bb\u00a0Resources<\/h3>\n
To learn more about JavaScript Extension development we highly recommend these three in-depth articles recently added to our documentation website:<\/p>\n