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.
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.
MLab has a free tier for MongoDB hosting.
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.
no problem in development; but once deployed the error logs on a production server are nearly worthless
Cordova in npm to not be tight to meteor version to update the cordova version.
It should be top of the list as it s a blocking point especially if meteor version are delivered at a different pace that now.
From my point of view it s not a nice to but a mandatory point, imagine if we get a meteror release each 6 month and suddenly a cordova version upgrade is really needed, how can it be possible to wait 6 month to have cordova updated ?
Another vote for sourcemaps! What happened? I upgraded from 1.2 to 1.4 and all package source maps are gone (we develop 90% of the app within packages). When I google for this, I only find old issues (or Chrome’s problem) regarding sourcemaps and no outcry of the new issue.
I’m glad someone else is noticing this. This makes one coworker doubt Meteor all together just because of this issue. I’m getting a lot of heat for upgrading to 1.4 all around. (Meteor Streams needed to be replaced with raix:eventddp. And now we have to run “meteor npm install” on every fresh instance as well.)
I agree with Sourcemaps, and it will be great to see Iron router back , seeing Blaze as a thin layer in front of React .
Iron router and blaze has their own strength, so many legacy apps and many small and rapid development apps could use them with no problem.
I’d like to see support for Service Workers in order to be able to build Progressive Web Apps (Push notifications, offline support, launch app from home screen, …) 
Since Blaze and FlowRouter are community packages, shouldn’t the burden be on the package maintainers to ensure that it continues to work with Meteor.
MDG should definitely be helpful and not make it difficult for the maintainers, but the majority of the burden shouldn’t be on them to keep these packages alive
Apparently there’s no reason why they should ever break, so I guess it’s a dead issue.
What you say is true for most packages; however, a router is a core feature for SPA apps. The only reason MDG didn’t make their own route package is because the community provided some. But if those packages become outdated and the community doesn’t step up, then it would be a suicide pill for MDG to not intervene.
My only concern about this is code privacy, everyone can then copy our code. Having uglified it, it makes it harder (not impossible) for hackers and competitors to make sense of it (unless they really really want to).
good point. What do other node.js frameworks do? like Express? Do they provide sourcemaps or is it kind of always obfuscated? Is there any framework where you could pass in some secret key, into the url or console, to trigger a debug-mode and get source maps for only your session?