Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Improving Angular performance with 1 line of code

medium.com

Post reply on HN
Print view View original

61–70 of 118 posts

Re: Improving Angular performance with 1 line of code

#61

Post by z4chj »

jholman wrote: post #59
PJDK wrote: post #56

Earlier quoted context omitted.

Interesting to note that generally even quite nice sets of draws have cheap wood at the back...

Yeah, what kind of asshole carpenter wastes his customer's money by inflating materials costs for no reason?

The same kind that was the CEO of one of the most successful companies in the history of the world.

Steve Jobs may have missed the mark on some of his products during his long tenure at Apple, but his focus on quality in every possible area of what he had a part in creating has paid its benefits

Re: Improving Angular performance with 1 line of code

#63

Post by fenomas »

rhinoceraptor wrote: post #3
Zekio wrote: post #2

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

> Seems like a weird design choice Angular.js in a nutshell.

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.)

Re: Improving Angular performance with 1 line of code

#65

Post by throwanem »

fenomas wrote: post #63
rhinoceraptor wrote: post #3

Earlier quoted context omitted.

> Seems like a weird design choice Angular.js in a nutshell.

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.)

Only if you opt not to use strict dependency injection, and strict DI has been best practice for quite a while now.

Re: Improving Angular performance with 1 line of code

#67

Post by justinsaccount »

I see this more as a tooling failure. All the yeoman/grunt/gulp/webpack/boilerplate/starterkit BS that you need to do to get a minified/concatenated/compressed build deployed and none of that turns this option off?

The only way I was ever able to get an angular project built/tested/deployed was by using something like yeoman. It's kind of shocking that the default project templates set up everything that you need except for this one thing.

I do notice that the made with angular site isn't even minifying their code:

https://www.madewithangular.com/static/js/main.js

Though that may be intentional so that people can see how it is written.

Re: Improving Angular performance with 1 line of code

#68

Post by RKoutnik »

fenomas wrote: post #63
rhinoceraptor wrote: post #3

Earlier quoted context omitted.

> Seems like a weird design choice Angular.js in a nutshell.

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.)

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.

Re: Improving Angular performance with 1 line of code

#69

Post by BinaryIdiot »

blinkingled wrote: post #62

This is a case of bad defaults - why should a developer be required to write code, even if it is a one liner, to _disable_ debug? It should be the other way around - you write a single liner to enable debug.

Correct. Debug options should never be a default. They should be enabled explicitly through the act of debugging (perhaps a flag somewhere in your web app, etc). I'm guessing it is the way it is for simplicity so someone can debug without trying to figure any of this out.
Post reply on HN