Your Meteor forum post from 18 months ago in this thread Use ES2015 or CoffeeScript?
that couldn’t express better how I feel about CoffeeScript, seem to suggest that you were at the time using Meteor with CoffeeScript for some serious business (presumably with Blaze).
Are you still using this stack today though?
If you do, do you debug your code using consol.log and debugger statements that you comment in and out? I for one find this is unautomated, pre-IDE era approach to debugging frustratingly unproductive.
Yet, I have tried both Webstorm and VSCode, and to my frustration I have discovered that:
the Webstorm Meteor debugger does not work properly with CoffeeScript (not stopping on breakpoints) and the numerous open issues filed concerning these bugs seem to receive zero attention from Webstorm support (not enough votes to be addressed I guess)
the VSCode node debugger and the VSCode chrome debugger, in addition to be very hard to configure, are not made to work together to debug Meteor code and they both suffer from the same kind of CoffeeScript+Meteor source map leveraging bugs than Webstorm, making breakpoints in CoffeeScript code unusables.
So, how does you and your team overcome this lack of functionning IDE to productively code in CoffeeScript with Meteor?
I code in Sublime Text, not an IDE. Most of the code I write is isomorphic, so I just set breakpoints in Chrome DevTools. The few purely server-only files in my projects I debug using either console.log, or if it requires a lot of debugging I attach the Node debugger (meteor debug, see http://joshowens.me/easily-debugging-meteor-js/). The coffeescript package in Meteor automatically generates source maps, and DevTools automatically loads them, so it all works fairly seamlessly.
How can the client-side UI code (server-specfiic initialization, template helpers, template event handlers) be isomorphic?
My understanding was that only persistant models (collections, schemas, triggers, etc.) code could be isomorphic (if by isomorphic you mean code that run both on the server and the client).
Do you set breakpoints in the Meteor transpiled and built web.browser/app/app.js file?
Or in the source CoffeeScript files?
This is surprising to me since the VSCode Chrome debugger is a connector to the between VSCode and the Chrome Dev Tools that rely on the latter to set breakpoints and stop at debugger statements but still misses some debugger statements and breakpoints set in the source CoffeeScript file as if it couldn’t always either finding the source maps, or correctly using them to identify the breakpoints in the CoffeeScript source code.
And Webstorm suffers from exactly the same issues, which do not get solved because the Meteor with CoffeeScript audience is at the intersection of two niches in the JS universe and hence gathers very little attention.
How can the client-side UI code (server-specfiic initialization, template helpers, template event handlers) be isomorphic?
Sorry, what I meant was, most of the code that runs on the server also runs on the client. All such code is easy to debug in DevTools, setting breakpoints in DevTools. The only annoying code to debug is the server-only code, which I either use console.log for or meteor debug (which is essentially DevTools for server-side code).
I generally set breakpoints by clicking in the gutter in DevTools. If I have trouble with that, which happens more often with server-side code, I just add a line in the code that says debugger and that sets a breakpoint.
There isn’t anything particular to CoffeeScript about any of this. The same issues arise with ES2015 code or TypeScript; any code that compiles to JavaScript, and hence uses source maps.
But isn’t the case that even if one chooses to avoid transpilers alltogether and program in ES5, the complex Meteor build will generate source maps anyway?
What I meant here was source maps relating the files and lines in the manually coded source files (ES5, ES6, CoffeeScript, TypeScript) to the corresponding lines in the Meteor build generated ES5 app.js files that get executed in node and the web browser.
Because if this is indeed the case, then any debugger unable to correctly handle breakpoints in source files by leveraging source maps will fail to provide adequate debugging support even if one opts to bite the bullet and code the source files in plain old vanilla ES5 instead of the more recent, concise, elegant or semantically safer alternatives.
I don’t know what you mean by a “debugger unable to correctly handle breakpoints in source files by leveraging source maps”. DevTools works well with source maps, and I haven’t had trouble setting breakpoints in it against my original Coffee code. You can’t always set a breakpoint on exactly the line you want, because your source doesn’t always correspond to the same number of lines as the generated JS; but in such cases you can always add the word debugger into your code on its own line and it will become the breakpoint. For me this happens rarely though.