Why do large websites use different languages for the backend and frontend?

Question

My understanding from small MVC applications is that you have the front end, which deals with HTML, JS, jQuery, etc, and you have the back end, which consists of your controllers and models.

However, when I talk to developers from large companies, they often mention having a frontend tier and a backend tier. So sometimes, I might hear that they have a frontend with C# and a backend with Java. Why would any company want a backend and frontend in different languages? Does this help the large website scale better?

When people say that their frontend is built in C#, does this mean that they are using a framework for the frontend (like .NET) and an additional framework on the backend (such as Spring)? Or does it mean something entirely different?

Answer 1

"Front-end" and "Back-end" can be nebulous terms, particularly in enterprise applications. "Front-end" can mean the UI, or it can be the entire application. "Back-end" can be used to mean the internals, or it could be the database or external services that are consumed. What the terms mean often depend entirely who are you talking to. So did you maybe ask "hey, what do you mean by that?"

When you get into large enterprise development, you are going to have lots and lots of teams writing lots and lots of code. These teams will be developing in different languages, using different paradigms, from different locations. Some of this code will need to work together and much of it will not.

I work for a large bank. My team develops our application in C#. All of it. But we consume web services that are largely written in Java, and those services talk to other services that talk to other services that get the account data to and from the appropriate data stores, and who knows what languages are used with those.

Short version: People use the tools that get the job done.

Answer 2

I think you need to broaden the question a bit: Why do large software projects use more than one programming language?

There are many possible answers, the most notable ones being:

• Large applications consist of many relatively independent parts; often, each part is built by a different team or even a different external contractor. The benefit of going with the best bid is often larger than the benefit of having everything in the same language.
• Languages come and go, and sometimes a component of a large system outlives the ecosystem. An example from the Microsoft world is how many companies now use C# for all new projects, but they still have a considerable VB codebase around. The cost of rewriting a project just for the sake of doing it in the latest programming language is practically never justified.
• Interfacing with third-party components. If your C# ecosystem needs to perform a specific task for which only Java solutions exist, then you have two choices: implement the solution yourself, or use the Java solution and develop a bit of glue to integrate it into your system. The latter is almost invariably cheaper for any non-trivial task.

Performance considerations are practically never the reason, except in extremely performance-critical applications like high-frequency trading - in those areas, it can be beneficial to write the critical core engine in a language with better run-time performance (say, C++), but the supporting systems (UI, reporting, etc.) in something higher-level like Java or C#.

Answer 3

It is relative in a large enterprise.
In my company the stack is roughly

(html/javascript)--> (JSP on Tomcat and Java based WebCMS) -> (.Net SOA)  

So for the web development team the frontend is HTML/JS and backend is Java. For the enterprise the frontend is Java and backend is .Net.

In fact the .Net layer has to work with a COBOL/UNIX application for Billing and Claims and so in this perspective .Net is frontend and COBOL is backend.

And yes as others have mentioned we have teams of UX designers, HTML/JS devs, Java devs, Web Middleware, .Net devs, SQL devs, COBOL devs working at each portion of the stack.

In fact in any sufficiently large enterprise it is turtles all the way down.

Answer 4

Confusing Semantics

It's a semantics issue. When somebody says a .NET front end or Java front end developer, they're usually talking about the person who knows a lot bout the templating languages and maybe frameworks that should never be used ever again like webforms that were used to try and hide the chucking of things over an http wall (i.e. "web development") from app developers who didn't want to or at least were assumed to not want to learn about all that crap. In the case of mixed .NET and Java, I'm not sure but I could only guess that in the MVC sense of things they've got Java acting for all the business model stuff and .NET handling everything else which would be better described as "middle-tier" but it's still all server-side.

The real separation is what happens on the server and what happens on the client or browser. You could easily conflate building the HTML to be sent to or representing the front end with "front end development" so I prefer avoiding confusion by using the terms client and server-side instead of front and back-end when discussing what I typically do, (usually client-side work).

Client Side Languages

The reason we use the same set of languages on the browser is because the browser is on the receiving end and for the most part (there's been now-mostly-dead resistance from Microsoft and Adobe on this) nobody wants to have to send out three different versions of the same client-side to satisfy every potential customer or require a proprietary plug-in be installed for the web to work. Also, the three languages actually encapsulate client-side concerns quite nicely, allowing us to rapidly build and modify web app front-ends by maintaining loose coupling between document structure, how everything looks and how it all behaves. You can change one without changing the other two quite easily.

Server Side Languages

The reason you have bazillions of options on the server side web of course is because you can. It's your server. All it has to do is communicate via http/ssl and the rest is up to you. JavaScript is now an option by the way, but that brings up an interesting question. Should you still treat a web app like it's really two apps on either side of that HTTP wall. I'm of the informed-through-pain opinion that yes, yes you should and I love Node.js.

Answer 5

In short, where you have large projects, you also have multiple teams of developers working on the project, and those teams tend to specialise on different layers of the application.

If you are focusing on the web UI, and you have flexibility in your choice of implementation, you are much more likely to use a web ui targeted language, such as JScript or Flex, rather than C#.

Likewise, if you are at the transactional data store end of the application, dealing with many concurrent actions at once, specialised languages such as erlang tend to get used. (Or third party products that are implemented in part in these languages)

Answer 6

The reason is business risk-balancing.

Let's say you're a giant employer in one city. You have to hire a lot of developers to build a lot of different services. Let's say your initial evaluation is that Lanuage A suits your interests best, and you want to start with it.

If you commit to one technology you might dry out the talent pool. Are you sure you want to hire a decent Langauge A guy when there is a Language B star just around the corner? What if tomorrow Langauge A's frameworks seize to be supported by the main developer? What if tomorrow there is an amazing Language C, should you ignore it because you committed to language A five years ago?

Ideally what you want is a hetrogenous system with different languages that reflects the current talent pool and technology trends. You want this balance to shift slowly as the talent pool and trends are changing so that at any point all of your systems are workable and you can hire the people to maintain them.

...and that's sort of what companies do.

Answer 7

It's helpful to think of your front end and back end as separate applications that both use the same data source.

Even for smaller sites, you can think of the front end as being what the client interfaces with, and the back end as something like a CMS. These can easily be separate MVC applications. The front end still needs models and controllers to run - after all, the controller is the point of entry for your site visitors and the models are going to be the way you get data from your database to the user.

I tend to like using Django/Python as a CMS on the back end, and using Rails, CodeIgniter or Spring MVC on the front end. Often there's no choice; the client already has some legacy site set up in some language on the front end and they just want a CMS solution. Most clients wouldn't even know the CMS was running a different language or framework if they weren't told.

It's really about finding what works best for the site you want to build. The front and back ends really only need to share the database, so as long as they can both work with that, feel free to choose the best options for the task at hand.

Answer 8

An example of a back end language is PHP, which is a scripting language. When a PHP page is requested, the server reads the PHP code and renders the markup. The result is HTML that is sent to you. You, the web page viewer, never see one line of PHP code. Assuming that the web server administrator has done his or her job correctly, the server would, and could never show you the actual PHP code. It is parsed when the page is served up and the result of that code translation is HTML.