🔍 搜尋結果:後端語言

🔍 搜尋結果:後端語言

Snake...純 HTML⁉️ [沒有 JS,沒有 CSS,沒有圖片!!] 😱

他們說有些人就是喜歡混亂。 大家好👋🏼,我是格雷厄姆「喜歡混亂」TheDev,這次我帶著另一個愚蠢的網路實驗回來了(如果你願意,你可以[直接跳到遊戲](#the-game))。 一切都是那麼天真地開始,「我可以寫一個貪吃蛇遊戲嗎?」。 但是,一如既往,我肩膀上的小惡魔低聲說「讓它變得更難」......所以我想「沒有 JavaScript,用純 CSS 來做」。 他再次嘰嘰喳喳地說:「噗,還是太簡單了,而且你最近做了太多 CSS 東西,用原始的、無樣式的 HTML 來做吧」。 我轉向另一邊肩膀,想聽聽天使的想法,希望得到更明智的結果。 然後我想起天使從來沒有在我身邊... 所以這就是,snake,純 HTML 格式(用一點 PHP 技巧來支援它)。 這是正確的! - 沒有 JavaScript - 沒有圖片 - 沒有CSS - 沒有 Cookie 不過,我想澄清一下(因為我不想被指責為點擊誘餌),我正在使用 PHP 渲染此 HTML。 雖然可以僅使用文件以純 HTML 形式完成此操作,無需後端語言,但它需要 640,345,228,142,352,307,046,244,325,015,114,448,670,890, 662,773,914,918,117,331,955,996,440,709,549,671,345,290,477,020,322,434,911,210,797,593,280,795,101, 545,372,667,251,627,877,890,009,349,763,765,710,326,350,331,533,965,349,868,386,831,339,352,024,373, 788,157,786,791,506,311,858,702,618,270,169,819,740,062,983,025,308,591,298,346,162,272,304,558,339, 520,759,611,505,302,236,086,810,433,297,255,194,852,674,432,232,438,669,948,422,404,232,599,805,551,610,635,942,376,961,399 ,231,917,134,063,858,996,537,970,147,827,206,606,320,217,379,472,010,321,356,624,613,809,077,942,304,597,360,699,567,595,836, 096,158,715,129,913,822,286,578,579,549,361,617,654,480,453,222,007,825,818,400,848,436,415,591,229,454,275,384,803,558,374,5 18,022,675,900,061,399,560,145,595,206,127,211,192,918,105,032,491,008,000,000,000,000,000,000,000,000,000,000,000,000,000,00 0,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000 個文件。 所以請原諒使用 PHP 產生下一頁的「捷徑」(對於那些在技術 Twitter 上花費太多時間的人,也請原諒我使用「死」語言!😱🤣)。 不管怎樣,序言太多了,我知道你為什麼來這裡,你想看到它的實際效果! 玩 HTML 貪吃蛇(有警告!) ---------------- 在桌面 PC 上的 Chrome 上執行...對於我來說,在 Firefox 和 iOS 上的任何瀏覽器上執行速度太快...您將在本文後面了解原因。 所以基本上,在桌面版 Chrome 中玩吧! 關鍵是: - ALT + I向上, - ALT + J向左, - ALT + K向下, - ALT + L向右, - ALT + O開始新遊戲(一旦你輸了)。 在 Mac 上,我相信是Control + Option而不是Alt ! 如果你想知道為什麼奇怪的鍵而不是 WASD,不幸的是ALT + D已經在 Windows 上的 Chrome 中使用,所以我不得不選擇「安全」鍵。 **最後一個警告:**我們用於實現此功能的技巧之一會用大量 URL 淹沒您的瀏覽器歷史記錄...您已被警告! ### 遊戲 **遺憾的是,這無法在 codepen 中執行,因此您必須[在我的網站上玩 HTML Snake](https://grahamthe.dev/demos/snake/) 。** 當你玩完後,回來看看我用了什麼技巧來完成這個工作(並在評論中分享你的最高分!)。 問題 1:取得遊戲勾選 ----------- 對於遊戲,您*通常*需要有一個“遊戲勾選”。每個刻度是當一個動作發生或您計算一個新的遊戲狀態然後渲染新的遊戲狀態。 但這提出了我們的第一個問題,我們如何能夠在沒有 JavaScript 的情況下自動更新頁面? 嗯,在 HTML 中執行此操作實際上非常簡單,我們只需將[`<meta http-equiv="refresh"`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/meta#http-equiv)設為較低值即可。 因此,我們從 0.35 秒刷新時間開始,然後隨著您的分數攀升,將刷新時間加快至 0.2 秒。 「元刷新」允許我們做的是指示瀏覽器載入頁面的 HTML 後,等待 X 秒,然後載入另一個 URL。 透過設定較低的刷新時間,然後更改我們在每次刷新時重定向到的 URL(稍後會詳細介紹),我們有一種方法可以讓頁面自行更改,即使您不按任何按鈕! 以下是格式的簡單範例: ``` <meta http-equiv="refresh" content="[time];url=[url-to-redirect-to]"> ``` **附註:**這是我之前提到的它不適用於其他瀏覽器的地方。他們不排除部分第二次刷新時間,因此刷新是即時的,使得遊戲太快而無法玩。 但僅元刷新不足以使遊戲正常執行,我們需要某種方法來保存遊戲狀態並將蛇方向的變化傳達給伺服器。 為此,我們使用另一個直接的技巧:URL 編碼的 GET 參數。 問題 2:管理遊戲狀態 ----------- 因為我們不能使用 POST 請求或類似的東西,所以我們需要另一個機制來管理瀏覽器和伺服器之間的遊戲狀態。 起初,我使用多個 GET 參數來管理狀態,因此 URL 如下所示: ``` url?playing=1&x=2&y=6&foodx=3&foody=6&dir=left. ``` 這一直工作得很好,直到我需要為蛇儲存多個點(它佔據的每個方塊的 x,y 座標)。 雖然我確實讓它與一些 hacky x,y 座標列表和解析一起工作(例如`snake=1,1,2,1` ,蛇位於x=1,y=1 和x=2,y=1),但這是凌亂的。 因此,我們轉向我們的好朋友: [`urlencode()`](https://www.php.net/manual/en/function.urlencode.php)和[`json_encode()`](https://www.php.net/manual/en/function.json-encode.php) 。 一起使用時,我可以取得一個陣列(或在本例中為多維陣列),將其轉換為 JSON,然後將其轉換為 URL 的有效字元。 讓我解釋: ### 在 URL 中儲存複雜資料 以下是我用於遊戲狀態的資料範例: ``` $state = array( 'width' => $width, 'height' => $height, 'snake' => array(array('x' => 5, 'y' => 5)), 'food' => array('x' => 7, 'y' => 7), 'direction' => 'right', 'score' => 0, 'state' => true ); ``` 要將這些資料儲存在 URL 中,我們可以使用以下命令: ``` $url = urlencode(json_encode($state)); ``` 透過 JSON 編碼我們的陣列,然後用 URL 友好的字符替換無效字符,這以 URL 友好(儘管不是人類友好!)的方式為我們提供了狀態: ``` %7B%22width%22%3A20%2C%22height%22%3A20%2C%22snake%22%3A%5B%7B%22x%22%3A19%2C%22y%22%3A5%7D%5D%2C%22food%22%3A%7B%22x%22%3A4%2C%22y%22%3A11%7D%2C%22direction%22%3A%22right%22%2C%22score%22%3A0%2C%22state%22%3Afalse%7D ``` 現在我們有一個機制可以將遊戲狀態傳遞到瀏覽器並備份到伺服器。 ### 最大 URL 長度 那些了解自己的東西的人會知道這裡有一個問題。 URL 長度有最大限制! 在 Chrome 中是 2083 個字元。 如果您玩遊戲的時間足夠長,您實際上會達到字元限制,因為為了儲存 x,y 位置對,我們每次使用超過 10 個字元。 但這是一個愚蠢的演示,所以我只想說:讓我知道如果你讓你的蛇足夠長,會發生什麼錯誤! 哦,在現實世界中,**您不應該對 URL 中的參數進行 JSON 編碼**,我們就這樣吧! 我們有狀態和遊戲標記,現在怎麼辦? ----------------- 這就對了! 嗯,差不多了。 我們需要將按鍵資訊傳達給伺服器。 ### 問題3:改變蛇的方向 這是最後一個問題(也是我們最終在 URL 中顯示遊戲狀態的原因),我們需要向伺服器傳達按鍵訊息以更改蛇的方向。 #### 問題 3a:按下按鈕 在我們將按鍵傳達給伺服器之前,我們需要某種方法來實際捕獲它們。 請記住,我們沒有 JS 來捕獲按鍵操作。 我們也不能使用`<button>`元素,因為它們需要 JS 才能運作。 所以我們剩下的就是不起眼的錨元素( `<a>` )。 但讓某人點擊錨點會讓遊戲變得很難玩。 幸運的是,HTML 中內建了一種名為[`accesskey`的](https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/accesskey)東西。 它們允許我們將一個字元指派給一個錨點,然後可以透過捷徑(ALT + Windows 上 Chrome 中的字元)存取這些字元。 這為我們提供了允許鍵盤控制的機制,我們只需要 4 個具有不同方向的連結(錨點)作為 URL,然後為每個連結分配一個`accesskey` 。 **重要提示:**應謹慎使用`accesskey` ,如果您選擇輔助科技 (AT) 使用者使用的按鍵,則可能會產生幹擾。 #### 問題 3b:方向 現在我們有了一種按鍵方法,以及一種將按鍵操作傳達給伺服器的方法,我們需要一種方法來管理按鍵操作,以便它們更新蛇的方向。 幸運的是,我們透過 URL 傳遞的狀態物件中已經有了一個`direction`屬性。 因此,我們要做的就是建立 4 個不同的 URL,每個方向一個。然後我們將這些加入到連結中就完成了。 ``` $encodedState = urlencode(json_encode($state)); <a href="index.php?state=<?php echo $encodedState; ?>&direction=up" accesskey="i">up (ALT + I)</a><br/> <a href="index.php?state=<?php echo $encodedState; ?>&direction=left" accesskey="j">left (ALT + J)</a> <a href="index.php?state=<?php echo $encodedState; ?>&direction=right" accesskey="l">right (ALT + L)</a> <a href="index.php?state=<?php echo $encodedState; ?>&direction=down" accesskey="k">down (ALT + K)</a> ``` 現在,例如,當您按ALT + K時,將單擊第四個連結,我們將當前狀態+新方向發送到伺服器! 現在剩下的就是獲取該資訊併計算下一個遊戲狀態。 ### 遊戲邏輯 最後,謎題的最後一部分是一些遊戲邏輯。 例如,在生成食物位置時,我們需要檢查它是否不在蛇已經佔據的圖塊上,因此我們有以下函數: ``` function generateFoodPosition($width, $height, $snake) { do { $food = array( 'x' => rand(0, $width - 1), 'y' => rand(0, $height - 1)); } while ( in_array($food, $snake) ); return $food; } ``` 還有一個移動蛇的功能 ``` function moveSnake($state) { $newHead = array('x' => $state['snake'][0]['x'], 'y' => $state['snake'][0]['y']); // Update snake's head position based on direction switch ($state['direction']) { case 'up': $newHead['y']--; break; case 'down': $newHead['y']++; break; case 'left': $newHead['x']--; break; case 'right': $newHead['x']++; break; } // Check if snake has collided with the wall or itself if ($newHead['x'] < 0 || $newHead['x'] >= $state['width'] || $newHead['y'] < 0 || $newHead['y'] >= $state['height'] || in_array($newHead, array_slice($state['snake'], 1))) { $state['state'] = false; return $state; // Game over } // Check if snake has eaten the food if ($newHead['x'] == $state['food']['x'] && $newHead['y'] == $state['food']['y']) { $state['score'] += 10; // Generate new food position $state['food'] = generateFoodPosition($state['width'], $state['height'], $state['snake']); } else { // Remove tail segment array_pop($state['snake']); } // Move snake array_unshift($state['snake'], $newHead); return $state; } ``` 以及建構遊戲板的循環。 ``` for ($y = 0; $y < 20; $y++) { echo "\r\n"; for ($x = 0; $x < 20; $x++) { if ($x == $state['food']['x'] && $y == $state['food']['y']) { echo '🍎'; } elseif (in_array(array('x' => $x, 'y' => $y), $state['snake'])) { echo '🟩'; }else{ echo '⬜'; } } } ``` 但我不會詳細介紹這些內容,因為您可以輕鬆找到(並找到更簡潔的方法)、找到其他人編寫的(更好的)程式碼並適應您的需求。 這是一個包裝 ------ 現在你已經知道了,我們使用元刷新、存取鍵和在 URL 中編碼複雜資料的技巧建立了一個遊戲。 這些東西對你的日常生活有用嗎?不,可能不會。 他們是否會在一個奇怪的邊緣情況下拯救你的屁股,完成這個工作,有能力使用黑客來交付產品情況?可能吧。 什麼?您沒想到我會提供您有用的教學嗎?你現在應該更清楚了。 但是,話雖如此,如果您確實喜歡這篇文章,或者奇蹟般地學到了一些新東西,請在下面給我留言,這真的意義重大! 祝大家週末愉快! 💗 --- 原文出處:https://dev.to/grahamthedev/snakein-pure-html-no-js-no-css-no-images-2ccg

您的下一個專案,可以試試看 HTMX 技術!

原文出處:https://dev.to/turculaurentiu91/why-you-should-choose-htmx-for-your-next-project-o7j 在本文中,我們將旨在了解為什麼您下次為 Web 應用程式選擇技術堆疊時應該考慮 HTMX 作為 React 的替代品。我們將研究傳統 HTTP JSON API + React 帶來的複雜性和挑戰,以及如何透過使用 HTMX 輕鬆避免它們。 **注意**:在本文中,我將討論 React,但它可以替換為任何其他前端框架,如 Angular、Vue、Svelte 或 Solid,但我談論 React 是因為它是大多數 Web 的預設技術開發人員預設為。 ### HTMX 到底是什麼 如果您還不知道,[HTMX](https://htmx.org/) 是一個小型瀏覽器 (JS) 庫,它使用一些屬性擴展了 HTML,允許您使用來自伺服器。它還使 HTML 能夠對所有動詞發出 HTTP 請求,而不僅僅是 GET 和 POST。 ## React 解決了什麼問題 React 是一個 JavaScript 程式庫,可協助您透過保持使用者介面與狀態同步來編寫高度互動的應用程式。您告訴它如何渲染給定的狀態,每次更新狀態時,它都會重新渲染(盡可能有效率)UI 以反映狀態變更。 每次狀態發生變化時,您都會通知庫它發生了變化,並提供新的狀態,它將處理 UI 更新。 需要本地記憶體狀態的高互動應用程式的範例可以是您可以在網路上找到的各種文字編輯器(VSCode)之一、拖放看板(如 Trello 或 JIRA)、視訊播放器或聊天室。 什麼不是此類應用程式的範例?您正在建立的待辦事項清單、您正在閱讀的新聞網站、您發布的部落格以及周圍的大多數網站。如果我們看一下 [80/20 規則](https://en.wikipedia.org/wiki/Pareto_principle) >80% 的結果來自 20% 的原因,80% 的結果來自 20% 的努力。 你可以說 80% 使用 React 的 Web 應用程式不需要本地狀態。對於那 20% 需要它的人來說,你可以說它只是應用程式的一小部分(大約 20%),其餘部分只能用 HTML 來表達。 **這些數字是編造的,我沒有任何研究來支持這一點** ## React 也解決了哪些問題,使其被現代網站廣泛採用 HTML 已經過時了。使用 HTML 製作應用程式的舊方法涉及頁面、連結和表單的集合,這些頁面、連結和表單向使用者描述給定資源的當前狀態以及他們可以執行哪些操作來更改它。 每次使用者與資源互動時,應用程式只能重新載入整個頁面以顯示資源的新狀態。 幾年後,FaceBook 推出了 React,這是一個 JS 程式庫,可讓開發人員建立單頁應用程式 (SPA)。導航時不再需要重新加載整個頁面,狀態更新的酷過渡、對用戶的有趣反饋以及其他使 Web 開發人員在其網站中採用 SPA 框架的細節。 ## 複雜性問題 ![AI 產生圖像,透過 next.js 展示現代應用程式的瘋狂複雜性](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/xpk0v0nz0d45hv91i166.png) 如果你不理解上面的架構,不用擔心,沒有什麼好理解的。我要求 ChantGPT 為我生成它,由於它過於複雜且沒有任何意義,它完美地反映了現代 Web 應用程式目前的預設基礎架構。 一個很酷的程式設計原則是**KISS**,它代表“保持簡單,愚蠢”,或者有些人可能喜歡開玩笑,“保持簡單,愚蠢!” 現代開發人員預設建立 Web 應用程式的當前基礎設施和技術堆疊極其複雜,做了很多不必要的事情,只是因為它很酷! 當您自己建立第一個 POC 時,效果很好,但下一刻您加入了更多團隊成員,並且使用多次迭代和「擁抱」更改的敏捷方式,它有點崩潰,原因是我們將往下看一下。 ## 傳統 HTTP JSON API + React 的狀態管理問題 在 Web 應用程式中,您經常要做的就是從資料庫中獲取資源的狀態並將其呈現給使用者。讓我們以任務管理應用程式為例。使用者有一個任務列表,每個任務都有一個狀態: - 任務的標題 - 說明 - 任務完成時的標誌 - 截止日期(可選) 我們通常將此狀態儲存在資料庫中,並將此資訊呈現給用戶,您必須: - 從使用者有權存取的資料庫中取得所有任務。 - 可以選擇轉換資料(也許您儲存完成的日期並從中計算「is_completed」標誌)。 - 將資料序列化為 JSON。 - 透過 HTTP 請求取得資料。 - (可選但通常)根據模式驗證資料,可能使用 YUP 或 ZOD。 - 使用 Redux、Zustand、react-query 或其他狀態管理庫將 JSON 轉換為狀態並將其儲存在快取中。 - 轉換 HTML 中的狀態,通常會決定使用者可以使用資料做什麼。 簡而言之,我們正在描述如何在 JavaScript 中渲染所有資源的所有可能狀態,在瀏覽器中下載所述 JavaScript,然後 JavaScript 下載一堆 JSON 格式的資料並將其渲染(如果它知道如何)瀏覽器顯示為HTML! 向使用者顯示任務清單需要做大量工作,特別是當任務僅在使用者變更時才更改時,應用程式必須將應用程式置於載入狀態,發出另一個 HTTP 請求(以PUT 或PATCH 或DELETE)使快取值(狀態)無效並重新獲取它以顯示更改的任務。 或者更糟的是,當用戶更改某些任務時,樂觀地更新本地狀態並立即顯示更改,並在幕後執行更新請求,僅在他們成功更新後通知用戶更新失敗。 這是非常容易出錯的。對於這個待辦事項應用程式來說,它可能會很有效,因為您是唯一的開發人員,並且該應用程式足夠大,您可以在腦海中保留正在發生的所有事情的地圖。但是當你的團隊規模更大時,尤其是當你將團隊分成前端和後端時,溝通不良可能會導致很多問題。 後端可能使用“is_completed”標誌,而前端可能需要“is_active”標誌。後端可能會將經過 Markdown 處理的「描述」傳送到 HTML,而前端可能希望它不被處理。後端可能會將“描述”設為可選,以允許使用者在前端不同步時保存草稿,並且您會看到許多“未捕獲的類型錯誤:無法讀取未定義的屬性(讀取“toLowerCase” )” 另一方面,在 HTMX 上,您可以直接在範本上呈現 HTML,只要後端語言允許,就可以確保類型安全。您僅向瀏覽器發送相關訊息,向使用者提供對資源的適當控制,並指示瀏覽器或 HTMX 如何解釋使用者操作以及後端對這些操作的回應。所有應用程式狀態都是 HTML,這個概念稱為 [HATEOAS](https://htmx.org/essays/hateoas/) ## 傳統 HTTP JSON API + React 對文件的需求 為了讓兩個團隊(後端和前端)獨立工作並透過 HTTP JSON API 進行通信,您需要擁有適當的 API 文件。您還需要記錄如何計算使用者可以對給定資源執行哪些操作以顯示控制項。 大多數此類文件寫起來都很痛苦,特別是因為通常需要在實作之前編寫,而開發人員尚未完全理解問題的範圍,因此前端可以並行開發。這通常會在開發過程中進行許多更新,以適應開發過程中出現的問題,並可能導致團隊之間的版本不一致。 您還需要對 API 進行版本控制,並注意不要在非主要版本變更中引入重大變更。您無法再在不變更主要版本的情況下變更欄位名稱。您還需要保持 API 的多個版本運作或強制前端團隊進行調整。 大多數時候,文件已經過時了。有些必須緊急修復,有些新要求是在發布前一天提出的,現在您的文件已經過時,即使在很短的時間內。而且您必須記住更新它,或者更糟的是,您建立了一張票來記住它,而其他人拿起它,但沒有完整的圖片並記錄了錯誤! ## 重複的邏輯問題 對於每個資源,您必須實施授權策略。您必須確定目前使用者是否可以將任務 **46234** 標記為已完成。您必須在後端程式碼的某個位置編寫此檢查。否則,您的應用程式將開放給_不安全的直接物件參考_,或任何使用 Postman 的人都可以將您的任務標記為已完成。 您還必須在前端實現相同的邏輯,僅當用戶有權標記已完成時才顯示標記按鈕(讓我們假設您可以與其他用戶共享您的任務,但只有您可以更改它們)。 現在每次這個邏輯改變時,你都必須在兩個應用程式中實作它,並同時發布它或擁有多個版本的API。 ## 效能問題 為了使用 React 在瀏覽器中呈現網站,您需要將佔用大量內存和解析/處理影響的 React 程式碼、狀態管理庫程式碼、腳趾 UI 庫程式碼、CSS-IN- 捆綁在一起。JS 庫程式碼、應用程式程式碼以及我們透過NPM 安裝和使用的任何js 程式庫(我們並不羞於安裝新套件,請參閱[leftpad 問題](https://www.theregister.com/2016/03/23/npm_left_pad_chaos/))。這通常會導致透過網路傳送大塊的 JavaScript 資源。當然,您可以在瀏覽器中緩存,但在現代敏捷開發中,每個衝刺至少部署一次,因此這無法解決任何問題。這會消耗網路流量和電池,這對行動裝置來說是一個經常被忽視的問題。 上述JavaScript需要由瀏覽器來解釋,消耗處理能力和電池。 JavaScript,尤其是 ReactDOM,需要追蹤 DOM 的鏡像。在其之上加入普通 DOM 和本地狀態緩存,以及所有渲染函數,以及所有“useMemo”、“useCallback”和“useState”。也要加入需要在記憶體中保存所有上下文變數的所有閉包。 JavaScript 引擎並不以其記憶體效率而聞名!您會聽到人們抱怨瀏覽器消耗了多少內存,但他們低估了他們存取的網站所消耗的內存量。 所有這些加起來,最終會耗盡用戶的電池和記憶體。當然,您可以付出努力並優化所有這些,或使用其他程式庫(如 Svelte),但所有這些努力都可以用於為您的用戶提供更有意義的功能。 ## 服務端渲染的需要 近年來,我們播種了伺服器端渲染專用框架(如「Next.js」)的興起。它們的流行凸顯了對以 HTML 格式交付內容的需求,特別是出於可存取性優化、效能和搜尋引擎優化的原因。 你不想等待瀏覽器下載 JavaScript 來渲染頁面,然後等待 JavaScript 發出 HTTP 請求來獲取內容然後渲染它,你希望它立即渲染,特別是對於上面的情況折疊內容。 這又增加了一層複雜性,包括: - 基礎設施,現在您還需要另一台伺服器用於前端應用程式 - 程式碼更複雜,包括什麼程式碼在伺服器上執行以及什麼在瀏覽器上執行的思維導圖 - 部署管道現在更加複雜 - 測試基礎設施現在更加複雜 - 現在解決問題變得更加困難,您需要了解問題是在瀏覽器上、在客戶端應用程式伺服器上還是在 API 伺服器上 ## 解決這些問題 Web 開發社群各自使用自己的語言或開發技術,以不同的方式解決這些問題: - Next.js(以及 Nuxt 等) - 反應伺服器元件 - 拉維爾 - 慣性.JS - 活線 - 點網 - Blazor 頁面 - 靈藥 - 鳳凰即時查看 - 鐵鏽 - 樂浦伺服器功能 還有許多我忘記或從未聽說過的其他解決方案! 無論如何,此類解決方案的存在和流行證明了這些問題是有效的並且在 Web 開發人員的日常生活中遇到過。否則他們不會不遺餘力地解決這些問題,尤其是以開源的方式! 還有 [Turbo](https://turbo.hotwired.dev/) 以及採用它們的框架、Ruby on Rails、PHP Symphony 以及其他可能以與 HTMX 相同的方式解決相同問題的框架。選擇 HTMX 只是個人喜好,但你絕對應該了解這一點,這和 HTMX 一樣酷! 在所有這些中,HTMX 脫穎而出,不僅因為它不會將您鎖定到特定技術,您可以透過對模板進行微小更改來從 PHP 切換到 Rust,而且還因為它完全消除了對有狀態元件的需求,或者需要追蹤與資源無關的應用程式的某種狀態。 例如,讓我們採用確認對話方塊模式。您通常最終要做的是,您有一個本地記憶體狀態(如果它是開啟的),並根據該狀態將其顯示給使用者。在 HTMX 中,狀態 **IS THE HTML** 意味著當您按一下開啟模式時,您 **GET** `tasks/{taskId}/confirm-delete` 並將回應 HTML 嵌入到 DOM 中。當它被刪除時,您就完全刪除了模式和任務!這以一種獨特且極其簡單的方式解決了上述所有問題,您不需要: - 追蹤狀態 - 知道如何渲染對話框 - 記錄API - 檢查使用者是否可以刪除任務(在前端) - 您的後端應用程式始終負責 - 您可以獲得更好的安全性,因為您不會向瀏覽器發送不相關的資料並竊取敏感資訊 - 你會得到更好的表現 __*最重要的是,您可以讓您的應用程式保持簡單,只有在解決使用者問題時才允許複雜性!*__ 您只需指示 HTMX 從何處獲取對話框以及將其放置在何處,一切就完成了! ``` <!-- the delete button --> @if ($chirp->user->is(auth()->user())) <form> @csrf @method('delete') <x-dropdown-link :component="'button'" type="submit" hx-get="{{ route('chirps.confirm-destroy', $chirp) }}" hx-swap="beforeend" hx-target="closest .chirp" > {{ __('Delete') }} </x-dropdown-link> </form> @endif <!-- the dialog template --> <div class="modal fixed z-10 inset-0 overflow-y-auto flex justify-center items-center bg-black bg-opacity-50" style="backdrop-filter: blur(14px);"> <div class="bg-white rounded p-6"> <h2 class="text-xl border-b pb-2 mb-2">Confirm Action</h2> <p>Are you sure you want to delete this chirp?</p> <div class="flex justify-end mt-4 gap-4"> <x-secondary-button _="on click remove closest .modal" > Cancel </x-secondary-button> <form> @csrf <x-danger-button hx-delete="{{route('chirps.destroy', $chirp)}}" hx-target="closest .chirp" hx-swap="delete"> Delete </x-danger-button> </form> </div> </div> </div> ``` _這個範例來自我的 [HTMX with Laravel] 教學(https://dev.to/turculaurentiu91/laravel-htmx--g0n) ,請看!_ 就像這樣,當我們單擊刪除按鈕時,我們指示 HTMX 對 `chirps/{chirp}/confirm-destroy` 執行 **GET** 請求,並將結果 HTML 放在最接近的父級 `< 之前div class="chirp">` 結束(在底部)。在刪除對話方塊中,當使用者確認時,我們指示 HTMX 對 `chirps/{chirp}` 端點執行 **DELETE** 請求,成功後,我們刪除具有 `chirp` 類別的最接近的父級。 ## 結論 在不斷發展的 Web 開發領域,看到 HTMX 等倡導簡單性和回歸基礎的工具令人耳目一新。透過利用 HTML 和 HTTP 的強大功能,HTMX 允許開發人員建立動態 Web 應用程式,而無需傳統 JavaScript 框架的複雜性和開銷。 因此,下次您開始新專案或考慮重構現有專案時,請嘗試 HTMX。您可能會驚訝於用這麼少的錢就能取得如此大的成就。

回答網友提問:如果前端要銜接後端的話,是不是學 node.js 比較快?

昨天在我們新手寫程式 LINE 群組,有幾個業界工程師&新手在討論: 如果前端要銜接後端的話,是不是學 node.js 比較快? https://line.me/ti/g2/nipkjq2WoZPKX5dTn9tE9266aEOt6EOICFGa1g 這主題很好,我決定單獨寫一篇文章討論這件事情 --- 首先,我很推薦新手前端也去學一點後端,這樣對整體概念會更清楚 這位網友提到的 node.js 很不錯,但是我更推薦去學 php,簡單幾個原因說明如下 # 無框架開發 常見的後端語言,在寫網站時,都需要套件&框架才能開發 - python 需要 django - ruby 需要 rails - java 需要 spring - node 需要 express 我建議你直接寫 php 做好玩的小網站,不要用框架 php 雖然現在都用 laravel 框架,但古早時代大家都寫純 php 如果現在只是自己做個小專案,當然寫純 php 也是夠用的 學框架沒什麼不好,但是,在新手一開始的階段,我更推薦從單純的東西開始學起 一來上手很快,二來等於是紮穩馬步,三來之後學框架可以去思考:如何用純 php 語言寫出框架元件 如果自己想補充後端知識,就試試純 php 吧!先別學 laravel,晚點再去學就好 # 後端先避免非同步程式設計 這件事比較 tricky,javascript 語言本身支援非同步,這在前端 UI 處理很好用 也就是常用的 async/await,`.then().then().then()` 或者到處傳 callback function 那些的 但是!我認為在寫後端的時候,這個語言特色會讓後端開發時,顯得有點囉唆 以後端讀取檔案內容來說,絕大多數情況下,你就是要現在就讀取好檔案、讀取完才讓程式接著繼續跑,才有意義 幾乎不存在「非同步去讀取檔案,不等結果,先直接去處理別的任務」這種情況 於是 node 後端程式碼就需要去傳 callback function 或者 async/await 我認為這有點囉唆,這些情境實在沒必要用「非同步程式設計」處理! node 社群自己也知道,所以除了 `fs.readFile` 之外,還有提供 `fs.readFileSync` 函式 作為一個教育者,我很不喜歡跟新手解釋,為甚麼會有這兩種函式,差異在哪 我認為新手後端,多去學非同步程式設計的觀念與技巧,是徒增挫折 用 python/php/ruby/java 寫後端,都不會遇到這個困擾 新手後端就學好 http 協定,GET 跟 POST 參數是怎麼傳遞的,怎麼使用 session,怎麼連接資料庫就好了 不要多被一個 asynchronous programming 困擾 # 多學一個程式語言 本身是前端工程師,再去學後端想用 node 繼續寫 javascript 當然很合理 不過,長遠來說,多學幾種程式語言,對職業生涯比較健康 首先,你會更有自信一點,並且,能夠開始比較各種程式語言的差異與哲學 很多在 A 語言理所當然的事情,在 B 語言是很罕見的 很多在 A 語言社群大家都說「對」的事情,在 B 語言社群大家都說「錯」 長遠職業生涯來說,你需要至少寫過多種程式語言,才會發現大多數事情都只是「不同社群」的「主觀偏好」 你會發現網路上多數講的斬釘截鐵的對錯觀念,都只是一種偏執。你的觀點會更全面 # 結論 以這位網友的狀況來說,本身是前端,其實,學 nodejs 或 php 都不錯啦 我個人是偏好 php > nodejs 一點,這樣 以上,簡單分享,希望對類似狀況的朋友有幫助!