Re: [討論] 請大家聊聊 JavaScript的缺陷

原來它是個反 React、反 Vue、反前端在瀏覽器動態解析樣板的框架兼開發工具。

它讓你在開發時期能夠先以 js 程式碼定義資料，

或是用它提供給你的特殊語法指示產生 html、css 等內容的邏輯，

接著它會依據你寫的 js 和特殊語法幫你產生 html 等資源並填充內容，

最後你再發佈這些資源到使用者的瀏覽器上……

咦…… 等等，這概念怎麼似曾相識啊？

這不就是古早 jsp、asp、php 時代後端吐網頁給瀏覽器的工作模式嗎？

前端從 jQuery 之後的 prototype、backbone 時代開始漸漸與後端分家，

衍生出 angular、react、vue 等函式庫，後來為了同時解決 SPA 和 SEO 的問題

又發展出令後端會心一笑的「server-side rendering」術語。

現在前端竟有人「標新立異」地發展出與 jsp、asp、php 概念相近的 Svelte。

真是太諷刺了前端，你離開你後端繞了一大圈，

最後寫出來的程式竟然是你不想寫的，後端的程式，

所以說呢，人心最後終究是要回到故鄉來的，

這個四千里長江的盡頭上海，或許正是你的極限也說不定。

Welcome home～ <3

小弟愚魯，除了 CDN 那邊的運作模式可能會有些不同，

以及後端伺服器執行時不用為樣板暖機以外，

實在不太懂這東西在用起來跟傳統後端樣板科技有多大不同啊～

--

他真的很屌，呢呢喃喃在它的語法和它生成的程式碼之間來來去去， 卻是少數讓我花了幾分鐘仍看不出有什麼重大突破的框架。 他就是想進一步改善前端開發者在意的幾項議題，例如讓前端開發時再少寫一點程式碼， 然後輸出的程式碼更簡短， 這樣要是你前端軟體規模夠大，那或許真能為團隊帶來足夠的好處，但代價是什麼？ 叫前端再多學一種語言 ─ svelte script 以及他開發出來的工具！ 你要同時用 html、css、javascript（或是 ts？）、svelte 語法開發前端模組， 然後再去熟悉他開發的工具了。 呃… 你不累嗎？ 不覺得更雜亂了嗎？ 逐行除錯的工具要去哪裡找？ 怎麼設定？ 調整或整合建置與打包工具不麻煩嗎？ 抽象洩漏的時候不可怕嗎？ 至於一人專案又無營利什麼的就更不用多提了。 你要用這種方式開發 SPA 為何不乾脆直接去用 GWT、flutter ，或是 qt 轉 wasm 那樣 單一語言，單一 programming mode，單一 api 開發前端的東西啊？ 這類工具以後就直接生成 wasm 了，到時你根本就不必理會框架生成什麼 js 程式碼， 交給廠商根據你寫的程式碼去最佳化就好。 效能差就罵原廠，真要簡單又效能佳就再回頭寫 js， 不像 svelte 竟然還拿他生成的東西出來當賣點講。 在我看他這方案贏不過目前主流 SPA 函式庫加上程式碼拆分再延遲載入的組合， 或是其他通用語言圖形介面轉 wasm，甚至是妥善模組化的後端樣板。 他就是在標新立異，為不一樣而不一樣，把事情弄得更複雜罷了。

玩啊～ 又沒說你不能找新玩具 我只是覺得開發者終究還是要讓精力盡可能投注在自己要開發的程式， 而不是用來開發自己要開發的程式之程式。

我若不懂他的限制與他的目標，那怎麼寫得出回給 OhGNM 的第二段內容？ 然而開發者終究還是要讓精力盡可能投注在自己要開發的程式， 而不是用來開發自己要開發的程式之程式。 你講的概念又是個已知用火的好例子，早在 react、vue 都沒問世之前， 其他通用語言圖形介面函式庫早就是一個一個元件，有介面內容隨狀態更新的設計了， 現在就只差轉成 wasm 讓瀏覽器可以讀罷了。 你若要那樣四種語言，模組碼與生成碼來回搞，那還真的不如去寫單一語言加 wasm。 看來我可能不懂框架的目標，而你卻是不懂工作的目標啊？ 最後附帶一提，他拿了一個 React 的 function 元件 todo list 在講 filter 的繁瑣， 然後說了自己提供的簡化語法。 但我轉頭一想，他為什麼要讓母元件過濾子元件的狀態再去變更 dom tree 結構， 而不是讓子元件自己管自己的狀態， 然後根據母元件給的參數和自己的狀態判斷要不要 display:none 就好？ 用它的 filter 語法可以縮短你 filter 的程式碼，但我連 filter 都不用欸～

就是為了 SEO 啦！ 但這點也別怪前端，依我看這其實是 Google 的問題。 Google 早在發展支援 SPA 的爬蟲技術之前就應該先提供一種 API 給前端， 讓前端能夠先快速產生要給搜尋引擎索引的內容， 然後再透過那個 API 通知 Google 它已呈現想給它索引的東西， 接著再產生要給使用者看的完整網頁。 這樣前端就不必非得在伺服器端產生頁面內容才敢送去客戶端。 為什麼有 sitemap 給搜尋引擎看，卻不願在 SPA 的時代提供這種 API 實在很奇怪。

就算提供 API 也不代表爬蟲只能解析使用者呼叫 API 之前產生的文件內容啊！ Google 可以抽驗網站的內容，看看呼叫 API 前後的資訊是否相似以防欺騙嘛～ 問題是若沒有這種 API，那前端開發者怎麼知道爬蟲能不能等到他呈現好網頁的內容？ 於是把原本在前端跑的程式放去後端的奇葩 SSR 不就勢在必行了？