As someone who has thus far only used with Angular for smaller projects, seeing performance raised as a concern is a bit of a concern for ever using it in a serious project. Would still like to see some numbers to back up the anecdotal evidence. It's also hard to motivate starting a potentially large project in Angular right now, knowing that v2 is on the way that is basically a new framework.
2 years with Angular
181–190 of 216 posts
Re: 2 years with Angular
#182While most of the arguments presented in this article are somewhat valid but I hope with the release of Angular 2.0 majority of the issues will be addressed (though does it make sense to make such drastic changes in the upcoming is another debate and already taken care of at: https://news.ycombinator.com/item?id=8507632 ) I'm currently working on a comparatively large webapp built in Angular and it was after about 7…
Why look forward to angular 2.0? I mean, it's a completely different framework, so why are you anticipating it, and not any of the millions of other new frameworks coming out?
You can find the detailed discussion in the HN link above, but to summarize my viewpoint on this:
1. It already has a much bigger and growing community than any of the new frameworks
2. It has backing/support of Google, when such a big company puts steam behind something than you can be sure it's not going to die out just like that, and will continue to grow and improve, no other framework other than ReactJS has such a portfolio
3. Third-party plugins/components, AngularJS already has some amazing libraries/plugins/directives built that one can easily plug into the project (this is by far greater than any other new frameworks coming out)
and one can go on...
Re: 2 years with Angular
#183Earlier quoted context omitted.
Somewhat, but not completely unrelated to your story... > Google recently released a new version of their developer console ( https://console.developers.google.com ) which is built on Angular. Which actually works worse than the previous version. The layout is non-responsive and creates massive amounts of scrollbars on "portrait"-monitors, while 90% of the screen is effectively white-space. Completely wasted. Complet…
IE11's developer console UI is also apparently written in HTML/JS rather than a native UI. It's not better.
To my knowledge, all browser developer console's are built with html/js. Most of them can be opened remotely as a consequence (where the browser acts as a web server).
Re: 2 years with Angular
#184Earlier quoted context omitted.
> 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…
My thought pattern on lexical scopes in javascript is that they're essentially a new object off of the prototype of the parent lexical scope. At least they have very similar properties.
In a new lexical scope, a new variable of the same name as one accessed via closure means I lose reference enclosed variable. In the same way, a new property of the same name as a property in the prototype chain means I lose reference to that property somewhere up the chain.
I have a suspicion that it's all linked lists of hashmaps under the hood, though I haven't checked the source. At the very least, prototypical inheritance and lexical scoping can definitely both be implemented that way.
Re: 2 years with Angular
#185I really resonate with: "Do not make things easy to use, make your components and abstractions simple to understand."
And not only for AngularJS but as design principle.
Re: 2 years with Angular
#186Maybe 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.
Backbone looks interesting and I've worked on projects that used it but honestly I've never really taken a hard look at it nor had to make huge changes with it to really have a good opinion one way or another on it. I mostly started writing and using msngr.js because I love messaging and I didn't see anything that did exactly what I wanted to do (and even if I had found something I still may have written it anyway as I've learned quite a bit in doing so).
Re: 2 years with Angular
#187Earlier quoted context omitted.
Somewhat, but not completely unrelated to your story... > Google recently released a new version of their developer console ( https://console.developers.google.com ) which is built on Angular. Which actually works worse than the previous version. The layout is non-responsive and creates massive amounts of scrollbars on "portrait"-monitors, while 90% of the screen is effectively white-space. Completely wasted. Complet…
IE11's developer console UI is also apparently written in HTML/JS rather than a native UI. It's not better.
He's talking about the console for managing your Google applications, not the web developer console.
Re: 2 years with Angular
#188disclaimer: I'm the author of Mithril.js
I've also used Angular for around 2 years for a large application. This article resonates pretty accurately with the problems we were running into before I decided to write Mithril.
It can certainly work well (heck, the mobile part of our app was doing just fine because it was specifically designed to be a trimmed down version of the much more powerful desktop app), but performance problems aren't necessarily because people don't know how to use Angular. In our case, performance problems usually became obvious when we had UIs for editing large volumes of information, and large volumes of information did appear on the page. Two of the examples that we were running into problems with were a work breakdown structure UI, and a scheduling UI, which are far from being things-you-should-not-be-doing.
The team scalability issue is real, but I think it's not entirely Angular's fault per se. My general experience w/ co-workers dabbling w/ Angular was that they were accustomed to jQuery in terms of discoverability (i.e. if you don't know jQuery, you can fake it w/ Google-fu until make it). Getting into Angular is not like that at all. There are lots of places where you can shoot your foot if you don't do it the right way (tm), and deadlines will trump doing it the right way if the right way is sufficiently non-intuitive. You can blame that on teams not having good processes or good developer or what have you, but hey, that's the real world for ya.
My main problem with Angular is the error messages. Imagine writing this:
$(".foo").each(function() {
this.addClass("bar")
})
Re: 2 years with Angular
#189Earlier quoted context omitted.
> 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.
apart from the overhead of finding out if the normal DOM method will work - and the overhead of parsing the selector to make sure it's not using jQuery extensions.
Re: 2 years with Angular
#190Earlier quoted context omitted.
Clearly you like react, but react also doesn't do as much for you as Angular. It's "only the V in MVC."
By this reasoning, functional programming is only the "method" in OOP. Surely that means OOP is a necessarily fuller abstraction? React gives you a powerful V that expresses things so intuitively that for most cases it eschews the help of a C or an M. That's a good thing when it's achievable.
It doesn't seem true to me that the "V" React gives you is so good that you don't need anything else. It does seem common (though not universal) to eschew MVC for React apps, but in most cases it is replaced with something like the Flux architecture, which is no more or less complexity than MVC, it's just different.