It should be their goal if they wish to be a commercially viable company. I worked as a developer in IBM Global Services in my previous full-time job, and worked on big projects for corporate clients. The clients are willing to pay top rates for quality (including labor), and project budgets are often into the multi millions.
Now that I’ve immersed myself into the Meteor world, I see huge disparities that need to be addressed. More people from the corporate world are going to discover Meteor as it continues to increase in popularity, so MDG need to work on marketing Meteor as a serious and robust platform that meets their needs and expectations, instead of remaining to be perceived only as a frivolous play toy for programmer nerds to tinker with.
Some of the concerns that I have had are:
Low attention to security. It’s not entirely MDG’s fault, it just seems that the general community, including package developers, don’t care much. Would that statement apply to the open-source developer community in general? I’ve come across many code examples that would open up security vulnerabilities in an app. Maybe most people are just developing apps in which there’s nothing for a hacker to gain financially, e.g. posts and comments apps. If that’s the case, it may have become a chicken-and-egg situation - If most people are developing posts and comments apps then development of Meteor security becomes low priority because the demand for security is low amongst most developers; on the other end, people who need to develop a highly secure app that involves e-commerce / monetary transactions may perceive Meteor as a low-security framework / platform because of the lack of attention to security (or they sense that most Meteor apps are frivolous “play” apps), and therefore choose not to use Meteor.
The security section in the Meteor Guide, and introduction of ValidatedMethod are good steps, but more needs to be done. MDG should take the lead in raising the level of security consciousness in the community and industry, up to the point at which they can market Meteor as a high-security framework / platform. The notion that Meteor is not appropriate for apps that require high security should be turned around 180 degrees. Offering high security out-of-the-box (or at least making it very easy to configure (like how they’ve made real-time data over the web easy)) will definitely increase uptake across all sectors, including corporate.
ACID transactions are not possible with MongoDB. i.e. there’s no commit / rollback functionality. The can lead to data inconsistency when two or more collections are meant to be updated at once but one update fails. MDG / Meteor has not offered any official solution at the application level. There is the meteor-transactions package by babrahams that looks like the best solution, but even he warns “do not use it to write banking applications or anything like that. Seriously, don’t.” What we would rather see is a solution that can confidently proclaim to solve the lack of ACID transaction support in the data layer. MemDB for Node.js looks great, but I’m not sure how to set it up with Meteor. This really needs to be solved.
Imprecise financial calculations. This is not MDG’s fault but JavaScript’s. For precise calculations, Java offers
BigDecimal. .NET offers decimal, and even explicitly proclaim in their reference documentation that it is “appropriate for financial and monetary calculations”. JavaScript only offers a floating point. If you type 0.1 + 0.2 in your browser console the result is 0.30000000000000004. Some people might say “just round the result off to 2 decimal places”. But that’s not a comprehensive solution. Type 0.1 + 0.2 === 0.3 in your browser console to see what you get. Most people would expect to see the result true at first glance, but it’s false. This makes comparing monetary values in JavaScript potentially troublesome.
There are some Node packages for precise financial calculations, however many assume that you are only working with 2 decimal place numbers and simply multiply or divide the number by 100 to calculate using integers, so they are not appropriate for doing calculations with numbers that may have variable decimal places (e.g. currency exchange rates - EUR/USD may have 4 or 5 decimal places, USD/JPY may have 2 or 3 decimal places). I’ve been using bignumber.js, and it does the job very well, but it doesn’t work frictionlessly with other packages, mainly because JavaScript is not strongly typed. I’m still trying to work out the best solution.
What is good is that IBM has been taking notice of Meteor and some IBM employees have spent time trying it out and have written technical articles about it. Searching for “Meteor” in the Bluemix Developers Community brings up quite a few Meteor-related pages. e.g.:
Tips for running Meteor.js on Bluemix. A notable quote: “we’ve also seen an uptick in the number of clients interested in Meteor”
Deploying your Meteor app to Cloud Foundry and Bluemix
Instant web applications with Meteor
IBM developerWorks MeteorJS community
This is evidence that IBM are definitely interested in and are keeping watch of Meteor.
I had a thought that IBM could simply acquire MDG and Meteor (as they’ve done with many other companies whose technology they’ve been interested in), and wondered whether that would be good for Meteor. Maybe more resources could be assigned to Meteor development in order to make the necessary improvements for it to fit comfortably in the corporate world. IBM already owns Compose.io DB hosting and SoftLayer cloud hosting infrastructure, so basically they could own all technology required for a Meteor app, which would make it easier to ensure that all components of the stack work seamlessly with each other.
Anyway, MDG should consider engaging in frequent communication with the Meteor enthusiasts at IBM to gain deeper insights into the needs of corporate clients and work towards catering for them.
