【问题标题】:Structure with Javascript code? CSS, Divs and then Scripts?Javascript代码的结构? CSS、Divs 和脚本?
【发布时间】:2011-05-30 16:29:06
【问题描述】:

我注意到脚本的位置并非无关紧要,如果脚本引用下面的某个div,它可能不起作用,不确定规则也许我的杂乱代码稍后会分配一些其他值。因此,我要求使用通用指南来设计 Javascript 代码中的结构。例如 CSS、Divs 和 Scripts 等部分的顺序是什么?

我个人的偏见是,好的代码应该从底部到顶部都易于阅读。因此,例如,浏览器可能在底部有 browse() 脚本以开始浏览,而其余的瘾君子则按逻辑顺序排列在顶部,因此在 browse() 之后,其上面的脚本应该是 browse() 使用的东西.字段值应该在顶部定义,我认为 CSS 和 div 之类的东西——我知道的粗鲁类比。但是如果用户的浏览器很慢,脚本可能根本无法执行,代码似乎无法正常工作。实用性和可读性的两难选择。

请定义术语,例如从上到下编码和从下到上编码,并显示结构。

【问题讨论】:

    标签: javascript implementation structure


    【解决方案1】:

    K-I-S-S 是我的信条。当我的代码不起作用时,它通常会在我杀死非内在代码时开始工作。 mwilcoxprodigitalson 等回复中涵盖了一些好东西。 没有不必要的图片,也没有过多的脚本块。实际上,有些人似乎有超过500 000 行的工作JS 代码,例如Gmail。 我不知道他们是如何做到的,但它暗示对这里的回复持批评态度!进一步的回复可能会涵盖如何设计大量的 JS 代码,比如 100 000 行,暂时。

    例外情况

    库和分析脚本是一个例外,可以从头开始(如果需要的话)。由于这种杂乱无章的事情,您可能会看到为什么structure 一词变得令人困惑。但是要制作某种结构,它看起来像:

    1. CSS
    2. 分区
    3. 结尾的脚本

    【讨论】:

      【解决方案2】:

      样式表在前,脚本在后。这样做的原因是脚本是“阻塞的”,这意味着当浏览器下载 JavaScript 时,它不会下载其他任何东西——不是样式表,也不是图像。

      浏览器一次只能下载这么多资源,并且会阻止所有其他加载,直到这些资源被释放。 IE8实际上一次会下载不少,多达18个或更多。 Firefox 和 Safari 一次会下载 6 个,而 IE6&7 一次只会下载一个脚本或两个非脚本。要记住的是,这些资源不是免费的,而且脚本也不同。

      一个好的经验法则是将样式表放在头部,将 JavaScript 放在正文的最底部。当然,JS 库为您提供了某种“准备 DOM”的附加功能。您可以使用它,大多数开发人员都可以使用,但有副作用:

      IE 偶尔会对加载 DOM 的 hack 感到厌烦。很少见,但它发生在我身上。 如果它们在头部,您的页面将被冻结,直到您的脚本加载。如果您的脚本过多,可能会使您的页面看起来很慢且没有响应。

      如果您的 JavaScript 全部位于页面末尾,则您无需担心内容是否已加载或 DOM 节点是否可用。页面将在您的 JavaScript 加载和计算时呈现和设置样式。

      最后,将您的资源保持在最低限度。如果您有两个以上的脚本和两个样式表,那么您的页面就不会尽可能快。图像也是 - 充分利用图像精灵。除非您处理缩略图或类似的东西,否则应该只有少数图像。

      【讨论】:

        【解决方案3】:

        RequireJS - 外包脚本加载

        我发现RequireJS 对于 JavaScript 应用程序开发特别有用。就我而言,我正在处理数十个 JavaScript 文件(模块),但我相信它在其他情况下也会派上用场。

        图书馆为您处理了很多无聊的东西。您需要做的就是设置一些文件(main.js,构建选项),状态模块依赖关系,一切顺利。它包含一个构建系统,因此您可以轻松完成调试或生产构建(缩小)。

        关于应用结构

        我喜欢“自上而下”地编写代码。这个想法是应用程序的更高级别应该被真正松散地定义。您不应该在那里看到用于解决某些特定问题的实际算法。最高级别应该只是将应用程序的各个部分连接在一起。较低的层次解决更具体的问题,直到你得到具体的实现。

        这是一种相当标准的分层应用程序开发方法。对于临时脚本,您可能不需要这样的东西。在实践中应用它仍然是一个好主意,因为它可以帮助您更好地编写脚本。您甚至可以在闭包级别上使用这个想法,以使代码更易于阅读。

        关于功能

        将“功能”理解为“至”可能会有所帮助(Logo 概念 :))。我认为一个写得很好的函数读起来就像一个食谱(要“drawLine”,你必须使用这些参数来做这个和那个......)。

        我知道这可能与问题不完全相关,但我认为这可能是一个有趣的想法。也许它会帮助您以不同的方式看待函数并帮助您以这种方式构建 JavaScript 代码。

        在未准备好的元素上

        考虑到元素未准备好和脚本加载...您最好在“文档准备好”处理程序中定义您的代码。这是相当标准的做法。

        如果您使用 RequireJS 或类似的库,您可能不必担心这一点。他们会为您处理这个特殊问题。

        【讨论】:

          【解决方案4】:

          我尽量不在我的代码中包含过多的脚本块。在包含某些 api 的情况下(例如 addthis),我会在头部或正文关闭之前调用所有外部脚本。所有内联脚本也都在正文标记结束之前的单个块中。

          【讨论】:

            【解决方案5】:

            您可以将整个页面、JavaScript、CSS 和 HTML 视为“从上到下”的通用程序的组合,以后的代码可以引用较早的代码。因为当页面加载时,它只是开始“执行”或解释它所看到的“代码”。大多数时候,“代码”只是简单的定义(如 JS 变量或函数)和元素的放置(如 DIV)。

            但是,如果您有在加载期间实际运行的 JS,即代码,在函数定义之外,那么它只会“看到”在代码执行之前存在的东西。因此,从这个意义上说,整个事情只是一个长程序,HTML 作为一种元语言构建一个 DOM,因为 HTML 由浏览器解释。

            显然,有一些技术可以在某些点运行代码,例如页面加载等,这就是 JQuery 等库用来公开这些事件点并使它们易于使用的地方。

            但从根本上说,它是一个自上而下的脚本,就像其他任何东西一样。

            【讨论】:

            • Will Hartung:从上到下的方法,你是指相反的方法,我认为 Java 和 C 是好的方法(我的偏见的起源)?
            • 有一个明显的例外,即声明的函数被“提升”并且可用于在它们“之上”的代码。
            • 我闻到了矛盾的味道。请看僵尸! -底部的代码 [1]。它使用了browse(),后来定义了browse(),它仍然有效,它在同一个]>.*中。 [1]code.google.com/apis/gadgets/docs/publish.html
            【解决方案6】:

            通常我尝试将操作 DOM 的脚本放在页面底部,它解决了在页面完全加载之前找不到 DOM 元素的问题。

            但是,库(例如 jQuery)应该放在 <head> 中。

            【讨论】:

              【解决方案7】:

              在头部,放置 CSS,然后按使用顺序和正文 Divs 中的脚本。

              例如,如果您使用 jQuery 并且有一个使用 jQuery 代码的 .js 文件,建议在您的 .js 之前导入 jQuery 文件

              我个人尽量避免将脚本放在正文中,并且很少遇到诸如脚本在下面找不到 div 之类的问题。

              【讨论】:

                猜你喜欢
                • 2017-02-12
                • 1970-01-01
                • 1970-01-01
                • 1970-01-01
                • 2013-06-06
                • 1970-01-01
                • 1970-01-01
                • 1970-01-01
                • 2014-03-20
                相关资源
                最近更新 更多