Comment by skrebbel | Hacker News Reader

Comment by skrebbel | Hacker News Reader

Parent Full thread

I really like opinionated books like these.

I've a question for HN on one of the opinions in this book: "use Browserify". There is only 1 single reason I don't currently use Browserify for client-side web apps: debugging. If Browserify turns all my files into one big file, all the time, and that's the only way, then how am I going to debug without going insane?

I know about source maps, but I use many compile-to-JS languages (TypeScript and React's JSX, in my case), and they provide source maps already. Afaik, Browserify doesn't re-map those source maps, or something like that.

Can I conclude that people who use Browserify simply never use compile-to-JS languages? Am I really forced to choose one of:

    * Avoid Browserify (and similar tools)
    * Write only vanilla JS
    * Deal with having to in-browser-debug a single 20000 line JS file
    * Finally spend time to contribute source map remapping to Browserify

Any ideas? Am I missing something awesome?

Browserify's --debug flag sets up source maps per-file and works just fine for me with transpiled CoffeeScript files (mapping to the original .coffee)

I'm not sure if there's something different about TS and React but I'd imagine if they have source map support it should work similarly?

You can't use the default transpilers. If you do, browserify can't really follow the source maps. But you're not alone!

For React JSX, you can use the browserify transform reactify. For typescript, you can use typescriptify. They should be right there in npm :)

If you're using karma as a testrunner though, I highly s suggest karma-browserifast over karma-browserify. It's orders of magnitude faster, and supports the latest jasmine and karma (the former does not). The former runs in O(n!) where n is the number of spec files. Yikes!

Browserify has had source maps since v2: http://thlorenz.com/blog/browserify-sourcemaps

Just pass {debug: true} to build function.

This probably only works if you're using a transpiler transform in the browserify pipeline. (instead of running browserify on an already-transpiled codebase)

Oh, got it. I misread the original comment.

No worries :)

I like that you're focusing so heavily on commonjs+browserify. We've made the switch for new projects as well. I'm curious as to why you advocate wildemitter over browserify's client side port of EventEmitter? Is it a lot lighter?

I use Browserify with Coffeescript modules, and the source maps work great. I'm using Coffeeify to do it: https://github.com/jnordberg/coffeeify

Browserify manages to remap our source maps... but we're using coffeeify to do that

Reply on news.ycombinator.com