Why you should not use AngularJs(medium.com) |
Why you should not use AngularJs(medium.com) |
It Kinda reminds me whole Wordpress thing. Really subpar codebase - but at the same time very easy to make simple things, and as a result - a lot of popularity. And this comes not as surprise to see so many blog posts comparing Angular to jQuery...
But perhaps this bothers me the most - https://www.youtube.com/watch?v=X0VsStcCCM8#t=745
Guy behind framework openly admits he did not really pay attention to what other frameworks were doing (and Ember used to be Sproutcore and went through similar observe-loop pains in the past.) He just transferred his Java-server-side-MVC experience ($scope/$context - these are very distinct server-side MVC concepts) as is to the browser, which, as turned out, not quite well suited for long living in-browser apps..
And then whole dependency/packaging mess. There were already solution and tooling in place for AMD - but he decided to reinvent it, and as a result integrating any serious building process is a pain (i am not talking about 1 page apps here, i am talking about apps with 10Mb of JS code bases.)
While this all workable, and this is what I do at my day job, this should not be necessary. I call it "bullshit job" just like many "create report" type of jobs - where no real value is created.
If you know 100% that your app will never grow outside small prototype - go for it, otherwise either have plan in place to redo your app in sane framework, or do your app in sane framework from the start.
For me personally it is Backbone (very minimal skeleton-like framework), view/binding library I like today (and can switch tomorrow) and routing I probably write myself for specific use case.
If this is too "low-level", next what I will check in "higher level" framework - as least "magic" as possible - i.e. explicit getters and setters with current state of Ecmascript, clear rules on how and when rendering happens, debuggable views (which often means views being compiled into JS.), being able to split large application in pieces which get loaded on demand without hacking/monkey-patching framework, being able to use jQuery if I want to, and not include it if I don't need it.
Sorry, no specific answer to your question, as I think it is problem specific, and even Angular can be used in some limited cases as it turned out.
The only thing they seem to use is react, a requirejs like module system combined with an EventEmitter. I still don't understand the need of three layers of abstraction on the front-end level. I would love to be proven wrong, but that seems outright over-engineering.
I much prefer to write my own controllers and models and use Reactjs for the views.
The databinding capabilities is said to be at 8000+ watchers now, although not all watchers are equal. A lot of performance improvements have been made since 2-3 years ago when that post was made about the watchers, which is where that oft poorly quoted 2000 watcher number originates from.
The two way databinding complaints miss the mark - the point of them in directives was to mimic eencapsulation and what is now being known as the we component spec. Web Components are essentially what Angular directives were meant to be in absence of an official spec for browsers to implement. The point of two way databinding in inputs also are for encapsulating logic for each component.
The comments about ng-cloak and ng-bind were also flat out incorrect.
I think most of all, the author doesn't understand context - Angular was conceived during a different time for frontend, and at a different time with browser support. Five years is a long time to last in the frontend world currently, and that it will likely last at least 3 years more is surprising for a framework that has changed frontend development for the better overall.
Angular is obviously not perfect, and the core team members are quick to point out flaws in approach, or solutions that were good at the time but don't make sense going forward due to changes in the browser environment or other technologies solving problems that Angular had to solve, such as with Object.observe, ES6 modules, and ES6 promises.
I have built & architected many Angular apps over the past two years, some being very complex due to the problem space. I have found Angular to be perfectly suited to the task, and snappy to boot. I have seen very few perf problems where I could not fix them with a little work - the only one that was too difficult was dealing with editable tables with lots of data in older browsers (IE8 - 10), and I believe I could have tackled it, but I was playing more of an advisor role to another developer, and these sort of problems usually require the engineer working on the problem to understand the nuances of the code itself.
But to each his own.
The scaling thing is just one of the hurdles you have to manage in this framework. Every system has them. Once you learn where the limits are the tools exist to manage it:
https://www.exratione.com/2013/12/considering-speed-and-slow...
Like all frameworks, Angular isn't suited to every task. If you are rendering massive tables, to pick the obvious example, then you probably shouldn't be using any of the modern binding-based frameworks for that part of your application.
Is this a fundamental rule? I thought it was something highly valued by python culture but not by, say, ruby on rails.
the only problem i have with this article is: i wrote a hatre comment on angularjs about 8 months ago and got downvoted heavily, but this one just keeps earning points!
The Angular does nice job allowing simple interactive apps to be written in 30 minutes by anyone familiar with HTML and JavaScript. At the same time, if the app performs what is needed by the client, the app can be profiles, and each bottleneck can be optimized in a couple of steps.
For example, we went through this process and described the steps we used in http://bahmutov.calepin.co/improving-angular-web-app-perform...
I'm not sure how a frontend noob can have "old jquery days"! Not sure a comparison with jquery is needed. They're different enough, or do some people actually consider using Angular a "step up from" Angular? That would be funny.
Personally I prefer the cross browser/device performance benefit of jquery even for a medium sized app. Potential growth of the app's frontend needs can be met with jquery. It runs quick I've noticed even when it has a ton of work both initially and dynamically. I've thrown a lot at it, too much, and Jquery doesn't mind a high load of elements and updates, especially if you get your loading spinner graphics and display-timing sorted, complex pages can look quite smooth even on mobile. It wouldn't be wise to rule out a good performer like jquery.
Of course, the generally poor documentation does not help newcomers...
I've begun using Angular for personal projects. At work we use CANjs. I like CANjs but I have to say it feels easier to become productive on AngularJS. For me productivity is most important.
Regarding framework vs library. I heard more than one speaker at Fluent last year say that Angular was a library and not a framework like Ember. For me Angular seems pretty light weight compared to what else is out there.
Maybe in a few months I'll feel different. For now I don't hate on Angular.
> When you minify your code, it stops working, since variables are injected by name. ... You have to use this syntax ...
We didn't have that problem. Or rather we did until we reaised that the minification tooling can convert it automatically. The author does not know that his problem is not a problem any more as it has already been solved.
How can you trust such a tool? Do you want to rewrite your applications when version 3 comes out? Whos to say thy want do the same thing come v3
One can always talk about any framework like this.
Good reasons to NOT use a framework might be: Lack of hope in future improvements, Inability to deliver the necessities, etc.
AngularJS delivers and there is a lot of hope around it and that's exactly the reason people use ReactJS too.
AngularJS is a very powerful framework and implements many of the common patterns in rich web applications. It has a learning curve which is normal, and poor documentation which is being improved day by day.
Adopting AngularJS will result in less coding in the near future which in turn will result in less bugs and support. Therefore making it worth the learning curve.
The more you want to throw on a page (say for infinite scrolling), not surprisingly, the more you'll have to be careful about how you do it. The benefit with Angular has always been that it brings the difficulty of every task down a notch or two and limits your cognitive load, very much due to its design. You still have to design your page and architect your data.
To be honest, after three years with the product, I still think Angular (1.x) was 10 years ahead of its time.
I've also come to a realization about Angular 2.0 as well: how many people are still using Windows XP? It's almost 4 versions behind, and closed-source to boot. I (as many others did) jumped all-too-quickly to the conclusion that I had to switch to version 2.0 when it came out. That's simply not the case.
Heck, even Microsoft seems to get every other version wrong. Maybe Angular 3.0 will be the time to switch.
Saying that data binding is wrong because it doesn't use click handlers for a button is kinda silly...Angular allows you to do that. I use ng-click all the time on buttons. $watch is for communicating between interdependent components not handling click events.
One example is overriding an association proxy to have other side effects. Sure it makes for a few very sort lines of code to cause whatever those effects are, but unless someone has read the implementation of the code that behavior becomes completely opaque.
Similarly, acts_as_foo plugins that add implicit behavior everywhere.
The core idea was clever at the time -- that one could do better domain modeling than a few sql statements in a file by using AR and callbacks, but after the app gets a bit complex the domain model classes typically become very tightly coupled and much logic has been flushed away into implicit behaviors to make the remaining code halfway readable.
I have yet to see a Rails app that can stick with the basic structure with over 20 models and still feel remotely well engineered.
app.php
<?php
// logic and state here
include 'some_other.php' // modifies or adds state in unknown ways
// more logic
$some_variable = 3; // does the include below depend on this? who knows.
include 'yet_another.php' // expects state, who knows what
// also modifies state
echo $state; // not sure if we can remove/replace any of those includes and this will be as expected.
?>
The same can be found in Rails in partials.
Also, in Rails, helpers are essentially crippled presenters that have access to lots of effectively global state and thus cannot be reused.
Of course, not all problems have default solutions and those should usually not have default behaviours.
To be honest, I'd rather state the rule as following when designing an API: "Do the obvious thing". Sometimes that will involve explicitness, and sometimes it will involve implicitness, but almost always it will be a mixture where some aspects are explicit and some things are implicit. The hard part is figuring out what should be which.
TLDR: with RoR, things like `[1,2,3].third` or `foo.present?` is highly encouraged.
That’s a totally human quality metric, which you can’t enumerate.
One thing I've found while doing Android dev is that views should exist as an immutable collection of state (POJO in Java), and there should be some mechanism to inflate a view from that state. I'm not sure how Angular or Backbone deal with this, but that switch simplified the logic a great deal and made testing straightforward.