[ 首頁 / 搜尋 / 管理Discord ] [ Komica首頁 ] [ 跨版面 ] [ 雜談 / / 攝影 / 運動 ] [ 人工智慧 / 程設交流 ] [ 蔚藍檔案 / 英雄聯盟 / 米哈遊 / Minecraft / 魔物獵人 / 勝利女神:妮姬 / Pokémon / 刀劍亂舞 / Unlight ]

/cs/ - 程設交流

Computer science
名稱
Email
主題
回覆
檔案
嵌入
Options
密碼 (用來刪除檔案。)
  • Allowed file types:jpg, jpeg, png, gif, mp4, webm
  • Max filesize is 10 MB.
  • Max image dimensions are 10000 x 10000.
  • You may upload 1 per post.

  [Go to bottom]   [Catalog]   [返回]   [Archive]   [Featured]

File: 1743525312173.jpg (1.31 MB, 4000x2668, wallhaven-nrkyl7.jpg)

fb745441 No.337

被Vue的Datatable氣到,一個inline-editor居然弄不出來。
明明都弄成Compoenent了…
估狗+問AI搞了半天也想不出怎麼樣把Editor跟Datatable Compoenent合體。

氣死人,最後自己用 v-for + v-if 硬幹了。
是引進最新型的框架:香草JS的時候啦(做夢吧你

https://kknews.cc/zh-tw/code/3qjg2ag.html

每次看到這些東西都覺得前端真的走錯方向到很歡樂的地步。
公司+客戶都說要用Vue我也沒辦法,不過比較好奇現在世界上還
存在能夠只靠VanillaJS + HTML + CSS 弄出現代網站的前端工程師嗎?
又,如果發案的時候堅持這個組合,會需要付出更高的金額嗎?
另外是,這樣子設計的網站,有辦法維持相同的維護性嗎?
維護姓老實說是目前不依賴框架很難達到的地方。

8390e102 No.344

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

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

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

1bb3a439 No.355

>>344

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

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

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

885fe6cf No.357

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

885fe6cf No.360

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

23cc0c03 No.361

>>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 現在的位置:作為通用的文件傳遞標準。

23cc0c03 No.362

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

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

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

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

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

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

a31a3ad1 No.363

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

d30bd40f No.374

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

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

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

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


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

78da0bf1 No.397

>>360
我個人認為這才是前端的優點,或者說 HTML + CSS + JS的優點

再不套用任何框架的情況下,你今天所寫的網站,十年、二十年,甚至一百年後,看起來還是一樣(或幾乎一樣)

你不會因為今天 JS 升級了,就得讓你程式碼大改

框架就不同了,你今天要開發,你還要確定框架版本,框架每次更新都有可能把舊的API刪了,如果你使用的程式還真的有用到那API,那是很讓人吐血的

偏偏考量到安全性等地,有時還不得不改

b7f25598 No.402

>>397
之前看過有一個可行的發展方向是
把 browser 的核心功能 wasm 模組化讓開發者自行宣告要用哪個
例如 render 模組版本限定使用 html3+css2+es5 js
或是 net 模組限定只用 http3 這樣
這樣就不用被向下相容阻礙 standard 發展
還可以順便幫 browser 瘦身
而且這想法再進一步延伸讓社群發展出自己的模組 (使用 js 以外的語言且不仰賴 html+css 的 rener 引擎之類的)
一舉多得

1aee115a No.410

>>402
>>把 browser 的核心功能 wasm 模組化讓開發者自行宣告要用哪個

核心功能應該是指連線跟請求處理的部分吧?

>>例如 render 模組版本限定使用 html3+css2+es5 js


這個現在真的是一坨爛帳,
像是那個deprecate快20年的frame元素,也沒看到誰家真的把它砍掉。

>>還可以順便幫 browser 瘦身


這樣做其實反而會變胖,原本一個模組要變N個,各模組再最佳化分化一下dependency就不只三倍了。

>>而且這想法再進一步延伸讓社群發展出自己的模組 (使用 js 以外的語言且不仰賴 html+css 的 rener 引擎之類的)


底層的render引擎不太可能,這個可是瀏覽器大戰的重點戰場。
大家在拚的速度就是從HTML變成畫面上這堆東西的速度(因為現在大家愛用JS產HTML所以還有JS的執行速度)。
但是理論上應該可以開出一個統一的render引擎中介層,讓使用者可以自行定義非標準的TAG,
像是以前<div class="date_time_picker"> ,套入模組之後可以直接 <datetimepicker…/>。
這可以很大程度的解決現在比較複雜的功能通通都要靠JS+一大堆Div搞到一定得靠框架來處理的問題。

然後就是語言的部分
,現在已經有很多把其他語言搬上瀏覽器的嘗試,C++ / Python / .Net 甚至 Ruby(雖然好像都死光了) 都有。我覺得算是有點過頭了,尤其是.Net。
但我還是很期待那個 <script language="Whatever" > 的時代。

746333c0 No.424

>>355
近年好像比較流行後端和前端共用程式,框架自動完成後端和前端,網頁同時有靜態的特性和動態的功能

>>360
>功能追加又要一審再審進度夭壽慢
W3C強調的是HTML文件的本質很多功能根本和HTML本身無關
不過現在瀏覽器為了搶市占率提早加入很多設計未完成的功能,導致有很多功能是別的瀏覽器做了才發現設計缺陷,有不少砍掉重練的例子

>html+css+js

html+css+js三者性質完全不同,wasm頂多取代js
mozilla倒是有嘗試使用rust取代DOM API和Web API,純rust做網頁
也有不少人用wasm+canvas/webgl製作UI
最終問提又會回到如何設計reactive

>考量到安全性

最討厭遇到的是為了安全性進行破換性變更,改minor就算了連patch都要破壞,導致一堆dependencies失效

>>410
>自行定義非標準的TAG
已經有很久了,十幾年了依舊沒什麼人知道,Angular從Angular.js時代就在用了
問題就在自定TAG注定和SEO不相容
https://developer.mozilla.org/en-US/docs/Web/API/Web_components/Using_custom_elements

至於轉換自定TAG為標準TAG…就是現在大多前/後端框架在做的事

ffac467c No.425

File: 1749784325290.png (284.73 KB, 837x327, Screenshot 2025-06-12 1947….png)

>>424
>html+css+js三者性質完全不同,wasm頂多取代js
WASM HTTP server?
html+css是顯示文字風格和螢幕輸出的網頁
它們在build wasm 應用程式時會自動生成

wasm跑Doom3
https://youtu.be/nnQ-6eAfWuw?t=52

d92502c8 No.426

>>425
>WASM HTTP server?

老實說都有Javascript 的 NodeJS了,跑出NodeWASM 好像也不是甚麼奇怪的事情。
雖然這可能跟WASM的方向有點背道而馳。

>>已經有很久了,十幾年了依舊沒什麼人知道,Angular從Angular.js時代就在用了


我是知道有這種做法,第一次注意到好像是 C3.js。深深覺得那才是正確的方向。
不過一般前端開發好像有一點把這種作法視為禁忌不推薦。
所以就先當不存在。

只不過這種還是基於Javascript,
對WASM的期待是可以提供更底層的事件處理跟最佳化。

>>問題就在自定TAG注定和SEO不相容

SEO我覺得是其次,主要是大眾沒有往這個方向走,所以自然沒有往這方面去開規格。
要不然其實也就多個tag對應表, MyTag aka title 、MyTag2 aka section 這樣的事情而已。

d92502c8 No.427

>>424
>最討厭遇到的是為了安全性進行破換性變更,改minor就算了連patch都要破壞,導致一堆dependencies失效

這也是對WASM的期待之一,畢竟有了通用編譯對象之後,
被砍掉的東西可以自己加回去,或者愛加甚麼就加甚麼,
開發者/使用者自己負責,跟瀏覽器無關這樣。

fb19dbb4 No.429

>>410
瀏覽器大戰早就結束了
現在瀏覽器只有Safari跟Chrome (Chromium)兩種
但是Safari也只是靠Apple政策不要臉硬撐罷了
然後Firefox沒有呼吸就只是個時代的敗北者而已

fb19dbb4 No.430

>>426
>雖然這可能跟WASM的方向有點背道而馳
沒有背道而馳
你去查一下WASI就知道了
只能說WASM設計的太好
現在WASM在後端的發展比在前端還要迅速咧

>SEO我覺得是其次

以前SEO做的好不好可是能夠決定一個網站的生死的
你寫了一堆SEO看不懂的tag
它直接把你網站排名調到最低讓人搜不到你網站
看你還敢不敢其次它
不過現在AI漸漸改變了人們的搜尋方式
SEO準備要變天了

be9b9f8f No.431

>>430
>>以前SEO做的好不好可是能夠決定一個網站的生死的
>>你寫了一堆SEO看不懂的tag
>>它直接把你網站排名調到最低讓人搜不到你網站

我的意思是,因為主流沒有選擇這條路,
所以自然沒有在這條路上發展相關規格導致你說的狀況。
主流選了自定義HTML標籤這條路的話,自然會出現屬於這條路線的解決方案。
至於是因為沒有辦法做SEO所以拒絕自定義標籤,
還是因為沒有對自定義標籤開出規格導致無法做SEO就
多少有些雞生蛋蛋生雞的問題。不過不管怎樣最後主流都是選了div無雙框架架好架滿的道路。

200ed27b No.433

>>431
>主流選了自定義HTML標籤
並沒有阿
你不要看主流web framework都是component based就以為大家喜歡自定義tag
那個component本質上就跟class/function沒什麼兩樣而已
目的上就只是為了提升維護可讀性
實際上bundle完用的還是標準tag

>div無雙框架架好架滿

這個也沒有
事實上現在社群推廣的是semantic tags
也就是鼓勵多使用header/footer/article/section/aside這種a11y friendly的tag
有的framework還會專門內建linter去提醒你這樣不a11y咧
至於你猜為什麼社群會突然開始推a11y了咧?
沒錯就是SEO
因為SEO突然說什麼要照顧殘障族群社群才開始推這個
所以沒有什麼雞生蛋蛋生雞的問題
SEO叫你往西沒有人敢往東
自google誕生以來web開發社群一直都被SEO耍的團團轉

e6d291d0 No.434

>>433
>>主流選了自定義HTML標籤這條路"的話"

麻煩看清楚,我這句話是假設語氣。

200ed27b No.435

>>434
喔好喔歹勢喔
不過我想表達的是SEO就是主流
web開發再怎麼發展終究還是要看SEO的臉色
你以為為什麼現在web framework開始捨棄CSR又回頭擁抱SSR?
就是為了SEO
現在只期望AI趨勢能改變這個局面吧
不過更可能的是誕生另外一個SEO標準而已

7ed10010 No.436

>>435
>>你以為為什麼現在web framework開始捨棄CSR又回頭擁抱SSR?

詳細希望,有相關事件或報導嗎?
至少在我的認知裡,V/A/R依然是現在前端工程的代名詞。

200ed27b No.437

>>436
那你認知要更新了
現在Next.js, Nuxt, Remix, Astro這些framework全部都是SSR first
如果上面的framework你都不認識的話
那你搜尋一下"SSR CSR"就這兩個字就好就會有一堆文章冒出來
再不行的話你問個AI也好
如果你都不想找只想伸手的話
那下面這個我隨便找的
你把裡面的討論看看就可以感受到那個SSR復甦的氛圍了
https://news.ycombinator.com/item?id=37234310

72078100 No.443

>>437
>>現在Next.js, Nuxt, Remix, Astro這些framework全部都是SSR first

你這樣說我倒是想起來了,這些的確是有強調可以改用後端Render。

>>你把裡面的討論看看就可以感受到那個SSR復甦的氛圍了

>>https://news.ycombinator.com/item?id=37234310

也選個好一點的,你這串根本是SSR派系大本營沒辦法代表甚麼。
實際上也沒有辦法推翻「V/A/R仍然是前端主流,目前沒有動搖的跡象這點。」
我會再繼續觀察。
雖然沒甚麼解答到我的問題,但還是謝謝你。



[Go to top] [Catalog] [返回][Post a Reply]
刪除貼文 [ ]
[ 首頁 / 搜尋 / 管理Discord ] [ Komica首頁 ] [ 跨版面 ] [ 雜談 / / 攝影 / 運動 ] [ 人工智慧 / 程設交流 ] [ 蔚藍檔案 / 英雄聯盟 / 米哈遊 / Minecraft / 魔物獵人 / 勝利女神:妮姬 / Pokémon / 刀劍亂舞 / Unlight ]