> Several months ago the general direction of Angular 2.0 began to change in critical ways. I found myself fundamentally at odds with certain aspects of the proposed design. Still, I tried to keep an open mind and explore the various possibilities. Unfortunately, I haven't been satisfied with how things have progressed since then. At this point, there are too many irreconcilable differences. The Angular that's being built is not the Angular I signed up to work on
See, I find this reaction to Angular understandable, but in some ways it should apply more towards the current version than the upcoming one. I think people should be unhappier with the pile of junk that they currently have to deal with, than the fact that a bunch of it is going to change or go away.
It looks like the new version does away with some unnecessary concepts (Angular itself has way too many concepts to deal with IMO) and adopts upcoming standards like module syntax. (The AtScript stuff does seem like sort of a nightmare, though apparently only contributors need to worry about it.)
I hated the time I spent with Angular 1.x and the whole thing strikes me a as a complex and painful way to build applications. But the new stuff seems like a slight course-correction if you want to build apps in that way.
> I hated the time I spent with Angular 1.x and the whole thing strikes me a as a complex and painful way to build applications.
This comment baffles me. Not your cup of tea, sure, that I can understand, but complex and painful? Angular, Ember, Backbone, React, etc. are all so vastly superior to hacking together jQuery spaghetti code with imperative DOM manipulation I can't understand how anybody wouldn't be elated with the productivity gains they get from any of the modern frameworks, regardless of their syntax preferences.
About the complexity part, I am referring to the number of concepts one must be familiar with in order to produce a working Angular app. I mean read TFA: part of it breaks down the three varieties of directives you need to know in order to do a thing.
And it's all like this, just a constant array of made-up concepts you have to digest in order to make something happen in the DOM. It's such a pain in the butt, and you constantly keep running into it -- whenever you need to output a URL to the view, you get to go hunting for the docs for $sce and figure out your exact use case just so you can spit out the damn URL.
Well, if you're not using jQuery or Backbone at the very least to build SPA's, then that just adds weight to my argument.
> About the complexity part, I am referring to the number of concepts one must be familiar with in order to produce a working Angular app. I mean read TFA: part of it breaks down the three varieties of directives you need to know in order to do a thing.
I agree wholeheartedly that Angular has far too many bizarrely named concepts (transclusion being the worst offender), but if you don't put pressure on yourself to learn a framework inside-out in order to use it then you can save yourself a lot of initial pain. Simply using Angular's templating and two-way binding system and nothing more (no directives, services, etc) saves you from having to write an incredible amount of boilerplate DOM manipulation code. As you start to learn more about the different features Angular offers you will agree that most of them were necessary evolutions of the framework. Because it evolved over time, it has become a bit bloated as frameworks often do so the rewrite should be a welcome change.
> whenever you need to output a URL to the view, you get to go hunting for the docs for $sce and figure out your exact use case just so you can spit out the damn URL.
This is a built in security measure that you can easily override by providing a blacklist of URLs. Unless you're keen on coming up with your own sanitization logic, $sce is a very nice feature.
In my (albeit limited) experience with Angular the level of complexity is much greater than say using something like Knockout for data binding only. Not everyone wants to build an SPA and make use of $http. Also not everyone is currently hacking together jQuery. There never seems to be community chat, or posts, from people who have migrated from another framework/library to Angular, it's always people mashing together jQuery who are held up as the target audience. That should really tell you something...
Data point: I moved from a relatively big Backbone project (utilizing some of the higher-level libraries that inevitably were built on top of it) to a bigger Angular project. I liked Backbone more, because it is simpler to reason about and much easier to debug, but I believe we build things much faster with Angular. I decry a lot of the same design in Angular that others do, but I can't argue with its productivity.
I think the productivity for me comes from two places: 1. Emphasis on isolated and reusable view components. You can certainly do this in Backbone, but I never felt like I had a satisfying pattern for it. 2. Automatic data binding in the "push" direction. That is, the direction of updating the view based on changes. I think the full bidirectional binding complicates things. I find that I have far more sinks for changes than sources, so being explicit at the sources would not be burdensome.
From my initial reading tinkering, using something like ReactJS as the view layer in a Backbone (or perhaps even plain JS) app may very well speak to both of those points.
Certainly at ng-europe AtScript was being touted as the way you should be writing Angular 2.0
As a massive fan of Typescript I'm not convinced it is actually that much of a problem. But when you see the JS you have to write to achieve what AtScript produces it's going to be pretty painful for someone who wants to stick with JS.
> What I am saying is that it is no longer fundamentally the same thing I was originally hired to help build nor is it compatible with my vision for the future.
I've heard elsewhere that 2.0 will be an entirely unrelated framework which will be still called Angular for no good reason.
Dismissing this opinion as a troll is no longer productive after the above commentary by an Angular developer.
In that Angular 1.x has been iterative changes and 2.0 is a completely new architecture and code base, it's not a rumor. The angular team has been saying that since the original announcement.
Any time I've ever left a job because of a project, all that time spent working on a broken product has left me with tons of time to figure out how I would do it on my own.
The guy's framework existed before he joined Angular, he announced that they were merging, and then he changed his mind. Your analogy doesn't quite fit.
I'm skeptical of several things, but so far trusting that team has gone well for me.
I don't think Angular can be fixed, without throwing out everything in 1.x.
What's wrong:
1. UIs are complex. Angular tries to solve this by attaching a lot of programming capability into its templating language. That makes the template itself very complex, which is the situation with Angular right now. Instead of injecting some programming capability into html-like templating, a better way would be to insert templating into a full programming language. Example, JSX.
2. One of the great things about the evolving JS ecosystem (as seen in say, the npm registry) is that components and libraries are tiny, and usually they do only one thing. While there are a few disadvantages to this, it also gives incredible flexibility. From my experience it reduces risk (because components are smaller and better understood) and makes it possible to adopt newer ideas/tech faster (because you could incrementally add small components). Angular on the other hand, tried to do too much.
3. Frameworks should enable users to re-use what they already know, instead of making them go through dozens of pages of documentation. Learning Angular takes as much time as learning JavaScript. We should encourage libraries which take advantage of what programmers already know, so that they can spend time working on features instead of learning the framework.
The general idea behind directives is still there in 2.0. JSX does come with one fatal flaw in order to accomplish what it does - it requires extra build tooling from the get go, which makes it that much more difficult for junior developers to pick it up, along with the assault of other technologies, code structure, and paradigms they have to pick up at the same time. The beauty of the declarative direction of Angular is that it still is just regular old HTML.
I do agree with #2, and it is a large part of why Angular is changing so drastically with 2.0 - part of this can be evidenced in 1.x with components being split into official optional modules (ngRoute, ngSanitize, ngAnimate, ngTouch, etc.).
I somewhat agree with #3 - I feel like in order to properly use any framework, there is no way around combing through documentation and the source code. I have found that true with most libraries I have used. Angular's documentation at least has the benefit of being very thorough compared to most at least. I do disagree that libraries should only use what programmers already know though - we should be pursuing how to best foster productivity in the long term, and sometimes this means exploring new patterns.
> JSX does come with one fatal flaw in order to accomplish what it does - it requires extra build tooling from the get go, which makes it that much more difficult for junior developers to pick it up, along with the assault of other technologies, code structure, and paradigms they have to pick up at the same time.
However if they managed to understand directives, digest cycles, dependency injection, MVVM, angular services, $scope, controllers (confession: as an amateur I haven't been able too), handling JSX build step doesn't seem like a stumbling block.
If #1 was a concern they wouldn't be pushing AtScript. Angular has already conceded that extra build steps are a good thing, so why not add JSX into the mix as well.
For the record, that is one thing I don't like about 2.0 - I rather have less required build tools. Frontend development is getting quite complex, and I fear that it makes it harder to build up competent developers in the long term - it's already hard enough to teach friends trying to learn about everything else in development.
I am fine working with this sort of tooling myself, but it is more of a concern coming from a lead/senior engineer viewpoint.
The other big thing, as a Knockout user, is the massive difference between observables and Angular's digest cycle. Choosing a slightly cleaner syntax over having a dependency graph strikes me as an absolute folly - and leads to bind once as a UI construct rather than letting my view model dictate whether something is a constant or a variable (or a function).
I don't necessarily disagree with any of your points, but 2.0 is doing the exact opposite on all three points. The front end UIs are now _more_ complex, does _more_, and requires more Angular tie in.
I'm really hoping this thread doesn't devolve into a framework flame war, but those who are interested in angular or currently using it would find this post very interesting. It clarifies a lot of the reasons why the Angular team felt that they needed to do a complete rewrite instead of incrementally improving 1.x and it also outlines a lot of the exciting new features they hope to include in 2.0. I personally appreciate their dedication to the web components specification and a desire to seamlessly co-exist with it. Atscript illuminated a lot of interesting programming concepts I'm not personally familiar with as a front-end developer and I'm intrigued by them. Definitely worth a read if you have time, Rob Eisenberg has a very extensive understanding of Angular.
sorry I just have to vent a little... I feel like I got wrecked twice jumping on the GWT and then the Angular train. I am not sure if I have the energy to jump on the Angular 2.0 train and get wreck once more... Any advice would be helpful.
Google built their brand-new email product Inbox with GWT apparently. GWT might not be hip but it was still their technology of choice to build an extremely complex, intricate and convoluted web application.
I have seen several large enterprise organizations build important applications in AngularJS. The kind of applications that you don't want to rewrite the UI in 2 years. In fact I know of one that will start in a few months. I would not be surprised if AngularJS was in the RFP.
These days I just stay away from those projects and watch them burn.
Don't trust Google APIs or Frameworks. They have a reputation of throwing it all away with each new version leaving you in the lurch and having to do major rewrites.
Well, on the one hand, GWT and Angular 1.x both still work. They might not be new and shiny anymore, but they do still get the job done.
Personally, I still like using Backbone.js. I liked it from the start because I could read and easily comprehend the entire codebase. That might be a decent rule of thumb before getting very invested into a tool/framework/whatever.
Don't take this the wrong way, but perhaps you should rethink your career choice. If tools changing and be supplanted by other tools causes you too much stress then I have unpleasant news for you - it will never stop. The good news is, it doesn't have to be stressful. If a tool you like works, use it! Don't worry about the shiny new stuff coming out, worry about being productive today, and you will find that your stress level will decrease dramatically. But above all, become comfortable with the fact that you will always be learning new things until the day you retire. You aren't flipping burgers.
Fair point, however his fear of "getting wrecked again" is a very valid concern for companies. Which certainly don't want to end up with webapps relying on obsolete frameworks.
At work we have some old projects built on GWT, some newer projects built on AngularJS and both will soon be outdated.
Also there is no real choice to build a modern web application, that clients now expect, while being really future-proof. That's the first time I see a situation like this, typically you need to pick between shiny new tech vs old boring one.
As someone already noted, Google's latest large-scale web app, Inbox, was built with GWT. How is it then "outdated"? When something new and shiny comes along, old technologies don't magically stop working. A maintenance path and new leadership has been established for ng1.x : https://plus.google.com/u/0/+IgorMinar/posts/2Uo6yh4AV7L
Building anything on the web and expecting it to last more than 5 years is foolish in my opinion. But yes, if your company is expecting to build an app that won't be re-written for more than 5 years then by all means do it in vanilla javascript, but you'll likely end up building a custom framework anyways.
Building anything on the web and expecting it to last more than 5 years is foolish in my opinion.
But why should it be? The goal of building web sites and apps isn't to use the latest shiny new technologies.
You can build excellent web sites that serve valuable business and/or social functions, using nothing but technologies that have been around for 10 or even 20 years.
And if we're talking about app-style development, why should someone who invests significant time and resources to build, say, an intranet app to automate some function in their business not expect that app to still work five years from now?
This is why standards and stability are important, and it's why "living standards" are a pile of [expletive deleted], and it's why it's a bad thing that some browsers currently have very rapid release cycles with an obvious emphasis on adding new shiny things at the expense of maintaining support for older technologies, and it's why you shouldn't build anything you might need to maintain for more than a year or two with the JS framework du jour.
A lot of front-end devs today make building simple user interfaces to access databases seem awfully complicated. Every time I read articles like this one I become more convinced that most of that complexity is of their own making. They talk down to old school developers who put most of the logic on the back end, or who build interactions using jQuery, but sites written 5 years ago using those technologies still work and can still be maintained just fine. I wouldn't bet on that being true for anything built with a framework like Angular or React today.
> But why should it be? The goal of building web sites and apps isn't to use the latest shiny new technologies.
I agree that it shouldn't be, but I don't agree that it's possible for it not to be, mainly because browsers are constantly changing and improving and assumptions older frameworks had become irrelevant over a long enough time period (certainly over 5 years). This is precisely the reason why Angular is having to make such drastic re-write - they're trying to align better with Web Components and other ECMA6 features that are coming down the pipeline.
I hate to stereotype but often people who complain about the volatility of web development tools and frameworks are people who are traditionally server-side developers who have enjoyed a relatively stable deploy target for periods much longer than 5 years. Trust me, I wish it was the same for front-end development.
> And if we're talking about app-style development, why should someone who invests significant time and resources to build, say, an intranet app to automate some function in their business not expect that app to still work five years from now?
Because building desktop style applications using old web technologies is really freaking hard. If it wasn't, we there wouldn't be such a huge deluge of web frameworks to help do it.
> This is why standards and stability are important, and it's why "living standards" are a pile of [expletive deleted], and it's why it's a bad thing that some browsers currently have very rapid release cycles with an obvious emphasis on adding new shiny things at the expense of maintaining support for older technologies, and it's why you shouldn't build anything you might need to maintain for more than a year or two with the JS framework du jour.
I can't really disagree with you here and that's why I find React so compelling because they're kind of saying "fuck you" to the standards committees and building something they know works whether or not the promises of ECMA6 and HTML5 come to fruition.
> A lot of front-end devs today make building simple user interfaces to access databases seem awfully complicated. Every time I read articles like this one I become more convinced that most of that complexity is of their own making. They talk down to old school developers who put most of the logic on the back end, or who build interactions using jQuery, but sites written 5 years ago using those technologies still work and can still be maintained just fine. I wouldn't bet on that being true for anything built with a framework like Angular or React today.
I'm guessing you're not a front-end developer so forgive me if I'm wrong, but what you're saying is absurd. It is hard. Much harder, in fact, than building an iOS or Android App which rely on sane frameworks built by single entities to function perfectly within one sandboxed environment. Web applications like Google Docs are every bit as sophisticated as native mobile apps but must be built without the benefit of native performance and monolithic, corporate-sponsored SDKs. Putting "most of the logic on the backend" isn't a viable solution for native mobile apps, why would it be a viable solution for desktop-style web apps?
Just step back for a moment and compare the functionality you get from a framework like Angular or Ember to the functionality you get with the iOS or Android SDK and you will see they are all solving generally the same problem in the same way. The only difference is that there are far more choices of frameworks on the Web (which is both a curse and a blessing).
I'm guessing you're not a front-end developer so forgive me if I'm wrong, but what you're saying is absurd. It is hard.
I suspect that we'll have to agree to disagree on that. I'd say building a real-time control system for an aircraft is hard. Writing safety-critical firmware for a medical device that must have literally no serious bugs because if you miss one then people could actually die is hard. Accurately modelling global weather patterns is hard. Building a database that can support Google or Facebook or global financial systems is hard. Writing networking algorithms that can manipulate hundreds of gigabits per second of network traffic on today's commodity hardware is hard. Performing voice recognition and natural language processing to allow a computer to respond to verbal commands in everyday language is hard.
In contrast, writing a relatively small, primarily text/form-based UI as a front-end to simple database is not hard, whether as a desktop app, or a mobile app, or a web app. It just isn't. There are no out-of-the-ordinary performance requirements. No-one is going to die or lose a million dollars per hour if it has a bug. There's no fundamental problem to solve that requires the development of new algorithms. It's like 2/10 on the scale of hard software problems.
It's interesting that you started your post by talking about assumptions underlying frameworks changing and you kept coming back to the 5 year time scale. As I see it, the fundamentals of HTML, CSS and JS haven't really changed very much in two decades. Likewise, the patterns we see in modern web and mobile UIs -- things like data binding, and MV*, and bundling updates together so you only do one expensive re-render -- have been widely used in desktop software for decades as well. So I'm wondering what fundamental assumptions could have changed so much in just a few years that a JS framework would no longer be useful so quickly, and I'm thinking maybe they were bad assumptions in the first place.
Of course a few of the details have evolved over time. And of course it's nice that there are now JS libraries to support some of those patterns as a ready-made tool so we don't have to set them up ourselves. Still, we've been using the same ideas, even in front-end web development, since long before Angular or React was on the scene. Implementing those patterns in JS using general programming principles isn't difficult, nor is it particularly time-consuming, given that you probably build these kinds of tools once per project and we're talking about projects large and important enough to have a multi-year lifespan. Much of the JS community for the past few years has just been kind of flailing around learning the same old lessons all over again, with varying degrees of success.
So I'm puzzled by this recurring idea in discussions about JS frameworks that all we could do before we had the likes of Angular and React was store data in the DOM and use arbitrarily large amounts of trivial jQuery. That is not a world I recognise. No doubt quite a few sites/apps did work like that; there are plenty of low-skilled people who write software, after all. But plenty of other sites/apps were built by real software developers who used real software design skills, just like any other programming project. Right now, I'm working professionally on multiple web front-ends that predate most or all of these JS frameworks, yet have been doing their job and adapting to changing requirements successfully for longer than anything written in those frameworks has been around. They each have their own considered software design, and they still use techniques like publish-subscribe, bundled rendering updates, separate models, and so on.
So as I said at the beginning, I'm afraid we'll just have to agree to disagree. I can't accept the premise that building a typical UI that is mostly text/forms and talks to a database is difficult to do without a framework. Countless programmers have been doing it on numerous different platforms for decades. It's just that a significant part of the JS community only just noticed and started borrowing the same ideas.
Keep it minimal. I've written pretty serious web applications with no more dependencies than jQuery, lodash, browserify, and handlebars, for instance. Learn javascript really well, leverage "plain old javascript" patterns like function composition and closures over fancy but poorly-motivated new stuff like reactive data-binding and MVWXYZ.
My only advice is to leave web development if you're afraid of changing technologies. The web is moving at light speed, any framework you pick today will likely be significantly different or gone in 10 years.
When AngularJS was first created, almost five years ago, it was not originally intended for developers. It was a tool targeted more at designers who needed to quickly build persistent HTML forms.
I guess this confirms it -- Angular really is the modern Visual Basic.
I haven't read the article (I never used Angular), any idea how does it compare to React? Does it use the one-way-only data-binding powered by shadow DOM?
It really only makes sense to compare React to Angular's Directives because they are both trying to simplify the process of creating isolated, reusable components with data binding built in. In fact, they both use in-memory representations of the DOM to track model changes, although they differ in the actual mechanisms for doing so. Angular uses "dirty-checking" which basically tracks whether or not a model has changed in any way from its previous value and it does this on a loop. It's very simple and inexpensive but can start to perform poorly when dealing with large lists of items (in the tens of thousands). React also has an in memory representation of the DOM they call the "virtual DOM" (not to be confused with Web Components' "shadow DOM") and differs from Angular in the way it employs its diffing algorithms to efficiently and surgically respond to only the elements that need to change when a model is updated. It performs better than Angular when dealing with very large collections of items but I believe Angular is as performant or better than React in the small case.
React also enforces certain restrictions by default when it comes to mutating data. While Angular encourages "two-way binding" where data can be changed by two different sources (e.g. the controller and the user changing the input field), React encourages a strict policy of one-way data passing. It is possible to restrict Angular directives to function exactly like React components, however, if you subscribe to React's core philosophies about data handling. For large applications, though, React applications get messy as they need to pass data down a very long tree of nested components. They wrote the "Flux" pattern to address this concern, but it really ends up looking like yet another version of MVC (although I like it, personally).
Where React and Angular differ dramatically is in how they handle templating. Angular's philosophy from the start was to embrace HTML and a declarative programming style. They believe HTML should be embraced and extended using "Directives" which is very much in-line with the philosophies behind the coming Web Components standard. React's team, on the other hand, challenges long-held assumptions about web development like not including markup in your code, opting instead for a framework that not only encourages it, but requires it. This is a controversial aspect of React, but it makes sense when you actually try it. Some logic is better written imperatively (like if statements, map/reduce, etc.) and it's nice having everything required to render the component in one file. It does, however, require a compilation step unless you use their imperative DOM manipulation library so in that respect Angular is far easier to get up and running with (which is part of its dramatic success).
In my mind, the only aspect where React really has a clear advantage is the ability to run server-side, which allows you to pre-render components before sending them to the client. This solves a variety of SEO and time-to-render issues single-page web applications often struggle with. The only caveat is that single-page apps don't typically need to be SEO friendly (like gmail or google docs, for instance) so it remains to be seen how important this differentiator really is. The React team admits it was really a happy side-effect of the virtual DOM and not really the main reason they built it, but it's compelling nonetheless.
One last thing I'll mention is that currently it's a very difficult time to pick a horse in front-end development world. All signs point to Web Components becoming the next big thing, but React has made a lot of people question whether or not that's the correct approach. React has not made it a stated goal of theirs to align with the Web Components specifications like the Ember and Angular teams have. I can't say whether this is incredibly wise or foolish, but again, it's compelling.
edit:
I forgot to answer your original question directly:
> Does it use the one-way-only data-binding powered by shadow DOM
It allows for both the use of one-way binding and two-way binding, which React actually does too (although React's core team discourages using two-way binding). Neither is powered by shadow DOM so I'll assume you meant virtual DOM. I kind of answered this above but to re-iterate, both frameworks build up virtual representations of the DOM in memory to better serve data-diffing, but they both chose different mechanisms for doing said diffing which is outside the scope of this post but definitely interesting to learn about. The important point to take away is that you can restrict Angular directives to function exactly the same as React components, the only functional difference being the diffing algorithms under the hood and the templating systems used.
I'm actually not sure what I prefer, to be honest. I am hoping web components show up in IE and Safari soon so we can start using them but for now I'm not sure which tech to fully invest in. The good news is they are all awesome in their own unique ways and it's sometimes easy to lose sight of that with all the flame wars.
Rob is a brilliant guy. We've used his WPF/Silverlight mvvm framework for years. Our consulting company uses durandal.js for current projects. It looks like Durandal v2 is now called Aurelia. I have high hopes for it, he knows how to write a framework.
I'm glad to see official Google support confirmed, but I wasn't too worried about that. It's an open source project, always available on github at any version, and if Windows XP can survive this long without those provisions, then I'm sure Angular 1.x will be last a long time.
I think the one thing that I would change for Angular 2.0 is the project name. With so many of the framework elements being killed, and the whole thing rewritten from scratch on a different language (AtScript, compiled to JS), with a different API, with different paradigms, the name "Angular" and the expected meaning it's built up to all developers involved doesn't apply anymore.
I will soon need to update my resume to say that I'm experienced in Angular 1.x. I'll need to ask people developing projects built on Angular, "But which version do you use?" I'd say the same gripes apply to Python 2 vs Python 3.
I don't want to go all Romeo and Juliet on the name here, but maybe there's room for a semver 2.1 that specifies the hitherto-unspecified contracts you can expect to be upheld if a project keeps the same name.
Keeping the name succinctly describes how 1.x will stop adding new features and the team behind it is building 2.0. It's a good move if the community stays with them.
> I'm glad to see official Google support confirmed, but I wasn't too worried about that. It's an open source project, always available on github at any version, and if Windows XP can survive this long without those provisions, then I'm sure Angular 1.x will be last a long time.
For example, I still using ExtJS 3.1.1 in some projects, even the 4.x version is available for a long time, so, i totally agree with you.
The Angular's level of complexity looks overwhelming. I feel like it creates more problems than it solves. I do hope I'm wrong, the man-hours put into it are not in vain and there is a good niche for this framework.
> Several months ago the general direction of Angular 2.0 began to change in critical ways. I found myself fundamentally at odds with certain aspects of the proposed design. Still, I tried to keep an open mind and explore the various possibilities. Unfortunately, I haven't been satisfied with how things have progressed since then. At this point, there are too many irreconcilable differences. The Angular that's being built is not the Angular I signed up to work on
http://eisenbergeffect.bluespire.com/leaving-angular