I won't be using Angular for my next project
javascriptkicks.com
javascriptkicks.com
After many years of dealing with various frontend frameworks I've essentially taken a curmudgeon attitude with many of them and find it far easier to simply write my applications using just JavaScript and maybe some messaging library to get the decoupling I want (I've posted on HN before about my little library called msngr.js that I use in many of my projects now because I am in love with messaging patterns). I find these far easier to understand than any of the frameworks that provide "magic" of sorts where automatic things happen for you.
The last time I used Angular was picking up a project other developers did. It had a good separation but felt very overly complex. But I feel that way with most frameworks (especially react).
I think the key takeaway here is that Angular, React, etc; these frameworks are not for everyone and are not for every project. If a framework forces a way of development that helps keep productivity higher then it's probably a good fit at least for that team. As a plus almost any of these frameworks can be used with great success for prototyping. So I think there is always value there.
If it were simply a view generation library you could use a dom-diffing library to diff it. But React does full lifecycle management in addition to "generation".
The fact that you can't use React along with other libraries in the same space means its a framework.
In other words, you're asking folks to not just learn something new, but also forget something they've perhaps invested a great deal of time and energy into already.
Sometimes, that tradeoff is worthwhile. But it's never free.
As an analogy, the difference between x and y is why, in decades past, so many inexperienced programmers started coding C without ever learning assembly - and then later, so many people started codig in a high-level interpreted language without ever learning C/C++. (Which may have been the language the interpreter was coded in, or even available directy if they needed it, such as in very performance-oriented code.)
* a general observation, more rigorously read: inexperienced.
I haven't written any assembly in many years now, but for a good while it was still pretty important to maintain that knowledge - you never knew when you'd need to use it for a routine here or there that was just too slow or cumbersome in C. And still, long, long after that, debugging C required at least some assembly knowledge if you wanted to get home in time for supper.
And this is where I see folks getting into the weeds with stuff like Angular: if you completely forget (or never learn) the underlying platform, it's entirely too easy to get stuck when it comes to debugging or even performance issues: you know it shouldn't take 3 seconds to render the page, but if you can't look under the abstraction then you're hosed.
So eventually, you're stuck learning the whole stack anyway. And now it's not a sunk cost: you have to forget what lies beneath every time you sit down...
I purposefully didn't include a link to it in my comment, possibly to my own detriment, because I didn't want to come across as someone who was trying to hop on the topic of the article to simply promote my library.
But I don't think it's a good idea to lump disparate things together under the rubric "JS frameworks". Saying "things like Angular or React" is not really saying much except that they're both written in the same programming language, IMO.
You're right; my underlying point was out of all of the frameworks or libraries I've tried that are supposed to abstract away from many aspects (DOM manipulation, AJAX calls, etc) I've found them being overly complex. I'll be more specific next time and expound on my thoughts.
I do use a lot of libraries though. But libraries are different beasts, they solve your problems and not try to hide it from you.
The unix ideology of single purpose, easy to debug tools chained together is the only way to stay sane in the industry. But we have not got that memo yet.
If any framework has "magic happens" step, you are probably safer not using it.
Also, it's actually a lot closer to being ready than people think. We've had relatively few roadblocks despite the alpha status. It tries to do less than v1 did, which we appreciate as a framework extension.
So, obviously we are heavily invested in Angular, but we also see the v1 design issues firsthand and are the first to admit Angular can, and should, be better (though people are building amazing applications with it today). I'm convinced v2 is going to be great for the project and switching costs won't be as terrible as previously predicted.
Plus, it's going to make v2 of Ionic a lot faster and better, so I'm all for it.
(also, we are starting a series of posts on how Angular 2 works, if you're interested: http://blog.ionic.io/angular-2-series-introduction/)
I disagree with many of this article's points. I was once a junior developer, and what Angular did was bring a lot of better practices to my code and exposed me to a lot of things that I would not likely to have been exposed to in such an easy manner, such as unit testing, easy to grasp high level structures. From what I have seen, it also has introduced a lot of better practices to a lot of companies, whose developers previously wrote awful code that was hard to reason about - Angular 1 does not cure this completely, but it helps give a foundation that does ease life some when working with flawed architecture, since it discourages even worse stuff strongly by design and by communication.
Angular 2 is already shaping up to be absolutely awesome so far, excepting how it handles dynamic components currently, but I believe this will be fixed before it reaches beta status - it is moving extremely fast currently. It feels very similar to using React, except with more standards-based tooling & browser technology support (Web Components, ES6 usage built into its design, etc.), no JSX, and less clunkiness (the getters/setters for component states in React get clunky quickly, as well as the various other checks).
I think there's room for a 2-way like wrapper for the common input use-case (ala ngModel). Still digging in though.
(way more info on change detection in v2: http://victorsavkin.com/post/110170125256/change-detection-i...)
Some quick tips for making the transition smoother:
* Use "controller as" syntax: http://toddmotto.com/digging-into-angulars-controller-as-syntax/
* Use ES6 if you want http://blog.thoughtram.io/angularjs/es6/2015/01/23/exploring-angular-1.3-using-es6.html
* Build components using element tags not classes. (attributes are fine but components are better expressed as unique elements).
Here's a talk (including Andrew Joslin, an Ionic dev) about moving from 1.3 to 2: https://www.youtube.com/watch?v=pai1ZdFI2dg
You probably don't need angular at that point anyway. You could make up your own stack it wouldn't make a difference. Or it means depending on a framework that may change with each version new, breaking all the code of your users because i'm pretty sure you won't be maintaining old versions of ionic for long.
Don't break interfaces, that's what made Linux popular, that's what made js popular,jquery popular, even windows(until the modern ui fiasco)... Refactor but don't break. Eventually you people following angular demise will learn it the hard way.
That being said, Angular 2 is a big technical improvement and the changes required to support it aren't too burdensome. It will make Ionic apps faster (on mobile we can use any perf improvements we can get). We are going to work hard to not break interfaces as it pertains to the Ionic API.
What made JS popular is that it is the only language available to do client-side development in the browser.
Why I don't like the article:
* Very vague about actual issues and instead a lot of generalizations. Even the explanation article isn't very helpful.
* No real concrete code backing his examples.
* Generalization that having any logic in views is a bad thing. (ng-if and ng-hide is all you really need in a view and it isn't bad if used responsibly!)
Performance is a real concern and is one of the reasons we haven't ported a large legacy view to Angular, but I think we could solve this if we really saw value in porting it over at this point.
I don't want to come across as rude, but it seems strange that hiring a junior developer and introducing them to web development doesn't come with a guide on what to do or how to approach js. I don't quite understand how researching deep enough into Angular to find out about performance tweaks doesn't lead one to make a guide or tips for new hires. Sure, you can hope that they know what they are doing, but if you care enough to stop using a framework due to their bad habits it might be time to reflect and realize that the power given by a framework comes with more abilities and more pitfalls.
This trade off is clearly demonstrated when the author talks about the "pit[s]" that junior engineers fall into. They look at code and see it works for one use and just use it in the other case because they have seen it work. It isn't all their fault that they are "very good at copy and pasting" because nobody has told them the steps to guide their code structure. I appreciate the author for sharing his views but it seems like it would be helpful to provide the list of pitfalls and ways to avoid them to his juniors instead of disliking frameworks.
It's also got nothing to do with the juniors coming from Python or Ruby, in fact most of mine started on Java and Erlang or are self taught, but I've had very little trouble with bad habits creeping in to projects with those same juniors when using frameworks like backbone, ember and react (so far) - so once again, it has very little to do with pitfalls in JavaScript and more to do with pitfalls in Angular itself - at least, that has been the case IME.
I ask because this post is a bit light on details and feels a bit angry to me. I'm not a front-end developer, but our dev team has not complained about Angular and I'm wondering if I'm missing something.
I really love the structure Angular brought to our front-end softwares. At some point, we may include React to optimize the rendering of our realtime dashboard.
Angular ain't perfect, but it's still pretty damn good.
"The very fact that an article exists which prescribes that you should be mindful of the order in which you write your HTML attributes in Angular to optimize performance and other quirks is staggering."
No, the article linked to in support of this statement is talking about readability. Angular directives have a priority attribute that determines the order they're evaluated in.
Hating on Angular is just a trendy thing right now.
Sure, Angular has its flaws & quirks, just like any framework. But it gets so many things right that it's worth sticking with it, IMHO.
- I can chuck away my angular 1.x knowledge, since Angular 2.0 is going to be completely different than 1.x (like Django and Node)
- Directives are such a pain to write, test, maintain, compose and reuse
- Doesn't scale (writing and debugging very complex app)
and also
- I had to dig deep down into internals to get how something works
- Angular has very step learning curve
- Harder to write isomorphic app
Having said that, Angular is an enormous improvement comparing to jQuery. If you start a new project, evaluate all options and pick what works best for you.
Angular is still, by far, the best framework I have ever used. I have zero regrets about choosing it.
This post reflects the pathological nonsense that pervades certain quarters of front-end development. It demonstrates the following fallacies:
1. If a technology has any flaws, they render the whole thing worthless.
2. New technologies that I haven't tried are probably perfect and won't require any hacks.
3. Kids these days aren't doing any real programming like we did back when we coded in Backbone / jQuery / Raw JS / VBScript / Java / C++ / COBOL / Assembly / Punch-cards.
4. Syntactic sugar and abstractions are inherently bad, whereas writing a lot of boilerplate code is good for the soul.
5. Someone I respect doesn't like something, so I shouldn't like it either.
6. Old, widely deployed technologies are over-complicated, because people have built more complex systems with them than with new technologies, and thus have been forced to tackle more complex requirements.
7. I have worked with this technology for a while, and built up a corpus of specialist knowledge and hacks, therefore it is more flawed and than these newer technologies, which I haven't worked with and therefore only understand in a shallow way, and therefore seem simpler.
8. Acquiring specialist knowledge is bad, and not the reason I am paid to do what I do.
I've strongly disliked angular as long as I've been able to code. On the other hand, I like react a lot even though it has a similar learning curve. React may have strange and unfamiliar concepts, but they are actually new concepts in ui development that make things less error prone, very performant, and cross platform.
If the angular team was not funded by Google, I doubt any of them would be working on it any more. Actually, with angular 2, that's the case anyway.
If you don't like dom-diffing frameworks, maybe check out vuejs. This is an observable framework like angular, but it's performance is acceptable and its api is very clean and makes sense.
• If a technology has flaws, that does not render the whole thing worthless.
• New technologies that you haven’t tried are not perfect, and will still require hacks.
• You have worked with some technology for a while, and built up a corpus of specialist knowledge and hacks. That does not necessarily mean that it is more flawed than some newer technology that seems simpler. That apparent simplicity is probably just because you haven’t worked with it and therefore only understand it in a shallow way.
• Old, widely deployed technologies are not over-complicated. It just seems that way because people have built more complex systems with them than with new technologies, and thus have been forced to tackle more complex requirements.
• Acquiring specialist knowledge is not bad – it is the reason you are paid to do what you do.
I like using Angular relative to Backbone and Ember, although my experience with Ember was last a year ago, and the framework has progressed a lot since then. I like React over Angular 1 currently, especially since it supports robust server-side rendering solutions. React takes some ideas from Angular such as not being opinionated with the models, but makes writing the core of its components much nicer than Angular 1's directives. It also does not take much opinions over the service architecture, which also makes me happy, but the tradeoff is that it leaves a lot of developers in the dark as far as how to organize code with it - that is why Facebook pushed the Flux pattern very strongly.
Angular 2 definitely took a lot of React's good points and integrated them in better ways into Angular 2, or have plans to integrate them. Ideas such as supporting immutable data, virtual DOM (well, at least something similar to virtual DOM anyhow), and unidirectional data flow make their way into Angular 2. Robust dependency injection (no more using $inject or the hacky array syntax for DI) and better API for creating components come as more evolutionary changes from Angular 1. The declarative templates are also a lot simpler, as expression support is more limited than the broad JavaScript-like syntax supported in Angular 1. Shadow DOM being a first class citizen of the framework makes having to worry about component CSS being clobbered a problem of yesterday.
Overall, I am excited as a frontend developer - there are a lot of exciting things happening in the frontend world, and the ecosystem is maturing by leaps and bounds.
While working professionally, my team lead chosen Ember.JS.
Anyway, in general Angular have a very different way to do thing and you basically create html element and the js will defined the html behavior.
In general, I think the announcement of Angular 2 have slowed down the momentum of 1.0 very much. Angular 2 from what people have been saying is totally completely different from 1 and it could be name something else and noone could tell it's an angular framework from 1.
With all the js front end framework out there, I think it's too wild west and I rather let this area mature much more before choosing one. Unless you can afford to rewrite frontend code every few years... I'd stick with backend rendering web pages, plus it's SEO friendly.
https://github.com/johnpapa/angular-styleguide
I haven't had any beef with Angular so far, and really enjoy working with it. But I understand that one size doesn't fit all.
Its true in C++/Java/C#, but less so in JS, Ruby, etc. If you can change what a dependency refers to without using injection, as you generally can in the fact namuc languages, injection is less useful.
// foo.js
var request = require('request');
module.exports = function (url) {
request.get(url, function (err, body) {
// ... business logic here.
});
}
Now consider another example:
// injected.js
module.exports = function (request) {
return function (url) {
request.get(url, callback);
}
}
I'm kinda pissed with Angular too, to be honest. I agree with the author that there were some pretty bad ideas in there, and it grew in popularity so quickly that a lot of people are going to be dealing with those problems for a while. Personally, I left the job I was speaking of earlier in this post, and I don't use all-consuming frameworks like that anymore. Whatever work they save you in the beginning becomes a prison sentence later on when you're forced to do things their way.
As everyone is learning, no project is really "typical" and so much is up to personal taste, chances are we won't see a case study of a project in various stages. Ideally the author of such a study would describe clearly just when the framework clicked for him, and when it became a burden. Just what code is so cumbersome it's never fun to work with? What feature was rejected due to performance concerns?
All we can do is read those articles and, going meta, keep track of the frequency and sigificance of these articles and get an idea where the hype train is going...
I love doing web development, but parts of web programming suck. Therefore, there's going to be parts in every web framework that suck.
I find that being a fanboy for any framework is unhealthy. So is being a hater. It has good parts & bad parts. This article seems uninformed. There is a lack of Angular specific terminology. Most of the criticisms may in fact be valid, but are not backed up or explained. The author also recommends alternatives then goes on to imply he has not yet "taken these for a spin". I feel the author may be talking about stuff he doesn't have enough experience with.
I won't tell you Angular is the best framework, or that it is good or bad. I will advise you to ignore articles like this & try it out for yourself.
Try Meteor[1].
Over the past few years using things like Angular, mithril[2], React[3], Vue[4] Meteor, and Ember[5] for large production sites, I've found Meteor painstakingly easy to quickly build real-time "isomorphic" web applications. If you haven't tried it and you're thinking about creating an app with a FRP[6] app I recommend giving it a whirl.
[2] https://lhorie.github.io/mithril
[4] http://vuejs.org
[6] https://gist.github.com/staltz/868e7e9bc2a7b8c1f754
Edit: Fix spacing
Regarding to MongoDB, the Postgres option is in the pipeline.
[1] Also it didn't support postgres.
It doesn't seem designed for large complex things though. Postgres support is on the way. I've been playing with it and trying to implement uploading profile pictures and that's quite hard. The standard thing in Meteor seems to be to offload the job to someone else's server probably running PHP. It's fun to use, I recommend playing about and trying to build something.
Josh Owen's talk is quite good on the business case for it. His company has built 40 apps using it, he says they tend to take about 6 weeks vs 10 for Rails.
What I'd like more than anything else is examples of substantial web apps written without a framework.
This is probably what they meant:
"Developers will move, I believe, from monolithic frameworks like Angular.js and Ember to a ‘pick n mix’ of small, dedicated libraries to mitigate the risk of churn"
Source: http://www.breck-mckye.com/blog/2014/12/the-state-of-javascr...
For every project and team, you [and the team] have the flexibility to choose the libraries that would be effective for said project. Thus, the ad-hoc framework would generally be different for every project.
In general, you [or the team] probably wouldn't re-invent the wheel, and you'll likely to find a decent library on npm.
Take this basic idea of what an app does (I use code in this context to mean js that was written by you.)
Input -> The code -> Output
Frameworks: The code exists in all three areas, resulting in having to change all three areas of the code instead of one.
Libraries: The code exists separate of the input and output, allowing one to make changes to any of the three areas without having to change much (if anything) in the way the code works. This (in theory and usually in practice) also makes testing easier to develop even if the code wasn't designed with testing in mind.
So, there are frameworks and there are libraries. With a framework, you use the structure provided by the framework, and hook pieces of your code into it; with a library, you structure your code to your problem, and use libraries to provide functionality.
Frameworks are generally easier to get started with: they provide a lot, and their pieces generally work well together. But inevitably, the day will come when you need to do something not envisioned by your framework, and then you're stuck: it can be arbitrarily difficult, painful and/or low-performance to do what you need. That last point is also worth mentioning: because a framework tries to be good at providing the same structure for a lot of different problems, it inevitably is a jack of all trades and a master of none. This can end up meaning poor performance, due to needing to call lots of functions to do simple things (imagine some hellacious Java framework with AbstractFactoryVisitorSingletons), or it can be a pain on the programmer, or both.
Meanwhile, libraries are just that…libraries of code that the programmer can use to implement needed functionality. How he stitches them together is up to him.
With a framework, your code lives within someone else's structure; using libraries, other people's code is called by yours.
'How are things structured?' However you want!
Read http://tom.lokhorst.eu/2010/09/why-libraries-are-better-than... for more, and http://www.evanjones.ca/frameworks-necessary-for-large-scale... for an opposing view.
I've found that ensuring functionality is locked into tiny angular modules and proper project structuring makes working with the framework a complete breeze. The testing framework that is inbuilt is mega handy too.
That said, the ending conclusion that we should be wary to jump on the Angular bandwagon is not unfounded. I'm a bit wary, however, of Ampersand since it looks a LOT like Ember, and well... I'd just use Ember if I wanted that.
Aurelia looks quite promising. There's not a lot of info out there about it, so I doubt a lot of people will start jumping the Angular ship just yet, but it's something interesting to keep an eye on.
One reason is the obvious one. The more people who use something, the bigger the population with something to complain about. And the bigger audience to write for.
I also think there is a tipping point when something gets so established that people are told to use it.
I tried ember.js as well, but it wasn't my cup of tea. I wouldn't go so far as to recommend people avoid Ember because I didn't like it, unlike this post has done.
Just because X isn't a good fit for you doesn't mean that it's a "Bad Thing". And just because X is great for you doesn't mean that it's a "Great Thing". We have so many options because there are tradeoffs for all of them.
For those bemoaning the fact that I was hating on junior devs - I wasn't - and I explain that in a separate article linked to from the post, so it may help clarify those points. I also give more concrete examples in that follow-up post because a lot of comments said I was being too vague in this post - which to a certain extent I agree with, but it was never my intention to write a book or a manual. If someone is genuinely interested in more depth to some of my reasoning, I'm happy to be contacted about it with specific questions and we can go more in depth. Doing that in the post would have lost more readers than it gained so for me it was a balance for an already long article.
The bottom line for me, is that it's been far easier to get junior devs going in frameworks like backbone, ampersand, durandal (aurelia now) and react than it has been with angular and I've seen less bad habits forming. For me those are facts in my day job - but your mileage may vary.
scrolls
...where is it...
scrolls some more
...ah, there it is.
I my experience AngularJS works well with quality teams who come into the Javascript ecosystem with a front-end / design / HTML background. They get the markup-based systems; it's less of a leap. I can think of one team in particular who had a horrible time with Ember, but took to Angular very quickly.
The application speed thing, I think, is non-issue now that people have figured it out and written a lot on the topic. There are a lot of good articles out there that explain very clearly how not to write slow AngularJS applications. I even wrote one myself back a ways:
https://www.exratione.com/2013/12/considering-speed-and-slow...
There are definitely other issues worthy of attention, such as learning why you don't factor your application into directives everywhere, learning to avoid all the normal global variable issues with $scope, and the very mixed quality of the documentation - sometimes good, sometimes encouraging outright bad design choices, sometimes lacking very necessary detail.
When you release first, you get valuable feedback from early adopters and you get an opportunity to add finishing touches without upsetting too many users.
When you announce first, you are effectively labeling your current release as stale/outdated and no one wants to build a new project on legacy technology!
As for AngularJS itself; I think it's fine structurally. I don't find it too 'monolithic' - I think it strikes a good balance.
You could use something more modular (single purpose) like React, but then you'd end up building a whole custom framework on top of it (made up of a large range of small libraries) to handle things like routing and data/validation layer, etc... Is using your own custom framework (made up of so many small <and potentially less than compatible> open source components) really better than using a single cohesive solution which is maintained externally (for free) by the open source community?
In my book, Angular (when used with Yeoman's generator-angular-fullstack) is a high-productivity tool that immediately generates a fully functional, well structured MEAN application that's very easy to extend. You get something useful running in less than an hour. That's perfect for prototypes and internal enterprise apps where productivity is more valuable than performance or SEO.
OTOH if you're working on a big web app that will take months to develop, you might as well spend more time building the foundation, and also choose a framework that provides server-side rendering, high DOM performance and things like that.
IMO most of the bickering related to JavaScript frameworks is just people using them for different purposes, and one person assuming everybody else will use them for the same purpose as she does.
Directly followed by:
> Views and data-binding are a mess, and seriously degrade performance
Want to have your cake and eat it, too?
Angular 2.x does simplify things quite a bit and it also offers much better performance.
The problem is Angular is ALSO obviously a hack and makes a lot of things harder than they need to be. Oh well!
In any case though, it feels like all JavaScript frameworks out there are just trying to overcome fundamental weaknesses in JavaScript the language. At that point, I'd recommend looking into ClojureScript which is fundamentally a better language. I've recently started using ClojureScript + ReactJS + Om and it's been great so far.
Definitely would look into something else for my next project.
A framework can't stop people from writing bad code. With Angular (or any other framework) you need to build the object model independent from the controller and template. The dependency injection makes this really easy. Then you've got logic that can be tested in plain unit tests and only a couple objects assigned to the scope (the roots of larger object graphs).
Angular will make a lot of calls to the backend, but in general you can not look at your Angular code and figure out where all the calls are going to the backend. Complex URLs are often assembled from diverse variables that are stored in varied locations. You can not grep for an URL because it does not exist as a string. There is no equivalent to the "rake routes" command -- no way to find out what routes Angular might use. I found myself opening the dev console on FireFox and watching what Ajax commands were issued while the pages loaded and operated -- which is a fine way to track down a call that is working, but if a call isn't working, then it won't show up in the dev console, and you are left trying to track it down.
There might be some structure or conventions that would allow us to find the problem when facing a bug in our Angular code, but so far we have not found it.
Why? Can't imagine why you can't look at code of your services and figure out where is URL.
I search criticism to make it better.
I tried using straight web components with the polyfills; it gets kinda messy compared to something more polished as Polymer. I assume it's the same deal with Aurelia.
1. Doesn't play well with jquery.
Digest cycles and event passing don't mix. With any significant jquery plugin you end up with $timeout(0) hacks (with or without the jquery being wrapped in a directive). Since jQuery is the foundation of pretty much everything, this is a torpedo that sinks the battleship. In addition, pulling in jQuery plugins (awesome ones!) requires a major hackathon of wrapping the code in a directive, figuring out why the events are always triggering, then throwing some $timeout(0) hacks in there. ship it!
2. No concept of M (model) in MVC/MVVC/MTV/M??
Data in the directives, data in the controllers, data in the services. oh my! Once your app reaches a certain complexity you'll be doing WTF's as to where a $scope.variable is actually being defined. (Oh i see it was defined in a controller inside a directive that was inserted into the DOM dynamically via a controller!?...)
3. When things go wrong you have to dig too deep
Want to make a recursive directive? Good luck reading the docs on the $compile phase. There are too many times that when something goes wrong with angular, you end up in a deep well of tears trying to figure out why it's not working. This creates a productivity problem.
Minor issues I have with angular:
1. DOM pollution
old schoolers see adding non-standard tags in the HTML as 'code smell' for the same reason that we no longer do 'onclick=alert('hi')'. Part of the reason that this stuff was replaced with $('id').click() was that it created tight coupling between the HTML and the dynamic code. By inserting non-standard tags into HTML which requires the use of a 'compiler' you are no longer separating the concerns of 'presentation', 'structure' and 'dynamic code'. I personally find it distasteful, however, I can live with it (like a stinky roommate).
2. Slow unit testing
One of the most touted features of angular is it's testability. However, 1) virtually every angular component out there has no unit tests and 2) testing directives and mocking out features is so time consuming that it brings development to a crawl. I find that the mix of time spent on testing vs coding is 50/50. That is that for 1 day of coding you'll put in a full day of writing unit tests. The reason is that testing angular is so complicated that it takes that long to get it right. Unit tests are always a good time investment, and that investment is not 0. However, if feel that a 50/50 ratio is too high. Testing should be faster to allow devs to be more productive.
3. Performance is easy to screw up
Reading some of the other comments I realized another minor issue. Performance in angular is great. However, because angular doesn't have any real organized (or patterned) way to create an app (you can make a controller or have a controller in a directive), you end in a situation where the way you have organized your code now creates performance problems. This is true in any framework and with some training can be avoided. However, it appears that the critical mass for this issue comes much sooner than expected due to the perl-like anything goes feel to application structure.
Here we go, another condescending, arrogant developer on his soap-box. Do you know why Junior developers like Angular? Because it is quick, intuitive, and you can rapidly release, just in the same way PHP and Ruby are. Are you building applications for the sake of building them, or building something users will use and love?
See: https://s3.amazonaws.com/m.helpscout.net/blog/2014/feb/devs-...
Sometimes the choices made presumes a specific application is built and then a junior developer over-commits to the current state of a dynamic application and thereby precludes the application from easy future repurposing to match the dynamics of the actual products intent.
What do I mean by that? You can call this "concreting the abstractions". The abstractions given by frameworks have to be implemented in a concrete manner in order to build the application - duh.
But then what you often get are ill-equipped abstractions layered on top (square peg in round hole syndrome) and then the concrete implementation on top of that.
Then the rug gets pulled out from underneath that.
The naivete of a Junior Anything is a lack of perception of the nuances of the craft - an ignorance of the consequences of actions - and the wisdom to have the right kind of deductive minimal execution to get from objective to actualization.
All too often, the frameworks give you a bag of hammers and say "alright, figure it out". With This approach, the limits of excellence are quite low.
This matters for the long term with the customers ... you want them ecstatic and to follow you in a near cult-like fashion --- not just merely shrugging their shoulders and cocking their head sideways as they abuse the product in a disenchanted ritual.
Anyone can do that. There's no beauty or value there - and it's not how you create a following. There is a meaning to art and mastery - when you do it right, everyone gets it.
It's the unquantifiable quality that Robert M Pirsig discusses in Zen and The Art of Motorcycle Maintenance, or what Tim Leberecht talks about in the Business Romantic. These things matter - otherwise we are all soulless hacks.
and yes, I'm not polite and it's intended. Haters deserve to be hated.