三個不要再用 jQuery Promise 的理由

Update 2016/04/05 20:27
話說 beta 中的 jQuery 3.0 確定 Promise 的部分會是相容於 Promises/A+,到時候出了正式版本可以開心升級!


其實不要用 jQuery promise 這回事兒,時有所聞,最主要的原因是其實它實作的內容跟外面大部分的 Promise library (Promises/A+)都不一樣。

所以很多人覺得 jQuery 的 Promise 只是名為 Promise 的「某種東西」,並不是真正的 Promise。

想了解詳情可以看一下 2012 年的這篇文章
You're Missing the Point of Promises

然而我一直不以為意。

到這個星期我才切身的實際體會不要用的原因,這邊列出三點,應該是比較容易碰到的情況。

1. 面對靜態結果,$.when() 不會以非同步的方式產出 resolved promise

這個我想應該很多人已經有經驗 XD

舉例如下:

// 期待中,結果會是以 async 的方式取得

function xhrGet(something) {
    if (cache) {
        return $.when(cache);
    }
    return $.get(something);
}

/**
 * 在送出 XHR request 之後清空頁面,取得 response 之後重繪頁面
 * 
 * 沒有 cache - 正常運作
 *   有 cache - 在 `renderPage()` 之後才 `clearPage()`,頁面就沒了
 */
xhrGet(...).then(function (res) {
    renderPage(res);
});
clearPage();

那麼我們實際來確認一下大家的情況,下面用了三家的 library 來做測試:
(其中 Promise 的部分是用 polyfill 的方式,如果你的瀏覽器有原生支援就會用瀏覽器內建的)

Read on

週末長知識: scrollable <div> 的捲動重繪問題

前端也是做了很久,直到最近才發現這個事實,感覺有點羞愧 ww
為了讓同樣的事情不要再重演,決定專文說明之!

以下文章的內容基本以 Chrome 瀏覽器作為展示用的平台,所以一些 render performance 的問題不見得會出你家的瀏覽器上,畢竟各家瀏覽器為了讓使用者能夠順暢瀏覽網頁,可能還是有做一些各自的調整。

現在已知的是 Opera 在本文主題的範圍內所受的影響與 Chrome 是一樣的(同為 Blink引擎)。

scrollable <div>

其實直接看一下 CSS 就明白我的意思啦

.scrollable {
    height: 100%;
    overflow: auto;
}

其實就是帶有捲軸的 <div> 而已,它的特性是在內容超出設定的 寬度/高度 之後會出現捲軸(用 overflow: scroll 的話,會一直有捲軸)

捲動重繪問題,初次見面!

其實就是在新版的 手打 首頁。

其實一開始還感覺不大出來,但多捲幾下之後發現這個捲動的吃力程度連我的(三年前的)超級遊戲桌機都有點受不了,馬上來用 Chrome DevTools 看兩把!

從圖中可以清楚的看到每個 frame 中有很長的時間用在 painting,並且很多 frame 的運作時間超過 16~17ms,造成整體的 fps 沒辦法達到 60。

簡單的重現

Preview 的時候先按「Launch the preview in a separate window」在新視窗開啟,再來打開 DevTools 觀察比較準(原本擺在 iframe 裡可能會影響結果)

確認的方法就是開啟 DevTools 裡的「Enable paint flashing」,就可以在捲動的時候看到重繪的區域。

Read on

angular-highlightjs v0.5.0 released!

https://github.com/pc035860/angular-highlightjs/releases/tag/v0.5.0

本來以為之前解掉神秘的 Webpack 問題,這次竟然因為有人嘗試使用 RequireJS 而破功 (X)

之前的 Webpack 問題
https://github.com/pc035860/angular-highlightjs/issues/26#issuecomment-125014758

本來以為順利改成 UMD 了(dependencies 之類的),結果 Webpack 在 UMD 的 syntax 之下竟然會嘗試 resolve 兩種 pattern 的 dependency... (在 browserfiy 正常,在 Webpack 會掛掉)

最後還是透過奇技淫巧,把 UMD 改寫成了一下才順利騙過 Webpack (O)

結果這次回過頭碰到 RequireJS 人,發現 highlightjs 在 npm package 跟 CommonJS 下的名字是不一樣 www
https://github.com/pc035860/angular-highlightjs/issues/47#issuecomment-129695318

總之,這次更新修了好幾個 bug,還終於把年初有人建議把所有 directive name 加上 prefix 的部分做掉了(老實說這不會花太多時間,但就是懶...)
有一種隨著 module 越擺越久,出現的問題漸漸比較難解決的 fu (X)

果然難解的問題都是要經過時間歷練的。

另外為何好像都沒有看過中文的 github open source 教學之類的,雖然已經搞了幾個 project 又過了這麼久,我總覺得目前我 維護 open source 專案的 github 操作方式好像不是很正確啊....

這個 repo 終於也突破 200 stars !

angular-easyfb v1.4.0 released!

https://goo.gl/9tPWeC

  • 支援 Ad Preview Plugin
  • 有鑑於支援 Ad Preview Plugin,將預設的 platform version 改為最新的 2.4

這次再版號上面其實是有點糾結的,主要是因為經歷了 Facebook Platform 從不需要帶 version 到需要帶 version 的這個轉換。

FB 1.0 -> FB 2.0

原本 init parameters 裡面不帶版號就使用的人再升到 FB 2.0 可能會遇到的問題是

  • 沒有帶版號所以預設使用 FB 2.0,造成自己有再使用的某些 API 崩壞

FB 官方的 API 文件其實是有明確表示需要帶版號的

然而從今年三月過後 FB 1.0 完全 deprecated,我為了盡量不造成人家的 app 掛掉,選擇預設帶入最舊的版號 2.0

FB 2.0 -> FB 2.4

結果前幾天一個新的 PR 表示想要支援一個新的 Facebook plugin 叫做 Ad Preview,這個 plugin 需要的是 FB 2.4。而這真的是尷尬到了極點啊~~~~

經過長考(!?)之後,還是決定以後都就直接帶入最新的 platform version 好了,反正依據官方文件這樣才是正確的行為。

於是乎,為了盡量造成最小的損害,我還是讓 version 的中間版號加了個 1 ,表示這還算是個有點大的改動。

Release 之後還是小小的擔心啊...

早餐吃麥片的COPY疑雲

Update 2015/09/07 已經收到來自早餐吃麥片的誠意道歉信

前兩天同事貼了一個截圖在 slack,所有在 channel 裡的人都震驚了。

是說如果使用我們家抄筆記來分享文章的話,點進來的人如果沒有安裝抄筆記,會看到一條精美的 側邊欄 (UX持續精進中),提示如果在閱讀英文的過程中碰到障礙可以參考使用我們家的 chrome extension。

對,該名同事只不過在 Facebook 上點了早餐吃麥片分享的 Popdaily 連結,竟然出現了跟我們家相似度高達9成的側邊欄。

早餐吃麥片與抄筆記側邊欄比較

由於這個 blog 基本上還是定位為技術 blog,我們就從多個角度來確認一下到底,只是設計上的相似呢?還是有實質上的 copy 呢?

前置作業

由於早餐吃麥片的版本使用了各種的高科技(X)

想要從瀏覽器上一窺其原始碼或是使用 Chrome DevTools 來分析需要一些小作業。

  • 點進連結之後會發現網址已經被改成 http://blog.morningshop.tw,這是用了 HTML5 pushState 來達到讓你重新整理此頁會直接跑到早餐吃麥片 blog 的效果,按上一頁再來檢視原始碼或開啟 DevTools
  • 發現重新進入頁面,側邊欄卻沒有跳出來,這是由於它使用了 cookie 來限制看到側邊欄的次數。可以直接將 blog.morningshop.tw 底下的 showside 清除或是直接用「無痕模式」來瀏覽

側邊欄附近

抄筆記

早餐吃麥片

<head> 裡面

抄筆記

早餐吃麥片

小結

明眼人大致上看了上面的截圖應該都可以了解兩者之接近程度,然而要怎麼證明是早餐吃麥片 copy 抄筆記,而不是相反呢?

其實早餐吃麥片的工程師感覺是有能力的,大部分該改掉的東西都有改掉,然而還是留下了幾個關鍵:

  1. CSS 檔名還是 note-article.min.css。當初取這個黨名就是因為抄筆記用來分享文章用的,我不懂為啥不把檔名改掉 www
  2. 抄筆記的核心配色是綠色的,CTA按鈕的 :hover:active 狀態也都是綠的,然而這部分被遺漏了 XD

一些感想

從上面的各種截圖可以看出來其實有改的部分也蠻多的,特別我沒有截到的程式碼部分大都是他們自己有另外再寫,利用 cookie 來鎖定兩小時才會看到一次是一個不錯的主意。而且還在持續更新中,硬是在外面的 frame 加上了早餐吃麥片粉絲團、分享跟讚之類的(這部分就覺得太過頭了)。

既然有能力做這些事情,為什麼還要複製我們的程式碼跟畫面呢?

我知道這種事可能對某些人來說是家常便飯,大家可能也見怪不怪,就跟如雨後春筍般冒出的內容農場一樣。

可能半年一年後你的產品大紅大紫,然而夜深人靜的時候請你仔細想想,這樣做你問心無愧嗎?