If we look at the Protractor architecture, Protractor uses WebDriver JS to call Selenium Webdriver which ultimately calls browser driver and then browser. Now since Selenium is passing commands to browser driver why can't we just use Selenium to automate Angular pages ?
I do use Webdriver to use Angular pages. So it IS possible, and OP's assumption is wrong.
But it is not easy - not as straightforward as using WebDriver to automate more traditional web pages (which do not use "single page application" concept and DOM manipulation so heavily), where is trivial to add id or name to any element you want.
Angular uses IDs heavily for interaction and DOM manipulation. As a result, WebDriver tests cannot rely on IDs to locate elements, and locating by name is bit more hassle (non-unique etc). But you can still write tests using WebDriver (that's how Protractor does it after all, under the skin).
WebDriver tests are Angular-agnostic, they know nothing about Angular and the complicated machinery on the page it uses to manipulate DOM.
Protractor understands Angular and this allows developers to write Protractor-based tests bit easier - and as always, for the price.
Edit (April 2018): Angular2+ is a significant if sneaky change over AngularJS. Angular2+ does not support some AngularJS-specific locator strategies anymore (and has no plans to implement them), so there is even less incentives to use JS (beyond JS unit-tests of Angular stuff). So when talking/reading about "the Angular" you need to be aware which version we are talking about, they are significantly different.
Our current strategy is to implement Angular2+ unit-tests (model, basic manipulation), and also single happy-path UI test in JS. More comprehensive UI tests will be in Python/WebDriver. Yes, it is slight duplication of work (locators are both in JS and Python, but locators are trivial). We prefer Python, have lots of code in it, including testing tools/fixtures, which are easier to call from Python than from JS, so we think it is the best compromise.
That is why I asked OP about any hands-on experience. For any person with hands-on experience with writing both WebDriver and Protractor tests, it is a matter of taste and preferences.
You can just use plain Selenium for testing Angular applications. Protractor just makes it easier to test Angular application. Its a framework for testing Angular applications.
It has Automatic Waiting for elements and you can access specific Angular elements by.model and by.binding. Also it implements the Page Objects in the framework making tests more maintainable if used correctly. Probably there are some more enhancements not listed on the front-page of Protractor.
Selenium WebDriver is a tool/library that enables automation, whereas Protractor is a Test Runner/Test Framework which defines the design/structure of the automation.
If your tests are flaky, it might need deeper analysis to determine the cause of flakiness. I've been automating AngularJS applications using SerenityBDD and Selenium WebDriver for almost over 3 years now. I run ~2000 test cases on 5 VMs using Selenium Grid which are integrated with CI tool. Flakiness on the development branch is high as we test under development features, whereas on the production branch is extremely low as the build is stable.
Selenium WebDriver might have sync issues with the AngularJS application, but that should not limit/restrict us from functional testing. Flaky tests can be fixed by introducing custom waits, catching known exceptions, soft assertions and retrying failed test steps a couple of extra times to ensure sync.
It seems to be best practice to make the automated tests at the gui level in the same language as the program under test is written in. Or at any level actually, it also applies at the api, business logic, data store and what ever other layers have been made across the stack.
It just helps in having a shared responsibility. No dev would like their build fail and not being able to comprehend what was going wrong. That and less excuses being made not to maintain the tests because "no one knows the language they are written in".
Which is better, a hammer or a screwdriver?
One may always use hammer on a nail but if you are working on screw then it is better to use screwdriver if you have one(Protractor!).
I have used both selenium & Protractor to test angular sites and from last couple of years using Protractor extensively to design large scale test automation for Angular/AngualrJS frontend applications.
Based on my experience , using selenium instead Protractor is like Reinventing the wheel ,either in an efficient way what Protractor does(which will take lot of effort , see below) or by the hard coded waits all over the place which is NOT an professionally mature scale-able efficient solution.
What Protractor does
Both Angular and AngularJS when run asynchronous operations exposes the special undocumented testability API, which Protractor uses when it wants to synchronize. This API allows one to provide a callback function which is going to be called once all asynchronous operations are completed.
Protractor injects a few functions on the page. One of those is waitForAngular(rootSelector, callback) function. Protractor calls this function every time it wants to synchronize.
This function serves as a synchronization facade – it expects caller to provide a callback function, which is going to be called once Angular says that there are no asynchronous operations running. Different version of Angular provide different testability API, so waitForAngular() has to know how to work with all of them.
After considering all this ,IMHO using Protractor over Selenium to test angular applications is no brainer.
I've been successfully automating angularjs e2e tests with selenium\watir\ruby as my tech stack for a few years now. My first attempt at using protractor\chai\jasmine in 2014 was a train wreck. The stack and angularjs were in their infancy and my teams time was filled with entering bugs and waiting for pull requests. Out of necessity I switched everyone over to the selenium\watir\ruby and finished the project on time. From what I've read on boards like this protractor has matured in the 5 plus years since I've last touched it, that said a need hasn't presented itself requiring me to revisit protractor. Next project is Angular 6 and I intend to use selenium\watir\ruby for that as well. If I have to switch I'll post it here :-)
I have a website made in Angular 2 and i'm starting to think that Selenium can not be dependable upon when testing. I have tests that pass one minute and fail another without any change in the code. When it comes to Protractor, with Angular 2, it doesnt deal with the issue of Promises. So it's not dependable as well.