Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

What's the long answer? I think it's laughable to say that you can take a part of a monolithic framework and drop it in as a replacement in a different framework.

Actually a short answer will do fine. Ignoring Backbone, name ONE part of a major framework you can do that with?



very short answer - backbone.

longer answer - there is rarely drop in replacement, but when framework uses other well designed technologies, instead of reinventing the wheel, knowledge about these technologies way more useful, than knowing details and gotchas of $digest loop.

Examples:

* handlebars templates used in many frameworks. Quite often you can literally copy templates over into new project.

* usage of real promises allows you to use chai async tests without looking back at framework, instead of relying on right timing of firing $apply() (and making sure to not call it twice!)

* not relying on dirty-checking, and instead use setters/getters quite often forces you to think and isolate model code from glue.

* describing state via html (as it is proposed with ui.router - very popular component) can not be easily migrated at all, since most of frameworks define state in code and/or configs. This is paradigm shift.

While I agree, the bigger framework, harder it gets to write portable code, but angular in practice tends to make it even harder in my experience.


So basically, your problem is you like to pick and choose modular pieces from non monolithic frameworks and "Angular sucks" because it doesn't do what you like.

There's nothing wrong with Backbone, particularly when you like to replace parts with other parts. But Angular is not bad simply because modularity wasn't a design goal.

It's notable that your arguments aren't arguments against Angular persay but against every single non-modular framework ever made.

I don't mind people disliking Angular. I mind it when people pretend their preconceived notions about software design are "right" and software that doesn't align with their notions are "wrong".


I don't like when I can't replace broken part of framework. And this is often the case with angular. Mostly because of foundation it is built on - dirty checking and it's own dependency injection mechanism. Because of these two there are a lot of things backwards. dirty checking is major cause of whole $digest loop, as well as every async function being mirrored via $-equivalent and non working promises. This cruft accumulates over time and wastes a lot of human resources.

The only reason you might not dislike angular is if you never had to deal with issues above OR you never had different experience, sorry.


Like I said, that's a ton of opinion based entirely on YOUR desire to replace parts YOU don't like. Dirty checking isn't perfect (by any stretch) but it's not the worst thing to happen since the cold war either.

The bottom line seems to be that your bad experience is relevant while all good experiences are irrelevant because they weren't your bad experience.

That tells me you simply don't know how to use it, sorry.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: