If there is one myth in the automation world that drives me crazy it is that browser automation scripts need to be written in the same language as the application is written in. It seems like that should be a Good Idea; in principle, but in reality it is actually responsible for a lot of 'failed' automation efforts.
Let's choose a language to pick on. How about C# using ASP MVC; has a large user base (especially in the enterprise space) and pretty mature stack to use. (We could have picked any language...)
So now we have a nice ASP MVC application that we think is going to solve some customer's burning needs and of course it's nicely unit tested because you are doing some variant of TDD/BDD. Your browser automation scripts should naturally be written in C#, right?
No.
Well, actually, 'maybe'.
If browser automation is the responsibility of the developer who implemented a particular feature then it makes sense for them to write it in C# as they (in theory) know that language and its nuances. And they can reuse the same runner and its idioms for controlling the browser scripts. If they don't know C# and are implementing features, you might have a larger problem to solve than just browser automation...
What happens more often though is that the developers are not responsible for browser-based tests. That falls to the test team or some semi-autonomous group who is focused entirely on automation.
Do they know C#? Awesome. Use that language. But if they do not then they should not.
Well, usually.
The vast majority of teams starting with browser automation either don't have programming skills or they are extremely rusty. Neither of those are harbingers of a successful project. This is about the point where someone has the brilliant idea of thinking they will 'just' teach the language to the responsible team. Ummm, ya. Have you ever taught someone to program at a professional level before? It's not that easy. And good luck if you are using C# (or Java, or C/C++ or other ceremonial languages).
I spent 4-ish years consulting on largely this 'getting started' problem. Python, Ruby, and yes, PHP are the keys to getting teams up and running on browser automation fast and effectively. Very little ceremony, powerful, large base to pull support from, and need only a fraction of the overall language to do effective browser automation. It is no real surprise that a number of universities are now using those languages for the year one introductions to programming.
"But! But! My Continuous Delivery Pipeline!!!" you may be screaming. Yes? What about it? I've not seen anywhere that says all actions in a pipeline need to be the same language. Its just another item that happens to be a different language than a previous item.
Now with all all that having been said, there is actually one really good reason to write your scripts in the same language as the application itself. And that is when there is a ridiculously complex algorithm implemented in that language that you want to leverage as part of your verification steps. But that is actually rarer than you might expect. I've really only encountered it once and that was with a crazy geo-fencing algorithm. (And even then, we cheated and used IronPython to enable us to use Python but still slurp in the .NET assembly.)
Remember, your web server doesn't care what kind of human is in front of the browser. Why the heck do you think it is going to care what kind of programming language is driving the browser? Pick whichever language makes the most sense for the team writing and maintaining the scripts and stop being such a language snob.
