From 2c01d4daeff989a556083d26b7c6e5cf7f89b472 Mon Sep 17 00:00:00 2001 From: David Thompson Date: Sat, 5 Feb 2022 17:41:36 -0500 Subject: Prefix old post file names with dates. --- posts/angularjs.md | 135 ----------------------------------------------------- 1 file changed, 135 deletions(-) delete mode 100644 posts/angularjs.md (limited to 'posts/angularjs.md') diff --git a/posts/angularjs.md b/posts/angularjs.md deleted file mode 100644 index 0ea8c19..0000000 --- a/posts/angularjs.md +++ /dev/null @@ -1,135 +0,0 @@ -title: AngularJS Post-mortem -date: 2013-08-08 11:00:00 -tags: web, javascript, angularjs, wsu -summary: AngularJS likes/dislikes and what went right/wrong ---- - -[AngularJS](http://angularjs.org/) is the new popular client-side -Javascript application framework developed by Google. We have recently -adopted it at Vista Higher Learning for building our latest features -that require a lot client-side logic. Now that I have a few -applications under my belt, it’s time to talk about my experience. - -If you want a quick TL;DR: I think AngularJS is good, but it has a -steep learning curve and there’s no well defined set of best -practices. - -Note: I will be using plenty of terms that will probably only make -sense for people that have used AngularJS. - -The Good Stuff --------------- - -These are the things that went well. The things that made me glad that -we chose to use AngularJS. - -### Easier Testing - -Our Javascript test suite uses -[Jasmine](http://pivotal.github.io/jasmine/). AngularJS is built with -test frameworks like Jasmine in mind. AngularJS could tends to be -easily testable due to dependency injection. When the components of an -application don’t rely on global state, it is easier to mock services -for unit tests. - -### Separation of Concerns - -AngularJS stresses separating the view from the data structures and -logic behind it. I think everyone that’s written a somewhat complex -JQuery application can relate to the mess of CSS selectors and click -callbacks that the code quickly degenerates into. - -AngularJS allows you to break up the DOM into logical chunks that are -handled by separate controllers. Treating the application as many -small pieces working together rather than one giant DOM blob keeps the -code clean. Message passing via `$emit` and `$broadcast` keeps -controllers loosely coupled to each other. - -### No More JQuery Spaghetti - -Directives, the strategy for encapsulating DOM manipulation, are -wonderful. It is an elegant solution to the mess that was JQuery -selectors and event callbacks. AngularJS comes with a lot of -directives out of the box to handle the most common stuff like -showing/hiding elements, handling clicks, dynamically setting CSS -classes. - -### More Maintainable Code - -AngularJS is feature-rich. It does a lot on your behalf, which greatly -reduces the amount of boilerplate code needed to get a prototype up -and running. I had the opportunity to essentially rewrite an existing -JQuery application using AngularJS. The results were clear: The -AngularJS version had fewer lines of code, was more readable, and -was easier to debug. - -Bumps in the Road ------------------ - -These are the things that didn’t go smoothly. They boil down to -AngularJS having a steep learning curve and ill-informed software -design decisions on my part. - -### Understanding the Magic - -A lot of things seem to happen by magic. For example, it is possible -to make a asynchronous request and get a promise object in -return. When the promise is assigned to a variable on `$scope`, -AngularJS not only knows to ignore it while the request hasn’t -finished, but it will re-assign to that variable the value of the -asynchronous call when it completes. It is a nice feature, but it -takes some digging to find out what is really going on. - -### Poor Documentation - -I know I’m not the only one that hates the official AngularJS -documentation. The documentation is getting more complete, but its -still not very useful. Functions frequently have a blurb describing -what they do, but no explanation of the parameter list. It’s hard to -use a function that doesn’t describe what it expects for input. - -When the documentation confused us, which it did frequently, we turned -to the AngularJS book from -[O’Reilly](http://shop.oreilly.com/product/0636920028055.do) for -help. I need to get around to reading more of it. - -### RESTful Resources and Rails - -AngularJS claims to be targeted at CRUD applications, but using the -HTTP backend and the `Resource` abstraction that sits on top of it was -particularly difficult. A good amount of time was spent on trying to -get the HTTP requests from resources to conform to what our Rails -backend expects, like root-wrapping. - -### Bloated Controllers - -I frequently made controllers that had too much state and logic that -should have been extracted into services/factories/etc. A controller -would start out slim but would quickly grow to several hundred lines -of code as features were added. Controllers should be the middle man -between the view and the model and that’s it. - -Some tell-tale signs that a controller is becoming bloated: - -* There are a lot of private functions (not defined on `$scope`) - -* Functions are defined on `$scope` just so you can unit-test them, - but are never used in the template - -I attribute controller bloat to a lack of knowing the appropriate uses -for other AngularJS components. It was easy to just keep adding to the -controller. - -Conclusion ----------- - -Overall, I think things went well, but I (and the rest of my team) -made a lot of beginner mistakes. But that’s the learning process, -isn’t it? - -Now that I know more about AngularJS, it will be easier to make better -design decisions moving forward. - -I believe that as AngularJS continues to mature, some concensus in the -community about best practices will emerge that will make things -easier for beginners. -- cgit v1.2.3