/cs/ - 程設交流

我完全不懂那些framework所以以下可能錯得很嚴重

framework主要是為了server-side render和reactive存在的
也就是如果你不使用這兩個東西，vanillajs應該是沒任何問題
然後如果你看看web以外的GUI library，也不會說很難維護
所以如果以上假設正確，維護性這點應該是沒問題

不過就開發效率而言各種framework提供的build process應該還是佔蠻大的比重
所以要找vanillajs應該是會比較貴吧

>>344

的確是滿離譜的，你接觸到的應該是NodeJS那類純後端吧。
這邊講的 React / Vue 之類前端框架主要目的就是把
「產生HTML」這件事情搬到前端來。
前後端之間的溝通只傳送資料，不傳送HTML，
HTML的部分由前端網頁在收到資料之後產生。
除此之外還可以做雙向綁定之類的。

前端框架比較矛盾的一點是在於這其實算是一種發展結果，
即使今天你限定你自己只准用 VanillaJS，
但是相關功能架一架之後為了重複運用一定會做某種程度的框架畫，
於是一個新的 OO.JS 就這樣誕生了。
雖然可能沒有 V/A/R 那麼複雜，但最終還會走上一樣的道路，
然後功能性還遠遠不及。

我是一直都認為前端完全走錯方向，搞得事倍功不到半。
但頗無奈，
現在也還在思考VanillaJS或者換個比較恰當且正確的說法：Javascript，
到底該怎麼做一個網站。我應該不是唯一一個這樣想的人，
我很好奇現在有沒有跟我一樣的人，甚至是正在商業中實踐這個想法的人。

如果只是簡單靜態網頁的話那當然沒什麼問題
但如果你是作那種互動性比較高的網站的話那還是用framework比較好
不然光處理reactive就會搞死你了
至於framework的話我目前是用svelte
它使用起來的體驗跟其它framework比起來算是比較接近vanilla了

>>355
前端發展會那麼扭曲歸根究底就出在web standard上
web standard限制你只能用html+css+js來做web開發
而這三個語言又被限制要能夠完整向下相容不能有breaking change
搞得一堆初期的爛設計沒辦法捨棄掉
然後功能追加又要一審再審進度夭壽慢
所以才會有一堆framework冒出來就是想要突破這些限制
現在只能寄望wasm發展起來後能夠改善這扭曲的環境吧

>>357

這老實說也是目前Vanilla派遇到的最大技術難點，
目前看起來也沒有甚麼現成的方法論可以用所以VanillaJS一直停在嘴砲或是半玩梗的階段。
就像樓下 No.360 說的，問題是出在Web Standard上，
可以說能弄出Standard就已經是很厲害的一件事情了。

>>360

Web Standard 的影響我覺得沒那麼大，

真的有問題的其實是心態，很多人都以為前端很簡單，然後發現不簡單之後就開始試圖把事情弄簡單(然後就是現在這慘況…
前端其實一點都不簡單，只是好接觸不用先裝一大堆東西(阿現在要了)，光是要理解HTML的ML(Markup Language)具體是甚麼就不是一件簡單的事情，更遑論去在標準框架內做變化。
CSS 雖然以不直接操作記憶體而言的確是高階語言，但實際上住海邊，根本可以說是把繪圖器七八成的變數都開出來給你改的程度。
JS 則是最痛苦的，因為被丟進來的我往都是連小白都不到的素人，還會被騙說這是一片白紙，才怪，
JS 最大的誤會就是這個，JS 是在網頁框架裡面運作的「腳本」而不是主角，「這不是我自己的程式，我必須跟瀏覽器的框架合作」，理解這點之後，就好理解很多。

以上算是這些年的心得。

>>現在只能寄望wasm發展起來後能夠改善這扭曲的環境吧

我也在期待WASM。這東西可能可以突破現在Javascript 獨大的狀況。
不過比起網頁的改造，我更期待的是這東西能夠開拓一條「非標準化網頁」的道路，
不依賴DOM而是隨製造商高興自己寫自己的介面語言。

HTML真的嚴重過勞了，人家最初的目的只是簡單的文件啊。
啊對了，有沒有人跟我一樣覺得 HTML 其實原本設計的目的比較接近 PDF 現在的位置：作為通用的文件傳遞標準。

>>但如果你是作那種互動性比較高的網站的話那還是用framework比較好
>>不然光處理reactive就會搞死你了

對，所以現在還是只能乖乖用框架，本公司是新專案被客戶逼著用Vue。
編輯方便性真的沒話說。

這種個人信仰的東西只能用下班時間加減拜一下。

是說關於Vanilla JS 的互動部分，我覺得會需要突破一些思考框架問題，
現在的思路大概是：

1. HTML本身就是並不是單純的介面標記，DOM跟程式不是分開的，是緊密結合的。
2. 資料不一定要存在Javascript管理的記憶體裡面，你也可以把它存在網頁上，用Markup的方式。
3. 雖然很多人可能對2的做法有很大疑慮，怕被使用者亂改什麼的，但其實這個安全性從來沒有過。所以放心去用吧，伺服器端做好檢查就好。
4. 不要覺得自己在寫程式，想像是路邊發送的傳單，下面有虛線可以把折價券/問券剪下來寫一寫交回去的那種。

現在的結論大概就是這樣吧。現在也慢慢在想辦法找機會實作。
這邊寫出來發洩一下，如果能啟發一些路人就更棒了。

>>361
html 一點也不複雜
只要會 div span p 就可以上了
甚至你要從頭 div 到尾也 ok
反正瀏覽器又不會跟你抱怨
真正複雜的是 SEO
說什麼你要用 article section aside 還什麼鬼的我搜尋才給你排高分喔
然後現在又叫你搞什麼 ally
媽的智障

>>363
>>html 一點也不複雜

這其實是我前面在講的心態錯誤的地方，
HTML本體不複雜，複雜的是自從有網際網路以來的發展歷史跟愛恨糾葛。
還有最重要的：這東西的本質，他的本質就是個Markup，介面的markup，
跟XUL / XAML 之類的東西同類，
不一樣的地方是HTML必須給N多個廠商實作不同的繪圖器等等。

而其他大致上只需要供應商自己顧好自己就好。
這部分需要去體驗過比較傳統GUI程式的撰寫方式才會比較有感覺。
我覺得這也是現在前端扭曲的肇因之一，很多人進來就是面對這些東西，
沒有碰過也不屑碰那些古老的東西，只是不斷地解決自己的問題，
沒有意識到自己走得有多偏，也沒辦法修正。

>>說什麼你要用 article section aside 還什麼鬼的我搜尋才給你排高分喔

這其實算是後面有從大div時代拉回來一點的表現啦。
更強調HTML的文件本質。