Just received an survey from Meteor by email. The final question is: what would you like for us to work on next? I answered “Sourcemaps so we can troubleshoot our app”. Would love to see others suggest sourcemaps too. What do others here think is a higher priority?
8 Likes
I agree that troubleshooting/debugging can be a huge time sink right now. Perhaps I’ve got wish lists on the mind as we near the holidays, but I suggested a Meteor IDE =)
2 Likes
relational database support
5 Likes
More support on critical packages, router, templating, scalability via redis-oplog, and integration with something like deepstreem.io for more scalability.
I’m sensing very bad signals, MDG should think more on it’s strategy.
3 Likes
Code splitting would be nice 
11 Likes
Asking your users about their wants and needs is exactly what any company should be doing.
9 Likes
interesting answer! but why?
Apollo is the best solution for other dbs support
7 Likes
I would just want ability to specify entry-point for apps. This would make creating micro-services absolutely trivial, within the same REPO and without having to go towards packages.
meteor --entry="/imports/microservices/deep-mind"
// file /imports/microservices/deep-mind/index.js
Meteor.isServer && require('./startup/server.js')
I would also like even faster builds. If possible I simply want instantaneous, I think there is a way to do this by separating “lib code” packages, node_modules and “run code”. So each change would result in recompiling run-code. And simply refresh the page.
If we make changes in packages or something, then we may need a way to fallback to the original way of doing things.
meteor run --optimistic-watcher
Next, I would like for them to support an official server-side router and client-side router. That would be great for a framework.
17 Likes
I had done that too ! Along with a few other things.
ritual calling for code-splitting & salty crackers(aka grapher docs)
I would like to see a commitment by MDG that updates for the next year will be compatible with Blaze and FlowRouter (and if there are breaking changes, to provide help to update Blaze and FlowRouter).
For those of us using Blaze on legacy apps, and for those of us who believe that Blaze is sometimes preferable to React, it would be really nice for MDG to provide some assurance that these packages will continue to be usable.
14 Likes
A good testing framework.
4 Likes
Yes! And I’d like to extend this to all essential parts of the Meteor classic framework, including Cordova.
1 Like
BAH. I should have checked here before completing the survey. This IMO critical issue has been around so long I just don’t think about it anymore. I guess I’ve just gotten used to decipher this kind of obfuscated frontend code in Sentry.
2 Likes
Almost every single breaking change since Meteor 1.0 is a bug (except some issues with build plugins). The best thing you can do to ensure this keeps working is stay up to date with the newest versions, and test out the beta releases and file bugs when things stop working for you.
What format could this commitment be in? What’s the definition of “compatible”?
1 Like
Oh, sorry. In another thread, some folks are saying they are debating leaving Meteor because of insecurity regarding the core platform. Specifically, they worry that in the near future, a Meteor release will no longer support Blaze and/or FlowRouter (because MDG seems focussed on Apollo and React, and because Blaze/FlowRouter are community packages).
While I personally like that Meteor is evolving rapidly, I can understand how that can lead to worries about the future. So, to respond to your question, I think it would be helpful when you release your Meteor 2017 roadmap to provide some statement about MDG’s position with respect to Blaze (and by extension, FlowRouter) for 2017. It would be great to know that, at least for the next 12 months, there is a commitment to ensuring that developers currently using Blaze/FlowRouter will be able to use them with new releases.
And, as long as I’m rambling, I think there is a business case to be made that Blaze is a gateway drug to Meteor, and Meteor is a gateway drug to Apollo and Galaxy. I teach Meteor to 60 students a semester, and it’s much easier to get them started using Blaze for their first few projects. Once they are comfortable with the platform (and that includes deployment to Galaxy), they start getting more ambitious, and that’s when React starts looking interesting to them.
6 Likes
To me, there is no higher priority than an IDE that properly exploits source maps.
I already posted several times is various threads of this forum, that the missing productivity link in Meteor developement is an IDE with robust, genuinely working source maps for the most popular dialects (Spacebar, Jade/Pug, JSX, ES6, CoffeeScript, TypeScript, Less, Sass, Stylus) supporting putting breakpoints in source code and have the app reliably stop at them to inspect watch expression results (preferably written in the dialect used for the source code).
Right now:
- the Webstorm’s meteor support is buggy for many dialects (CoffeeScript and TypeScript at least) and does not support breakpoints in HTML generation templates (whether Spacebar or Jade/Pug);
- the VSCode node debugger and chrome debugger extensions are also buggy in terms of their handling breakpoints and source maps for Meteor apps, and they cannot easily be used in concert to debug the server-only, client-only and isomorphic code parts of a Meteor apps.
Because the Meteor community is such a small part of the larger JS community, Webstorm and VSCode developpers never prioritize Meteor support issues and missing features, so there is little hope to see them addressing these in the near future.
So our prospect seems to be one of these three possibilities:
-
some ninja team in shiny armour emerges by magic from the Meteor user community to provide a VSCode or a Webstorm extensions that really works;
-
MDG finally understands that IDE support is a key technology adoption factor, that it can be part of a sustainable business model (see JetBrains) and it is currently one of the weakest point of Meteor, and starts to allocate some of its resources to it;
-
we keep debugging our Meteor apps improductively, 80s style with console.log and debugger statements with the added confusion of having to do it in the Meteor builder generated code due to source maps not being properly exploited by an available IDE … until we get so frustrated by such improductivity that we abandon Meteor, trading off its otherwise wonderful goodies for genuinely productivity-boosting debugging tools.
I am ready to pay for a working Meteor IDE that provides robust, debugging support out-of-the-box of my source code, much like I am ready to pay for Meteor app out-of-the-box cloud hosting and devop automation.
2 Likes
Is that a Meteor problem or a problem with CoffeeScript and Typescript support in Webstorm and VS Code? I haven’t had a problem with Webstorm and Chrome breakpoints in JavaScript during development.
2 Likes