Live data from Hacker News

2 years with Angular

fse.guru

31–40 of 216 posts

Re: 2 years with Angular

#31
post #25

I recently wrote about my experience with Angular in a different forum. Sharing it here: I worked on Angular last year building an app with a few complex views. The initial days were full of glory. Data-binding was new to me, which produced much goodwill towards the framework. Things started falling apart as I had to inevitably understand the framework in a little more depth. They practically wrote a programming lang…

I ran into a similar issue with data bindings on table cells. My solution was to keep a track of the cells in a service (later refactored into a directive), and then have the directive update the cells directly when they needed to be updated, rather than each cell listening for if it should be updated. Indeed this is more like jquery and less like angular, but with so many databindings it was necessary.

Re: 2 years with Angular

#32

I've worked on Angular projects of varying sizes -some as large as 30KLOC (products where every page has enough interaction to justify an Angular controller)- and I can never find myself agreeing with these articles. Have I just drunk too much kool-aid? Or is it possible that with the right team, the right architecture, Angular can actually be a really great framework to use? The common theme for every large Angular…

YES! Thank you! I think I'll die if I have to read another developer arrogantly defining what should and should not be, and how he, in all his glory, hereafter defines this framework to "NOT BE WORTHY".

I can't stand how some articles simply s&*t on years of software architecture principles and the work of very talented engineers and simply dismisses them like it's nothing.

If you disagree with a framework's perspective, AT LEAST be respectful.

BTW, I also have used Angular for 2 years and, given the pros and cons and existing alternatives, I will choose it again for my next big project. The structure is simply too solid. This is invaluable when you have a large team that must work together.

Re: 2 years with Angular

#33
post #25

I recently wrote about my experience with Angular in a different forum. Sharing it here: I worked on Angular last year building an app with a few complex views. The initial days were full of glory. Data-binding was new to me, which produced much goodwill towards the framework. Things started falling apart as I had to inevitably understand the framework in a little more depth. They practically wrote a programming lang…

I ran into a similar issue with data bindings on table cells. My solution was to keep a track of the cells in a service (later refactored into a directive), and then have the directive update the cells directly when they needed to be updated, rather than each cell listening for if it should be updated. Indeed this is more like jquery and less like angular, but with so many databindings it was necessary.

We ended up with a similar solution as well.

Large grids were rendered using jQuery's DOM methods. The data-flow was made explicit, and the view was updated whenever any change was needed.

React embraces the explicitness of data flow instead of watching the objects in the background. This is done using `setState`, which queues up a re-render of the virtual dom.

Re: 2 years with Angular

#34

"And whar are no-no factors for angular? Teams with varying experience. Projects, which are intended to grow. Lack of highly experienced frontend lead developer, who will look through the code all the time." I am greatly interested in learning what is the alternative that would be a 'yes-yes' in these bulletpoints.

This kind of distorts the issue here. The problem is not lack of highly skilled devs but rather the fact that you need highly skills devs to digest and maintain the level of complexity that Angular produces.

I'm big believer on light frameworks that does least amount of abstractions and can get out of way if you need. You definitely want to avoid frameworks that claims to abstract everything away and especially those that requires to learn entirely new way of doing pretty much everything and its own world of lingua franca. My preference therefore gravitates towards lighweight stuff like KnockoutJS and likes. Any average dev can understand KnockoutJS in just hour or two. More importantly, most devs can immediately have intuitive understanding of how things work under the hood and therefore can anticipate performance issues or easily extend it.

Re: 2 years with Angular

#35

I've worked on Angular projects of varying sizes -some as large as 30KLOC (products where every page has enough interaction to justify an Angular controller)- and I can never find myself agreeing with these articles. Have I just drunk too much kool-aid? Or is it possible that with the right team, the right architecture, Angular can actually be a really great framework to use? The common theme for every large Angular…

I am on the same boat.

I chose to use AngularJS in our team a year ago for quite a large web-app. It isn't perfect, but it is leagues ahead of whatever other choices I was and still aware of.

Regarding the brought up problems, they indeed exist. I think the true fault of Angular is that it gives the impression easy and friendly, while it is really, nothing of the sort:

"Come" it says, "Use my nice bindings. You don't need to worry, just bind all your data and will magically appear, no need to read the docs". Gladly you comply and all your data appears there. Magic.

"I see you have a lot of objects", says Angular, "go ahead and use ng-repeat to show them all... They will all manifest by themselves, no need to write anything." So you do that too, and it works.

Then a week later, when faced with real data in production, you have huge delays and the browser freezes for customers. "What have you done, Angular?" you shout angrily. "Now, now", it replies, "I thought you understood what you're doing, perhaps you should, after all, read all the docs, and maybe some blogs and videos about AngularJS performance tips, and of course, it is always suggested to read the source."

P.S I haven't played too much with React yet and I should definitely do so.

Re: 2 years with Angular

#37

I've worked on Angular projects of varying sizes -some as large as 30KLOC (products where every page has enough interaction to justify an Angular controller)- and I can never find myself agreeing with these articles. Have I just drunk too much kool-aid? Or is it possible that with the right team, the right architecture, Angular can actually be a really great framework to use? The common theme for every large Angular…

I think the keyword here is "state". A lot of bad code is written because people think they need to access (global) state all the time.

Maybe you drunk too much good practice-aid ;)

Re: 2 years with Angular

#38
post #32

I've worked on Angular projects of varying sizes -some as large as 30KLOC (products where every page has enough interaction to justify an Angular controller)- and I can never find myself agreeing with these articles. Have I just drunk too much kool-aid? Or is it possible that with the right team, the right architecture, Angular can actually be a really great framework to use? The common theme for every large Angular…

YES! Thank you! I think I'll die if I have to read another developer arrogantly defining what should and should not be, and how he, in all his glory, hereafter defines this framework to "NOT BE WORTHY". I can't stand how some articles simply s&*t on years of software architecture principles and the work of very talented engineers and simply dismisses them like it's nothing. If you disagree with a framework's perspect…

I am always conflicted about writing about Angular on a negative light because the team has put some great work into it while raising the bar in how rich apps could be built on the web. Being a back-end developer for a long time, it let me build some great interfaces on the front-end really quickly, and I'm very thankful for that.

But we should also learn from where Angular succeeded and where it failed. Making XML declarative is fraught with difficulties. Things like ng-repeat are but a thin declarative veneer over the fundamentally imperative nature of constructing views. The biggest difference between most existing templating frameworks and React is in this world view: is the view constructed imperatively, or is it declared?

The other question of contention is how much implicit magic should the framework supply vs how much explicitness the user should bring into the code. Angular's design decision is to make bindings work magically, while React identifies explicitness as a virtue.

Having used both, I'm liking the imperative+explict camp.

Re: 2 years with Angular

#39
I can't speak of Angular since I haven't used it but one problem that is recurring with use frameworks, in general, is that thinking or getting used to "their" way takes a significant amount of time and seeing the continuous change of technology, I am not sure that time is justifiable in the longer run.

Take example of rails. I was trying to learn it sometime ago and was really amazed how it has a process for nearly everything. Migrations, asset pipelines, generators, and very extensive command line. Sure it does make it seem like "Once I learn it, it will be so much easy to make the next app" but it is easy to realize after sometime that you have to cross usual hurdles of Googling everything, learning these processes, facing issues, digging out new ways of debugging to finally be good at it.

My idea is that frameworks should be minimal which only ensure a basic working architecture and everything else should be extensible (via packages).

Re: 2 years with Angular

#40
post #6

If Angular is not The Thing (a premise which I have no trouble believing), then what is a Good Thing to perform the task of, for example, consuming Django Rest Framework endpoints and making a frontend of them?

IMHO Good Thing is to have set of libraries and not a framework at all. Start with handcrafting all HTML,CSS with interactions you need. You HTML skeleton will depend greatly on what you want to achieve - like when one page changes to other and theres a ajax call between - where you put the wait screen: as separate, on old page, then wait, transit to new at once, then wait and so on. If that is done you know broadly what you need. Example configuration may be React for rendering, cherry picked Model (or State) from Ampersand, Backbone Events Standalone for event bus. Something for History/routes too, can't recommend anything specific because my projects did not had one (yes, you can build web-app without back button support). This way if something better comes up, you can switch, if something is abandoned, gets your way, you can switch. Or you can rewrite it in-house fairly easily. I imagine that when you discover that React is too much, too heavy, too bloaty (for example, i'm not saying, that it is, we are happy React users now), then preserving all API calls and replacing it with few lines of Mustache templates is doable. Not trivial, but doable.
Post reply on HN