Re:AngularJS: The Bad Parts
by lobster_johnson on Wednesday November 05, 2014 @11:03PM
(#8565739)
Coincidentally, the scoping issue is almost exactly the same issue that plagued Zope, a Python-based app server, back in the day.
In Zope, any property could be inherited not just from the parent object, but from the current context; you could invoke the object path "a.b" and b would inherit from b, but if you invoked the object path "a.c.b", b would inherit from c instead. They called this design pattern "acquisition", and seemed rather proud of it until they realized it was the kind of magic that was ultimately too magical for its own good.
The Zope guys tried very hard to eradicate it, and in the process ended up alienating all the developers with the new, non-backwards-compatible version. Funnily enough, there is another Angular parallel to Zope: Just like Zope 3, AngularJS 2.0 is also not backwards-compatible.
Angular's parameter-based dependency injection is coincidentally the same reason Martini [1] is slower than most other Golang web frameworks. Clever, sure, but ultimately a design flaw.
These problems demonstrate how important it is to introduce a good design from the very beginning. You can fix bad code, but bad design is much harder to change.
In Zope, any property could be inherited not just from the parent object, but from the current context; you could invoke the object path "a.b" and b would inherit from b, but if you invoked the object path "a.c.b", b would inherit from c instead. They called this design pattern "acquisition", and seemed rather proud of it until they realized it was the kind of magic that was ultimately too magical for its own good.
The Zope guys tried very hard to eradicate it, and in the process ended up alienating all the developers with the new, non-backwards-compatible version. Funnily enough, there is another Angular parallel to Zope: Just like Zope 3, AngularJS 2.0 is also not backwards-compatible.
Angular's parameter-based dependency injection is coincidentally the same reason Martini [1] is slower than most other Golang web frameworks. Clever, sure, but ultimately a design flaw.
These problems demonstrate how important it is to introduce a good design from the very beginning. You can fix bad code, but bad design is much harder to change.
[1] https://github.com/go-martini/martini#service-injection