你們的2016年前端學習計劃是什麼？

12-29

2015年結束了，網上各種前端年度總結，發展回顧，2016年的前端技術發展趨勢，不知道各位有為自己制定年度計劃嗎？或者對這方面有何看法嗎？

沒必要追新。基礎很重要：

1、css,html，js（ES5，ES2015，ES2016）遵循標準來學習

2、http，socket等網路協議。

3、數據結構和演算法

4、設計模式，這裡不建議為了設計而學習，多了解，項目多思考。

5、項目抽象，建模，分層的能力。

總之，代碼儘可能不重複，易讀易維護易擴展。

軟能力：

1、溝通能力

2、推動項目可執行，有反饋

3、提高英語能力

4、提煉出自己的學習方法

去年寫了一篇文章《前端演進史》， GitHub - phodal/repractise: RePractise

細細整理了過去接觸過的那些前端技術，發現前端演進是段特別有意思的歷史。人們總是在過去就做出未來需要的框架，而現在流行的是過去的過去發明過的。如，響應式設計不得不提到的一個缺點是：他只是將原本在模板層做的事，放到了樣式（CSS）層來完成。

複雜度同力一樣不會消失，也不會憑空產生，它總是從一個物體轉移到另一個物體或一種形式轉為另一種形式。

如果六、七年前的移動網路速度和今天一樣快，那麼直接上的技術就是響應式設計，APP、SPA就不會流行得這麼快。儘管我們可以預見未來這些領域會變得更好，但是更需要的是改變現狀。改變現狀的同時也需要預見未來的需求。

什麼是前端？

維基百科是這樣說的：前端Front-end和後端back-end是描述進程開始和結束的通用辭彙。前端作用於採集輸入信息，後端進行處理。計算機程序的界面樣式，視覺呈現屬於前端。

這種說法給人一種很模糊的感覺，但是他說得又很對，它負責視覺展示。在MVC結構或者MVP中，負責視覺顯示的部分只有View層，而今天大多數所謂的View層已經超越了View層。前端是一個很神奇的概念，但是而今的前端已經發生了很大的變化。

你引入了Backbone、Angluar，你的架構變成了MVP、MVVM。儘管發生了一些架構上的變化，但是項目的開發並沒有因此而發生變化。這其中涉及到了一些職責的問題，如果某一個層級中有太多的職責，那麼它是不是加重了一些人的負擔？

前端演進史

過去一直想整理一篇文章來說說前端發展的歷史，但是想著這些歷史已經被人們所熟知。後來發現並非如此，大抵是倖存者偏見——關注到的都知道這些歷史。

數據-模板-樣式混合

在有限的前端經驗里，我還是經歷了那段用Table來作樣式的年代。大學期間曾經有償幫一些公司或者個人開發、維護一些CMS，而Table是當時幫某個網站更新樣式接觸到的——http://ASP.Net（maybe)。當時，我們啟動這個CMS用的是一個名為aspweb.exe的程序。於是，在我的移動硬碟里找到了下面的代碼。

&

&
&
&
&&

&&
&
&
&

雖然，我也已經在HEAD里找到了現代的雛形——DIV + CSS，然而這仍然是一個Table的年代。

&

人們一直在說前端很難，問題是你學過么？？？

也許，你也一直在說CSS不好寫，但是CSS真的不好寫么？人們總在說JS很難用，但是你學過么？只在需要的時候才去學，那肯定很難。你不曾花時間去學習一門語言，但是卻能直接寫出可以work的代碼，說明他們容易上手。如果你看過一些有經驗的Ruby、Scala、Emacs Lisp開發者寫出來的代碼，我想會得到相同的結論。有一些語言可以讓寫程序的人Happy，但是看的人可能就不Happy了。做事的方法不止一種，但是不是所有的人都要用那種方法去做。

過去的那些程序員都是真正的全棧程序員，這些程序員不僅僅做了前端的活，還做了資料庫的工作。

Set rs = Server.CreateObject("ADODB.Recordset") sql = "select id,title,username,email,qq,adddate,content,Re_content,home,face,sex from Fl_Book where ispassed=1 order by id desc" rs.open sql, Conn, 1, 1 fl.SqlQueryNum = fl.SqlQueryNum + 1

在這個ASP文件里，它從資料庫里查找出了數據，然後Render出HTML。如果可以看到歷史版本，那麼我想我會看到有一個作者將style=""的代碼一個個放到css文件中。

在這裡的代碼里也免不了有動態生成JavaScript代碼的方法：

show_other = "&

人們在不斷地反思這其中複雜的過程，整理了一些好的架構模式，其中不得不提到的是我司Martin Folwer的《企業應用架構模式》。該書中文譯版出版的時候是2004年，那時對於系統的分層是

層次職責表現層提供服務、顯示信息、用戶請求、HTTP請求和命令行調用。領域層邏輯處理，系統中真正的核心。數據層與資料庫、消息系統、事物管理器和其他軟體包通訊。
化身於當時最流行的Spring，就是MVC。人們有了iBatis這樣的數據持久層框架，即ORM，對象關係映射。於是，你的package就會有這樣的幾個文件夾：
|____mappers

|____model

|____service

|____utils

|____controller


在mappers這一層，我們所做的莫過於如下所示的資料庫相關查詢：
@Insert(

        "INSERT INTO users(username, password, enabled) " +

                "VALUES (#{userName}, #{passwordHash}, #{enabled})"

)

@Options(keyProperty = "id", keyColumn = "id", useGeneratedKeys = true)

void insert(User user);


model文件夾和mappers文件夾都是數據層的一部分，只是兩者間的職責不同，如：
public String getUserName() {

    return userName;

}

public void setUserName(String userName) {

    this.userName = userName;

}


而他們最後都需要在Controller，又或者稱為ModelAndView中處理：

 
@RequestMapping(value = {"/disableUser"}, method = RequestMethod.POST)

public ModelAndView processUserDisable(HttpServletRequest request, ModelMap model) {

    String userName = request.getParameter("userName");

    User user = userService.getByUsername(userName);

    userService.disable(user);

    Map& map = new HashMap&();

    Map & usersWithRoles= userService.getAllUsersWithRole();

    model.put("usersWithRoles",usersWithRoles);

    return new ModelAndView("redirect:users",map);

}


在多數時候，Controller不應該直接與數據層的一部分，而將業務邏輯放在Controller層又是一種錯誤，這時就有了Service層，如下圖：


然而對於Domain相關的Service應該放在哪一層，總會有不同的意見：


Domain（業務）是一個相當複雜的層級，這裡是業務的核心。一個合理的Controller只應該做自己應該做的事，它不應該處理業務相關的代碼：
if (isNewnameEmpty == false  newuser == null){

    user.setUserName(newUsername);

    List& myPosts = postService.findMainPostByAuthorNameSortedByCreateTime(principal.getName());

    for (int k = 0;k &< myPosts.size();k++){
        Post post = myPosts.get(k);
        post.setAuthorName(newUsername);
        postService.save(post);
    }
    userService.update(user);
    Authentication oldAuthentication = SecurityContextHolder.getContext().getAuthentication();
    Authentication authentication = null;
    if(oldAuthentication == null){
        authentication = new UsernamePasswordAuthenticationToken(newUsername,user.getPasswordHash());
    }else{
        authentication = new UsernamePasswordAuthenticationToken(newUsername,user.getPasswordHash(),oldAuthentication.getAuthorities());
    }
    SecurityContextHolder.getContext().setAuthentication(authentication);
    map.clear();
    map.put("user",user);
    model.addAttribute("myPosts", myPosts);
    model.addAttribute("namesuccess", "User Profile updated successfully");
    return new ModelAndView("user/profile", map);
}

我們在Controller層應該做的事是：


處理請求的參數
渲染和重定向
選擇Model和Service
處理Session和Cookies

業務是善變的，昨天我們可能還在和對手競爭誰先推出新功能，但是今天可能已經合併了。我們很難預見業務變化，但是我們應該能預見Controller是不容易變化的。在一些設計裡面，這種模式就是Command模式。

 
View層是一直在變化的層級，人們的品味一直在更新，有時甚至可能因為競爭對手而產生變化。在已經取得一定市場的情況下，Model-Service-Controller通常都不太會變動，甚至不敢變動。企業意識到創新的兩面性，要麼帶來死亡，要麼佔領更大的市場。但是對手通常都比你想像中的更聰明一些，所以這時開創新的業務是一個更好的選擇。
高速發展期的企業和發展初期的企業相比，更需要前端開發人員。在用戶基數不夠、業務待定的情形中，View只要可用並美觀就行了，這時可能就會有大量的業務代碼放在View層：
&

    &

    &


        ${errors.username} ${errors.password}

    &
    &

    &

    &


        Woohoo, User &${user.userName}& has been created successfully!

    &
    &

&


不同的情形下，人們都會對此有所爭議，但只要符合當前的業務便是最好的選擇。作為一個前端開發人員，在過去我需要修改JSP、PHP文件，這期間我需要去了解這些Template：
{foreach $lists as $v}

&

&[{fun date("Y-m-d",$v["addtime"])}]&&{$v["title"]}&&
{/foreach}


有時像Django這一類，自稱為Model-Template-View的框架，更容易讓人理解其意圖：
{% for blog_post in blog_posts.object_list %}

{% block blog_post_list_post_title %}

&


{% editable blog_post.title %}

&

    &

        &{{ blog_post.title }} ? &

    &
&
{% endeditable %}

{% endblock %}


作為一個前端人員，我們真正在接觸的是View層和Template層，但是MVC並沒有說明這些。

 
從桌面版到移動版
Wap出現了，並帶來了更多的挑戰。隨後，解析度從1024x768變成了176×208，開發人員不得不面臨這些挑戰。當時所需要做的僅僅是修改View層，而View層隨著iPhone的出現又發生了變化。
這是一個短暫的歷史，PO還需要為手機用戶製作一個怎樣的網站？於是他們把桌面版的網站搬了過去變成了移動版。由於網路的原因，每次都需要重新載入頁面，這帶來了不佳的用戶體驗。
幸運的是，人們很快意識到了這個問題，於是就有了SPA。如果當時的移動網路速度可以更快的話，我想很多SPA框架就不存在了。
先說說jQuery Mobile，在那之前，先讓我們來看看兩個不同版本的代碼，下面是一個手機版本的blog詳情頁：
&


    {% for blog_post in blog_posts.object_list %}

        &
        {% editable blog_post.title blog_post.publish_date %}

        &
&{{ blog_post.title }}&&
        &{% blocktrans with sometime=blog_post.publish_date|timesince %}{{ sometime }} ago{% endblocktrans %}&

        {% endeditable %}

        &
    {% endfor %}

&

而下面是桌面版本的片段：
{% for blog_post in blog_posts.object_list %}

{% block blog_post_list_post_title %}

{% editable blog_post.title %}

&
    &{{ blog_post.title }}&

&
{% endeditable %}

{% endblock %}

{% block blog_post_list_post_metainfo %}

{% editable blog_post.publish_date %}

&


    {% trans "Posted by" %}:

    {% with blog_post.user as author %}

    &{{ author.get_full_name|default:author.username }}&

    {% endwith %}

    {% with blog_post.categories.all as categories %}

    {% if categories %}

    {% trans "in" %}

    {% for category in categories %}

    &{{ category }}&{% if not forloop.last %}, {% endif %}

    {% endfor %}

    {% endif %}

    {% endwith %}

    {% blocktrans with sometime=blog_post.publish_date|timesince %}{{ sometime }} ago{% endblocktrans %}

&
{% endeditable %}

{% endblock %}


人們所做的只是重載View層。這也是一個有效的SEO策略，上面這些代碼是我博客過去的代碼。對於桌面版和移動版都是不同的模板和不同的JS、CSS。


在這一時期，桌面版和移動版的代碼可能在同一個代碼庫中。他們使用相同的代碼，調用相同的邏輯，只是View層不同了。但是，每次改動我們都要維護兩份代碼。
隨後，人們發現了一種更友好的移動版應用——APP。
APP與過渡期API
這是一個艱難的時刻，過去我們的很多API都是在原來的代碼庫中構建的，即桌面版和移動版一起。我們已經在這個代碼庫中開發了越來越多的功能，系統開發變得臃腫。如《Linux/Unix設計思想》中所說，這是一個偉大的系統，但是它臃腫而又緩慢。
我們是選擇重新開發一個結合第一和第二系統的最佳特性的第三個系統，還是繼續臃腫下去。我想你已經有答案了。隨後我們就有了APP API，構建出了博客的APP。


最開始，人們越來越喜歡用APP，因為與移動版網頁相比，其響應速度更快，而且更流暢。對於伺服器來說，也是一件好事，因為請求變少了。
但是並非所有的人都會下載APP——有時只想看看上面有沒有需要的東西。對於剛需不強的應用，人們並不會下載，只會訪問網站。
有了APP API之後，我們可以向網頁提供API，我們就開始設想要有一個好好的移動版。
過渡期SPA
Backbone誕生於2010年，和響應式設計出現在同一個年代裡，但他們似乎在同一個時代里火了起來。如果CSS3早點流行開來，似乎就沒有Backbone啥事了。不過移動網路還是限制了響應式的流行，只是在今天這些都有所變化。
我們用Ajax向後台請求API，然後Mustache Render出來。因為JavaScript在模塊化上的缺陷，所以我們就用Require.JS來進行模塊化。
下面的代碼就是我在嘗試對我的博客進行SPA設計時的代碼：
define([

    "zepto",

    "underscore",

    "mustache",

    "js/ProductsView",

    "json!/configure.json",

    "text!/templates/blog_details.html",

    "js/renderBlog"

],function($, _, Mustache, ProductsView, configure, blogDetailsTemplate, GetBlog){

    var BlogDetailsView = Backbone.View.extend ({

        el: $("#content"),
        initialize: function () {

            this.params = "#content";

        },
        getBlog: function(slug) {

            var getblog = new GetBlog(this.params, configure["blogPostUrl"] + slug, blogDetailsTemplate);

            getblog.renderBlog();

        }

    });
    return BlogDetailsView;

});


從API獲取數據，結合Template來Render出Page。但是這無法改變我們需要Client Side Render和Server Side Render的兩種Render方式，除非我們可以像淘寶一樣不需要考慮SEO——因為它不那麼依靠搜索引擎帶來流量。
這時，我們還是基於類MVC模式。只是數據的獲取方式變成了Ajax，我們就犯了一個錯誤——將大量的業務邏輯放在前端。這時候我們已經不能再從View層直接訪問Model層，從安全的角度來說有點危險。
如果你的View層還可以直接訪問Model層，那麼說明你的架構還是MVC模式。之前我在Github上構建一個Side Project的時候直接用View層訪問了Model層，由於Model層是一個ElasticSearch的搜索引擎，它提供了JSON API，這使得我要在View層處理數據——即業務邏輯。將上述的JSON API放入Controller，儘管會加重這一層的複雜度，但是業務邏輯就不再放置於View層。
如果你在你的View層和Model層總有一層介面，那麼你採用的就是MVP模式——MVC模式的衍生（PS：為了區別別的事情，總會有人取個表意的名稱）。
一夜之前，我們又回到了過去。我們離開了JSP，將View層變成了Template與Controller。而原有的Services層並不是只承擔其原來的責任，這些Services開始向ViewModel改變。
一些團隊便將Services抽成多個Services，美其名為微服務。傳統架構下的API從下圖


變成了直接調用的微服務：


對於後台開發者來說，這是一件大快人心的大好事，但是對於應用端/前端來說並非如此。調用的服務變多了，在應用程序端進行功能測試變得更複雜，需要Mock的API變多了。
Hybird與ViewModel
這時候遇到問題的不僅僅只在前端，而在App端，小的團隊已經無法承受開發成本。人們更多的注意力放到了Hybird應用上。Hybird應用解決了一些小團隊在開發初期遇到的問題，這部分應用便交給了前端開發者。
前端開發人員先熟悉了單純的JS + CSS + HTML，又熟悉了Router + PageView + API的結構，現在他們又需要做手機APP。這時候只好用熟悉的jQuer Mobile + Cordova。
隨後，人們先從Cordova + jQuery Mobile，變成了Cordova + Angular的 Ionic。在那之前，一些團隊可能已經用Angular代換了Backbone。他們需要更好的交互，需要data binding。
接著，我們可以直接將我們的Angular代碼從前端移到APP，比如下面這種博客APP的代碼：
  .controller("BlogCtrl", function ($scope, Blog) {

    $scope.blogs = null;

    $scope.blogOffset = 0;

    //

    $scope.doRefresh = function () {

      Blog.async("https://www.phodal.com/api/v1/app/?format=json").then(function (results) {

        $scope.blogs = results.objects;

      });

      $scope.$broadcast("scroll.refreshComplete");

      $scope.$apply()

    };

    Blog.async("https://www.phodal.com/api/v1/app/?format=json").then(function (results) {

      $scope.blogs = results.objects;

    });
    $scope.loadMore = function() {

      $scope.blogOffset = $scope.blogOffset + 1;

      Blog.async("https://www.phodal.com/api/v1/app/?limit=10offset="+ $scope.blogOffset * 20 +  "format=json").then(function (results) {

        Array.prototype.push.apply($scope.blogs, results.objects);

        $scope.$broadcast("scroll.infiniteScrollComplete");

      })

    };

  })


結果時間軸又錯了，人們總是超前一個時期做錯了一個在未來是正確的決定。人們遇到了網頁版的用戶授權問題，於是發明了JWT——Json Web Token。
然而，由於WebView在一些早期的Android手機上出現了性能問題，人們開始考慮替換方案。接著出現了兩個不同的解決方案：


React Native
新的WebView——Crosswalk

開發人員開始歡呼React Native這樣的框架。但是，他們並沒有預見到人們正在厭惡APP，APP在我們的迭代里更新著，可能是一星期，可能是兩星期，又或者是一個月。誰說APP內自更新不是一件壞事，但是APP的提醒無時無刻不在干擾著人們的生活，雜訊越來越多。不要和用戶爭奪他們手機的使用權
一次構建，跨平台運行
在我們需要學習C語言的時候，GCC就有了這樣的跨平台編譯。
在我們開發桌面應用的時候，QT有就這樣的跨平台能力。
在我們構建Web應用的時候，Java有這樣的跨平台能力。
在我們需要開發跨平台應用的時候，Cordova有這樣的跨平台能力。
現在，React這樣的跨平台框架又出現了，而響應式設計也是跨平台式的設計。
響應式設計不得不提到的一個缺點是：他只是將原本在模板層做的事，放到了樣式（CSS）層。你還是在針對著不同的設備進行設計，兩種沒有什麼多大的不同。複雜度不會消失，也不會憑空產生，它只會從一個物體轉移到另一個物體或一種形式轉為另一種形式。
React，將一小部分複雜度交由人來消化，將另外一部分交給了React自己來消化。在用Spring MVC之前，也許我們還在用CGI編程，而Spring降低了這部分複雜度，但是這和React一樣降低的只是新手的複雜度。在我們不能以某種語言的方式寫某相關的代碼時，這會帶來諸多麻煩。
RePractise
如果你是一隻辛勤的蜜蜂，那麼我想你應該都玩過上面那些技術。你是在練習前端的技術，還是在RePractise？如果你不花點時間整理一下過去，順便預測一下未來，那麼你就是在白搭。
前端的演進在這一年特別快，Ruby On Rails也在一個合適的年代裡出現，在那個年代裡也流行得特別快。RoR開發效率高的優勢已然不再突顯，語法靈活性的副作用就是運行效率降低，同時後期維護難——每個人元編程了自己。
如果不能把Controller、Model Mapper變成ViewModel，又或者是Micro Services來解耦，那麼ES6 + React只是在現在帶來更高的開發效率。而所謂的高效率，只是相比較而意淫出來的，因為他只是一層View層。將Model和Controller再加回View層，以後再拆分出來？
現有的結構只是將View層做了View層應該做的事。
首先，你應該考慮的是一種可以讓View層解耦於Domain或者Service層。今天，桌面、平板、手機並不是唯一用戶設備，雖然你可能在明年統一了這三個平台，現在新的設備的出現又將設備分成兩種類型——桌面版和手機版。一開始桌面版和手機版是不同的版本，後來你又需要合併這兩個設備。
其次，你可以考慮用混合Micro Services優勢的Monolithic Service來分解業務。如果可以舉一個成功的例子，那麼就是Linux，一個混合內核的「Service」。
最後，Keep Learning。我們總需要在適當的時候做出改變，儘管我們覺得一個Web應用代碼庫中含桌面版和移動版代碼會很不錯，但是在那個時候需要做出改變。
對於複雜的應用來說，其架構肯定不是只有純MVP或者純MVVM這麼簡單的。如果一個應用混合了MVVM、MVP和MVC，那麼他也變成了MVC——因為他直接訪問了Model層。但是如果細分來看，只有訪問了Model層的那一部分才是MVC模式。
模式，是人們對於某個解決方案的描述。在一段代碼中可能有各種各樣的設計模式，更何況是架構。

從畢業到現在已經碼了5年代碼了，從前端到後端到資料庫再到運維，網站和app都玩過了一輪，不能說自己有多深的造詣，不過對於的技術的學習過程還是有些許感悟。
今年2016對於前端自己也沒安排什麼學習計劃，因為已經在創業了，只能是邊做邊用了。所以就說說自己曾經的學習過程吧。
我覺得在互聯網圈子裡干技術是個挺苦逼的活，因為各種技術更新換代太快，三天兩頭出現些新玩意，總會給人一種我嘴裡吃的還沒吞下去，尼瑪新的又要塞進來了，壓根吃不下啊。一度我也被這些如潮水般泳出來的新框架，新語言，新工具壓得闖不過氣來，覺得如果不拚命學習的話，馬上就要被行業淘汰了。
但是，當我們冷靜下來想想，我們手頭現在確實掌握了1萬種技術手段，我們真正在工作中用的上的能有幾樣，估計10個指頭都能數的過來。web前端，到現在我依然寫著html，用著js，當然需要用到一堆js的庫（如jquery等等），css這麼多年也沒變出個花來，頂多來了個css3。儘管我們還是需要用到很多新工具，比如grunt，glup，bower等等一系列，但是這些都是已經被業界證明了能夠提高工作效率，讓前端開發變得更好的東西，這些東西我們可以有足夠的時間去快速上手，前提是你的基礎足夠紮實，js不會只是三腳貓功夫，不然你根本搞不清這些工具的原理。而其他的跟多的前端的mvc框架，諸如angular，react等等，這些我們是否真的用的著，是否需要玩命的去吸收消化，我覺得我們還是需要根據自己的實際需求而定，不要盲目的浪費自己的時間去學習。
所以講了這麼多，我只是想給前端入門的童鞋，或者打算今年在前端有所成長的童鞋點點建議：
1. 不要盲目追隨新的技術，新的不一定是好東西，適合自己的才是最好的，別讓新技術分散了自己的學習注意力
2. html，js，css這些基礎一定要足夠紮實。因為不管是多牛逼的框架，js的庫，都脫離不了這三個最基礎的傢伙，萬變不離其宗。現在很多童鞋一直用jquery，就覺得自己js牛掰了，誠然不是，因為一旦脫離jquery，你會發現你對js一無所知。 所以可以多看看類似bootstrap，jquery等這些框架的源碼，如果你發現自己有不能理解的地方，說明你需要補課，好好回頭看看最基礎的html，js，css
3. 代碼模塊化。 js別亂七八糟的混在一起寫一大坨，注意功能的拆分。  頁面的布局就如同一同大樓，結構一定要簡明清晰
4. 大學學的演算法和數據結構撿起來，當你寫js的時候，這些都用得著
5. 多看看一些牛掰的網站，如豆瓣，facebook，看看別人的頁面都怎麼寫的。手上用的js庫，多看看源碼，這樣才知道自己寫的js水平如何
6.github可以時不時去關注些star多的前端項目，你可以不花時間去學習他的功能，不過可以去瞧瞧他的代碼結構和設計原理嘛
可能還有很多很多一時想不起來。不過我覺得基礎才是最重要的，萬丈高樓平地起，所以大家別急躁，靜下心來，一切都會好的。(*^__^*) 嘻嘻……
與前端直接相關的:
工作: 
消化好工作職責之內的React  Redux  Node  Webpack。
適當的造一點輪子，哪怕這個輪子再簡單不過: 
GitHub - EcutDavid/webpack-file-transform-plugin
工作之餘的學習：
基本功:
Exploring ES6: Upgrade to the next version of JavaScript


應用：
今年在應用方面計劃自學數據可視化。
選擇了從這本書開始入手:


學的過程中編碼，記錄哪怕一點點再小的成果。先不要想的太遠，弄通這本書再想下一步。(現在進度是第4章)
David Guan on CodePen


問答社區：
在stackoverflow試著回答問題，盡己之能幫助他人。


http://stackoverflow.com/users/5076405/david-guan
https://www.quora.com/profile/David-Guan-7與前端並間接相關：
個人時間管理：
每天選擇一個時間段，只在那個時間段使用知乎，並努力嘗試回答問題(個人選擇了21:00 - 23:00)
早點起床，一日之際在於晨。(個人選擇了7:15)
減少查看微信等通訊工具以及郵箱的次數,(每小時設定某個點查一下)
飲食健康：
少吃油膩，多鍛煉，保持良好心情。
不要一直坐著，公司允許的話配一個站立辦公桌。
有贊繼續補充如何學習React redux webpack d3～
剛好翻譯了一篇文章：State of the Art JavaScript in 2016，加上了部分譯者的觀點。

就像是隧道終點前的光明，JS生態的最佳實踐不再劇烈變更著，現在關於需要學什麼越來越明確了。本文就關於核心類庫，狀態管理，語言特性，構建工具，CSS預處理，API  HTTP 類庫，測試工具，依賴管理等等前端開發的方方面面進行了展望和梳理，為你挑出這些最佳實踐和面向未來的設計~

事實上，我也苦惱過JavaScript社區的這種現狀：
唯一正確寫 JavaScript 的方式就是每周換個花樣重寫一遍！
事實上擁有一個不斷進化和自我革命的社區是一件很不錯的事情，但前提是要你要接受這樣的現實。不斷學習和充實自己，並且透過變動改變的這些抓住真正永恆和持久的東西。
關於JavaScript社區為什麼這麼生機勃勃，折騰不止，請看文章永不停步（折騰死人）的JavaScript 生態


全文如下：2016/04/07 展望 Javascript 2016年的趨勢和生態發展 · Issue #12 · gaohailang/blog · GitHub


（上圖中的大部分都過時了 - 所有東西都變了！！）

本文翻譯自

那麼，你要開始一個嶄新的Javascript前端項目了，或者被之前老項目折騰半死，你也許並沒有和改變進化步伐極快的社區生態保持技術實踐的同步，或者你開始了，但是有大量的可選項不知道怎麼選。React，Flux，Angular，Aurelia，Mocha，Jasmine，Jasmine，Babel，TypeScript，Flow。哦我的天吶這麼多~ 為了讓事件變得更簡單，我們很多人正陷入一個陷阱：被我喜歡的XKCD漫畫描述的很好：
?
是的，好消息是現在JS生態開始慢下來了，好項目開始冒出。最佳實踐愛你慢慢變得更清晰了。工程師開始在現有項目上構建自己的工程還是重新創造輪子。
作為起點，下面是我對現代化Web應用各個部分的個人選擇。一些選擇看起來會有些爭議，我會在每個選擇後附上我的基本推理判斷。要注意的是，這些選擇通常是我建立在我目前對社區的觀察和我個人的經歷。你的看法當然會有不同~
核心類庫：React
?目前勝者很顯然就是React（譯者：你確定？！）


從頂到底都是組件，你的應用程序代碼非常容易理解
學習曲線非常平緩，要知道羅列它所有關鍵的API都不會超過一頁A4紙張。
JSX非常棒，你可以用獲得JavaScript編程語言的能力和工具鏈來描述頁面
使用Flux和Redux這種單向數據流非常直白來表達業務邏輯
React的社區生態圈非常不錯，產出了很多高質量的開發工具如Redux（後續會講到）
在React寫的大型項目中，利用Flux管理起數據流/內部狀態非常容易（而不像在雙向數據綁定中， 例如Angular1.x/Knockout中
如果你需要類似於服務端渲染，那麼選React沒錯了

現在不少全能的大型框架如Ember，Angular，它們承諾說幫你處理所有的事。但是在React生態中，儘管需要對組件做一些決定（哈這就是你為什麼要閱讀本文的原因啦），但是這方案更強壯。很多其他框架，譬如Angular2.0正在快速追趕React。
『選擇React不僅是個技術上的選擇，更多是個商業決定！』


額外獎勵：一旦你要著手構建自己的移動應用，你會感謝ReactNative項目的

（很牽強哈，Angular社區的Ionic也是PC Web向移動端遷移的好選擇。各自的2.0版本也相輔相成推進上）
應用生命周期：Redux?
PS: 以上不是它最終的logo
現在我們有了我們的視圖和組件層，應用程序還需要管理數據狀態和應用的生命周期。Redux也是毋容置疑的優勝者。
除了React，Facebook展示了名叫Flux的單向數據流的設計模式。Flux最早用來解決和簡化應用的狀態管理，但是隨之而來，很多開發者提出了不少新的問題如如何存儲數據狀態和從哪發送Ajax請求。
為了解決這些問題，不少基於Flux模式之上的框架誕生了：Fluxible, Reflux, Alt, Flummox, Lux, Nuclear, Fluxxor 還有很多。
不過，這其中的類Flux的優雅實現最終贏得了社區的關注，它就是Redux。
最重要的是，學習Redux小菜一碟。它的作者，Dan Abranmov是一位非常棒的老師（他的教學視頻非常易懂好學）。通過那些視頻你很容易成為Redux的專家。我見見識到一組幾乎沒有任何React開發經驗的工程師通過學習他的視頻，在幾周內就開發好能上線的React項目（代碼質量也是頂級的）
Redux的生態系統和Redux本身一樣優秀。從神乎其神的開發者工具到令人記憶深刻的reselect，Redux的社區是你最好的後盾。
不過有一點需要注意的是不要輕易的去嘗試抽象Redux的項目模板。那些模板背後都是有意義有原因的。所以你嘗試盲目修改前確保你已經使用過它和理解這樣組織代碼背後的原因。
語言：ES6配合Babel，先不加類型?
不用在用CoffeeScript了（譯者哭了出來，公司13年大規模的使用它，至今後端JS項目80%都是它的身影）。因為它的大部分好的特性在ES6都有了（它是JavaScript的標準語言規範），而且CoffeeScript的工具很弱（如CoffeeLint），它的社區也在快速的衰落。
ES6是語言的標準。它的大部分特性在最新的主流瀏覽器中已經被實現，Babel是個可插拔ES6編譯器。把它配置到使用合適的預設目標（preset target，如es2015瀏覽器，es2015-node5），就可以開動了。
那麼關於類型了，TypeScript和FLow都給JavaScript提供了加上靜態類型的功能，來配合編輯器提供更好的IDE支持和不需要測試就能捕獲一些bug。不過我還是建議，先等等看，看看社區的進展和動向。
TypeScript做了很多工作讓JavaScript寫起來看起來非常像Java/C#，但它缺乏完善的現代化的類型系統特性如代數數據類型（它對你真正開始實操靜態類型時是很重要的）。它也不像Flow那樣很好的處理 nulls。
更新：TypeScript有union types也能覆蓋很多用戶開發場景。
Flow比起來似乎更強大，能捕獲到更大範圍的bug異常，但是比較難設置。在語言特性上，它比起Babel落後不少，在Windows上的支持也不好。
我要說些有爭議性的話了：類型在前端開發中並沒有我們想的那麼重要（可能需要寫一篇長文來講述了）。所以就先等著類型系統變得更強健，目前先只使用Babel，同時關注下Flow~
格式和風格：ESlint配合Airbnb指南?
關於ESLint異議也不大。使用它的React插件和良好的es6的支持，幾乎非常完美完成lint的工作。JSLint是過時了，ESLint這個軟體可以單獨完成原本需要 JSHint 和 JSCS 聯合起來做的事。
你需要配置他用你的風格約定。我強烈建議你使用 Airbnb的風格指南，大部分可以被 ESLint airbnb config 來嚴格約束實現。如果你們團隊會在代碼風格上產生分歧和爭超，那麼拿出這份指南來終結所有的不服！它也不是完美的（因為完美的風格不存在），但保持統一一致的代碼風格是要高度推薦的。
一旦你開始熟悉它，我建議你開啟更多的規則。在編輯撰寫代碼時候越多的捕獲不規範（配置你的編輯器IDE使用上這個ESLint插件），就會避免分歧和在決定費神，從而讓你和團隊更加高效！
依賴管理：僅考慮NPM，CommonJS 和ES6模塊?
這一點很明確 - 就用NPM。所有東西，忘記之前的bower。類似與 Browserify 和 Webpack 的構建工具把npm的強大功能引到了web上。版本處理變得很簡單，你也獲得了node生態的大部分模塊提供的功能。不過CSS的相關處理還是不夠完美。
你可能會考慮的一件事：如何在開發伺服器構建應用。不想Ruby社區的Bundler，npm 常使用通配符來指定版本號，導致你開始書寫代碼到最後部署時候版本號很可能已經變化了。使用 shrinkwrap 文件來鎖定你的依賴（我建議使用 Uber的 shrinkwrap 來獲得更見一致性的輸入）。同時考慮使用利用類似於 Sinopia 來構建自己的私有npm伺服器。
Babel可以把 ES6 模塊語法編譯到CommonJS。意味著你可面向未來的語法，和在使用構建工具（如Webpack 2.0）時獲得它支持的一些靜態代碼分析工具如 tree shaking 的優勢
構建工具：Webpack?
不想在你的頁面文件中加入非常多的外鏈Script引用，那你就需要一個構建工具來打包你的依賴。如果你也需要允許npm包在瀏覽器運行工作的工具，那麼Webpack就是你需要的。
一年前，關於這塊還有不少選擇。根據你的開發環境，你可以利用Rails的sprockets來解決類似問題。RequireJS，Browserify和Webpack都是以JavaScript基礎的工具，現在RollupJS聲稱自己在ES6模塊上處理的更好。
在一個個嘗試使用後，我最終還是高度推薦Webpack：


它有自己獨特的寫法，不過即使是最少見的場景也能找到解決的方法
主流的模塊格式都支持（如AMD，CommonJS，Globals寫法）
它有處理有問題模塊的能力（不是標準的模塊寫法
它能處理CSS文件
它有最完善的cache busting/hashing 系統（如果你需要把你的資源發布到CDN）
它內置熱載入功能
它能載入幾乎你需要的一切
它一套令人驚嘆的優化列表

Webpack目前也是處理大型SPA應用項目的最好方案，利用它的代碼切割（code splitting）和懶載入特性。
不過它的學習曲線很陡峭，但是一點你掌握了，你還是會認為非常值得因為它的強大功能。
那麼Gulp或Grunt呢？ Webpack比起來最適合處理靜態資源。所以他們開始可以用來跑一些其他的任務（但是也不推薦），現在更簡單的方法是直接用上 npm scripts
測試：Mocha + Chai + Sinon（但沒那麼簡單）?
目前在 JavaScript 單元測試上，我們有眾多選擇，你選擇任何一個都不會錯太多。因為你開始做單元測試，你就走對一大步了。
一些選擇包括了 Jasmine，Mocha，Tape，AVA 和 Jest。我知道我漏掉來一些，它們都有一些比其他做的好的地方。
我對一個測試框架的的選擇標準是：


它應該可以在瀏覽器中運行從而方便調試
它應該運行的足夠快
它可以很好的處理解決非同步測試
它可以在命令行就能很方便的使用
它應該允許我使用任意斷言庫，而不會約束限制

第一個指標讓AVA脫穎而出（因為它的確做的非常棒）和Jest（自動Mocking並不像它說的那麼好，因為它太慢了）
選擇Jasmine，Mocha或Tape都不會差太多。我傾向於 Chai 斷言因為它擁有很多插件，Sinon"s mocks to Jasmine"s built in construct。Mocha的非同步測試支持很棒（你不用在寫類似於 done callback之類的）。Chai as Promised 也是很屌。我強烈建議你使用 Dirty Chai 來避免一些讓人頭疼的問題。Webpack的mocha loader 讓你編碼時自動執行測試。
對於React而言，Airbnb的Enzyme和Teaspoon（不是Rails那個！）是不錯的相關工具選擇。
我非常喜歡Mocha的特性和支持情況。如果你喜歡一些最小主義的，讀讀這篇關於tape的文章
PS：
Facebook在最近的文章中說，它們是如何擴展Jest的。可能對大部分人來說過於複雜了，如果你有那些資源，不關心是否在瀏覽器中跑測試，那麼它就很適合你。
另外，很多人認為我對AVA太武斷了。不要誤會我，AVA的確很棒。但我有個標準：全瀏覽器支持。這樣我們可以直接從任何瀏覽器去執行（來測試跨瀏覽器兼容性）同時要方便調試。如果你不介意那些，你可以使用非常棒的iron-node來debugging。
工具庫：Lodash是絕對王者，但留意 Ramda
JavaScript不像Java或.NET上有很多強大的內置工具集。所以你可能需要引入一個。
Lodash，目前來說應該是雜七雜八都有的首選。同時它類似注入懶求值這樣的特性讓它成為性能最高的選擇之一。如果你不想用你就不要把它全部都導入，同時：lodash能讓你僅僅引入哪些你需要的函數（這點尤其重要考慮到它現在變得越來越大）。隨著4.x版本帶來，它原生支持可選的函數式模式給那些函數式編程的極客們使用。來看看怎麼使用它
如果你真的很喜歡函數式編程，那麼不管怎麼樣，留意下優秀的Ramda。如果你決定用它，你可能還是需要引入一些lodash函數（Ramda目前專註於數據處理和函數式構建），但這樣你能在JavaScript中以非常友好方式獲得函數式編程的強大功能
Http請求：就只用fetch
許多React應用再也不需要jQuery了。除非你需要使用一些遺留的老舊的第三方組件（它依賴於jQuery），因為根本沒必要。同時，意味著你需要一個類似於$.ajax的替代品。
為了保持簡單，僅僅使用fetch，它在Firefox和Chrome中內建支持。對於其他瀏覽器，你可能需要引入polyfill。我推薦使用isomorphic-fetch 來在伺服器端在內覆蓋了基礎組件選擇。
還有一些其他好的類庫選擇如Axios，但目前在fetch之上沒有多餘需求。
為了更多關於為什麼Promise是重要的討論，請看我們博客非同步代碼
樣式：考慮CSS模塊
這是個我覺得相對發展較慢的領域。Sass就是目前的選擇，使用node-sass是你JavaScript項目的不錯開始、。我仍然覺得離最終最好的方案還是有很多不足。缺乏引用導入（如僅僅是從文件導入變數和mixin，而不用重新定義選擇器和它的樣式規則）和原生的URL重寫（使它在保持線上代碼足夠精簡就很困難）。node-sass是一個C寫的類庫，所以要對應好你的Node版本。
LESS並不受此影響，不過它缺了很多Sass的特性功能。
PostCSS 看起來更有生命力，它允許你構建自己的CSS預處理器。我推薦你使用它，即使你已經有了你喜歡的預處理器如SASS，它類似於AutoPrefixer使得你不需要要導入類似於Bourbon這樣的大型依賴。
有一點需要特殊注意的是，CSS Modules。它限制了CSS的層疊部分，使得我們可以定義更加明確的依賴，來避免衝突。你再也不用擔心Class名稱一致導致的覆蓋，也不用特意為了避免它而添加額外的前綴。它和React也配合的很好。有個不足：css-loader和css modules一起使用會導致非常緩慢，如果你的樣式數量不少，那麼在它優化之前還是避免使用它吧。
如果要我現在從頭開始一個新項目，那麼我大概會使用PostCSS配合一些我喜歡的預編譯的CSS類庫。
不管你選擇什麼，我還是推薦你看下我這篇文章CSS performance with Webpack，尤其你也在配套使用SASS。
前後同構：確保你真的需要它
Universal或Isometric的JavaScript代表著JavaScript寫的代碼可以被同時運行在客戶端和伺服器上。這需要用來在伺服器端預先渲染頁面來提升性能或SEO友好。感謝React，之前只有類似於Ebay或Facebook這樣的巨型科技公司才能實施的方案，現在很多小的開發團隊都能做到。不過它並不那麼容易，它顯著的加大了複雜性，限制了你類庫和工具選擇。
如果你在構建B2C的網站，類似於電商網站，那麼你可能必須使用這個方案。但如果你是在做內部網站或者是B2B應用站點，那麼這樣的性能提升和SEO其實並不需要。所以和你的項目經理討論下，看看是否有必要~
API介面：暫時沒有好方案
看起來每個開發者最後都會疑問那麼關於API介面呢？很多人會直接想到RESTful API（因為太流行了），同時SOAP真的成為過去式了。同時現在也有不少其他標準如：HATEOAS, JSON API,HAL,GraphQL 等
GraphQL 賦予客戶端強大的能力（也是職責），允許它來實施任意的查詢介面。結合Relay，它能為你處理客戶端狀態和緩存。在伺服器端實施GraphQL看起來比較困難而且現有的文檔大部分是針對Node.js的
網飛(NetFlix）的Falcor 看起來它也能提供那些Relay和GraphQL提供的功能，但是對於伺服器端的實現要求很低。但現在它僅僅是開發者預覽版沒有正式發布。
所有這些有名的標準規範有他們各種的奇怪之處。一些是過於複雜，一些只能處理讀取沒有覆蓋到更新介面。一些又嚴重和REST走失。許多人選擇構建它們自己的，但是最終也要解決它們設計上帶來的問題。
我不認為現在有什麼方案是個大滿貫（完美的），但是下面是我對API應該有的功能的一些思考：


它應該是可預測的，你的API節點應該是遵循一致性規範的
它可以在一次就能拉取多個資源的數據（如果你的應用啟動需要來回請求十幾個介面來獲得相關的資源數據，應用的性能應該是非常糟糕的
它可以覆蓋除去讀取，也包括更新的能力（很多方案僅僅提供讀取的
它應該容易debug：譬如看看Chrome的開發者工具的network網路tab下就能審視發生了什麼
它應該容易被消費，譬如可以簡單的通過 fetch API 方式或者有相應的客戶端類庫支持如Relay

我沒有找到能覆蓋這些需求的方案。如果有，務必讓我知道。
同事考慮，如果你實施一個標準化的RESTful資源路徑時，使用Swagger來文檔化我們的API。
客戶端軟體：Electron
Electron 是Atom這個優秀編輯器的背後基石。你可以用它來構建自己的應用程序。它的核心，就是一個特殊版本的Node可以來打開Chrome窗口來渲染GUI頁面，並且能夠獲取到操作系統底層的API（不用藉助瀏覽器的安全沙箱等措施）。你可以打包你的應用程序像其他的桌面客戶端軟體那樣分發安裝包，並且輔以自動更新機制。
這就是用來構建橫跨OSX，WIndows和Linux這多個桌面環境的應用軟體的最簡單的方式，利用起上面提到的所有好用的工具。它也有不錯的文檔和活躍的社區支持。
你也許也聽過nw.js（之前叫node-webkit）它年事已高，Electron比它更穩健，更容易上手使用。
來使用這個模板項目來開搞自己的Electron，React和熱更新項目吧，你可以看看這些東西是怎麼相互配合工作的~
向誰學習，從哪學起
社區有一些大牛，你可以在Twitter，Weibo，掘金上關注他們。
還有不少好的文章和鏈接。
如 Removing user interface complexity, or why React is awesome 就是對了解React背後實現原理和原因的不錯講述。
如果你不需要，就別用它！
JavaScript生態區發展很快，欣欣向榮，在快速前進著。但是就像是隧道終點前的光明，最佳實踐不在劇烈變更著。現在關於需要學什麼越來越明確了。
最重要的是記住要保持簡單，如無必要，勿增實體。

如果你的應用就是兩三個頁面，那你不需要用到 Router。如果就一個頁面，那麼你也不用Redux，只需要用React自己管理狀態就好。你的應用就是簡單的 CRUD 程序，那麼不需要用到 Relay。你在學習 ES6 的語法，那麼先別急著弄 Async/Await 或者裝飾器。你準備開始學習 React 了，你不必要立馬就去了解 Hot Reload 熱更新和伺服器端渲染。如果你剛剛使用上 Webpack，那麼也別急著就來用代碼切割（code splitting）和多代碼塊（multiple chunks）。如果你才開始 Redux，那麼也不用匆忙用 Redux-Form 或 Redux-Sagas。
保持簡單，一次學一樣，你就不會像其他人一樣抱怨JavaScript的破碎（Fatigue
我少了什麼嗎？
這就是我對目前JavaScript生態現狀的看法和觀點。如果你覺得我遺漏了那些類別的討論，或者你認為我在一些選型上的決定不正確，你有更好的可以推薦。那麼留言吧~

謝邀。
2016對我來說很簡單，唯一目標是能寫點JavaScript。順便能整點SVG 和Web Animation。
react-native
electron
為了培養全端技術棧
redux
Relay
GraphQL
主要是理解架構思想
virtual DOM
vue
深入研究實現細節，知道原理
http2
service worker
主要是性能優化上的知識儲備
---------------------------------------------
2016-3-5補充：
鞏固基礎本是常態，不僅僅是2016要學。
造一個mvvm的輪子，學習下編譯原理
輪子飛快 天下未定 
我只想守著演算法導論，犀牛書直至天下一統，萬法歸一。
別整那些框架，庫。一年幾個完全學不過來。
跟著規範，es5，了解了嗎
es6會了嗎。
編程思想，設計思想，演算法都OK嗎。如果都不行，那學的框架有何意義，只是個搬磚的。
深入學習好 jQuery，然後保證自己有能力寫一個 jQuery，也就可以了。


Eloquent JavaScript
ES6
React Native

es5，es6。
CSS相關的黑魔法。
UI設計。
node，PHP擼一遍。
無聊寫寫iOS。
做幾個逗比項目。
寫幾篇逗比文章。
好好睡覺，來年來看完成多少。
少上知乎，少聽牛逼，別過分追新，別過分厭舊，技術不過一碗飯，再喜歡在中國也是先是飯後是事業，飯吃穩了再是菜，錦上添花。多掙錢，活好就是為掙錢，沒意義的為了學而學有毛前途？三兩人引領新技術的事悠著點做，扯著蛋了反而不好。2016年沒計劃，能寫代碼寫代碼，寫不了是我吃不了這口飯，就去干點別的
看到樓上們都有很完善的學習計劃，有點不敢把自己的計劃拿出來曬。
也許曬出來才能完成得更好，所以拋磚了。
主要任務是H5 Canvas。工作上有很多需要H5小遊戲的地方，所以要多多了解多多學習。目標是做一款想做的遊戲。
其次是ES5、ES6，基礎真的很重要，每一個屬性都要搞清楚明白。
與諸君共勉。
學英語。。
- 學英語看文檔
- 學java 熟悉後端的處理和複雜系統設計方式


1.有空的時候多看犀牛書
2.多做訂單（學的再多不去用時間長了忘了就白學了）
3.segmentfault上面多提問、多回答問題（這是一個真正專註技術的網站，有很多大神）
網路/伺服器


HTTP2
Nginx

語言


ES6
TypeScript

可視化/虛擬現實


WebGL
WebVR
Canvas
Three.js
D3.js

工程/框架


React
Redux

全端


Electron
React Native

媽蛋，好多東西要學啊，我好方...
GLR演算法，HM類型推導，抽象解釋，再擼個新語言......哦你說的前端不是指這個啊（逃
  推薦閱讀：
※自定義對象中this為什麼代表A.fn.A.init {}？
※webstorm 如何自定義代碼的補全提示,快捷輸入?
※瀏覽器自身為什麼不集成js，jQuery文件？反正每個網站基本都會用到？
※web前端工程師的迷茫？
※一般用哪些工具做大數據分析？
TAG:前端開發 | JavaScript | 前端工程師 | IT行業 | 



				               	
                
       
 
                             
		
    						
    	

    
    	
	
	



      
   一點新知 
    GetIt01