Live data from Hacker News

2 years with Angular

fse.guru

171–180 of 216 posts

Re: 2 years with Angular

#171

Maybe I'm old fashioned but Angular just does too much for me. In fact many frontend frameworks simply do too much for me. I like to structure my web applications in a very minimal way. I like having one layer that covers the UI display and UI events. This layer does nothing beyond styling, setting up the UI and using messages to pass back events in a generic way. My business logic handles generic events. So say I ha…

Question: I also like a minimally structured app. I've experimented with Backbone.js. Have you tried it? Did you decide to go with msngr.js after using Backbone?

I feel like I spend a lot of time trying frameworks, only to find very little benefit. Happy to learn more, but would love to have some basis of comparison to some tech I've worked with to date.

Re: 2 years with Angular

#172
post #120

I think people are failing to see that not all apps are huge monolithic applications; for most of those apps Angular works just fine. In fact we should be striving to get away from all of those monolithic code bases as much as we can. In the cases where we can't get away from that then we should be going with tried and trusted methods of building those apps and probably relying on the server a hell of a lot more for…

Cordova has nothing to do with angular. Why do you bring it up? In fact, angular is probably one of the worst possible frameworks to wrap into a mobile app, because of its abysmal performance.[1]

[1] http://matt-esch.github.io/mercury-perf/

Re: 2 years with Angular

#173
post #10
post #2

I confess I am an Angular fan. But this article is not Angular specific at all, it stays on a very high-level. Replace the word Angular with any other web framework and the article would still make perfect sense. Not that the article does not have some value, just that it has very little to do with its title.

Same opinion here. I think angular hit an inflection point on the js frameworks, proof is the rapid growth that angular had. Granted, there's some bad parts but I would say it's mostly leaky abstractions; I'm wondering how angular2 will be, but I surely don't understand why all the hate around angular. It seems that the poster got bitten by some problems and blames it on angular. I recommend an exercise to current an…

None of the stuff that angular actually does is hard, and it is done by a lot of other frameworks. 90% of the effort spent learning angular is spent on its bizarre api.

Re: 2 years with Angular

#174
All of the frameworks suffer from performance issues. Performance will get better, but we will always have to profile our applications. A slow web component used in a ng-repeat scenario will always bring the application down to its knees. We can't just design a spaceship and expect an engineer to build a performant application. Designs need boundaries and guides as performance is one if not the most important factor of the UX. We also cannot reason with the jQuery spaghetti demon. Practice some Feng Shui, write better code. Understand whats going on in your framework. Work through the limitations with your designers. We are at the mercy of limited computation until our browsers give us more, and there is no magic bullet.

Re: 2 years with Angular

#175
post #151
post #147

Earlier quoted context omitted.

My team is using Angular for an app that contains large tabular data all over the place. We ended up having to rewrite the table generation in jQuery and now we've got a POC in development using React. Most other places we've had to use shims like angular-once to make menus performant. At this point we're building work-arounds for most of the things that makes Angular special.

> has perf issues with angularjs > writes a solution using jQuery Angular tries to be clever and solve loads of problems, sure tables and table rendering sucks anyways, but a simple querySelector with jQuery is 98% slower than just using normal DOM methods. If you're gonna write your own bits of code to improve the caveats of any framework, especially in the financial industry, you go full hog and you write it proper…

a simple querySelector with jQuery is 98% slower than just using normal DOM methods.

A simple querySelector with jQuery maps directly to a normal DOM method in browsers that support it.

Re: 2 years with Angular

#176
post #147

Earlier quoted context omitted.

I knew someone who consulted a large bank not to use Angular for financial apps. They were insistent to use Angular until he finally showed them a fairly typical requirement of an app like that in angular: 5 tables with 100 rows and columns. It literally crawled when running on a Dell Workstation laptop. It is kind of nuts that angular is big.

My team is using Angular for an app that contains large tabular data all over the place. We ended up having to rewrite the table generation in jQuery and now we've got a POC in development using React. Most other places we've had to use shims like angular-once to make menus performant. At this point we're building work-arounds for most of the things that makes Angular special.

Yeah, that's the final irony of all this. They get you hooked on the cool, easy two-way binding and then later you find out that whoops, it's actually a fundamental architectural problem and you get to go back and rip it all out. Good thing we picked this framework that saved us sooo much time!!

Re: 2 years with Angular

#177

I find the rise of Angular kind of baffling. Angular's scope system is exactly analogous to the scope system of a programming language. This is a solved problem! When you make a scope system, make it lexical, and require explicit declaration before use. If you're not making those choices, then at least acknowledge that these are the standard answers, with very clear advantages over other scoping systems, and explain…

> Angular's scope system is exactly analogous to the scope system of a programming language.

Yup. Because it's literally using javascript scoping/inheritance directly. A new $scope object from a parent $scope can be treated the same as the new scope inside of a function block because it's how prototypical inheritance works. Not surprising that they used the scoping system of the language they're building in.

> Now that angular is being widely used, people are noticing that it's slow...

With wide use comes wide misuse. This is not new either. A hammer makes a crappy screwdriver, but it works. If you don't know your tool, you're gonna have a bad time.

> people are finally realizing Angular has its faults

I hope you're right. Because the more that people think something is perfect, the more it disappoints them when they realize that nothing's perfect. Use the right tool for the job and know its strengths and weaknesses and you're less likely to get caught with your pants down.

Re: 2 years with Angular

#178

Earlier quoted context omitted.

Personally, I use Angular for Backoffice tools and Backbone.Marionette for customer facing frontends.

what is your opinion about Backbone.Marionette. i have been looking at it for a while but have not jumped in

If you're using Backbone, Marionette is pretty much a must-have. It provides some great classes for common Backbone use cases like rendering a template and showing views for models in a collection. It also provides some additional application-level abstractions. Fills in a lot of common boilerplate and functionality.

My current app is actually still back on Marionette 1.0.4 for various reasons, so I'm not as familiar with the changes in the latest versions of Marionette. Looks like they've added a considerable amount since then.

Re: 2 years with Angular

#179

Earlier quoted context omitted.

Actually it depends more on the time of development and project specs. For now I'll probably choose ReactJS. If by the time Angular 2.0 is launched then I'll definitely give it a shot, it seems promising and is based on ECMA6 utilizing the new features provided by it will be a plus. IMO AngularJS can be scaled _IF_ used with caution, though I won't recommend it unless one has a good experience with its core.

But ReactJS isn't a full replacement for AngularJS (and I don't see why people apparently fail to make that distinction); React is just the V in MVC, Angular is / can be the rest.

I've seen many people repeating it; but I don't know what it even means.

It definitely is the V - since it renders the view.

But it is also the C - a component encapsulates the view and view logic together. From within the component, you have lifecycle events: when the component is mounted for the first time, whenever it receives new properties, when it is unmounted etc. In any of these events, you can receive data from the external world through AJAX calls. Or you can set up AJAX calls from outside the component, and in its callback, ask React to re-render the component. There are as many ways to update the data model inside the component as we can possibly do with Javascript and callbacks. This is exactly what a Controller in a traditional MVC does: orchestrate data flow between the external world and the view. React does it beautifully.

React can also be the M, or it can compose it into the component. You can have your own validation methods and business logic that mutates the state in the component (a component is simply a Javascript object with state); or you can compose your custom Javascript object or something like Backbone.model, and keep all your logic in there.

And you can use react-router for routing. What else do we need to compare React with Angular?

Re: 2 years with Angular

#180

I find the rise of Angular kind of baffling. Angular's scope system is exactly analogous to the scope system of a programming language. This is a solved problem! When you make a scope system, make it lexical, and require explicit declaration before use. If you're not making those choices, then at least acknowledge that these are the standard answers, with very clear advantages over other scoping systems, and explain…

> Angular's scope system is exactly analogous to the scope system of a programming language. Yup. Because it's literally using javascript scoping/inheritance directly. A new $scope object from a parent $scope can be treated the same as the new scope inside of a function block because it's how prototypical inheritance works. Not surprising that they used the scoping system of the language they're building in. > Now th…

"A new $scope object from a parent $scope can be treated the same as the new scope inside of a function block because it's how prototypical inheritance works."

This seems rather confused. There's lexical scoping with function blocks, and there's prototypical inheritance on objects, and yes in the abstract both are used for dereferencing identifiers. The parent post's point is that Angular's $scope rules are as though every function's scope behaves like prototypical inheritance on the call site rather than lexical name resolution. This is analogous to every function call being wrapped in a 'with' statement.

Post reply on HN