3 ms·
every time google plays with front end code they make every attempt to turn it into their own language one that has as little relation as possible to the underl
by vectorpush 13y ago
every time google plays with front end code they make every attempt to turn it into their own language one that has as little relation as possible to the underlying code that's happening.
This doesn't make sense to me. AngularJS is the underlying code that is happening. Angular is a framework, not a language, it's just JavaScript and really quite simple once you wrap your head around the role of the injector, services, and service providers (whereas everyone seems to pick up modules, controllers and directives pretty quickly).
As we all know, abstractions leak, please avoid and use one of the many other libraries that people can actually follow through and debug without having to learn Angular first.
Abstractions leak, please avoid and use one of the many other libraries that also make heavy use of abstractions, the foundation of modern computing.
- andy_ppp 13y agoIt's difficult to trace through Angular programs compared to say Express JS - express is a much cleaner framework than Angular which pollutes your HTML and JavaScript with lots of magic. In the early days of Django the had a magic removal branch for this very reason; people who do not understand the framework will find it harder to learn. This is just my experience. Maybe you are some sort of Angular savant who agrees with all the assumptions the authors made. Haha, and your abstractions comment deliberately misses the point; of course we abstract things but you should use the simplest possible abstraction for the job. Angular is not that.
- vectorpush 13y agoIt's difficult to trace through Angular programs compared to say Express JS - express is a much cleaner framework than Angular which pollutes your HTML and JavaScript with lots of magic. "lots of magic" and "difficult to trace compared to x" sound a lot more reasonable than claiming AngularJS is an abomination, so I'll address those claims instead. Yes, magic in programming can be dangerous, but keep in mind that magic always has a logical explanation. In this case, the magic turns out to be a pretty mundane case of metaprogramming. If a developer can't understand how it might be possible to pattern match parameter identifiers in JavaScript, then I think AngularJS DI is the least of their worries. Maybe you are some sort of Angular savant who agrees with all the assumptions the authors made. I'll take that as a compliment, but I'm just a regular guy who has pushed a few medium sized angular apps into production. I definitely don't agree with all of angular's design decisions, but I don't have to agree with everything to use the framework effectively. In the early days of Django the had a magic removal branch for this very reason; people who do not understand the framework will find it harder to learn. Contrast that anecdote with Rails, a framework that has very successfully embraced the power of magic from the start to create what is arguably the most influential web framework of the last decade. It's an opinionated approach, but not inherently wrong. of course we abstract things but you should use the simplest possible abstraction for the job. Angular is not that. The simplest solution isn't always the best solution, if that were the case we wouldn't be discussing client side scripting in any capacity.