Lastor
coding 意外看到,居然有這種神祕的東西,把 JS 引擎整到 PHP 裡面執行
GitHub - phpv8/v8js: V8 Javascript Engine for PHP — ...
Lastor
這個 No 快笑死
https://imgs.plurk.com/QBn/j1B/j8hlpj4Pa7lnqs1AXTzKU8KOUlX_lg.png
Lastor
真的很想把 TS 整進 PHP 專案,但是 TS 要編譯,管理流程其實會搞得很麻煩。勢必會變成在 PHP 專案中,git 要同時記錄 src ts 與 output js,而且會強迫性的讓開發必須在本機上進行,遠端去跑 Node.js 編譯,怎麼想都不是個好主意
Lastor
編譯本身是不難,ts cli 就可以做到了,但實在想不到一個聰明的管理方案。或許可以考慮使用這類瀏覽器 runtime 編譯 ts 的方案,但這以效能角度來說,這 cost 我覺得不划算啊
GitHub - harrysolovay/ts-browser: 🦄 Compile (in work...
Lastor
拉到 Server 端處理的話,就算找到方法讓 PHP 去編譯 TS,但一樣會變成是在 runtime 時編譯,鐵定會影響效能。這真的有點兩難......
Lastor
除了在 js 開 ts-check 用 JSDoc 替代之外,似乎找不到更好的做法
Lastor
JSDoc 終究沒有 TS 那麼方便啊
Lastor
JSDoc 的缺陷就是 interface 宣告寫起來麻煩,要做到 interface extends 的話,寫法整個很複雜。另外,型別斷言寫起來也沒 TS 精簡,且終究他是 JS,依然無法在運行前自動回報 TypeError
Lastor
Laravel 似乎可以整合 PHP 與 Node.js build 架構,不過沒用過,不知道他是怎麼 work 的。總覺得原理可能也是很單純的把 composer 跟 npm 整在一個專案,一起跑而已
Lastor
越來越覺得,後端也用 Node.js 的話就真的省事很多
Lastor
或是完全把前後端分離,後端就單純當 API Server。可是既有架構就已經是 PHP SSR 了,去整個推翻掉並不是一個好主意
Lastor
memo,對岸也有人腦迴路跟我一樣,在想這件事啊。他碰到的情境跟我這邊實在很像
【第1592期】ts2php, 將你的 TypeScript 程式碼轉換為 PHP_前端早讀課 - 微文...
Lastor
他這個思路... 看起來是把 Next.js 跟 Nust.js 那一套 SSR 水合方案整過來,我覺得不好
Lastor
話說上面那個 ts-brower 有點瞎啊,號稱只有幾 kb 的 cost,看他源碼是直接讓瀏覽器在線把整包 typescript 拉下來,再用 ts 的 api 去編譯。而那一包 TS 要 10MB 啊,說輕量是想唬爛誰
載入新的回覆