为什么像C这样的语言最终不能用于Web开发？当然，编译后的速度提高对重负载站点有用吗？

另一个很好的原因是，在一个大的服务器上，执行速度并不是一个问题，而是连接速度。大部分时间都花在发送和接收数据上，而不是处理数字。实际上，在进行大量计算的某些Web服务中，硬计算可能作为编译程序运行。

另外，解释语言不需要编译(在大型项目中编译可能需要一些时间)，因此它更适合于Web解决方案的典型敏捷开发。

大多数Web应用程序都与数据库通信。绝大多数应用程序几乎全部时间都在与数据库通信。因此，对于应用程序的任何给定请求，应用程序服务器中都有少量的处理，然后在等待数据库时会有很长的停顿。由于任何请求的时间在实际应用程序服务器代码中所占的百分比很小，因此通过在C/C++中编写该代码来优化该代码只会在响应时间上获得一个微小的、可能不明显的改进。

因此，与其关注C/C++和节省每一个CPU周期，更担心开发者的生产力。开发人员非常昂贵。而且，它们在脚本语言中甚至在Java中比在C/C++中更具生产力。

当然，也有例外。如果对应用程序的一些请求是CPU或内存密集型的，它们应该用C/C++编写。但是，对于应用程序的其余部分，您最好集中精力优化算法、数据结构、与数据库的通信以及开发人员的工作效率，而不是优化语言。

脚本语言比C有以下优势：

C在早期用于Web应用程序——我在其中编写了各种CGI脚本。

然而，随着时间的推移，更有效的语言(例如C语言和Java语言，但不完全是这些语言)已经被证明是"足够有效"的Web应用程序。注意，C语言和Java都编译为中间代码，然后编译JIT，实现"粗略"的本机代码性能。为什么我们要用C来代替？

据我所知，即使是传统的"真正解释"语言(如PHP)也经常在执行时编译。(尤其是我对PHP的了解都是二手的。也许它总是被编译的…同样地，我相信还有一些Web平台仍然可以被解释。)

好问题。原因主要是由于网络的发展。分步思考：

1)"net"上的基本文本->2)一些"markup"添加到文本->3)"center"标签和"marquee"已形成！！！！多大的进步！！！！->4)在客户端上编写脚本！！！！5)->嗯……在服务器上编写脚本！！！！

虽然我的回答有点愚蠢，但这是真的。Internet，尤其是"Web"，是一个惊人的进化过程。实际上，对更强大的语言(和更高性能的语言)的需求只是最近才出现的事情。

另外，看看这些工具。我在记事本(和其他一些简单的应用程序)中使用了PHP。当我第一次进行Web开发时，我的计算机没有足够的硬盘空间来支持Visual Studio 2008:。

然而，附带的一点是：已经有了".exe"应用程序(我认为"sunbiz"发布到了"exe")，还有一些编译了一段时间的CGI应用程序，但它们要少得多。

至少在最初，后端代码所做的很多工作(我假设这就是您所说的)都是面向文本的。他们要么直接从头开始构建页面，要么通过将数据库中的数据与模板组合起来。

C不是…总是非常适合文本处理。C字符串是非常基本的，虽然C语言中的文本处理可以快速执行，但通常需要更长的时间来开发，并且需要一些更深入的技能才能正确执行，而不是帮助您完成更多任务的语言。

值得指出的是，大多数脚本语言(python、ruby等)都可以很容易地——几乎非常简单地——连接到C(我刚刚为一个python程序编写了一些C扩展，我对它的简单性印象深刻。)如果一个网站/Web应用程序确实由于使用了"慢"脚本语言而存在一些瓶颈，那么人们通常可以编写性能以更快的语言(如C)编写关键部分。事实上，这正是大型应用程序(如谷歌搜索、Facebook等)所做的——他们用脚本语言编写界面，并用其他语言(如C)完成繁重的工作。

尝试在perl/php中的c-an中进行一些字符串解析/操作，您就会知道。

顺便说一句：为什么这么多人说绩效不再是问题？对于小型主页/博客，我可能不是一个问题，但不管是用Java、PHP还是Ruby编写的，大型Web应用程序仍然需要调整性能(CPU /网络/内存)。

这主要是因为它是快速和简单的改变他们的飞行。编译语言需要与服务器匹配的开发环境。使用脚本，您可以使用FTP工具直接编辑文本，然后保存它。这种从任何操作系统或类型的计算机上执行此操作的能力多次拯救了我的生命(或正确地拯救了我的网站生命)。

动态语言的许多非常有用的特性，比如内省和eval()之类的函数，真的很难/不可能实现？以编译为本机代码的语言实现。

也就是说，大多数"脚本"语言都会(即时)编译成某种中间代码，然后将其解释为(python、ruby、perl)，甚至可以编译成本地代码(jsp、.net)。

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++.

号

哦，非常非常真实。如果使用更动态的语言会使开发人员一周的工作时间偏离计划，那么您不必支付的那一周的程序员时间将为您购买额外的服务器。如果你喜欢很多便宜的服务器，而不是一些大型的服务器，甚至可能是多个服务器。

对于世界上大多数国家(例如，不是Google/Amazon/eBay/etc)，一个额外的服务器将弥补由于语言选择而导致的原始性能损失。

以下是我对这个问题的看法：

• 最初的CGI应用程序需要自己的操作系统进程，这当然是一种资源占用。在本机代码中，尝试将所有内容捆绑到一个进程中也是不容易的，因为如果应用程序中出现问题，很容易导致整个服务器停机。使用解释器或虚拟机更容易处理这些事情。当然，您也可以对本机代码进行同样的操作，但我认为实现该框架将更加困难。最后，您将实现类似于解释器或VM的东西。
• 解释的语言可以跨操作系统移植。
• 当然，最大的好处是你使用现代语言所获得的生产力提升。
• 性能当然很重要。但是，在这方面，解释语言或虚拟机语言越来越好(使用诸如JIT编译之类的技术)，并且正在接近本机代码的性能。此外，只比较执行过程中花费的时间也是不公平的。您需要测量整个过程：从服务器接收请求、委派到适当的应用程序、执行、将结果返回到服务器。本地应用程序在所有这些方面都会更快吗？

因为业界普遍认为执行速度并不重要(正如公认的答案所证明的那样)。

我认为真正的原因是，如果您使用现有的框架，那么解释语言就更容易入门，而且它们使在Web应用程序上工作看起来既简单又有趣。

在许多情况下，您确实需要在Web应用程序中执行数字处理，但开发人员最终要么不执行这些操作(因为成本高昂)，要么将任务委托给外部服务器：数据库服务器或其他服务器。

这可以在最近所谓的"微服务"体系结构的激增中看到。

我的公司使用C++(一个ISAPI扩展)为我们的WebApp。几乎所有的工作都是在编译后的二进制文件中完成的。我们还为系统中需要脚本的部分使用了一个javascript引擎(是的，服务器端的javascript)。这项设计引用的原因是速度，但年龄也是一个因素…这是一个旧的代码库。此外，我们还将产品分发给我们的一些客户，让他们自己托管，因此编译它可以保护我们的源代码(许多解释语言都是微不足道的可编译语言，或者在PHP和Perl的情况下，根本不编译)。

脚本语言是很久以前Web开发的唯一选择。现在我们还有其他的选择(Java，.NET)，所以情况并不太糟。< BR>

C作为一个平台并不是非常成功的Web开发，因为它很难建立一个模块，可以加载和执行从Web /应用服务器，但第一个框架，建立动态Web应用程序的ISAPI模块为微软的IIS，其中主要是在C++开发和编译。