代码之家 › 专栏 › 技术社区 › Emma

AJAX崩溃,服务器端和客户端脚本之间的界限?

ajax javascript php

Emma · 技术社区 · 15 年前

我已经开发了我的第一个基于web的应用程序大约两个月了(我是一个本科生,对C和Python有着丰富的经验,在启动时加入了一些Java)。到目前为止,我的页面是一个精简的HTML布局(thin意味着一个非常简单的布局,也就是不到50行HTML),它主要使用jQuery,由AJAX进行大量操作。AJAX是通过生成的。PHP与SQL操作的结合。这个webapp最多可被6-10个客户端(编辑:用户)使用,跨浏览器兼容性只是一个额外的好处;看来IE7是最薄弱的环节。

web开发的未来是否真的像我想象的那样向浏览器和平台的方向发展?根据我的经验,用JS编写客户端脚本似乎是一个相当不错的GUI工具包,AJAX将其作为一个易于使用的数据访问层进行备份。
显然,服务器端脚本将一直占据一席之地。服务器端真正的亮点在哪里?如: c) 创建可以在iframe中使用的完整页面。

1 回复 | 直到 15 年前

Benoit 15 年前

在业界,Ajax和客户端脚本的使用与GUI或可用性工具一样是一个生产力和可维护性问题。有时只获取部分内容比获取所有内容更容易(尤其是在MVC服务器环境中)。但这几乎是观点的问题

对我来说,在客户端使用繁重的javascript(比如用JS构建所有的GUI)与从服务器上提供HTML页面相比,主要的缺点是无法控制错误、小的图形错误、环境差异等。最终你就像一个分发桌面应用程序的软件供应商,您无法真正控制客户端的可用性。您应该尝试这两种技术,使用Ajax并不总是最好的,有时它可以挽救您的生命(去构建一个动态树,其中包含多个选择和数百万个只包含HTML的分支)。
业务层对我们来说太重要了,不能依赖浏览器来处理它。数据存储在同一位置(对我来说也是),它必须保存在服务器上。
服务器端在我下面提到的所有阶段都很出色,但对于数据传输格式,我更喜欢直接将HTML传输到浏览器,或者使用JSON来传输任何其他需要传递的结构化数据。对于轻量级客户机来说,使用XML似乎有点冗长。如果你能避免iframe,那么就去做吧,在我见过的99.9%的案例中没有理由使用它们。

作为结论,你是学生,学习有趣的东西。如果你想提高你在客户端的知识,那就去做吧,这里有很多东西要学(HTML解析器,DOM和jsapi,浏览器内部对我来说真的很有趣)。

但你必须知道,在我工作过的公司中,web有两种含义:通信和对业务应用程序gui的支持。我目前为web应用程序(intranet)工作,我们有3个前端开发人员在做PHP和javascript,还有20个人在做服务器端Java。只是为了让你在专业的大规模应用程序的GUI所占的位置。