Comment by fein | Hacker News Reader

Comment by fein | Hacker News Reader

Parent Full thread

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.

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?

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

Chrome 45 gave me about 3.2k ops/sec

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.

You might consider using mithril.js: https://lhorie.github.io/mithril/benchmarks.html http://matt-esch.github.io/mercury-perf/

Use something like UI Grid for Angular to create a table in a way that avoids excessive watchers:

"Performs well with large data sets; even 10,000+ rows"

http://ui-grid.info/

In addition to what others have said:

If the individual cells in your grid aren't changing dynamically, you can use a one-time-binding[1] which will improve performance by removing the watchers after the expression is populated.

You can also always use a directive to do the DOM management yourself, and still use Angular-y templating in the rest of your app.

[1] https://code.angularjs.org/1.4.6/docs/guide/expression#one-t...

React + Redux: https://github.com/rackt/redux

You will not regret it.

knockout.js doesn't do everything Angular does, but it does two-way binding incredibly well. Very efficient with binding and rendering, so you don't need to be concerned with total data binding count.

I'd argue that KO's rendering isn't actually all that efficient - I use it daily on our core product and have been won over by React's crazy pseudo-DOM diffing voodoo.

keep in mind that even if you go with angular you don't need to use it in 100% of your site. Need to display a grid of data fast? Use any grid. There are lots of fast grids out there. Angular 2 eliminates dirty checking (last I've read) so it could be good enough, or maybe there will be something faster on the market that works best in your situation. There is no reason to assume that once you go with Angular you are now limited by 2000 watchers. you don't have to choose between Angular vs React vs Ember for that a single specific case (unless maybe one big mega grid is the bulk of your app). It is far more important to decide which architecture works best for your needs/team and how it will fit with all the other decisions you've made in your application stack.

> 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?

The array notation can be automatically added to your build tool (gulp, grunt) using ngAnnotate: 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.

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/

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

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.

Well, you're assuming the content does not live inside the app. In my situation, and in many others, it does.

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

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.

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.

Reply on news.ycombinator.com