【问题标题】:Alternatives to JavaScriptJavaScript 的替代品
【发布时间】:2009-05-30 22:06:09
【问题描述】:

目前,在浏览器中唯一完全支持的语言和事实上的 DOM 树操作标准是 JavaScript。看起来它有很深的设计问题,使其成为新手的错误和安全漏洞雷区。

您是否知道任何现有的或计划的倡议,以在下一代浏览器中为 DOM 树操作和 HTTP 请求引入一种更好的(重新设计的)语言(不仅仅是 javascript)?如果是,那么将它集成到 Firefox 等的路线图是什么?如果不是,出于什么原因(除了互操作性)JavaScript 应该是浏览器平台上唯一支持的语言?

我已经使用过 jQuery,并且还阅读了“javascript: the good parts”。确实这些建议很好,但我无法理解的是:为什么只有 javascript?在服务器端(您最喜欢的操作系统平台),我们可以使用每种语言(甚至是 fortran)操作 DOM 树。为什么客户端(浏览器平台)只支持javascript?

【问题讨论】:

  • Google Dart、Script#、CoffeeScript、JSX(两种不同的 JS 实现)、JavaScript Harmony 等。更多信息请参阅此链接github.com/jashkenas/coffee-script/wiki/…
  • "为什么只有 javascript?在服务器端(你最喜欢的操作系统平台),我们可以用每种语言操作 DOM 树,甚至是 fortran。为什么客户端(浏览器平台)只支持javascript?”在服务器端,你可以安装任何你想要的东西,但我不能强迫你的客户安装额外的插件/插件,如果我们有这么多的 javascript 错误和安全问题,猜猜如果我们会有多少错误和安全问题我们再添加几个?
  • @Peter 我不知道你的论点是认真的还是开玩笑的。如果他们愿意,人们可以很容易地安装平台。如果 Javascript 的替代品可用并且运行良好,那么商业提供商将只要求用户下载运行它所需的任何东西——就像他们一直使用 Flash 所做的那样,就像他们曾经使用 Silverlight 所做的那样。在客户端可能不会出现替代方案的所有原因中,确保您的用户拥有您的平台的困难并不是其中一个重要的原因。
  • @ely:结果很好?闪光? Java小程序?银光?我什至没有安装过 Silverlight 的实例。
  • @SebastianMach 是的,这些第三方运行时运行得非常好,并为他们的上级组织带来了大量的市场份额和回报。事实上,我想说 DRM 技术可能是最成功的(从公司的角度来看)运行时框架,它现在比以往任何时候都更大,在浏览器和其他地方。关于这一论点要考虑的另一件事是,任何人都可以创建浏览器运行时环境来操作 DOM。用不同的语言变体来做这件事是不值得的。 Javascript 只是意外地赢得了土地抢夺。

标签: javascript browser


【解决方案1】:

javascript 的问题不在于语言本身——它是一种完美的原型和动态语言。如果您来自 OO 背景,则有一点学习曲线,但这不是语言的错。

大多数人认为 Javascript 类似于 Java,因为它具有相似的语法和相似的名称,但实际上它更像 lisp。它实际上非常适合 DOM 操作。

真正的问题是它是由浏览器编译的,这意味着它的工作方式因客户端而异。

不仅实际的 DOM 因浏览器而异,而且在性能和布局方面也存在巨大差异。


编辑以下有问题的说明

假设支持多种解释语言 - 你仍然有同样的问题。各种浏览器仍然会出现问题并且具有不同的 DOM。

此外,您还必须在浏览器中内置一个解释器,或者以某种方式安装为每种语言的插件(您可以在提供页面之前对其进行检查)。使 Javascript 保持一致需要很长时间。

您不能以相同的方式使用编译语言 - 那么您引入的可执行文件不能轻易地被审查它的作用。很多用户会选择不让它运行。

好的,那么对于已编译代码的某种沙箱呢?对我来说听起来像 Java Applets。或 Flash 中的 ActionScript。或者 Silverlight 中的 C#。

那么某种 IL 标准呢?那更有潜力。用你想要的任何语言进行开发,然后将其编译为 IL,然后由浏览器进行 JIT。

除了,Javascript 已经是那种 IL - 看看 GWT。它允许您用 Java 编写程序,但将它们分发为 HTML 和 JS。


在进一步澄清问题后进行编辑

Javascript 不是,或者更确切地说,不是,浏览器支持的唯一语言:回到 Internet Explorer 的黑暗时代,您可以选择 Javascript 或 VBScript 在 IE 中运行。从技术上讲,IE 甚至没有运行 Javascript——它运行了JScript(主要是为了避免向 Sun 支付 java 这个词,Oracle 仍然拥有 Javascript 这个名称)。

问题在于 VBScript 是 Microsoft 专有的,但也不是很好。虽然 Javascript 在其他浏览器(如 FireBug)中添加了功能并获得了顶级调试工具,但 VBScript 仍然仅限 IE 并且几乎不可调试(IE4/5/6 中的开发工具不存在)。同时 VBScript 也扩展成为操作系统中非常强大的脚本工具,但这些功能在浏览器中都不可用(并且当它们成为巨大的安全漏洞时)。

仍有一些公司内部应用程序使用 VBScript(有些依赖于这些安全漏洞),并且它们仍在运行 IE7(它们只是停止了 IE6,因为 MS 最终将其杀死)。

让 Javascript 达到目前的状态一直是一场噩梦,花了 20 年的时间。它仍然没有一致的支持,一些浏览器仍然缺少语言功能(1999 年指定)并且需要大量的填充程序。

在浏览器中添加另一种解释语言面临两个主要问题:

  • 让所有浏览器供应商实施新的语言标准——这是他们 20 年来仍未为 Javascript 实现的目标。

  • 1234563我真的不想为不同的浏览器编写不同语言的代码。

值得注意的是,Javascript 并未“完成”——它仍在不断发展,以在新的浏览器中变得更好。 latest version 比浏览器的实现提前了好几年,他们正在开发下一个。

【讨论】:

  • 我会说它是“解释的”,而不是浏览器“编译的”。
  • 较新的浏览器在 JavaScript 上进行 JIT 编译。
  • 我还搜索了 jit 声明,结果表明,Firefox 3.1 将内置支持。查看andreasgal.com/2008/08/22/tracing-the-webpeople.mozilla.com/~schrep/tm-image-adjustment.swf
  • V8 JavaScript 引擎(chrome)直接编译。
  • 我非常不同意您的第一个回答“JavaScript 的问题不在于语言本身”。我认为它在语法上是一种非常丑陋的语言,并且缺乏您从大多数其他语言中获得的功能。至少我在大型应用程序中仍然需要的功能(加载依赖项,可读 OO 原则)。如果我们现在必须这样做(互联网),我认为 JavaScript 不会是一种语言的“最佳”选择。
【解决方案2】:

编译成Javascript

目前,使用编译为 Javascript 的语言似乎是在编写更智能代码的同时覆盖所有平台的唯一现实方法,而且这种情况很可能会持续很长时间。对于任何新产品,总会有一些原因导致一个或多个供应商不急于发货。

(但我真的不认为这是一个问题。Javascript 现在已经很好地优化了。如果手动编写机器代码也是不安全的,但作为编译目标和执行语言可以正常工作。)

这么多选择

有越来越多的语言可以编译成 Javascript。在这里可以找到一个相当全面的列表:

值得注意的

我会提到一些我认为值得注意的(当然忽略了一些我不知道的宝石):

  • Spider 出现在 2016 年。它声称吸收了 Go、Swift、Python、C# 和 CoffeeScript 的最佳思想。它不是类型安全的,但确实有一些较小的 safety features

  • Elm:Haskell 可能是所有语言中最聪明的语言,而 Elm 是 Haskell for Javascript 的变体。它具有高度的类型意识和简洁性,并提供 函数式反应式编程 作为反应式模板或 MVC 意大利面条的简洁替代品。但这对于程序程序员来说可能是相当震惊

  • Google 的Go 旨在简洁、简单和安全。 Go代码可以通过GopherJS编译成Javascript。

  • Dart 是 Google 后来尝试替换 Javascript。它通过类似 C/Java 的语法和可选类型提供接口和抽象类。

  • Haxe 类似于 Flash 的 ActionScript,但它可以针对多种语言,因此您的代码可以在 Java、C、Flash、PHP 和 Javascript 程序中重复使用。它提供类型安全的动态对象。

  • Opalang 将语法糖添加到 Javascript 以提供直接数据库访问、智能延续、类型检查和协助客户端/服务器分离。 (绑定到 NodeJS 和 MongoDB。)

  • GorillaScript, “一种编译为 JavaScript 的语言,旨在为用户提供支持,同时尝试防止一些常见错误。” 类似于 Coffeescript,但更全面,提供了一堆增加安全性并减少重复样板模式的额外功能。

  • LiteScript 介于 Coffeescript 和 GorillaScript 之间。它为“内联”回调提供 async/yield 语法,并检查变量拼写错误。

  • Microsoft 的 TypeScript 是 Javascript 的一个小型超集,可让您对函数参数设置类型限制,这可能会捕获一些错误。同样,BetterJS 允许您应用限制,但在纯 Javascript 中,可以通过添加额外调用或通过在 JSDoc cmets 中指定类型。现在 Facebook 提供了Flow,它还可以执行类型推断。

  • LiveScript 是 Coffeescript 的衍生产品,因其简洁而广受欢迎,但对我来说看起来不太可读。可能不是团队的最佳选择。

如何选择?

选择替代语言时,有一些需要考虑的因素

  • 如果将来有其他开发人员加入您的项目,他们需要多长时间才能加快速度并学习这门语言,或者他们已经知道这门语言的机会有多大?

  • 语言的功能是否太少(代码仍然充满样板)或功能太多(需要很长时间才能掌握,在此之前某些有效代码可能无法解读)?

  • 它是否具有您项目所需的功能? (你的项目需要类型检查和接口吗?它是否需要智能延续来避免嵌套回调地狱?是否有很多反应性?将来可能需要针对其他环境吗?)

未来...

Jeff Walker 写了 a thought-provoking series 的关于“Javascript 问题”的博客文章,包括为什么他认为 TypeScriptDartCoffeescript 都没有提供足够的解决方案。他在the conclusion 中提出了一些改进语言的理想特性。

【讨论】:

  • ES6 扩展了 Javascript 的一系列特性,允许更清晰地指定类,并通过生成器“内联异步”。不过仍然是动态类型的!
  • Elm 的方法类似于 Nitrogen 或 N2O(erlang 框架),这就是我喜欢它的原因。
  • 现在我们在 ES8 和 TypeScript 以及 async-await 中有一些 CoffeeScript 的语法糖。 TypeScript 防止了我工作场所的很多错误,尽管仍有一些惊喜的机会!
  • 现在还有Wasm,它允许各种其他语言在浏览器中运行。但是与 DOM 的通信仍然通过 JavaScript。
【解决方案3】:

JavaScript 应该是浏览器平台上唯一支持的语言吗?

是和不是。有一个替代方案,称为 Dart by Google,它可以编译为 JavaScript,就像 jQuery 一样,它试图使 DOM 操作更容易一些。尝试一下可能会很有趣,看看吧。

另见

【讨论】:

    【解决方案4】:

    确实,Javascript 在某一时刻是出了名的难以处理,但从那时起 Web 开发社区已经走了很长一段路。相反,我鼓励您查看jQuery。它很简单,并且可以抽象出所有各种问题。

    而且确实没有其他选择可以全面发挥作用。 Flash 浮现在脑海,但它也是 ECMA 脚本,对于大多数事情来说它可能已经过时了。

    【讨论】:

    • 或 MooTools、Prototype 和 Dojo。 jqueryvsmootools.com 是 mootools 和 jquery 之间的一个很好的比较。
    • Javascript 本身没有/没有任何问题。您可能指的是 IE 的 JScript 中的问题以及一般呈现问题以及与各种浏览器的不一致。
    【解决方案5】:

    短期内,我会使用 jQuery 之类的东西来隐藏浏览器的不兼容性。从长远来看,Silverlight 或 Adob​​e AIR 等技术可能会在未来使其成为一个非常不同的雷区(但仍然是一个雷区)。

    【讨论】:

    • +1 用于使用 jQuery 隐藏浏览器不兼容问题。我读了一本书,解释了其中一些机制是如何工作的,当我说 jQuery 正在为这个部门的程序员省去头痛时,我相信我。
    • 事后看技术答案总是一种奇怪的看法。现在我们知道 web 赢了:silverlight、flash 和 air 都死了,剩下的胜利者是 javascript 的所有奇怪而美妙的咒语。
    【解决方案6】:

    Doug Crockford gave a talk to Google 详细介绍了 JavaScript 的优缺点及其未来。自 1999 年以来,它实际上并没有太大变化——这可以说是一件好事(几乎所有浏览器都可以运行相同的代码,只要你知道它们的局限性),Doug 展示了好的部分在哪里主要是误解,结果非常强大。

    对于 DOM 操作,将 JQuery 视为一个客户端库,它用那些难以编写的操作来替换大部分糟糕的 DOM API。

    【讨论】:

      【解决方案7】:

      如果您认为 JavaScript 存在严重问题,我推荐 Doug Crockford 的书,JavaScript: The Good Parts。 (或在 Google 中搜索“Crockford JavaScript”以查找他完成的几个视频演示。)Crockford 勾勒出一个安全的子集和一组实践,并特别列出了要避免的语言的一些部分。

      我不知道将 JavaScript 替换为操作 DOM 的事实上的手段的计划。所以最好学会安全和良好地使用它。

      【讨论】:

      • 再读一遍。很明显,他在阅读答案后编辑了他的问题。
      【解决方案8】:

      就客户端而言,Javascript 是操作 DOM 的唯一方法。在服务器端有多种方式。

      【讨论】:

        【解决方案9】:

        Internet Explorer 支持可插入的脚本语言,尽管除了 JScript 之外,IE 中唯一可靠的语言是 VBScript。

        据我所见,浏览器中似乎普遍存在对动态语言的偏见,而 JavaScript 似乎足以满足这一需求,以至于网络效应使任何其他语言都无法入门。该语言实际上非常强大,尽管它在浏览器中的实现还有很多不足之处。

        【讨论】:

        • 不要在 IE 中使用 VBScript - 这是一些可怕的 VB 变体,大 MS 认为会起飞但没有。它实际上不像普通的 VB 或 VBScript 那样工作,而且比 Javascript 慢。
        • WebKit 或 Gecko 的 JavaScript/ECMAScript 实现在非浏览器实现中缺少什么?这个评论让我很困惑。
        【解决方案10】:

        如果您愿意将您的客户/访问者限制在特定的浏览器中,并且可能愿意要求他们安装插件,您可以查看MS Silverlight——wikipedia 上有一个可读的概述。使用 Silverlight 2,您可以在客户端运行您用 C#、IronPython、IronRuby、VB.NET 等编写的代码;来自 Mono 项目的 Silverlight 的免费 Moonlight 克隆,承诺为 Linux 带来相同的功能。

        在实践中,大多数网络应用程序和网站的开发人员更愿意接触比 Silverlight(最终是 Moonlight)目前所能提供的更广泛的受众——这意味着坚持使用 Javascript 或可能的 Flash(它使用类似的编程语言 Actionscript)。

        因此,事实证明,即使对于拥有大量工程师和营销预算的免费软件项目的 Microsoft 来说,获得大量的思想份额、采用和牵引力也是一场艰苦的战斗(可能减轻对专有锁定的担忧)——这可能有助于解释为什么兴趣很少,例如就 Mozilla 基金会而言,在推动这一目标的过程中。 “除了互操作性”,您说:但很明显,互操作性问题是这里的大问题,因为我们观察到 Silverlight 的进展......

        【讨论】:

          【解决方案11】:

          如前所述,您有 Flash(ActionScript,它是 Javascript 的派生语言)和 Silverlight/Moonlight(IronPython、IronRuby、JScript、VBScript、C#),它们可以通过插件在浏览器中运行(第一个是很多更普遍)。

          如果您喜欢 Ruby,还有另一种选择:HotRuby,它是在浏览器中运行的 javascript 中的 ruby​​ 实现。还不是很成熟,不过大家可以看看。

          【讨论】:

            【解决方案12】:

            我没有看到提到的一件事(哦,我看到 Alcides 在我写作时提到了 HotRuby,而 Nosredna 提到了 GWT 和 Script#)并且想抛出的是 [插入语言] 的许多实现-on-JavaScript(例如,允许您将RubyPythonC#JavaObj-J/Cappuccino [类似于 Obj-C/Cocoa] 或 Processing [for Canvas] 转换为JavaScript 在客户端或部署之前 [其中一些还具有各种抽象库])。当然,如果在客户端上翻译它会产生性能开销,但如果您更熟悉另一种语言,它会给您带来一定的灵活性。

            不过,就我个人而言,我建议学习爱上 JavaScript。它是一种优秀、强大的语言,一旦你了解它就会非常优雅。我正面临着相反的困境,急切地想要拥有一个能够满足我所有需求的功能强大的服务器端 JavaScript/DOM 解决方案。 /不请自来的意见

            【讨论】:

            • 我提到了 GWT 和 Script#。对于那些对脚本#感兴趣的人,链接是projects.nikhilk.net/ScriptSharp
            • 感谢您将我指向 Obj-J/Cappuccino。创建网络应用程序真是太棒了,我只是因为你提到它而打开它,而且它的名字(和可可相关性)引起了我的兴趣。
            【解决方案13】:

            JavaScript 是网络的英语语言。英语在历史上传播开来,是因为它拥有强大的海军征服各个国家。这可以与用 JavaScript 征服网络的大公司相媲美。它是一种从多个欧洲来源(希腊语、拉丁语、日耳曼语、法语甚至一些中文和印度语)拼凑而成的语言。多年来,JavaScript 从其他语言(结构、OO、函数)中借鉴了许多概念。英语在不同的地方使用,方言和口音略有不同,这可能会使理解变得困难。就像 JavaScript 有不同的浏览器解释它有点不同。

            尽管英语最初很容易学习,但它的发音非常不一致,并且例外多于规则。就像 JavaScript 一样,它总是能提供惊喜。

            尽管口音不同,JavaScript 是网络的通用语。就像您可能不是英语并在这里用英语写作一样,每个网络浏览器都有一定程度的英语理解。 IE6 就像那个人在简历上说自己流利,但只参加了为期两周的英语作为外语课程。

            有人试图取代英语成为世界主要语言,例如世界语。但他们都失败了,因为地球上大多数人都会说一些英语。同样,也很难引入更好的 JavaScript 替代方案。

            【讨论】:

              【解决方案14】:

              Jquery(仍然是 javascript,但是)它真的会帮助你他们支持几乎所有的浏览器,而且学习起来并不难:)

              【讨论】:

                【解决方案15】:

                没有。 JavaScript 就是它,但它会发展。下一个版本是“JavaScript Harmony”,您可以通过 Google 了解更多信息。

                有时有人建议将字节码解释器与 JavaScript 一起放入浏览器。可能不会发生,至少暂时不会。

                我碰巧喜欢 JavaScript。但还有其他解决方案,包括将 Java 编译为 JavaScript 的 GWT 和将 C# 编译为 JavaScript 的 Script#。

                【讨论】:

                  【解决方案16】:

                  我认为 Javascript 不会很快被取代。对于富客户端的完全不同方法,您可能需要研究 Flex,它是一种基于 Flash 的技术。

                  【讨论】:

                    【解决方案17】:

                    也许像 haxe(参见 haxe.org)这样的东西可以帮助你。它是一种看起来比 JavaScript 更干净的语言,并且可以编译成 JavaScript,因此它可以在浏览器中运行。

                    我知道这不是对您问题的直接回答,但我认为这对您来说可能很有趣。

                    【讨论】:

                      【解决方案18】:

                      很多人都知道 Javascript 并不是最好的和最漂亮的语言。但是,目前浏览器都支持它,因此很难引入不同的语言。我们根本不需要另一场浏览器大战。

                      这解释了为什么我知道没有切换到其他客户端语言的计划。

                      但如果您开始考虑 DOM 模型以及如何使用它,我认为 Javascript 并不是那么糟糕。很多 JS 乱七八糟的东西都是 DOM 模型工作方式的结果。

                      【讨论】:

                        猜你喜欢
                        • 2012-04-08
                        • 2012-06-13
                        • 1970-01-01
                        • 1970-01-01
                        • 2013-03-07
                        • 1970-01-01
                        • 1970-01-01
                        • 2019-07-31
                        • 1970-01-01
                        相关资源
                        最近更新 更多