Skip to content

Latest commit

 

History

History
339 lines (295 loc) · 19.1 KB

article.md

File metadata and controls

339 lines (295 loc) · 19.1 KB

前端精选文集

主要是一些值得反复阅读, 细细品味的文章

  • 前端开发技术的发展

    一. 刀耕火种 1. 静态页面 2. 带有简单逻辑的界面 3. 结合了服务端技术的混合编程 4. 组件化的萌芽

    二. 铁器时代 1. AJAX 2. JavaScript基础库 3. 模块代码加载方式

    三. 工业革命 1. 数据模型 2. 控制器 3. 视图 4. 模板 5. 路由 6. 自定义标签

  • 前端MV*框架的意义

    归根结底，前端MV*框架带来的是一整套工作流程的变更，后端工程师也可以编写前端的模型代码，把它跟后端彻底打通，交互工程师处理UI跟模型的互动关系，UI工作人员可以专注、无障碍地处理HTML源码，把它们以界面模版的形式提供给交互工程师。这一整套协作机制能够大大提高B/S架构系统的开发效率，如果再有外围的管控平台，生产效率将真正踏进工业化的阶段。

    到这个阶段，前端开发人员的出路是什么呢？我认为有两种。拿服装行业来对比，如果你要的是普通的，就使用工业手段批量生产，使用MV*框架，做好架构和组件重用，做得快，细节不是很讲究。如果你想要更好的，有特色的，就需要名家设计，手工打造，非常精巧，高端大气上档次。所以，这也就代表着前端开发的两种发展方向。

  • Web应用的组件化开发

    1. 为什么要做组件化？

    2. 早期的前端怎么做组件化的？

    3. SPA时代

    4. 架构的变更

    5. MV*框架的基本原理

    6. 如何做组件化(HTML/JavaScript/CSS的组件化)

  • 构建单页Web应用

    • 代码隔离
    • 代码合并与加载策略
    • 组件化
    • 样式的规划
    • 路由与状态的管理
    • 服务端通信
    • 缓存与本地存储
    • 内存管理

  • 从零开始编写自己的JavaScript框架

    1. 模块的定义和加载

    2. 数据绑定

  • 2015前端组件化框架之路

    1. 为什么组件化这么难做

    2. 标准的变革(ES6, observe, Web Components)

    3. 当下最时髦的前端组件化框架/库

    4. 前端组件的复用性

    5. 为什么MVVM是一种很好的选择

    6. 组件的长期积累

    7. 我们需要关注什么(模块化, Web Components, 变更检测, Immutable Data, Promise与异步, Isomorphic JavaScript)

  • 关于前端开发中“模块”和“组件”概念的思考

    模块（对应英文"module"）

    组件（对应英文"component"）

    组件与模块的关系

    通过JS Module Loader加载CSS等资源

    CSS局域化问题

  • 影响企业应用前端开发效率的因素

    1. 命令式还是声明式

    2. 控件标签集

    3. 带逻辑的控件

    4. Polymer与Angular

    5. 为什么HTML默认标签集这么小

    6. 界面修饰

    7. 模块化和加载

    8. 逻辑的分层

  • 基于AngularJS的企业软件前端架构

    • 企业应用前端的特点
    • 企业应用常见的前端框架
    • 曾经的企业B/S应用几件宝
    • 单页应用和前端分层
    • 前端的自定义标签体系
    • 业务逻辑
    • 二次开发平台
    • 移动开发
    • 工程化

  • 前端架构那些事儿

    架构的本质是什么？其实也是一种管理。通常我们所说的管理，都是指对于任务和人员的管理，而架构管的是机器和代码。

    前端的工程化问题。

    早期为什么没有这些问题？因为那时候前端很简单，复杂度不高，现在整个很复杂了，就带来了很多管理问题。比如说整个系统的前端都组件化了之后，HTML会拆分成各种模板，JavaScript会拆分成各种模块，而CSS也通过LESS或者SASS这种方式，变成了一种编译式的语言。

    这时候，我们考虑一个所谓的组件，它就比较麻烦了。它可能是一个或者多个HTML模板，加上一个或者多个JavaScript模块，再包含CSS中的一部分构成的，而前两者都可能有依赖项，三个部分也都要避免与其他组件的冲突。

    这些东西都需要管理，并且提供一种比较好的方案去维护。在JavaScript被模块化之后，也可以通过单元测试来控制它们的质量，并且把这个过程自动化，每次版本有变更之前，保证它们最基本的正确性。最终，需要有一种自动化的发布机制，把这几类代码提取，打包合并，压缩，发布。

  • JavaScript 模块化七日谈

    • 第一日 上古时期 Module? 从设计模式说起
    • 第二日 石器时代 Script Loader 只有封装性可不够，我们还需要加载
    • 第三日 蒸汽朋克 Module Loader 模块化架构的工业革命
    • 第四日 号角吹响 CommonJS 征服世界的第一步是跳出浏览器
    • 第五日 双塔奇兵 AMD/CMD 浏览器环境模块化方案
    • 第六日 精灵宝钻 Browserify/Webpack 大势所趋，去掉这层包裹！
    • 第七日 王者归来 ES6 Module 最后的战役

  • 前端开发体系建设日记

  • 前端集成解决方案

  • 大公司里怎样开发和部署前端代码？

    这是一个非常有趣的 非主流前端领域，这个领域要探索的是如何用工程手段解决前端开发和部署优化的综合问题

    对于大公司来说，那些变态的访问量和性能指标，将会让前端一点也不"好玩"。

    • 通过更新页面中引用的资源路径，让浏览器主动放弃缓存，加载新资源。
    • 只有文件内容变化，才会导致相应url的变更，从而实现文件级别的精确缓存控制。
    • 现代互联网企业，为了进一步提升网站性能，会把静态资源和动态网页分集群部署，静态资源会被部署到CDN节点上，网页中引用的资源也会变成对应的部署路径
    • 同时改了页面结构和样式，也更新了静态资源对应的url地址，现在要发布代码上线，亲爱的前端研发同学，你来告诉我，咱们是先上线页面，还是先上线静态资源？
    • 这个奇葩问题，起源于资源的 覆盖式发布，用 待发布资源 覆盖 已发布资源，就有这种问题。解决它也好办，就是实现 非覆盖式发布。
    • 用文件的摘要信息来对资源文件进行重命名，把摘要信息放到资源文件发布路径中，这样，内容有修改的资源就变成了一个新的文件发布到线上，不会覆盖已有的资源文件。上线过程中，先全量部署静态资源，再灰度部署页面，整个问题就比较完美的解决了。

    所以，大公司的静态资源优化方案，基本上要实现这么几个东西：

    • 配置超长时间的本地缓存 —— 节省带宽，提高性能
    • 采用内容摘要作为缓存更新依据 —— 精确的缓存控制
    • 静态资源CDN部署 —— 优化网络请求
    • 更资源发布路径实现非覆盖式发布 —— 平滑升级

    前端所有静态资源加载的位置都要做这样的处理 。是的，所有！什么js、css自不必说，还要包括js、css文件中引用的资源路径

    总之，前端性能优化绝逼是一个工程问题！

  • 前端工程——基础篇

    前端是一种技术问题较少、工程问题较多的软件开发领域

    前端工程的几个阶段

    • 第一阶段：库/框架选型
    • 第二阶段：简单构建优化
    • 第三阶段：JS/CSS模块化开发
    • 第四阶段：组件化开发与资源管理(静态资源管理系统 = 资源表 + 资源加载框架)

    前端组件化开发理念

    • 页面上的每个独立的可视/可交互区域视为一个组件
    • 每个组件对应一个工程目录，组件所需的各种资源都在这个目录下就近维护
    • 由于组件具有独立性，因此组件与组件之间可以自由组合
    • 页面只不过是组件的容器，负责组合组件形成功能完整的界面
    • 当不需要某个组件，或者想要替换组件时，可以整个目录删除/替换

    基于这些理念，我眼中的前端开发就成了这个样子

    • 整个Web应用由页面组成
    • 页面由组件组成
    • 一个组件一个目录，资源就近维护
    • 组件可组合，组件的JS可依赖其他JS模块，CSS可依赖其他CSS单元

  • 这里的东西还需要整理一下, 还有顺序看是否稍微调整下

  • xufei的blog和issue再过一遍

  • lifesingerblog整理

  • evernote里面的F2E再过一遍

  • JavaScript与有限状态机

    有限状态机的写法，逻辑清晰，表达力强，有利于封装事件。一个对象的状态越多、发生的事件越多，就越适合采用有限状态机的写法。

  • Build a Great Web Experience

    Tools, best practices for building great web apps.

  • Decoupling Your HTML, CSS, and JavaScript

    The mark of maintainable HTML, CSS, and JavaScript is when individual developers can easily and confidently edit parts of the code base without those changes inadvertently affecting other, unrelated parts.

    A back-end developer should be able to change the markup in an HTML template without worrying about accidentally breaking a CSS rule or some JavaScript functionality.

    It’s best to style all your visual components with one or more classes on the root element of the component itself.

    DON't use the same class for both styling purposes and behavior(a JavaScript hook). Use the prefix js-* to define class for JavaScript hook.

    USE the prefix is-* to define class selectors that alter the state of a visual component

  • Side Effects in CSS

    The hardest problem in CSS

    There are two types of problems in CSS: cosmetic problems and architectural problems.

    Cosmetic problems—issues like vertical centering or equal-height columns—usually engender the most vocal complaints, but they’re almost never showstoppers. They’re annoying, sure, but they don’t break the build.

    Architectural problems, on the other hand, can cripple development. I can remember distinct cases, at each of the companies I’ve worked for, where we postponed developing a new feature because we were too afraid to make any changes to the CSS.

    CSS is global, and every rule you write has the potential to affect entirely unrelated parts of the site. It’s this unpredictability that makes writing good CSS so hard.

    Because all CSS rules live in the global scope, side effects are extremely common. And since your average stylesheet usually consist of an extremely fragile collection of highly-coupled rules, all intimately dependent on the presence, order, and specificity of other rules, even the most unassuming changes can have unforeseen consequences.

    In CSS, side effects come in three main forms:

    • Base rule changes
    • Naming collisions
    • Subtree matches

    CSS的副作用主要是由于CSS是全局的, 会造成各种各样的冲突.

    CSS中最难的部分

    1. 如何实现某种效果(cosmetic problems)

    2. 如何组织管理CSS(architectural problems)

    CSS的副作用主要体现为

    • 样式冲突
    • 命名冲突

  • CSS Modules

    1. Global Namespace

    2. Dependencies

    3. Dead Code Elimination

    4. Minification

    5. Sharing Constants

    6. Non-deterministic Resolution

    7. Isolation

  • 时尚且健壮: 实现更优秀的CSS

    • 创建你自己的样式指南

      启动这一工作的最简单方式就是在你的项目根目录下新建一个style-guide.html文件，在其中包含整个网站中的CSS。

    • 限定特定样式的范围

      让这些代码只在这种场景中生效，而在其他场景中将自动忽略， 这种方式能够帮助我们确保在这个范围内的任何代码都不会影响网站的其余部分。

    • 批判性地看待每一行CSS

      当完成代码的编写后，你应当重新审视你的代码。你可以试着删除你所编写的每一行CSS代码，并检查这一行代码有没有什么实际的作用。你是否真的需要overflow: hidden，将display属性改为inline有没有实际意义？如果答案是否定的，那就删除它。你所留下的代码越少，等到你下一次回顾这些代码时，它们为你所造成的困扰就越少。

  • About HTML semantics and front-end architecture

    A flexible and reusable component is one which neither relies on existing within a certain part of the DOM tree, nor requires the use of specific element types. It should be able to adapt to different containers and be easily themed. If necessary, extra HTML elements (beyond those needed just to markup the content) and can be used to make the component more robust.

  • webpack Motivation

    Today’s websites are evolving into web apps:

    • More and more JavaScript is in a page.
    • You can do more stuff in modern browsers.
    • Fewer full page reloads → even more code in a page.

    As a result there is a lot of code on the client side!

    A big code base needs to be organized. Module systems offer the option to split your code base into modules.

    MODULE SYSTEM STYLES

    • <script>-tag style (without a module system)

      Common problems

      • Conflicts in the global object.
      • Order of loading is important.
      • Developers have to resolve dependencies of modules/libraries.
      • In big projects the list can get really long and difficult to manage.

    • CommonJS: synchronous require

    • AMD: asynchronous require

    • ES6 modules

    TRANSFERRING

    Modules should be executed on the client, so they must be transferred from the server to the browser.

    There are two extremes when transferring modules:

    • 1 request per module
    • All modules in one request

    Chunked transferring: A compromise between the extremes is better in most cases. While compiling all modules: Split the set of modules into multiple smaller batches (chunks).

    WHY ONLY JAVASCRIPT?

    Why should a module system only help the developer with JavaScript? There are many other resources that need to be handled Or translated/processed

    STATIC ANALYSIS

    When compiling all these modules, a static analysis tries to find its dependencies.

    所以 webpack 主要解决这几个问题

    • module bundler
    • loader other resources as a module
    • code split

  • 淘宝前后端分离实践

    在服务器(Java) 与 浏览器(JS)的中间 架了一个中间层(NodeJS)

    后端 前端
    服务器 浏览器
    Java NodeJS JS+HTML+CSS
    服务层 提供数据 跑在服务器上的JS 转发数据, 串接服务 路由设计, 控制逻辑 渲染页面, 体验优化 跑在浏览器上的JS CSS, JS加载与运行 DOM操作 共用模版, 路由

  • 如何带好前端团队

    技术团队的梯形互补

    • 第一类是将才，是编程高手
    • 第二类是帅才，是产品高手

  • Web 应用架构指南 | 5分钟学会五个前端框架

    学会编写组件

    • M 绑定到 V: 数据更新, View 自动更新
    • V 绑定到 C: 绑定 DOM 事件
    • C 更新到 M

  • 抛开 React 学习 React

    • 更新整个应用的 state
    • 更新 DOM（根据应用当前的 state 来调用 render 函数）
    • state 作为中间媒介，简化了事件和 DOM 元素之间的交互, 而不是通过事件来直接操作 DOM
    • 简单的单向数据流（one-way data flow）的原则