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.
good point, but a sunk cost. New programmers, such as young* developers learning front-end architectures for the first time, never learned all of the underlying platform. So they can spend the next ten hours achieving x amount of progress in pure javascript, or y amount of progress coding atop a framework.
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.
That only works if the framework actually does work as a complete platform, though - that is, if you can get away with forgetting (or never learning) the underlying platform once. To go back to Angular, it would mean forgetting all about the non-Angular-friendly parts of the DOM, events, etc. and never needing to use them again.
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...
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.
> 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.
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.
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.
I hadn't thought about including it in my profile so I went ahead and updated it. Thanks!
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.
I think its fine. From time to time a question or comment will come up related to something I've done. I've never had anyone complain about it. Usually people are happy to hear about possible solutions to a problem they're having.
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).
Right now, it's event driven: input triggers an event, event is handled in component, component state is updated. For the one-way case (that I think is pretty awesome): a zone is set up in the component to detect changes locally in the component (even changes in setTimeout) and update the components template only.
I think there's room for a 2-way like wrapper for the common input use-case (ala ngModel). Still digging in though.
> 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.
Though your comment is overly dramatic, I agree to an extent. Ionic "transcended" angular to the point that a lot of new Ionic devs learn Angular through Ionic.
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.
Mark my words, you don't need Angular but you're now taking a risk with each version of a product you don't even need at first place.The time spent rewriting your entire framework is some time not spend writing new features for the current one.
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?
I think it makes sense to learn v1 right now, mainly because with 1.3 and 1.4, the delta between Angular 1 and 2 is shrinking.
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).
Note: a lot of of the Ionic components (as mark up) won't be changing.
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.
I disagree - most of this post I wrote has very little to do with JavaScript itself and everything to do with Angular. Likewise, I don't want to come across as rude, but I also don't want words put in my mouth. The performance issues with Angular are not fiction, they are very real concerns. Hence the sheer number of tutorials popping up lately showing you how to use React in your Angular apps to improved the rendering performance plus a number of other hacks I'd prefer my juniors steer clear of.
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.
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.
Good points, but angular has the very real drawback of useless terminology (transclude?) and a lot of wheel-reinvention (the several strange types of components). It's a pretty standard observable framework dressed up with a bunch of unnecessary hocus pocus (and pretty bad performance).
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.
9 years checking in. Front and back end. Previously spent 1.3 years working on a behemoth of an Angular app for a corporate client. No complaints. Agree with your analysis of the article.
Good identification of some common fallacies and misconceptions. If anyone finds the fallacies hard to read, here are restatements of some of them as straight advice:
• 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.
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.
Thanks for the link, I have never seen this article before and it is resonating with me quite strongly. Although I like the NodeJS library for what they have achieved there. I really don't like having to use javascript on the server side. I guess it is down to personal preferences as far as I am concerned.
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.
That is not actually all that true in JS, or generally any languages where without static types or classes that aren't duck-typed objects themselves.
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.
It's not so much about duck typing, as it is about private/public variables and how they relate to a module's interface. `require`d modules are essentially private in Javascript. Consider the following:
// foo.js
var request = require('request');
module.exports = function (url) {
request.get(url, function (err, body) {
// ... business logic here.
});
}
Here, if one wanted to test the actual business logic (without implicitly testing the request module as well), one would have to refactor the code such that the callback is somehow exposed to the test suite. Additionally, one would not be able to run such tests in isolation (i.e. without an internet connection), and the test speed would depend on network latency.
Now consider another example:
// injected.js
module.exports = function (request) {
return function (url) {
request.get(url, callback);
}
}
In this version, the request library is taken as an argument to the module and thus can have a mocked version injected for testing purposes.
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.
Of course not. Meteor is not a frontend framework that will fit yor X backend. Meteor is an Isomorphic Environment that, by the way, rocks if you have the freedom to choose it. Completely different things.
Regarding to MongoDB, the Postgres option is in the pipeline.
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?
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.
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.
"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"
I should've pre-empted this, but I didn't. If you're gluing libraries together, it seems like you're sort of creating an ad-hoc framework. Is the difference just that you're making it up as you go along and you're not creating something that attempts the same kind of generality?
A major advantage to putting libraries together is making the code that is able to be the glue between the different libraries. It usually is the part that defines the structure of the app overall, allowing you create solutions to your needs that are not available to you in large frameworks. You can implement the same things in Angular or Ember, but you will be sacrificing choices that will result in the problems present in the author's article. The inherent formulaic approach lends itself to extending the use of things that worked in the code base to places they shouldn't be. This is significantly decreased when you are handling the libraries, because they force you to think on a more fundamental level of the approach you need to take.
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.
The general philosophy is that you're not wasting time fighting against the [monolithic] framework. In addition, in practice, one size doesn't fit all.
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.
Shoutout for Ampersand.js which was mentioned in the article. The modularity is really nice for keeping things flexible so I can swap out parts as our app evolves.
> 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?
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.
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.
I didn't invest a whole lot of time reading about it, but when they ended support for XP a lot of whining was from business owners who either couldn't or were too cheap to upgrade.
I blame things like todomvc, which I think is great in spirit, but a huge menace in practice. It gives people false hope that framework x will solve all their ills. Any SPA that is more than trivial requires engineering skills. Additionally, it is likely that you'll be building said SPA with a team of developers who have varying skill levels. From my experience, a framework should provide a certain amount of level-setting (as opposed to something that is 100% custom) for new team members. However, there is nothing stopping people from putting data access logic in controllers or polluting the views with complex logic. Those sorts of mistakes can and will happen regardless of technology. The key is to pick the right technology for your team and the problem at hand and stick with it.
I used Angular for the first time recently building a little example demo based off a template that used Angular. It was so horrible to use in basically every way, however some of the concepts (as noted in this article) intrigued me. I would never use it again, but I do data-bindings are conceptually correct, in that the DOM should have dynamic properties. Right now you do that in jQuery or common JS by adding a class or ID and then binding manipulations to that class/id or element, but that's obviously a hack.
The problem is Angular is ALSO obviously a hack and makes a lot of things harder than they need to be. Oh well!
I used AngularJS a for a little while about a year ago. It made you feel like you're using a different programming language to overcome all the JavaScript shortcomings, which is probably a good thing.
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.
We use Angular on our application and I can't stand it. The only thing I like about it is how well testing is built in to the framework. Beyond that it is far too complicated. Once your project really grows and you've got a huge Angular codebase, with the sometimes inevitable rushed pace you need to work in at a company, it just becomes a disaster. "Scope" crap everywhere that you have no idea where to find what you're looking for.
Definitely would look into something else for my next project.
> "Scope" crap everywhere that you have no idea where to find what you're looking for.
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).
This is what I've run into on every Angular project I've been thrusted into. It goes from a somewhat decent separation to absolute chaos incredibly quickly. While that's the developer's fault I don't feel like Angular lends itself to extending and revising existing applications very easily.
The pain I've felt with Angular has been less about Angular itself and more about the way it integrates with the backend frameworks I've seen it used with. If the backend has a clean RESTful API, then Angular is not so painful. If the backend has a complicated structure, then I find myself wasting epic amounts of time trying to find templates, paths, etc.
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.
No, really, REST API services in Angular usually have path to endpoint written in the most top part of code (especially in $resource). So I really wonder how it's possible to hide API endpoint URI there.
This guy says he is thinking of using Aurelia instead. Aurelia mentions using web components. If I can use web components now the why do I need Aurelia?
Same reason you might use Polymer instead of raw web components: Polymer adds nice polyfills, binders and observers and overall nice helpers to make handling web components much easier than the raw standard.
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.
Using the DOM to keep state seems like a very smart trick to me. I liked that about Angular when I first started learning JS MV* frameworks. I didn't like the whole Angular way but I did copy that trick to my Backbone apps. I like to use what I find smart and mix it on my solutions. Next up on my list is virtual DOM.
I can share the pain. I have been using Angular for a long time now and I avoid it as hard as I can now these days because it is so painful to use. When you write Angular applications you're not writing Javascript you're writing decorated HTML. I have actually been building a production application in Rob's newer framework and Durandal successor: Aurelia. The thing I love about it is you're writing ES6 Javascript and using standards based features. I think we are reaching the point where we will see less decoration based abstractions and more of just plain old Javascript in future frameworks. Aurelia is just the beginning of what is to come. I have also been loving React.js + Flux, but Aurelia more so than React these days.
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.
>> Ask any junior developer who has used it briefly, and they’ll tell you that they absolutely love Angular. In this sense it’s like giving candy to a child.
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?
Sure, but I'm going to move myself into the line of fire by suggesting that some frameworks can encourage the development of bad habits and anti-patterns - especially those that prevent projects from being easily re-arrange-able in the future.
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.
lol, another one. People are free to use React, Angular, Ember, Backbone, Meteor, VanillaJS, even brainfuck. You don't like something - don't use it and calm down, stop being a bigot.
and yes, I'm not polite and it's intended. Haters deserve to be hated.
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.