typeof JavaScript != typeof Java
Recently, I’ve been re-working an old project in Java. For those that are familiar with the PC Minecraft community, a couple years ago a plugin enabled server called “Bukkit” existed. It was handy, it was modular, and it was good. There was a problem though, which caused the fallout of the custom server. You can read more of the store here. During those days though, I had helped create a plugin that essentially allowed you to skip writing in Java and use JavaScript instead with Java’s Rhino engine.
But the upkeep was no joke. This was in the time where Java was on the tightrope of Java 7 and 8 (the new JavaScript engine Nashorn was a big redux to Java). So the project was dropped for a while after having stability, but something always prevented me and others from returning to it. It always felt…clunky. Like the JavaScript was organized in a way that Java was. Now this all happened before I’d became a web-developer. Sure, I’d tinkered with JavaScript, CoffeeScript, etc. But I still hadn’t learned the patterns and styling of web, so I followed what I knew: server and systems layout. It was embarrassing now that I look back at it, to say the least.
Several months ago, a group that I’m apart of online brought the idea up to me “we should remake a Spigot server!” (the predecessor of Bukkit but by a different team). It was an idea I’d thought of time and time again, but I was never one for building or civil engineering. That creativity was lost to me. So to do my best to give those that would be the best tools, I decided to kick up the JavaScript plugin. This is all a couple years that I’d now been a seasoned web-developer. Time to put my practices into good use for another project. So began my work to remake NodeJS on top of Java’s Nashorn engine so a Node developer could be familiar with the environment.
So why the long backstory? Well, before remaking the plugin myself, I tried to see if maybe someone had made a better one. I’d of liked to see because there’s no use reinventing the wheel, even if you were one of the first ones to make it. Searching yielded one result above others: ScriptCraft. I’m not here to demean the quality of the product that was made here, as it’s definitely good. But in my eyes, it’s something that is not quite…kosher. An example is the modules folder in ScriptCraft. Where some are described as proper modules directories like NodeJS, others are just individual files. So while some may be comfortable with that, I’m not. My OCD leads me to organize in a much more definite pattern. And while this is one example, I see it way too commonly in projects like this.
ScriptCraft isn’t the only JS plugin service for Spigot, Bukkit, SpongeAPI, and all the rest, but they all share one thing in common: they all treat the JavaScript like Java. What do I mean by this? They’ll load the JavaScript compiler and then let the developer do the rest. This means they’ll leave the developer to use the Java API rather than a JS API, thereby defeating one of the main purposes of using JS. Where this occurs is something like the console object within JS. It doesn’t exist in Nashorn, so you have to create a custom StreamWriter to write to the default output stream then tie those functions to a global console object, but ScriptCraft is the only one I’ve seen do this. Module loading also is not built into Nashorn. Both my require library and ScriptCraft’s follow CommonJS’s standards, but no other libraries I’ve found do the same. People simply create the engine to run the code on, but not the environment, and it doesn’t seem to be stopping anytime soon. The only way I see to curb this is for developers learn more about the goal they’re trying to achieve. Coding isn’t just about writing the code. It’s about planning it out, making use of each and every function to finish the product.
So there goes my rant for today. Maybe it was too long, maybe it was too short, but it for sure let off some steam.
console.log('Until next time,');
console.log('Justin Cox');
let nextPost = await writer.getPost();