Home » Posts tagged "framework"

JavaScript Framework 不可避免的成本

看到「The Baseline Costs of JavaScript Frameworks」這篇文章在研究目前主流 JavaScript Framework 無法避免的成本到底有多高。

文章的結論是目前常見的 JavaScript Framework 其實都很肥重,在網路速度不快的地方得花不少時間下載,在非旗艦的手機上會需要花不少時間處理 (parse & compile)。

這是 gzip 後的大小:

這是 parse & compile 的時間:

這是下載時間 (扣除 latency 與 TLS connection 建立時間):

並不是說不能用,但重點會在客群:

But it’s important to consider your audience. If you’re building for resource constrained devices — which you certainly are if your product targets a country like India — you could consider using a lighter framework such as Riot or Preact. Your users will thank you.

最後有建議如果只是要呈現資訊,不要用整套 JavaScript Framework,在有需要互動的地方另外寫就好了:

For websites that primarily display content, it’s more efficient and cost-effective to just send some server-rendered HTML down the wire. If there are areas of your website that require interactivity, you can always use JavaScript to build those specific parts.

沒有 Google 專屬套件的 Android

剛剛在「How to Android without Google」這邊的文章裡看到「How to Android without Google [easy way]」這篇指南,說明如何弄出一個沒有 Google 專屬套件的 Android 環境。

主要是 LineageOS 當作底層基礎 (作業系統),然後用 microG 提供 API 相容層,並且用 F-Droid 安裝 Open Source 軟體。

裡面有兩個方案以前沒看過,一個是 XPosedFramework,提供框架讓使用者有更強的控制力,更完整的說明可以參考「Xposed Framework + App Settings 為每個 App 設定不同的運行模式」這篇。

另外一個是 Yalp Store,當軟體只在 Google Play 平台上提供安裝的時候,就需要透過這個套件了 XD

Netflix 對 Landing Page 的效能改善計畫...

幹掉 React (噗):

官方帳號丟戰文出來... 後面就有人開始亂 XDDD

不過先拉回來看... 依照說明,其他頁面都還是跑 React,只有 Landing Page 被改寫,看起來 Landing Page 的 TTI (Time to Interactive) 是他們的 KPI,所以就被拿出來另外處理了...

當然也有可能有其他的陰謀論 (而且我覺得可能性是在的):因為之前 React 的專利問題,變成之後 Facebook 如果真的出手提出告訴,會以惡意侵權來告 (因為鬧這麼大以後,沒有理由裝作不知道了)。這次只換 Landing Page 可以當作是試水溫練功 (累積 migration 的經驗),後續再換內頁...

PHP 的 BotMan

看到「PHP BotMan」這個專案 (A framework agnostic PHP library to build chat bots),把各家 IM 工具都串起來讓你直接接上去用,在 initialize 完後,就可以這樣寫:

$botman->hears('keyword', function(BotMan $bot) {
    // do something to respond to message
    $bot->reply('You used a keyword!');
});

或是:

$botman->fallback(function(BotMan $bot) {
    return $bot->reply('Sorry I do not know this command');
});

把事情專注在 bot 邏輯本身,不需要去管怎麼跟 Facebook 或是 Slack 接的細節...

用起來有點苦的 Laravel...

Laravel 是個 PHP framework,是目前還蠻常看到討論的 PHP framework。不過實際在研究後發現用起來有點苦啊...

Laravel 官方覺得 PSR-2 是個鳥蛋 (參考 GitHub 上的 issue:「PSR-2 Conflicts」),而我也知道 PSR-2 不怎樣,但這好歹是個標準可以靠啊...

另外一個是 overhead,在 AWS 上用 m1.large 跑 Ubuntu 64bits 測試純 PHP 的 echo "Hello, world."; 可以到 8000 reqs/sec (這是開了 APC 的情況測試,比較接近 production),但同樣是要顯示 Hello, world.,用了 Laravel 後剩下 174 reqs/sec (debug mode 已經關閉),如果再套上 Laravel 的 View 就剩下 152 reqs/sec...

也就是說這個數字是起點 (往下的起點),這樣看起來有點慘烈啊...

Zend Framework 1 的 Zend_View 與 Zend Framework 2 的 Zend\View 的差異...

Zend Framework 1 的 Zend_View 實踐了 Rasmus Lerdorf (PHP 發明人) 的想法「PHP 本身就是 template language,不應該在 PHP 裡面再發明一套 template language」。

Zend_View 是可以獨立拿出來用的,使用方式很簡單:

$view = new Zend_View();
$view->setBasePath(realpath(__DIR__ . '/../application/view'));
echo $view->render('index/index.phtml');

這樣對應的 template 檔案是 application/view/scripts/index/index.phtml

Zend Framework 2 除了改用 namespace 外 (所以名稱從原來的 "_" 改成 "\"),還把 Zend\View 深度整合到 Zend\Mvc 裡,這使得要獨立拿出來用的手續就變得... 超... 麻... 煩...

透過 Composer 安裝的人除了在 composer.json 裡面要設定 zendframework/zend-view 外,還要設定 zendframework/zend-filter 才會動 (不知道為什麼沒被放進 dependency),像是這樣:

    "require": {
        "zendframework/zend-filter": "2.2.*",
        "zendframework/zend-view": "2.2.*"
    }

另外 ZF 2 的 Zend\View 則是透過 resolver 物件設定要讀哪個目錄,而非之前用 setBasePath 打發:

$resolver = new \Zend\View\Resolver\TemplatePathStack(
    array(
        'script_paths' => array(
            realpath(__DIR__ . '/../webdata/view/')
        )
    )
);

$renderer = new \Zend\View\Renderer\PhpRenderer();
$renderer->setResolver($resolver);

echo $renderer->render('index/index.phtml');

這樣對應的 template 檔案是 webdata/view/index/index.phtml,跟 ZF1 相比少了一個 scripts

ZF 的文件一如往常的難讀,還是要去翻 source code 才知道要這樣用,所以也跟往常一樣,寫下來避免之後又忘記...

Archives