6 ms·

Shouldn't debugging be something you opt-in to rather than opt-out of? Seems like a weird design choice

• rhinoceraptor 11y ago
  > Seems like a weird design choice Angular.js in a nutshell.
  • fenomas 11y ago
    Keep in mind Angular is a framework where, when you pass it a callback function, it will sometimes behave differently depending on what you named the function's parameters. @_@ (Or at least it used to when last I checked. It does it by calling toString on the function and parsing the result.)
    • throwanem 11y ago
      Only if you opt not to use strict dependency injection, and strict DI has been best practice for quite a while now.
    • RKoutnik 11y ago
      This is known as Dependency Injection and makes testing and codebase componentization a breeze. You may have seen it called "inversion of control" elsewhere. In essence, my components define what they need to run (through the function params) and Angular hands it to them. For instance: myApp.service('foo', function (bar, baz) { registers a service named `foo` that depends on the `bar` and `baz` components. My service doesn't need to know how/where bar & baz come from, it just knows that it'll have them at runtime. This isn't all callback functions (in fact, Angular is built on Promises, not callbacks) but rather functions when you register a new component. You can override what gets injected (say, mocking things out in tests). DI is a fantastic pattern that reduces or otherwise eliminates all sorts of snarls that can come up.
      • fenomas 11y ago
        Cheers for the explanation, but this isn't so much "DI", as "reflection for the sake of DI", right? I mean, libraries can have DI without being quite this magical. I say this naively as a non-user, but in my case this specifically is what made me decide not to use Angular. I was trying it out for a new project and running through tutorials, but when I realized it was being that clever behind the scenes I decided that learning all its quirks would take longer than the rest of the project, and switched to something way simpler.
        • voltagex_ 11y ago
          When I've implemented (toy) DI in C#, I've also used reflection. How else are you finding the types to load? (Happy to see examples in other languages, too)
        • RKoutnik 11y ago
          Sure, Angular has strict DI, which looks like this: myApp.service('foo', ['bar', 'baz', function (bar, baz) { Now it doesn't need to read the function params as it has the strict strings. This'll survive function param mangling (a typical minification step). Sorry to hear you felt you weren't up to learning Angular & DI patterns. It can be tough for some folks who are still learning programming & JavaScript in general, so there's no shame in passing. Maybe next time - challenge yourself!
          • fenomas 11y ago
            > Sorry to hear you felt you weren't up to learning Angular & DI patterns. It can be tough for some folks who are still learning programming & JavaScript in general I'm sure you don't mean that to sound condescending, but that's really not what I said. It was a question of magicalness vs. payoff - I needed a front-end framework that would handle a bunch of databinding and stay out of my way, and halfway into my first tutorial I found none of the sample code worked (either because I changed a local variable name or because my project already had minification set up, I don't recall). Either way the docs and tutorial I was using didn't even mention the function was being introspected, I had to go source-diving to find that out. It all worked out to make Angular feel less like a framework and more like a career choice - I couldn't just give it idiomatic javascript and expect things to work. If this introspection thing is the one and only magical part of Angular and I just happened to trip over it, maybe I got the wrong impression.
• MaulingMonkey 11y ago
  I'd be interested in how significant the actual performance hit is - I see no measurements. There are plenty of times you'd want to enable various debug features, even in production, even if it means leaving them always on. The only real question is if the tradeoffs are worth it - the performance hit, if any, and the security implications, if any, versus the productivity gains.
• mkolodny 11y ago
  Django has DEBUG set to True by default, too.
  • hiimnate 11y ago
    Yes, but it's a setting that you can see and are required to define, it's not a built-in constant that is True unless you define it to be False.
  • Lxr 11y ago
    They have a fairly obvious "SECURITY WARNING: don't run with debug turned on in production!" above it though.
• pbreit 11y ago
  Since performance rarely matters and debugging usually does, doesn't seem totally crazy.
• geofft 11y ago
  It's the same design choice as most C compilation toolchains: you get debug symbols during the compilation process, and you can strip the binaries later if you want.
  • joosters 11y ago
    It's a little different though, as debug symbols won't slow down the execution of a compiled program, they just take up space in the binary.
  • nothrabannosir 11y ago
    Really? Limited experience, but doesn't GCC require -g to enable debug symbols?
• joshschreuder 11y ago
  It wasn't an option before 1.3, so I imagine it was debug by default to avoid breaking sites in the wild (ours uses angular.element().scope() in some old code which breaks with debug info off)