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

看板Soft_Job作者 (全新開始)時間3年前 (2020/11/05 02:59), 3年前編輯推噓11(13推 2噓 34→)
留言49則, 17人參與, 3年前最新討論串4/19 (看更多)
推
11/04 21:02,
同意樓上，不過看到這次美國大選很多新聞網都拿
11/04 21:02
→
11/04 21:03,
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.cc), 來自: 61.231.183.84 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1604516373.A.39D.html
推
11/05 04:39, 3年前 , 1F
這就跟我剛看到elm 有種我跑回去寫 GUI 的感覺一樣
11/05 04:39, 1F
推
11/05 05:56, 3年前 , 2F
一切只為了人類等那幾秒reload
11/05 05:56, 2F
→
11/05 05:56, 3年前 , 3F
應該是說不想等
11/05 05:56, 3F
→
11/05 07:13, 3年前 , 4F
SSR正是解決SPA加載時空白時間，先有個東西給人看，免得
11/05 07:13, 4F
→
11/05 07:14, 3年前 , 5F
有些人等著等著，耐心都等沒了，直接索性離開呢。
11/05 07:14, 5F
推
11/05 09:54, 3年前 , 6F
笑了，很幽默
11/05 09:54, 6F
推
11/05 11:00, 3年前 , 7F
覺得沒什麼不同就回去寫template語言囉
11/05 11:00, 7F
推
11/05 13:00, 3年前 , 8F
我主管都說給使用者看的就叫前端 給管理者看的頁面
11/05 13:00, 8F
→
11/05 13:00, 3年前 , 9F
都叫後端 所以 svelte 還是前端無誤
11/05 13:00, 9F
→
11/05 13:19, 3年前 , 10F
覺得你好像有點誤會, 推薦你可以看該作者的演講https://you
11/05 13:19, 10F
→
11/05 13:19, 3年前 , 11F
tu.be/AdNJ3fydeao
11/05 13:19, 11F
他真的很屌，呢呢喃喃在它的語法和它生成的程式碼之間來來去去， 卻是少數讓我花了幾分鐘仍看不出有什麼重大突破的框架。 他就是想進一步改善前端開發者在意的幾項議題，例如讓前端開發時再少寫一點程式碼， 然後輸出的程式碼更簡短， 這樣要是你前端軟體規模夠大，那或許真能為團隊帶來足夠的好處，但代價是什麼？ 叫前端再多學一種語言 ─ svelte script 以及他開發出來的工具！ 你要同時用 html、css、javascript（或是 ts？）、svelte 語法開發前端模組， 然後再去熟悉他開發的工具了。 呃… 你不累嗎？ 不覺得更雜亂了嗎？ 逐行除錯的工具要去哪裡找？ 怎麼設定？ 調整或整合建置與打包工具不麻煩嗎？ 抽象洩漏的時候不可怕嗎？ 至於一人專案又無營利什麼的就更不用多提了。 你要用這種方式開發 SPA 為何不乾脆直接去用 GWT、flutter ，或是 qt 轉 wasm 那樣 單一語言，單一 programming mode，單一 api 開發前端的東西啊？ 這類工具以後就直接生成 wasm 了，到時你根本就不必理會框架生成什麼 js 程式碼， 交給廠商根據你寫的程式碼去最佳化就好。 效能差就罵原廠，真要簡單又效能佳就再回頭寫 js， 不像 svelte 竟然還拿他生成的東西出來當賣點講。 在我看他這方案贏不過目前主流 SPA 函式庫加上程式碼拆分再延遲載入的組合， 或是其他通用語言圖形介面轉 wasm，甚至是妥善模組化的後端樣板。 他就是在標新立異，為不一樣而不一樣，把事情弄得更複雜罷了。
推
11/05 13:52, 3年前 , 12F
seo問題呢？
11/05 13:52, 12F
推
11/05 15:33, 3年前 , 13F
你的累跟麻煩是別人的樂趣欸
11/05 15:33, 13F
玩啊～ 又沒說你不能找新玩具 我只是覺得開發者終究還是要讓精力盡可能投注在自己要開發的程式， 而不是用來開發自己要開發的程式之程式。
噓
11/05 16:35, 3年前 , 14F
只能說你不暸解前端，現代前端框架都是想要提供 reactive
11/05 16:35, 14F
→
11/05 16:35, 3年前 , 15F
機制還有元件化，這兩樣東西已經被證明對開發效率有極大的
11/05 16:35, 15F
→
11/05 16:35, 3年前 , 16F
幫助，如何擁有這兩者的同時也貼近只用JS 的效能，才是各
11/05 16:35, 16F
→
11/05 16:35, 3年前 , 17F
個框架努力的目標，是你連目標都沒搞清楚，就別秀下限了。
11/05 16:35, 17F
我若不懂他的限制與他的目標，那怎麼寫得出回給 OhGNM 的第二段內容？ 然而開發者終究還是要讓精力盡可能投注在自己要開發的程式， 而不是用來開發自己要開發的程式之程式。 你講的概念又是個已知用火的好例子，早在 react、vue 都沒問世之前， 其他通用語言圖形介面函式庫早就是一個一個元件，有介面內容隨狀態更新的設計了， 現在就只差轉成 wasm 讓瀏覽器可以讀罷了。 你若要那樣四種語言，模組碼與生成碼來回搞，那還真的不如去寫單一語言加 wasm。 看來我可能不懂框架的目標，而你卻是不懂工作的目標啊？ 最後附帶一提，他拿了一個 React 的 function 元件 todo list 在講 filter 的繁瑣， 然後說了自己提供的簡化語法。 但我轉頭一想，他為什麼要讓母元件過濾子元件的狀態再去變更 dom tree 結構， 而不是讓子元件自己管自己的狀態， 然後根據母元件給的參數和自己的狀態判斷要不要 display:none 就好？ 用它的 filter 語法可以縮短你 filter 的程式碼，但我連 filter 都不用欸～
→
11/05 18:48, 3年前 , 18F
一堆 local state 和 mutation 會讓你的元件很難 scal
11/05 18:48, 18F
→
11/05 18:48, 3年前 , 19F
e 吧
11/05 18:48, 19F
推
11/05 19:29, 3年前 , 20F
其實就是所謂不如單一語言是你自己的偏好而已，很多人就
11/05 19:29, 20F
→
11/05 19:29, 3年前 , 21F
是喜歡多個領域專用的語言然後湊在一起。
11/05 19:29, 21F
→
11/05 21:36, 3年前 , 22F
...你的子原件還是要做loop或filter才有辦法顯示
11/05 21:36, 22F
→
11/05 21:38, 3年前 , 23F
喔對不起我搞錯體的意思了
11/05 21:38, 23F
→
11/05 21:38, 3年前 , 24F
display none喔 你4不4很久沒寫前端了
11/05 21:38, 24F
推
11/05 23:12, 3年前 , 25F
樓上剛好反證原生JS沒效率又難用 又一個幫忙證實JS就是垃
11/05 23:12, 25F
→
11/05 23:12, 3年前 , 26F
圾的證詞
11/05 23:12, 26F
→
11/05 23:13, 3年前 , 27F
你看看 要是JS原本就好棒棒 會需要那些一拖拉庫的低能函式
11/05 23:13, 27F
→
11/05 23:13, 3年前 , 28F
庫和框架？所有語言裡就JS最多「補強」 笑死
11/05 23:13, 28F
→
11/06 00:45, 3年前 , 29F
現在的js並不慢耶，慢的是dom api。我是不會說他多好用
11/06 00:45, 29F
→
11/06 00:45, 3年前 , 30F
，但就算其他語言你這樣用確定code review不會被定在牆
11/06 00:45, 30F
→
11/06 00:45, 3年前 , 31F
上嗎？
11/06 00:45, 31F
→
11/06 00:47, 3年前 , 32F
我只是想說，把這個跟jsp比表示他根本沒搞懂吧，批的很
11/06 00:47, 32F
→
11/06 00:47, 3年前 , 33F
奇怪
11/06 00:47, 33F
→
11/06 00:50, 3年前 , 34F
有時候人生就是這樣 語言缺陷多還是很多人用 要學會習慣
11/06 00:50, 34F
→
11/06 10:49, 3年前 , 35F
之前有想過要用 svelte，但總覺得不如用 Vue
11/06 10:49, 35F
→
11/06 14:22, 3年前 , 36F
公司產品還是不要亂冒險...side project可以用
11/06 14:22, 36F
推
11/06 16:13, 3年前 , 37F
參考 https://bit.ly/3l4LEgf 的圖片說明,還真的有像
11/06 16:13, 37F
→
11/06 16:14, 3年前 , 38F
自己生成畫面與互動元件
11/06 16:14, 38F
推
11/06 16:16, 3年前 , 39F
11/06 16:16, 39F
推
11/06 20:47, 3年前 , 40F
完全說出我對 SSR 的心聲。如果說為了 SEO 還勉勉強強可以
11/06 20:47, 40F
→
11/06 20:47, 3年前 , 41F
理解，為了不想看到那一兩秒不到的 loading 畫面就繞這麼
11/06 20:47, 41F
→
11/06 20:47, 3年前 , 42F
一大圈實在是……
11/06 20:47, 42F
→
11/06 20:48, 3年前 , 43F
而且實際上真正的等待時間也沒少啊，一個暮四朝三的概念
11/06 20:48, 43F
就是為了 SEO 啦！ 但這點也別怪前端，依我看這其實是 Google 的問題。 Google 早在發展支援 SPA 的爬蟲技術之前就應該先提供一種 API 給前端， 讓前端能夠先快速產生要給搜尋引擎索引的內容， 然後再透過那個 API 通知 Google 它已呈現想給它索引的東西， 接著再產生要給使用者看的完整網頁。 這樣前端就不必非得在伺服器端產生頁面內容才敢送去客戶端。 為什麼有 sitemap 給搜尋引擎看，卻不願在 SPA 的時代提供這種 API 實在很奇怪。
推
11/07 08:55, 3年前 , 44F
因為這樣就會被偽裝資料啊....要看當然要看真的
11/07 08:55, 44F
就算提供 API 也不代表爬蟲只能解析使用者呼叫 API 之前產生的文件內容啊！ Google 可以抽驗網站的內容，看看呼叫 API 前後的資訊是否相似以防欺騙嘛～ 問題是若沒有這種 API，那前端開發者怎麼知道爬蟲能不能等到他呈現好網頁的內容？ 於是把原本在前端跑的程式放去後端的奇葩 SSR 不就勢在必行了？ ※ 編輯: dream1124 (118.160.95.12 臺灣), 11/07/2020 10:03:13
→
11/07 21:25, 3年前 , 45F
dynamic rendering？
11/07 21:25, 45F
→
11/07 21:27, 3年前 , 46F
google最新版的效能指標+效能會影響SEO 最後還是要做SSR
11/07 21:27, 46F
噓
11/08 02:01, 3年前 , 47F
論點完全沒沾到 reactive 且看起來完全不懂 FP 帶來的
11/08 02:01, 47F
→
11/08 02:03, 3年前 , 48F
好處。建議你還是先去學懂了再來批。
11/08 02:03, 48F
→
11/08 02:05, 3年前 , 49F
"怎麼寫得出回給 OhGNM" 問題是你沒有回到點耶
11/08 02:05, 49F
‣ 更多 dream1124 的文章
文章代碼(AID): #1VeleLET (Soft_Job)
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 4 之 19 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共19篇)
‣ 更多 dream1124 的文章
文章代碼(AID): #1VeleLET (Soft_Job)