4 ms·

Anyone who has worked in real web development knows that source maps are barely functional. When they do work, they are slow and there's a non-trivial delay, du

Anyone who has worked in real web development knows that source maps are barely functional. When they do work, they are slow and there's a non-trivial delay, during which time the minified source or transpiled source or whatever is shown. There's a 50/50 shot they won't even work at all, and of that 50% of the time they do work, they often don't have the correct line and column. Again, things like the interactive debugger and "pause on caught exceptions" often casually break with source maps. In short, it's a mess.

foota 9y ago
Maybe it wasn't "real web development" but I've worked in projects with O(thousands of lines) of transpiled and minimized typescript where they worked fine.
- jondubois 9y ago
  I think that the issue is around creating and distributing source maps correctly and also about maintaining the correct configurations to match updates in the source language. I've worked on many projects for large companies and I have to agree with the previous commenter that it feels like source maps often don't work correctly. You can blame the bundling tools, you can blame the deployment process, you can blame the developers... But ultimately, source maps are not so straight forward and they slow things down because they add a lot of unnecessary complexity to the project. I don't think I've ever worked on a CoffeeScript or TypeScript project without encountering at least a few major recurring issues with the source maps. When you have many developers working on the same code, things will break in unexpected ways and so you want to minimize system complexity.
  - ehnto 9y ago
    Closely matching the experience I have with many support tools for development. Including things like docker, vagrant, dependency managers, build pipelines, CI, migration/setup scripts, compilation, codegen... My intuition is that while these all solve real problems, they are complex enough solutions that they themselves have problems over the course of time. Each tool and configuration of the tool individually understood by whoever put it into the project but never understood by all team members. Two things come out of this: when a tool breaks, it can't be fixed by everyone, and because it can't be fixed by everyone no one feels responsible and it stays broken or gets fixed ad hoc by each team member until a real fix is made by someone who can (doesn't always happen). By the time you are a few years into a project your tooling is a mess, people that built it have left, and dependencies and the ecosystem have well and truly moved on. I loved Vagrant, until it broke, on every single project I touched after it was initially implemented and in a myriad weird and wonderful ways. I know these are complex tools, but they often don't feel worth the trouble. They are not robust, they pass out of fashion quickly, and they are rarely effective enough for long enough to truly reap rewards (in my experience). I want these things to work. But they are broken and in the way so often that I prefer not to rely on them. If a builder had to open his magic drill and learn an unfamiliar skillset to fix it every few months he would probably go back to the regular drill that just worked.
- iaml 9y ago
  I also worked on a reasonably complex angular app that had sourcemaps generated through webpack, never had any problems with it.
- coldtea 9y ago
  Thousands of lines is barely enough to get the full pain, given that webapps can get to multiple tens of thousands to hundreds of thousands of lines. Not to mention several Chrome bugs about sourcemaps over the years.
  - AlphaWeaver 9y ago
    I've had no complaints about source maps in Firefox.
maaaats 9y ago
> Anyone who has worked in real web development knows (...) I've never encountered these problems, have I not done real web development?
- coldtea 9y ago
  Or you're one of the blissfully lucky outliers.
vog 9y ago
This is an interesting case for languages with strict type systems. Maybe you can get away without source maps and still not loosing much? Some time ago I took a look at various transpilers for ML-like languages: OCaml->JS, Elm->JS, Haskell->JS, etc. I worried about how good the source maps would be, because good source maps are non-trivial, and it is no fun to debug in a different language than your source. To my astonishment, those transpilers provide either rudimentary source maps, or no source maps at all! And I didn't find any significant push towards better source maps. I wondered how this is possible, given that the communities around ML-like languages place great emphasis on high-quality code with as few bugs as possible. Then I got it: This is just another instance of "If it compiles, it almost always works". Imagine client-side code where no type of server response can be ignored, no unexpected null or undefined can slip into your data structures, every function or method you call will 100% surely exist, and so on. Think of TypeScript or Flow, but on steroids. That's what these languages and their transpilers offer. Well, at least that's the theory. It would be interesting to have reports from people actualitty writing larger web applications that way, and in how far these promises hold.
- Drup 9y ago
  This is true as long as you stay in the language. When you start binding to JS libraries, all hell break loose and you have to track down undefined and nulls that slip into places they shouldn't, because most JS libraries are poorly written. I only have experience with js_of_ocaml, which has fairly good support for source maps .... after a painful setup phase. It does help a lot for bindings though.
  - vog 9y ago
    > js_of_ocaml, which has fairly good support for source maps Wow. That must have changed in the meantime. Bucklescript seems to be the way forward, and much better than js_of_ocaml. But that's hearsay. Anyone with actual experience in bucklescript? > you start binding to JS libraries, all hell break loose and you have to track down undefined and nulls that slip into places they shouldn't, because most JS libraries are poorly written If the interface to that JS library is not performance critical, couldn't you just setup a thin wrapper and communicate to the library via JSON structures? Then, your OCaml code could treat it like any other (potentially buggy) external source.
tomseldon 9y ago
I've had all of these problems where I've had to roll my own solution in some way. Whether that was trying to get source maps to work when compiling + minifying via Google Closure and Webpack, or using Babel and Webpack back when the underlying source map util (I forget the name) didn't support certain things and having to fudge it myself (I forget the specifics). They worked, but they were fairly brittle. Now, tooling seems to have been improved a lot and using things like `angular-cli` means I don't have to do any of the setup anymore and I haven't had these kinds of problems in a really long time. Ok, the delay from output to showing the source map is still an issue, but it's not one I find a problem. A few seconds after page load is acceptable to me before going digging through the source, and any breakpoints set in the source files continue to work. Overall, for me, the weak point wasn't the source maps themselves, but the idiot setting up the build tooling to make them possible (me). :)
iza 9y ago
In my experience this was true a few years ago but they work perfectly in current versions of Chrome.

foota 9y ago

Maybe it wasn't "real web development" but I've worked in projects with O(thousands of lines) of transpiled and minimized typescript where they worked fine.

jondubois 9y ago
I think that the issue is around creating and distributing source maps correctly and also about maintaining the correct configurations to match updates in the source language. I've worked on many projects for large companies and I have to agree with the previous commenter that it feels like source maps often don't work correctly. You can blame the bundling tools, you can blame the deployment process, you can blame the developers... But ultimately, source maps are not so straight forward and they slow things down because they add a lot of unnecessary complexity to the project. I don't think I've ever worked on a CoffeeScript or TypeScript project without encountering at least a few major recurring issues with the source maps. When you have many developers working on the same code, things will break in unexpected ways and so you want to minimize system complexity.
- ehnto 9y ago
  Closely matching the experience I have with many support tools for development. Including things like docker, vagrant, dependency managers, build pipelines, CI, migration/setup scripts, compilation, codegen... My intuition is that while these all solve real problems, they are complex enough solutions that they themselves have problems over the course of time. Each tool and configuration of the tool individually understood by whoever put it into the project but never understood by all team members. Two things come out of this: when a tool breaks, it can't be fixed by everyone, and because it can't be fixed by everyone no one feels responsible and it stays broken or gets fixed ad hoc by each team member until a real fix is made by someone who can (doesn't always happen). By the time you are a few years into a project your tooling is a mess, people that built it have left, and dependencies and the ecosystem have well and truly moved on. I loved Vagrant, until it broke, on every single project I touched after it was initially implemented and in a myriad weird and wonderful ways. I know these are complex tools, but they often don't feel worth the trouble. They are not robust, they pass out of fashion quickly, and they are rarely effective enough for long enough to truly reap rewards (in my experience). I want these things to work. But they are broken and in the way so often that I prefer not to rely on them. If a builder had to open his magic drill and learn an unfamiliar skillset to fix it every few months he would probably go back to the regular drill that just worked.
iaml 9y ago
I also worked on a reasonably complex angular app that had sourcemaps generated through webpack, never had any problems with it.
coldtea 9y ago
Thousands of lines is barely enough to get the full pain, given that webapps can get to multiple tens of thousands to hundreds of thousands of lines. Not to mention several Chrome bugs about sourcemaps over the years.
- AlphaWeaver 9y ago
  I've had no complaints about source maps in Firefox.

maaaats 9y ago

> Anyone who has worked in real web development knows (...) I've never encountered these problems, have I not done real web development?

coldtea 9y ago
Or you're one of the blissfully lucky outliers.

vog 9y ago

This is an interesting case for languages with strict type systems. Maybe you can get away without source maps and still not loosing much? Some time ago I took a look at various transpilers for ML-like languages: OCaml->JS, Elm->JS, Haskell->JS, etc. I worried about how good the source maps would be, because good source maps are non-trivial, and it is no fun to debug in a different language than your source. To my astonishment, those transpilers provide either rudimentary source maps, or no source maps at all! And I didn't find any significant push towards better source maps. I wondered how this is possible, given that the communities around ML-like languages place great emphasis on high-quality code with as few bugs as possible. Then I got it: This is just another instance of "If it compiles, it almost always works". Imagine client-side code where no type of server response can be ignored, no unexpected null or undefined can slip into your data structures, every function or method you call will 100% surely exist, and so on. Think of TypeScript or Flow, but on steroids. That's what these languages and their transpilers offer. Well, at least that's the theory. It would be interesting to have reports from people actualitty writing larger web applications that way, and in how far these promises hold.

Drup 9y ago
This is true as long as you stay in the language. When you start binding to JS libraries, all hell break loose and you have to track down undefined and nulls that slip into places they shouldn't, because most JS libraries are poorly written. I only have experience with js_of_ocaml, which has fairly good support for source maps .... after a painful setup phase. It does help a lot for bindings though.
- vog 9y ago
  > js_of_ocaml, which has fairly good support for source maps Wow. That must have changed in the meantime. Bucklescript seems to be the way forward, and much better than js_of_ocaml. But that's hearsay. Anyone with actual experience in bucklescript? > you start binding to JS libraries, all hell break loose and you have to track down undefined and nulls that slip into places they shouldn't, because most JS libraries are poorly written If the interface to that JS library is not performance critical, couldn't you just setup a thin wrapper and communicate to the library via JSON structures? Then, your OCaml code could treat it like any other (potentially buggy) external source.

tomseldon 9y ago

I've had all of these problems where I've had to roll my own solution in some way. Whether that was trying to get source maps to work when compiling + minifying via Google Closure and Webpack, or using Babel and Webpack back when the underlying source map util (I forget the name) didn't support certain things and having to fudge it myself (I forget the specifics). They worked, but they were fairly brittle. Now, tooling seems to have been improved a lot and using things like `angular-cli` means I don't have to do any of the setup anymore and I haven't had these kinds of problems in a really long time. Ok, the delay from output to showing the source map is still an issue, but it's not one I find a problem. A few seconds after page load is acceptable to me before going digging through the source, and any breakpoints set in the source files continue to work. Overall, for me, the weak point wasn't the source maps themselves, but the idiot setting up the build tooling to make them possible (me). :)

iza 9y ago

In my experience this was true a few years ago but they work perfectly in current versions of Chrome.