>Many would not even see the problem here, and just as children don't know cars can hurt, juniors don't know just how destructive this anti-pattern can be to performance, separation of concerns and long term code base maintenance.
Yup, I don't get it. I guess not only am I eternally doomed to be a junior dev but also am being compared to a child, a monkey typing at a typewriter, but also someone who doesn't know JS at all. Feels good man.
Other than some horribly obtuse undefined checking, there's no explanation of what the problem is. The argument seems to be that the controller depends on $scope. I... I thought that was the point. From the first line of documentation on controllers:
>In Angular, a Controller is a JavaScript constructor function that is used to augment the Angular Scope.
If the idea is that this is a bad habit to bring elsewhere, fine. Some more explanation would be nice, but whatever. But the implication is that this is a trap within the context of Angular dev itself.
This article only did one thing for me - demonstrate that the author himself doesn't understand Angular or the problems. I don't know Angular that well myself, but the author knew anything more than I did, he'd be able to spend the extra 30 seconds to write the refactored code.
Dismiss this article. It's a waste of time and energy. In fact, I really shouldn't even be wasting my time commenting on it.
Ad hominem. I can't really comment on the article itself since I don't understand anything about Angular, but let's do our best not to just throw a bunch of random stuff at the wall and hope something sticks just to justify our lack of understanding of the author's point.
I agree completely. You wouldn't do this any ANY language let alone Angular. However, I get he is trying to make a point that junior developers are using the $scope too trivially therefore causing slow performances, but this can be easily overcome by just incorporating better conventions into your codebase.
I don't know Angular at all. But it appears that the example with $scope is not respecting the MVC design pattern. It's all been flattened and merged. The controller should only update the model. And the view should only get state from the model. In the example, the controller wraps the model and presents itself to the view as the model and controller. So now to write a test of the view, you can't just create some dummy model, you have to create a mocked up controller.
Well, there's a good reason why $scope and controllers will disappear with Angular 2.0. $scope is convenient, but also a massive source of problems. There's workarounds for those problems, but those workarounds wouldn't even be necessary if this aspect of Angular had been designed better.
Angular has some great stuff, and some really necessary ideas and principles that were sorely needed in Javascript. I love working with it, most of the time. But it also has some serious design errors.
I think anyone who knows Angular well would agree - it's a joy to work with, but it isn't perfect. Angular 2.0 is a step in the right direction in many ways.
This blog post is pretty horrid though.
I find myself moving more of my code into pure JS & borrowing concepts from languages like Java (interfaces, abstract classes, etc.) to increase agility in the event I want to move towards using a different library/framework. I gave a talk related to this idea of a frontend SOA about a week ago - here are the slides: http://slides.com/wesleycho/soa-angular
Totally. I like Angular a lot, and I'm not blind to its drawbacks. The code sample in the blog post has room for improvement, but I don't understand what he thinks it demonstrates. Yeah, it's a little weird that controllers don't expose their own functions, that instead you attach functions and data to the $scope. But if that's the way you do it Angular, I don't understand what makes it a bad habit to learn.
"Overuse of the eventing system ($watch, $emit, $broadcast) leading to performance problems and memory leaks and not realizing it or being able to debug it"
Blindly overusing most features in frameworks or libraries can cause performance problems. Which memory leaks?
"Writing Controllers and Directives that take dependencies which make them nearly impossible to test."
Doesn't dependencies in general make any code harder to test?
"Views that are heavily dosed with logic - but more on that later"
I certainly don't feel my views are dosed with logic? Which kind of 'logic' are you referring to here? Is there something preventing you from moving your logic outside of the view?
"Their first experience of DI is quite often that in Angular and it's horribly broken. Since the "patch" which fixed the minification issues, it's still really just a square peg in a round hole with woeful support for scope and lifetime and features which most DI gives you for free such as child containers. They end up hating DI and shy away from it on other projects."
This seems like wild speculation here, as well as not being very specific (how is it broken?). I'm sure DI in Angular could have been done in a more elegant way (I have no idea how), but I don't seem to run into any problems.
"Strange bugs that (when called over) have us all scratching our heads until one of use realizes - oh yeah, sorry we forgot to mention that pretty much everything passed around is global, and Directives etc. aren't namespaced, so I see what's happened - you've got a naming collision there"
Not sure what to respond here - you had a bug in your code and discovered it was due to naming collision. Do you run into this daily? I've run into 'strange bugs' or at least hard-to-diagnose bugs in almost every framework or library I've used.
None of these issues seem especially unique to Angular. I'm not saying Angular is a perfect framework, but my own experience have been mostly pleasant, and I don't feel that there is anything in particular in Angular vs. other frameworks or libraries that encourage bad behavior - juniors or seniors.
I can't disagree more with the author's assessment of Angular's dependency injection.
DI in Angular was the first time DI made sense to me. And it makes testing really staightforward: test the component you're on top of, mock and fake the rest. Lots of boilerplate, but no actual hassle.
iOS has the exact same situation for it's notifications framework (essentially, observer pattern).
From what I've seen, consistently across frameworks that support the pattern, that you need to de-register your listener before releasing it from memory.
Pretty funny to think, I'm a "junior" developer and even I know that you have great power, but also responsibility, in the observer pattern.
The page is not loading properly for me (on a Windows laptop with Chrome). When I use the given link I get "500 - InternalServerError Something went horribly, horribly wrong while servicing your request. We're sorry :-(" and when I go via javascriptkicks.com it keeps loading and never completes.
After I turned off µBlock, it loaded alright(Chrome/OSX 10.8). I know a lot of people here love them an adblocker, so that might be the problem. It seems to be blocking a JSONP call somewhere, and thus the loader spins forever...
Might be a false positive on my part - between this and my phone, the thing is wildly inconsistent. Not sure this website is a great advert for the whole "everything should be a SPA otherwise you're a dinosaur" point of view...
There was a lot of commentary on my first post https://javascriptkicks.com/stories/2657 about not detailing enough why I think Angular isn't good for junior programmers asking for more detail. Here it is.
One of the big motivators for this follow-up post is due the the cries of FUD. Of course it's just my opinion, but I like to back my opinion up with facts if possible and it seems there were some questions cropping up around how much of a problem it geniunly is versus me just having a whine about it.
In all fairness I'm excited about Angular 2.0, but it's just too far off to quantify its use just yet. So it's not that I'm anti-Angular, I'm just anti-Crap, and there is a lot of that in the first incarnation I'm afraid, and it's biting too hard to ignore.
I hope my next post will be a lot more cheerful :)
I find it interesting that most negative Angular articles are so vague. Why is it so tough to articulate what is wrong with Angular? I agree Angular is not the best, but I don't have such strong negative feelings for it. I've used it successfully in the past and as long as you keep things simple and don't go overboard with all that it offers, you can create a decent website with it.
I wish I could go back in time and strongly oppose AngularJS at the last place I worked. Knowing what I know now, it was such a bad idea. I also made the mistake of adding it to a resume, too, so I have gotten too many recruiter emails about AngularJS jobs.
AngularJS has an amazing success/failure story. The developers have managed to get their technology used by so many web development teams whilst being extremely over-engineered and having a very steep learning curve. Why did so many of us get enamored with it in the first place? The power of Google?
The overengineering actually led to success, as it resulted in a batch of non-JS devs thinking that they had discovered some secret magic. They went on to write a bunch of blog posts, which made people think it was good.
Enabling non-JS devs to create a rich experience website (even if it has performance and future-proofing flexibility issues) is secret magic. Never underestimate the number of non-web engineers who desperately want to make browser-accessible frontends to their tools without having to learn the "hell" that is Javscript.
I strongly suspect people were writing those blog posts because Angular worked for them in a way that alternatives had not; I hear that's how things get popular sometimes.
I have the same feeling, except there was actually no debating it. Everyone used the phrase that Angular is the future of web development, even the back-end .NET people who only play with JS when the fancy strikes. Even the product people.
I didn't even try to mount a serious inquiry or evaluation - it was like an opinion steamroller. I really hated that feeling, but I was actually okay with the choice at the time because I wanted to learn Angular. I just remember being spooked by the total consensus that it was what we would use.
I don't think it does have a steep learning curve, really. I first tried it when I was a real greenhorn, having played around with backbone and ember and not really enjoyed the experience; with Angular you can be doing something cool in about 10 minutes.
The weird terminology almost helps, especially if you're coming from a server-framework background where your Ms, Vs and Cs are pretty different (due to the difference between request/response and UI design) from the same terms in a client-side framework. I am not going to confuse $scope with an ActiveRecord model. Most of it, in any case, works a bit like this (or did for me when I was very junior) - 'if it has a dollar in front of it, it does Magic Stuff with little or no human intervention.
No, the learning curve is very flat - until, as the OP says, you hit a brick wall.
All that said, IME it is possible to properly organise code in an Angular app, get logic out of views and so on. But it is dependent on you knowing a bit about application design. The easy option is to turn scope into a god object and have a 500 line spaghetti controller.
I was not part of the crowd that made this comment at the outset of the first article but I would say that the second article only confirms the suspicions of these readers.
Identifying a treacherous design pattern is one thing. To say that a particular pattern says one thing or another about the skill or scale of a particular developer is another. Especially in the land of Javascript frameworks where the flexibility to do and incorporate anything can be a serious poison pill.
I have worked on and lead two teams that implemented angular projects, on the first we moved into it as a group of relatively experienced developers. In the second we on-boarded a number of junior developers. My experience with the junior developers was that they took their queues pretty quickly from the work of the senior developers.
In particular I have never seen this particular pattern in our code. I have found that the tendency to want to break the angular paradigm with outside JavaScript or angular library injection overkill are much more common practices that we end up needing to spend time quashing.
I am not a web developer but I have been trying to keep up with the technology.
I tried learning Angular because people at work started using and hyping it beyond measure. So I thought 'ok' this got to be really good stuff.
And it was good, _if_ experienced people held my hand. Otherwise I got lost in a soup of what seemed like unnecessary terminology -- $scopes, controllers, digest cycles, dependency injections, directives, and so on.
It kind of brought back memories of first generations of Enterprise Java frameworks (you know the factoryfactorymanager joke...)
So I have seen Angular work easily for already experienced devs who knew web front-end development very well. For me, what I really like is React. Ever since watching Peter Hunt's video one or two years ago, the idea of the virtual DOM and how events propagate made sense and was small enough to fit in my brain. I was able to go through some tutorial and do a few toy project in my spare time.
Anyway, if you care for another data point, there it is.
I'm an experienced front-end developer and I spent some months working on an Angular app. My experience was much like yours - way too many concepts to contend with and an overall "enterprisey" feel. I also think the dirty-checking and digest cycle was a pretty serious mistake.
Unfortunately, that issue isn't limited to angular: it falls under the general category of "If you haven't gotten burned by the problems a pattern is trying to solve, a pattern looks like unnecessary complexity." I'm reminded of when I had to learn COM back in the day; as a developer who had cut their teeth on programming on Macintosh followed by Debian, it seemed like needless complexity until I grasped the zen of the problem it tried to solve: providing a common protocol for different binaries compiled by different C++ compilers to share data structures and do inter-process communication in an object-oriented fashion without sharing source code. COM seemed way too complex to me because (a) in the Mac world, there was only one compiler that mattered (at least by the time I got into it), so binary incompatibility was essentially a non-issue, and (b) in the Linux world, if you needed two modules to inter-operate, you could meld their source code together.
Similarly, if you haven't tried for 100% test coverage, dependency injection seems needlessly complicated, and if you haven't had to nest dozens of HTML templates written by different developers using different patterns, directives seem way over-engineered.
I strongly disagree. The idea of a directive isn't unnecessarily complex because it isn't needed. And yes, there should be a pattern to force their use, for exactly the reasons you specified.
The claim that's being lobbied against Angular, however, is that they were schizophrenic in their choice of implementations for all of their patterns, or to state it another way, that the same advantages could have been gained with much, much simpler patterns. Instead of building a nice clean framework, they built an auto-magical framework, and declared you must learn every workaround in the "Angular Way" to use it.
There are plenty of js frameworks now, many of which have analogous components to directives and controllers and views, etc. But while most, if not all of them, allow for the same advantages you've mentioned, few of them do so in such a complicated, boilerplate, and arbitrary manner.
And this is scary, because it looks like they're continuing this trend with a completely new "Angular 2.0 Way".
I'm going to go off the deep end here for a moment, but, back when I was in college, I took some marketing class where they discussed in depth the idea of user interface as a method of product lockin. The idea was if you built a product simple enough, but then obfuscated the correct method of usage correctly, you could make a product that was simple enough that new comers would be drawn to your product, but complicated enough that it would take so much time to master, that most who did so would actively desire never to leave as they were now the local experts. SharePoint really is a poster-child for this sort of dark design. And I think of this every single time I use angular, not because the ideas are wrong, but because of what simple things were implemented in a complicated manner, and what others were made auto-magical.
To pull it back a bit from the deep end: another possibility besides intentional vendor lock-in is that AngularJs dates back to an initial public launch of 2009 (and was likely older than that in the bowels of Google's infrastructure), while the frameworks that have been mentioned in this thread are younger (react: 2013, boostrap: 2011). It's quite possible that angular is simply over-engineered to solve the problems it's targeted to solve and other, younger frameworks have second-mover advantage on architecture and design (while angular has first-mover advantages of "Older, therefore more well-understood" and "wide adoption base").
COM wasn't the last word on binary cross-communication either; for various reasons I see that sort of thing done a lot more often these days via building a RESTful HTTP service, even when the intent is localhost-only communication.
which, I think, was the entire point of this article. But it speaks a lot to the angular community, and the heavy hand Google has used to build and maintain it, that the top half of the comments on this page center around people intentionally not seeing this
I don't think I can agree with that assessment. Alternatively, is the top half of the comments saying "Angular is complicated, but not unnecessarily so for building large web apps with big teams?"
It seems like what junior Angular devs really need is a post showing examples of both what NOT to do and also what to do INSTEAD.
I think the difficulty of Angular is largely you have so many tools available but it's hard for a junior developer (like myself) to recognise when each should be used.
I agree, and this article does not really help. I feel that part of calling yourself a senior developer is teaching junior developers how to write great software.
Yeah I personally think the page has shown bad habits much worse than Angular. I think AngularJS makes it REALLY easy to make SPA applications with data binding. I find it ironic that they bash AngularJS while their own site has (had) sever loading issues.
Interesting, the title tells something about bad habits but as soon as I try to visit it I just get a "loading" message that never seems to complete. If something is a bad habit, that's how it looks like.
yes I'm working on that this weekend - also in an effort to fix the mobile issues. Full posts will display on the page on their own instead of the side bar like link stories appear
> the second camp, those that said I was just spouting FUD because I didn't explain myself in detail, which surprised me a bit because those are developers who presumably have been working on Angular and in my opinion should already know about the pitfalls and their effect on juniors.
I have come to learn that the majority of people who say they work in a particular system have actually only ever dabbled in it.
MVVM has been around for years and years. It's just newish to the JS scene.
It is painful to read articles like this where even the author misunderstands the pattern and failed to read some of the standard literature on the topic. Just because MVVM is hip now does not mean everyone needs to reinvent wheels.
Agreed. If you click out of the weird popup the article is in, you get a list of articles. If you click on one of those articles, a new window/tab opens in your browser, with a similar setup (article in weird popup), and if you click to the left of that, now you have two windows/tabs with lists of articles.
I almost wonder if it was made like that as a joke.
The central problem with Angular is what is says about the software industry in general - that a framework so fundamentally and ridiculously flawed could invite such wide appeal suggests that many people have absolutely no idea what they are doing. The thousand monkeys approach to engineering has wide implications for security and safety of systems that we rely on. There is simply no way that you can say that you know Javascript and at the same time support Angular. None.
For one, it is incompatible with the whole open web stack. You cannot use Bootstrap with it. And if you decide to move off Angular, you are going to be in a world of pain.
Second and worst of all - it is a monolithic framework. As long as you just do things the "Angular Way" - you are fine. If you want to change or override something, you are in a world of pain.
If you are learning Angular - you are hardly learning JavaScript. The knowledge learned from it is hardly transferable to the next framework down the line.
To me it looks a lot like SOAP. Everybody is acting like they understand what is going on. But nobody really does.
No Boostrap? The project I recently worked on must not have happened, and it must have all been a dream...
Are there non-monolithic frameworks? I believe that's the main value proposition of using a framework: you don't need to think about how to organize things because it's the framework's job to provide you with square and round holes, all you have to do is provide the square and round pegs. I am not saying that framework is better than N libraries. I am saying that that is the framework's value proposition. Honestly, I tried helping someone with a Backbone project a while ago. The first thing you have to do when using Backbone is apparently learn a dozen or two of really random names (I swear JS project names are generated as `englishNouns[randInt(englishNouns.length)]`).
The knowledge gained from using Angular is as transferrable as the knowledge of jQuery: it's not straight JS, but if you understand what it does under the hood you can switch to a different library rather quickly.
Lastly, Angular has something that many other frameworks don't: a commercial backer. This means that it's not likely to just bitrot on GitHub for years when the original author loses interest.
> Lastly, Angular has something that many other frameworks don't: a commercial backer. This means that it's not likely to just bitrot on GitHub for years when the original author loses interest.
Google's track record is hardly impeccable in this regard.
True. I'd rather see Red Hat or some such backing it. However, Google is better than a random dev working on a project a few hours a month, then losing interest. Having Google as the backer will give Angular a boost that will get it to be popular. Then, if Google ever walks away from it, someone with enough money will depend on it so much that they'd have to pick up where Google left off.
> For one, it is incompatible with the whole open web stack. You cannot use Bootstrap with it.
Bootstrap is not the "open web stack," whatever that is supposed to mean. And it's a little amusing to hear that the past six months I've spent using Bootstrap in Angular didn't actually happen.
> If you are learning Angular - you are hardly learning JavaScript.
Of course. But nobody says, "Hey, learn this Angular thing, and then you'll understand JavaScript." You must know JavaScript first, and learn Angular second.
There are a lot of broad generalizations and some misinformation here.
I am curious what you consider to be the open web stack and why you think that Angular is not "compatible" with them. In my mind, it includes things like Linux, Apache, possibly Nginx, MySQL, languages that begin with a "P" and some other letters, etc. None of these remotely have incompatibilities with Angular. You want to sprinkle in some jQuery with Angular on the front-end? That's fine too, if you want.
As for moving off of Angular causing a world of pain, the same could be hypothesized as likely if moving from any set of patterns to a new set of patterns. I would not discredit it for providing a set of patterns, it is a framework and that is the point. Also, as for learning Angular versus learning JavaScript -- the same goes for most frameworks. You can learn the framework, and you can also learn the underlying, lower-level details that implement the framework. The two are not the same.
Doesn't work with Bootstrap? What? Sure it does. You can use any CSS classes you like, and as for the Javascript components, although not necessary there are even these native directives from the AngularJS team to make things easier:
Isn't this just criticism of frameworks? If I want to do something a framework doesn't support I'm going to be in "a world of pain" but that's the cost of using a framework.
We have had shit like this circa 2005 - when jQuery started hitting the mainstream.
And monolyths had to cede their ground to small specialized frameworks that would be built for fast deprecation and mixing with other stuff. Sort of the UNIX way.
Angular is causing just as much damage as GWT, ASP and others did in their day. IMHO.
No I haven't and will refrain from doing so. Although I am tempted to invest more of my time in it, because I can smell some phat consulting opportunities from everybody and his dog having a big, slow, badly architectured Angular app and searching for an "Angular Expert" to help them get their shit in order.
However I am not ignorant about it I have invested nearly a month into it and worked on implementing my usual TODO Demo App, which I gave up on eventually, because it became clear to me that it has nothing to offer that I would want from it.
Are you seriously suggesting that diving fully into the deep end of the hype cycle is a viable, let alone preferable way to build anything but a throwaway MVP for your resume?
You can use bootstrap with it, at least the HTML/CSS part. But for the JS part, you don't really need most of those tools most of the time. I worked with a few different companies doing SaaS, and we have always rolled a custom solution because of the designs. We never needed anything from bootstrap.
To address your comment about knowledge not carrying over to the next framework down the line, what framework isn't like this? You always spend time learning the nuances of a framework that are never transferable.
Based on history (Angular published in 2009, Bootstrap in 2011), that's a bit revisionist isn't it? It's the open web stack that's incompatible with Angular---as well it should be, since each piece of that stack is trying to solve a part of the elephant and Angular was architected to solve the whole elephant.
That having been said, the criticisms about it being an enterprise framework that's hard to move off of are spot-on. But lots of people prefer a one-stop solution to cobbling together an open stack---less flexibility, more out-of-the-box functionality.
1: You shouldn't be using bootstrap, even though you can with angular.
2: What do you need to do in the front end that can't be accomplished the 'angular way'? I'm not sure you understand what monolithic really means. The beauty part of angular is that you can use it as little or as much as you'd like in your web applications.
3: Angular 2 is going to be preeeetty much only ecma6. Also, understanding angular means you understand AMD, digest cycles, etc... totally applicable to other frameworks.
I will believe Angular 2.0 cures cancer when I see it[1]. Ok?
Regarding your other statements - you are saying the same things I am. I can do everything I could do otherwise, just at the expense of a lot of overhead I would not have if I didn't use Angular in the first place.
[1]: When it materializes.
Edit:
> understanding angular means you understand AMD
This is a load of bullcrap. __Nobody__ understands AMD, it is a cargo cult. Just like the SOAP was. And yes I think Angular (in its present form) is a cargo cult. That's what I meant with the SOAP thing.
For the record I use RequireJS on pretty much every project nowadays, but not because I like it - merely because my clients want to use it.
It is necessarily harsh. The industry goes in these cycles with monolithic frameworks. Each time they end up collapsing under their own weight and each time a new generation goes and builds another piece of bloatware that catches on and away we go again...
It is an unnecessarily harsh comment and I wouldn't have dignified it with a request for further clarification.
I'm also confused how something like that is a top comment on HN and makes me wonder what is so different about me and the everybody else who felt the need to upvote that comment.
Makes me think back about that dev Klabnik made cry after making fun their open source project. I can't get over that last sentence of kuni-toko-tachi's comment.
> There is simply no way that you can say that you know Javascript and at the same time support Angular. None.
How does someone say something like that and not feel like an asshole afterwards.
I liked Angular because it seemed to have a lot of the same ideas that polymer and other libraries had, but supported older browsers also. It seemed more pragmatic.
So when you see everyone flock to a framework you deem poorly implemented, the solution to the dissonance is to call everyone stupid, instead of admitting maybe there's some angle you're missing?
I've been doing JS since Netscape and Angular since before Google. I support Angular. Guess I don't know anything about JavaScript though. Nothing.
I think what alot of people don't think about is that "proper / correct engineering principles" don't necessarily translate to creating successful projects / companies.
If your goal is to nitpick about the reasons why a specific framework is not right for the job, then "mission accomplished".
If your goal is to create amazing products / services. And are willing to do anything to accomplish that, then sadly I think you're on the wrong side of the argument.
Angular may be monolithic and less flexible, but if a young company gets to prototype faster with it and as a result survives to second- and third- funding rounds, they can afford the engineering hours to re-implement their UI from scratch.
Success (and its associated revenue) solves all engineering problems in the long run.
"There is simply no way that you can say that you know Javascript and at the same time support Angular. None."
These kind of statements always make me think the author is trying to be dramatic because they don't know enough about the subject to try to get their strong feelings across in any other way.
Thats a little hyperbole. I "support" it in that its an easy way for someone to make a typical web application without having to know the details of call vs apply, arguments, prototypes, etc, or writing a lot of boilerplate. So in that way I guess angular is for people who don't want to learn "javascript" - and thats what you see it being used for generally anyways.
And how do those developers deal with issues such as XSS, injection, untrusted JSON, etc if they don't know JavaScript? I agree with the OP. At some point it will come back to bite you.
I've watched many ASP and ASP.NET developers struggle with more modern web methodologies such as restful web apis, client side MVC, etc and it's because they never took the time to understand the web, the browser, or javascript and let ASP take care of it for them since everything is server side and postbacks.
I fear it will be the same mistake again but made with frameworks such as angular where we have a generation of developers who have no idea how the underlying technology works.
>And how do those developers deal with issues such as XSS, injection, untrusted JSON, etc if they don't know JavaScript? I agree with the OP. At some point it will come back to bite you.
Well thats the thing, they don't because thats what the senior devs are for, and learning that stuff is part of becoming a senior dev. I just don't see angular making any more developers who don't really know the core of their technology than any other "generation"... I bet the exact same things were said about jQuery 8 years ago.
You say that as if there is some volition involved in the "settling" on JS. But there is no cohesive group with the agency to do any such thing. It's like blaming human evolution on individual human choices throughout history.
Well, we could decide as an industry that we really need to fix the code-in-web-browsers problem, and then fix it with a language which encourages safety and reliability. The fact that we haven't done that supports the OP's point.
But the same can be said about C / C++ with undefined and quirky behaviour. Even when the desire to replace them is there, it's near possible given the present situation.
But what does it say exactly? That people prefer C-like syntax as opposed to anything else? That "done is better than perfect" when it comes to releasing a new language? That Netscape got it "wrong" in the 90's by including Javascript in their browser? I'm not quite sure what you're implying here.
If that were true there would be no such things as CoffeeScript and TypeScript. The market settled on JavaScript, not the software industry. The software industry is doing what it can with the hand the market dealt them. It's not like x86 is an awesome architecture, but here we are.
The central problem with Angular is what is says about the software industry in general - that a framework so fundamentally and ridiculously flawed could invite such wide appeal suggests that many people have absolutely no idea what they are doing.
I have yet to see an Angular project that doesn't qualify as tiny. For that purpose -- banging out some internal CRUDish app -- if it allows people to create working success, then it's a success. Instead people are busy arguing over the semantics of over-engineering a couple of text boxes, and that really is what leaves me boggling. Though of course, as is the nature of these things, there are over-dramatizing camps, and one month Angular is the greatest thing ever on HN, the next it's the demonstration of all that is wrong in the world. The reality, as always, is somewhere in between.
It wasn't that many years ago when people didn't even understand basic concepts like closures in JavaScript, or the power they bring. Now people are viciously arguing about the edges. It's all very surreal.
There is simply no way that you can say that you know Javascript and at the same time support Angular.
One of the most common features pushed by just about every framework (just saw it about React yesterday) is desperately, and leakily, trying to abstract Javascript into some sort of classic OOP language. Some of the most popular tools allow you to write in various compiled-to-JavaScript languages (TypeScript, CoffeeScript, GWT, etc). It's all very strange. But again, if JavaScript is treated just as a runtime, and if it works for a team, there is some measure of success.
> trying to abstract Javascript into some sort of classic OOP language
Which is wrong. And, I think, stems from the way CS is taught. Everyone starts with Java and learns that programming is all about knowing that a dog and a cat are just subclasses of the 4-legged-creature class, which is itself inherited from the mammal class. Wait no, that's not right now is it?
But it's how people learn.
JavaScript is a beautiful glorious language when you realise it's a weird hybrid between functional and OOP and is messy enough to let you do just about anything. It reminds me a lot of what I hear about Scala ...
>One of the most common features pushed by just about every framework (just saw it about React yesterday) is desperately, and leakily, trying to abstract Javascript into some sort of classic OOP language.
You missed the point of yesterday's React announcement.
You seem to have misunderstood what I was saying. I said that I saw it yesterday about React. You know, in their announcement where they outright said -
"JavaScript originally didn't have a built-in class system. Every popular framework built their own, and so did we."
I was not making a comment on any new development or change in direction, just that React (a tool I don't use) admitted to also jumping on the pretend-OOP thing.
Thank you for clarification, I get your point now.
To be fair though, React never allowed inheritance (even in its own class system) so it's a bit misleading to compare it to other frameworks where (pseudo-)inheritance is one of the valid ways to reuse UI code.
Of all OOP, in my experience it's inheritance that doesn't play well with UI code at all—and React never allowed it in the first place.
The worst part about abstracting JS to classical inheritance (ex, CoffeeScript classes) is that the concepts do not match 1 to 1. If you try to create class variables, you will quickly run into closure issues which are clearly obvious in the compiled JavaScript.
JavaScript uses prototype inheritance and can fake classical inheritance, but it has its limitations.
Yup, I don't get it. I guess not only am I eternally doomed to be a junior dev but also am being compared to a child, a monkey typing at a typewriter, but also someone who doesn't know JS at all. Feels good man.
Other than some horribly obtuse undefined checking, there's no explanation of what the problem is. The argument seems to be that the controller depends on $scope. I... I thought that was the point. From the first line of documentation on controllers:
>In Angular, a Controller is a JavaScript constructor function that is used to augment the Angular Scope.
If the idea is that this is a bad habit to bring elsewhere, fine. Some more explanation would be nice, but whatever. But the implication is that this is a trap within the context of Angular dev itself.