I find myself liking almost every one of these articles that talks about how "you shouldn't use popular JavaScript framework X because <list of reasons why>" a little too much.
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.
IME, this tends to be a problem with frameworks in general: the goal, after all, is essentially to create a new platform on which to build, but that implicitly invalidates a whole lot of knowledge your potential users have of the underlying platform.
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.
Totally agree. Honestly I find the level of noise around JS frameworks to be insane. It's really not that hard to roll your own framework out of a couple simple libraries, which lets you write something perfectly tailored to your own requirements, that doesn't do a bunch of extra junk under the hood that you don't need. Unfortunately this approach doesn't have its own corporate hype machine (and why would it?) so it's usually completely missing from the conversation.
I agree that the best way is to use "just JavaScript" - crazy idea, right?! :)
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.
That is why the only framework I use is Backbone - and only as a router. It says here are your event, njoy.
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.
There seems to be an approaching "framework overload" point where javascript (at least frameworks) will suffer some backlash and begin to push people away from them. It happened before with java and ruby for a time.
We've been working on the next version of Ionic with Angular 2, and I've been really impressed by it. No more two-way data binding and going crazy with ngModel, scope oddities are gone, etc. Scope is replaced by component instance data, and controllers by component constructors and methods, just like it should be! Building components is a lot easier than directives, and they can be extended and composed in a more OO fashion. It's way more accessible and easier to learn than v1 was.
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.
Agreed on this on all counts, as a current consumer of Ionic v1 and having used Angular intensely for the past 2 1/2 years. I'm also looking forward to using Ionic 2, I know you guys have been hard at work on it and I believe Drifty will come up with something far more awesome than Ionic 1 with the better API & design available in Angular 2.
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).
> So, obviously we are heavily invested in Angular
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.
So I am thinking about learning Angular for the sole purpose of using Ionic with my Cordova apps. Does it make sense to learn Angular 1.X now or is it close enough that I should try and learn Angular 2.0?
This seems slightly sensational to me. I thought maybe it was because the author would view me as Junior, but then I saw his other post and it just doesn't apply at all. In fact, I felt even more strongly after reading his explanation article.
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!)
I've only been served well by Angular. I find it's flexibility to be exceptional, and has blended almost perfectly with our Rails pipeline and API. We have a pretty large codebase with it and integration with legacy javascript. It just works.
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.
A lot of the post has more to do with js itself. The author talks about performance, but never addresses the fact that most juniors probably started in Python or Ruby. They didn't have to care about doing things the most efficient way, and could probably just use a framework to do what they wanted to do without caring about implementation. This lack of concern is not rectified by any of the senior engineers, and only appears once they are required to do something outside of a framework that provides decent performance.
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.
For those folks who have used Angular in major projects, but also have experience with other frameworks, what do you think?
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 have been using Angular for the past two years as the primary front-end dev in a start-up. Prior to that I spent ten years doing web development, both back-end and front-end, with a wide variety of libraries and frameworks.
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.
Overall, I like what Angular v1 does and how easy it is to be productive in it - I have helped save multiple companies' products (medium-sized codebases) because Angular can be extremely quick to iterate on top of and gives you so many tools for that productivity, while unit testing much of it (although the unit testing situation is not quite perfect).
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.
I've been using Angular 1.x for a year in various projects. After that I came to conclusion that for my side project I will use React. Main reason is React is better than Angular 1.x and Angular 2.0 is not ready. Cons:
- 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.
I built reasonably thick client projects with jQuery and a home grown system before moving to Angular and it's been a godsend. I've not done anything significant in the other major frameworks and it looks like there's some genuine innovation in React for people that don't mind the IP issue. But... I just don't know where guys like the author are coming from.
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.
I love angular 1.x but can't recommend it given how its team is ready to break everything to follow the latest fads of javascript development. I want something stable,not something that will drastically change with each version. I certainly don't want something "for the future" that requires an asset pipeline because ES6 is "cooler". Truth is, I love angular first and foremost for its dependency injection, but since I wrote my own container, I will probably ditch it,sooner or later.
I have used Angular in a major project and can say most problems go away if you AND your team follow something like the AngularJS Style Guide early on:
A little over a year ago I got roped into using Angular, I was put on a team that had built an Angular app and needed a bunch of features added before it shipped. I learned a lot about it in a short time and came to really dislike the way apps get built with it. It makes it hard to program things "outside" Angular so it ends up consuming everything. Views and scope are a disaster. Dirty-checking was a bad idea that killed the performance of our app. There are just so many damn concepts everywhere! It's overcomplicated and slow.
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.
We use Angular over at zenginehq.com. Not only did we build an entire business process management platform on top of it; we even exposed a JS plugin architecture that allows developers to create Angular plugins on top of the platform. Really cool stuff.
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 used Angular to build keymetrics.io and it works like a charm.
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.
2.0 is very valid. They let it loose and a few devs, including myself have put off fully investing in Angular 1.0. I was investing in Angular 1.0 until this happen.
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.
Another one of those articles :-) The author feels the pulse of a javascript framework's culture. Watches versions, core developers and his own feelings about it all. Career opportunities and sunk learning costs are at stake.
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...
No web framework is perfect. I do dislike parts of Angular, for example silently ignoring unrecognized directives.
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.
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.
Meteor is not just a web framework which many actually want. I can't just build a new frontend for my existing Django application with Meteor can I? Meteor is server & client with also a lock on Mongodb.
I was looking at Meteor a year ago and didn't think it was production-ready enough to recommend our company to build its next platform on[1]. What is the story now?
I really don't get what people mean when they say they're against frameworks. Your app that you're making with no framework...how are things structured? Do you just repeat yourself everywhere? Or do you really have a pseudo-framework that's implicit in the conventions that you use?
What I'd like more than anything else is examples of substantial web apps written without a framework.
As someone who has worked extensively with Ember and Angular in large projects, I'd say that I prefer Angular even though I know the current version will be deprecated.
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.
The main difference between Ampersand and Ember is that Ampersand has embraced npm and does not require you to find a way to fit the problem at hand into the framework. For example, at work we have an app that only uses the domain layer (collections and models) from Ampersand and uses React for the view layer. Ampersand has embraced the library concept and is not really a framework at all.
The most popular technologies always get the most complaints. You can almost use the hate volume to measure what the best technology of the day is (I said almost).
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've used Angular for a big project before and had no issues with it. In fact, it's one of the most productive frameworks that I've used.
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.
I just started using ngReact https://github.com/davidchang/ngReact.
I replaced the main ng repeaters in the app with react jsx lists and the performance improvements are noticeable even on lists that are not long (15 items) with lots of ng binds. This needs to be built into angular by default period and the integration could be improved significantly. Also filters are horribly slow and need to be fixed or not used in views at all.
Wow, didn't expect the varied responses to my article, but glad to see it's opened up some good criticism of Angular itself, and of course my own reasoning in the post. Always good to get balanced opinion, and the only reason I put something like this out in the public domain is to get that feedback - maybe there's something huge I'm missing and others with experience can help. I've been in this web programming game for 20 years now and if there's one thing I've learned, is you're never too old (or experienced) to learn something new.
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.
I don't exactly love Angular either (though I do use it), but you can criticize it without descending to outright misrepresentation, as with the claim that you have to order view directives in a particular way or things break. That's totally untrue, and the article linked in support of the claim doesn't say anything of the sort -- it's just some random guy explaining how he orders his directives and why.
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:
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.
I think it was a huge mistake to announce Angular 2.0 so long before its release date. In the open source world, you should aim to release the product BEFORE you even announce its existence, not the other way around!
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?
What is the framework you hate the most? The one I am using right now! AngularJS has been a love and hate, feature and bug library in my stack. Many times I tried to run away.. I tried Rivets (easy but a pain to do binding), React, looks promising but needs some serious investment, Ractive, cant even remember what I didnt like.. oh well..
Angular.js should be considered a tool that solves certain problems well and some other problems less well.
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.
With free Windows 10 around, dismissing older browsers MIGHT be more realistic than today. Then we only have the Android 2.xx legacy to deal with. XP users have absolutely no excuse.
Totally unrelated, but I don't think XP still used because customers don't want to spend money on upgrade. More likely because some part of their business tied to technology which tied with some XP components.
[+] [-] BinaryIdiot|11 years ago|reply
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.
[+] [-] Shog9|11 years ago|reply
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.
[+] [-] andrewchilds|11 years ago|reply
[+] [-] serve_yay|11 years ago|reply
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.
[+] [-] venomsnake|11 years ago|reply
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.
[+] [-] hcarvalhoalves|11 years ago|reply
[+] [-] geuis|11 years ago|reply
[+] [-] mhuffman|11 years ago|reply
[+] [-] yesimahuman|11 years ago|reply
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/)
[+] [-] Bahamut|11 years ago|reply
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).
[+] [-] gkoberger|11 years ago|reply
[+] [-] aikah|11 years ago|reply
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.
[+] [-] icpmacdo|11 years ago|reply
[+] [-] sb8244|11 years ago|reply
Why I don't like the article:
I've only been served well by Angular. I find it's flexibility to be exceptional, and has blended almost perfectly with our Rails pipeline and API. We have a pretty large codebase with it and integration with legacy javascript. It just works.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.
[+] [-] zarriak|11 years ago|reply
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.
[+] [-] cl42|11 years ago|reply
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.
[+] [-] stupidcar|11 years ago|reply
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.
[+] [-] Bahamut|11 years ago|reply
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.
[+] [-] lukasm|11 years ago|reply
- 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.
[+] [-] cheriot|11 years ago|reply
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.
[+] [-] aikah|11 years ago|reply
[+] [-] lobo_tuerto|11 years ago|reply
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.
[+] [-] serve_yay|11 years ago|reply
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.
[+] [-] anthonyp|11 years ago|reply
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.
[+] [-] sassyalex|11 years ago|reply
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.
[+] [-] digitalzombie|11 years ago|reply
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.
[+] [-] UweSchmidt|11 years ago|reply
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...
[+] [-] joshribakoff|11 years ago|reply
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.
[+] [-] dyscrete|11 years ago|reply
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.
[1] http://meteor.com
[2] https://lhorie.github.io/mithril
[3] http://reactjs.org
[4] http://vuejs.org
[5] http://emberjs.com
[6] https://gist.github.com/staltz/868e7e9bc2a7b8c1f754
Edit: Fix spacing
[+] [-] ciokan|11 years ago|reply
[+] [-] meric|11 years ago|reply
[1] Also it didn't support postgres.
[+] [-] hyperpape|11 years ago|reply
What I'd like more than anything else is examples of substantial web apps written without a framework.
[+] [-] deif|11 years ago|reply
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.
[+] [-] modnine|11 years ago|reply
[+] [-] BurningFrog|11 years ago|reply
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.
[+] [-] mmastrac|11 years ago|reply
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.
[+] [-] dude3|11 years ago|reply
[+] [-] Bahamut|11 years ago|reply
[+] [-] EugeneOZ|11 years ago|reply
[+] [-] EugeneOZ|11 years ago|reply
[+] [-] robertthegrey|11 years ago|reply
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.
[+] [-] collypops|11 years ago|reply
scrolls
...where is it...
scrolls some more
...ah, there it is.
[+] [-] aaronem|11 years ago|reply
[+] [-] exratione|11 years ago|reply
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.
[+] [-] jonpress|11 years ago|reply
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?
[+] [-] dazhbog|11 years ago|reply
[+] [-] kennu|11 years ago|reply
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.
[+] [-] UnoriginalGuy|11 years ago|reply
[+] [-] hippich|11 years ago|reply
[+] [-] BinaryIdiot|11 years ago|reply