4 ms·
This is possibly better called a list of framework design mistakes made by the AngularJS team. #3: The fact that the default dependency injection mechanism bre
by lars 12y ago
This is possibly better called a list of framework design mistakes made by the AngularJS team.
#3: The fact that the default dependency injection mechanism breaks when minified means it should never have been included. If this mechanism sneaks in anywhere in your app (and there are plenty of third party libs that use it), it wont start breaking until you bundle and minify the code, at which point you may already be in production.
#5: The service/factory distinction adds a conceptual complexity that is completely unnecessary, as demonstrated in this blog post.
#7: Having too many watchers will slow your app down to a crawl on a desktop machine, and be even worse on a phone. This happens more easily than you'd think and it's fundamentally caused by Angulars reliance on its digest loop. This loop is the essence of how Angular works, and it means that there are tons of applications that cannot ever run efficiently if they're built on Angular.
8#: Because of the way their $scope system works, it is actually literally impossible to tell what the the meaning of ng-model="foo" is by reading the program. It may in fact depend on the order in which the user interacts with elements of the web page. Consider this example: http://jsfiddle.net/7kkxLkxh/ http://jsfiddle.net/7kkxLkxh/ What foo binds to is dependent on which input you type into first. Yes, there are ways to avoid this, but it should have been avoided by either disallowing this construct, or requiring foo to be declared before it is used. (If you miss a var in JS, you get a global - that turned out to be bad language design. Removing the var keyword and effectively deciding on variable scope at runtime is certainly a much worse language design.)
After working on a large Angular project, it is clear to me that there are a lot of ideas in there that are frankly not good. It's sad that there seems to be very little discussion anywhere about the downsides of the various frameworks that are out there.
- hcho 12y agoThere are angular specific minifiers dealing just fine with #3. It's more of a toolchain problem. For #5 the real deal is the provider and everything else is syntactic sugar on top of it. Once you have a very large application you start to appreciate the distinction. The naming of concepts is awful though; could have been much more clearer.
- nawitus 12y ago>There are angular specific minifiers dealing just fine with #3. It's more of a toolchain problem. I'm sorry to say it's pretty "retarded" to add in framework-specific minifiers to the build process. I don't want to tweak 10 different minifiers if I'm using 10 different libraries in my application.
- hcho 12y agoSorry, I was wrong at the first time it's not actually the minifier that deals with injection. It's a preprocessor called ng-min. You can use any minifier after that. It's been a while since I touched my grunt file. I stand corrected.
- josekpaul 12y agoI concur: this is a good list of issues. One additional thing I found was composition/inheritance of controllers with $injector.invoke.. breaks in minified code because of issues similar to #3.
- grumblestumble 12y agoI'm fairly certain that the majority of Angular developers would tell you that controller inheritance is an anti-pattern. This is what services are for. The furthest I go is using services as controller mixins, eg. $scope.commonTools = CommonToolsMixinService.call($scope);
- nawitus 12y ago>#3: The fact that the default dependency injection mechanism breaks when minified means it should never have been included. If this mechanism sneaks in anywhere in your app (and there are plenty of third party libs that use it), it wont start breaking until you bundle and minify the code, at which point you may already be in production. I think the real mistake in that scenario is not minifying the code until "in production". You should minify your code from the day one. Although I agree that the "not safe for minifying" mechanism shouldn't have been included in AngularJS. On the other (other) hand, it's pretty abhorrent that minifying is something that developers need to actually place any thought into..
- boydjd 12y ago> I think the real mistake in that scenario is not minifying the code until "in production". You should minify your code from the day one. How are you debugging minified code?
- grumblestumble 12y agosourcemaps?
- nawitus 12y agoThat's a big problem. Firefox and Chrome these days support debugging source mapped files. However, I'm running through two source map steps: TypeScript to JavaScript and JavaScript to minified JavaScript. For whatever reason the browser debuggers don't work that well with this setup. They're buggy and make the browser very slow. I often do have to resort to "console.log" debugging. On the plus side I'm always running code like it's run in "production", which will make it easier to catch any bugs resulting from minifying.
- kaoD 12y agoI use Webpack with a similar setup (CoffeeScript->JavaScript->Minified) and I didn't notice any issues. Source maps stop working when using Webpack's hot code reloading, but it's a price I'm willing to pay.
- drdaeman 12y agoAs for #3, that's what "testing" (or "acceptance", if automated tests are run not in "development" phase, but at a separate "testing" stage) in development→testing→production sequence is for. It's virtually the same setup, running the code intended for production, but not visible to general audience.
- serve_yay 12y agoWow, bang on. I completely agree with all of this, and it has been my experience working on a large-ish Angular project as well.