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
agreed, part of what worries me is there seems to be an atmopshere of uncertainty sorrounding blaze and flow router. I think most people want to know now what direction things are going in regarding this so we can start thinking about a transition if necessary.
That said I really like blaze and have always used it. I don’t want to switch but react is also looking good in many ways.
1 Like
I’m using Webstorm for server-side breakpoints and Chrome debugger for client-side, and it works very well. However, I am using ES6 rather than CoffeeScript or TypeScript.
In my experience, Webstorm does care very much about their product. Have you filed bug reports regarding the issues you’ve experienced?
I’m a student and I frequently make demos of web app ideas and I don’t like paying real money to setup mongo hosting. If I could use MySQL for something simple and quick that would make it possible to get more demos online for someone like me.
You can also host MongoDB just as easily as MySQL.
1 Like
MLab has a free tier for MongoDB hosting.
1 Like
Yes I did, several of them: https://youtrack.jetbrains.com/issue/WEB-23837. At least 6 issues concerning Webstorm ignoring breakpoints or stopping at wrong locations in CoffeeScript source code are currently open, some since 2014 and they are just not solved because they do not receive enough votes.
It is my understanding that the CoffeeScript Atmosphere package geneates the CoffeeScript to ES5 source maps. Since the VSCode node debugger and VSCode chrome debugger also suffers from similar bugs (and for which I have also filed issues) I am not sure at this point whether the problem is generating the correct source maps in the complex context of the Meteor build, or whether it is Webstorm and VSCode that have trouble exploiting those source maps correctly. But they work for ES6, I do not see why they could not work for CoffeeScript.
Get something done like https://github.com/jcoreio/crater
I am waiting for a simple npm installable version which removes the long builds from isobuild and works well with webpack/react.
Is this to come in 1.5 ?
By JavaScript do you mean ES5 or ES6?
If it is ES5, then I guess that I misunderstood what you meant in your thread launching post:
What kind of source maps is Meteor not generating that prevents you to troubleshoot your app?
Those mapping the various imports/…/file.js into the two web.browser/app/app.js and server/app/app.js files generated by the build?
When creating your production bundle there is no way to generate a source map that can be uploaded to your error tracker and used to debug. It’s near impossible to determine the source of an error in production from the minified code.
3 Likes