Why didn't languages such as C end up being using for web dev? Surely the speed increases from being compiled would be useful for heavy load sites?
Another good reason is that on a big server execution speed is not so much an issue as the connection speed anyway. Most of the time is spent sending and receiving data, not number crunching. And actually in certain web services which do a lot of computations, the hard crunching is probably run as a compiled program.
Plus interpreted languages don't need compiling (which on a large project can take time), thus it's more suited for the typically agile development of web solutions.
Most web applications talk to a database. The overwhelming majority of these apps spend almost all of their time communicating with the database. So, for any given request to the application, there is a tiny amount of processing in the application server and then a long pause while waiting for the database. Since such a small percentage of any request's time is spent in actual application server code, optimizing that code by writing it in C/C++ will gain only a tiny, likely not noticeable, improvement in response time.
So, rather than focusing on C/C++ and saving every last CPU cycle, it makes more sense to worry about developer productivity. Developers are very expensive. And, they're typically much more productive in a scripting language or even in Java than they are in C/C++.
Of course, there are exceptions to this. And if some requests to your application are CPU or memory intensive, they should be written in C/C++. But, for the rest of your application, you're better off focusing on optimizing your algorithms, data structures, communication with the database, and developer productivity than in optimizing your language.
Scripting languages have the following advantages over C:
- Much faster development
- Today, all of those relevant to this question are compiled at runtime. In some cases, this can make them faster than an equivalent C program, so performance just isn't an issue anymore.
- Maintenance costs much less
- You can develop using Agile methods (like unit tests) which results in much better code. Yeah, you can do that in C, too, but it's much more effort.
- When you're doing web development, you have huge frameworks which do most of the work for you.
- They are much more open to change. A new feature can take as much as a few minutes to implement.
- If something is broken, you can login to your server, start a text editor in the console and fix the problem, sometimes without having to restart.
C was used for web applications early on - I wrote various CGI scripts in it.
Over time, however, more productive languages (C# and Java for example - but not exclusively those, of course) have proven to be "efficient enough" for web applications. Note that both C# and Java are compiled to intermediate code and then JIT-compiled, achieving "roughly" native code performance. Why would we want to use C instead?
Even the traditionally "genuinely interpreted" languages such as PHP are often compiled at execution time these days, as far as I'm aware. (My knowledge of PHP in particular is all second hand. Maybe it's always been compiled... And likewise I'm sure there are web platforms which are still always interpreted.)
At least initially, a lot of the work done by backend code (which I assume is what you're talking about) was text-oriented. They either built pages directly from scratch, or by e.g. combining data from a database with a template.
C is not ... always well-suited for text processing. C strings are very basic, and while text processing in C of course can execute fast, it often takes a bit longer to develop, and requires somewhat deeper skills to get right, than languages that help you out a bit more.
Great question. The reason is basically due to the evolution of the web. Think about it in steps:
1) Basic text on the 'net' -> 2) Some 'markup' added to text -> 3) the "center" tag and "marquee" are formed!!! what progress!!! -> 4) scripting on the client!!! 5) -> hmm... scripting on the server!!!
While I formed this answer to be a bit goofy, it's really true. The interenet, and most especially the "web", has been an amazing evolutionary process. Really, requirements for more powerful languages (and more performant languages) has only been a more recent thing.
Also, look at the tools. I did my PHP in notepad (and some other simple apps). When I was first doing web development, my computer didn't have enough harddrive space to support Visual Studio 2008 :)
Side Point However: There have been ".exe" apps out there (I think "SunBiz" posts to an 'exe'), and some compiled cgi apps for a while, but they were much fewer.
It's worth pointing out that most scripting languages (Python, Ruby, etc.) bridge easily -- almost trivially -- to C. (I just wrote some C extensions for a Python program, and I was impressed with how easy it was.) If a website/web application does have some bottlenecks due to the use of a "slow" scripting language, one can usually write the performance-critical sections in a faster language like C. In fact, that's what large applications like Google search, Facebook, etc., do -- they write the interface in a scripting language and do the heavy lifting with other languages like C.
It is mostly because it is quick and simple to change them on the fly. Compiled languages require a development environment that must match the server. With a script you can use an ftp tool and edit the text directly and then save it. This ability to do this from any computer of any OS or type has save my life (or correctly my websites life) many times.
Try to do some string parsing/manipulation in C an in Perl/PHP and you will know.
BTW: Why do so many people state that performance is not an issue anymore? I might not be an issue for small homepages/blogs, but large scale web applications still need to be tuned for performance (cpu/network/memory) no matter if they are written in java, php or ruby.
Here are my thoughts on the issue:
- Original CGI applications required an OS process of their own, which is of course a resources hog. Trying to bundle everything into a single process is also not easy with native code, since if something goes wrong in an application could easily bring down the whole server. These things are much more easier handled with an Interpreter or a Virtual Machine. You can of course do the same with native code, but I suppose it would be much more difficult implementing the framework. At the end you will end up implementing something similar to an interpreter or a VM.
- Interpreted languages are portable across operating systems.
- Of course the great benefit is the productive boost you gain by using a modern language.
- Performance is of course important. However interpreted or VM languages are getting better and better in this respect (with technologies like JIT compilation) and are approaching the performance of native code. Also it isn't fair to compare only the time spent during execution process. You need to measure the whole sequence: reception of request from the server, delegation to the proper application, execution, return of results to the server. Would a native application be faster in all of these?
So, rather than focusing on C/C++ and saving every last CPU cycle, it makes more sense to worry about developer productivity. Developers are very expensive. And, they're typically much more productive in a scripting language or even in Java than they are in C/C++.
Oh, so very, very true. If the use of a more dynamic language shaves a developer-week off the schedule, that week of programmer time that you don't have to pay for will buy you an additional server. Maybe even multiple servers, if you like lots of cheap ones instead of a few massive beasts.
For most of the world (i.e., not Google/Amazon/eBay/etc.), one extra server will more than compensate for any loss of raw performance that may result from the language choice.
A lot of the extremely useful features of dynamic languages, such as introspection and functions like eval() are really difficult/impossible? to implement in languages that compile to native code.
That being said, most "scripting" languages do compile (on the fly) to some sort of intermediate code which is then interpreted (Python,Ruby,Perl) or maybe even JIT compiled to native code (JSP, .NET)
My company uses C++ (an ISAPI extension) for our webapp. Nearly everything is done in the compiled binaries. We also use a JavaScript engine for parts of the system that require scripting (yes, server-side JavaScript). The reason cited for this design is speed, but age is also a factor... this is an old codebase. Also, we distribute our product to some of our customers to host themselves, so having it compiled protects our source code (many interpreted languages are trivially decompilable, or in the case of PHP and Perl, never compiled at all).
Because the industry suffers from a mass delusion that execution speed does not matter (as demonstrated by the accepted answer).
I think the actual reason is that interpreted languages are easier to get started with if you use an existing framework and they make it seem easy and fun to work on a web application.
There are many, many cases where you do actually need to do number crunching in web applications, but developers end up either not doing them (because they are expensive) and/or delegate the task to an external server: either the database server or some other server.
This can be seen in the recent proliferation of so called "micro service" architectures.
Scripting languages where the only option for web development a long time ago. Now we have other alternatives (Java, .NET ..) so situation is not so bad.
C as a platform was not very successful for web development since it's hard to build a module that could be loaded and executed from web/application server, but one of the first framework for building dynamic web application was ISAPI modules for Microsoft's IIS that where mainly developed in C++ and where compiled.
来源：https://stackoverflow.com/questions/340298/why-are-so-many-web-languages-interpreted-rather-than-compiled