良いプログラマのウェブフロントエンドを共有する方法単一ページの構築方法のWeb アプリケーションを、すべての単一ページのアプリケーションが何であるかを見てみましょう最初の？いわゆる単一ページのアプリケーション、ページ上に集積する様々な機能を指し、あるいはシステム全体は1ページのみですサブモジュールである全てのビジネス機能は、特定の方法でメインインターフェイスに取り付けられています。それはAJAX 、さらに昇華技術AJAXが極端に何のリフレッシュメカニズムを果たしていない、それはデスクトッププログラムと同等のスムーズなユーザーエクスペリエンスを作成することができます。
実際には、1ページのアプリケーション私たちには見知らぬ人、多くの人が書いたのExtJSのシステムを実装したプロジェクトを、単一のページを持っているのが自然である、そしてそれはまた、使用されたのjQueryを似たようなまたは他のフレームワークを達成するために。様々なJSのフレームワーク、偶数フレームなしで、彼らは単一ページのアプリケーションを実現することができ、それだけで考えです。このようなシステムの開発に適用されるいくつかのフレームワークは、あなたがそれらを使用する場合は、利便性の多くを得ることができます。
まず、開発フレームワーク
ExtJSには、それは、様々なカプセル化し、単一のページの最初の世代の典型的なアプリケーションフレームワークと呼ばれてもよいUI ユーザが主に使用し、コンポーネントをJavaScriptを全体先端部、さらにレイアウトを完了すること。増加機能により、ExtJSののボリュームは徐々にでも時々面倒な社内システムの開発、ではないに言及し、インターネット上で実行されている複数のこのようなシステムの開発のために、増加します。
jQueryのは重視に起因DOMの操作、そのプラグインアーキテクチャと比較的緩いので、比ExtJSのこのシステムは、比較的軽量で柔軟になり、ソリューション全体を実行して、パブリックネットワークに展開単一ページのシステムに適しています。
しかし、のために jQueryの上部の操作について主に、それが組織コードの制約の欠如です。急速な拡大の凝集の場合にはコードの各ブロックを制御し、モジュール間の適切なデータ転送や共有を生成する方法は、困難な問題となっています。
単一ページのアプリケーションの時間のサイズを大きくするために、問題のコードのロジックを解決するために、多くのがありました MV *の枠組み、その基本的な考え方はしているJSの階層化モジュールと通信メカニズムを作成する層。いくつかのMVC 、いくつかのMVP 、いくつかのMVVM 、彼らはほとんどのフロントエンド開発の特性に適応するためのこれらのモデルのバリエーションを持っていました。
そのようなフレームは、バックボーン、ノックアウト、AngularJS 、アバロンなど。
第二に、コンポーネントベース
フロントエンド従来のいわゆるコンポーネントベースのコードの構成要素促進する層状枠組みを行うウェブ製品は、より呼ばUIの構成要素を、実際には成分は広い概念であり、伝統的なウェブ製品UI コンポーネントの高い割合その理由は、クライアントコードの割合の増加に伴って、ビジネス・ロジックの前端のかなりの部分は、それによって非インタフェース型コンポーネントの多数が発生作成、その厚さの欠如です。
階層の一つの利点は、各層のより具体的な責任であるもたらし、したがって、カバーユニットテストは、その品質を確保するために、そこにすることができます。伝統的な UIの層のテストは最も厄介な問題のあるUI と論理が混合し、このような変更は、リモートコールバック要求する傾向があるDOMは、層状に導入されたときに、これらのものは個別にテストすることができ、その後の試験は、シーンによって確保されています全体的なプロセス。
第三に、コード分離
単一ページのアプリケーションを実現するために、従来のページベースのWebサイトの開発プロセスと比較すると、特に懸念のいくつかのより多くのポイントがあります。
それは、ページベースのWebサイトよりも依存している、アプリケーションの観点から単一のページを備えたJavaScript 、およびなぜなら単一ページ、種々のサブ機能のページのJavaScriptの同じ範囲に集まっコードので、コードの分離、モジュール式になりますそれは非常に重要です。
単一ページのアプリケーションでは、ページテンプレートの使用は非常に一般的です。多くは、特定のテンプレートの枠組みを構築し、いくつかのフレームワークは、サードパーティのテンプレートを導入する必要があります。このインターフェースは、テンプレートのフラグメントである、我々はアナログにそれらを置くことができる JavaScriptのアセンブリの別のタイプであるモジュール。
同じテンプレートの分離が必要です。いない孤立したテンプレートは、それがどんな問題を引き起こすだろう？テンプレートとの間の競合を主に、ID プロパティに、テンプレートが含まれている場合は、固定IDを、それはバッチレンダリング時間あるときに、同じスコープになります複数のページを持っています同じIDを予測できない結果をもたらす要素の、。したがって、我々は、中のテンプレートの使用を避ける必要があり、上記のID に存在する場合、DOMのアクセス要件、他のセレクタによって行われるべきです。1ページのアプリケーションの度合いの構成要素が非常に高い場合、全体のアプリケーションの要素がない可能性があるID を使用は。
第四に、コードをローディング戦略とマージされ
単一のページのロード時間トレランスシステムとのための人々のWeb 異なるページ、彼らは買い物をロードするためにページを待つために喜んでいる場合は3 秒、単一ページのアプリケーションへの意思があるかもしれないが最初に待機するようにロードされている5~10 秒が、その後、比較的滑らかでなければならない様々な機能を使用し、可能な限りすべてのサブページがで機能するために1-2 、秒以内にハンドオーバー成功そうでない場合は、システムが遅いと感じています。
これらの特徴から、私たちは各負荷の負荷の量を減らすために、公共の関数に最初の負荷をより多くを置くことができ、いくつかのサイトがあっても、すべてのビジネス・インタフェース、すべての家庭にロードされたすべてのインターフェイスとロジックを置きます切り替え時にその応答が非常に高速であるので、データ要求は、のみ生成され、そのよう×××コンソールがなかったです。
通常、単一ページのアプリケーションは、障害物がファイルの読み込みをレンダリング防ぐために、製品のようなウェブサイトを入力することなく、 JS にHTMLがそのインターフェースは基本的に動的に生成されるため、バックロード。
当切换功能的时候，除了产生数据请求，还需要渲染界面，这个新渲染的界面部件一般是界面模板，它从哪里来呢?来源无非是两种，一种是即时请求，像请求数据那样通过AJAX获取过来，另一种是内置于主界面的某些位置，比如script标签或者不可见的textarea中，后者在切换功能的时候速度有优势，但是加重了主页面的负担。
在传统的页面型网站中，页面之间是互相隔离的，因此，如果在页面间存在可复用的代码，一般是提取成单独的文件，并且可能会需要按照每个页面的需求去进行合并。
单页应用中，如果总的代码量不大，可以整体打包一次在首页载入，如果大到一定规模，再作运行时加载，加载的粒度可以搞得比较大，不同的块之间没有重复部分。
五、路由与状态的管理
我们最开始看到的几个在线应用，有的是对路由作了管理的，有的没有。
管理路由的目的是什么呢?是为了能减少用户的导航成本。比如说我们有一个功能，经历过多次导航菜单的点击，才呈现出来。
如果用户想要把这个功能地址分享给别人，他怎么才能做到呢?
传统的页面型产品是不存在这个问题的，因为它就是以页面为单位的，也有的时候，服务端路由处理了这一切。
但是在单页应用中，这成为了问题，因为我们只有一个页面，界面上的各种功能区块是动态生成的。所以我们要通过对路由的管理，来实现这样的功能。
具体的做法就是把产品功能划分为若干状态，每个状态映射到相应的路由，然后通过pushState这样的机制，动态解析路由，使之与功能界面匹配。
有了路由之后，我们的单页面产品就可以前进后退，就像是在不同页面之间一样。
其实在Web产品之外，早就有了管理路由的技术方案，AdobeFlex中，就会把比如TabNavigator，甚至下拉框的选中状态对应到url上，因为它也是单“页面”的产品模式，需要面对同样的问题。
当产品状态复杂到一定程度的时候，路由又变得很难应用了，因为状态的管理极其麻烦，比如开始的时候我们演示的c9.io在线IDE，它就没法把状态对应到url上。
六、缓存与本地存储
在单页应用的运作机制中，缓存是一个很重要的环节。
由于这类系统的前端部分几乎全是静态文件，所以它能够有机会利用浏览器的缓存机制，而比如动态加载的界面模板，也完全可以做一些自定义的缓存机制，在非首次的请求中直接取缓存的版本，以加快加载速度。
甚至，也出现了一些方案，在动态加载JavaScript代码的同时，把它们也缓存起来。比如AddyOsmani的这个basket.js，就利用了HTML5localStorage作了js和css文件的缓存。
在单页产品中，业务代码也常常会需要跟本地存储打交道，存储一些临时数据，可以使用localStorage或者localStorageDB来简化自己的业务代码。
七、服务端通信
传统的Web产品通常使用JSONP或者AJAX这样的方式与服务端通信，但在单页Web应用中，有很大一部分采用WebSocket这样的实时通讯方式。
WebSocket与传统基于HTTP的通信机制相比，有很大的优势。它可以让服务端很便利地使用反向推送，前端只响应确实产生业务数据的事件，减少一遍又一遍无意义的AJAX轮询。
由于WebSocket只在比较先进的浏览器上被支持，有一些库提供了在不同浏览器中的兼容方案，比如socket.io，它在不支持WebSocket的浏览器上会降级成使用AJAX或JSONP等方式，对业务代码完全透明、兼容。
八、内存管理
传统的Web页面一般是不需要考虑内存的管理的，因为用户的停留时间相对少，即使出现内存泄漏，可能很快就被刷新页面之类的操作冲掉了，但单页应用是不同的，它的用户很可能会把它开一整天，因此，我们需要对其中的DOM操作、网络连接等部分格外小心。
九、样式的规划
在单页应用中，因为页面的集成度高，所有页面聚集到同一作用域，样式的规划也变得重要了。
样式规划主要是几个方面：
1、基准样式的分离
这里面主要包括浏览器样式的重设、全局字体的设置、布局的基本约定和响应式支持。
2、组件样式的划分
这里面是两个层面的规划，首先是各种界面组件及其子元素的样式，其次是一些修饰样式。组件样式应当尽量减少互相依赖，各组件的样式允许冗余。
3、堆叠次序的管理
传统Web页面的特点是元素多，但是层次少，单页应用会有些不同。
在单页应用中，需要提前为各种UI组件规划堆叠次序，也就是z-index，比如说，我们可能会有各种弹出对话框，浮动层，它们可能组合成各种堆叠状态。新的对话框的z-index需要比旧的高，才能确保盖在它上面。诸如此类，都需要我们对这些可能的遮盖作规划，那么，怎样去规划呢?
了解通信知识的人，应当会知道，不同的频率段被划分给不同的通信方式使用，在一些国家，领空的使用也是有划分的，我们也可以用同样的方式来预先分段，不同类型的组件的z-index落到各自的区间，以避免它们的冲突。
十、单页应用的产品形态
我们在开始的时候提到，存在着很多新型Web产品，使用单页应用的方式构建，但实际上，这类产品不仅仅存在于Web上。点开Chrome商店，我们会发现很多离线应用，这些产品都可以算是单页应用的体现。
除了各种浏览器插件，借助node-webkit这样的外壳平台，我们可以使用Web技术来构建本地应用，产品的主要部分仍然是我们熟悉的单页应用。
单页应用的流行程度正在逐渐增加，大家如果关注了一些初创型互联网企业，会发现其中很大一部分的产品模式是单页化的。这种模式能带给用户流畅的体验，在开发阶段，对JavaScript技能水平要求较高。
单页应用开发过程中，前后端是天然分离的，双方以API为分界。前端作为服务的消费者，后端作为服务的提供者。
在此模式下，前端将会推动后端的服务化。当后端不再承担模板渲染、输出页面这样工作的情况下，它可以更专注于所提供的API的实现，而在这样的情况下，Web前端与各种移动终端的地位对等，也逐渐使得后端API不必再为每个端作差异化设计了。
十一、部署模式的改变
在现在这个时代，我们已经可以看到一种产品的出现了，那就是“无后端”的Web应用。这是一种什么东西呢?基于这种理念，你的产品很可能只需要自己编写静态Web页面，在某种BaaS(BackendasaService)云平台上定制服务端API和云存储，集成这个平台提供的SDK，通过AJAX等方式与之打交道，实现注册认证、社交、消息推送、实时通信、云存储等功能。
我们观察一下这种模式，会发现前后端的部署已经完全分离了，前端代码完全静态化，这意味着可以把它们放置到CDN上，访问将大大地加速，而服务端托管在BaaS云上，开发者也不必去关注一些部署方面的繁琐细节。
假设你是一名创业者，正在做的是一种实时协同的单页产品，可以在云平台上，快速定制后端服务，把绝大部分宝贵的时间花在开发产品本身上。
十二、单页应用的缺陷
单页应用最根本的缺陷就是不利于SEO，因为界面的绝大部分都是动态生成的，所以搜索引擎很不容易索引它。
十三、产品单页化带来的挑战
一个产品想要单页化，首先是它必须适合单页的形态。其次，在这个过程中，对开发模式会产生一些变更，对开发技能也会有一些要求。
开发者的JavaScript技能必须过关，同时需要对组件化、设计模式有所认识，他所面对的不再是一个简单的页面，而是一个运行在浏览器环境中的桌面软件。