开发人员使用复杂JavaScript UI的方法
已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗?更新问题,使其仅通过编辑此帖子来关注一个问题。 6年前关闭。 我试图了解围绕复杂的客户端JavaScript开发的不同方法和最佳实践的前景。 我不确定用什么来标记此类应用程序,也许是沉重的AJAX或RIA(但不能像Flash / Silverlight这样的插件)。我指的是具有以下特征的Web应用程序: 在JavaScript中模拟丰富/本地桌面UX 使用服务器作为数据API(JSON / Html-Templates),包含客户端JS中的大多数/所有行为。 这与使用Web服务器进行UI呈现相反,后者以页面刷新模型生成所有HTML。 一些例子是: Google文件/ Gmail 迈德迈斯特 关键跟踪器 随着我们逐步进入HTML5,我可以看到这种带有大量JavaScript的RIA开发风格变得越来越普遍和竞争所必需。 问题:那么,围绕这些大量的JS开发进行管理的通用方法是什么? 随着应用功能的增加,客户端代码非常复杂。使用原始JS在多个团队之间扩展开发工作时遇到了问题(或者,我听到了,并且完全可以相信)。 Google通过构建可从高级语言(Java)编译为JS的GWT来解决此问题,它依靠高级语言具有的现有开发基础结构(Eclipse,强类型,重构工具)以及抽象的浏览器兼容性和开发人员无法解决的其他问题。 还有其他工具,例如用于C#的Script#,其功能也类似。所有这些使JS更加具有IL(中间语言)的作用。即。“您再也不会真正用这种'低级语言'来写作了。” 但是,这种“编译为JS”并不是唯一的方法。尚不清楚GWT是占主导地位的方法...或确实会成为它。 人们在使用富客户端JavaScript做什么?一些定向问题: 大多数商店都在手工制作JS(在jQuery等类似的库上面)吗? 还是有许多不同的方法,没有明确的最佳实践? 大多数商店是否都在避免RIA规模开发,而转向更简单的开发人员服务器端/页面重绘模型?如果是这样,这会持续吗? 编译为JS可能是一种新兴的未来趋势吗?还是这是错误的方向? 他们如何管理客户端JS的复杂性和重构? 跨团队模块化和分配工作? 客户端模式(例如MVC / MVP等)的应用,实施和测试。 那么,在我们这个庞大的JavaScript和HTML5未来中,新兴趋势是什么? 谢谢!