PTT推薦

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

看板Soft_Job標題Re: [討論] 請大家聊聊 JavaScript的缺陷作者
dream1124
(全新開始)
時間推噓11 推:13 噓:2 →:34

laputaflutin: 同意樓上,不過看到這次美國大選很多新聞網都拿11/04 21:02
laputaflutin: svelte來寫,感覺蠻有趣的,應該會拿來試試看11/04 21:03

禁不住好奇心的我終究還是去看一下 Svelte,

原來它是個反 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 那邊的運作模式可能會有些不同,

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

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

--

※ PTT留言評論
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 61.231.183.84 (臺灣)
PTT 網址

laputaflutin11/05 04:39這就跟我剛看到elm 有種我跑回去寫 GUI 的感覺一樣

superpai11/05 05:56一切只為了人類等那幾秒reload

superpai11/05 05:56應該是說不想等

jobintan11/05 07:13SSR正是解決SPA加載時空白時間,先有個東西給人看,免得

jobintan11/05 07:14有些人等著等著,耐心都等沒了,直接索性離開呢。

newhandfun11/05 09:54笑了,很幽默

chatnoir11/05 11:00覺得沒什麼不同就回去寫template語言囉

mercurycgt6811/05 13:00我主管都說給使用者看的就叫前端 給管理者看的頁面

mercurycgt6811/05 13:00都叫後端 所以 svelte 還是前端無誤

OhGNM11/05 13:19覺得你好像有點誤會, 推薦你可以看該作者的演講https://you

OhGNM11/05 13:19tu.be/AdNJ3fydeao

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

Jokering556611/05 13:52seo問題呢?

superpai11/05 15:33你的累跟麻煩是別人的樂趣欸

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

dojay11/05 16:35只能說你不暸解前端,現代前端框架都是想要提供 reactive

dojay11/05 16:35機制還有元件化,這兩樣東西已經被證明對開發效率有極大的

dojay11/05 16:35幫助,如何擁有這兩者的同時也貼近只用JS 的效能,才是各

dojay11/05 16:35個框架努力的目標,是你連目標都沒搞清楚,就別秀下限了。

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

stopcrying11/05 18:48一堆 local state 和 mutation 會讓你的元件很難 scal

stopcrying11/05 18:48e 吧

superpai11/05 19:29其實就是所謂不如單一語言是你自己的偏好而已,很多人就

superpai11/05 19:29是喜歡多個領域專用的語言然後湊在一起。

ku39999911/05 21:36...你的子原件還是要做loop或filter才有辦法顯示

ku39999911/05 21:38喔對不起我搞錯體的意思了

ku39999911/05 21:38display none喔 你4不4很久沒寫前端了

strlen11/05 23:12樓上剛好反證原生JS沒效率又難用 又一個幫忙證實JS就是垃

strlen11/05 23:12圾的證詞

strlen11/05 23:13你看看 要是JS原本就好棒棒 會需要那些一拖拉庫的低能函式

strlen11/05 23:13庫和框架?所有語言裡就JS最多「補強」 笑死

ku39999911/06 00:45現在的js並不慢耶,慢的是dom api。我是不會說他多好用

ku39999911/06 00:45,但就算其他語言你這樣用確定code review不會被定在牆

ku39999911/06 00:45上嗎?

ku39999911/06 00:47我只是想說,把這個跟jsp比表示他根本沒搞懂吧,批的很

ku39999911/06 00:47奇怪

ku39999911/06 00:50有時候人生就是這樣 語言缺陷多還是很多人用 要學會習慣

Schelfaniel11/06 10:49之前有想過要用 svelte,但總覺得不如用 Vue

ku39999911/06 14:22公司產品還是不要亂冒險...side project可以用

locklose11/06 16:13參考 https://bit.ly/3l4LEgf 的圖片說明,還真的有像

locklose11/06 16:14自己生成畫面與互動元件

locklose11/06 16:16原文: https://bit.ly/3n06nm2

Saaski11/06 20:47完全說出我對 SSR 的心聲。如果說為了 SEO 還勉勉強強可以

Saaski11/06 20:47理解,為了不想看到那一兩秒不到的 loading 畫面就繞這麼

Saaski11/06 20:47一大圈實在是……

Saaski11/06 20:48而且實際上真正的等待時間也沒少啊,一個暮四朝三的概念

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

wulouise11/07 08:55因為這樣就會被偽裝資料啊....要看當然要看真的

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

※ 編輯: dream1124 (118.160.95.12 臺灣), 11/07/2020 10:03:13

ku39999911/07 21:25dynamic rendering?

ku39999911/07 21:27google最新版的效能指標+效能會影響SEO 最後還是要做SSR

electgpro11/08 02:01論點完全沒沾到 reactive 且看起來完全不懂 FP 帶來的

electgpro11/08 02:03好處。建議你還是先去學懂了再來批。

electgpro11/08 02:05"怎麼寫得出回給 OhGNM" 問題是你沒有回到點耶