The meteor group has $11 million dollars, that’s a lot of funding. Comparing to other frameworks in other languages (Django/Rails/Sails), schemas and ability to make some auto-forms for testing database entries are some of the most valuable time savers in building applications. I think that is a windfall of cash that the MDG received provides thousands and thousands of development hours and that’s a lot of time in engineering, this doesn’t seem to be some side project. By the way, I’d never pay to use a web-framework and there’s a lot of choice. So building something that has major movement in the development community is worth it, or it won’t gain the popularity to have the momentum a framework needs.
I assume MDG only wants Meteor to be a good as it can be. I just feel like in it’s current offering it seems like it’s 80% - and doesn’t feel quite production ready (or at least worthy enough to let my company put Meteor in production). I’ve been watching this project off and on for a year, and thought by now these problems I ran into would have been solved.
I had some real points and concerns, I think those areas are important points I raise:
- Poor package structure in filesystem (ex: lib client server) folders… (I don’t want all my code in every folder executed, it should be explicit not inferred)
- Loosey Goosey confusing variable scope (Class based objects why not?) why not support require AMD loading
- Admin should be built in out of the box
- Better watcher-reloader performance (I read that it’s coming)
- Better dependency management for packages with libraries that conflict with other packages.
I’m hoping they rebuild the entire template system to use React btw, or a fork of the meteor project exclusively for React. I think React is a great pattern for Meteor development. The templates that React uses, as good as they are, already feel old fashioned.
Wasn’t meteor co-founded by former facebook devs? How come some of these choices were made?