我自 2019 年以來一直是 Web 開發人員。我使用 React.js 和基於 React 的框架，如 Gatsby、Next、Remix、Astro 和 Hydrogen。我從來沒有對這些工具感到完全滿意，但是，作為一個深入 JS 生態系統的初學者，我從同行那裡聽到的都是這樣的話：「這就是方式，任何其他程式語言要么慢，要么老」。  結果，我習慣了巨大的複雜性：多個獨立的儲存庫、數千個函式庫和框架來實現簡單的事情、GraphQL、微服務、無伺服器、靜態網站產生、增量靜態再生、部分水化、 redux 、redux-thunk、babel、webpack、react 伺服器元件、伺服器操作等。這個清單還可以再持續 10 分鐘。 直到有一天我說**受夠了！** 讓我們來看看我慢慢發瘋的完整時間線。這需要一段時間，在閱讀長篇文章之前，請隨意煮點咖啡！ --- ## 倦怠的時間表 ### [Gatsby.js](https://www.gatsbyjs.com/) 我記得完成我的訓練營並想：“我終於能夠建立我的作品集了！”，所以我做到了。只有一個小問題，我想在 Google 上建立索引，但是使用舊的「create-react-app」使這項任務幾乎不可能完成。很快我了解了 SEO 和 React 的水合循環，這讓我找到了這個問題的「解決方案」：Gatsby.js。靜態網站產生的想法對當時的我來說簡直是革命性的，畢竟沒有什麼比預先渲染 HTML 檔案更快了，對吧？ 我決定透過閱讀文件來學習這個新框架，讓我告訴你，這**不是**一次有趣的體驗。我以前從未聽說過 GraphQL，顯然，您需要它來產生所有靜態檔案（到底是什麼？？？）。我問我的一些網友，很難學習這些過度設計的廢話是否正常，他們回答說「技能問題，再努力一點！」。於是我更加努力，終於學會了之後，我把我的個人網站移植到了Gatsby上。  我的大部分頁面都成功在 Google 上建立了索引，幾個月來，我對結果非常滿意。然後另一個問題出現了：我的**很多**開發者朋友開始說“Gatsby 死了！建立 Next 是為了簡化靜態站點生成並提供伺服器端渲染”。 ### [Next.js](https://nextjs.org/) 我快速瀏覽了 Next 文件並**立即**愛上了它。我能夠在沒有 GraphQL 的情況下用三分之一的程式碼做與 Gatsby 相同的事情！我再次將我的作品集移植到另一個框架：Next。 這次我確實有一次美好的經驗。部署到 Vercel 輕而易舉，「getStaticProps」和「getServerSideProps」功能很簡單，但功能非常強大，我可以選擇每個頁面的渲染樣式，整體來說非常靈活。 不幸的是，我透過慘痛的教訓學到了一些東西：在 JavaScript 生態系統中，所有美好的事情都會結束。 ### [混音](https://remix.run/) 我清楚記得 Remix 發佈時的情景。多名科技影響者開始發布有關它的內容（一如既往）。然而，當時我在主頁上看到它不支援靜態網站生成，只支援伺服器端渲染，所以我想「等一下，這些年來投資於 [JAMstack](https://jamstack.org/) 都被扔在這裡了嗎？不可能，這個框架不會長久」。然而，令我驚訝的是，Remix 不僅生存了下來，而且還被 Shopify 收購 https://shopify.engineering/remix-joins-shopify ，並成為 Next 的重要競爭對手。 幾個月過去了，我決定嘗試看看。我再一次感到驚訝，Remix 的主要座右銘是使用 Web 基礎知識，而不是像 Next 這樣過於複雜的快取系統。因此，在Remix 中編碼時，我腦中需要的思維模型要簡單10 倍：沒有全域狀態管理器，只需使用URL，更少的客戶端狀態，將所有邏輯移至伺服器，並使用cookie，無需使用完整堆疊中間的 REST API 非常簡單，只需將資料庫查詢移至「loader」函數即可。 ### 離開矩陣  然後，突然間，真相呈現在我面前，我服下了紅色藥丸。我的腦海中開始浮現出多個問題：Remix 不就像所有其他「古老而無聊」的框架（如 Rails、Laravel 和 Django）一樣嗎？幾十年來，我們一直在使用伺服器端渲染進行全端 Web 開發，但 JavaScript 黑手黨集體認為這種方法是垃圾，將所有內容移至客戶端才是未來。難道同一個黑手黨認為 Rails 一直都是對的嗎？用 JS 框架做所有那些過度設計的怪物不是正確的舉動嗎？我開始質疑一切。這種「新」的 Web 開發方式更加簡單、快速。 ### 我已經完成了 Next 和 Vercel 我透過 [Next.js 應用程式路由器](https://nextjs.org/docs/app) 達到了臨界點。以下是 Vercel 向 Next 推送的所有錯誤的完整清單： - 曾經簡單的：「getStaticProps」和「getServerSideProps」函數現在變得複雜而麻煩。目前，沒有特定的位置來新增 API 呼叫或資料庫查詢，您可以將它們寫入任何您想要的位置！在多年前使用 PHP 犯了同樣的錯誤之後，我們開始再次將業務邏輯與 UI 混合。難道前端開發者不吸取過去的教訓嗎？如果我刪除按鈕會發生什麼事？這是否會破壞我的使用者身份驗證流程，因為資料庫呼叫位於其中？您的前端應該 100% 可廢棄且可更換。你相對於競爭對手的競爭優勢在於業務邏輯，它應該與 UI 層完全隔離。  - 接下來是伺服器優先。這聽起來沒那麼糟吧？畢竟，這解決了 SEO 問題並立即向用戶展示新鮮內容。問題在於，大多數現有的 Next 程式碼庫都依賴客戶端程式庫，例如樣式元件和一些全域狀態管理器。這是什麼意思？隨著此類重大變化的不斷發生，您的應用程式將在幾週而不是幾年內變成遺留軟體。更多的時間花在保持所有依賴項最新上，而不是做重要的事情：發布功能。 - Vercel 從 Meta 聘請了多名 React 核心團隊成員。這帶來了嚴重的利益衝突，因為這些工程師現在（據稱）正在發布有利於 Next 的功能，而不是優先考慮那些可以幫助所有基於 React 的框架（如 Remix）的功能。  我再也受不了了。我對自己說：你知道嗎？我厭倦了一遍又一遍地重新學習相同的框架，我完全不同意這種新的範式。 毫不奇怪，其他內容創作者也經歷了類似的情況： https://youtu.be/zkCBSz353fc?si=z3-FDVgcB3xfp06h https://youtu.be/Zt8mO_Aqzw8?si=10fy1d-ZoB7t3Uc_ --- ## 啟蒙之路 我非常累。在厭倦了所有的 React 工具後，我開始了尋找更簡單的 Web 框架的旅程。以下是我一直在尋找的先決條件： - 含電池 - 約定優於配置 - 良好的開發體驗 - 現代化且高性能的前端 我的第一個反應是查看 [Stack Overflow Survey 2023](https://survey.stackoverflow.co/2023/#section-most-popular-technologies-web-frameworks-and-technologies) 中的頂級框架。我立即從清單中刪除了所有與 JS、C# 和 Java 相關的內容。我從來沒有興趣學習後兩個，它們看起來醜陋且冗長。所以剩下的選項是：Laravel (PHP)、Django (Python)、Rails (Ruby) 和 Phoenix (Elixir)。 Python 是我在網路工程學位期間使用的語言，我獲得了非常愉快的體驗。 Django 似乎遵循約定優於配置的理念，但最終讓我放棄它的是沒有一個好的內建工具來在前端工作。論壇上的大多數人都說他們使用[HTMX](https://htmx.org/) 和[Alpine](https://alpinejs.dev/)，但是，兩者都是您需要安裝的外部依賴項。 放棄Laravel 是非常困難的，因為它具有驚人的成本效益，有數百個官方軟體包可以處理新創公司可能需要的幾乎所有內容，例如託管、身份驗證、條紋支付等。對於前端，他們創造了[慣性。Node.js](https://inertiajs.com/)，這是一種非常簡單而優雅的方式，可以在前端使用 React 的同時保持 Laravel 的高生產力和強大功能。百分之百誠實地說，我沒有選擇 Laravel 的唯一原因是 PHP 的語法，它看起來很難看，到處都是一堆 `$` 和 `->`。 ### Ruby on Rails Ruby on Rails 無需介紹。它是 Web 開發框架的元年，其革命性的「15 分鐘建立部落格」至今仍令人印象深刻。在我開始抱怨我發現的所有問題之前，讓我們先從好的方面開始。 與 Python 類似，Ruby 是一種可以向非技術人員展示的語言，他們會理解該軟體想要做什麼。它是**迄今為止**我見過的最容易閱讀和最美麗的語言。我很快就意識到，[編寫視覺上令人愉悅的程式碼](https://world.hey.com/dhh/a-writer-s-ruby-2050b634) 是Rails 團隊的首要任務，這對我來說來說是新的。 更不用說 Rails 幾乎發明了「包含電池」和「約定優於配置」的哲學，所以這不會是一個問題。在一份文件中，我提供了任何類型的 Web 應用程式所需的一切。 在前端，有 [Hotwire](https://hotwired.dev/)，這是一種非常簡單且輕量級的方法，可以實現 SPA 框架提供的所有 UX 改進。我一直很好奇測試這個庫的極限，它看起來非常有前途。 好吧，Rails 在紙面上滿足了我想要的框架的所有先決條件。我們來試試吧！我在本地測試的第一件事是“railsscaffold”命令。我立即感到震驚。一個指令就能產生 CRUD 所需的一切？決不！  在 Node + React 領域，要實現相同的目標，我需要手動編寫所有程式碼（這裡沒有生成器）並安裝一堆程式庫，例如：Vite、prisma、express、react router、redux、redux-thunk 、 vitest、cypress 、react 測試庫、zod、typescript、eslint、prettier、1000 個不同的插件，甚至可能還有GraphQL 或tRPC。基本上就是一個已經有 900 個依賴項的 package.json。 在“railsscaffold”最初的震驚之後，當我從控制器打開程式碼時，我再次震驚了： ``` class ArticlesController < ApplicationController def index @articles = Article.all end def show @article = Article.find(params[:id]) end def new @article = Article.new end def create @article = Article.new(article_params) if @article.save redirect_to @article else render :new, status: :unprocessable_entity end end def edit @article = Article.find(params[:id]) end def update @article = Article.find(params[:id]) if @article.update(article_params) redirect_to @article else render :edit, status: :unprocessable_entity end end def destroy @article = Article.find(params[:id]) @article.destroy redirect_to root_path, status: :see_other end private def article_params params.require(:article).permit(:title, :body) end end ``` 這是所有後端程式碼嗎？只需幾行？這不可能！這非常簡單，看起來就像一個「低程式碼」工具。它簡單、優雅、可讀性極強，這是我們在 JS 領域很少見的。 好吧，好吧，你現在一定在想：「這個來自網路的瘋狂 React 開發者說他最終使用了 Elixir，所以 ruby 一定有問題！」。你是對的，我的匿名朋友，有些事情讓我很惱火，讓我們談談。 首先，我們需要解決房間裡的大象：從 React + Typescript 轉向動態類型語言並不容易。從我開始編寫程式碼的那一刻起，我的 VScode 上就沒有出現智慧感知或充滿程式碼建議的下拉式選單，我感到盲目和迷失。這是一種可怕的感覺，我可能會在函數名稱上輸入錯誤，直到網站投入使用時才意識到！我知道我們可以編寫測試，但這是我希望在 IDE 上立即辨識的錯誤類型，而不是在測試或部署期間辨識。 另一件我以為我會喜歡但最終討厭它的事情是：太多的魔法。在 Typescript 程式碼庫中，我可以點擊任何類別或函數的頂部，前往原始程式碼並查看其實作方式。在 Rails 上，我到底在哪裡進行驗證（例如）？我是否在控制器內建立私有函數？有專門的資料夾嗎？不，正確的位置是在模型內部。為什麼？因為這就是它的工作原理，所以您要么採用該約定，要么很難編寫 Ruby 程式碼。我根本無法對一切在幕後如何運作產生“直覺”，我必須盲目地相信維護者在組織一切方面做得很好。 為了解決我的挫折感，我開始寫前端程式碼。如何建立元件？ [部分](https://guides.rubyonrails.org/layouts_and_rendering.html#using-partials)。如何定義該元件的 prop 類型？沒有辦法做到這一點，您需要打開它並直觀地查找其中的所有變數。做一些互動怎麼樣？建立國家？嗯，有帶有 [Stimulus](https://stimulus.hotwired.dev/) 的 Hotwire，但是正如您所看到的，您需要手動建立“重新渲染”功能，它沒有找到一種方法像React 這樣改變狀態後自動重新渲染頁面。 ``` // src/controllers/slideshow_controller.js import { Controller } from "@hotwired/stimulus" export default class extends Controller { static targets = [ "slide" ] initialize() { this.index = 0 this.showCurrentSlide() } next() { this.index++ this.showCurrentSlide() } previous() { this.index-- this.showCurrentSlide() } showCurrentSlide() { this.slideTargets.forEach((element, index) => { element.hidden = index !== this.index }) } } ``` 我再一次感到沮喪。我非常接近找到完美的框架！如果 Rails 失敗，我想嘗試的下一個框架是什麼？靈丹妙藥。 ### 長生不老藥和鳳凰 我必須說實話，我已經沒有耐心了。我嘗試了多種不同的生態系統，我幾乎確信要堅持使用 Ruby on Rails，並放棄對完美的追求。直到我的 YouTube 推薦部分出現了一個影片： https://www.youtube.com/live/bfrzGXM-Z88?si=Xsa7yCKeVSY5R3sT 堅持，稍等！在這裡我們可以看到一位 React 開發人員說了很多關於函數式程式設計、Elixir 和 Phoenix Live View 的好話。也許我應該嘗試一下！ 我做的第一件事就是打開Elixir 和Phoenix 的文件，我真的很喜歡這樣一個事實：所有包都使用[Hex Docs](https://hexdocs.pm/) 以相同的方式進行記錄，您只需要取得習慣於單一介面以學習新事物。 另一個好處是，您只需閱讀文件即可真正學習 Elixir，無需昂貴的課程！在其他所有生態系統中，我必須透過付費課程學習語言，然後透過閱讀文件來學習框架。 然後是時候開始編寫程式碼了。很快我就明白函數式程式設計與 OOP 有很大不同。我們來做一個小小的比較： ``` // JS const obj = {name: "daniel"} obj.age = 25 // result: obj = {name: "daniel", age: 25} ``` ``` # Elixir obj = %{name: "daniel"} obj = Map.put(obj, :age, 25) # result: obj = %{name: "daniel", age: 25} ``` 或者您可以使用管道運算子透過更簡單的語法實現相同的效果： ``` # Elixir with pipe operator obj = %{name: "daniel"} |> Map.put(:age, 25) # result: obj = %{name: "daniel", age: 25} ``` 最初，您可能會發現它的可讀性較差且更複雜，但我保證隨著時間的推移它會變得有意義！嗯，至少對我來說是這樣。身為 React 開發人員，我已經習慣了到處都可以看到多個函數，甚至前端元件也是函數！更不用說建立類別有時被 JavaScript 黑手黨視為一種程式碼味道。我的大腦已經針對這種新範式進行了“塑造”，這對我來說很自然。自從我在大學獲得網路工程學位以來，我上過幾門關於物件導向程式設計的課程，但它從來沒有「受歡迎」。我無法將複雜的問題建模為類別和物件。隨著時間的推移，使用多個函數來「改變」一個變數是我在腦海中建模的方式。 主要框架怎麼樣？包含鳳凰電池嗎？約定優於配置？ **是的！** 老實說，生態系統與 Rails 不在同一水平，但已經達到了 95%。除非您需要非常具體的功能，Phoenix 都能滿足您的需求。 我幾乎被 Elixir 迷住了，我的清單中缺少兩件事：良好的開發人員體驗和現代/高效能的前端程式碼。 José Valim 宣布他正在嘗試為該語言加入類型，但 Elixir 目前還沒有這些類型，所以我很擔心。如何在沒有類型的情況下獲得智能感知和自動完成？很快我發現這些功能不一定相關。在 VScode 上安裝 [ElixirLS 擴充功能](https://marketplace.visualstudio.com/items?itemName=JakeBecker.elixir-ls) 後，我感到很驚訝。可以在隨機資料夾的隨機模組內定義函數，將其導入其他位置，並取得它的智慧感知和文件！我從靜態類型語言中獲得了這些好處，而無需編寫類型的麻煩，簡直太棒了！ https://elixir-lang.org/blog/2022/10/05/my-future-with-elixir-set-theoretic-types/ 我對前端的最後一個擔憂是由 Phoenix [Live View](https://hexdocs.pm/phoenix_live_view/welcome.html) 解決的。在程式碼方面，這正是文件主頁中讓我信服的部分：  您可以為每個元件定義“props”，如果類型不匹配，您的 IDE 中會出現錯誤，就像 React 一樣！感人的！ 使用者體驗怎麼樣？每當使用者點擊連結時是否會載入整個頁面？一定不行！即時視圖與客戶端建立 WebSocket 連接，然後每次頁面轉換只是透過 Websocket 進行內容交換，不會發出新的 HTTP 請求。此外，所有狀態都在伺服器端進行管理，這意味著 Trello 等豐富的用戶體驗過去由於加載過多的 JavaScript 而在客戶端非常卡頓，現在變得非常快！ Elixir 處理所有複雜的狀態邏輯並將頁面的更新部分傳送到前端。看看這裡的完整解釋： https://youtu.be/wrmVk2czqMg?si=ZoWAlPjQC-svmV3Y 由於我們使用 WebSocket 來建立 UI，因此建立像 Twitter 這樣的「即時」應用程式只需要幾行程式碼！ https://youtu.be/MZvmYaFkNJI?si=gAow6oIjgf8_OTkg ## 結論 可以肯定地說，「完美的技術堆疊」並不存在。解決所有問題的靈丹妙藥是我們在腦中創造的幻覺，以不斷尋找和建構最優化的工具。 然而，在個人層面上，完美的堆疊確實存在。因為每個開發人員都有偏好，您可以輕鬆找到適合您標準的工具。如果你有和我類似的旅程，完美的可能就是長生不老藥和鳳凰！所以試試看吧，也許你會像我現在一樣喜歡它。 如果您讀到了這篇文章的結尾，那您就太棒了！非常感謝您抽出寶貴的時間，希望我能為您的職業生涯帶來一些價值。  --- 原文出處：https://dev.to/danielbergholz/from-nextjs-to-rails-then-elixir-my-journey-through-reactjs-burnout-h8d
**簡介** 您選擇的 Web 應用程式框架並不重要。嗯，這很重要，只是不像別人希望你相信的那麼重要。 2024 年存在如此多的庫和框架，並且最好的庫和框架[仍在激烈爭論](https://joshcollinsworth.com/blog/self-fulfilling-prophecy-of-react)這一事實證明了我的觀點。這是網頁開發人員最大的「第一世界問題」——一個實際上並不是問題的問題。在馬斯洛的開發者需求層次結構中，它絕對接近頂部（好吧，這是我編的😅）  例如，根據 [StateOfJS](https://2022.stateofjs.com/en-US/libraries/front-end-frameworks/) 2022 年調查（我們仍在等待 2023 年結果），2018年留存率較高的前端框架有5個； 2022 年有 11 個。這在 4 年內增長了 120%，這甚至沒有考慮到像 NextJS、SvelteKit 或Astro ！  總體而言，這些都是該領域的巨大發展。它們提高了開發人員速度、捆綁包大小、效能和開發人員體驗等。但它們也讓開發人員和團隊在嘗試決定在下一個專案中使用哪一個時很難做出決定。對於初學者來說更糟糕，這可能是為什麼他們只選擇 React 這個最「主流」的解決方案。 我認為這一切都沒關係，因為最終你選擇哪一個並不重要。 **真正歸根結底，重要的是您選擇的框架**： - 穩定（足夠） - 讓你快速移動 - 讓您達到最終目標 為什麼？因為它們中的大多數都是圍繞著相同的概念建置的，已經證明自己有能力大規模執行，並且擁有可供您參與和學習的社區。 React 可能是職位描述中最突出的一個，但如果你正在尋找一個新角色並且只有 Vue 或 Angular 經驗，我無法想像你會花費一周以上的時間來建置一個副專案做出反應，向未來的雇主展示您的能力。 另一方面，如果您是初學者或初級開發人員，一旦您掌握了 HTML、CSS 和 JS 的基礎知識，學習什麼框架並不重要。我個人開始使用 PHP 學習後端開發，但後來轉向使用 Angular 進行前端開發。在我隨後的第二個角色中，我使用了React，現在我使用[Wasp](https://wasp-lang.dev)（一個基於React 和Node.js 建置的全棧框架）來開發我的副專案， https://reflectdaily.app/ - [開發人員永遠不會停止學習](https://www.youtube.com/watch?v=gl5HvBpUbt8)，因此嘲笑任何特定框架都是毫無爭議的——除非它真的很糟糕，但沒有人會繼續這樣做無論如何使用它。  所以，最後，使用有效的方法。因為在99.99%的情況下，你對Web框架的選擇並不會決定你專案的命運。 如果您做了一些研究並找到了適合您需求的框架並且您喜歡使用它 - **使用它**。確實沒有充分的理由不這麼做。 ## 支持我們！ 🙏⭐️  如果您喜歡這篇文章，[考慮在 Github 上給我們一顆星](https://kdta.io/github-wasp-lang-wasp_18)！我們在 Wasp 所做的一切都是開源的，您的支援幫助我們使 Web 開發變得更容易，並激勵我們撰寫更多這樣的文章。  --- 原文出處：https://dev.to/wasp/the-best-web-framework-doesnt-exist-2aom
看更多文章： 1. [使用 gRPC 和微服務建立可擴展的通知系統](https://dev.to/suprsend/building-a-scalable-notification-service-with-grpc-and-microservices-l6d) 2. [在 React 網站中新增通知來源](https://dev.to/suprsend/adding-a-notification-feed-in-react-websites-4oa0) 4. [2023 年現代應用通知基礎設施完整指南](https://dev.to/suprsend/a-complete-guide-on-notification-infrastruct-for-modern-applications-in-2023-13b9) --- 應用程式通常可以分為兩種類型的效能瓶頸： 1. **I/O 限制：** 這些應用程式將大部分時間花在處理輸入和輸出上。 2. **CPU 限制：** 這些應用程式將大部分時間花在運算任務上。 現在，這些分類如何轉化為前端應用程式的上下文，特別是 React 應用程式？ **React 中的 I/O 效能挑戰** 當涉及到 React 應用程式時，經常會出現 I/O 效能方面的問題，主要與非同步 HTTP 呼叫相關。無效地管理這些網路請求可能會導致應用程式速度減慢。雖然這篇文章主要關注 CPU 效能，但有必要簡要介紹一下可以找到 I/O 限制問題解決方案的關鍵領域： - 盡可能實施延遲載入。 - 在初始載入資產和後端請求時請務必小心。 - 減少載入高度靜態元素的頻率（例如，選擇選項、配置）。 - 去抖特定請求的次數。 - 使用 Promise.all 等技術盡可能並行化請求。 - 透過優化資料庫存取等措施來提高關鍵後端端點的效率。 **React 中的 CPU 效能挑戰** 這篇文章的主旨是解決 React 中的 CPU 效能挑戰。在深入研究細節之前，讓我們先對效能建立一個具體的定義： - 瀏覽器應用程式主要作為單執行緒程式執行。 - 腳本任務，例如 JavaScript 執行、DOM 渲染和事件處理，都發生在同一個執行緒。 - 緩慢的 JavaScript 模組可能會阻塞主執行緒。 - 如果主執行緒被阻塞，使用者介面將變得無回應，導致每秒幀數 (fps) 下降。 - 響應式 UI 的目標是至少 30 fps，理想情況下達到 60 fps，這意味著每幀的計算時間應在 30 毫秒或更短的時間內。 在 React 的背景下，這個問題變得至關重要。當觸發 React 元件更新時，整個子樹必須在 30 毫秒內渲染完畢。對於複雜而冗長的元件結構（例如表、樹和列表），這變得尤其具有挑戰性，可能需要大規模重新渲染。 **反應渲染和提交階段** 從高層次來看，React 分為兩個不同的階段： **渲染階段：** - 當元件更新時啟動，由 props 或 hooks 的變更觸發。 - React 遍歷元件子樹，渲染每個子樹並計算虛擬 DOM (VDOM) 子樹。 - 只有受更新影響的「髒」子樹需要重新計算；更新元件的父元件可能不需要重新渲染。 - 此階段的效率與每個子元件的大小和計算成本成正比。 - React.memo 可用於提供更有效率渲染流程的提示。 **提交階段：** - 渲染階段產生整個 UI 的新虛擬 DOM。 - 在提交階段，React 將新樹與前一棵樹進行比較（VDOM 比較）。 - React 計算反映新 VDOM 樹所需的最小 DOM 突變。 - 套用 DOM 突變，更新 UI。 - 預設情況下，此階段本質上是高效的。 - 整個過程必須在 30 或 16 毫秒內完成（分別針對 30 fps 和 60 fps），UI 才會被視為回應。工作負載與應用程式的大小成正比。 後續探索將聚焦在提升Render階段的效率。在深入研究優化技術之前，了解如何測量和辨識應用程式中的緩慢元件至關重要。 **測量** 我經常依賴的工具包括： 1. **Chrome 開發工具的效能標籤** 2. **React Dev Tool 的效能標籤** **Chrome 開發工具的效能標籤** 該工具作為適用於任何瀏覽器應用程式的綜合資源而脫穎而出。它提供對每秒幀數的洞察、捕獲堆疊追蹤、辨識程式碼的慢速或熱點部分等等。主要使用者介面由火焰圖表示。 若要深入了解套用於 React 的 Chrome 效能選項卡，請參閱此[文件](https://developers.google.com/web/tools/chrome-devtools/evaluate-performance)。 **React 開發工具的效能標籤** 若要利用此工具，您需要在瀏覽器中安裝 React Dev Tool 擴充功能。它專門針對 React 客製化了 Chrome 開發工具效能標籤中的資訊。透過火焰圖，您可以觀察不同的提交階段以及在對應渲染階段執行的 JavaScript 程式碼。 該工具有助於輕鬆確定： - 當元件進行重新渲染時。 - 哪些道具改變了。 - 哪些鉤子發生了變化，包括狀態、上下文等等。有關更多詳細訊息，請參閱[介紹性帖子](https://reactjs.org/blog/2018/09/10/introducing-the-react-profiler.html)。 **測量方法** 這是我在評估前端應用程式時更喜歡的方法： 1. **確定問題：** - 找出導致 UI 回應問題的頁面互動。 2. **建立一個假設：** - （可選）產生有關問題的潛在位置的想法。 3. **測量：** - 透過測量每秒幀數 (fps) 等基本指標來驗證問題。 4. **測量（第二部分）：** - 辨識有問題的程式碼部分； （可選）驗證您的假設。 5. **建立解決方案：** - 根據收集到的見解實施解決方案。 6. **測量解決方案：** - 透過檢查關鍵指標來驗證實施的解決方案是否解決或緩解了問題。 在沒有適當衡量的情況下進行最佳化會使努力實際上變得無效。雖然有些問題可能很明顯，但大多數問題都需要徹底的測量，從而構成性能增強過程的基石。 此外，測量可讓您向上傳達成果，向使用者、利害關係人和您的領導層通報應用程式特定領域內實現的效能改進（以百分比增益表示）。 **React 應用程式中 CPU 限制問題的通用解決方案** 現在有了測量結果並了解了問題領域，讓我們深入研究潛在的解決方案。優化 React 效能圍繞著改進渲染的元件和渲染的元件。 許多效能問題也源自於反模式。消除這些反模式（例如避免渲染方法中的內聯函數定義）有助於提高渲染時間。事實上，解決不良模式可以降低複雜性並同時提高效能。 **🤔 改進元件渲染** 辨識 React 應用程式中的緩慢元件通常指的是難以渲染或單一頁面上實例數量過多的特定元件。多種原因可能導致他們行動遲緩： - 元件內的阻塞計算。 - 渲染大型元件樹。 - 使用昂貴或低效率的函式庫。 大多數這些問題都歸結為提高元件渲染的速度。有時，關鍵元件不能依賴過於複雜的函式庫，需要回歸基本原則並實施更簡單的替代方案。 例如，我在複雜表格中每行的多個單元格中過度使用 Formik 時遇到了此類挑戰。雖然提高單一元件的效率還有很長的路要走，但注意力最終必須轉移到正在渲染的元件上。 **🧙 改進哪些元件渲染** 這方面提供了兩大類改進： 1. **虛擬化：** - 僅渲染視窗中可見的元件。例如，僅呈現使用者可以看到的表格行或清單專案。事實證明，這種方法對於複雜的 UI 是有益的，雖然可以在不解決「內容」步驟的情況下應用它，但建議這樣做。現代函式庫通常為虛擬化表和清單提供強大的支持，例如“react-virtualized”。虛擬化減少了 React 需要在給定幀中渲染的元件數量。 2. **道具優化：** - React 的目標是使元件類似於純函數，但可能會嘗試渲染不必要的次數。 **反應.備忘錄：** - React 中的大多陣列件都可以被記憶，確保使用相同的 props，元件返回相同的樹（儘管鉤子、狀態和上下文仍然受到尊重）。如果它們的 props 保持不變，則利用 `React.memo` 通知 React 跳過重新渲染這些已記憶的元件。 ``` import React from 'react'; const MyComponent = React.memo((props) => { // Component logic here }); export default MyComponent; ``` **假道具更改：useCallback：** - 解決虛假道具更改問題涉及道具內容保持不變但引用發生變化的情況。一個典型的例子是事件處理程序。 ``` import React, { useCallback } from 'react'; const MyComponent = () => { const onChange = useCallback((e) => console.log(e), []); return <input onChange={onChange} />; }; export default MyComponent; ``` **假道具更改：useMemo：** - 在將複雜資料結構作為 props 傳遞之前，在沒有適當記憶的情況下建立複雜的資料結構時，也會出現類似的挑戰。利用「useMemo」可確保僅在依賴項發生變更時才重新計算行，從而提高效率。 ``` import React, { useMemo } from 'react'; const MyComponent = ({ data, deps }) => { const rows = useMemo(() => data.filter(bySearchCriteria).sort(bySortOrder), [deps]); return <Table data={rows} />; }; export default MyComponent; ``` 雖然您可以靈活地自訂「React.memo」如何比較目前與先前的道具，但保持快速運算至關重要，因為它是渲染階段不可或缺的一部分。避免在每次渲染期間過於複雜的深度比較。 ## 現在看起來怎麼樣？ ### 道具已更改 它在 React 開發工具中的樣子：  他們真的嗎？它們是假的道具更改嗎？使用`useCallback`和`useMemo`。 ### 父渲染 它在 React 開發工具中的樣子：  使用“React.memo”來記住您的純元件。 ### 掛鉤已更改（狀態、上下文） 它在 React 開發工具中的樣子：  這裡沒有什麼太明顯的事情要做。嘗試驗證更改的鉤子是否有意義。也許一個糟糕的上下文提供者正在以與假道具更改可能出現的方式相同的方式偽造更改。 --- > 與此類似，我個人在 Slack 上經營著一個由開發人員主導的社群。我們在其中討論這些類型的實現、整合、一些真相炸彈、奇怪的聊天、虛擬會議以及一切有助於開發人員保持理智的事情；）畢竟，太多的知識也可能是危險的。 > 我邀請您加入我們的免費社區，參與討論，並分享您的驚人經驗和專業知識。您可以填寫此表格，Slack 邀請將在幾天後收到您的電子郵件。我們擁有來自一些偉大公司（Atlassian、Scaler、Cisco、IBM 等）的出色人員，您一定不想錯過與他們的互動。 [邀請表](https://forms.gle/VzA3ST8tCFrxt39U9) --- 您可能想要查看整合通知基礎架構的無縫方式。 https://github.com/suprsend/suprsend-go --- 原文出處：https://dev.to/nikl/react-is-slow-what-to-do-now-369g
我不是第一個這麼說的人，但我還是要說，2023 年對 JavaScript 框架來說是個不平凡的一年。我們一直在關注的新技術最終顯示出它們可以交付，而舊框架正在復興，如果您不注意，您可能會錯過一個相當重大的轉變。 我預計 2024 年將繼續出現更大的全面變化。這次不是新技術，而是精細化。既然基礎已經存在，那麼還有很多事情要做。 -------------------- ## 伺服器優先 如果讓我為過去幾年選擇一個主題，那就是這個。這一直是爭論的焦點，但不可否認。幾年前，每個人都在談論漸進式 Web 應用程式和離線應用程式。但那個對話框幾乎消失了。 相反，我們會受到 HTMX 的敏銳智慧的影響，解釋為什麼 JavaScript 只是一個錯誤。 Astro 毫無歉意地接管了內容網站的開發。甚至 React Core 團隊也接受了 React Server Components 的伺服器簡單性，Dan Abramov 的演講令人信服地表達了這一點，該演講探討瞭如果 React 始終是伺服器優先會怎樣。 https://www.youtube.com/watch?v=zMf_xeGPn6s 那麼我們的單頁應用程式親愛的在這麼短的時間內發生了什麼？它是否仍然存在，還是我們生活在多頁面應用程式和僅伺服器渲染 HTML 的時代？ ------------------ ## 回顧 2023 年 去年，我寫了一篇非常類似的文章，探討了新的一年 JavaScript 框架的趨勢，我認為這是一個很好的起點。 https://dev.to/this-is-learning/javascript-frameworks-heading-into-2023-nln 該文章中確定的三大技術趨勢成為去年討論的重要組成部分。 ### 訊號無所不在 從 2022 年底開始，Preact 和 Qwik 緊跟著 SolidJS 和 Vue 的腳步，採用這些 Reactive 原語，這種勢頭只會持續到 2023 年。 二月份，Angular 團隊宣布採用。這一訊息震驚了社群媒體。不僅。這是 Angular 的存在發生非常顯著變化的幾個因素之一。有人甚至稱之為「角度復興」。這是過去幾年我們第一次看到 React 團隊加入這場爭論，因為真正被問到的問題是「訊號什麼時候出現在 React 中？」。 我在下面的文章中寫了這個問題的更長的答案（以及在評論中與丹·阿布拉莫夫的討論）。 https://dev.to/this-is-learning/react-vs-signals-10-years-later-3k71 但簡短的回答是，訊號（至少作為 API）並不是他們感興趣的東西，而他們備受期待的「忘記」編譯器將扮演類似的角色。 但訊號傳播並沒有就此結束。 Lit 是 Google 的 Web 元件框架，推出了[Lit 3，具有第一方訊號支援](https://lit.dev/blog/2023-10-10-lit-3.0/#preact-signals-integration)。 Rich Harris 公佈了 Svelte 的未來，[他們新的基於訊號的「Runes」](https://svelte.dev/blog/runes)，將成為即將推出的 Svelte 5 中反應性的主要來源。 2023 年結束訊號是大多數前端 JavaScript 框架的主要部分。 ### 混合路由  去年，基於伺服器的路由得到了加強並發揮了新的作用。從 2022 年底開始，到今年，我們看到人們已經習慣了這種範式轉變，例如 React Server Components 和 Astro 的 View Transition API 整合。 前提是初始頁面載入後的伺服器渲染不應阻止客戶端導航，且客戶端導航不應意味著我們需要發送所有 JavaScript 來渲染可以靜態伺服器渲染的頁面部分。 值得注意的是，並非所有解決方案都是等效的，而且這個領域仍在建設中。我們正在進入一個新的空間，它不完全是單頁應用程式，也不完全是傳統的多頁面網站。需要進行新的權衡和新的理解。我們還沒有完成對陷阱的探索。 ### 邊緣網路：最後的前沿  邊緣功能似乎是那些明顯的勝利之一。將伺服器移至更靠近最終用戶的位置，可以大幅減少延遲。使用更輕的執行時間可以大幅減少冷啟動時間。我們終於可以提供我們一直夢想的網路體驗。以靜態的速度實現動態。 好吧，如果有什麼不同的話，2023 年是成長的陣痛和邊緣的一年。我們開始非常熱情。畢竟，Cloudflare 發布了邊緣資料庫，我們最喜歡的所有提供者都開始提供邊緣功能，而我們最喜歡的框架正在加入開箱即用的支援。提供者成立了一個 WinterCG 委員會來討論平台標準化問題。未來就在這裡。 我們最終認識到，即使在這些邊緣功能中，某些 Node API 也是必不可少的。您可以感謝或討厭 Next 和 Vercel 將“AsyncLocalStorage”推送到每個執行時，但我們需要它。 我們也意識到邊緣資料庫永遠無法滿足所有應用程式。即使使用串流媒體，伺服器瀑布也是真實且有影響力的。是的，即使使用 React Server 元件也是如此。 但這確實實現了我去年提出的目標，透過分散式部署進行整體創作。我們看到伺服器函數（`server$`、`use server`），甚至像 Worker Functions 這樣的變體在今年年初出現，表明我們可以分發我們部署 API 的方式，並被 Solid、Qwik 和 Next 採用。 到年底 [Next 14 發布了新的實驗性部分預渲染](https://nextjs.org/blog/next-14)，它允許單一請求從邊緣提供靜態內容，同時代理到伺服器-less 靠近資料庫的函數全部被串流傳輸，以提供類似Edge 的體驗，而無需在那裡部署整個應用程式。看到一些獨創性提供了兩全其美的解決方案真是太棒了。 ---------------- ## 展望 2024 年 ### 訊號年 我知道我已經在一篇文章中充分討論了信號，但真正的回報還沒有發生。我們在 JavaScript 中使用細粒度的類似 Signal 的原語已有 15 年了，那麼為什麼現在呢？ 這不僅僅是關於擁有它們，而是關於你如何使用它們。 Vue 多年來一直在隱藏這些原語，React 和 MobX 也是如此，但這幾乎沒有觸及事情的發展方向。那就是細粒度渲染。 SolidJS 所普及的內容，現在以 Vue Vapor 的形式進入 Vue，以及 Svelte 5 中的 Svelte。這些只是已經宣布的內容。 我希望其他採用訊號的人能夠更自然地將它們融入框架中，以便更好地從中受益。 這個領域的潛力令人興奮，致力於將 Signals 引入瀏覽器的 TC-39 提案的小組包括來自每個主要 JavaScript 框架的代表，而這個小組並不總是與標準密切相關。 ### 基礎設施主導的發展 既然伺服器端渲染框架已經打了一針強心劑，那麼下一個合乎邏輯的地方就是繼續考慮最大限度地利用這項新功能為我們提供的功能。標準的製定很慢，WinterCG 也需要一些時間，但這不會阻止這裡的發展。 為了實現差異化，我預期框架和基礎設施供應商都會面臨壓力，要求他們提供只能在特定平台上運作的獨特功能。雖然 2023 年各個提供者都在推動平等，以提供超出其基本靜態和功能託管的類似功能（例如鍵值存儲 Blob），但我只看到這裡提供獨特價值的競爭正在升溫。 框架在這方面的作用是保持一致的創作體驗和思考模型，同時找到利用呈現給我們的新能力的方法。這與 2000 年代末的瀏覽器戰爭沒有什麼不同，而且未來還會有很多事情發生。 ### 人工智慧  去年從框架的角度談論人工智慧還為時過早。明年也可能如此。但它就在眼前。程式碼遷移和生成工具都是很棒的想法，但它們遇到了我們多年來使用視覺化無程式碼或低程式碼編輯器所遇到的相同問題。人機界麵點仍然至關重要。畢竟，程式碼是有生命的東西。它會隨著時間的推移而增長和維持。 在過去的一年裡，與其他框架作者交談時，我們發現它吸引了我們周圍的人，但還沒有達到明確我們在其中的角色的程度。但這種情況正在改變。 是的，人工智慧正在回答一個永恆的問題：為什麼你的應用程式速度很慢。 對開發人員工具的影響是一回事。但我們也看到我們的框架中內建即時性的潛力越來越大。我也不僅僅指用於持久後端的 Websockets。元框架中的 API 已經從簡單的 JSON 發展到使用 SolidStart、Qwik 和 Next 中的「伺服器功能」完全流式跨網路 JavaScript 執行。不難想像生成技術即時建立使用者介面。 -------------------------- ## 結論  2024 年可能會繼續我們過去幾年看到的成熟趨勢。從 2020-22 年，我們看到了許多新的 JavaScript（和 WASM）框架（Qwik、Million.js、Astro、Next 13、Remix、Hydrogen、SvelteKit、SolidStart、Leptos、Dioxus、HTMX），但這還不是去年的案例。我們已經找到了方法，現在我們需要充分發揮它們的潛力。 我不確定我們是否已經成功地解決了複雜性，這對像 Astro 或 HTMX 這樣的簡化解決方案給予了大力支持。但我仍然充滿希望。 期望每個人都就「單頁應用程式」到底是什麼或何時應該使用擺在我們面前的各種選項達成一致可能有點太過分了，但這些解決方案每天都在變得更有能力實現他們設定的目標出去做。 我們所知道的網頁開發是否會改變已經不再是一個問題。即使方向還不完全明確，革命已經來臨。期望在那裡見到你。 --- 原文出處：https://dev.to/this-is-learning/javascript-frameworks-heading-into-2024-i3l
承接前面幾篇 > 開發人員平台現在需要商家驗證才能取得進階存取權限 https://developers.facebook.com/blog/post/2023/02/01/developer-platform-requiring-business-verification-for-advanced-access/ > 針對今天之後建立的應用程式（在 developers.facebook.com 上建立的應用程式），我們會開始逐步在新應用程式要求進階存取權限時，實施此規定。從 2023 年 5 月 1 日開始（除非需要提前要求此程序），在今天（2023 年 2 月 1 日）之前建立且具有進階存取權限的應用程式，必須連結至已驗證的商家。為了管理初期大量的商家驗證要求，我們將在 2023 年針對我們平台上現有的應用程式逐步實施此規定。從 2023 年 7 月 1 日開始，現有的開發人員將會收到開發人員重要通知，告知其應用程式何時可以進行商家驗證程序；收到通知後，開發人員有至少 30 天的時間可以提交商家驗證要求。屆時應用程式若未連結到已驗證的商家或等待驗證的商家，將會被撤銷進階存取權限。如果您已經有經過驗證的商家，強烈建議您確認所有現有的應用程式都已連結到該商家，以免存取時遭到中斷。另請注意，商家驗證程序完成後，將不再允許存取個別驗證。 所以是進階權限才要公司登記？ --- https://developers.facebook.com/docs/graph-api/overview/access-levels/ > 針對 2021 年 2 月 16 日之前建立的商家和遊戲應用程式，其 email 和 public_profile 權限，以及通過應用程式審查批准的任何權限或功能（若有使用），都會自動獲准進階存取權限。 所以我工程師做 side project，只要 email 跟用戶大頭貼，應該不用登記公司囉？ > 進階存取權限現在需要商家驗證 > 自 2023 年 2 月 1 日起，要求進階存取權限的應用程式「可能」必須連結已驗證的商家。詳情請參閱此部落格文章。 「可能」要？到底要還是不要？ --- https://developers.facebook.com/docs/permissions > App Review is required for all permissions except for email and public_profile if your app needs access to data that you do not own or manage > Business Verification is required for all apps making requests for Advanced Access Only select permissions that your app needs to function as intended. Selecting unneeded permissions is a common reason for rejection during app review 到底在寫什麼？誰看得懂？ 所以我工程師 side project 會通過 app review 但無法拿到 business verification 然後還是會被撤銷「FB 登入」功能？ 如果是我誤會了，那為啥我會收到 FB 緊急停權通知？ > REMINDER: Business verification Urgent > Here’s what a person with full control of your Business Account needs to do for Meme 梗圖倉庫 by 2023年12月24日 to maintain access: > Connect the app to a Business Account, if you haven't already. > Complete business verification for the Business Account. > If business verification isn't completed, this app will lose access data from users (for some apps this means permissions and features will be switched to standard access). > 11月20日 --- 一般權限，是只有ＡＰＰ開發者自己可以登入，那這ＡＰＰ跟本就不能用啊！ 只要做ＦＢ登入功能，就需要進階權限，那到底有沒有包含 email 跟用戶大頭貼？ 寫一大堆文章，怎麼還是不清不楚？ 一堆冗言贅詞、「可能」、「必須」、「進階」、「一般」、反面表達，到底在寫什麼？ 我認了，不能去賭我ＡＰＰ被關掉、用戶無法登入的風險 我直接去登記公司了 大家串接 FB API 要小心，不要跟我一樣，變成傻瓜
大概從 2012 年開始，幾乎大大小小的網站、APP 都會有「FB 登入」功能吧 就是去 FB 後台 註冊 申請一下即可 一堆資工系大學生、工程師業餘 side project 幾乎都玩過 但是相關政策一直在改變 就在今年 2023 改成 一定要有註冊公司 才能使用 https://developers.facebook.com/blog/post/2023/02/01/developer-platform-requiring-business-verification-for-advanced-access/ FB 寫了很多篇 曖昧不明的文章 創造一堆專有名詞 你看半天也看不懂 我講結論：反正就是 會隨機抽查 開始抓 app 只要沒有「政府核准文件」的 app 就會砍掉 FB 登入權限 要政府核准函 或是 有公司名稱＆地址的水電帳單 很硬喔 我研究過了 沒有取巧、迴避的方法 --- 就算你是經營不錯的公司 還是會被這種政策搞到 例如 財報狗 今年有一段時間 無法ＦＢ登入 https://www.facebook.com/statementdog/posts/pfbid0v7sYjy3HLvMaqSWvd11hMt32xQL8Mgi7iNdeZoP7UrYPCo3o9fMNruNgeoaKfQNGl?__cft__[0]=AZXS4AqmqXa1jGrsqKEihimrD8KttxyEbzqcF52n8AAJ0c4JICCpx14TPPPyH4IWB85zhmRZn5BizOXycj_EYAQOj74rHtI262e2fsU2WOvMWzhTnCT3sPxTLTB9igX2tB96p2B5okinh_N-Dss5QBSz&__tn__=%2CO%2CP-R --- 這件事在台灣沒人討論 在國外已經議論紛紛 > Ask HN: Is “sign in with Facebook” dead for indie developers? https://news.ycombinator.com/item?id=37349924 --- 建議 大學生、工程師業餘做 side project，請避免使用「FB 登入」功能 就算要做 也要讓用戶登入之後 規定要輸入密碼，保留密碼的登入方式，社交登入只是方便而已 也就是讓社交登入變成註冊流程的一個環節，而不是直接就註冊完成 不然你網站，某天就不能用了，要去做公司登記 額外成本會變多少呢？我另寫一篇說明 https://codelove.tw/@howtomakeaturn/post/l3jOpa
 在過去的十年裡，我一直是一名全端開發人員，建置了像[gitup](https://gitup.dev/) 這樣的較小專案和像[crosspublic](https://github.com/github-20k/) 這樣的更大專案跨公共）。 多年來，我測試了不同的工具： 1. 提高工作效率 2. bug 更少 3. 少寫程式碼 我整理了一系列庫來幫助您開發我每天使用的優秀 NextJS 東西，並解釋了您可以用它們做什麼。 **讓我們深入了解一下。**  --- # 1. [Trigger.dev](https://github.com/triggerdotdev/trigger.dev) 使用 NextJS，我總是需要幫助來處理與後台作業相關的所有事情。 它可以是在背景執行的 cron 作業，用於傳送電子郵件或處理系統中的新使用者管道。 這導致我執行另一台伺服器來處理這些作業，無論是外部 EC2 伺服器還是帶有事件橋的無伺服器功能。 這會導致我支付額外的服務費用（管理更多服務）並自行管理水平擴展（在某些時候）。 [Trigger.dev](http://Trigger.dev) 改變了這一點，在 NextJS（以及許多其他）之上提供後台作業。 他們也知道如何解決 NextJS 無伺服器逾時限制來處理長時間執行的作業。  --- ## 2. [Prisma](https://www.prisma.io) Prisma 不是 NextJS 特有的。它是一個與資料庫一起使用的 ORM。 ORM 是資料庫查詢的統一包裝器。 它保持良好的結構，並允許您在不同的資料庫提供者之間快速更改。 雖然您可以使用很多 ORM，但 Prisma 的獨特之處在於為您的查詢提供 Typescript 支持，使一切速度提高 100 倍。 NextJS 在預設配置中使用了 typescript，使其成為完美的匹配。  --- ## 3. [NextAuth.js](https://next-auth.js.org) 假設您要實現任何服務提供者身份驗證，例如 Facebook / Google / GitHub (oAuth)。 在這種情況下，您必須為每個提供者建立實作或使用外部服務，例如 [Auth0](https://auth0.com/) 或 [Clerk](https://clerk.com/)。 如果您打算自行執行此操作，NextAuth 提供了豐富的實現，以便您只需提供正確的金鑰即可輕鬆新增它們。 一旦您登錄，他們也會處理授權。 *Next.JS auth 可以與 Prisma 開箱即用。*  --- ## 4. [下一個網站地圖](https://github.com/iamvishnusankar/next-sitemap) 在伺服器上部署 NextJS 後，您需要協助 google 索引所有頁面。 如果您可以告訴 Google 您網站上的所有頁面，那就更好了。 為此，您可以建立一個列出所有頁面的 sitemap.xml 檔案。 您可以輕鬆地使用 Next-Sitemap 來實現這一點。  --- ## 5. [下一步 SEO](https://github.com/garmeeh/next-seo) SEO 是透過向您的網站預覽提供關鍵字、描述和圖像，使您的網站出現在 Google Feed 上以進行不同查詢的過程。 如果您使用新的 NextJS 應用程式路由器，則可能不需要使用它。 您可以使用他們的“導出元資料”方法或“生成元資料”， 但如果您使用舊的應用程式路由器，這是為您的網站加入 SEO 的最佳方式。  --- ## 6. [Zod](https://github.com/colinhacks/zod) Zod 是一個物件驗證器（伺服器和客戶端）。 您可以在物件上放置不同的規則並稍後對其進行驗證，例如使用者名稱和密碼，或更複雜的內容（例如陣列長度或其他鍵上的條件）。 *Zod 不是 NextJS 特定的。* 多年來，我看過很多物件驗證器，例如 [Yup](https://github.com/jquense/yup) 和 [class-validator](https://github.com/typestack/class-validator)。 是的，它看起來不像 Zod 那樣維護，並且在使用 NestJS 之類的東西時，類驗證器非常強大 - 所以你最好使用 Zod。  --- ## 7. [React-hook-form](https://github.com/react-hook-form/react-hook-form) 雖然 Zod 可以驗證物件，但如果沒有自訂邏輯，它不會影響您的用戶端和後端。 React-hook-form 是優秀的用戶端驗證專案（顯示輸入錯誤、管理輸入狀態和提交）。 當然，您可以使用 Zod 作為 React-hook-form 的驗證器。  --- ## 8. [tRPC](https://github.com/trpc/trpc) 我承認我以前從未使用過 tRPC，但今天它似乎吸引了許多人的目光。 它與 Prisma 有類似的概念；它們為您的請求和回應產生一個接口，因此當您使用前端呼叫時，您會獲得自動完成功能。 這很好，因為它減少了錯誤的機會 - 假設您修改了後端路由，您將無法編譯專案 - 客戶端將返回不存在的參數或回應鍵的錯誤。  --- ## 9. [SWR](https://swr.vercel.app) 和 [React-Query](https://github.com/TanStack/query) 多年來我一直使用 Axios 和 fetch 作為發送請求的基礎庫。 SWR 和 React-Query 增強了這些函式庫並提供鉤子、快取、轉換等。 強烈推薦用於每個專案。請注意，這些庫適用於客戶端元件（“使用客戶端”），而不是伺服器元件。  --- ## 10. [lodash](https://lodash.com) 這不是 NextJS 特定的函式庫。 它是一個用於改變資料的函式庫，雖然這些年來 JavaScript 憑藉像 flatMap 這樣優秀的原生函數取得了很大的進步，但仍然缺少一些東西，例如按鍵或分塊和陣列的唯一陣列。 我發現自己幾乎在所有專案中都使用 lodash。  --- ## 11. [dayjs](https://day.js.org/) day.js 是一個包含與日期、格式、時區等相關的所有內容的函式庫。 我可能會因為那件事而被烤。我多年來一直在使用“moment.js”。 現在它不再維護了，dayjs 是一個不錯的選擇。 有些人喜歡新的 JS 函數來處理日期，但我仍然覺得 dayjs 選項和原生 JS 日期函數之間存在很大的差距。  --- ## 12. [jsdom](https://github.com/jsdom/jsdom) 這不是必須的，但我最近在許多專案中都使用它作為 [cheerio](https://github.com/cheeriojs/cheerio) 的替代品。 您可以取得整個頁面內容(`<html><body>....</html>)` 並將其轉換為稍後可以使用「本機」javascript dom 函數`querySelector`、`innerHTML` 等來操作的物件… 非常適合需要一些刮擦的專案。  --- 我們在 X 上連接嗎？ :) [我在這裡](https://twitter.com/nevodavid) 您是否為 NextJS 使用其他一些很酷的程式庫？ 請在評論中讓我了解它們:) --- 原文出處：https://dev.to/nevodavid/top-12-libraries-for-your-nextjs-project-1oob
科技愛好者常有遠大的夢想，渴望實現突破創新和個人發展界限的目標。為了幫助建立這些雄心壯志，我為科技愛好者量身定制了廣泛的願望清單。此清單不僅概述了各種目標，還包括「靈感」、「如何」、「年份」、「狀態」和「紀念品」等附加欄，為您的技術之旅提供全面的路線圖。 ## 清單中有什麼？ 該清單涵蓋了廣泛的目標，從培養特定技能（例如達到 150 WPM 的打字速度）到雄心勃勃的專案（例如製作 DIY 電動滑板或自行車）。它包括參加重大活動，例如參加大型技術會議，以及個人發展的里程碑，例如指導初級開發人員。每個目標都經過分類以便於參考，涵蓋 DIY 專案、程式設計、開發、學習等領域。 ## 列表 [我的遺願清單進度](https://syki.dev/bucket-list) |目標|類別|靈感|年份|狀態|紀念品| |---------------------------|----------------|----------------| ----|------|--------| |成為大型專案的貢獻者 |開發 |[如何像專業人士一樣開源](https://www.youtube.com/watch?v=MT6M_sqAuZo) | | | | |建立新聞聚合器 |開發 |[Feedly](https://feedly.com/) | | | | |建立實體引擎 |開發 |[我正在從頭開始編寫整個實體引擎](https://www.youtube.com/watch?v=iSMbRGTBOHU) | | | | |建立推薦系統 |開發 |[推薦系統如何運作 (Netflix/Amazon)](https://www.youtube.com/watch?v=n3RKsY2H-NE) | | | | |建構情緒分析工具 |開發 |【2023 如何掌握人工智慧驅動的情緒分析？】(https://brand24.com/blog/sentiment-analysis/) | | | | |建立擴增實境 (AR) 應用程式 |開發 |[關於如何在 2023 年建立擴增實境應用程式的指南](https://www.tekrevol.com/blogs/how-to-build-an-augmented-reality -應用程式/) | | | | |建置與部署聊天伺服器 |開發 |[IRC](https://en.wikipedia.org/wiki/Internet_Relay_Chat) | | | | |建立網路安全工具|開發|[Kali Tools](https://www.kali.org/tools/) | | | | |建立多人線上遊戲|開發|[Dani](https://www.youtube.com/watch?v=_ze26M_Fm6g) | | | | |建立 PWA（漸進式 Web 應用程式）|開發 |[PWA](https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps) | | | | |建立 AI 影響者 |開發 |[AI 影響者變得非常富有...讓我們建立一個](https://www.youtube.com/watch?v=ky5ZB-mqZKM&t=11s) | | | | |開發區塊鏈應用程式 |開發 |[使用以太坊智能合約和 Solidity 建置您的第一個區塊鏈應用程式](https://www.youtube.com/watch?v=coQ5dg8wM2o) | | | | |開發一種加密貨幣 |開發 |[您需要立即建立一種加密貨幣！！](https://www.youtube.com/watch?v=befUVytFC80) | | | | |開發VR 應用程式|開發|[教學 - 在Meta Quest 耳機上建立您的第一個VR 應用程式](https://developer.oculus.com/documentation/unity/unity-tutorial-hello-vr/) | | | | |開發一個電子商務網站 |開發 |[Next.js Commerce](https://nextjs.org/commerce) | | | | |開發開源遊戲引擎 |開發 |[C++ 中的 GameDev](https://www.youtube.com/watch?v=LyJkcv_rL9Y&list=PLpM-Dvs8t0Va6RoHkaLuPbRh7Fwpy4nbV) | | | | |開發瀏覽器擴充 |開發 |[Chrome 擴充應該會嚇到你。](https://www.youtube.com/watch?v=xIKwkPWUgOA) | | | | |在 github 上有一個擁有 100 顆星的專案 |開發 |[Linus Torvalds](https://github.com/torvalds?achievement=starstruck&tab=achievements) | | | | |擁有自己的 Tor 頁面 |開發 |[我在 Raspberry Pi 上放置了一個 DARK WEB 網站！!](https://www.youtube.com/watch?v=bllS9tkCkaM) | | | | |發明手勢控制介面 |開發 |[鋼鐵人](https://www.youtube.com/watch?v=P5k-4-OEuTk) | | | | |建立持續整合/持續部署管道|開發|[自動化您的工作流程](https://github.com/features/actions)從想法到生產]| | | | |設定 Kubernetes 叢集 |開發 |[為什麼要建置 Raspberry Pi 叢集？](https://www.youtube.com/watch?v=8zXG4ySy1m8) | | | | |贊助開源專案 |開發 |[投資為您的世界提供動力的軟體](https://github.com/sponsors) | | | | |使用查詢機制編寫自己的資料庫|開發|[製作我們自己的資料庫](https://acmiitr.medium.com/making-our-own-database-part-1-6cd9c49ed924) | | | | |在靜態網站產生器中撰寫頁面 |開發 |[Gatsby](https://www.gatsbyjs.com/) | | | | |編寫單頁應用程式 |開發 |[React](https://react.dev/) | | | | |使用 Raspberry Pi 專案實現家居自動化 |DIY |[我建立了一個更聰明的智慧家庭](https://www.youtube.com/watch?v=0rIvB3LZiKA) | | | | |建立自訂鍵盤 |DIY |[建立自己的機械鍵盤......正確的方式](https://www.youtube.com/watch?v=bBon6WwkdJE) | | | | |DIY電動滑板或自行車 |DIY |[我做了一個電動滑板！](https://www.youtube.com/watch?v=3bcvFzecg2Q) | | | | |以自訂遊戲建立迷你街機 |DIY |[終極 DIY 街機指南](https://www.youtube.com/watch?v=oTydZBIGAuk) | | | | |組裝一台 PC |DIY |[為 Minecraft 組裝一台價值 100,000 美元的 PC](https://www.youtube.com/watch?v=AHR80l7od2Q) | | | | |建立個人雲端儲存系統 |DIY |【這是我的終局之戰 - Mother Vault 伺服器機房更新】(https://www.youtube.com/watch?v=pLC0FUnko-M) | | | | |利用 IoT 建造自動澆水花園系統 |DIY |[Arduino 花園控制器 - 自動澆水和資料記錄](https://www.youtube.com/watch?v=O_Q1WKCtWiA) | | | | |打造小型自動駕駛汽車或機器人 |DIY |[快速巡線機器人](https://www.youtube.com/watch?v=lnP32gzHdvI) | | | | |建造水下ROV |DIY |[建造一艘DIY潛水艇](建造一艘DIY潛水艇) | | | | |搭建並飛行 FPV 無人機 |DIY |[為什麼要以 800mW 功率自由式飛行？ | [FPV](https://www.youtube.com/watch?v=bBb_kSO3vTo) | | | | |設計具有互動功能的智慧鏡子|DIY |[DIY智慧鏡子 - 完整教學](https://www.youtube.com/watch?v=OYlloiaBINo) | | | | | 以 3D 方式設計和列印一些東西 |DIY |[我在房間中央製作了一個機器人手臂！](https://www.youtube.com/watch?v=nRsaf16EdNM) | | | | |設計您自己的 PCB |DIY |[PCB 建立初學者 - 10 分鐘內開始完成教程](https://www.youtube.com/watch?v=MsdJgEinb34) | | | | |修復損壞的電子產品 |DIY |[ElectroBOOM](https://www.youtube.com/@ElectroBOOM) | | | | |在本地擁有自己的伺服器 |DIY |[為什麼要建立 Raspberry Pi 叢集？](https://www.youtube.com/watch?v=8zXG4ySy1m8) | | | | |實現智慧家庭|DIY |[我建造了一個更聰明的智慧家庭](https://www.youtube.com/watch?v=0rIvB3LZiKA) | | | | |製作機械手臂 |DIY |[我在房間中央製作了機械手臂！](https://www.youtube.com/watch?v=nRsaf16EdNM) | | | | | 用 Flipper Zero 開啟一些東西 |DIY |[這讓駭客攻擊太容易了 - Flipper Zero](https://www.youtube.com/watch?v=nLIp4wd0oXs) | | | | |成為智慧型手機應用程式的擁有者|創業|[VoidLog](https://www.youtube.com/watch?v=LY4rxYe-jKI&list=PLN3n1USn4xllDDLwgJ4avEqgj4dWynofp) | | | | |開發 SaaS 產品 |創業精神|[我如何在一天內建立一個新的 SaaS 產品](https://www.youtube.com/watch?v=v_3lcqUOaOA) | | | | |在店裡擁有自己的遊戲 |創業|[Dani](https://www.youtube.com/watch?v=_ze26M_Fm6g) | | | | |在新創公司工作 |創業精神|[新創工程師在家工作的一天](https://www.youtube.com/watch?v=TLysAkFM4cA) | | | | |一週多相睡眠|創業|| | | | |參加播客 |創業|[Lex Fridman](https://www.youtube.com/lexfridman) | | | | |完全存取伺服器 - 黑客 |黑客 |[先生。機器人](https://www.youtube.com/watch?v=QqknSms8VVI&t=16s) | | | | |獲得錯誤賞金 |駭客 |[HackerOne](https://www.hackerone.com/) | | | | |在奪旗大賽中進行駭客攻擊 |駭客攻擊 |[Mr.機器人](https://www.youtube.com/watch?v=6MrQ-mN8HM8) | | | | |編寫惡意軟體 |駭客 |[惡意軟體開發：進程、執行緒與句柄](https://www.youtube.com/watch?v=aNEqC-U5tHM) | | | | |150 wpm 速度打字 |程式設計 |[Monkeytype](https://github.com/monkeytypegame/monkeytype) | | | | |使用 Python 腳本自動化您的日常任務 |程式設計 |[開始使用 Python 自動化您的生活！ （Python檔案管理教學）](https://www.youtube.com/watch?v=NCvI-K0Gp90) | | | | |建立 Twitter 機器人 |程式設計 |[如何使用人工智慧發布熱門推文 // Twitter 機器人教學](https://www.youtube.com/watch?v=V7LEihbOv3Y) | | | | |編譯您自己的 Linux 核心 |程式設計 |[如何編譯自訂 Linux 核心](https://www.youtube.com/watch?v=APQY0wUbBow) | | | | |建立聊天機器人 |程式設計 |[使用深度學習、Python 和 TensorFlow 建立聊天機器人 p.1](https://www.youtube.com/watch?v=dvOnYLDg8_Y&list=PLQVvvaa0QuDdc2k5dwtDTyT9aCja0on8j) | | | | |使用 D3.js 建立資料視覺化專案 |程式設計 |[使用 D3.js 進行資料視覺化 - 完整教學課程](https://www.youtube.com/watch?v=_8V5o2UHG0E) | | | | |建立照片編輯工具 |程式設計 |[如何製作照片編輯應用程式的完整指南](https://www.cleveroad.com/blog/how-to-build-a-photo-editing-app-like-棱鏡並使其蓬勃發展/) | | | | |開發數位藝術作品產生器 |程式設計 |[如何為初學者產生瘋狂的人工智慧藝術（Midjourney V4）](https://www.youtube.com/watch?v=zf4z8A-OWBY) | | | | |開發檔案加密工具 |程式設計 |[製作您自己的加密程式](https://www.youtube.com/watch?v=TZT7wvTeVyY) | | | | |開發影片編輯軟體|程式設計|[我寫了一個影片編輯器（有點糟糕）](https://www.youtube.com/watch?v=iydG-e1dQGA) | | | | |開發語音助理應用程式 |程式設計 |[建立由 OpenAI 和 Python 驅動的 Jarvis | ChatGPT](https://www.youtube.com/watch?v=BEw5EFqCCEI) | | | | |開發智慧手錶應用程式 |程式設計 |[使用 Android Studio 在 WearOS 上建立並執行穿戴式應用程式](https://www.youtube.com/watch?v=-JO5oHRkybk) | | | | |開發您自己的 Slack/Discord 機器人 |程式設計 |[使用 Python 編寫 Discord 機器人 - 在雲端免費託管](https://www.youtube.com/watch?v=SPTfmiYiuok) | | | | |實現臉部辨識系統 |程式設計 |[從紙張到程式碼建立深度臉部辨識應用程式](https://www.youtube.com/watch?v=bK_k7eebGgc&list=PLgNJO2hghbmhHuhURAGbe6KWpiYZt0AMH) | | | | |學習函數式程式語言 |程式設計 |[函數式程式設計 - 概述](https://www.youtube.com/watch?v=8z_bUIl_uPo) | | | | |學習古老的語言 |程式設計 |[100 秒內的 COBOL](https://www.youtube.com/watch?v=7d7-etf-wNI) | | | | |學習並使用 Docker 進行容器化 |程式設計 |[Docker](https://www.docker.com/) | | | | |學習極快的語言 |程式設計 |[ThePrimeagen](https://www.youtube.com/@ThePrimeagen) | | | | |學習一門不尋常的語言（例如 Brainfuck） |程式設計 |[100 秒內完成 Brainfuck](https://www.youtube.com/watch?v=hdHjjBS4cs8) | | | | |學習量子運算基礎 |程式設計 |[在量子電腦上編碼](https://www.youtube.com/watch?v=q3ecPsMd4tA) | | | | |掌握高階演算法與資料結構（100道LeatCode） |程式設計|【569道 Leetcode 題後的我的大腦】(https://www.youtube.com/watch?v=8wysIxzqgPI) | | | | |對自訂語音控製家庭助理進行程式設計 |程式設計 |[建立由 OpenAI 和 Python 提供支援的 Jarvis | ChatGPT](https://www.youtube.com/watch?v=BEw5EFqCCEI) | | | | |對微控制器進行程式設計 |程式設計 |[微控制器程式設計駭客指南 [教學]](https://www.youtube.com/watch?v=XlFO5Iat178) | | | | |在 Vim 中編程 |程式設計 |[Vim 作為你的編輯器](https://www.youtube.com/watch?v=X6AR2RMB5tE&list=PLm323Lc7iSW_wuxqmKx_xxNtJC_hJbQ7R) | | | | |使用分離式鍵盤|編程|[拆箱新鍵盤！！！ （也進行打字測試！）](https://www.youtube.com/watch?v=nh-BAxbithc&t=156s) | | | | |網頁抓取資料 |程式 |[使用 AI 和代理網路進行工業規模的網頁抓取](https://www.youtube.com/watch?v=qo_fUjb02ns) | | | | |用組合語言寫程式 |程式設計 |[Tsoding](https://www.youtube.com/watch?v=WnBXLmKk_qw&t=82s) | | | | |寫一個 NPM 模組 |程式設計 |[NPM](https://www.npmjs.com/) | | | | |編寫伺服器端應用程式 |程式設計 |[Next.js](https://nextjs.org/) | | | | |編寫您自己的人工智慧模型 |程式設計 |[讓我們建立 GPT：從頭開始，用程式碼，拼寫出來。](https://www.youtube.com/watch?v=kCc8FmEb1nY) | | | | |編寫您自己的作業系統 |程式設計 |[Linus Torvalds](https://github.com/torvalds) | | | | |寫你自己的程式語言 |程式設計 |[我製作了自己的程式語言](https://www.youtube.com/watch?v=pgeSGBwtHW8&t=132s) | | | | |擁有私人部落格 |教學 |[Dan Abramov](https://overreacted.io/) | | | | |對學生的講座 |教學 |[馬克·祖克柏的 CS50 講座 - 2005 年 12 月 7 日](https://www.youtube.com/watch?v=xFFs9UgOAlE&t=807s) | | | | |指導初級開發人員 |教學 |[如何正確指導初級開發人員](https://stablekernel.com/article/how-to-properly-mentor-a-junior-developer/) | | | | |寫一篇關於科技主題的論文並發表 |教學 |[兩分鐘論文](https://www.youtube.com/@TwoMinutePapers) | | | | |編寫技術書籍或電子書 |教學 |[編寫技術書籍](https://paulcunningham.me/writing-technical-books/) | | | | |參加大型科技會議 |旅遊 |[CES](https://www.ces.tech/) | | | | |參加黑客松 |旅行 |[我挑戰自己贏得黑客馬拉松](https://www.youtube.com/watch?v=mAJlZUKhOGs) | | | | |參觀電腦歷史博物館 |旅行 |[工程師的旅行願望清單](https://www.mwrf.com/community/article/21848496/the-engineers-travel-bucket-list) | | | | |參觀 NASA 約翰遜航天中心 |旅行 |[工程師的旅行願望清單](https://www.mwrf.com/community/article/21848496/the-engineers-travel-bucket-list) | | | | |參觀國家航空暨太空博物館 |旅行 |[工程師的旅行願望清單](https://www.mwrf.com/community/article/21848496/the-engineers-travel-bucket-list) | | | | |參觀歷史科學儀器收藏 |旅行 |[工程師的旅行願望清單](https://www.mwrf.com/community/article/21848496/the-engineers-travel-bucket-list) | | | | |參觀大型強子對撞機 |旅行 |[工程師的旅行願望清單](https://www.mwrf.com/community/article/21848496/the-engineers-travel-bucket-list) | | | | |參觀麻省理工學院博物館 |旅行 |[工程師的旅行願望清單](https://www.mwrf.com/community/article/21848496/the-engineers-travel-bucket-list) | | | | |參觀國家核科學與歷史博物館 |旅行 |[工程師的旅行願望清單](https://www.mwrf.com/community/article/21848496/the-engineers-travel-bucket-list) | | | | ### 下載列表 [下載 CSV](https://syki.dev/uploads/bucket-list.csv) [下載 JSON](https://syki.dev/uploads/bucket-list.json) ## 附加列解釋 ### 靈感 本專欄反映了是什麼激發了追求特定目標的想法或願望。它可以是一個人、一個事件、一本書，甚至一部電影，點燃了人們對特定成就的熱情。例如，DIY 電動滑板的靈感可能是對永續交通的熱情或最喜歡的科技影片部落客的專案。 ### 年 本專欄提出了實現該目標的時間表或目標年份。它有助於規劃和設定現實的時間表。例如，您可能計劃在 2025 年之前參加一次大型技術會議。 ### 地位 狀態追蹤您的進度。它可以是“未開始”“進行中”“已完成”或“暫停”這有助於追蹤您的旅程並保持動力。 ### 紀念品 本專欄是一個獨特的補充，旨在紀念這一成就。它可以是實體、數位徽章、部落格文章，甚至是照片。例如，組裝 PC 的紀念品可能是已完成設定的第一張照片。 ## 結論 技術愛好者的願望清單不僅僅是目標的集合；這是技術領域個人和職業成長的路線圖。透過附加專欄提供靈感、方法、計時、追蹤和紀念成就的框架，此列表對於任何熱衷於技術的人來說都是一個動態工具。 快樂的科技冒險！ --- 原文出處：https://dev.to/syki/100-bucket-list-ideas-for-programmers-506m
是的，這篇文章的標題就是一個例子，類似於許多所謂的「Listicles」之一，這些「Listicles」一直在開發人員中亂扔。它們的標題充滿了表情符號和「你必須知道」或「對任何開發人員來說都是必不可少的」之類的詞語，它們吸引了我們人類天生的好奇心。 ## 重要的！ ### 並非所有清單都不好！ 請遵循以下準則來建立一個好的指南： - 確定目的：明確定義清單的目的和目標。您想提供讀者什麼資訊或價值？ - 選擇相關表情符號：選擇與內容相符並有助於您想要傳達的訊息的表情符號。確保它們不會讓人不知所措或分散注意力。 - 提供有意義的內容：專注於建立內容豐富且寫得好的文本，為讀者提供價值。表情符號應該補充內容而不是掩蓋內容。 - 評估整體影響：在發布之前，請檢查清單文章，以確保標題中使用表情符號或潛在的標題誘餌文字可以增強讀者的體驗並支持文章的預期目的。 透過執行這些步驟，您可以建立一個清單文章，該文章可以根據需要有效地包含盡可能多的表情符號和「您必須知道」文本，同時保持內容的品質和實質內容。   本質上，它們是點擊誘餌。這些帖子訴諸了人性中被稱為“FOMO”的東西。 ## 什麼是 FOMO？ FOMO 代表「害怕錯過」。這是一種以焦慮或不安的感覺為特徵的現象，這種感覺來自於相信其他人可能擁有自己未參與的有益經驗或機會。 FOMO 通常與社交媒體以及其他人分享的持續更新和活動聯繫在一起。 ## 什麼是「表情符號誘餌」？ 這些貼文利用的另一件事是「表情符號誘餌」。這個概念最近才被探索。它涉及使用 🤯、🚨、👿 和 🚀 等表情符號在社交媒體平台上操縱人們的情緒。人工智慧（AI）是這方面的專家。 **為什麼這些貼文不好？** 因為幾乎不可能找到任何好的內容！ 作為內容創作者，我們有責任以各種可能的方式支持我們的開發者同行的成長。在下面的評論中，讓我們討論如何在 DEV 這樣的平台上實現這一目標。我很想聽聽您對此事的看法。如何才能提升DEV社群的價值，讓所有開發者不那麼難以承受？ 請記住，成為一名出色的開發人員不僅僅需要了解所有可用的工具或資源。這是關於磨練解決問題的能力、培養創造力和擁抱終身學習。讓我們優先考慮這些基本技能，其餘的就自然而然了。 而且，正如所承諾的，這裡有 🚀 🚨 對於 dev.to 🤯 🚨 來說「Listicles」不好的 25 個原因。當您閱讀清單文章時，請考慮它如何反映其內容（畢竟，它本身就是清單文章） {% 可折疊 點選展開並查看清單 %} 1.內容淺薄：清單文章和點擊誘餌通常優先考慮簡潔性而不是深度，導致主題覆蓋膚淺。 2. 缺乏脈絡：它們提供的脈絡或背景資訊有限，使讀者的理解支離破碎。 3. 過度簡化：複雜的主題可能會過度簡化以適應清單格式，導致誤解和誤解。 4.標題誘餌：使用聳人聽聞或誤導性的標題來吸引點擊，損害內容的完整性。 5. 誤導性資訊：清單文章和點擊誘餌可能包含不準確或過時的訊息，導致讀者誤入歧途。 6. 缺乏可信度：有些缺乏可靠的來源或參考資料，導致難以驗證所提供資訊的準確性。 7. 內容重複：類似主題的清單文章經常有重複的內容，對尋求新見解的讀者沒有什麼價值。 8.缺乏深度：由於篇幅限制，清單文章很少深入研究某個主題的複雜或微妙的面向。 9. 阻礙批判性思考：清單文章和標題誘餌提供填鴨式訊息，阻礙讀者進行批判性思考和分析。 10. 忽略替代觀點：他們通常提出單一觀點，排除不同或互相衝突的意見。 11. 貨幣化高於品質：有些人優先考慮透過廣告創造收入，而不是製作高品質、資訊豐富的內容。 12. 不切實際的期望：清單文章和點擊誘餌可能會在沒有適當支持的情況下做出廣泛的主張或承諾，從而造成不切實際的期望。 13.內容研究不足：由於急於快速製作內容，一些內容缺乏徹底的研究和事實查核。 14. 缺乏原創性：許多人重複使用其他來源的內容，但沒有加入任何獨特的價值或見解。 15. 話題過度飽和：熱門話題經常被重複提及，導致社群充斥著冗餘內容。 16. 忽略長篇寫作：清單文章和標題誘餌掩蓋了長篇文章，削弱了深入分析的重要性。 17. 抑制學習：清單文章和點擊誘餌的小規模性質可能會阻礙讀者尋求全面的學習經驗。 18.注意力持續時間縮短：持續閱讀清單文章和點擊誘餌可能會導致注意力持續時間縮短，並減少對詳細內容的關注。 19. 浪費點擊：清單文章和點擊誘餌可能會用誘人的標題來吸引讀者，但結果卻是提供膚淺或無用的內容。 20. 失去細微差別：複雜的主題在簡化為編號列表時就失去了細微差別，從而過度簡化了重要細節。 21. 缺乏參與度：清單文章和點擊誘餌由於其膚淺的性質，經常無法產生有意義的討論或社區參與。 22. 創造力下降：它們可能會扼殺創意表達和原創性，因為作者覺得必須遵守清單格式。 23. 寫作標準下降：對快速清單文章和標題誘餌的需求可能會降低社群內寫作的整體品質和標準。 24. 延續線上瀏覽：清單文章和點擊誘餌助長了瀏覽而不是深度閱讀的文化，影響了整體理解。 25. 專業知識貶值：它們可能削弱主題專家的專業知識，因為他們的見解被濃縮或過度簡化。 {% 結束折疊 %} 我希望您覺得這篇文章很有趣！如果您對我做的其他事情感興趣，請查看我的網站： [https://the-best-codes.github.io/](https://the-best-codes.github.io/?ref=dev.to_post&click=https://dev.to/best_codes/25-原因-你-必須-知道-為什麼-listicles-are-bad-for-devto-1hok/&site=https://dev.to/&reason=best-codes-bad-listicles-post) 謝謝閱讀！ _2023年12月13日：_ _更新說明：_ 您可能已經看過我的一些帖子，“面向 Web 開發人員的 11 個令人驚嘆的書籤🔖 🚀（它們是什麼？🤔）”、“6️⃣ 常見瀏覽器：它們到底有多安全？ 🔒 😯」和「為無聊的程式設計師提供的 10 個有趣的 Web 開發專案創意 👍」。我相信這些不是“列表文章”或標題誘餌，因為它們並不淺薄，而且它們不僅僅是一個列表。如果您對其中任何一個有不同的意見，請告訴我如何改進它們！ --- 原文出處：https://dev.to/best_codes/25-reasons-you-must-know-why-listicles-are-bad-for-devto-1hok
隨著每個人和他們的貓為他們的應用程式建立一個“2023 Wrapped”，我無法阻止，不得不為這個很棒的 dev.to 社區建立一個小型開源應用程式 🥰 造訪[devto-wrapped.sliplane.app](https://devto-wrapped.sliplane.app/?username=code42cate)，輸入您的用戶名，看看您作為dev.to 的作者在2023 年取得了什麼成就！ **無需 API 金鑰或登入！** 這是我在 dev.to 的第一年的經驗：  PS：在評論中分享你的截圖，我會隨機挑選一個人，給他們發送一些免費的開發者貼紙作為提前的聖誕禮物🎅🎁 不管怎樣，你來這裡是為了學習一些東西，所以讓我們深入研究程式碼吧！ ## 教程 建立這個小應用程式的速度對我來說至關重要，因此我決定使用我最近使用的自己的[Hackathon Starter Template](https://dev.to/code42cate/how-to-win-any-hackathon -3i99)寫了關於。我剝離了一些我不需要的功能，從而產生了一個非常精簡的 monorepo： 1.Next.js + Tailwind 2. ShadcnUI 你可以在這個[Github儲存庫](https://github.com/Code42Cate/devto-wrapped)中看到所有內容 ### 設定 如果您想長期關注並親自嘗試一下，請按照以下步驟操作： ``` # Clone repository git clone https://github.com/Code42Cate/devto-wrapped.git # Install dependencies pnpm install # Start app pnpm run dev --filter web ``` 該應用程式現在應該從 http://localhost:3000 啟動。如果它不起作用，請在評論中告訴我！ ### 存取 dev.to 資料 這個小應用程式最有趣的部分可能是我們如何存取 dev.to 資料。雖然有幾種方法可以解決這個問題，但我有一些要求幫助我決定前進的方向： 1. 不抓取 - 花費太長時間，我希望資料可用 <1 秒 2. 僅公開資料 - 我不想向使用者詢問 API 金鑰或使用我自己的 3.不需要資料庫－我很懶，想避免無用的複雜性 這為我們提供了兩種可能的獲取資料的方式： 1. [記錄和未經驗證的 API 呼叫](https://developers.forem.com/api/v1) 2. 即使您未登錄，dev.to 網站也會進行未記錄的公開 API 呼叫 考慮到這兩種獲取資料的方式，我們基本上可以獲得 3 類資料： 1.使用API公開使用者資訊：`dev.to/api/users/by_username` 2. 使用 `dev.to/search/feed_content` API 和 `class_name=Article` 發布帖子 3. 包含 `dev.to/search/feed_content` 和 `class_name=Comment&search_fields=xyz` 的搜尋查詢的評論 這些 API 呼叫都是在伺服器端進行的，以加快請求速度，可以在「/apps/web/actions/api.ts」中找到。由於這只是組合在一起，因此功能相當簡單，錯誤處理也非常少： ``` export async function getUserdata(username: string): Promise<User | undefined> { const res = await fetch( `https://dev.to/api/users/by_username?url=${username}`, ); if (!res.ok) { return undefined; } const data = await res.json(); return data as User; } ``` 對於這個用例來說，這很好，但如果您不希望用戶發生意外崩潰，請記住正確捕獲異常並驗證您的類型😵 ### 計算統計資料 計算統計資料出奇地容易，主要是因為我們的資料非常小。即使你每天發帖，我們只會瀏覽 365 個帖子。迭代 365 個專案的陣列幾乎不需要時間，這給了我們很大的空間來完成工作，而無需關心效能！您在頁面上看到的每個統計資料都是在單一函數中計算的。以「總反應」為例： ``` const reactionsCount = posts?.reduce( (acc: number, post: Article) => acc + post.public_reactions_count, 0, ); ``` 我們需要做的就是檢查帖子陣列並總結每個帖子的“public_reactions_count”數量。田田，完成！ 即使對於更複雜的，它也只不過是一個嵌套循環： ``` const postsPerTag: Record<string, number> = posts?.reduce( (acc: Record<string, number>, post: Article) => { post.tag_list.forEach((tag) => { acc[tag] = acc[tag] ? acc[tag] + 1 : 1; }); return acc; }, {} as Record<string, number>, ); ``` ### 前端 由於這是使用 Next.js 建構的，因此所有內容都可以在「/apps/web/app/page.tsx」檔案中找到。 在元件的頂部，您可以先看到我們如何取得資料並檢查使用者是否存在或是否有足夠的資料來顯示任何內容： ``` const user = await getUserdata(username); if (!user) { return <EmptyUser message="This user could not be found 🫠" />; } const stats = await getStats(user.id.toString()); const mentionsCount = await getMentionedCommentCount(user.username); if (stats.postCount === 0) { return <EmptyUser message="This user has no posts 🫠" />; } ``` 不同的統計資料都是它們自己的元件，它們是 CSS 網格的一部分，看起來像這樣（縮短） ``` <div className="grid grid-cols-2 gap-2 w-full text-sm text-gray-800"> <PublishedPostsCard count={stats.postCount} /> <ReactionsCard count={stats.reactionsCount} /> <BusiestMonthCard busiestMonth={stats.busiestMonth} postsPerMonth={stats.postsPerMonth} /> <CommentsCard count={stats.commentsCount} /> <ReadingTimeCard readingTime={stats.readingTime} totalEstimatedReadingTime={stats.totalEstimatedReadingTime} /> </div> ``` 這些元件都是「啞」的，這意味著它們只負責顯示資料。他們不獲取或計算任何東西。其中大多數都非常簡單，就像這張「最佳貼文」卡： ``` import Image from "next/image"; import { Article } from "@/actions/api"; export default function BestPostCard({ post, coverImage, }: { post: Article; coverImage: string; }) { return ( <div className="flex w-full flex-col justify-between gap-2 rounded-xl border border-gray-300 bg-white p-4 shadow-md"> Your fans really loved this post: <br /> <Image src={coverImage} alt={post.title} width={500} height={500} className="rounded-md border border-gray-300" /> <a className="font-semibold underline-offset-2" href={`https://dev.to${post.path}`} > {post.title} </a> </div> ); } ``` ### 部署 為了部署我們的應用程式，我們將對其進行dockerize，然後使用Sliplane（稍微有偏見，我是聯合創始人！）將其託管在我們自己的[Hetzner Cloud](https://www.hetzner.com /cloud) 伺服器上。我在[上一篇部落格文章](https://dev.to/sliplane/understanding-nextjs-docker-images-2g08)中介紹瞭如何對Next.js 應用程式進行docker 化，這基本上是相同的，只是做了一些小的更改適應我的 Turborepo 設定:) ``` # src Dockerfile: https://github.com/vercel/turbo/blob/main/examples/with-docker/apps/web/Dockerfile FROM node:18-alpine AS alpine # setup pnpm on the alpine base FROM alpine as base ENV PNPM_HOME="/pnpm" ENV PATH="$PNPM_HOME:$PATH" RUN corepack enable RUN pnpm install turbo --global FROM base AS builder # Check https://github.com/nodejs/docker-node/tree/b4117f9333da4138b03a546ec926ef50a31506c3#nodealpine to understand why libc6-compat might be needed. RUN apk add --no-cache libc6-compat RUN apk update # Set working directory WORKDIR /app COPY . . RUN turbo prune --scope=web --docker # Add lockfile and package.json's of isolated subworkspace FROM base AS installer RUN apk add --no-cache libc6-compat RUN apk update WORKDIR /app # First install the dependencies (as they change less often) COPY .gitignore .gitignore COPY --from=builder /app/out/json/ . COPY --from=builder /app/out/pnpm-lock.yaml ./pnpm-lock.yaml COPY --from=builder /app/out/pnpm-workspace.yaml ./pnpm-workspace.yaml RUN pnpm install # Build the project COPY --from=builder /app/out/full/ . COPY turbo.json turbo.json RUN turbo run build --filter=web # use alpine as the thinest image FROM alpine AS runner WORKDIR /app # Don't run production as root RUN addgroup --system --gid 1001 nodejs RUN adduser --system --uid 1001 nextjs USER nextjs COPY --from=installer /app/apps/web/next.config.js . COPY --from=installer /app/apps/web/package.json . # Automatically leverage output traces to reduce image size # https://nextjs.org/docs/advanced-features/output-file-tracing COPY --from=installer --chown=nextjs:nodejs /app/apps/web/.next/standalone ./ COPY --from=installer --chown=nextjs:nodejs /app/apps/web/.next/static ./apps/web/.next/static COPY --from=installer --chown=nextjs:nodejs /app/apps/web/public ./apps/web/public CMD node apps/web/server.js ``` 在 Docker 化並推送到 Github 儲存庫後，我們需要做的就是在 Sliplane 中建立一個新服務並選擇我們想要託管的伺服器。我已經有一台伺服器，在上面執行一些小型專案，所以我只使用該伺服器：  點擊「部署」後，需要幾分鐘時間來建置並啟動我們的 Docker 映像。可以在日誌檢視器中監視進度：  第一次成功部署後，我們將獲得一個可以存取我們的應用程式的免費子網域，或者我們可以加入自己的自訂網域：  就是這樣！我們的應用程式在線，世界上每個人都可以存取，並且不會產生令人驚訝的無伺服器帳單 🤑 感謝您到目前為止的閱讀，不要忘記用您的截圖進行評論，以_可能_贏得一些貼紙😊 乾杯，喬納斯 --- 原文出處：https://dev.to/code42cate/devto-wrapped-2023-13o
--- 標題：我如何教 Git 發表：真實 描述： 標籤： git, 學習 canonical_url：https://blog.ltgt.net/teaching-git/ 封面圖片：https://marklodato.github.io/visual-git-guide/conventions.svg.png # 使用 100:42 的比例以獲得最佳效果。 # 發佈時間: 2023-11-26 19:17 +0000 --- 我使用 Git 已經十幾年了。八年前，我必須為一家即將建立開源專案的合作夥伴公司舉辦有關 Git（和 GitHub）的培訓課程，我將在這裡向您介紹我的教學方式。順便說一句，從那時起，我們在工作中建立了使用相同（或類似）方法的內部培訓課程。話雖如此，我並沒有發明任何東西：這很大程度上受到了其他人之前寫的內容的啟發，包括[the <cite>Pro Git</cite> book](https://git-scm. com/book/)，儘管順序不同，但 <abbr title="in my view">IMO</abbr> 可以有所作為。 我寫這篇文章的原因是，多年來，我不斷看到人們實際上使用 Git，但沒有真正理解他們在做什麼；他們正在使用 Git。他們要么被鎖定在一個非常具體的工作流程中，他們被告知要遵循，並且無法適應另一個開源專案正在使用的工作流程（這也適用於開源維護人員並不真正了解外部貢獻者如何使用 Git） ），或者如果任何事情沒有按照他們想像的方式執行，或者他們在呼叫Git 命令時犯了錯誤，他們就會完全迷失。我受到 [Julia Evans](https://jvns.ca) 對 Git 的（更新）興趣的啟發而寫下來，因為她有時會在社交網絡上徵求評論。 我的目標不是真正教你有關 Git 的知識，而是更多地分享我教授 Git 的方法，以便其他可能會教導的人從中獲得靈感。因此，如果您正在學習 Git，那麼這篇文章並不是專門為您而寫的（抱歉），因此可能不是自給自足的，但希望其他學習資源的連結足以填補空白，使其成為也是有用的學習資源。如果您是視覺學習者，這些外部學習資源都是有插圖的，甚至是視覺學習的。 ## 心理模型 一旦我們清楚了為什麼我們使用VCS（版本控制系統）來記錄_commits_ 中的更改（或者換句話說，我們_將我們的更改_提交到歷史記錄；我假設你對這個術語有一定的熟悉），讓我們多了解一下Git具體來說。 我認為理解 Git 至關重要的一件事是獲得其背後概念的準確心理模型。 首先，這並不是很重要，但Git 實際上並沒有記錄_changes_，而是記錄我們文件的_snapshots_（至少在概念上是這樣；它將使用_packfiles_ 來有效地儲存內容，並且在某些情況下方實際上會儲存_changes_ –diffs–），並且會按需產生差異。不過，這有時會顯示在某些命令的結果中（例如為什麼某些命令顯示一個檔案被刪除而另一個檔案被加入，而其他命令顯示一個檔案被重新命名）。 現在讓我們深入探討一些 Git 概念，或是 Git 如何實現一些常見的 VCS 概念。 ### 犯罪 Git _commit_ 是： * 一個或多個父親提交，或第一次提交沒有父親提交 (_root_) * 提交訊息 * 作者和作者日期（實際上是帶有時區偏移的時間戳） * 提交者和提交日期 * 和我們的檔案：相對於儲存庫根的路徑名、_mode_（UNIX 檔案系統權限）及其內容 每次提交都會獲得一個標識符，該標識符是透過計算該資訊的 SHA1 雜湊值確定的：更改逗號，您將獲得不同的 SHA1，即不同的_提交物件_。 (<abbr title="For What it's value">Fwiw</abbr>，Git 正在慢慢[轉向 SHA-256](https://git-scm.com/docs/hash-function-transition) 作為哈希功能）。 #### 旁白：SHA1 是如何計算的？ Git 的儲存是_內容尋址_，這表示每個_物件_都使用直接從其內容派生的名稱進行存儲，並採用 SHA1 雜湊的形式。 從歷史上看，Git 將所有內容儲存在文件中，我們仍然可以這樣推理。文件的內容儲存為 _blob_，目錄儲存為 _tree_（一個文字文件，列出目錄中的文件及其名稱、模式和表示其內容的 _blob_ 的 SHA1，以及其子目錄及其名稱和 SHA1他們的_樹_） 如果您想了解詳細訊息，Julia Evans（再次）寫了一篇令人驚嘆的[博客文章](https://jvns.ca/blog/2023/09/14/in-a-git-repository-- where-do-your-檔案-即時-/);或者您可以[從 <cite>Pro Git</cite> 書中閱讀](https://git-scm.com/book/en/v2/Git-Internals-Git-Objects)。 <圖> <img src=https://git-scm.com/book/en/v2/images/commit-and-tree.png width=800 height=443 alt='包含5 個框的圖表，分為3 列，每個框標有 5 位 SHA1 前綴；左邊的子標籤為“commit”，包含元資料“tree”，中間是框的 SHA1，“author”和“committer”的值均為“Scott”，文字為“The initial commit of我的專案”;中間的框被子標記為“tree”，包括三行，每行標記為“blob”，其餘 3 個框的 SHA1 以及看起來像文件名的內容：“README”、“LICENSE”和“test.rb” ”;最後 3 個框，在右側垂直對齊，都是子標籤為「blob」的內容，包含看起來像是 README、LICENSE 和 Ruby 原始檔內容開頭的內容；有箭頭連結框：提交指向樹，樹指向 blob。'> <figcaption>提交及其樹（來源：<a src=https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell><cite>Pro Git</引用></a>）</figcaption> </圖> _commit_ 中的_父親提交_ 建立一個代表我們歷史的[有向無環圖](https://en.wikipedia.org/wiki/Directed_acirclic_graph)：_有向無環圖_ 由連結的節點（我們的提交）組成與有向邊一起（每個提交連結到其父提交，有一個方向，因此_directed_）並且不能有循環/循環（提交永遠不會是它自己的祖先，它的祖先提交都不會連結到它作為父提交）。 <圖> <img src=https://git-scm.com/book/en/v2/images/commits-and-parents.png width=800 height=265 alt='包含 6 個框排列成 2 行 3 列的圖表;第一行的每個框都標有 5 位 SHA1 前綴，子標籤為“commit”，元資料“tree”和“parent”均帶有 5 位 SHA1 前綴（每次都不同）、“author”和“ committer」的值都是“Scott”，以及一些代表提交訊息的文字；左邊的盒子沒有「父」值，另外兩個盒子將左邊的盒子的 SHA1 作為「父」；這些框之間有一個箭頭，指向代表「父」的左側；順便說一句，左邊的框與上圖中的提交框具有相同的 SHA1 和相同的內容；最後，每個提交框也指向其下方的一個框，每個框都標記為「快照 A」、「快照 B」等，並且可能代表從每個提交連結的「樹」物件。'> <figcaption>提交及其父級（來源：<a src=https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell><cite>Pro Git</ cite ></a>)</figcaption> </圖> ### 參考文獻、分支和標籤 現在 SHA1 哈希對於人類來說是不切實際的，雖然 Git 允許我們使用唯一的 SHA1 前綴而不是完整的 SHA1 哈希，但我們需要更簡單的名稱來引用我們的提交：輸入 _references_。這些是我們選擇的提交的_標籤_（而不是 Git）。 有幾種_參考_： * _branches_ 是_moving_ 引用（請注意，`main` 或`master` 並不特殊，它們的名稱只是一個約定） *_標籤_是_不可變_引用 * `HEAD` 是一個特殊的引用，指向_當前提交_。它通常指向一個分支而不是直接指向一個提交（稍後我們會看到原因）。當一個引用指向另一個引用時，這稱為[_符號引用_](https://blog.ltgt.net/confusing-git-terminology/#reference-symbolic-reference)。 * Git 會在某些操作期間為您設定其他特殊參考（`FETCH_HEAD`、`ORIG_HEAD` 等） <圖> <img src=https://git-scm.com/book/en/v2/images/branch-and-history.png width=800 height=430 alt='帶有 9 個框的圖； 6 個盒子的排列方式與上圖相同，並且標記相同（三個提交及其 3 個樹）；最右邊（最新）提交上方的兩個框，箭頭指向它，分別標記為“v1.0”和“master”；最後一個框位於“master”框上方，有一個箭頭指向它，並標記為“HEAD”。'> <figcaption>分支及其提交歷史記錄（來源：<a src=https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell><cite>Pro Git< /引用></a>）</figcaption> </圖> ### 三個狀態 當您在 Git 儲存庫中工作時，您在 Git 歷史記錄中操作和記錄的檔案位於您的_工作目錄_中。要建立提交，您需要在 [_index_](https://blog.ltgt.net/confusing-git-terminology/#index-staged-cached) 或_暫存區域_中_暫存_檔案。完成後，您附加一則提交訊息並將您的_staged_檔案移至_history_。 為了關閉循環，_工作目錄_是根據_歷史記錄_中的給定提交進行初始化的。 <圖> <img src=https://git-scm.com/book/en/v2/images/areas.png width=800 height=441 alt='包含3 位參與者的序列圖：「工作目錄」、「暫存區域」和「.git directpry（儲存庫）」；有一條“簽出專案”訊息從“.git 目錄”到“工作目錄”，然後從“工作目錄”到“暫存區域”進行“階段修復”，最後從“暫存區域”進行“提交”區域」到「.git 目錄」。'> <figcaption>工作樹、暫存區域和 Git 目錄（來源：<a href="https://git-scm.com/book/en/v2/Getting-Started-What-is-Git%3F#_the_third_states" ><cite>Pro Git</cite></a>）</figcaption> </圖> ### 旁白：忽略文件 並非所有檔案都需要_追蹤_歷史記錄：由建置系統（如果有）產生的檔案、特定於您的編輯器的檔案以及特定於您的作業系統或其他工作環境的檔案。 Git 允許定義要忽略的檔案或目錄的命名模式。這實際上並不意味著Git 會忽略它們並且無法_跟踪_，但如果不跟踪它們，多個Git 操作將不會向您顯示它們或操縱它們（但您可以手動將它們加入到歷史記錄中，並且從那時起，他們將不再被_忽略_）。 忽略檔案是透過將路徑名稱（可能使用 glob）放入忽略檔案中來完成的： * 儲存庫中任何位置的 `.gitignore` 檔案定義了包含目錄的忽略模式；這些忽略文件會在歷史記錄中被跟踪，作為開發人員之間共享它們的一種方式；在這裡，您將忽略建置系統產生的那些檔案（Gradle 專案的“build/”，Eleventy 網站的“_site/”等） * `.git/info/excludes` 是您機器上的本機儲存庫；很少使用，但有時很有用，所以很高興了解一下 * 最後 `~/.config/git/ignore` 對機器來說是全域的（對你的使用者）；在這裡，您將忽略特定於您的電腦的文件，例如特定於您使用的編輯器的文件，或特定於您的作業系統的文件（例如macOS 上的“.DS_Store”或Windows 上的“Thumbs. db”） ） ### 加起來 這是所有這些概念的另一種表示： <圖> <img src=https://marklodato.github.io/visual-git-guide/conventions.svg width=907 height=529 alt='有 10 個框的圖； 5 個框在中心排成一行，標有 5 位 SHA1 前綴，它們之間有從右向左指向的箭頭；一條註釋將它們描述為“提交物件，由 SHA-1 哈希標識”，另一條註釋將其中一個箭頭描述為“子項指向父項”；一對框（看起來像一個水平分割成兩個框的單一框）位於最右邊（最新）提交的上方，有一個向下指向它的箭頭，該對的上面的框被標記為“HEAD”並描述為“引用當前分支”；下面的框被標記為“main”並被描述為“目前分支”；第七個框位於另一個提交上方，有一個向下指向它的箭頭；它被標記為“穩定”並被描述為“另一個分支”；最後兩個框位於提交歷史記錄下，一個在另一個之上；最底部的框標記為“工作目錄”並描述為“您'看到'的文件”，它和提交歷史記錄之間的另一個框標記為“階段（索引）”並描述為“要存取的文件”在下次提交中”。'> <figcaption>提交、引用和區域（來源：<a href=https://marklodato.github.io/visual-git-guide/index-en.html#conventions><cite>可視化 Git 參考</cite >< /a>，馬克‧洛達托）</figcaption> </圖> ## 基本操作 這就是我們開始討論 Git 指令以及它們如何與圖表互動的地方： * `git init` 初始化一個新的儲存庫 * `git status` 取得檔案狀態的摘要 * `git diff` 顯示任意兩個工作目錄、索引、`HEAD` 之間的更改，或實際上任何提交之間的更改 * `git log` 顯示並搜尋您的歷史記錄 * 建立提交 * `git add` 將檔案加入_index_ * `git commit` 將_index_ 轉換為_commit_ （帶有新增的_commit 訊息_） * `git add -p` 以互動方式將檔案新增至 _index_：選擇要新增的變更以及僅將哪些變更保留在工作目錄中，逐一檔案、逐個部分（稱為 _hunk_） * 管理分支機構 * `gitbranch` 顯示分支，或建立分支 *`git switch`（也稱為`git checkout`）將分支（或任何提交，實際上是任何_樹_）簽出到您的工作目錄 * `git switch -b` （也稱為 `git checkout -b`）作為 `gitbranch` 和 `gitswitch` 的捷徑 * `git grep` 搜尋您的工作目錄、索引或任何提交；這是一種增強的“grep -R”，它支援 Git * `gitblame` 來了解更改給定文件每一行的最後一次提交（因此，誰應該為錯誤負責） * `git stash` 將未提交的更改放在一邊（這包括_staged_文件，以及工作目錄中的_tracked_文件），然後_unstash_它們。 ### 提交、分支切換和 HEAD 當您建立提交（使用「git commit」）時，Git 不僅建立_提交物件_，還移動「HEAD」以指向它。如果「HEAD」實際上指向一個分支（通常是這種情況），Git 會將該分支移動到新的提交（並且「HEAD」將繼續指向該分支）。每當當前分支是另一個分支的祖先（該分支指向的提交也是另一個分支的一部分）時，提交將使“HEAD”移動相同，並且分支將_發散_。 當您切換到另一個分支（使用“git switch”或“git checkout”）時，“HEAD”會移至新的目前分支，並且您的工作目錄和索引將設定為重新組合該提交的狀態（未提交的更改將暫時保留；如果 Git 無法做到這一點，它將拒絕切換）。 如需更多詳細資訊和視覺表示，請參閱[commit](https://marklodato.github.io/visual-git-guide/index-en.html#commit) 和[checkout](https://marklodato. github .io/visual-git-guide/index-en.html#checkout）Mark Lotato 的<cite>可視化Git 參考</cite>的部分（請注意，該參考是幾年前寫的，當時`git switch ` 和 ` git Restore` 不存在，而 `git checkout` 是我們所擁有的一切；因此 _checkout_ 部分涵蓋的內容比 `git switch` 多一點）。 當然，<cite>Pro Git</cite> 這本書也是一個很好的視覺表示參考； [<cite>Branches in a Nutshell</cite> 子章節](https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell) 涵蓋了所有內容的很大一部分上述的。 ### 旁白：Git 是保守的 正如我們在上面所看到的，由於其_內容尋址存儲_，對提交的任何“更改”（例如使用“git commit --amend”）實際上都會導致不同的提交（不同的 SHA1）。 _舊提交_不會立即消失：Git 使用_垃圾收集_最終刪除無法從任何_引用_存取的提交。這意味著，如果您設法找回提交SHA1，則可以恢復許多錯誤（“git reflog”可以在此處提供幫助，或者符號“<branch-name>@{<n>}”，例如“main@{ 1}”） ` main` 在更改之前指向的最後一次提交）。 ### 使用分支機構 我們在上面已經看到了分支是如何發散的。 但分歧要求最終_合併_變回來（使用“git merge”）。 Git 在這方面非常擅長（我們稍後會看到）。 合併的一個特殊情況是目前分支是要合併到的分支的祖先。在這種情況下，Git 可以執行 [_fast-forward merge_](https://blog.ltgt.net/confusing-git-terminology/#can-be-fast-forwarded)。 由於兩個分支之間的操作可能始終針對同一對分支，因此 Git 允許您設定一個分支來追蹤另一個分支。另一個分支被稱為_追蹤_它的分支的_上游_。例如，設定時，「git status」將告訴您兩個分支彼此之間有多少分歧：目前分支是[_最新_](https://blog.ltgt.net/confusing-git-terminology /#your- branch-is-up-to-date-with-originmain) 及其上游分支，_後面_和[可以快轉](https://blog.ltgt.net/confusing-git-terminology/ #can-be- fast-forwarded），_超前_許多提交，或它們有分歧，每個提交都有一定數量。其他命令將使用該資訊為參數提供良好的預設值，以便可以省略它們。 要整合來自另一個分支的更改，而不是合併，另一種選擇是_cherry-pick_（使用同名命令）單一提交，而不包含其歷史記錄：Git 將計算該提交帶來的更改並將相同的更改應用於當前分支，建立一個與原始分支類似的新提交（如果您想了解更多有關Git 實際操作方式的訊息，請參閱Julia Evans 的[<cite>如何gitcherry-pick 和revert 使用3 路合併< /cite> ](https://jvns.ca/blog/2023/11/10/how-cherry-pick-and-revert-work/))。 最後，工具帶中的另一個指令是「rebase」。 您可以將其視為一次進行許多選擇的方法，但它實際上更強大（正如我們將在下面看到的）。但在其基本用途中，它只是這樣：您給它一系列提交（在作為起點的任何提交和作為終點的現有分支之間，預設為當前分支）和一個目標，並且它會挑選所有這些提交位於目標之上，並最終更新用作終點的分支。這裡的指令的形式是`git rebase --onto=<target> <start> <end>`。與許多 Git 命令一樣，參數可以省略，並且具有預設值和/或特定含義：因此，`git rebase` 是 `git rebase --fork-point upper` 的簡寫，其中 `upstream` 是 [upstream]當前分支的（https://blog.ltgt.net/confusing-git-terminology/#untracked-files-remote-tracking-branch-track-remote-branch）（我會忽略`--fork-point`這裡，它的作用很微妙，在日常使用上並不那麼重要），它本身就是`git rebase upper HEAD` 的簡寫（其中`HEAD` 必須指向一個分支），它本身就是`git rebase 的簡寫-- on=upstream uploaded `，`git rebase --onto=upstream $(git merge-baseupstream HEAD) HEAD` 的簡寫，並將rebase `upstream` 的最後一個共同祖先與當前分支之間的所有提交另一方面，手和當前分支（即自從它們分歧以來的所有提交），並將它們重新應用到“上游”之上，然後更新當前分支以指向新的提交。明確使用`--onto` （其值與起始點不同）實際上很少見，請參閱[我之前的文章](https://blog.ltgt.net/confusing-git-terminology/#git- rebase- --onto) 對於一個用例。 我們無法在沒有互動式變體「git rebase -i」的情況下呈現「git rebase」：它以與非互動式變體完全相同的行為開始，但在計算需要完成的操作之後，它將允許您對其進行編輯（作為編輯器中的文字文件，每行一個操作）。預設情況下，所有選定的提交都是精心挑選的，但您可以對它們重新排序，跳過某些提交，甚至將某些提交合併到單一提交中。實際上，您可以挑選最初未選擇的提交，甚至建立合併提交，從而完全重寫整個歷史記錄！最後，您還可以停止對其進行編輯（然後使用“git commit --amend”，和/或可能在繼續變基之前建立新的提交），和/或在兩次提交之間執行給定的命令。最後一個選項非常有用（例如，驗證您沒有在歷史記錄的每個點上破壞您的專案），您可以在`--exec` 選項中傳遞該命令，Git 將在每個重新基底提交之間執行它（這也適用於非互動式變基；在互動模式下，當能夠編輯變基場景時，您將看到在每個櫻桃選擇行之間插入執行行）。 更多詳細資訊和視覺表示，請參閱[merge](https://marklodato.github.io/visual-git-guide/index-en.html#merge)、[cherry pick](https://marklodato . github.io/visual-git-guide/index-en.html#cherry-pick) 和 [rebase](https://marklodato.github.io/visual-git-guide/index-en.html#rebase) Mark Lodato 的<cite>視覺化Git 參考</cite> 部分，以及[<cite>基本分支和合併</cite>](https://git-scm.com/book/en/v2/Git-分支-基本-分支和合併），[<cite>變基</cite>]（https://git-scm.com/book/en/v2/Git-Branching-Rebasing）和[<cite>重寫歷史< /cite>](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History) <cite>Pro Git</cite> 書的子章節。 您也可以查看 David Drysdale 的 [<cite>Git Visual Reference</cite>](https://lurklurk.org/gitpix/gitpix.html) 中的「分支和合併」圖。 ## 與他人合作 目前，我們只在我們的儲存庫中進行本地工作。 但 Git 是專門為與他人合作而建構的。 讓我介紹一下_遙控器_。 ### 遙控器 當您_複製_儲存庫時，該儲存庫將成為本機儲存庫的_遠端_，名為「origin」（就像「main」分支一樣，這只是預設值，名稱本身沒有什麼特別的，除了有時用作省略命令參數時的預設值）。然後，您將開始工作，建立本地提交和分支（因此從遠端_forking_），同時遠端可能會從其作者那裡獲得更多提交和分支。因此，您需要將這些遠端變更同步到本機儲存庫，並希望快速了解與遠端相比您在本機所做的變更。 Git 處理這個問題的方式是在一個特殊的命名空間中記錄它所知道的遠端（主要是分支）的狀態：「refs/remote/」。這些被稱為[_遠端追蹤分支_](https://blog.ltgt.net/confusing-git-terminology/#untracked-files-remote-tracking-branch-track-remote-branch)。 Fwiw，本機分支儲存在「refs/heads/」命名空間中，標籤儲存在「refs/tags/」中（來自遠端的標籤通常直接「匯入」到「refs/tags/」中，因此例如您會遺失位置資訊他們來自）。您可以根據需要擁有任意多個遙控器，每個遙控器都有一個名稱。 （請注意，遙控器不一定位於其他電腦上，它們實際上可以位於同一台電腦上，直接從檔案系統存取，因此您無需進行任何設定即可使用遙控器。） ### 取得 每當你從遠端 _fetch_ 時（使用 `git fetch`、`git pull` 或 `git Remote update`），Git 都會與它對話以下載它還不知道的提交，並更新 _remote-tracking遠端分支_ 。要取得的確切引用集以及取得它們的位置將傳遞給 `git fetch` 命令（如 [refspecs](https://blog.ltgt.net/confusing-git-terminology/#refspecs) ）以及儲存庫的` .git/config` 中定義的預設值，預設由`git clone` 或`git remote add` 配置以取得所有分支（遠端上的`refs/heads/` 中的所有內容）並放置它們位於` refs/remote/<remote>` 中（因此`origin` 遙控器的`refs/remote/origin/` ）具有相同的名稱（因此遙控器上的`refs/heads/main` 變成`refs/remote / origin/main` 本地）。 <圖> <img src=https://git-scm.com/book/en/v2/images/remote-branches-5.png width=800 height=577 alt='帶有3 個大方框的圖表，代表機器或儲存庫，包含代表提交歷史的較小框和箭頭；一個框標記為“git.outcompany.com”，子標記為“origin”，並包含名為“master”的分支中的提交；另一個框標記為“git.team1.outcompany.com”，子標記為“teamone”，並包含名為“master”的分支中的提交； 「origin」和「teamone」中的提交 SHA1 雜湊值相同，除了「origin」在其「master」分支上多了一個提交，即「teamone」在「後面」；第三個框標記為“我的電腦”，它包含與其他兩個框相同的提交，但這次分支被命名為“origin/master”和“teamone/master”；它還在名為“master”的分支中包含另外兩個提交，與遠端分支的較早點不同。'> <figcaption>遠端和遠端追蹤分支（來源：<a href=https://git-scm.com/book/en/v2/Git-Branching-Remote-Branches><cite>Pro Git</cite>< / a>)</figcaption> </圖> 然後，您將使用與分支相關的命令來獲取從_遠端追蹤分支_到本地分支的更改（“git merge”或“git rebase”），或“git pull”，這只不過是“git fetch”的簡寫` 後面跟著 `git merge` 或 `git rebase`。 <abbr title="By the way">順便說一句</abbr>，在很多情況下，當你建立本地分支時，Git 會自動將_遠端追蹤分支_設定為本地分支的_上游_（它會告訴你相關資訊）當這種情況發生時）。 ### 推 要與其他人共用您的更改，他們可以將您的儲存庫新增為遠端儲存庫並從中_pull_（意味著透過網路存取您的電腦），或者您可以_push_到遠端儲存庫。 （如果您要求某人從您的遙控器中提取更改，這稱為..._拉請求_，您可能在 GitHub 或類似服務中聽說過這個術語。） 推送與提取類似，相反：您將提交發送到遠端並更新其分支以指向新提交。作為安全措施，Git 只允許遠端分支_快速轉送_；如果您想推送以非快轉方式更新遠端分支的更改，則必須使用「git push --force-with-lease」（或「git push --force」）_force_它，但要小心：`-- force-with-lease`將首先確保您的_遠端追蹤分支_與遠端分支是最新的，以確保自上次_fetched_以來沒有人將變更推送到分支；` --force` 不會執行該檢查，而是按照您的指示執行操作，風險由您自己承擔）。 與「git fetch」一樣，您可以將要更新的分支傳遞給「git push」命令，但如果您不這樣做，Git 會提供良好的預設行為。如果你不指定任何東西，Git 會從目前分支的上游推斷遠程，所以大多數時候 `git push` 相當於 `git push origin`。這實際上是“git Push origin main”的簡寫（假設當前分支是“main”），它本身是“git Push origin main:main”的簡寫，是“git Push origin refs/heads/main:refs/”的簡寫heads/main`，意思是將本地的`refs/heads/main`推送到`origin`遠端的`refs/heads/main`。有關使用不同來源和目標指定 _refspecs_ 的一些用例，請參閱[我之前的文章](https://blog.ltgt.net/confusing-git-terminology/#refspecs)。 <圖> <img src=https://lurklurk.org/gitpix/push2.svg width=1052 height=744 alt='代表「git push」指令的圖表，有四個 git 圖表（點，有些有標籤，用線連接) 排列成兩行兩列；列之間的箭頭表示左列是「之前」狀態，右列是「之後」狀態；上面一行中的圖位於雲內部，代表遠端儲存庫，並且有兩個分支，“master”和“other”，它們偏離了共同的祖先；左下圖與上面的圖形狀相同，只是標籤更改為“origin/master”和“origin/other”，並且每個分支有更多提交：與“origin”分支相比，“master”分支有兩個額外的提交/master”，而“other”比“origin/other”多了一個提交；與左上圖相比，右上圖在其「master」分支中多了兩次提交；右下圖與左下圖相同，除了「origin/master」現在指向與「master」相同的提交；換句話說，在「之前」狀態下，遠端缺少三個提交，而在「git Push」之後，本地「master」分支的兩個提交被複製到遠端，而「其他」保持不變。'> <figcaption><code>git Push</code>（資料來源：<a href=https://lurklurk.org/gitpix/gitpix.html><cite>Git 視覺參考</cite></a>，David Drysdale ）</圖標題> </圖> 更多詳細資訊和視覺表示，請參閱[<cite>遠端分支</cite>](https://git-scm.com/book/en/v2/Git-Branching-Remote-Branches)，[< cite >使用遙控器</cite>](https://git-scm.com/book/en/v2/Git-Basics-Working-with-Remotes)，以及[<cite>為專案做出貢獻</ cite> ](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project) <cite>Pro Git</cite> 書的子章節，以及「處理遠程來自David Drysdale 的[<cite>Git Visual Reference</cite>](https://lurklurk.org/gitpix/gitpix.html) 的「儲存庫」圖表。 <cite>Pro Git</cite> 的<cite>為專案做出貢獻</cite>一章也涉及在GitHub 等平台上為開源專案做出貢獻，您必須先_fork_儲存庫，然後透過_pull requests_進行貢獻（或_合併請求_）。 ## 最佳實踐 這些是針對初學者的，希望不會引起太多爭議。 嘗試保留_clean_歷史記錄： * 明智地使用合併提交 * 清晰且高品質的提交訊息（請參閱[<cite>提交指南</cite>](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project #_commit_guidelines）在<cite>Pro Git</cite> 中） * make _atomic_ commits：每個提交應該獨立於歷史記錄中跟隨它的提交進行編譯和執行 這僅適用於您與他人分享的歷史記錄。 在本地，想怎麼做就怎麼做。對於初學者，我會給以下建議： * 不要直接在“main”（或“master”，或您在遠端上沒有專門擁有的任何分支）上工作，而是建立本機分支；它有助於解耦不同任務的工作：即將開始處理另一個錯誤或功能，同時等待有關當前任務的說明的更多詳細資訊？切換到另一個分支，稍後您可以透過切換回來回到該分支；它還使從遠端更新變得更容易，因為如果您的本地分支只是同名遠端分支的副本，沒有任何本地更改（除非您想推送這些更改），您確信不會發生衝突到該分支） * 毫不猶豫地重寫你的提交歷史記錄（`git commit --amend` 和/或 `git rebase -i`），但不要太早這樣做；在工作時堆疊許多小提交是完全可以的，並且只在共享之前重寫/清理歷史記錄 * 同樣，請毫不猶豫地重新調整本機分支以整合上游變更（直到您共用該分支，此時您將遵循專案的分支工作流程） 如果出現任何問題並且您迷路了，我的建議是使用 `gitk` 或 `gitk HEAD @{1}`，也可能使用 `gitk --all` （我在這裡使用 `gitk` 但使用任何工具你喜歡），可視化你的Git 歷史並嘗試了解發生了什麼。由此，您可以回滾到先前的狀態（`git reset @{1}`）或嘗試修復問題（擇優選擇提交等）。合併失敗，您可以使用“git rebase --abort”或“git merge - -abort」等命令中止並回滾到先前的狀態。 為了讓事情變得更簡單，請不要猶豫，在任何可能具有破壞性的命令（`git rebase`）之前，建立一個分支或標籤作為“書籤”，如果事情沒有按預期進行，您可以輕鬆重置。當然，在執行這樣的命令後，請檢查歷史記錄和文件，以確保結果是您所期望的。 ## 進階概念 這只是其中的一小部分，還有更多值得探索！ * 分離的「HEAD」：[`git checkout` 手冊頁](https://git-scm.com/docs/git-checkout#_detached_head) 有一個關於該主題的很好的部分，另請參閱[我之前的帖子](https ://blog.ltgt.net/confusing-git-terminology/#detached-head-state），要獲得良好的視覺表示，請參閱[<cite>使用分離的HEAD 進行提交</ cite>](https:// /marklodato.github.io/visual-git-guide/index-en.html#detached) Mark Lodato 的 <cite>視覺化 Git 參考</cite> 部分。 * Hooks：這些是可執行檔（大多數情況下是 shell 腳本），Git 將執行它們來回應儲存庫上的操作；人們使用它們在每次提交之前檢查程式碼（如果失敗則中止提交），產生或後處理提交訊息，或在有人推送到儲存庫後觸發伺服器上的操作（觸發建置和/或部署）。 * 一些很少需要的命令可以在您真正需要時節省您的時間： * `git bisect`：一個進階命令，透過測試多個提交（手動或透過腳本）來幫助您找出哪個提交引入了錯誤；對於線性歷史，這是使用二分法並且可以手動完成，但是一旦您有許多合併提交，這就會變得更加複雜，並且最好讓 git bisect 來完成繁重的工作。 * `git filter-repo`：實際上是一個[第三方命令](https://github.com/newren/git-filter-repo)，作為Git 自己的`filter-branch` 的替代品，它允許重寫儲存庫的整個歷史記錄，以刪除錯誤新增的文件，或協助將儲存庫的一部分提取到另一個儲存庫。 我們完成了。 有了這些知識，人們應該能夠將任何 Git 命令映射到如何修改提交的_有向無環圖_，並了解如何修復錯誤（在錯誤的分支上執行合併？基於錯誤的分支重新建置？）並不是說理解這些事情會很容易，但至少應該是可能的。 --- 原文出處：https://dev.to/tbroyer/how-i-teach-git-3nj3
你有沒有想過... **如果軟體開發人員的需求如此之大，為什麼現在找到開發人員的工作這麼難？** 為什麼面試過程這麼長？為什麼會有數百次拒絕？ 為什麼提供的工資低？ 今天，您將了解混亂背後的原因。 我們是如何來到這裡的。以及為什麼。 我還將向您展示為什麼事情並不像大多數開發人員想像的那麼糟糕。以及您需要採取的 5 個步驟來利用這種情況為您帶來優勢。 因此，當大多數開發人員都在倒退時，您可以快速發展您的職業生涯。 如果您是一位雄心勃勃的開發人員，想要更上一層樓並增加薪水，那麼這就是適合您的。 **因為有一件事是真的，我們所知道的軟體開發在 2023 年已經發生了永遠的變化。** 「美好的舊時光」已經一去不復返了。 知道如何建立 React 應用程式將不再讓你獲得這份工作。我們不會很快回到那個狀態。 我們走吧。 這一切都要追溯到 2022 年，當時從谷歌到 Meta 和微軟等大型科技公司開始宣布裁員。不是各種裁員，是裁員開發者。 起初，大多數開發人員都很有信心。 他們說，_「軟體開發總是在成長並且需求旺盛，我們將會復甦」_。 現在，12 個多月過去了，許多程式設計師已經失去了樂觀情緒（免責聲明：我仍然對開發人員的未來非常樂觀，稍後會詳細介紹）。 許多開發者正在失去耐心等待就業市場的復甦。如果它永遠不會發生怎麼辦？ 一些開發人員正在懷疑他們的職業選擇。正在考慮 B 計劃或已經轉向做其他事情。 其他人則被迫回到編寫程式碼之前的低薪工作。  最初的樂觀很快就變成了悲觀，許多開發者都在尋找 B 計畫。 **最好的情況是資料輸入或客戶服務工作。在最壞的情況下，它會回到咖啡店或倉庫。** 我認為這是一件非常悲傷的事情。僅僅因為你找不到擺脫困境的有效策略，就拋棄了你的夢想和多年的努力。 我相信，如果你進入軟體開發，那是有原因的。您可能工作勤奮、雄心勃勃且富有創造力。你至少應該有機會證明自己的價值。 在這篇文章中，我將向您展示該怎麼做。具體來說，無論市場表現如何，如何使用經過驗證的軟體工程原理來度過這場風暴，並將您的開發人員職業生涯提升到一個新的水平。 我是誰可以給你這方面的建議？ 我叫 Dragos，在過去 3 年裡，我幫助超過 230 多名軟體開發人員提升了技能，快速晉升到高級級別，並獲得了他們應得的認可和報酬。  我不是大師或技術影響者。我並不打算成為其中之一。 但是，在作為自學成才的開發人員編寫程式碼期間，我一直在戰壕里工作，現在幫助其他開發人員升級，這使我很有資格為您提供這方面的建議。 首先，讓我們先了解一下軟體開發行業目前正在發生什麼… **🚨附：您是否希望快速晉升為擁有優質資源、回饋和責任的高階開發人員？ [點擊此處加入我們的免費社區 - 高級開發學院。](https://bit.ly/46hbx3h)🚨** ## 現在的情況 像任何好醫生一樣，為了治療症狀，我們必須了解背後的問題。 開發人員就業市場就像任何市場一樣，受簡單的供需機制控制。對開發者的需求越大，開發者的議價能力就越大。 對開發者的需求越少，我們的談判能力就越小。 如果你不斷地感覺自己與其他開發者比較，無法要求高薪，並且很難找到工作，這意味著你在市場上的力量很小。  供需關係決定開發者就業市場。 傳統上，開發者在市場上擁有大部分權力，公司會不遺餘力地獲得最好的工程人才。 這就是為什麼開發人員的薪水不斷增長以及每個人都想學習如何編碼的原因。 **但是，在過去 12 個月裡，權力已經從開發者轉移到了公司（除了頂層的開發者，稍後會詳細介紹）。** 為什麼？ 很多原因。讓我們一一回顧一下… ## 1.“效率時代” 戰爭、通貨膨脹和經濟衰退迫使世界各地的公司最大限度地利用資金。包括軟體公司。 企業需要找到更有效的做事方式——如果您正在建立軟體，這意味著擺脫一些開發人員並自動化盡可能多的任務。  糟糕的經濟狀況迫使科技公司的執行長提高公司的效率。 正如馬克·祖克柏在他關於 Meta 的「效率年」的文章中提到的那樣，公司希望提高開發人員的生產力和工具並減少員工人數。 **一言以蔽之：科技公司希望盡可能精簡。** 這意味著軟體開發團隊不能再龐大了。他們需要一些高技能的開發人員以及大量的自動化設備。  這意味著縮小團隊規模（即：解僱表現不佳的員工）、取消優先順序較低的專案並降低招募率。用更少的軟體開發人員完成更多的工作。 對於開發人員就業市場來說，這可不是好訊息… **🚨附：您是否希望快速晉升為擁有優質資源、回饋和責任的高階開發人員？ [點擊此處加入我們的免費社區 - 高級開發學院。](https://bit.ly/46hbx3h)🚨** ## 2.人才海嘯 開發人員就業市場變得非常非常擁擠，有數百名候選人瞄準同一職位。 這是因為編碼技能變得越來越普遍。 在過去的十年中，訓練營和電腦科學學位一直在將軟體開發人員吸引到一個已經擁擠的市場中。尤其是訓練營，經過六週的編碼後，他們實現了六位數薪資的夢想。  這引發了一場「人才海嘯」。開發人員的工作被當作中產階級的金票出售。成千上萬的人放棄了學習編碼的希望。 然而，正如許多初級開發人員所看到的那樣，這主要是一種行銷承諾。 事實上，開發人員職位的競爭非常激烈，你在 3 個月的 Bootcamp 中學到的技能已經不足以脫穎而出。  由於大量開發者在尋找黃金，就業市場很快就飽和了。 2020 年的情況就已經如此，但後來情況變得更糟… ## 3.遠距工作 Covid-19 大流行推動全世界轉向遠距工作。鑑於編碼基本上可以在任何地方完成，開發人員的工作是適應速度最快的工作之一。 對許多開發人員來說，在家工作聽起來像是個夢想。 無需通勤，擁有更多屬於自己的時間，並以相同的薪水在舒適的家中進行編碼，這是大多數人在任何給定時間都需要的交易。 但事實證明，遠距工作是一把雙面刃。 因為最終，公司透過增加招募人數而受益最多。  遠距工作意味著軟體公司現在可以僱用來自世界各地的開發人員。 本地職缺吸引了數十名遠距求職者，他們願意以少得多的錢做同樣的工作。正如《紐約時報》所說： **“遠距工作者普遍面臨更多競爭，並且更加依賴運氣。” - 紐約時報** 如果您想知道為什麼現在有數百甚至數千名求職者，那麼答案就是：遠端候選人。 大多數職缺現在都在收到來自世界各地的申請。  隨著遠距工作的興起，本地工作現在面臨國際競爭。 當我可以在中西部找到具有相同技能且至少少兩倍的錢的人時，為什麼還要雇用矽谷的開發人員呢？ 在歐洲也一樣。 一家位於柏林的公司可以聘請一位位於德國中部小村莊的開發者。讓他們每個月來辦公室兩次。並少付給他們幾十萬歐元。 當然，一些公司採取了重返辦公室政策。 但從長遠來看，我們將看到越來越多的公司採用完全遠端的思維方式。從經濟學的角度來看，遠距工作很有意義。 **🚨附：您是否希望快速晉升為擁有優質資源、回饋和責任的高階開發人員？ [點擊此處加入我們的免費社區 - 高級開發學院。](https://bit.ly/46hbx3h)🚨** ## 4. 人工智慧與自動化 人工智慧已經存在很多年了，但從未像現在這樣出現在我們的生活中。 2023 年 10 月，OpenAI 發布了 ChatGPT。 近年來人工智慧創新的巔峰和迄今為止最好的人工智慧模型。它可以與您談論您的一天，也可以為您撰寫論文。 更糟的是，它可以編碼。  隨著人工智慧能夠編寫功能齊全的程式碼，許多開發人員都會問自己：“現在怎麼辦？” 如果有足夠好的提示，它可以比大多數人類開發人員更好、更快、更便宜地編寫程式碼。 當然，ChatGPT 無法自行思考。 這是一個巨大的統計機器。它會犯很多錯誤並且陷入循環。但是，這足以讓事情順利進行。而且情況只會變得更好。 GitHub 很快就做出了調整，將其整合到 GitHub Copilot 中，後者已直接在 VS Code 中可用。 從長遠來看，沒有人知道人工智慧將對就業市場產生什麼影響。 它會像某些人聲稱的那樣導致我們所知的編碼的終結嗎？或者它只是人類開發人員完成工作的工具？ 我們所知道的是，在短期內，人工智慧透過自動化任務或完全取代一些工作，給就業市場帶來了更大的壓力。  高盛估計，大約 29% 的電腦相關任務可以透過人工智慧自動化。 結果？ **找到一份體面的開發人員工作變得越來越難。** 回到報價和供應曲線，開發者數量增加，但就業機會數量保持不變。 隨著市場上數百名開發人員尋找職位，軟體開發產業正遭受「Tinder 效應」的困擾。類似網路約會的現象。 就像約會應用程式中的熱門個人資料一樣，軟體公司現在面臨著數百種不同的選擇。數百名候選人和簡歷。 整理噪音並不容易。 你必須更快地放棄候選人。即使你拒絕了一個合適的開發者，總會有其他人在門口等著。 好吧，現在對於開發者來說情況並不好。 忍住眼淚，因為我會告訴你為什麼事情並不像大多數開發人員想像的那麼糟糕... # 好訊息 這場「完美風暴」讓大多數開發者感到驚訝。許多人覺得薪水過低，但同時又沒有勇氣去市場。 這創造了一個“技能差距”，你可以利用它來跑得更快。  「在陽光明媚的天氣裡你無法超越 15 輛汽車…但在下雨天你可以。」- Ayrton Senna **風雨飄搖的就業市場實際上可能是您將開發人員職業提升到全新水平的完美時刻。** 首先，不要像其他人一樣屈服於恐懼。恐懼會讓你癱瘓，擾亂你的思考。不要驚慌失措，而是要超越噪音。 裁員開始一年後，公司意識到消除成本實際上會阻礙他們的成長。 在資本主義中，一家不成長的公司就是一家正在消亡的公司。 公司需要重新開始創造價值。緊急。 更多價值，因為我們正處於經濟衰退之中，消費者只想要最優惠的價格。而且速度更快，因為競爭是全球性的。 **在軟體開發中，價值意味著功能。這意味著高品質的程式碼。** 那麼人工智慧呢？ AI實際上刺激了市場。軟體公司別無選擇，只能將人工智慧模型整合到現有的軟體中。否則就有倒閉的風險。 你需要什麼？ 開發者、開發者、開發者… 好吧，這就是為什麼這可能是您作為一個雄心勃勃的開發人員超越競爭對手的最佳時機： ## 1. 質量重於數量 是的，市場上的開發者總數有所增加。但他們的技術技能品質卻沒有。 經濟衰退可能在一夜之間發生，但技術掌握需要時間。 即使在這樣的市場條件下，大多數公司仍然抱怨很難找到符合其工作要求的合格開發人員。 企業的要求是否過高？ 或許。 但是，這正是您可以利用的差距來保持競爭優勢。  市場上有如此多的噪音，這與您發送的申請數量無關。追求數量只會產生更多垃圾郵件。 重要的是您的簡歷和申請的品質。 這並不意味著您應該成為完美主義者。數字仍然很重要。在開始找工作之前，只需在[您的簡歷和LinkedIn 個人資料上做更多工作](https://dev.to/dragosnedelcu/how-to-find-a-developer-job-in-2023-with-little-or-no-experience-27h7)。 並專注於技術掌握而不是數字！ ## 2. 人工智慧作為補充 正如我所提到的，人工智慧模型無法思考，至少目前還不能。事實證明，它們更多的是對開發人員工作的補充，而不是替代品。 人工智慧帶來的是更多透過人工智慧整合進行的軟體開發。對正在開發的軟體的需求不斷增加。 這似乎有悖常理，但事實證明，人工智慧和自動化對軟體產業的影響與 70 年代修建高速公路對汽車交通的影響類似。 更多的高速公路意味著更多的汽車空間，因此更多的人使用汽車。導致汽車流量增加，而不是減少！  更多的高速公路，更多的汽車。更多人工智慧，更多程式碼。 人工智慧編碼工具將使產生的程式碼量倍增。 最終，這意味著更多的程式碼需要由人類檢查、驗證和維護。整體而言，需要更多的開發人員。 **🚨附：您是否希望快速晉升為擁有優質資源、回饋和責任的高階開發人員？ [點擊此處加入我們的免費社區 - 高級開發學院。](https://bit.ly/46hbx3h)🚨** ## 3. 現金仍為王 $$$ 有趣的是，開發人員的薪資仍在增加。但它們的成長並不相同。 事實上，大多數開發者都無法跟上通貨膨脹的腳步。許多人根本沒有加薪，儘管在市場上待了很久卻找不到職位。 其他人則獲得小幅加薪，例如 3%。由於去年通膨率約為 10%，這並不是加薪。又是減薪！ 但是，一小群幸運的程式設計師的薪酬正在打破記錄。 事實上，我們在 theSeniorDev.com 上看到了這一點。許多高級開發人員的薪資創下歷史新高，即使在歐盟市場也超過 6 位數。 幾年前，如此高的報價是非常不尋常的。 但是，如果你仔細想想，更高的薪水是有道理的。 一家公司面臨著交付一款可以為他們帶來數百萬美元收入的軟體的壓力，他們不會介意為能夠交付該軟體的開發人員額外花費數千美元。 這樣想吧，熟練勞力不是商品。 公司不會購買一雙一模一樣的鞋子並尋求優惠。有些鞋子會讓他們走得更快。為他們支付更多費用是有道理的。 **無論是矽谷或歐洲科技中心，趨勢都很明顯：熟練的開發人員需求量很大，公司願意為他們支付大量資金。** 正如您所看到的，事情並不像大多數開發人員想像的那麼糟糕。 至少不適合所有開發人員... 因為如果你和你的資深朋友交談過，你可能會發現有一群開發者做得併不差…。 ## 僅限資深開發人員的就業市場 儘管發生了一切，但高階開發人員的需求仍然非常大。您可以在招聘板上看到它，其中指定：僅限高級。 或查看誰正在被雇用並立即簽署工作合約。 Hired.com 的一份報告顯示，目前簽署工作合約的軟體開發人員中有超過 73% 擁有 7 到 5 年（或更長）的經驗。  高級開發人員受最近科技業裁員的影響最小。 感覺無論經濟如何發展，成為高級開發人員都會有回報。或多少程式碼 A.I.可以生成。  如果就業市場是動物農場。所有開發人員都是平等的，但高級開發人員比其他人更平等。 如果市場如此糟糕，為什麼高級開發人員仍然受歡迎？ 從公司的角度來看，高階開發人員從第一天起就可以創造價值。 公司知道，他們比以往任何時候都更需要快速、優質的交付，才能在當前經濟狀況下保持競爭力。通貨膨脹，記住。 所有這些因素意味著整個軟體開發團隊將崩潰為少數開發人員利用兩個要素： 1. **高級開發人員** 2. **人工智慧工具和自動化** 儘管發生了這一切，但也不全然是壞訊息。堅持幾秒鐘，我會告訴你原因。 **事實是，您可以利用當前的情況來發揮自己的優勢。** **🚨附：您是否希望快速晉升為擁有優質資源、回饋和責任的高階開發人員？ [點擊此處加入我們的免費社區 - 高級開發學院。](https://bit.ly/46hbx3h)🚨** # 真相 為了在這個充滿活力的就業市場中取得成功，您將需要比與您競爭的其他數千名開發人員更可靠的策略和更有效率的流程。 您需要立即採取行動，因為… 提供高薪、酷炫技術堆疊、良好福利和遠距工作的開發人員工作每天都變得越來越有競爭力。 這並不意味著他們不可能到達。簡而言之，獲得開發人員工作的舊方法不再有效。 如果您需要其他 5 名開發人員的幫助才能將程式碼投入生產，那麼您的日子就很寶貴了。還有另一個開發人員可以提供端到端的服務，他們將取代您的位置。 所以你會怎麼做？ 正如我的一位招募人員朋友所說： **「你最好的選擇是盡快成為高級開發人員」。** 盡快達到高級水平是目前在軟體開發市場中生存的唯一途徑。 成為高級開發人員將使您從眾多編碼人員中脫穎而出，提供端到端的價值，並被視為對公司的投資，而不僅僅是另一個昂貴的開發人員。  聰明的開發人員正在尋找提供更多服務並脫穎而出的方法。他們正在尋找快速實現這一目標的方法。 他們首先需要解決的是如何提升自己的技術能力。 好訊息是，您不需要在周末花費無數時間或編碼來實現這一目標。您不需要啟動數百個線上課程和副專案。 而且您不需要等待數年才能做到這一點。因為有更好的方法可以做到這一點。 你只需要專注在那些不會改變的事情上。 **那麼，如何獲得對自己技能的完全信心、端到端交付並釋放高級信心？** 您遵循基於經過驗證的軟體開發原則的逐步過程。就像高級開發人員每天使用的那樣。我們稱之為技術掌握藍圖。 在接下來的幾行中，我將更深入地討論具體步驟，但這不是本文的目標。 如果您有興趣了解更多訊息，可以單擊下面的連結並觀看我為您準備的免費培訓。 [這是免費培訓的連結。](https://bit.ly/3udWD0m) **免責聲明**：您必須加入您最好的電子郵件才能存取它。別擔心我不會寄垃圾郵件給你。我只會與您分享有關如何快速晉升高級開發人員並讓您的開發人員職業生涯提升到一個全新水平的相關資訊。您可以隨時取消訂閱。 **🚨附：您是否希望快速晉升為擁有優質資源、回饋和責任的高階開發人員？ [點擊此處加入我們的免費社區 - 高級開發學院。](https://bit.ly/46hbx3h)🚨** ### 1. 首先，你要採取資深開發人員的心態🧠 成為高級開發人員的第一步是改變您對軟體開發職業和整個生活的看法。 這意味著要以更高的標準要求自己。對您目前的開發者職業生涯承擔全部責任。並掌控你的職涯道路。 你也必須擺脫限制性信念或任何內在的關於自己的負面情緒。你必須養成新的習慣並培養紀律技能。 這意味著設定明確的重點目標，為自己定義一個在情感上令人信服的願景，並在執行這些目標時對自己負責。 **🚀[行動專案]**：準確定義您想要在未來 12 個月內實現的目標。為什麼想實現它？到達那裡需要採取哪些步驟？你是否缺乏任何知識和技能？你需要做一些與現在不同的事情才能到達那裡嗎？寫下來。 當你走向高級開發的旅程時，這將是讓你的火焰保持活力的燃料。大多數開發人員從未到達那裡，因為他們退出得太早。他們忘記了過程就是目標。 ### 2. 其次，你掌握了「基礎知識」📚 大多數開發人員，特別是 JavaScript 開發人員已經習慣相信軟體開發中的資歷就像一個購物袋。 新增的庫和框架越多，其等級就越高。 事實上，情況完全相反。高級開發人員平均編寫的程式碼比初級開發人員少。他們使用不太閃亮的庫和框架來解決問題。 沉迷於框架和庫會讓你成為炒作列車的受害者。當一個圖書館失寵時，另一個圖書館就會出現，需要您投入時間和注意力。這是一場你無法獲勝的遊戲。 如何才能逃脫炒作機器？ 透過專注於**「不會改變的事情」**。我們所說的基礎知識。 模式和原則是大多數框架和函式庫的核心。對基礎知識的深入理解將確保您無論情況如何變化都能掌握最新資訊。 它還可以保護您免受人工智慧和自動化的影響。在程式碼在幾秒鐘內產生的世界中，清晰的思維變得越來越有價值。雙贏。 基礎知識取決於您的技術堆疊。 如果您是 JavaScript 開發人員，您主要需要掌握 2 組基礎知識。電腦科學基礎知識和 JavaScript 基礎知識。 這不是本文的範圍，但我整理了一個路線圖，供您準確了解這些內容，請參見下文。 🚨 PS有關“計算機科學基礎知識”的詳細列表，請查看[計算機科學基礎知識掌握路線圖](https://mm.tt/app/map/2980765378?t=LsjjpEBYky)。🚨 🚨附言有關「JavaScript 基礎知識」的詳細列表，請查看我們的 2023 年 [JavaScript 基礎知識掌握路線圖](https://mm.tt/app/map/2962635113?t=ILeYm71vU3)。🚨 順便說一句，我們免費社群的開發人員可以存取獨家內容和針對基礎知識的客製化練習。請在下面註冊！ **🚨附：您是否希望快速晉升為擁有優質資源、回饋和責任的高階開發人員？ [點擊此處加入我們的免費社區 - 高級開發學院。](https://bit.ly/46hbx3h)🚨** ### 3. 第三，您學習如何端到端交付🎯 任何科技公司執行長現在最不想做的就是僱用更多的開發人員。但他們確實想解決問題。很多問題。 但是，你無法真正解決問題，我的意思是，當你只建構孤立的功能時，會出現有價值的問題。或者當您需要另外 5 名開發人員的幫助才能將您的東西投入生產時。 **高級開發人員之所以需求如此巨大，是因為他們可以提供端到端的服務。** 他們可以與產品經理或其他利害關係人獨立工作，並從第一天起就交付價值。掌握了這一點，你的價值就會增加10倍。 端到端交付並不意味著您必須了解一切。 這意味著您需要了解後端以及基礎設施方面的情況。目前無需深入研究各個元件。但從大局來看是的。 **[進階開發提示]**：學習如何端到端交付的最快方法不是 100 小時的雲端憑證課程（這些課程的重點是向您推銷品牌，而不是教您東西） ）。 相反，請嘗試規劃您公司的 CI/CD 流程。 找出他們擁有的任何架構圖，然後自己參與其中。如果他們沒有，請自己建造一些。這已經可以給你一個良好的開始，並在你的下一次技術面試中談論很多事情。 🚨附言要確切了解您需要掌握哪些端對端交付心理模型，請查看我們的[JavaScript 開發人員的「端對端交付」路線圖](https://mm.tt/app/map/2974013323?t=pqAIdWZ7W2 ).🚨 **🚨附：您是否希望快速晉升為擁有優質資源、回饋和責任的高階開發人員？ [點擊此處加入我們的免費社區 - 高級開發學院。](https://bit.ly/46hbx3h)🚨** ### 4.第四，成為「AI驅動」🚀 當我接到想要加入我們專案的開發人員的電話時，最令我驚訝的事情之一是他們每天很少使用人工智慧。 有些人多次使用 ChatGPT 來執行日常任務（樣板檔案、測試）。真正使用過 GitHub Copilot 的人就更少了。 他們告訴我他們不相信它的未來。或者他們的公司並沒有真正使用它。 如果你在飛機上，氧氣會耗盡，我敢打賭，即使機組人員沒有給你，你也會尋找氧氣面罩。 ChatGPT 和 GitHub Copilot 不只是更好的自動完成工具。自動完成無法重構、尋找程式碼中的錯誤或擴充功能。 人工智慧模型可以優化、重構，甚至可以比許多開發人員提出更好的程式碼。事實上，到 2023 年，在人工智慧工具的幫助下，初級開發人員可以完成與沒有人工智慧工具的高級開發人員一樣多的工作。 重點很明確：如果您是願意轉為高級的 JavaScript 開發人員，您需要成為「人工智慧驅動」。 如果您已經是大四學生並希望在未來幾年保持相關性，情況也是如此。潮流正在改變。透過升級這些技能來確保您處於正確的位置。 您是否必須學習 Python、Numpy、深度學習以及 AI 堆疊中的十幾種工具？並不真地。這是一項完全不同的工作。 **這意味著你應該將人工智慧工具整合到你所做的一切中。** 從建置功能到程式碼審查，再到測試和效能優化。如果您希望我寫一篇有關如何做到這一點的文章，請在評論中告訴我。 **🚨附：您是否希望快速晉升為擁有優質資源、回饋和責任的高階開發人員？ [點擊此處加入我們的免費社區 - 高級開發學院。](https://bit.ly/46hbx3h)🚨** ### 5.第五，有效推銷自己🏆 如果你找不到一家公司來支付你的技能費用，那麼無論你是多麼優秀的開發人員，也沒有用。由於開發人員就業市場已經過度飽和，這一點更加正確。 為了脫穎而出並獲得頂級軟體開發人員的職位，您必須以盡可能最好的方式將自己推向市場。 作為一名員工，這一點更為重要，因為您應該始終擔心的一件事是您的就業能力。 **如果你明天被解僱，你找到另一個職位有多容易？** 你越有就業能力就越好。 您的就業能力取決於兩件事。您的產品（在這種情況下，您的開發技能和支持這些技能的過去經驗）。 其次，你如何推銷自己和你的人脈。有多少人認識你？如果你現在被解僱，明天有人可以提供你工作嗎？ 要改進您的產品，請提高您的開發技能。我們在前面的幾點中討論過這一點。但如何改進自我推銷的方式呢？ **好吧，如果你想要高級開發人員的薪水，你首先必須看起來像高級開發人員。** 這意味著建立一份相關的履歷，以最好的方式量化以展示您為市場帶來的東西。 如果您想讓我寫一篇關於如何打造一流開發人員履歷表的文章，請在評論中告訴我！ ## 總結與後續步驟 好吧，現在你知道了。 下次當你問自己為什麼現在找到開發人員的工作如此困難時，請考慮這些原因。您還了解如何透過盡快成為高級開發人員來解決這個問題。 能夠落實這 5 個支柱並以最快的速度適應這個新市場範式的開發人員將獲得工作保障、對自己的技能充滿信心並獲得最高的薪水。 無法適應的開發者將慢慢被淘汰，並面臨被完全擠出市場的風險。 按照我在本文中概述的步驟操作，您不僅可以輕鬆找到開發人員工作，而且可以「快速」晉升到高級開發人員級別，並將您的開發人員職業生涯提升到一個全新的水平。 他們為我和世界各地 230 多名其他開發人員工作，他們也將為您工作！ 我們下一篇再見 德拉戈斯 **🚨附：您是否希望快速晉升為擁有優質資源、回饋和責任的高階開發人員？ [點擊此處加入我們的免費社區 - 高級開發學院。](https://bit.ly/46hbx3h)🚨** --- 原文出處：https://dev.to/dragosnedelcu/why-is-it-so-hard-to-find-a-developer-job-in-2023-and-how-to-fix-it-2d13
我們正在開發 [Wasp](https://github.com/wasp-lang/wasp) - 一個基於 React、Node.js 和 Prisma 建置的全端 Web 框架。自從 GPT 出現以來，我們想知道是否可以使用它來更快地建立 Web 應用程式。這讓我們想到了 [MAGE - 一個由 GPT 驅動的 Web 應用程式產生器](https://usemage.ai/)，它可以根據簡短的描述建立完整的堆疊程式碼庫。 我們已經寫過[MAGE 可以（和不能）做什麼](https://dev.to/wasp/gpt-web-app-generator-let-ai-create-a-full-stack-react-nodejs-codebase-based-on-your-description-2g39)和[它在幕後的工作原理](https://wasp-lang.dev/blog/2023/07/17/how-we-built-gpt-web-app-generator)。這是關於它的起源和採用的故事 - 為什麼我們決定建立它，開發人員如何發現它，以及他們實際上用它做什麼。 ## 為什麼要建構另一個 AI 編碼代理？ 我們很晚才進入整個 GPT 編碼代理遊戲。在我們開始考慮建立自己的工具之前，Smol AI、GPT Engineer 和 MetaGPT 等工具就已經受到了廣泛的關注，我們對此也很清楚。  那為什麼還要麻煩呢？事實是，這些代理程式都不是專門為建立 Web 應用程式而設計的，而這正是我們看到機會的地方。 儘管使用 GPT 代理進行編碼可以讓人感覺超級強大，但它們通常會很慢並且沒有抓住要點，需要多次迭代，最終使該過程相當麻煩且昂貴。 有了這些經驗，我們想知道，*「如果我們為特定堆疊中的 Web 應用程式製作一個高度專業化的編碼代理，而不做其他事情會怎麼樣？它能變得更容易、更快、更便宜嗎？」* 儘管我們對此很感興趣，但作為一個兼顧多個優先事項的小團隊，我們仍然相當懷疑，幾乎放棄了整個專案。事實證明，它的效果比我們預期的還要好。 ## 第 1 步：建造它🛠️  在決定 MAGE（*Magic App Generator*）的 v0 版本時，我們考慮了多種選擇。第一個也是最直接的一個是將其與 Wasp CLI 集成，因為我們已經擁有了圍繞它的所有工具。然後，開發人員將執行“wasp new myProject -ai”，而不是執行“wasp new myProject -ai”，CLI 會要求他們提供應用程式描述和其他所需的輸入，然後在終端中完成所有工作。 另一方面，我們知道在開始描述您的應用程式之前下載並安裝 Wasp 是一個很大的要求。最重要的是，CLI 中的使用者介面功能非常有限。這就是我們選擇網路介面的原因 - 零摩擦開始，我們可以讓應用程式建立流程變得非常簡單且美觀。 花了幾週的時間來建構它，最終的結果是一個[用Wasp 製作的完全開源的Web 應用程式](https://github.com/wasp-lang/wasp/tree/wasp-ai/wasp-ai)可以在 https://usemage.ai/ 上免費使用，或在本地託管以獲得更多控制和靈活性（例如，使用您自己的 OpenAI API 金鑰）。 ### 超級具體（僅限網頁應用程式）得到了回報！  如上所述，我們的主要賭注是建立一個專門的編碼代理來建立全端 Web 應用程式，而不是其他任何東西，這得到了回報。它使我們能夠預先為代理提供大量上下文和結構，並引入專門的啟發式方法來修復錯誤。此外，由於 Wasp 的高級抽象（例如身份驗證、專案結構、查詢和作業系統等），我們顯著減少了錯誤的表面積。 另一個結果是執行時間顯著減少，甚至更重要的是成本減少。典型的MAGE 建立的Web 應用程式成本在0.10 至0.20 美元之間，而一般編碼代理[同一應用程式的花費可能高達10 美元](https://wasp-lang.dev/blog/2023/08/01/smol-ai-vs-wasp-ai#thoughts--further-considerations)（所有價格均在 OpenAI 23 年 11 月 7 日定價更新公告之前）。 您可以閱讀有關Wasp 內部工作原理的更多資訊[此處](https://wasp-lang.dev/blog/2023/07/17/how-we-built-gpt-web-app-generator)，以及它的比較其他編碼代理[此處](https://wasp-lang.dev/blog/2023/07/17/how-we-built-gpt-web-app-generator)。 ## 第 2 步：啟動它🚀  開發產品是一回事，但傳播產品並讓人們使用它則完全是另一回事。在我們建立了 MAGE 並在團隊內對其進行了測試之後，問題是下一步該做什麼？我們如何真正聯繫開發人員並開始接收回饋？ ### 社區啟動 - 生命的證明  由於當時我們已經擁有一個[擁有大約 1,000 名成員的 Wasp 社區](https://discord.gg/rzdnErX)，因此我們[發布了 MAGE 作為我們發布週 #3 的一部分](https://wasp-lang.dev/blog/2023/06/22/wasp-launch-week-third#gpt-web-app-generator--friday-waspularity---tutorial-o-thon)。這是一個很好的測試平台，我們可以看到第一個應用程式正在建置。儘管如此，更多的開發人員本可以從更簡單的方式來啟動他們的 React 和 Node.js 專案中受益，但他們卻無法找到 MAGE。 ### 啟動 Product Hunt — 首次「真正」使用  這就是為什麼我們決定在內部社群啟動後將 MAGE 放在 Product Hunt 上。儘管Product Hunt 不是一個特定於開發工具的平台，並且吸引了來自不同背景的人群，但仍然有很多開發人員在使用它，而且我們[之前有很好的經驗](https://www.producthunt.com/products/wasp-lang-alpha/launches) 與它。 Product Hunt 對於[獲得Wasp 的第一批用戶並在GitHub 上獲得1,000 顆星](https://wasp-lang.dev/blog/2022/09/29/journey-to-1000-gh-stars) 至關重要，因此我們想再試一次。 有些人在發布準備工作上投入了大量精力，需要提前幾個月才能準備好，但我們沒有那個時間，只是想盡快完成。我們要求我們的朋友和社區查看 [MAGE on Product Hunt](https://www.producthunt.com/products/wasp-lang-alpha#gpt-webapp-generator-for-react-node-js) 並提供支持我們在發布當天就進入了當天的前十名產品，後來又躋身本週排名第二的開發者工具！ 這就是我們的目標，因為排名前十的產品最終會出現在第二天的電子報中，有超過 100 萬訂閱者閱讀。很快，我們看到建立的應用程式數量顯著增加，新的人開始加入我們的 Discord 社群！ ### 有機成長（又稱「無所事事」）階段 在 Product Hunt 推出後，我們放鬆了行銷工作，因為其他與 Wasp 相關的任務趕上了團隊。我們必須為即將到來的[發布週#4](https://wasp-lang.dev/blog/2023/10/13/wasp-launch-week-four)做準備，所以 MAGE 最終被擱置了。在我們決定投入更多資源之前，我們也想看看社區如何接受它。 我們發布了更多後續文章，「[它是如何在後台工作的](https://wasp-lang.dev/blog/2023/07/17/how-we-built-gpt-web-app-generator)”和“[MAGE vs. 一般編碼代理](https://wasp-lang.dev/blog/2023/08/01/smol-ai-vs-wasp-ai)”，獲得平均數量牽引力，但沒有爆炸。我們在 Reddit 和 Hackernews 上也沒有什麼成功，感覺社群已經厭倦了所有的人工智慧內容。 儘管如此，使用 MAGE 建立的應用程式數量持續增長（約 200 個應用程式/天），偶爾會出現小規模爆炸。我們無法真正追蹤用戶來自哪裡 - MAGE 似乎是透過封閉社區和時事通訊中的口碑傳播的。 ### YouTube 和 TikTok 影片 - 病毒式傳播（每天 1,300 個應用程式！） 在我們的第 4 週發布週結束後，我們意識到，在近 2 個月的時間裡，在我們付出最小努力的情況下，MAGE 一直在不斷成長。這向我們表明它具有一定的實際價值，因此我們決定對其進行更多投資。  我們決定與該領域的影響者碰碰運氣。我們不想簡單地支付廣告費用，而是希望與真正對我們正在建立的產品感興趣並且想要客觀地審查 MAGE 的人合作。我們發現 [Matthew Berman](https://www.youtube.com/watch?v=KQrGu8cnwvA&t=2s&ab_channel=MatthewBerman) 涵蓋了 LLM 領域從最新模型到工具的所有內容，他將 MAGE 視為非常適合他的觀眾。 該影片在幾週內就準備好了，當它發佈時，觀看次數很快就達到了約 25,000 次。許多觀眾對透過 Web 介面從單一提示中獲取全端程式碼庫的可能性感到興奮，我們看到使用率和開發人員再次嘗試。  大約一周後，我們看到建立的應用程式數量再次大幅增加，但無法弄清楚它來自哪裡。我們做了一些搜尋，在TikTok 上找到了一位開發者@techfren，他製作了[一個關於它的短影片](https://www.tiktok.com/@techfren/video/7288306291733269778)（MAGE 甚至最終無法在就是那個！），一天之內瀏覽量猛增至 20 萬次，並迅速走紅。如今，它的瀏覽量已接近 100 萬。 ## 現實 - 所有這些應用程式會發生什麼？ 儘管 25,000 個建立的應用程式聽起來令人印象深刻，但退後一步並進一步細分是很好的。 與大多數人工智慧驅動的編碼工具一樣，想要建立自己產品的開發人員和非開發人員都對該領域抱持極大的興趣和好奇心。許多人甚至沒有想要建立的具體專案，但他們熱衷於嘗試一下，看看它是如何運作的。此外，由於法學碩士不是確定性的，因此還沒有任何工具能夠完美執行，並且經常會出現需要手動幹預和編碼知識的小錯誤。 雖然我們對此非常明確(https://wasp-lang.dev/blog/2023/07/10/gpt-web-app-generator#what-kind-of-apps-can-i-build-with-it )和其他[挑戰](https://wasp-lang.dev/blog/2023/07/10/gpt-web-app-generator#challenges)GPT驅動的工具面臨，MAGE仍然吸引了一部分的用戶對建置自己的產品感到興奮，但不精通編碼，需要幫助下載、執行和修復應用程式。另一方面，它是一種非常友好且易於參與 Web 開發和編碼的方式。我們不會阻止非編碼人員嘗試，而是盡可能透明地管理期望。 因此，大約 40% 的所有建立的應用程式都會下載並在本地執行。 ## 結論 事實證明，我們對 MAGE 的實驗非常成功，甚至超越了我們最初的預期。除了許多現有的通用編碼代理之外，高度專業化和結構化的方法可以以低廉的價格產生更好、更一致的結果。 此外，開發人員對啟動全端應用程式的簡單方法（其中包含最佳實踐）感到興奮，並且正在積極尋找這樣的解決方案並在彼此之間共享。 我預計人工智慧輔助的 SaaS 新創公司將成為 Web 開發的未來。如果有人可以使用已經為其應用程式定制的資料模型和 CRUD 邏輯來建立他們的應用程式，那麼為什麼有人會使用通用樣板啟動器呢？另一個問題是誰以及如何具體實現這一點，但我預計未來每個主流框架都會有一個。 ## 祝你好運！ 我希望這篇概述對您有所幫助，並讓您了解建立和行銷新的（人工智慧驅動的）開發工具時幕後的情況。請記住，這是我們獨特的經歷，每個故事都是不同的，因此對一切都持保留態度，只選擇對您和您的產品有意義的內容。 我們祝您好運，如果您有任何疑問或想了解 [MAGE](https://usemage.ai/) 和 [Wasp](https://github.com/wasp-lang/wasp)！ --- 原文出處：https://dev.to/wasp/how-we-built-a-gpt-web-app-generator-for-react-nodejs-from-idea-to-25000-apps-in-4-months-1aol
 一週前，我參加了在芝加哥舉行的 Kubecon 2023。我讀了一些部落格並參加了會議上的一些101教程，但仍然對這項技術沒有很好的理解。最糟糕的是會議的最後一天——我叫了優步送我回飯店。我的司機問我“大會是關於什麼的？”我回答說“這是關於 Kubernetes 的”，但經過一番解釋後，很明顯我不知道自己在說什麼。 想像一下，參加完為期 3 天的會議後，無法向您的 Uber 司機描述這項技術。 _摀臉_所以，為了挽回自己，這是我重新想像的與我的優步司機的對話。 # 對話開始 我：想像一下，你是一家繁忙餐廳廚房的廚師。你有一組廚師為你工作，每個人都在準備膳食的不同部分——一組負責開胃菜，一組負責主菜，另一組負責甜點。您的工作就是協調這些廚師，確保準時為顧客提供餐點。你腦子裡有畫面嗎？  司機：明白了。 我：在這個場景中，主廚是 Kubernetes。就像主廚需要管理廚房中所有不同的廚師一樣，Kubernetes 可以幫助管理執行軟體所需的所有不同部分。 Kubernetes 的官方定義是“容器編排工具”，但由於“容器”這個詞在這裡非常抽象，因此您可以用“容器”一詞代替“廚師”。所以 Kubernetes 將是一個「廚師編排工具」。這樣，每次聽到這個詞時，您就可以在腦海中形成廚房的畫面。  司機：好的，目前為止是有道理的。但這些容器是什麼？我不能永遠想像他們是廚師。 我：是的，好點。現在您腦海中已經有了 Kubernetes 廚房的圖片，讓我們從最小到最大，深入了解所有不同的廚房角色如何映射到 Kubernetes 概念。 > 貨櫃 這個難題中最小的部分是容器，它基本上是任何軟體。例如，它可以是託管Web 應用程式的Node.js Web 伺服器，也可以是儲存資料的MongoDB 資料庫容器_（這句話更多是針對閱讀此部落格的工程師而言，我不會對我的Uber 司機說這句話😛 )_。在廚房裡，想像一下您正在為開胃菜提供湯和沙拉。湯就是你的容器。沙拉也將是它自己的容器。 我知道這個定義現在看起來有點武斷，但一旦我在即將推出的元件的上下文中解釋它，它就會更有意義。  > 吊艙 在廚房裡，吊艙就是用來盛湯和沙拉的盤子/托盤。在 Kubernetes 中，Pod 是可以容納 1 個或多個容器的東西。原因是 Pod 內的容器可以相互通訊。 給工程師：舉個例子，假設我的 pod 中有一個用於 Web 伺服器的容器和一個用於資料庫的容器。他們可以透過本地主機相互通訊。 至於用廚房來比喻，我真的想不出什麼。想像香腸派對的惡作劇，你的擬人化湯和沙拉開始互相聊天。但是開胃菜盤上的湯和沙拉無法與餐盤上的牛排和土豆通信，因為它們位於不同的盤子上（也就是說，不同的 Pod 不共享相同的網絡命名空間，因此無法相互通信.)  > 主節點 主廚負責管理和監督整個廚房。這就是我們之前談到的「容器編排」或「廚師編排」的概念。這個主節點將執行的編排工作的一些現實範例如下： > 擴展，即根據 CPU 使用率向上或向下調整正在執行的 pod 數量。在繁忙的廚房中，當顧客需求激增時，廚師可能需要透過準備更多菜餚來擴大營運規模。順便說一句，在此視覺化中需要注意的一件事 - 您可能會想像廚房正在招聘新廚師，但我希望您將其想像得更像是當前的廚師正在被克隆。當發生擴展時，Pod 本質上是在被複製。 > 自動部署，又稱為在 YAML 檔案中定義應用程式的依賴項和執行時間指令，以便它可以基於此組態進行部署。在廚房中，此 YAML 檔案類似於書麵食譜，告訴廚師如何製作菜餚以確保一致性和效率並進行準備。 > 負載平衡，又稱在不同 Pod 之間分配網路流量。在廚房中，負載平衡涉及將任務分配給烹飪站的不同廚師。也許甜點站的鮑勃因舀冰淇淋的請求超載，因此主廚克隆了鮑勃，並讓鮑勃 2.0 從鮑勃 1.0 手中接走了一些冰淇淋訂單。  同樣要注意的是：每個工作節點都有一個稱為「kubelet」的東西。在廚房場景中，「kubelet」類似於每張桌子上的廚師。廚師有很多工作，例如確保食物托盤正確組裝、幫助準備食材以及扔掉殘渣。同樣，「kubelet」的作用包括確保 pod 內的容器正在運作、幫助初始化 pod（例如安裝必要的依賴項）、幫助垃圾收集等等。 為工程師提供的一些額外背景資訊：Kubelet 是一個開源的可執行二進位檔案（又稱為包含 CPU 可以直接執行的機器碼指令的檔案），用 Go 程式語言編寫。  讓我們在這裡停一下。如果您理解到目前為止我所說的所有內容，您就了解了 Kubernetes 架構的基礎知識！如果您不想永遠依賴廚房圖像，我已將下圖中的所有廚房圖紙僅替換為 Kubernetes 術語。  司機：其實，這一切都很有道理。所以我明白了 Kubernetes 是什麼。但我還是不明白為什麼它有用。例如擁有它或學習它有什麼意義？ 我：是的，難題的最後一部分是了解 Kubernetes 的**如何**使用。人類如何與 Kubernetes 互動？ Kubernetes 在科技領域有何相關性/有用性？讓我們回顧一下廚房的類比來解釋更多概念。 - 餐廳/特許經營店的所有者類似於建立應用程式或服務的軟體開發人員。在麥當勞，特許經營權所有者（假設他們的名字是 Francis Cockadoodledoo）希望獲得有關每個麥當勞門市賺多少錢的訊息，並能夠根據需要解僱/僱用員工。為此，Francis Cockadoodledoo 可能會拿起電話打給主廚以獲取資訊並下達命令。在 Kubernetes 中，軟體工程師無法真正拿起電話與他們的 Kubernetes 叢集進行交互，但「主節點」有一個可以呼叫的 API 伺服器，這允許您存取所有任務。例如，工程師可以獲得所有 Pod、節點、服務的訊息，了解執行狀況和指標訊息，並能夠刪除或建立資源。 - 在餐廳吃飯的顧客類似於應用程式或服務的使用者。與麥當勞廚房為我製作巨無霸漢堡類似，Spotify Kubernetes 集群為我提供透過網頁瀏覽器收聽大量音樂的服務。 我已將這些新資訊納入下面的繪圖中。您將看到的實際上與您在谷歌上搜尋“Kubernetes 架構”時看到的圖表非常相似。   當然，我意識到我在解釋中遺漏了一些抽象概念，因為我覺得它們對於形成 Kubernetes 的基本思考模型並不重要。請隨意挖掘更多內容。當我自己深入研究時，我可能會在這個部落格中加入一些我認為有用的資源連結。 # 結論 我之所以選擇這種講故事的方式（透過與 Uber 司機對話的鏡頭來描述技術）是因為我想將 Kubernetes 分解成一種普遍可以理解且平易近人的東西。 感謝您的閱讀！如果您對改進我的寫作（或我糟糕的繪圖）有任何「建設性」回饋，請在評論中留下它們。 請欣賞這張我和我的同事在 #Kubecon 2023 上的照片。順便說一句，我們在那裡推廣我正在開發的產品。 如果您有興趣，您應該檢查一下。這是對過時終端機（命令列）體驗的現代詮釋，讓您成為更好的開發人員。請造訪 https://www.warp.dev/ 以了解更多資訊。  --- 原文出處：https://dev.to/therubberduckiee/explaining-kubernetes-to-my-uber-driver-4f60
您是否正在為您的 Web 應用程式尋找令人驚嘆的 VS Code 擴充功能？那麼這裡是 2023 年最佳 VS Code 擴充的驚人集合。 [**VS Code 擴充**](https://marketplace.visualstudio.com/VSCode) 在現代 Web 開發中至關重要。它們基本上是用於建立現代 Web 應用程式的原始程式碼編輯器。它是一個免費的開源編輯器。此外，它支援大量可用於 Web 應用程式開發的擴充功能。 **[VS Code](https://code.visualstudio.com/)** 擴充功能可讓您為安裝新增偵錯器、語言和工具，以支援您的開發工作流程。其豐富的可擴充性模型使擴充作者可以直接插入 VS Code UI，並透過 VS Code 使用的相同 API 提供功能。 因此，為了幫助您選擇正確的擴展，這些擴展將比它們從您的系統中獲得的資源增加更多的價值，我們列出了當今可用的最佳趨勢擴展的廣泛列表。雖然其中一些是眾所周知且普遍安裝的，但其他擴充功能是使用 Visual Studio Code 的經驗豐富的開發人員強烈推薦的擴充功能。 現在，在處理任何Web 專案時，我們建議您使用這個令人印象深刻的[Bootstrap 儀表板範本](https://themeselection.com/item/category/bootstrap-admin-templates/)，它具有現代且獨特的設計。 [](https://themeselection.com/products/sneat-bootstrapsneat-bootstrapsneat-bootstrapsneat-bootstrapsneat-bootstrapsneat-bootstrap-html-管理模板/) ##### 1. [GITLENS](https://marketplace.visualstudio.com/items?itemName=eamodio.gitlens) [](https://marketplace.visualstudio.com/items?itemName=eamodio.gitlens) GitLens 只是幫助您更好地理解程式碼。快速了解一行或程式碼區塊被更改的人、原因和時間。此外，它還可以讓您輕鬆探索程式碼庫的歷史和演變。 GitLens 增強了 Visual Studio Code 中內建的 Git 功能。它還可以幫助您透過 Git 責任註釋和程式碼鏡頭一目了然地視覺化程式碼作者身份，無縫導航和探索 Git 儲存庫，透過強大的比較命令獲得有價值的見解等等。 下載次數：5,972,117 ##### 2. [PRETTIER – 程式碼格式化程式](https://marketplace.visualstudio.com/items?itemName=esbenp.prettier-vscode) [](https://marketplace.visualstudio.com/items?itemName=esbenp.prettier-vscode) 它是一個固執己見的程式碼格式化程序，透過解析程式碼並使用自己的規則重新列印程式碼（考慮最大行長度）來強制執行一致的樣式，並在必要時包裝程式碼。此外，它支援多種語言。它可以與大多數編輯器整合。 下載次數：7,676,738 ##### 3. [ESLINT](https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint) [](https://themeselection.com/wp-content/uploads/2020/08/12-ESLint-1024x640-2.png) ESLint 靜態分析您的程式碼以快速發現問題。 ESLint 靜態分析您的程式碼以快速發現問題。它內建於大多數文字編輯器中，您可以將 ESLint 作為持續整合管道的一部分執行。 ESLint 修復是語法感知的，因此您不會遇到傳統尋找和取代演算法引入的錯誤。 下載次數：10,236,293 ##### 4. [QUOKKA.JS](https://marketplace.visualstudio.com/items?itemName=WallabyJs.quokka-vscode) [](https://marketplace.visualstudio.com/items?itemName=WallabyJs.quokka-vscode) Quokka.js 是一款用於快速 JavaScript / TypeScript 原型設計的開發人員生產力工具。當您鍵入時，執行時間值會更新並顯示在 IDE 中程式碼旁邊。它使**原型設計、學習和測試** JavaScript / TypeScript **速度極快**。預設不需要配置，只需開啟一個新的 Quokka 檔案並開始試驗 下載次數：754,978 ##### 5. [路徑智慧](https://marketplace.visualstudio.com/items?itemName=christian-kohler.path-intellisense) [](https://marketplace.visualstudio.com/items?itemName=christian-kohler.path-intellisense) 它為檔案名稱加入了智慧感知風格的補全，讓您可以輕鬆輸入長路徑名。如果語句是導入語句，則預設刪除檔案副檔名 下載次數：3,318,156 ##### 6. [路徑自動完成](https://marketplace.visualstudio.com/items?itemName=ionutvmi.path-autocomplete) [](https://marketplace.visualstudio.com/items?itemName=ionutvmi.path-autocomplete) 此擴充功能為 VS Code 提供路徑補全，因此您不必記住那些長路徑。 下載次數：558,868 ##### 7. [VISUAL STUDIO INTELLICODE](https://marketplace.visualstudio.com/items?itemName=VisualStudioExptTeam.vscodeintellicode) [](https://marketplace.visualstudio.com/items?itemName=VisualStudioExptTeam.vscodeintellicode) 它旨在幫助開發人員和程式設計師提供智慧程式碼完成建議。此外，它還預設支援 Python、TypeScript/JavaScript、React 和 Java。 IntelliCode 將您最有可能使用的內容放在完成清單的頂部，從而節省您的時間。 IntelliCode 建議基於 GitHub 上的數千個開源專案，每個專案都有超過 100 顆星。當與程式碼的上下文結合時，完成清單將被自訂以促進常見實踐。 下載次數：6,401,943 ##### 8. [導入成本](https://marketplace.visualstudio.com/items?itemName=wix.vscode-import-cost) [](https://marketplace.visualstudio.com/items?itemName=wix.vscode-import-cost) 此擴充功能將在編輯器中內聯顯示導入包的大小。此擴充功能使用 webpack 和 babili-webpack-plugin 來偵測導入的大小。 下載次數：710,298 ##### 9. [檔案大小](https://marketplace.visualstudio.com/items?itemName=mkxml.vscode-filesize) [](https://marketplace.visualstudio.com/items?itemName=mkxml.vscode-filesize ) 它在編輯器的狀態列中顯示焦點檔案的大小。 下載次數：198,807 **查看最佳的 [Asp.NET Core 管理範本](https://themeselection.com/item/category/asp-net-dashboard/)：** [](https://themeselection.com/item/sneat-aspnet-core-admin-模板/) ##### 10. [即時伺服器](https://marketplace.visualstudio.com/items?itemName=ritwickdey.LiveServer) [](https://marketplace.visualstudio.com/items?itemName=ritwickdey.LiveServer) 點擊即可啟動開發本機伺服器，並透過一些額外功能觀看即時更改 下載次數：6,541,468 ##### 11. [專案經理](https://marketplace.visualstudio.com/items?itemName=alefragnani.project-manager) 它可以幫助您輕鬆存取您的專案，無論它們位於何處。不要再錯過那些重要的專案了。 下載次數：1,090,254 ##### 12. [程式碼拼字檢查器](https://marketplace.visualstudio.com/items?itemName=streetsidesoftware.code-spell-checker) [](https://marketplace.visualstudio.com/items?itemName=streetsidesoftware.code-spell-checker) 適用於多種程式語言的簡單原始碼拼字檢查器。 下載次數：1,596,862 ##### 13. [支架對著色器](https://marketplace.visualstudio.com/items?itemName=CoenraadS.bracket-pair-colorizer) [](https://marketplace.visualstudio.com/items?itemName=CoenraadS.bracket-pair-colorizer) 此擴充允許用顏色來辨識匹配的括號。使用者可以定義要匹配哪些標記以及要使用哪些顏色。 下載次數：1,154,226 ##### 14. [遠端 — SSH](https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-ssh) 遠端 – SSH 擴充功能可讓您使用任何具有 SSH 伺服器的遠端電腦作為開發環境。 下載次數：1,605,734 ##### 15. [REST 用戶端](https://marketplace.visualstudio.com/items?itemName=humao.rest-client) [](https://marketplace.visualstudio.com/items?itemName=humao.rest-client) REST 用戶端可讓您傳送 HTTP 請求並直接在 Visual Studio Code 中查看回應。 下載次數：1,025,700 ##### 16. [JAVASCRIPT (ES6) 程式碼片段](https://marketplace.visualstudio.com/items?itemName=xabikos.JavaScriptSnippets) [](https://marketplace.visualstudio.com/items?itemName=xabikos.JavaScriptSnippets) 此擴充包含 Vs Code 編輯器的 ES6 語法中的 JavaScript 程式碼片段（支援 JavaScript 和 TypeScript）。 下載次數：3,789,793 ##### 17. [程式碼執行器](https://marketplace.visualstudio.com/items?itemName=formulahendry.code-runner) [](https://marketplace.visualstudio.com/items?itemName=formulahendry.code-runner) Code Runner 是多種語言的執行程式碼片段或程式碼檔案。透過檔案總管的上下文功能表執行目前活動文字編輯器的程式碼檔案非常有用。此外，您還可以在文字編輯器中執行選定的程式碼片段。它透過在整合終端中執行程式碼來支援 REPL 下載次數：4,549,546 --- 建議使用[Next js Dashboard Template](https://themeselection.com/item/category/next-js-admin-template/)，因為它附帶預製元件，您可以直接使用，無需任何額外的工作。 例如，您必須查看 [**Sneat MUI React Next js 管理範本**](https://themeselection.com/item/sneat-mui-react-nextjs-admin-template/)。 [](https://themeselection.com/item/sneat-mui-react-nextjs-管理範本/) [**React 管理儀表板**](https://themeselection.com/item/category/react-admin-templates/) 具有 6 種獨特的佈局：預設、邊框、半暗和暗😎 --- ##### 18. [DOCKER](https://marketplace.visualstudio.com/items?itemName=ms-azuretools.vscode-docker) [](https://marketplace.visualstudio.com/items?itemName=ms-azuretools.vscode-泊塢窗戶) Docker 擴充功能可讓您輕鬆地從 Visual Studio Code 建置、管理和部署容器化應用程式。它還提供容器內 Node.js、Python 和 .NET Core 的一鍵偵錯。此擴充功能可辨識使用最受歡迎的開發語言（C#、Node.js、Python、Ruby、Go 和 Java）的工作區，並相應地自訂生成的 Docker 檔案。 Docker 擴充功能為 VS Code 提供了 Docker 視圖。 Docker 檢視可讓您檢查和管理 Docker 資產：容器、映像、磁碟區、網路和容器登錄檔 下載次數：5,136,014 ##### 19. [更好的評論](https://marketplace.visualstudio.com/items?itemName=aaron-bond.better-comments) [](https://marketplace.visualstudio.com/items?itemName=aaron-bond.better-comments) Better Comments 擴充功能將幫助您在程式碼中建立更人性化的註解。您將能夠將註釋分類為警報、查詢、待辦事項、突出顯示等。此外，還可以對註釋掉的程式碼進行樣式設置，以明確該程式碼不應該在那裡，並且您想要的任何其他註釋樣式都可以在設定中指定。 下載次數：960,927 ##### 20. [Chrome 偵錯器](https://marketplace.visualstudio.com/items?itemName=msjsdiag.debugger-for-chrome) [](https://marketplace.visualstudio.com/items?itemName=msjsdiag.debugger-for-chrome) 偵錯器是 VS Code 擴展，用於在 Google Chrome 瀏覽器或支援 Chrome DevTools 協議的其他目標中偵錯 JavaScript 程式碼。它有助於除錯 eval 腳本、腳本標籤、動態加入的腳本以及設定斷點，包括在啟用來源映射時在來源檔案中設定斷點。 下載次數：1,617,311 ##### 21. [MARKDOWN 多合一](https://marketplace.visualstudio.com/items?itemName=yzhang.markdown-all-in-one) [](https://marketplace.visualstudio.com/items?itemName=yzhang.markdown-all-in-one) Markdown 所需的一切（鍵盤快速鍵、目錄、自動預覽等）。它支援以下 Markdown 語法： - [CommonMark](https://spec.commonmark.org/) - [表格](https://help.github.com/articles/organizing-information-with-tables/)、[刪除線](https://help.github.com/articles/basic-writing-and-formatting-syntax/#styling-text)和[任務清單](https://docs.github.com/en/github/writing-on-github/basic-writing-and-formatting-syntax#task-lists)（來自GitHub 風格的 Markdown） - [數學支援](https://github.com/waylonflinn/markdown-it-katex#syntax)（來自 KaTeX） - [前題](https://github.com/ParkSB/markdown-it-front-matter#valid-front-matter) 下載次數：5,136,014 ##### 22. [搜尋節點模組](https://marketplace.visualstudio.com/items?itemName=jasonnutter.search-node-modules) [](https://marketplace.visualstudio.com/items?itemName=jasonnutter.search-node-modules) 搜尋節點模組是 VS Code 的簡單插件，可讓您快速導航專案的 node_modules 目錄中的檔案。 下載次數：571,040 ##### 23. [設定同步](https://marketplace.visualstudio.com/items?itemName=Shan.code-settings-sync) 透過設定同步，您可以使用簡單的 Gist 跨電腦同步設定、片段、主題、檔案圖示、鍵綁定、工作區和擴充。它支援 GitHub Enterprise、帶有 @sync 關鍵字的編譯指示：host、os 和 env。一鍵上傳和下載很簡單。它允許您在電腦之間同步任何檔案。 下載次數：1,870,161 ##### 24. [NPM](https://marketplace.visualstudio.com/items?itemName=eg2.vscode-npm-script) 此擴充功能支援執行 package.json 檔案中定義的 npm 腳本，並根據 package.json 中定義的依賴項驗證已安裝的模組。這些腳本可以在整合終端或輸出視窗中執行。 下載次數：2,748,322 #### 結論： 嗯，到 2023 年，Visual Studio Code 的月活躍用戶數為 490 萬。毫無疑問，它是目前最好的程式碼編輯器。最好的功能之一是 [**Market Place**](https://marketplace.visualstudio.com/vscode) 提供大量擴展，可以根據您的需求準確定制它，並幫助您編寫高品質的程式碼。 在本文中，我們將向使用 CSS、HTML、JavaScript 以及 Angular、ReactJS 和 VueJS 等框架的前端工程師推薦這些 VS Code 擴充功能。 我們 [ThemeSelection](https://themeselection.com/) 使用其中一些擴充功能來建立現代且乾淨的 Bootstrap 管理範本。 [Sneat Bootstrap 5 HTML 管理範本](https://themeselection.com/products/sneat-bootstrap-html-admin-template/) [Chameleon 免費 Bootstrap 管理範本](https://themeselection.com/products/chameleon-admin-free-bootstrap-dashboard-template/) 您也可以檢查使用這些擴充功能製作的一些[引導管理範本](https://themeselection.com/products/category/bootstrap-admin-templates/)。 我們想說這個集合不是完整的，擴充不一定是最好的，但我們希望它可以幫助您選擇最好的工具來幫助您編寫高品質的程式碼並成為最好的 Web 開發人員。 如果您認為此列表缺少擴展，請隨時提出建議並透過在評論部分中加入您最喜歡的擴充功能來擴展它。 --- 原文出處：https://dev.to/themeselection/vs-codes-every-developers-should-use-in-2020-2fa3
原文出處：https://dev.to/avinashvagh/react-ecosystem-in-2024-418k 2024 年，React 將慶祝其成立 11 週年，值得期待 React 生態系統中令人興奮的發展。在本部落格中，我們將基於 2023 年發生的情況以及來年的預期，探討生態系統的各個面向。 ## 1. 路由 路由一直是Web開發的關鍵部分，在2023年，我們看到了各種各樣的路由解決方案。讓我們看看2024年會發生什麼： - **React Router：** React Router 仍然是 React 應用程式中處理路由的基本選擇。憑藉其廣泛的文檔和活躍的社區，它仍然是應用程式中聲明式路由的可靠選擇。 - **React Query：** Tanstack 的 React Query 在 2023 年流行的基礎上，旨在增強資料擷取和狀態管理。它簡化了 React 應用程式中管理、快取和同步資料的過程。 - **Next.js：** Next.js 是一個建立在 React 之上的框架，預計將保持其作為具有靈活路由選項的伺服器渲染 React 應用程式首選的地位。它的官方文件是 Next.js 應用程式中路由的寶貴資源。 2024 年，React 充滿活力的生態系統將繼續蓬勃發展，為開發人員提供豐富的工具和函式庫。請繼續關注 React 世界的更多更新和進步。 ## 2. 客戶端狀態管理 客戶端狀態管理是現代 Web 開發的一個重要方面，可以在前端應用程式中實現高效的資料處理。 Redux Toolkit 和 Zustand 是兩種流行的用戶端狀態管理解決方案。以下是兩者的簡要概述： ### 1. **Redux 工具包** - **網址：** [Redux 工具包](https://redux-toolkit.js.org/) Redux Toolkit 是一個建立在 Redux 之上的綜合狀態管理函式庫，Redux 是 React 應用程式中成熟的狀態管理函式庫。它提供了一組工具和最佳實踐，以可預測且高效的方式簡化狀態管理流程。 Redux Toolkit 的結構化方法（包括 actions、reducer 和 store）非常適合複雜的大型專案。它提倡採用集中式和聲明式的狀態管理方法。 ### 2. **條件** - **示範：** [狀態示範](https://state-demo.pmnd.rs/) Zustand 是一個輕量級且靈活的狀態管理庫，專為小型專案或喜歡更簡單解決方案的開發人員而設計。它簡化了狀態管理，無需複雜的設定和概念。 Zustand 以其簡單性和易用性而聞名，這使其成為小型應用程式和重視更輕量級方法的人的絕佳選擇。 在 Redux Toolkit 和 Zustand 之間進行選擇時，請考慮專案的複雜性以及您對 Redux 的熟悉程度。 Redux Toolkit 是大型、結構化應用程式的絕佳選擇，而 Zustand 則非常適合需要快速、簡單的狀態管理解決方案的小型專案。 ## 3.伺服器狀態管理 伺服器狀態管理是 Web 開發的一個重要方面，特別是對於跨客戶端和伺服器的應用程式。以下是兩個可以幫助您有效管理伺服器狀態的關鍵庫： ### 1. **TanStack 查詢** - **文件：** [TanStack 查詢](https://tanstack.com/query/latest) TanStack Query 是一個強大且靈活的狀態管理庫，用於處理應用程式中的伺服器狀態。它允許您輕鬆地從伺服器獲取、快取和更新資料。該程式庫提供自動快取、高效資料擷取以及自訂 API 端點的功能等功能。對於需要即時資料更新和高效資料同步的應用程式來說，它是管理伺服器狀態的絕佳選擇。 ### 2. **Redux 工具包 - RTK 查詢** - **文件：** [Redux 工具包 - RTK 查詢](https://redux-toolkit.js.org/rtk-query/overview) RTK Query 是 Redux Toolkit 生態系統的一部分，提供管理伺服器狀態的全面解決方案。它以可預測且高效的方式簡化了發出 API 請求、快取資料和更新狀態的過程。 RTK Query 與 Redux 無縫集成，對於使用 Redux 進行狀態管理的應用程式來說是一個絕佳的選擇。它提倡最佳實踐並提供結構化方法來處理伺服器狀態。 選擇伺服器狀態管理庫時，請考慮您的專案需求、資料擷取需求的複雜性以及您對 Redux 的熟悉程度（如果您選擇 RTK 查詢）。這兩個庫都提供了用於管理應用程式中的伺服器狀態的強大解決方案。 ## 4. 表單處理 表單處理是建立 Web 應用程式的關鍵部分，尤其是在 React 中。用於表單處理的兩個流行的程式庫是 Formik 和 React Hook Form。概述如下： ### 1. **甲酸** - **網址：** [Formik](https://formik.org/) Formik 是在 React 中建立表單最常用的函式庫。它提供了一組實用程式和元件，可以輕鬆管理表單狀態、驗證和提交。雖然它是一個流行的選擇，但截至最新消息，Formik 並未得到積極維護，這可能會影響其與未來 React 更新和不斷發展的最佳實踐的兼容性。使用 Formik 的唯一缺點是它不被維護。 Formik 文件/網站甚至不鼓勵在新專案中使用 Formik。 ### 2. **反應鉤子形式** - **網址：** [React Hook 表單](https://www.react-hook-form.com/) React Hook Form 是一個現代表單函式庫，它利用 React hooks 來有效地處理表單狀態和驗證。它得到積極維護，並提供輕量級且直觀的 API。 React Hook Form 以其效能和靈活性而聞名，使其成為在 React 應用程式中處理表單的絕佳選擇。 在 Formik 和 React Hook Form 之間進行選擇時，請考慮維護和專案的特定要求等因素。根據最新消息，React Hook Form 因其積極的開發和現代的表單處理方法而成為推薦選擇。 ## 5. 測試 測試是軟體開發過程的關鍵部分，有各種工具和程式庫可協助開發人員編寫有效的測試。以下是一些用於測試的資源和工具： ### 1. **ViTest** - **網址：** [ViTest](https://vitest.dev/) ViTest 是一個由 vite 支援的單元測試框架。它提供了一種為 React、Vue、Svelte 等應用程式編寫單元測試、元件測試和端到端測試的簡單方法。如果您使用 React，ViTest 可以透過全面的測試來幫助您確保程式碼的可靠性和品質。 ### 2. **React 測試函式庫** - **文件：** [React 測試庫](https://testing-library.com/docs/react-testing-library/intro/) React 測試庫是 React 應用程式的熱門測試庫。它專注於編寫模擬使用者互動的測試，幫助您確保元件從使用者的角度按照預期運行。該程式庫鼓勵測試 React 元件的最佳實踐。 ### 3. **劇作家** - **網址：** [劇作家](https://playwright.dev/) Playwright 是一個端對端測試框架，支援多種瀏覽器，包括 Chromium、Firefox 和 WebKit。它為瀏覽器自動化提供了統一的 API，並允許您編寫測試來驗證 Web 應用程式在不同瀏覽器上的功能。 Playwright 是確保跨瀏覽器相容性的強大工具。 這些資源和工具可以幫助您涵蓋測試的各個方面，從單元測試到端到端測試，具體取決於您的專案需求和您正在使用的技術。請務必進一步探索它們，以選擇最適合您要求的一種。 ## 6. 樣式 當談到 Web 開發中的樣式時，有幾種流行的工具和庫可供選擇。以下是三個值得注意的選項： ### 1. **Tailwind CSS** - **網址：** [Tailwind CSS](https://tailwindcss.com/) Tailwind CSS 是一個實用程式優先的 CSS 框架，它提供了一組預先建立的原子 CSS 類別來設計您的 Web 應用程式。它旨在透過在 HTML 中編寫實用程式類別來幫助您快速創建響應式且高度可自訂的設計。 Tailwind CSS 以其靈活性而聞名，對於想要實用程式驅動的樣式設計方法的開發人員來說是一個絕佳的選擇。 ### 2. **樣式元件** - **網址：** [樣式組件](https://styled-components.com/) Styled Components 是一個 CSS-in-JS 函式庫，用於設計 React 元件的樣式。它允許您透過使用標記模板文字定義樣式元件來直接在 JavaScript 檔案中編寫 CSS。這種方法使您能夠將樣式封裝在元件中，從而更輕鬆地管理和維護 CSS。樣式化組件在 React 生態系統中特別受歡迎。 ### 3. **情感** - **文檔：** [情緒](https://emotion.sh/docs/introduction) Emotion 是另一個 CSS-in-JS 函式庫，重點是效能和靈活性。它提供了多種方法來定義樣式並將其應用到 React 元件，包括字串和物件樣式。 Emotion 以其可預測性和適合使用 JavaScript 編寫不同 CSS 樣式而聞名。它提供了一種與框架無關的方法，使其適用於各種 JavaScript 框架。 這些工具中的每一個都有自己的優勢，並且適合不同的用例。 Tailwind CSS 擅長使用實用程式類別進行快速 UI 開發。 Styled Components 和 Emotion 是 React 應用程式中元件級樣式的理想選擇。您的選擇將取決於您的專案要求和個人喜好。 ## 7.UI元件庫 用於在 2023 年建立使用者介面的 UI 元件庫，並將在 2024 年繼續使用。 ### 1. **材質-UI** - **網址：** [Material-UI](https://mui.com/) Material-UI 是一個受歡迎且維護良好的 React UI 框架。它基於 Google 的 Material Design 指南，並提供廣泛的元件來創建現代且具有視覺吸引力的使用者介面。 ### 2. **曼汀** - **網址：** [Mantine](https://mantine.dev/) Mantine 是一個現代 React 元件庫，專注於提供高品質的元件和鉤子。它提供了各種 UI 元素和工具來簡化您的開發流程。 ### 3. **螞蟻設計** - **網址：** [Ant Design](https://ant.design/) Ant Design 是一個用於建立企業級 React 應用程式的綜合設計系統和元件庫。它以其豐富的組件和強調自然清晰的設計理念而聞名。 ### 4. **脈輪使用者介面** - **網址：** [Chakra UI](https://chakra-ui.com/) Chakra UI 是在 React 中建立可存取且高度可自訂的使用者介面的熱門選擇。它提供了一組可組合組件和一個樣式道具系統，用於靈活的樣式設定。 ### 5. **無頭 UI（Tailwind CSS 框架）** - **網址：** [無頭 UI](https://headlessui.com/) Headless UI 是一組完全可存取、無樣式的 UI 元件，旨在與 Tailwind CSS 無縫協作。它允許您建立可存取的介面，同時保留對樣式的完全控制。 ### 6. **DaisyUI（Tailwind CSS 框架）** - **網址：** [DaisyUI](https://daisyui.com/) DaisyUI 是 Tailwind CSS 的擴展，它帶來了額外的元件和實用程式來增強您的開發體驗。如果您已經在使用 Tailwind CSS，它會特別有用。 ### 7.**Shadcn UI（Tailwind CSS 框架）** - **網址：** [Shadcn UI](https://ui.shadcn.com/) Shadcn UI 是另一個基於 Tailwind CSS 的 UI 元件庫，它提供了一系列元件和實用程序，用於快速有效地建立 Web 應用程式。 這些程式庫提供了各種元件和工具，可協助您在 React 應用程式中建立響應靈敏且具有視覺吸引力的使用者介面。庫的選擇取決於您的項目的要求和您的個人喜好。 ## 8. 動畫 如果您對 React 動畫庫感興趣，兩個流行的選擇是： 1. **React Spring** - 您可以在 React Spring 的官方網站 [react-spring.dev](https://www.react-spring.dev/) 上找到有關 React Spring 的更多資訊和文件。 React Spring 是一個功能豐富的動畫庫，它利用基於實體的動畫在 React 中創建流暢的互動式動畫。 2. **Framer Motion** - 另一個出色的選擇是 Framer Motion，您可以在 [framer.com/motion](https://www.framer.com/motion/) 進一步探索它。 Framer Motion 因是專為 React 設計的功能豐富的動畫庫而聞名。它提供了靈活性，非常適合在 React 應用程式中創建流暢的動畫。 這兩個庫都有其優點，它們之間的選擇可能取決於您的特定項目要求和個人喜好。 React Spring 提供基於實體的動畫和豐富的功能集，而 Framer Motion 以其易用性和靈活性而聞名。最好對兩者進行探索，看看哪一個更符合您的動畫需求。 請隨意參考各自的網站以獲取詳細的文件和範例，以便做出明智的選擇。 ## 9. 資料視覺化 當涉及 React 中的資料視覺化時，有幾個函式庫可以幫助您建立互動式且資訊豐富的圖表和圖形。以下是三個流行的選項： 1. **Victory** - 您可以在 [formidable.com/open-source/victory/docs](https://formidable.com/open-source/victory/docs) 中瀏覽 Victory 的文檔 Victory 是一個強大的 React 資料視覺化函式庫，提供廣泛的圖表類型和自訂選項。它旨在輕鬆創建具有視覺吸引力的互動式資料視覺化。 2. **React Chartjs 2** - 造訪 [react-chartjs-2.js.org](https://react-chartjs-2.js.org/) 以了解更多資訊。 React Chartjs 2 是 Chart.js（一個流行的 JavaScript 圖表庫）的 React 包裝器。它提供了一種將 Chart.js 整合到 React 應用程式中的簡單方法，可讓您使用 Chart.js 的底層功能建立各種圖表和圖形。 3. **Recharts** - 有關Recharts的詳細信息，您可以參考[recharts.org/en-US/](https://recharts.org/en-US/)。 Recharts 是一個使用 React 建立的可組合圖表庫。它提供了一個簡單而靈活的 API 來創建各種類型的圖表，非常適合將資料視覺化添加到您的 React 專案中。 每個庫都有自己的一組功能和優點，因此選擇將取決於您的特定項目要求和個人喜好。您可以存取他們各自的文件以了解更多資訊並開始使用 React 中的資料視覺化。 ## 10. 表 如果您正在尋找有關 React 中表格的信息，可以在 [tanstack.com/table/v8](https://tanstack.com/table/v8) 上瀏覽版本 8 的 TanStack Table 文件。 TanStack Table 是一個無頭 UI 庫，可讓您在 TS/JS、React、Vue、Solid 和 Svelte 等各種框架中建立強大的表格和資料網格，同時保留對標記和樣式的控制。該文件將為您提供有關如何使用 TanStack Table 和配置表的詳細信息，包括選項和 API 屬性。 無論您使用 TypeScript 還是 JavaScript 以及使用受支援的框架之一，TanStack Table v8 都提供了一種靈活的解決方案，用於在 Web 應用程式中建立表格和資料網格。該文件將引導您完成整個過程，並幫助您充分利用該庫來滿足您的特定需求。 ## 11. 國際化（i18n） 當涉及 React 應用程式中的國際化 (i18n) 時，有多個程式庫和工具可協助您管理翻譯和在地化。 React 中 i18n 的兩個突出選項是： 1. **i18next** - 您可以在 [react.i18next.com](https://react.i18next.com/) 找到使用 i18next 的文件和資源。 i18next 是一個流行的 JavaScript 國際化框架，包括 React。它提供了處理翻譯、格式化等的全面解決方案。 2. **React-Intl (Format.js)** - React-Intl 的文檔是 Format.js 專案的一部分，可以在 [formatjs.io/docs/react-intl](https: //formatjs.io/ docs/react-intl）。 React-Intl 是一個函式庫，提供用於在 React 應用程式中格式化和處理國際化文字的工具。 這兩個函式庫都有活躍的社群、豐富的文檔，並且在 React 生態系統中廣泛使用。您可以探索這些資源，以確定哪一個最適合您的 React 應用程式國際化需求。 ## 12. 開發工具 DevTools 對於偵錯和改進 Web 應用程式的開發工作流程至關重要。以下是一些流行的 React 開發工具和相關函式庫： 1. **React 開發者工具** - 該工具可作為 Chrome 擴充功能使用。它允許您檢查 React 元件層次結構、查看元件的狀態和 props，甚至更改元件的狀態以進行測試。您可以從 [Chrome Web Store](https://chrome.google.com/webstore/detail/react-developer-tools/fmkadmapgofadopljbjfkapdkoienihi) 安裝它。 2. **Redux DevTools** - Redux DevTools 是另一個 Chrome 擴展，可以增強 Redux 開發工作流程。它提供了對 Redux 儲存的深入了解，讓您可以檢查操作和狀態變更、倒回和重播操作等。您可以從 [Chrome Web Store](https://chrome.google.com/webstore/detail/redux-devtools/lmhkpmbekcpmknklioeibfkpmmfibljd) 安裝它。 3. **Testing Playground** - Test Playground 是一個 Chrome 擴展，可以簡化 React 元件的測試。它提供了一個用於試驗組件及其道具的視覺環境。您可以在 [Chrome 線上應用程式商店](https://chrome.google.com/webstore/detail/testing-playground/hejbmebodbijjdhflfknehhcgaklhano) 上找到它。 4. **React Hook Form DevTools** - 對於使用 React Hook Form 的用戶，可以使用 DevTools 來協助偵錯表單行為。您可以在 [React Hook Form 網站](https://www.react-hook-form.com/dev-tools/) 上存取它們。 5. **TanStack Query DevTools** - TanStack Query 是 React 的資料擷取庫，它提供用於偵錯和檢查查詢和突變的 DevTools。您可以參考[官方文件](https://tanstack.com/query/v4/docs/react/devtools)以了解更多資訊。 這些開發工具可協助開發人員簡化開發和偵錯流程，從而更輕鬆地建置和維護 Web 應用程式。 ## 13. 文檔 文件對於任何軟體專案都至關重要。以下是用於建立文件的兩種流行工具： 1. **Docusaurus** - Docusaurus 是一種廣泛採用的用於建立文件網站的工具。它是一個開源框架，為創建和維護文件提供了乾淨且用戶友好的介面。 Docusaurus 具有高度可自訂性，許多專案和組織都使用它來建立文件網站。您可以在 Docusaurus 的[官方網站](https://docusaurus.io/)上了解更多並開始使用 Docusaurus。 2. **Nextra** - Nextra 是建立文件網站的另一種選擇。雖然 Nextra 可能不像 Docusaurus 那樣出名，但它提供了一種現代且簡約的方法來建立文件。它的設計是輕量級且用戶友好的，對於那些喜歡簡單乾淨的文檔風格的人來說是一個不錯的選擇。您可以在 Nextra 的[官方網站](https://nextra.site/) 上探索有關 Nextra 的更多資訊。 Docusaurus 和 Nextra 都有各自的優勢，它們之間的選擇取決於您的特定需求和偏好。您可以訪問他們各自的網站以了解更多資訊、訪問文件並確定哪一個最適合您的專案。 ## 14. 元件開發環境 元件開發環境 (Dev Env) 對於有效建置和測試 UI 元件至關重要。用於為 UI 元件創建開發環境的廣泛使用的工具之一是 [Storybook](https://storybook.js.org/)。 Storybook 是業界標準的元件瀏覽器，可讓開發人員獨立開發 UI 元件。當處理設計系統或元件庫時，它特別有價值。以下是 Storybook 如何協助創建 UI 元件的開發環境： 1. **目錄 UI 元件**：Storybook 提供了用於編目和顯示 UI 元件的專用環境。開發人員可以單獨查看每個組件的外觀和行為。 2. **將元件變體儲存為故事**：在 Storybook 中，開發人員可以為每個元件建立「故事」。這些故事代表組件的不同變體或用例。這是記錄和展示組件行為的絕佳方式。 3. **開發人員體驗工具**：Storybook 提供了一系列開發人員體驗工具，包括熱模組重新加載，以簡化組件開發流程。 透過使用 Storybook，您可以有效率地開發、測試和記錄 UI 元件。它在設計系統時特別有用，因為它允許您專注於單個組件及其互動。您可以在 Storybook 的[官方網站](https://storybook.js.org/) 上了解更多並開始使用。 它是一種多功能工具，可以根據專案的特定需求進行定制，使其成為組件開發環境的寶貴資產。 ## 15. 類型檢查 TypeScript 是 Microsoft 開發的一種程式語言，透過新增靜態類型來擴充 JavaScript。它提供全面的類型檢查和強大的類型系統，以捕獲開發過程中的錯誤並提高程式碼品質。以下是 TypeScript 中類型檢查的一些關鍵方面： 1. **靜態型別系統**：TypeScript 引進了靜態型別系統，這表示在編譯時檢查類型。這有助於在執行程式碼之前識別與類型相關的錯誤。 2. **型別註解**：開發者可以使用型別註解來指定變數、函數參數和傳回值的型別。這提供了清晰度並確保變數的使用一致。 3. **推斷**：TypeScript 可以根據指派給變數的值推斷類型。這減少了對顯式類型註解的需求並提高了程式碼簡潔性。 4. **類型聲明**：TypeScript支援自訂類型的聲明，例如介面和枚舉，以定義資料結構的形狀並增強程式碼的可維護性。 5. **類型相容性**：TypeScript 有一個檢查類型相容性的系統，這確保你不能將不相容的類型指派給變數。這有助於防止常見的運行時錯誤。 6. **對 JavaScript 文件進行類型檢查**：TypeScript 還可以檢查 JavaScript 文件，讓您可以逐步將 TypeScript 引入現有的 JavaScript 專案中。 透過將 TypeScript 合併到您的開發工作流程中，您可以從這些類型檢查功能中受益，從而儘早發現錯誤、增強程式碼可維護性並提高程式碼的整體品質。您可以在[官方 TypeScript 網站](https://www.typescriptlang.org/) 上了解有關 TypeScript 及其類型檢查功能的更多資訊。 ## 16. 行動應用程式 如果您想要開發行動應用程序，特別是 Android 和 iOS 的行動應用程序，React Native 是一個值得考慮的有價值的框架。 React Native 是一個開源框架，可讓您使用 JavaScript 和 React 建立行動應用程式。這就是 React Native 成為行動應用程式開發的熱門選擇的原因： 1. **跨平台開發**：React Native 使您能夠使用單一程式碼庫開發適用於 Android 和 iOS 的應用程式。這種方法可以顯著減少開發時間和工作量。 2. **可重複使用元件**：您可以建立跨平台工作的可重複使用 UI 元件，幫助您在應用程式中保持一致的外觀和感覺。 3. **熱重載**：React Native 支援熱重載，這意味著您可以立即看到程式碼變更的結果，而無需重新編譯整個應用程式。這加快了開發速度。 4. **大型社區**：React Native 擁有龐大且活躍的社區，這意味著您可以找到豐富的資源、庫以及常見問題的解決方案。 5. **本機效能**：React Native 應用程式具有接近本機的效能，因為它們使用本機元件進行渲染。這確保了流暢的用戶體驗。 6. **成本效益**：透過在 Android 和 iOS 之間共用程式碼庫，您可以降低開發成本。 要開始使用 React Native，您可以造訪官方網站 [React Native](https://reactnative.dev/) 以取得全面的文件、教學和資源。無論您是初學者還是經驗豐富的開發人員，React Native 都是行動應用程式開發的強大選擇。 ## 17. 為 React 開發人員提供的很棒的函式庫 很高興看到您對 React 開發人員的優秀庫感興趣。以下是一些非常有用的程式庫，可用於 React 開發中的各種功能： ### 1. **用於拖放功能的 DND 套件** - 網址：[免打擾套件](https://dndkit.com/) DND Kit 是一個強大的庫，用於為 React 應用程式添加拖放功能。它提供了一種簡單且可自訂的方法來實現拖放功能，以便在使用者介面中重新排序、重新排列或組織元素。 ### 2. **React Dropzone 用於檔案上傳** - 網址：[React Dropzone](https://react-dropzone.js.org/) React Dropzone 是一個流行的程式庫，用於在 React 應用程式中處理檔案上傳。它提供了一個用戶友好且高度可自訂的 dropzone 元件，簡化了上傳文件的過程，使其成為任何需要文件上傳的項目的有價值的補充。 ### 3. **Firebase 用於身份驗證** - 網址：[Firebase](https://firebase.google.com/) Firebase 由 Google 開發，是一個用於建立 Web 和行動應用程式的綜合平台。它提供廣泛的服務，包括用戶身份驗證。透過 Firebase 驗證，您可以輕鬆地將安全的使用者註冊和登入功能新增到您的 React 應用程式中。 ### 4. **Supabase 用於身份驗證** - 網址：[Supabase](https://supabase.com/) Supabase 是 Firebase 的開源替代品，提供一套用於建立應用程式的服務，包括身份驗證。它提供了可以無縫整合到您的 React 專案中的用戶身份驗證功能。 這些程式庫涵蓋了 React 開發的基本面，包括拖放功能、檔案上傳和使用者身份驗證。根據您的專案要求，您可以利用這些程式庫來增強您的 React 應用程式。 **免責聲明：**“本文是在人工智慧的幫助下創建的” --- 喜歡這個部落格嗎？ **[在 X 上關注我](https://twitter.com/avinashvagh)** 我非常活躍，在 Dev.to 上關注我，不錯過更新。 **聯絡人** — [[email protected]](mailto:[email protected]) 與我一起工作。 --- 訂閱**[遠端檔案通訊](https://remoteprofile.beehiiv.com/)**，隨時了解遠距工作趨勢和工作機會。 {% 嵌入 https://x.com/remoteprofile/status/1698215946463359023?s=20 %} 加入 1K+ 遠端求職者，他們正在世界任何地方在美國尋找遠端工作，所有工作機會面向全球受眾（在任何地方工作），**[立即訂閱](https://remoteprofile.beehiiv.com/訂閱）* * 每日在您的收件匣中獲取機會！
原文出處：https://dev.to/nikl/json-is-slower-here-are-its-4-faster-alternatives-2g30 --- ## 介紹 在快節奏的 Web 開發世界中，速度和反應能力是不容妥協的。您的用戶希望即時存取資訊、快速互動和無縫體驗。 JSON 是 JavaScript 物件表示法的縮寫，一直是 Web 開發中資料交換的忠實夥伴，但它會減慢您的應用程式速度嗎？讓我們深入探討 JSON 的世界，探索其潛在瓶頸，並發現更快的替代方案和優化技術，讓您的應用程式像獵豹一樣衝刺。 --- 您可能還想查看本教學：[使用 Golang 建立即時通知系統 - 逐步通知系統設計指南](https://dev.to/nikl/using-golang-to-build -即時通知系統逐步通知系統設計指南-50l7) --- ### 什麼是 JSON 以及為什麼您應該關心？ 在開始 JSON 優化之旅之前，讓我們先了解 JSON 是什麼以及它為何重要。 JSON 是將應用程式中的資料黏合在一起的黏合劑。它是伺服器和客戶端之間通訊資料的語言，也是資料儲存在資料庫和設定檔中的格式。從本質上講，JSON 在現代 Web 開發中發揮關鍵作用。 了解 JSON 及其細微差別不僅是任何 Web 開發人員的基本技能，而且對於優化應用程式也至關重要。隨著我們深入研究此博客，您將發現為什麼 JSON 在性能方面可以成為一把雙刃劍，以及這些知識如何對您的開發之旅產生重大影響。 ## JSON 的受歡迎程度以及人們使用它的原因 JSON 在 Web 開發領域的受歡迎程度怎麼強調都不為過。由於以下幾個令人信服的原因，它已成為資料交換的事實上的標準： 1. **人類可讀格式**：JSON 使用簡單的、基於文字的結構，開發人員和非開發人員都可以輕鬆閱讀和理解。這種人類可讀的格式增強了協作並簡化了調試。 ``` // Inefficient { "customer_name_with_spaces": "John Doe" } // Efficient { "customerName": "John Doe" } ``` 2. **與語言無關**：JSON 不依賴任何特定的程式語言。它是一種通用資料格式，幾乎可以由所有現代程式語言解析和生成，因此具有高度通用性。 3. **資料結構一致性**：JSON 使用鍵值對、陣列和巢狀物件強制資料結構一致。這種一致性使其在各種程式設計場景中都可預測且易於使用。 ``` // Inefficient { "order": { "items": { "item1": "Product A", "item2": "Product B" } } } // Efficient { "orderItems": ["Product A", "Product B"] } ``` 4. **瀏覽器支援**：Web 瀏覽器原生支援 JSON，允許 Web 應用程式與伺服器無縫通訊。這種原生支援對其在 Web 開發中的採用做出了重大貢獻。 5. **JSON API**：許多Web服務和API預設提供JSON格式的資料。這進一步鞏固了 JSON 作為 Web 開發中資料交換首選的角色。 6. **JSON Schema**：開發人員可以使用 JSON Schema 來定義和驗證 JSON 資料的結構，為其應用程式添加額外的清晰度和可靠性。 有鑑於這些優勢，全球開發人員依賴 JSON 來滿足資料交換需求也就不足為奇了。然而，當我們更深入地探索部落格時，我們將發現與 JSON 相關的潛在性能挑戰以及如何有效解決這些挑戰。 ## 對速度的極品 在當今快節奏的數位環境中，應用程式速度和回應能力是不容談判的。用戶期望跨網路和行動應用程式即時存取資訊、快速互動以及無縫體驗。這種對速度的需求是由以下幾個因素所驅動的： ### 用戶期望 使用者已經習慣了數位互動中閃電般的快速回應。他們不想等待網頁加載或應用程式回應。即使是幾秒鐘的延遲也會導致沮喪和放棄。 ### 競爭優勢 速度可以成為顯著的競爭優勢。快速回應的應用程式往往比反應遲緩的應用程式更有效地吸引和留住用戶。 ### 搜尋引擎排名 像 Google 這樣的搜尋引擎將頁面速度視為排名因素。載入速度更快的網站往往在搜尋結果中排名更高，從而提高可見度和流量。 ### 轉換率 尤其是電子商務網站，他們敏銳地意識到速度對轉換率的影響。更快的網站可以帶來更高的轉換率，從而增加收入。 ### 移動效能 隨著行動裝置的普及，對速度的需求變得更加重要。行動用戶的頻寬和處理能力通常有限，因此需要快速的應用程式效能。 ### JSON 會減慢我們的應用程式速度嗎？ 現在，讓我們解決核心問題：JSON 是否會減慢我們的應用程式速度？ 如同前面提到的，JSON 是一種非常流行的資料交換格式。它靈活、易於使用且廣受支援。然而，這種廣泛的採用並不能使其免受性能挑戰。 在某些情況下，JSON 可能是降低應用程式速度的罪魁禍首。解析 JSON 資料的過程，尤其是在處理大型或複雜結構時，可能會消耗寶貴的毫秒時間。此外，低效率的序列化和反序列化可能會影響應用程式的整體效能。 ### 解析開銷 當 JSON 資料到達您的應用程式時，它必須經過解析過程才能將其轉換為可用的資料結構。解析可能相對較慢，尤其是在處理大量或深層巢狀的 JSON 資料時。 ``` // JavaScript example using JSON.parse for parsing const jsonData = '{"key": "value"}'; const parsedData = JSON.parse(jsonData); ``` ### 序列化與反序列化 JSON 要求資料從用戶端傳送到伺服器時進行序列化（將物件編碼為字串），並在接收時進行反序列化（將字串轉換回可用物件）。這些步驟可能會帶來開銷並影響應用程式的整體速度。 ``` // Node.js example using JSON.stringify for serialization const data = { key: 'value' }; const jsonString = JSON.stringify(data); ``` ### 字串操作 JSON 是基於文字的，嚴重依賴字串操作來進行連接和解析等操作。與處理二進位資料相比，字串處理可能會慢一些。 ### 缺乏資料類型 JSON 具有一組有限的資料類型（例如字串、數字、布林值）。複雜的資料結構可能需要效率較低的表示，導致記憶體使用量增加和處理速度變慢。 ``` { "quantity": 1.0 } ``` ### 冗長 JSON 的人類可讀設計可能會導致冗長。冗餘金鑰和重複結構會增加有效負載大小，導致資料傳輸時間更長。 ``` // Inefficient { "product1": { "name": "Product A", "price": 10 }, "product2": { "name": "Product A", "price": 10 } } ``` ### 沒有二進位支持 JSON 缺乏對二進位資料的本機支援。在處理二進位資料時，開發人員通常需要將其編碼和解碼為文本，這可能會降低效率。 ### 深度嵌套 在某些場景下，JSON資料可能會深度嵌套，需要遞歸解析和遍歷。這種計算複雜性可能會減慢您的應用程式的速度，尤其是在沒有最佳化的情況下。 --- > **與此類似，我與其他熱愛開源的開發人員一起在 Slack 上運行一個以開發人員為中心的社群。我們討論這些類型的主題、實現、整合、一些真相炸彈、奇怪的聊天、虛擬會議、為開源做出貢獻以及一切有助於開發人員保持理智的事情；）畢竟，太多的知識也可能是危險的。* * > **我邀請您加入我們的免費社區（_沒有廣告，我保證，並且我打算保持這種方式_），參與討論，並分享您的經驗和專業知識。您可以填寫此表格，Slack 邀請將在幾天後收到您的電子郵件。我們有來自一些偉大公司（Atlassian、Gong、Scaler）的優秀人員，您一定不想錯過與他們的互動。 [邀請表](https://forms.gle/VzA3ST8tCFrxt39U9)** 讓我們繼續... --- ## JSON 的替代方案 雖然 JSON 是一種通用的資料交換格式，但其在某些場景下的效能限制導致人們探索更快的替代方案。讓我們深入研究其中一些替代方案，並了解您何時以及為何選擇它們： ### 協定緩衝區 Protocol Buffers，也稱為 protobuf，是 Google 開發的二元序列化格式。它在速度和效率方面表現出色。這就是您可能考慮使用 Protocol Buffer 的原因： 1. **二進位編碼**：Protocol Buffers 使用二進位編碼，與 JSON 基於文字的編碼相比，它更緊湊，編碼和解碼速度更快。 2. **高效的資料結構**：Protocol Buffers 可讓您透過精確的類型定義高效的資料結構，從而實現更快的序列化和反序列化。 3. **架構演化**：Protocol Buffers 支援架構演化，這表示您可以在不破壞向後相容性的情況下更新資料結構。 ``` syntax = "proto3"; message Person { string name = 1; int32 age = 2; } ``` ### 訊息包 MessagePack 是另一種專為提高效率和速度而設計的二元序列化格式。以下是您可能考慮使用 MessagePack 的原因： 1. **緊湊性**：MessagePack 產生高度緊湊的資料表示形式，從而減少資料傳輸大小。 2. **二進位資料**：MessagePack 提供了對二進位資料的原生支持，非常適合涉及二進位資訊的場景。 3. **速度**：MessagePack 的二進位性質允許快速編碼和解碼。 ``` // JavaScript example using MessagePack for serialization const msgpack = require('msgpack-lite'); const data = { key: 'value' }; const packedData = msgpack.encode(data); ``` ### BSON（二進位 JSON） BSON，通常發音為“bee-son”或“bi-son”，是一種二進位序列化格式，主要用於 MongoDB 等資料庫。以下是您可能考慮使用 BSON 的原因： 1. **類似 JSON 的結構**：BSON 維護了類似 JSON 的結構，並添加了二進位資料類型，在效率和可讀性之間提供了平衡。 2. **二進位資料支援**：BSON 提供對二進位資料類型的原生支持，這有利於處理映像或多媒體等資料。 3. **資料庫集成**：BSON 與 MongoDB 等資料庫無縫集成，使其成為此類環境的自然選擇。 ``` { "_id": ObjectId("60c06fe9479e1a1280e6bfa7"), "name": "John Doe", "age": 30 } ``` ### 歐元 Avro 是在 Apache Hadoop 專案中開發的資料序列化框架。它強調模式相容性和效能。以下是您可能考慮使用 Avro 的原因： 1. **架構相容性**：Avro 優先考慮架構相容性，讓您在不破壞相容性的情況下發展資料結構。 2. **二進位資料**：Avro 使用緊湊的二進位編碼格式進行資料傳輸，從而產生更小的有效負載。 3. **語言中立**：Avro 支援多種程式語言，使其適合不同的應用程式生態系統。 ``` { "type": "record", "name": "Person", "fields": [ { "name": "name", "type": "string" }, { "name": "age", "type": "int" } ] } ``` JSON 及其替代方案之間的選擇取決於您的特定用例和要求。如果架構相容性至關重要，Avro 可能是最佳選擇。如果您需要緊湊性和效率，MessagePack 和 Protocol Buffers 是強有力的競爭者。在處理二進位資料時，MessagePack 和 BSON 可以滿足您的需求。每種格式都有其優點和缺點，因此請選擇適合您專案需求的格式。 ### 最佳化 JSON 效能 但是，如果您決心使用 JSON，儘管它有潛在的速度障礙，該怎麼辦？如何讓 JSON 運作得更快、更有效率？好消息是，有一些實用的策略和最佳化可以幫助您實現這一目標。讓我們透過程式碼範例和最佳實踐來探索這些策略。 **1.最小化資料大小** A。 **使用簡短的描述性鍵**：選擇簡潔但有意義的鍵名稱以減少 JSON 物件的大小。 ``` // Inefficient { "customer_name_with_spaces": "John Doe" } // Efficient { "customerName": "John Doe" } ``` b. **盡可能縮寫**：在不犧牲清晰度的情況下，考慮使用鍵或值的縮寫。 ``` // Inefficient { "transaction_type": "purchase" } // Efficient { "txnType": "purchase" } ``` **2.明智地使用數組** A。 **最小化巢狀**：避免深度巢狀數組，因為它們會增加解析和遍歷 JSON 的複雜度。 ``` // Inefficient { "order": { "items": { "item1": "Product A", "item2": "Product B" } } } // Efficient { "orderItems": ["Product A", "Product B"] } ``` **3.優化數位表示** A。 **盡可能使用整數**：如果一個值可以表示為整數，請使用它而不是浮點數。 ``` // Inefficient { "quantity": 1.0 } // Efficient { "quantity": 1 } ``` **4.刪除冗餘** A。 **避免重複資料**：透過引用共享值來消除冗餘資料。 ``` // Inefficient { "product1": { "name": "Product A", "price": 10 }, "product2": { "name": "Product A", "price": 10 } } // Efficient { "products": [ { "name": "Product A", "price": 10 }, { "name": "Product B", "price": 15 } ] } ``` **5.使用壓縮** A。 **套用壓縮演算法**：如果適用，請使用 Gzip 或 Brotli 等壓縮演算法來減少傳輸過程中 JSON 有效負載的大小。 ``` // Node.js example using zlib for Gzip compression const zlib = require('zlib'); const jsonData = { // Your JSON data here }; zlib.gzip(JSON.stringify(jsonData), (err, compressedData) => { if (!err) { // Send compressedData over the network } }); ``` 根據塞繆爾的評論，我添加了一個編輯。 {% devcomment 2adn4 %} ``` As Samuel rightly observes, the adoption of HTTP/2 has brought significant advancements, particularly in optimizing data interchange formats like JSON. HTTP/2's multiplexing capabilities efficiently manage multiple requests over a single connection, enhancing responsiveness and reducing overhead. In practical terms, a comprehensive optimization strategy may involve both embracing HTTP/2 and utilizing compression techniques per your use-case, recognizing that each approach addresses specific aspects of network efficiency and performance. HTTP/2 excels in network-level optimization, while compression strategies enhance application-level efficiency, and the synergy between them can lead to substantial gains in data handling speed and resource utilization. ``` **6。使用伺服器端快取** A。 **快取 JSON 回應**：實作伺服器端快取以有效儲存和提供 JSON 回應，減少重複資料處理的需要。 **7.設定檔和優化** A。 **分析效能**：使用分析工具來識別 JSON 處理程式碼中的瓶頸，然後最佳化這些部分。 請記住，您實施的具體優化應符合應用程式的要求和約束。 ### 實際最佳化：在實作中加速 JSON 現在您已經探索了優化 JSON 的理論方面，現在是時候深入研究遇到 JSON 效能瓶頸並巧妙克服它們的實際應用程式和專案了。這些範例提供了有關用於提高速度和回應能力的策略的寶貴見解，同時仍利用 JSON 的多功能性。 **1. LinkedIn 的協定緩衝區整合** *挑戰：LinkedIn 與 JSON 冗長和網路頻寬使用的鬥爭* 全球最大的職業社交平台LinkedIn面臨嚴峻的挑戰。他們對 JSON 進行微服務通訊的依賴導致了冗長和網路頻寬使用量的增加，最終導致更高的延遲。在每一毫秒都至關重要的數位世界中，這是一個需要解決方案的挑戰。 **解決方案：協定緩衝區的力量** LinkedIn 轉向了 [Protocol Buffers](https://engineering.linkedin.com/blog/2023/linkedin-integrates-protocol-buffers-with-rest-li-for-improved-m)，通常稱為 protobuf，由Google開發的二進位序列化格式。 Protocol Buffers 的主要優勢在於其效率、緊湊性和速度，使其在序列化和反序列化方面比 JSON 快得多。 **影響：延遲減少高達 60%** Protocol Buffers 的採用顯著降低了延遲，報告顯示延遲可提高高達 60%。此次優化顯著提高了 LinkedIn 服務的速度和回應能力，為全球數百萬用戶提供了更流暢的體驗。 **2. Uber 的 H3 地理索引** *挑戰：Uber 在地理空間資料方面的 JSON 困境* 叫車巨頭優步的營運嚴重依賴地理空間數據。 JSON 是表示地理空間資料的預設選擇，但解析大型資料集的 JSON 被證明是一個瓶頸，減慢了演算法的速度。 **解決方案：引入 H3 地理索引** Uber 推出了 [H3 Geo-Index](https://www.uber.com/en-IN/blog/h3/)，這是一種用於地理空間資料的高效能六邊形網格系統。透過從 JSON 轉向這種創新解決方案，他們成功地大幅減少了 JSON 解析開銷。 **影響：加速地理空間操作** 這種優化大大加速了地理空間操作，提高了 Uber 乘車服務和地圖系統的效率。使用者體驗到更快的回應時間和更可靠的服務。 **3. Slack 的訊息格式最佳化** *挑戰：Slack 與即時訊息渲染的戰鬥* Slack 是團隊的訊息平台，需要在即時聊天中傳輸和呈現大量 JSON 格式的訊息。然而，這導致了效能瓶頸和訊息渲染緩慢。 **解決方案：簡化 JSON 結構** Slack 優化了 JSON 結構以減少不必要的資料。他們開始在每個訊息中只包含基本訊息，從而減少有效負載的大小。 **影響：更快的訊息渲染和增強的聊天效能** 此優化顯著提高了訊息渲染速度。 Slack 用戶享受到更靈敏、更有效率的聊天體驗，尤其是在繁忙的群組聊天中。 **4. Auth0 的協定緩衝區實作** *挑戰：Auth0的身份驗證和授權資料效能* Auth0 是一個著名的身份和存取管理平台，在處理身份驗證和授權資料時面臨 JSON 的效能挑戰。這些數據需要在不影響安全性的情況下有效處理。 **解決方案：採用協定緩衝區進行資料序列化** [Auth0 也轉向Protocol Buffers](https://auth0.com/blog/beating-json-performance-with-protobuf/#How-Do-We-Use-Protobuf)，利用其高效的資料序列化和反序列化功能。此交換器顯著提高了資料處理速度，使身份驗證過程更快並增強了整體效能。 **影響：加速身份驗證和授權** Protocol Buffers 的採用增強了身分驗證和授權流程，確保 Auth0 的服務提供一流的效能，同時保持最高的安全標準。 這些現實世界的例子強調了優化在克服 JSON 相關的速度下降方面的力量。這些案例中採用的策略證明了 JSON 和替代格式在滿足現代數位環境的需求方面的適應性和多功能性。 請繼續關注結論部分，我們總結了關鍵要點，並為您提供了在您自己的專案中優化 JSON 效能的路線圖。 ＃＃ 結束語 在開發領域，JSON 是一種多功能且不可或缺的資料交換工具。其人類可讀的結構和跨語言適應性使其成為當代應用程式的基石。然而，正如我們在本指南中的探索所揭示的那樣，JSON 的普遍使用並不能使其免受性能挑戰。 我們在增強 JSON 效能的過程中獲得的重要收穫是顯而易見的： - 1. **效能至關重要：** 速度和反應能力在當今的數位環境中至關重要。用戶要求應用程式以閃電般的速度運行，即使是輕微的延遲也會導致不滿意並錯失機會。 - 2. **大小很重要：** 資料有效負載的大小直接影響網路頻寬使用和回應時間。減少資料大小通常是優化 JSON 效能的第一步。 - 3. **探索替代格式：** 當效率和速度至關重要時，探索替代資料序列化格式（如 Protocol Buffers、MessagePack、BSON 或 Avro）是有益的。 - 4. **真實世界範例：** 從組織有效解決 JSON 相關減速問題的真實實例中學習，表明最佳化工作可以顯著提高應用程式效能。 當您繼續開發和增強 Web 應用程式時，請務必牢記 JSON 對效能的影響。精心設計資料結構，選擇有意義的鍵名稱，並在情況需要時開放探索替代序列化格式。透過這樣做，您可以確保您的應用程式在速度和效率方面不僅滿足而且超越用戶的期望。 在不斷發展的 Web 開發環境中，優化 JSON 效能成為一項寶貴的資產，使您的專案與眾不同，並確保您的應用程式在即時數位體驗時代蓬勃發展。 --- > **與此類似，我與其他熱愛開源的開發人員一起在 Slack 上運行一個以開發人員為中心的社群。我們討論這些類型的主題、實現、整合、一些真相炸彈、奇怪的聊天、虛擬會議、為開源做出貢獻以及一切有助於開發人員保持理智的事情；）畢竟，太多的知識也可能是危險的。* * > **我邀請您加入我們的免費社區（_沒有廣告，我保證，並且我打算保持這種方式_），參與討論，並分享您的經驗和專業知識。您可以填寫此表格，Slack 邀請將在幾天後收到您的電子郵件。我們有來自一些偉大公司（Atlassian、Gong、Scaler）的優秀人員，您一定不想錯過與他們的互動。 [邀請表](https://forms.gle/VzA3ST8tCFrxt39U9)** > _如果您能與您的開發朋友（他們是奉獻者）分享該表格，我將不勝感激。_
原文出處：https://dev.to/madza/24-open-source-projects-for-developers-in-2023-391l --- 標題：2023 年開發人員的 24 個開源專案 🔥👍 發表：真實 描述： 標籤： 開源、 github、 程式設計、 Web 開發 封面圖：https://dev-to-uploads.s3.amazonaws.com/uploads/articles/74998ffdt3doqvxtxumz.png canonical_url：https://madza.hashnode.dev/24-open-source-projects-for-developers-in-2023 --- 開源專案是創新、協作和創造力的遊樂場。它是來自世界各地的開發人員聚集在一起分享他們的想法、技能和熱情的中心。 在本文中，我精心挑選了 24 個涵蓋廣泛興趣和技術的開源專案。 從尖端的人工智慧框架到漂亮的生產力工具以及介於兩者之間的一切，每個開發人員都能找到適合自己的東西。 我提供了直接連結、描述和視覺效果，以便您可以立即獲得每個工具的初步印象。 --- ## 1\. [集算器SPL](https://github.com/SPLWare/esProc)（贊助） 集算器SPL是一種基於腳本的資料操作語言，與SQL資料庫集成，支援進階分析和高效能並行處理。 它適合處理大型資料集，與各種工具集成，提供資料視覺化，並跨多個平台工作。一些主要功能包括： **💪 強大的資料處理能力：** 集算器SPL是一種腳本語言，具有豐富的函數庫和強大的語法。 **✨ 預存程序等效項：** 它允許透過 JDBC 介面執行 SPL 腳本。 **📈 多功能視覺化：** 它提供了成熟的報告工具，具有廣泛的視覺化配置，用於建立各種類型的報告。 **⚡ 自動化工作流程：** 它支援軟體工作流程的自動化，包括用於程式碼建置、測試和部署的 CI/CD 流程。 **🔥 相比SQL更具彈性：** 與SQL語法不同，集算器SPL允許將資料處理程式碼寫在多條語句中。  ## 2\. [跳房子](https://github.com/hoppscotch/hoppscotch) 一種多功能開源 API 開發和測試工具，提供使用者友善的介面，用於發出 HTTP 請求來測試 API 並與 API 互動。 它簡化了製作和發送請求的過程，使其成為使用 API 的開發人員和測試人員的必備工具。  ## 3\. [Supabase](https://github.com/supabase/supabase) Firebase 的開源替代方案，為開發人員提供了一組用於建立可擴展的即時應用程式的工具。 它提供了強大的後端即服務 (BaaS) 平台，具有身份驗證、資料庫管理和即時功能等功能，使其成為創建現代 Web 和行動應用程式的強大選擇。  ## 4\. [超級代幣](https://github.com/supertokens/supertokens-core) 一種開源身份驗證解決方案，提供強大的安全功能和輕鬆集成，以增強 Web 和行動應用程式中的使用者身份驗證和授權。 它為開發人員提供了一個全面的工具包，用於保護用戶資料並確保無縫登入體驗。  ## 5\. [Git](https://github.com/git/git) Git 版本控制系統的官方開源程式庫，最初由 Linus Torvalds 建立。 Git 廣泛用於追蹤原始程式碼的更改，並透過提供強大的分支和合併功能來實現協作軟體開發。  ## 6\. [VS 代碼](https://github.com/microsoft/vscode) 由 Microsoft 開發的免費開源程式碼編輯器。 它提供了高度可自訂且高效的程式設計環境，具有 IntelliSense、調試支援和龐大的擴充庫等功能，可增強您的開發工作流程。  ## 7\. [OhMyZsh](https://github.com/ohmyzsh/ohmyzsh) 一個流行且高度可自訂的框架，用於在類 Unix 作業系統中管理 Zsh 配置。 它簡化了 shell 自訂，提供了大量插件和主題來增強您的命令列體驗。  ## 8\. [包子](https://github.com/oven-sh/bun) 一個開源 JavaScript 工具包，旨在簡化和優化為 Web 應用程式捆綁 JavaScript 程式碼的過程。 它提供了一種現代且快速的方法來建立捆綁包，從而增強了使用 JavaScript 專案時的效能和開發人員體驗。  ## 9\. [SWR](https://github.com/vercel/swr) SWR（Stale-While-Revalidate）是一個用於在 React 應用程式中取得資料的 JavaScript 函式庫。 它可以在客戶端和伺服器之間實現高效、自動的資料同步，提供無縫的即時更新，同時確保資料保持新鮮和最新。  ## 10\. [Prisma](https://github.com/prisma/prisma) 用於現代應用程式開發的開源資料庫工具包，透過強大的查詢產生器和類型安全的 ORM（物件關聯映射）層簡化資料庫存取和操作。 它允許開發人員使用聲明性和直觀的方法管理資料庫並與之交互，從而使資料庫操作在各種資料庫系統中無縫且安全。  ## 11\. [ElasticSearch](https://github.com/elastic/elasticsearch) 由 Elastic 開發的強大且可擴展的開源搜尋和分析引擎。 它旨在幫助用戶快速有效地搜尋、分析和視覺化大量數據，使其成為從全文搜尋引擎到日誌分析等應用程式的熱門選擇。  ## 12\. [哈蘇拉](https://github.com/hasura/graphql-engine) 一款功能強大的開源工具，可簡化應用程式的 GraphQL API 開發。 借助 Hasura，您可以輕鬆建立、管理和保護 GraphQL API，從而更輕鬆地與資料來源互動並建立現代的資料驅動應用程式。  ## 13\. [BioDrop](https://github.com/EddieHubCommunity/BioDrop) 透過單一連結與您的受眾建立聯繫。在一處展示您創建的內容和項目。 讓人們更容易找到、關注和訂閱。  ## 14\. [Powertoys](https://github.com/microsoft/PowerToys) 適用於 Windows 的開源實用程序，可提高工作效率和自訂功能。 它提供了一系列方便的工具和實用程序，包括快速啟動器、文件預覽和視窗管理等功能，旨在簡化您的 Windows 體驗。  ## 15\. [Strapi](https://github.com/strapi/strapi) 開源無頭內容管理系統 (CMS)，使開發人員能夠快速建立強大且可自訂的 API。 它使團隊能夠輕鬆創建和管理內容豐富的網站和應用程序，為各種專案提供靈活性和可擴展性。  ## 16\. [看似合理](https://github.com/plausible/analytics) 一種開源網路分析工具，旨在為網站所有者提供對其網站效能的簡單且注重隱私的見解。 它提供用戶友好、輕量級的跟踪，且不會損害訪問者的隱私，使其成為那些重視數據分析而無需侵入性跟踪方法的人的理想選擇。  ## 17\. [Astro](https://github.com/withastro/astro) 現代靜態網站產生器，透過僅傳送頁面所需的 JavaScript 來提供閃電般的效能，從而實現近乎即時的載入時間。 它將傳統伺服器渲染框架的靈活性與靜態網站產生器的速度相結合，使其成為建立高效動態網站的絕佳選擇。  ## 18\. [混音](https://github.com/remix-run/remix) 用於建立現代 JavaScript 應用程式的 Web 框架，注重速度和開發人員體驗。 它使開發人員能夠透過無縫組合伺服器渲染和客戶端渲染的內容來創建高效能的 Web 應用程式。  ## 19\. [張量流](https://github.com/tensorflow/tensorflow) 由Google開發的開源機器學習框架。 它為建立和部署機器學習模型提供了靈活且全面的生態系統，使其成為人工智慧領域研究人員和開發人員的熱門選擇。  ## 20\. [顫動](https://github.com/flutter/flutter) 由 Google 創建的開源 UI 軟體開發工具包，以其從單一程式碼庫建立適用於行動、Web 和桌面的本機編譯應用程式的能力而聞名。 它使開發人員能夠使用單一程式語言 Dart 跨多個平台創建美觀、快速且高度可自訂的使用者介面。  ## 21\. [Kubernetes](https://github.com/kubernetes/kubernetes) 一個開源容器編排平台，可自動執行容器化應用程式的部署、擴充和管理。 它為編排容器提供了強大而靈活的基礎架構，使在雲端原生環境中大規模管理複雜的分散式系統變得更加容易。  ## 22\. [Docker](https://www.docker.com/community/open-source/) 一個開源工具，可簡化多容器 Docker 應用程式的管理。 它允許開發人員使用簡單的 YAML 檔案定義和運行多容器應用程序，從而更輕鬆地編排和部署複雜的服務。  ## 23\. [鉻](https://github.com/chromium/chromium) Google 的一個開源瀏覽器項目，旨在為所有使用者建立更安全、更快、更穩定的網路體驗方式。 它是開發人員在網路瀏覽技術領域做出貢獻和創新的平台。  ## 24\. [Linux 核心](https://github.com/torvalds/linux) 由 Linus Torvalds 和全球貢獻者社群開發的開源、類別 Unix 作業系統核心。 它作為各種基於 Linux 的作業系統的核心組件，提供硬體互動和系統管理的基本功能。  --- 寫作一直是我的熱情，幫助和激勵人們讓我感到很高興。如果您有任何疑問，請隨時與我們聯繫！ 透過[Twitter](https://twitter.com/madzadev)、[LinkedIn](https://www.linkedin.com/in/madzadev/) 和[GitHub](https://github.com) 與我聯繫/madzadev）！ 請訪問我的[部落格](https://madza.dev/blog)以獲取更多此類文章。
2024 年，React 將慶祝其成立 11 週年，值得期待 React 生態系統中令人興奮的發展。在本部落格中，我們將基於 2023 年發生的情況以及來年的預期，探討生態系統的各個面向。 原文出處：https://dev.to/avinashvagh/react-ecosystem-in-2024-418k ## 1. 路由 路由一直是Web開發的關鍵部分，在2023年，我們看到了各種各樣的路由解決方案。讓我們看看2024年會發生什麼： - **React Router：** React Router 仍然是 React 應用程式中處理路由的基本選擇。憑藉其廣泛的文件和活躍的社區，它仍然是應用程式中聲明式路由的可靠選擇。 - **React Query：** Tanstack 的 React Query 在 2023 年流行的基礎上，旨在增強資料擷取和狀態管理。它簡化了 React 應用程式中管理、快取和同步資料的過程。 - **Next.js：** Next.js 是一個建立在 React 之上的框架，預計將保持其作為具有靈活路由選項的伺服器渲染 React 應用程式首選的地位。它的官方文件是 Next.js 應用程式中路由的寶貴資源。 2024 年，React 充滿活力的生態系統將繼續蓬勃發展，為開發人員提供豐富的工具和函式庫。請繼續關注 React 世界的更多更新和進步。 ## 2. 客戶端狀態管理 客戶端狀態管理是現代 Web 開發的一個重要方面，可以在前端應用程式中實現高效的資料處理。 Redux Toolkit 和 Zustand 是兩種流行的用戶端狀態管理解決方案。以下是兩者的簡要概述： ### 1. **Redux Toolkit** - **網址：** [Redux Toolkit](https://redux-toolkit.js.org/) Redux Toolkit 是一個建立在 Redux 之上的綜合狀態管理函式庫，Redux 是 React 應用程式中成熟的狀態管理函式庫。它提供了一組工具和最佳實踐，以可預測且高效的方式簡化狀態管理流程。 Redux Toolkit 的結構化方法（包括 actions、reducer 和 store）非常適合複雜的大型專案。它提倡採用集中式和聲明式的狀態管理方法。 ### 2. ** Zustand** - **示範：** [Zustand Demo](https://state-demo.pmnd.rs/) Zustand 是一個輕量級且靈活的狀態管理庫，專為小型專案或喜歡更簡單解決方案的開發人員而設計。它簡化了狀態管理，無需複雜的設定和概念。 Zustand 以其簡單性和易用性而聞名，這使其成為小型應用程式和重視更輕量級方法的人的絕佳選擇。 在 Redux Toolkit 和 Zustand 之間進行選擇時，請考慮專案的複雜性以及您對 Redux 的熟悉程度。 Redux Toolkit 是大型、結構化應用程式的絕佳選擇，而 Zustand 則非常適合需要快速、簡單的狀態管理解決方案的小型專案。 ## 3.伺服器狀態管理 伺服器狀態管理是 Web 開發的一個重要方面，特別是對於跨客戶端和伺服器的應用程式。以下是兩個可以幫助您有效管理伺服器狀態的關鍵庫： ### 1. **TanStack Query** - **文件：** [TanStack Query](https://tanstack.com/query/latest) TanStack Query 是一個強大且靈活的狀態管理庫，用於處理應用程式中的伺服器狀態。它允許您輕鬆地從伺服器獲取、快取和更新資料。該程式庫提供自動快取、高效資料擷取以及自訂 API 端點的功能等功能。對於需要即時資料更新和高效資料同步的應用程式來說，它是管理伺服器狀態的絕佳選擇。 ### 2. **Redux 工具包 - RTK Query** - **文件：** [Redux 工具包 - RTK 查詢](https://redux-toolkit.js.org/rtk-query/overview) RTK Query 是 Redux Toolkit 生態系統的一部分，提供管理伺服器狀態的全面解決方案。它以可預測且高效的方式簡化了發出 API 請求、快取資料和更新狀態的過程。 RTK Query 與 Redux 無縫集成，對於使用 Redux 進行狀態管理的應用程式來說是一個絕佳的選擇。它提倡最佳實踐並提供結構化方法來處理伺服器狀態。 選擇伺服器狀態管理庫時，請考慮您的專案需求、資料擷取需求的複雜性以及您對 Redux 的熟悉程度（如果您選擇 RTK 查詢）。這兩個庫都提供了用於管理應用程式中的伺服器狀態的強大解決方案。 ## 4. 表單處理 表單處理是建立 Web 應用程式的關鍵部分，尤其是在 React 中。用於表單處理的兩個流行的程式庫是 Formik 和 React Hook Form。概述如下： ### 1. ** Formik** - **網址：** [Formik](https://formik.org/) Formik 是在 React 中建立表單最常用的函式庫。它提供了一組實用程式和元件，可以輕鬆管理表單狀態、驗證和提交。雖然它是一個流行的選擇，但截至最新訊息，Formik 並未得到積極維護，這可能會影響其與未來 React 更新和不斷發展的最佳實踐的兼容性。使用 Formik 的唯一缺點是它不被維護。 Formik 文件/網站甚至不鼓勵在新專案中使用 Formik。 ### 2. **React Hook Form** - **網址：** [React Hook 表單](https://www.react-hook-form.com/) React Hook Form 是一個現代表單函式庫，它利用 React hooks 來有效地處理表單狀態和驗證。它得到積極維護，並提供輕量級且直觀的 API。 React Hook Form 以其效能和靈活性而聞名，使其成為在 React 應用程式中處理表單的絕佳選擇。 在 Formik 和 React Hook Form 之間進行選擇時，請考慮維護和專案的特定要求等因素。根據最新訊息，React Hook Form 因其積極的開發和現代的表單處理方法而成為推薦選擇。 ## 5. 測試 測試是軟體開發過程的關鍵部分，有各種工具和程式庫可協助開發人員編寫有效的測試。以下是一些用於測試的資源和工具： ### 1. **ViTest** - **網址：** [ViTest](https://vitest.dev/) ViTest 是一個由 vite 支援的單元測試框架。它提供了一種為 React、Vue、Svelte 等應用程式編寫單元測試、元件測試和端到端測試的簡單方法。如果您使用 React，ViTest 可以透過全面的測試來幫助您確保程式碼的可靠性和品質。 ### 2. **React 測試函式庫** - **文件：** [React 測試庫](https://testing-library.com/docs/react-testing-library/intro/) React 測試庫是 React 應用程式的熱門測試庫。它專注於編寫模擬使用者互動的測試，幫助您確保元件從使用者的角度按照預期執行。該程式庫鼓勵測試 React 元件的最佳實踐。 ### 3. ** Playwright** - **網址：** [Playwright](https://playwright.dev/) Playwright 是一個端對端測試框架，支援多種瀏覽器，包括 Chromium、Firefox 和 WebKit。它為瀏覽器自動化提供了統一的 API，並允許您編寫測試來驗證 Web 應用程式在不同瀏覽器上的功能。 Playwright 是確保跨瀏覽器相容性的強大工具。 這些資源和工具可以幫助您涵蓋測試的各個方面，從單元測試到端到端測試，具體取決於您的專案需求和您正在使用的技術。請務必進一步探索它們，以選擇最適合您要求的一種。 ## 6. 樣式 當談到 Web 開發中的樣式時，有幾種流行的工具和庫可供選擇。以下是三個值得注意的選項： ### 1. **Tailwind CSS** - **網址：** [Tailwind CSS](https://tailwindcss.com/) Tailwind CSS 是一個實用程式優先的 CSS 框架，它提供了一組預先建立的原子 CSS 類別來設計您的 Web 應用程式。它旨在透過在 HTML 中編寫實用程式類別來幫助您快速建立響應式且高度可自訂的設計。 Tailwind CSS 以其靈活性而聞名，對於想要實用程式驅動的樣式設計方法的開發人員來說是一個絕佳的選擇。 ### 2. **樣式元件** - **網址：** [樣式元件](https://styled-components.com/) Styled Components 是一個 CSS-in-JS 函式庫，用於設計 React 元件的樣式。它允許您透過使用標記模板文字定義樣式元件來直接在 JavaScript 檔案中編寫 CSS。這種方法使您能夠將樣式封裝在元件中，從而更輕鬆地管理和維護 CSS。樣式化元件在 React 生態系統中特別受歡迎。 ### 3. ** Emotion** - **文件：** [Emotion](https://emotion.sh/docs/introduction) Emotion 是另一個 CSS-in-JS 函式庫，重點是效能和靈活性。它提供了多種方法來定義樣式並將其應用到 React 元件，包括字串和物件樣式。 Emotion 以其可預測性和適合使用 JavaScript 編寫不同 CSS 樣式而聞名。它提供了一種與框架無關的方法，使其適用於各種 JavaScript 框架。 這些工具中的每一個都有自己的優勢，並且適合不同的用例。 Tailwind CSS 擅長使用實用程式類別進行快速 UI 開發。 Styled Components 和 Emotion 是 React 應用程式中元件級樣式的理想選擇。您的選擇將取決於您的專案要求和個人喜好。 ## 7.UI元件庫 用於在 2023 年建立使用者介面的 UI 元件庫，並將在 2024 年繼續使用。 ### 1. ** Material-UI** - **網址：** [Material-UI](https://mui.com/) Material-UI 是一個受歡迎且維護良好的 React UI 框架。它基於 Google 的 Material Design 指南，並提供廣泛的元件來建立現代且具有視覺吸引力的使用者介面。 ### 2. ** Mantine** - **網址：** [Mantine](https://mantine.dev/) Mantine 是一個現代 React 元件庫，專注於提供高品質的元件和鉤子。它提供了各種 UI 元素和工具來簡化您的開發流程。 ### 3. ** Ant Design** - **網址：** [Ant Design](https://ant.design/) Ant Design 是一個用於建立企業級 React 應用程式的綜合設計系統和元件庫。它以其豐富的元件和強調自然清晰的設計理念而聞名。 ### 4. ** Chakra UI** - **網址：** [Chakra UI](https://chakra-ui.com/) Chakra UI 是在 React 中建立可存取且高度可自訂的使用者介面的熱門選擇。它提供了一組可組合元件和一個樣式道具系統，用於靈活的樣式設定。 ### 5. ** Headless UI（Tailwind CSS 框架）** - **網址：** [Headless UI](https://headlessui.com/) Headless UI 是一組完全可存取、無樣式的 UI 元件，旨在與 Tailwind CSS 無縫協作。它允許您建立可存取的介面，同時保留對樣式的完全控制。 ### 6. **DaisyUI（Tailwind CSS 框架）** - **網址：** [DaisyUI](https://daisyui.com/) DaisyUI 是 Tailwind CSS 的擴展，它帶來了額外的元件和實用程式來增強您的開發體驗。如果您已經在使用 Tailwind CSS，它會特別有用。 ### 7.**Shadcn UI（Tailwind CSS 框架）** - **網址：** [Shadcn UI](https://ui.shadcn.com/) Shadcn UI 是另一個基於 Tailwind CSS 的 UI 元件庫，它提供了一系列元件和實用程序，用於快速有效地建立 Web 應用程式。 這些程式庫提供了各種元件和工具，可協助您在 React 應用程式中建立響應靈敏且具有視覺吸引力的使用者介面。庫的選擇取決於您的專案的要求和您的個人喜好。 ## 8. 動畫 如果您對 React 動畫庫感興趣，兩個流行的選擇是： 1. **React Spring** - 您可以在 React Spring 的官方網站 [react-spring.dev](https://www.react-spring.dev/) 上找到有關 React Spring 的更多資訊和文件。 React Spring 是一個功能豐富的動畫庫，它利用基於實體的動畫在 React 中建立流暢的互動式動畫。 2. **Framer Motion** - 另一個出色的選擇是 Framer Motion，您可以在 [framer.com/motion](https://www.framer.com/motion/) 進一步探索它。 Framer Motion 因是專為 React 設計的功能豐富的動畫庫而聞名。它提供了靈活性，非常適合在 React 應用程式中建立流暢的動畫。 這兩個庫都有其優點，它們之間的選擇可能取決於您的特定專案要求和個人喜好。 React Spring 提供基於實體的動畫和豐富的功能集，而 Framer Motion 以其易用性和靈活性而聞名。最好對兩者進行探索，看看哪一個更符合您的動畫需求。 請隨意參考各自的網站以獲取詳細的文件和範例，以便做出明智的選擇。 ## 9. 資料視覺化 當涉及 React 中的資料視覺化時，有幾個函式庫可以幫助您建立互動式且資訊豐富的圖表和圖形。以下是三個流行的選項： 1. **Victory** - 您可以在 [formidable.com/open-source/victory/docs](https://formidable.com/open-source/victory/docs) 中瀏覽 Victory 的文件 Victory 是一個強大的 React 資料視覺化函式庫，提供廣泛的圖表類型和自訂選項。它旨在輕鬆建立具有視覺吸引力的互動式資料視覺化。 2. **React Chartjs 2** - 造訪 [react-chartjs-2.js.org](https://react-chartjs-2.js.org/) 以了解更多資訊。 React Chartjs 2 是 Chart.js（一個流行的 JavaScript 圖表庫）的 React 包裝器。它提供了一種將 Chart.js 整合到 React 應用程式中的簡單方法，可讓您使用 Chart.js 的底層功能建立各種圖表和圖形。 3. **Recharts** - 有關Recharts的詳細訊息，您可以參考[recharts.org/en-US/](https://recharts.org/en-US/)。 Recharts 是一個使用 React 建立的可組合圖表庫。它提供了一個簡單而靈活的 API 來建立各種類型的圖表，非常適合將資料視覺化加入到您的 React 專案中。 每個庫都有自己的一組功能和優點，因此選擇將取決於您的特定專案要求和個人喜好。您可以存取他們各自的文件以了解更多資訊並開始使用 React 中的資料視覺化。 ## 10. 表 如果您正在尋找有關 React 中表格的訊息，可以在 [tanstack.com/table/v8](https://tanstack.com/table/v8) 上瀏覽版本 8 的 TanStack Table 文件。 TanStack Table 是一個無頭 UI 庫，可讓您在 TS/JS、React、Vue、Solid 和 Svelte 等各種框架中建立強大的表格和資料網格，同時保留對標記和樣式的控制。該文件將為您提供有關如何使用 TanStack Table 和配置表的詳細訊息，包括選項和 API 屬性。 無論您使用 TypeScript 還是 JavaScript 以及使用受支援的框架之一，TanStack Table v8 都提供了一種靈活的解決方案，用於在 Web 應用程式中建立表格和資料網格。該文件將引導您完成整個過程，並幫助您充分利用該庫來滿足您的特定需求。 ## 11. 國際化（i18n） 當涉及 React 應用程式中的國際化 (i18n) 時，有多個程式庫和工具可協助您管理翻譯和在地化。 React 中 i18n 的兩個突出選項是： 1. **i18next** - 您可以在 [react.i18next.com](https://react.i18next.com/) 找到使用 i18next 的文件和資源。 i18next 是一個流行的 JavaScript 國際化框架，包括 React。它提供了處理翻譯、格式化等的全面解決方案。 2. **React-Intl (Format.js)** - React-Intl 的文件是 Format.js 專案的一部分，可以在 [formatjs.io/docs/react-intl](https://formatjs.io/docs/react-intl)。 React-Intl 是一個函式庫，提供用於在 React 應用程式中格式化和處理國際化文字的工具。 這兩個函式庫都有活躍的社群、豐富的文件，並且在 React 生態系統中廣泛使用。您可以探索這些資源，以確定哪一個最適合您的 React 應用程式國際化需求。 ## 12. 開發工具 DevTools 對於偵錯和改進 Web 應用程式的開發工作流程至關重要。以下是一些流行的 React 開發工具和相關函式庫： 1. **React 開發者工具** - 該工具可作為 Chrome 擴充功能使用。它允許您檢查 React 元件層次結構、查看元件的狀態和 props，甚至更改元件的狀態以進行測試。您可以從 [Chrome Web Store](https://chrome.google.com/webstore/detail/react-developer-tools/fmkadmapgofadopljbjfkapdkoienihi) 安裝它。 2. **Redux DevTools** - Redux DevTools 是另一個 Chrome 擴展，可以增強 Redux 開發工作流程。它提供了對 Redux 儲存的深入了解，讓您可以檢查操作和狀態變更、倒回和重播操作等。您可以從 [Chrome Web Store](https://chrome.google.com/webstore/detail/redux-devtools/lmhkpmbekcpmknklioeibfkpmmfibljd) 安裝它。 3. **Testing Playground** - Test Playground 是一個 Chrome 擴展，可以簡化 React 元件的測試。它提供了一個用於試驗元件及其道具的視覺環境。您可以在 [Chrome 線上應用程式商店](https://chrome.google.com/webstore/detail/testing-playground/hejbmebodbijjdhflfknehhcgaklhano) 上找到它。 4. **React Hook Form DevTools** - 對於使用 React Hook Form 的用戶，可以使用 DevTools 來協助偵錯表單行為。您可以在 [React Hook Form 網站](https://www.react-hook-form.com/dev-tools/) 上存取它們。 5. **TanStack Query DevTools** - TanStack Query 是 React 的資料擷取庫，它提供用於偵錯和檢查查詢和突變的 DevTools。您可以參考[官方文件](https://tanstack.com/query/v4/docs/react/devtools)以了解更多資訊。 這些開發工具可協助開發人員簡化開發和偵錯流程，從而更輕鬆地建置和維護 Web 應用程式。 ## 13. 文件 文件對於任何軟體專案都至關重要。以下是用於建立文件的兩種流行工具： 1. **Docusaurus** - Docusaurus 是一種廣泛採用的用於建立文件網站的工具。它是一個開源框架，為建立和維護文件提供了乾淨且用戶友好的介面。 Docusaurus 具有高度可自訂性，許多專案和組織都使用它來建立文件網站。您可以在 Docusaurus 的[官方網站](https://docusaurus.io/)上了解更多並開始使用 Docusaurus。 2. **Nextra** - Nextra 是建立文件網站的另一種選擇。雖然 Nextra 可能不像 Docusaurus 那樣出名，但它提供了一種現代且簡約的方法來建立文件。它的設計是輕量級且用戶友好的，對於那些喜歡簡單乾淨的文件風格的人來說是一個不錯的選擇。您可以在 Nextra 的[官方網站](https://nextra.site/) 上探索有關 Nextra 的更多資訊。 Docusaurus 和 Nextra 都有各自的優勢，它們之間的選擇取決於您的特定需求和偏好。您可以存取他們各自的網站以了解更多資訊、存取文件並確定哪一個最適合您的專案。 ## 14. 元件開發環境 元件開發環境 (Dev Env) 對於有效建置和測試 UI 元件至關重要。用於為 UI 元件建立開發環境的廣泛使用的工具之一是 [Storybook](https://storybook.js.org/)。 Storybook 是業界標準的元件瀏覽器，可讓開發人員獨立開發 UI 元件。當處理設計系統或元件庫時，它特別有價值。以下是 Storybook 如何協助建立 UI 元件的開發環境： 1. **目錄 UI 元件**：Storybook 提供了用於編目和顯示 UI 元件的專用環境。開發人員可以單獨查看每個元件的外觀和行為。 2. **將元件變體儲存為故事**：在 Storybook 中，開發人員可以為每個元件建立「故事」。這些故事代表元件的不同變體或用例。這是記錄和展示元件行為的絕佳方式。 3. **開發人員體驗工具**：Storybook 提供了一系列開發人員體驗工具，包括熱模組重新加載，以簡化元件開發流程。 透過使用 Storybook，您可以有效率地開發、測試和記錄 UI 元件。它在設計系統時特別有用，因為它允許您專注於單個元件及其互動。您可以在 Storybook 的[官方網站](https://storybook.js.org/) 上了解更多並開始使用。 它是一種多功能工具，可以根據專案的特定需求進行定制，使其成為元件開發環境的寶貴資產。 ## 15. 類型檢查 TypeScript 是 Microsoft 開發的一種程式語言，透過新增靜態類型來擴充 JavaScript。它提供全面的類型檢查和強大的類型系統，以捕獲開發過程中的錯誤並提高程式碼品質。以下是 TypeScript 中類型檢查的一些關鍵方面： 1. **靜態型別系統**：TypeScript 引進了靜態型別系統，這表示在編譯時檢查類型。這有助於在執行程式碼之前辨識與類型相關的錯誤。 2. **型別註解**：開發者可以使用型別註解來指定變數、函數參數和傳回值的型別。這提供了清晰度並確保變數的使用一致。 3. **推斷**：TypeScript 可以根據指派給變數的值推斷類型。這減少了對顯式類型註解的需求並提高了程式碼簡潔性。 4. **類型聲明**：TypeScript支援自訂類型的聲明，例如介面和枚舉，以定義資料結構的形狀並增強程式碼的可維護性。 5. **類型相容性**：TypeScript 有一個檢查類型相容性的系統，這確保你不能將不相容的類型指派給變數。這有助於防止常見的執行時錯誤。 6. **對 JavaScript 文件進行類型檢查**：TypeScript 還可以檢查 JavaScript 文件，讓您可以逐步將 TypeScript 引入現有的 JavaScript 專案中。 透過將 TypeScript 合併到您的開發工作流程中，您可以從這些類型檢查功能中受益，從而儘早發現錯誤、增強程式碼可維護性並提高程式碼的整體品質。您可以在[官方 TypeScript 網站](https://www.typescriptlang.org/) 上了解有關 TypeScript 及其類型檢查功能的更多資訊。 ## 16. 行動應用程式 如果您想要開發行動應用程式，特別是 Android 和 iOS 的行動應用程式，React Native 是一個值得考慮的有價值的框架。 React Native 是一個開源框架，可讓您使用 JavaScript 和 React 建立行動應用程式。這就是 React Native 成為行動應用程式開發的熱門選擇的原因： 1. **跨平台開發**：React Native 使您能夠使用單一程式碼庫開發適用於 Android 和 iOS 的應用程式。這種方法可以顯著減少開發時間和工作量。 2. **可重複使用元件**：您可以建立跨平台工作的可重複使用 UI 元件，幫助您在應用程式中保持一致的外觀和感覺。 3. **熱重載**：React Native 支援熱重載，這意味著您可以立即看到程式碼變更的結果，而無需重新編譯整個應用程式。這加快了開發速度。 4. **大型社區**：React Native 擁有龐大且活躍的社區，這意味著您可以找到豐富的資源、庫以及常見問題的解決方案。 5. **本機效能**：React Native 應用程式具有接近本機的效能，因為它們使用本機元件進行渲染。這確保了流暢的用戶體驗。 6. **成本效益**：透過在 Android 和 iOS 之間共用程式碼庫，您可以降低開發成本。 要開始使用 React Native，您可以造訪官方網站 [React Native](https://reactnative.dev/) 以取得全面的文件、教學和資源。無論您是初學者還是經驗豐富的開發人員，React Native 都是行動應用程式開發的強大選擇。 ## 17. 為 React 開發人員提供的很棒的函式庫 很高興看到您對 React 開發人員的優秀庫感興趣。以下是一些非常有用的程式庫，可用於 React 開發中的各種功能： ### 1. **用於拖放功能的 DND 套件** - 網址：[DND Kit](https://dndkit.com/) DND Kit 是一個強大的庫，用於為 React 應用程式加入拖放功能。它提供了一種簡單且可自訂的方法來實現拖放功能，以便在使用者介面中重新排序、重新排列或組織元素。 ### 2. **React Dropzone 用於檔案上傳** - 網址：[React Dropzone](https://react-dropzone.js.org/) React Dropzone 是一個流行的程式庫，用於在 React 應用程式中處理檔案上傳。它提供了一個用戶友好且高度可自訂的 dropzone 元件，簡化了上傳文件的過程，使其成為任何需要文件上傳的專案的有價值的補充。 ### 3. **Firebase 用於身份驗證** - 網址：[Firebase](https://firebase.google.com/) Firebase 由 Google 開發，是一個用於建立 Web 和行動應用程式的綜合平台。它提供廣泛的服務，包括用戶身份驗證。透過 Firebase 驗證，您可以輕鬆地將安全的使用者註冊和登入功能新增到您的 React 應用程式中。 ### 4. **Supabase 用於身份驗證** - 網址：[Supabase](https://supabase.com/) Supabase 是 Firebase 的開源替代品，提供一套用於建立應用程式的服務，包括身份驗證。它提供了可以無縫整合到您的 React 專案中的用戶身份驗證功能。 這些程式庫涵蓋了 React 開發的基本面，包括拖放功能、檔案上傳和使用者身份驗證。根據您的專案要求，您可以利用這些程式庫來增強您的 React 應用程式。 **免責聲明：**“本文是在人工智慧的幫助下建立的”
開源專案是創新、協作和創造力的遊樂場。它是來自世界各地的開發人員聚集在一起分享他們的想法、技能和熱情的中心。 在本文中，我精心挑選了 24 個涵蓋廣泛興趣和技術的開源專案。 從尖端的人工智慧框架到漂亮的生產力工具以及介於兩者之間的一切，每個開發人員都能找到適合自己的東西。 我提供了直接連結、描述和視覺效果，以便您可以立即獲得每個工具的初步印象。 原文出處：https://dev.to/madza/24-open-source-projects-for-developers-in-2023-391l --- ## 1\. [ esProc SPL](https://github.com/SPLWare/esProc)（贊助） 集算器SPL是一種基於腳本的資料操作語言，與SQL資料庫集成，支援進階分析和高效能並行處理。 它適合處理大型資料集，與各種工具集成，提供資料視覺化，並跨多個平台工作。一些主要功能包括： **💪 強大的資料處理能力：** 集算器SPL是一種腳本語言，具有豐富的函數庫和強大的語法。 **✨ 預存程序等效項：** 它允許透過 JDBC 介面執行 SPL 腳本。 **📈 多功能視覺化：** 它提供了成熟的報告工具，具有廣泛的視覺化配置，用於建立各種類型的報告。 **⚡ 自動化工作流程：** 它支援軟體工作流程的自動化，包括用於程式碼建置、測試和部署的 CI/CD 流程。 **🔥 相比SQL更具彈性：** 與SQL語法不同，集算器SPL允許將資料處理程式碼寫在多條語句中。  ⭐ 支援他們的 GitHub 倉庫：[https://github.com/SPLWare/esProc](https://github.com/SPLWare/esProc) ## 2\. [Hoppscotch](https://github.com/hoppscotch/hoppscotch) 一種多功能開源 API 開發和測試工具，提供使用者友善的介面，用於發出 HTTP 請求來測試 API 並與 API 互動。 它簡化了製作和發送請求的過程，使其成為使用 API 的開發人員和測試人員的必備工具。  ## 3\. [Supabase](https://github.com/supabase/supabase) Firebase 的開源替代方案，為開發人員提供了一組用於建立可擴展的即時應用程式的工具。 它提供了強大的後端即服務 (BaaS) 平台，具有身份驗證、資料庫管理和即時功能等功能，使其成為建立現代 Web 和行動應用程式的強大選擇。  ## 4\. [Supertokens](https://github.com/supertokens/supertokens-core) 一種開源身份驗證解決方案，提供強大的安全功能和輕鬆集成，以增強 Web 和行動應用程式中的使用者身份驗證和授權。 它為開發人員提供了一個全面的工具包，用於保護用戶資料並確保無縫登入體驗。  ## 5\. [Git](https://github.com/git/git) Git 版本控制系統的官方開源程式庫，最初由 Linus Torvalds 建立。 Git 廣泛用於追蹤原始程式碼的更改，並透過提供強大的分支和合併功能來實現協作軟體開發。 ## 6\. [VS Code](https://github.com/microsoft/vscode) 由 Microsoft 開發的免費開源程式碼編輯器。 它提供了高度可自訂且高效的程式設計環境，具有 IntelliSense、除錯支援和龐大的擴充庫等功能，可增強您的開發工作流程。  ## 7\. [OhMyZsh](https://github.com/ohmyzsh/ohmyzsh) 一個流行且高度可自訂的框架，用於在類 Unix 作業系統中管理 Zsh 配置。 它簡化了 shell 自訂，提供了大量插件和主題來增強您的命令列體驗。  ## 8\. [Bun](https://github.com/oven-sh/bun) 一個開源 JavaScript 工具包，旨在簡化和優化為 Web 應用程式捆綁 JavaScript 程式碼的過程。 它提供了一種現代且快速的方法來建立捆綁包，從而增強了使用 JavaScript 專案時的效能和開發人員體驗。  ## 9\. [SWR](https://github.com/vercel/swr) SWR（Stale-While-Revalidate）是一個用於在 React 應用程式中取得資料的 JavaScript 函式庫。 它可以在客戶端和伺服器之間實現高效、自動的資料同步，提供無縫的即時更新，同時確保資料保持新鮮和最新。  ## 10\. [Prisma](https://github.com/prisma/prisma) 用於現代應用程式開發的開源資料庫工具包，透過強大的查詢產生器和類型安全的 ORM（物件關聯映射）層簡化資料庫存取和操作。 它允許開發人員使用聲明性和直觀的方法管理資料庫並與之交互，從而使資料庫操作在各種資料庫系統中無縫且安全。  ## 11\. [ElasticSearch](https://github.com/elastic/elasticsearch) 由 Elastic 開發的強大且可擴展的開源搜尋和分析引擎。 它旨在幫助用戶快速有效地搜尋、分析和視覺化大量資料，使其成為從全文搜尋引擎到日誌分析等應用程式的熱門選擇。  ## 12\. [Hasura](https://github.com/hasura/graphql-engine) 一款功能強大的開源工具，可簡化應用程式的 GraphQL API 開發。 借助 Hasura，您可以輕鬆建立、管理和保護 GraphQL API，從而更輕鬆地與資料來源互動並建立現代的資料驅動應用程式。  ## 13\. [BioDrop](https://github.com/EddieHubCommunity/BioDrop) 透過單一連結與您的受眾建立聯繫。在一處展示您建立的內容和專案。 讓人們更容易找到、關注和訂閱。  ## 14\. [Powertoys](https://github.com/microsoft/PowerToys) 適用於 Windows 的開源實用程序，可提高工作效率和自訂功能。 它提供了一系列方便的工具和實用程序，包括快速啟動器、文件預覽和視窗管理等功能，旨在簡化您的 Windows 體驗。  ## 15\. [Strapi](https://github.com/strapi/strapi) 開源無頭內容管理系統 (CMS)，使開發人員能夠快速建立強大且可自訂的 API。 它使團隊能夠輕鬆建立和管理內容豐富的網站和應用程式，為各種專案提供靈活性和可擴展性。  ## 16\. [Plausible](https://github.com/plausible/analytics) 一種開源網路分析工具，旨在為網站所有者提供對其網站效能的簡單且注重隱私的見解。 它提供用戶友好、輕量級的跟踪，且不會損害存取者的隱私，使其成為那些重視資料分析而無需侵入性跟踪方法的人的理想選擇。  ## 17\. [Astro](https://github.com/withastro/astro) 現代靜態網站產生器，透過僅傳送頁面所需的 JavaScript 來提供閃電般的效能，從而實現近乎即時的載入時間。 它將傳統伺服器渲染框架的靈活性與靜態網站產生器的速度相結合，使其成為建立高效動態網站的絕佳選擇。  ## 18\. [Remix](https://github.com/remix-run/remix) 用於建立現代 JavaScript 應用程式的 Web 框架，注重速度和開發人員體驗。 它使開發人員能夠透過無縫組合伺服器渲染和客戶端渲染的內容來建立高效能的 Web 應用程式。  ## 19\. [Tensorflow](https://github.com/tensorflow/tensorflow) 由Google開發的開源機器學習框架。 它為建立和部署機器學習模型提供了靈活且全面的生態系統，使其成為人工智慧領域研究人員和開發人員的熱門選擇。  ## 20\. [Flutter](https://github.com/flutter/flutter) 由 Google 建立的開源 UI 軟體開發工具包，以其從單一程式碼庫建立適用於行動、Web 和桌面的本機編譯應用程式的能力而聞名。 它使開發人員能夠使用單一程式語言 Dart 跨多個平台建立美觀、快速且高度可自訂的使用者介面。  ## 21\. [Kubernetes](https://github.com/kubernetes/kubernetes) 一個開源容器編排平台，可自動執行容器化應用程式的部署、擴充和管理。 它為編排容器提供了強大而靈活的基礎架構，使在雲端原生環境中大規模管理複雜的分散式系統變得更加容易。 ## 22\. [Docker](https://www.docker.com/community/open-source/) 一個開源工具，可簡化多容器 Docker 應用程式的管理。 它允許開發人員使用簡單的 YAML 檔案定義和執行多容器應用程式，從而更輕鬆地編排和部署複雜的服務。  ## 23\. [Chromium](https://github.com/chromium/chromium) Google 的一個開源瀏覽器專案，旨在為所有使用者建立更安全、更快、更穩定的網路體驗方式。 它是開發人員在網路瀏覽技術領域做出貢獻和創新的平台。  ## 24\. [Linux 核心](https://github.com/torvalds/linux) 由 Linus Torvalds 和全球貢獻者社群開發的開源、類別 Unix 作業系統核心。 它作為各種基於 Linux 的作業系統的核心元件，提供硬體互動和系統管理的基本功能。  --- 以上，簡單分享！
你的轉職路上，還缺少一份自學作業包！寫完這幾包，直接拿作品去面試上班！
本論壇另有附設一個 LINE 新手發問＆交流群組！歡迎加入討論！
