4 ms·

Not to mention his example is just straight wrong about $scope and ng-if. His JSFiddle examples are all using angular 1.1.5. Angular 1.2 properly binds scope i

by fein 11y ago

Not to mention his example is just straight wrong about $scope and ng-if. His JSFiddle examples are all using angular 1.1.5. Angular 1.2 properly binds scope inside an ng-if. I agree that angular 1.1.5 had it's warts, if that's what this is supposed to be about. The current release version of angular is 1.4, about to be 1.5. Edit: After fully reading through this blog post; it's almost all wrong. Dirty Checking: Yes, we have have to sacrifice ease of use for performance sometimes. So keep it in mind and don't make so many simultaneous data bindings. Why you would need 2000+ in any given state(ui-router)/route is just mystifying. Don't abuse ng-model. Dependency Injection: Are you kidding me? He's not even using the array notation for proper DI with minification. Pointless Complexity: This is an actual valid argument, and the only one on the blog. Google has some pretty bad documents for angular, especially when describing directives that isolate scope. Server Side Rendering: Uh, the whole idea behind stuff like angular is decoupled frontends from your server. Build a REST API and point angular at it; no need to ship layout code with services. Angular 2: There's an upgrade path that should allow the two to exist in tandem. There's no reason to not keep writing angular 1.x code right now. It's not like Angular 2 being released means all your previous code is worthless.

jksmith 11y ago
+1 on just saying no to server side rendering. This should be idiomatic.
- strickjb9 11y ago
  There are tradeoffs to both. Server-side will always have a seat at the table. Ex - populating a simple key-value select statement will always perform better using server-side.
  - jksmith 11y ago
    There are functional reasons, yes. But the best business case for internet dev is a frontend hits a backend, and that's it. The relationship is purely request/response payloads. It's transactional, massively simplifies development and qa, and better encourages the notion that every endpoint should be able to provide, as well as consume services.
DougWebb 11y ago
Dirty Checking: Yes, we have have to sacrifice ease of use for performance sometimes. So keep it in mind and don't make so many simultaneous data bindings. Why you would need 2000+ in any given state(ui-router)/route is just mystifying. Don't abuse ng-model. As someone who's going to need to make a recommendation soon about whether or not to use Angular on a new project, this part worries me. The apps my company builds are full of data grids (Enterprise CRUD-based stuff) and it's entirely reasonable for us to have a 100-row grid with 20 columns as just one of the components on our page. So that's 2000 data bindings right there just for the data values. We'd also have metadata on every cell bound to classes and validation state. If we allow in-place editing, a single one of those fields can be updated. We can't have the entire grid re-checked after every update if that's going to hit the limit on acceptable performance. We'd need to limit it to the row (eg: cross-field validation rules) and elements outside the grid (eg: change toolbar button states.) Does Angular 2 have similar limitations? Should we wait for Angular 3 and Object.Observe?
- fein 11y ago
  Might be a nasty pill to swallow, but in most cases, populating a grid with 2000+ bindings is in the area I'd call bad UI. However, I don't think that the performance hit you would take would be that noticeable depending on the implementation. Here's a jsperf test that can demonstrate angular performance with 10k watchers: http://jsperf.com/angularjs-digest/72 http://jsperf.com/angularjs-digest/72 Chrome 45 gave me about 3.2k ops/sec
  - DougWebb 11y ago
    Might be a nasty pill to swallow, but in most cases, populating a grid with 2000+ bindings is in the area I'd call bad UI. Totally agree, but my business is auto-generating fully-featured applications based on database schema inspection and a code-generation wizard, for clients with large enterprise databases. So the app has to work reasonably well with out-of-the-box generation before we start tweaking it to customize and improve the UI for the most important tables and most common workflows. Thanks for the jsperf test. It's good to know the range of results for different browsers. Our app needs to run on everything, including Mobile browsers, and that test proves that we can't get away with using the typical Bootstrap responsive "hide some columns for xs" approach. We need to not generate markup for most of the columns at all. That means we're going to have to enhance our generation wizard to let us specify, per-table, device-size-specific column lists instead of just a single column list.
elros 11y ago
>Server Side Rendering: Uh, the whole idea behind stuff like angular is decoupled frontends from your server. Build a REST API and point angular at it; no need to ship layout code with services. This is not a solution because the lack of content from the perspective of UAs that don't process JS (such as some web crawlers) decreases search ranking. The alternative solution for the architecture you propose (0 rendering on the server) is to add a prerendering server between the Internet and your system. With JS frameworks that do not depend on the DOM, one can have isomorphic JS that runs in both the browser and node. This means the same code can run on the server, for the first request, and after the rendered code is sent down the pipe further requests use the API. Sending acontent-less HTML with proceeds to fetch something from some API is a non-answer for websites whose search ranking is relevant. If I had to chose between isomorphic JavaScript + server-side prerendering OR having an extra layer between my frontend server and the Internet, I rather the former – assuming there are no other language/technology requirements.
- fein 11y ago
  So code your public facing pages with static html and reserve angular for the app? The public pages I build for my apps are all static html with some JS for flashy crap that people ask for. Search engines don't need to care about the app itself, just the front page, about page, contact, etc, of the biz. Unless you're talking about a CMS built in Angular, which can get sketchy. Google's web crawler parses JS now anyway, so it shouldn't be a huge problem.
  - elros 11y ago
    Well, you're assuming the content does not live inside the app. In my situation, and in many others, it does.
bphogan 11y ago
> Dependency Injection: Are you kidding me? He's not even using the array notation for proper DI with minification. Can I just say that this is the single thing that really irritates me about Angular? This has been the "gotcha" forever... why are all the guides not using this syntax by default? Why is this just not "the way you do things" if everyone knows this is a problem?
- joeyrobert 11y ago
  The array notation can be automatically added to your build tool (gulp, grunt) using ngAnnotate: https://github.com/olov/ng-annotate https://github.com/olov/ng-annotate. This reduces the amount of duplication and Angular boilerplate around dependency injection. Most Angular projects I've worked on use this, making the Angular guides relevant.
squeaky-clean 11y ago
Seriously, 3 different ways to fix their "Problem #1" 1) Define $scope.obj in the controller, instead of letting ng-model create it for you. [0] 2) Bind to $parent.obj in the inner scope (not necessary in later versions of angular) [0] 3) Upgrade to a modern version of Angular. [0] https://jsfiddle.net/e924n237/ https://jsfiddle.net/e924n237/

by fein 11y ago

jksmith 11y ago

+1 on just saying no to server side rendering. This should be idiomatic.

strickjb9 11y ago
There are tradeoffs to both. Server-side will always have a seat at the table. Ex - populating a simple key-value select statement will always perform better using server-side.
- jksmith 11y ago
  There are functional reasons, yes. But the best business case for internet dev is a frontend hits a backend, and that's it. The relationship is purely request/response payloads. It's transactional, massively simplifies development and qa, and better encourages the notion that every endpoint should be able to provide, as well as consume services.

DougWebb 11y ago

Dirty Checking: Yes, we have have to sacrifice ease of use for performance sometimes. So keep it in mind and don't make so many simultaneous data bindings. Why you would need 2000+ in any given state(ui-router)/route is just mystifying. Don't abuse ng-model. As someone who's going to need to make a recommendation soon about whether or not to use Angular on a new project, this part worries me. The apps my company builds are full of data grids (Enterprise CRUD-based stuff) and it's entirely reasonable for us to have a 100-row grid with 20 columns as just one of the components on our page. So that's 2000 data bindings right there just for the data values. We'd also have metadata on every cell bound to classes and validation state. If we allow in-place editing, a single one of those fields can be updated. We can't have the entire grid re-checked after every update if that's going to hit the limit on acceptable performance. We'd need to limit it to the row (eg: cross-field validation rules) and elements outside the grid (eg: change toolbar button states.) Does Angular 2 have similar limitations? Should we wait for Angular 3 and Object.Observe?

fein 11y ago
Might be a nasty pill to swallow, but in most cases, populating a grid with 2000+ bindings is in the area I'd call bad UI. However, I don't think that the performance hit you would take would be that noticeable depending on the implementation. Here's a jsperf test that can demonstrate angular performance with 10k watchers: http://jsperf.com/angularjs-digest/72 http://jsperf.com/angularjs-digest/72 Chrome 45 gave me about 3.2k ops/sec
- DougWebb 11y ago
  Might be a nasty pill to swallow, but in most cases, populating a grid with 2000+ bindings is in the area I'd call bad UI. Totally agree, but my business is auto-generating fully-featured applications based on database schema inspection and a code-generation wizard, for clients with large enterprise databases. So the app has to work reasonably well with out-of-the-box generation before we start tweaking it to customize and improve the UI for the most important tables and most common workflows. Thanks for the jsperf test. It's good to know the range of results for different browsers. Our app needs to run on everything, including Mobile browsers, and that test proves that we can't get away with using the typical Bootstrap responsive "hide some columns for xs" approach. We need to not generate markup for most of the columns at all. That means we're going to have to enhance our generation wizard to let us specify, per-table, device-size-specific column lists instead of just a single column list.

elros 11y ago

>Server Side Rendering: Uh, the whole idea behind stuff like angular is decoupled frontends from your server. Build a REST API and point angular at it; no need to ship layout code with services. This is not a solution because the lack of content from the perspective of UAs that don't process JS (such as some web crawlers) decreases search ranking. The alternative solution for the architecture you propose (0 rendering on the server) is to add a prerendering server between the Internet and your system. With JS frameworks that do not depend on the DOM, one can have isomorphic JS that runs in both the browser and node. This means the same code can run on the server, for the first request, and after the rendered code is sent down the pipe further requests use the API. Sending acontent-less HTML with proceeds to fetch something from some API is a non-answer for websites whose search ranking is relevant. If I had to chose between isomorphic JavaScript + server-side prerendering OR having an extra layer between my frontend server and the Internet, I rather the former – assuming there are no other language/technology requirements.

fein 11y ago
So code your public facing pages with static html and reserve angular for the app? The public pages I build for my apps are all static html with some JS for flashy crap that people ask for. Search engines don't need to care about the app itself, just the front page, about page, contact, etc, of the biz. Unless you're talking about a CMS built in Angular, which can get sketchy. Google's web crawler parses JS now anyway, so it shouldn't be a huge problem.
- elros 11y ago
  Well, you're assuming the content does not live inside the app. In my situation, and in many others, it does.

bphogan 11y ago

> Dependency Injection: Are you kidding me? He's not even using the array notation for proper DI with minification. Can I just say that this is the single thing that really irritates me about Angular? This has been the "gotcha" forever... why are all the guides not using this syntax by default? Why is this just not "the way you do things" if everyone knows this is a problem?

joeyrobert 11y ago
The array notation can be automatically added to your build tool (gulp, grunt) using ngAnnotate: https://github.com/olov/ng-annotate https://github.com/olov/ng-annotate. This reduces the amount of duplication and Angular boilerplate around dependency injection. Most Angular projects I've worked on use this, making the Angular guides relevant.

squeaky-clean 11y ago

Seriously, 3 different ways to fix their "Problem #1" 1) Define $scope.obj in the controller, instead of letting ng-model create it for you. [0] 2) Bind to $parent.obj in the inner scope (not necessary in later versions of angular) [0] 3) Upgrade to a modern version of Angular. [0] https://jsfiddle.net/e924n237/ https://jsfiddle.net/e924n237/