# MyJsFrameWork

**Repository Path**: 007slm/MyJsFrameWork

## Basic Information

- **Project Name**: MyJsFrameWork
- **Description**: 前端框架
- **Primary Language**: JavaScript
- **License**: MIT
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2014-05-29
- **Last Updated**: 2020-12-18

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

#MyJsFrameWork

### 2014.5.29
准备写一个自己的js框架，目标是做到想kissy等一样的能力，同时要有data-bind的能力
### 2010.5.30
dom操作的底层依赖jquery这样的库，
工具函数参考prototype对jquery这样的dom库做补充 暂时命名为lang 模块，以后需要一个添加一个

### 2010.6.4
##基础体系收到aralejs的影响比较大

####基础模块加载机制采用sea.js
    模块写法

    define(function(require, exports, module) {

      // 通过 require 引入依赖
      var $ = require('jquery');
      var Spinning = require('./spinning');

      // 通过 exports 对外提供接口
      exports.doSomething = ...

      // 或者通过 module.exports 提供整个接口
      module.exports = ...

    });

###选择理由

    对打包的影响。 假设模块 a 和模块 b，打包后

    define('a', [...], ....)
    define('b', [...], ....)
    在 AMD 下，由于 define 时模块 a 及其依赖立刻就执行了，这意味着，如果 b 依赖 a，那么在打包时，需要将模块 a 放在模块 b 前面，否则就执行有问题了。

    但在 CMD 里，由于一切都是懒执行的，define 时仅仅是 meta 信息的注册，这意味着在 CMD 规范下，打包时，模块的顺序是无关的。

    而包规范（Packages 规范）中很重要的一条，就是合并模块时，模块的顺序应该无关。

    CMD 可以使得构建时的复杂度降低。

    这个问题还可以深挖。目前 Sea.js 拥有 plugin-combo 插件，模块的合并可以放在线上动态做。有些情况下（比较容易出现），动态 combo 的地址会很长：

    https://a.alipaybojects.com/??path/to/a.js,path/to/b.js..................path/to/long-url.js
    当 url 地址很长时，超过 2083（好像是这个值），在 IE 以及一些服务器配置下，过长的 url 会出问题。这时经典的解决办法是将 url 拆分成多段：

    https://a.alipaybojects.com/??path/to/a.js,path/to/b.js..................path/to/u.js
    https://a.alipaybojects.com/??path/to/f.js,path/to/g.js..................path/to/long-url.js
    拆分后，在 CMD 规范下，上面两个 url 可以并发同时请求，谁先返回都没问题。但在 AMD 下，上面的需求，就挂了，很难实现。

    单个你会说 RequireJS 鼓励的是项目上线前，通过构建工具先构建好，不需要线上 combo，也就不会遇到上面的问题。

    我想说的是，RequireJS 通过严格的项目开发流程的确可以解决问题。但 Sea.js 放得更宽泛，提前合并好，还是线上时才动态 combo，对 CMD 模块来说都可行。很多时候，combo 真心省事，也更自然。前端开发并非处处要像 Java 一样引入严格的构建过程。

    除了对打包的影响，CMD 的懒执行策略，也更有利于页面性能。通过 CMD，可以做到页面首次可交互时间（TTI）达成前，不会执行其他脚本。CMD 为执行点提供了更多可控项。

    以上理解可能有误，RequireJS 2.0 后，不少理念也在悄悄地发生着变化，现在好像也支持懒执行了，当初对 CommonJS Wrap 格式的支持，也是一种妥协。Sea.js 目前更纯粹、简单。

    当然，上面都是我说的。我希望我都是错的，但期望看到有人能理性的证明我是错的。
[参见https://github.com/seajs/seajs/issues/588](https://github.com/seajs/seajs/issues/588) 里面的讨论

####开始些最基础的base模块 参考kissyui 和arale（主要来自）

  *认为Base 包含 基本的Class Event Attribute Aspect 能力
  
####2014.6.5
  开始些基本的Class模块，在采用seajs的基础上采用spm机制，这样模块化写法上和nodejs保持一直 同时看中了 spm的test和doc机制
 
 
#### 2014.6.25
   为了找个一个好的模块化写法的工具。重新参考了 fis ，最有决定编译工具采用fis-pure，同样的模块化工具采用mod.js,
采用mod.js的理由：简单，代码非常少，符合我的想法，如果需求达不到在采用seajs等 这样才能知道真正的需求是什么。、
一上来没必要采用一个复杂的模块化框架。