In fairness those same users would also have said they wanted support for insert favorite DB without migrating to Apollo if you had given them that option.
Really I think how this conversation is framed has a huge impact on what people will say.
If you give me the choices of:
- You can have a much faster build tool with lazy loading that is used by the larger js ecosystem in a relatively short timeframe but you will have to migrate some code.
vs.
- You can have a somewhat faster meteor specific build tool possibly without lazy loading in a longer timeframe but you won’t have to migrate any code.
Despite having a production Meteor 1.3 app, I really think I would choose the first option for a number of reasons:
- I don’t believe that improving the existing build tool is in line with the refocused part of the MDG philosophy of working on things that have wide applicability
- As part of the above I think any improvements will be a stop gap rather than an attempt to make the build tool more widely adopted
- I believe that MDG could come up with a relatively easy migration path
- I think it would take less time for MDG to do it and maintain the ultimate solution, freeing them up to do other awesome things
- It’s something people in the Meteor community want - sure some would want it only if it comes with backward compatibility, but for many I don’t think that is true