Let me try to give a different perspective on NodeJS: We've been building tools to work with Excel files. The hardest problems aren't related to writing code.

Let me try to give a different perspective on NodeJS: We've been building tools to work with Excel files. The hardest problems aren't related to writing code. It's all about finding files that use different combinations of Excel features from different versions of Excel (and files from external tools that read/write files). For example, if you start from Excel 2011/2013, you wouldn't know about the custom smart tags that were removed in Excel 2010. However, those records are still persisted (e.g. BrtWbFactoid in XLSB), so you would need to produce a file from Excel 2007 to actually reproduce the error. For other people to discover errors in python or java libraries, they have to try it in some capacity. That either involves installing something foreign (which may be prohibited or undesirable) or submitting data to a third party (which is most likely forbidden). A pure-JS in-browser solution can address both problems effectively. We have a cool little web demo which parses excel files in the web browser: http://oss.sheetjs.com/ http://oss.sheetjs.com/ No installation required. Files are processed in the web browser (HTML5). We've received reports from many organizations involving confidential data. Over time, we've built other tools to inspect features of files without requiring that people send us the original file, and this allowed us to test bugfixes without having to share files. Now for the really cool part: NodeJS exposes some features like Buffers that make data processing competitive with python or other scripting languages. But since it uses the same code for parsing, fixes to the web version immediately benefit the NodeJS version. As a result, our server-side code (http://npm.im/xlsx http://npm.im/xlsx and http://npm.im/xlsjs http://npm.im/xlsjs) benefits from the performance of V8 and from the exposure that a browser-based solution enables.