These bring up the concerns below;
- Node’s platform support is critically limited to V8
- Unknown roadmap of when V8′s ABI will break (means a major release for Node)
- Fewer number of ES6 features supported in the latest V8 compared to SpiderMonkey
- How a design change in V8 may affect Node
Risk of Depending on a Single JS Engine
V8 engine is the heart of Node.JS. Each time Google releases a new version of V8 with API changes, Node’s native modules break. The main reason Google develops V8 engine is to power its Chrome browser. So Google has no reason to maintain compatibility for Node or any other applications using V8. Google’s priorities lies in the browser market. Hence, it has every reason to keep updating V8 for improving the performance and capabilities of Chrome exclusively.
Why Multiple Engine Support Matters?
JXcore and Its Multi-Engine Abstraction
JXcore is also an open source project with MIT license. We are committed to keeping up with updates in the Node project to maintain compatibility. We are also committed to contributing relevant changes upstream to Node. The abstraction layer in JXcore is designed to handle compatibility with Node in the long run. There is a lot of work to be done. Most native modules don’t yet work with SpiderMonkey due to API differences. Those modules need to be updated to work with JXcore. But once they work with JXcore, they will be isolated from any future changes in JS engines.
JXcore’s gaining popularity among mobile developers is already expanding Node ecosystem to a range of applications that could never be handled with Node. Considering the importance of mobility in the enterprise, keeping the whole development within the ecosystem instead of pushing developers to other platforms for mobile apps will only improve the long-term popularity of the whole Node ecosystem.
Read other posts: