为什么Web框架不像编程语言那样简单,优雅且有趣?[关闭]


10

当我想到几乎任何编程语言(例如C,C ++,PHP,SQL,JavaScript,Python,ActionScript,Haskell,Lua,Lisp,Java等)时,我都很棒,我很乐意使用任何一种语言来开发计算机应用程序这些语言。

但是,当我想到Web框架(我大部分都使用PHP)时,例如Cake,CI,Symfony,Laravel,Zend,Drupal,Joomla,Wordpress,Rails,Django等,我就像是上帝。

为什么没有提供像编程语言一样为我提供简单,有趣和强大功能的Web框架?


2
“我非常喜欢使用任何一种语言来开发计算机应用程序,” 您是其中任何一种语言的大师吗?因为任何知道自己在做什么的人都不会告诉您任何语言都是优雅或有趣的。它们只是实现您的目标的工具,而工具有其问题和缺陷。
欣快感,2013年

14
@Euphoric我有10年的经验,对此表示反对。一些语言有趣。其他人很痛苦。还有一些精心设计的也很优雅。但是,我确实同意他们都有自己的问题。
2013年

@Izkata每个人都十年?
2013年

5
@Euphoric在少数几种语言中大约有10年,但所有类型却截然不同(按C与Javascript的顺序排列),还有大约3年。我已经使用了问题中提到的三分之一,还有更多未提及的问题(包括我最喜欢的Rebol)。例如,对我来说,Javascript和Rebol是“有趣”的语言,而Rebol和Lisp是“优雅”的(我听说Haskell也是如此,但我不知道)。如果您使用足够多的语言,并且碰到它的优点和缺点,那么这些“有趣”和“优雅”的观点很快就会自行形成。
2013年

4
编程语言中基本的原子概念的数量很少且易于理解,因此可以很容易地围绕此类概念构建精美的工具。操作最简单的Web交互所需的不可简化的概念的数量要大得多。复杂的问题不可避免地产生了复杂,丑陋的解决方案。
SK-logic

Answers:


19

即使我站在Python方面,我也有多年这个问题。对于这种现象,我没有一个单一的解释,但这是我对这个问题的看法:

  • Web框架必须使用客户端服务器方式处理XMLish标记语言-HTML,这是当前Web三合一HTML-CSS-JavaScript的一部分。它表示三种语言,它们彼此交互,一个浏览器DOM和执行模型(和安全模型)。实际上,每个功能(“模块”)的所有三种语言都应具有其代码。除此之外,jQuery的选择器语言正在成为另一种需要关注的语言。

  • HTML + CSS缺乏用于放置对象的直观且数学上合理的模型。甚至Tcl / Tk在定义几何图形管理器方面也是恕我直言的。这阻止了程序员严格地定义HTML呈现,而是依靠运气:“也许这个div在大多数浏览器中大部分时间都可以工作”。但是在这方面也有一些积极的发展,例如HTML5和Twitter Bootstrap。

  • Web技术已经有机地增长了,框架也随之发展了,因此它们的形状不一定是优雅的。这意味着程序员应该记住那些次优的API,将不推荐使用的API等。

  • Web浏览器确实仍然存在一些不兼容性,并且为Web框架增加了不必要的复杂性

  • 整体架构一团糟。这是后端和前端的分离思想,它们与后端的请求/响应以及前端的数据驱动的渲染捆绑在一起。执行顺序不是很明确(同步需要努力),并且需要放置样式,将脚本放置到适当的位置(几乎所有js脚本都需要放置在body标签的末尾,依此类推)。缓存是又一个方面,从后端到代理再到前端。而且我什至不提表格处理!

  • Web框架必须通过添加许多概念和处理管道来应对其中的大多数复杂性。

  • 在Web行业中,通常将图形设计人员,Web设计人员/ Web程序员和后端程序员之间的工作划分为最少的角色集。前两个不一定具有编程技能,因此它们需要不同的抽象和工具,并且框架也应为它们提供便利

总而言之,Web框架试图抽象出很多复杂性(本身就越来越复杂),但是由于标准和其他活动部件的快速发展,很难实现。编程语言更加成熟,因为不使用新功能通常不是问题。

我认为,只有在GUI标准到位(覆盖不同的操作模式,例如移动设备)并且基础技术足够稳定之后,才能实现方便的Web框架。

Web框架缺乏简单的构造,因为Web技术领域没有这种东西。较低级别的抽象必然会泄漏到较高级别。


3

我认为这很大程度上与WWW的局限性有关。具体来说,在服务器和客户端之间没有内置的状态存储方式。客户端请求一些数据,服务器提供该数据,并且连接已关闭。因此,所有这些Web平台都必须组合使用自己的方法来保持服​​务器调用之间的状态。

我不得不做一个小型的Web应用程序,那时我从未做过任何服务器/客户端编程。我花了几周的时间才弄清楚这一切,最困难的部分是试图让我一直在跟踪客户端和服务器的位置。

这会改变吗?我对此表示怀疑。这将需要对网络架构进行根本性的改变。


2

一般来说,原因可能有多种:

  1. 在框架情况下,抽象差距更大。现代的过程/ OOP语言提供了对机器的抽象,但是保留了一些机器构造(例如,为变量分配一些数据/在存储单元中写入一些数据或调用过程等);差距不是很大,而框架试图为开发具有更多概念的Web应用程序提供抽象。
  2. 从程序员的角度来看,框架可能会更复杂。这就像第一点的结果。编程语言相当简单,它具有简单的构造(例如,对于变量,过程等)。此外,标准库还抽象了一些简单的事情,例如写入IO或使用集合。它的标准库也非常模块化,几乎没有或没有模块之间的连接。您无需了解IO即可使用集合,反之亦然。要注意的是,如果标准库的某些部分相当复杂,则将它们放置在微型框架中(例如Java Collections Framework或Executors框架)。在框架的情况下,您需要了解整个流程,所有部分,以便充分利用框架。同样,框架是已经构建的应用程序。
  3. 没有像编程语言那样投入框架的资源太多了。我相信这不需要任何解释。

0

嗯,但是您看到的正是问题所在。框架不应该是图灵完整的。它们应该由更严格的抽象组成,这些抽象可以组合在一起以简洁的方式执行一组特定的任务。因此,您提到的所有这些框架都不是很有趣,因为它们没有提供一组受限制的抽象。它们提供的泄漏抽象比它们本身组成的抽象机器更可能是图灵完整的。“ 怪异的机器 ” 的概念是我想到的最接近的东西。所有这些框架都是用于Web应用程序的“怪异机器”,而“怪异机器”与框架应有的相反。


1
我给出+1的原因是,尽管帖子内容繁琐,但正确的是框架不一定是图灵完备的。这是一种完整的通用语言的吸引力之一,如果您知道怎么做,便可以执行任何操作。
2013年
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.