整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
php js jquery功能片段#
唯一需求：表格id。
注意：因提交數據不能包含\n，所以要替換。呈現時可以替換回換行符。
<script type="text/javascript">
/**
* 遍歷表格內容后返回數組
* @param string id 表格id
* @return Array 或者JSON
*/
function getTableContent(id) {
var mytable = document.getElementById(id);
var data = [];
var tmpTxt;
for(var i = 0, rows = mytable.rows.length; i < rows; i++) {
for(var j = 0, cells = mytable.rows[i].cells.length; j < cells; j++) {
if(!data[i]) {
data[i] = new Array();
}
tmpTxt = mytable.rows[i].cells[j].innerHTML;
//tmpTxt = tmpTxt.replace(/<[^>]+>/gi,'');//過濾全部的html標簽，不包括內容
//tmpTxt =tmpTxt.replace(/\s/gi,'');
tmpTxt =tmpTxt.replace(/\n/gi,'<br>');
//data[i][j] = tmpTxt;
data[i][j] = tmpTxt.replace(/ /g, ""); //替換全角空格
}
}
//var JSONdata=data;
var JSONdata = JSON.stringify(data); //序列化數組JSON.stringify(data) 反序列化數組JSON.parse(data)
return JSONdata;
//return data;//返回數組
}
</script>
本文中，我們將介紹GitHub上頂級的JavaScript開源項目。
作者 | Isha Jauhari
譯者 | 彎月，責編 | 屠敏
以下為譯文：
JavaScript是當今最全能的流行編程語言之一。JavaScript之所以如此受歡迎，是因為它與HTML以及CSS構成了互聯網的核心，為我們提供了可視化的當今互聯網。
盡管最初JavaScript的設計意圖是作為一門腳本語言，編寫前端Web應用程序，然而如今它已經滲透了開發領域的方方面面。因此，JavaScript成為了GitHub（全球最大的軟件開發及共享平臺）用戶最常使用的語言，也就不足為奇了。
GitHub是目前最主要的共享代碼和開源項目的平臺，自然有許多項目都是用JavaScript編寫的。 在本文中，我們將介紹GitHub上頂級的JavaScript開源項目。
React：Facebook的JavaScript開源代碼庫
React可以說是世界上使用最廣泛的開源項目之一，由Facebook創建。我們可以使用這個庫輕松地在Web應用程序中創建用戶界面。而且開發新功能也異常容易，開發人員也不必擔心影響到任何現有的代碼。
React Native建立在React之上，它將React的功能擴展到了移動應用程序上，也促使React成為了廣泛使用的開發平臺。
GitHub代碼庫鏈接：https://github.com/facebook/react
TensorFlow.js
在過去的幾年中，隨著人們對機器學習的興趣日益增加，涌現了很多為構建更出色的庫而努力的項目，因為他們都希望降低創建機器學習模型的難度。著名的TensorFlow庫最初是用Python編寫的，后來又衍生出了JavaScript版的TensorFlow.js。
在轉換為JavaScript后，我們就可以利用這個庫在Web應用程序中構建和部署機器學習模型，而且還可以放到移動應用中。TensorFlow.js可以在瀏覽器中訓練機器學習模型，因此降低了服務器訓練模型的計算開銷。
在這個庫的幫助下，我們可以將機器學習應用擴展到移動應用程序，盡管對于機器學習應用程序而言，移動設備的計算能力嚴重不足。
GitHub代碼庫鏈接：https://github.com/tensorflow/tfjs
Node.js
Node.js是開源的Javascript運行時環境。它是在Chrome瀏覽器的V8引擎之上構建的。沒有單獨的運行時環境，JavaScript只能直接在瀏覽器的環境中運行。但是有了Node.js以后，JavaScript可以像Python那樣，作為獨立的腳本語言運行。
開發人員隨時可以在自己的機器上測試JavaScript，甚至不需要瀏覽器。因此，原本只能為各個網站帶來交互性的JavaScript功能幾乎擴展到了所有領域。
GitHub代碼庫鏈接：https://github.com/nodejs/node
AngularJS
AngularJS是業界最古老的前端JavaScript開源框架之一。該框架最初由Mi?ko Hevery開發，后來發展成了GitHub上排名前十的JavaScript項目之一。
Angular開發的Web應用程序可以實現跨平臺，因為它們可與各種設備兼容，無論是移動設備、臺式機還是平板電腦。無論在速度，還是性能和可伸縮性方面，AngularJS都可以與其他框架一較高低。
AngularJS的宣傳中稱其能夠滿足巨大的數據需求，其提供的可擴展基礎架構可以支持Google等大規模的應用程序。
GitHub代碼庫鏈接：https://github.com/angular/angular.js
jQuery
jQuery開源代碼庫可以大幅簡化客戶端的HTML腳本。它的座右銘是“少寫，多做”，而它也的確做到了。jQuery將最常見的JavaScript任務打包成了方法，從而減輕了編程的工作量，并提高了編程的效率。據估計，jQuery是網頁中使用率最高的庫。
GitHub代碼庫鏈接：https://github.com/jquery/jquery
npm
npm的全稱是Node Package Manager，這個工具庫的功能正如其名。它可以管理已安裝的Node.js軟件包，還可以更方便地安裝其他軟件包。
GitHub代碼庫鏈接：https://github.com/npm/cli
Vue.js
Vue.js是GitHub上獲星最多的JavaScript開源框架。Vue.js是用于構建交互式用戶界面的開源JavaScript框架。Vue側重于與其他JavaScript庫的集成，旨在簡化和組織Web應用程序。最初由Evan You于2014年開發。
Vue的宣傳中稱這是一個易于學習、使用和維護的漸進式JavaScript框架。
GitHub代碼庫鏈接：https://github.com/vuejs/vue
Ember.js
Ember是一個JavaScript開源框架，它可以幫助開發人員創建可擴展的單頁Web應用程序，類似于AngularJS。Ember.js注重生產力、增強功能的簡便性以及對開發人員的友好性。
Ember.js是目前對開發人員最友好的框架之一，新手只需幾分鐘即可構建應用程序。 Netflix等許多人氣網站都使用了Ember。
GitHub代碼庫鏈接：https://github.com/emberjs/ember.js
MeteorJS
Meteor是面向Web、移動和桌面的跨平臺開源平臺。Meteor實現了與其他各種JavaScript框架的無縫集成。 MeteorJS注重優化代碼的規模、跨平臺兼容性以及與其他庫的集成。
與其他框架不同，Meteor不僅限于前端Web應用程序，它還可以快速建立原型，以及自動適應數據的變化。除此之外，Meteor還提供了許多增強功能的大型界面。
GitHub代碼庫鏈接：https://github.com/meteor/meteor
Polymer
Polymer是一個JavaScript開源庫，使用所謂的“ Web組件”構建應用程序。鼓勵開發人員重用Web的小部件或塊，從而促進了各個Web元素的互操作性。這個想法已在許多大型項目中得到了應用，例如YouTube和Google Earth。
GitHub代碼庫鏈接：https://github.com/Polymer/polymer
除了上述開源項目之外，GitHub上還有很多項目也同樣出色。而且，這些項目還有很多正在開發的功能，敬請期待。
原文：https://medium.com/javascript-in-plain-english/top-10-javascript-open-source-projects-on-github-d1a83d502e12
本文為 CSDN 翻譯，轉載請注明來源出處。
于有人站出來，打算跟 JavaScript 生態系統正面交鋒了。這家伙知道自己在干什么，而且也描繪出了干掉 JS 之后要創造的美好新世界。
2022 年，前 Stripe 開發人員 Jared Sumner 發布了Bun，一種用 Zig 編程語言開發的運行時。據我所知，Bun 最初只是種 JavaScript webserver，但在后續發展中逐漸醞釀出了全面顛覆 JS 生態系統的野心。
按我個人的關注度排序，Bun 的優勢主要有以下幾點：
Bun 改朝換代的思路看著非常簡單粗暴——JS 有的我也要有，而且我的要更簡單、更高效。這里沒有小聰明、沒有曲線救國，要的就是正面對抗而且樣樣比 JS 強。用一種低級語言，編寫出運行極快的代碼，這就是 Bun。
Bun 還很年輕，也許還沒準備好迎接那些令人頭大的真實生產用例。但它確實發展迅速，所以如果 Bun 真能在幾年后快速占據市場份額，我也覺得完全在情理之中。
不知道大家在實際工作中有沒有編寫過 JS 或 TS 生產代碼，那種體驗挺難受的。多數情況下，開源工具和小項目也能良好運轉，但一到商業和企業級用例上就經常掉鏈子。而因為傳統、常規的路線走不通，企業只能試遍各種辦法讓項目能在生產環境中正常起效。
例如，TypeScript 在涉及多位開發者的項目中解決了不少老大難問題，所以只要 JS 的路子走不通，我們就能隨時引入 TS 進行代碼轉換。這里要真心感謝微軟。NPM 對大型項目和單體 repo 來說速度太慢，所以公司可能需要轉向 Yarn。這里又要謝謝 Facebook。總之，我們就是在拼了命地東拼西湊，最終搞出性能勉強說得過去的成果。
作者提到自己所在企業的整個單體 repo 執行 eslint 需要耗費 79 秒，所以只能單獨配置，保證只對發生變更的文件執行 lint。雖然會引入更多復雜元素，但也沒有辦法。
總的來說，無數開發者都在用自己的辦法加速 JS 工具鏈中的某些特定部分。比如用 Yarn 3 那瘋狂的“即插即用”節點模塊虛擬化速度來替代 NPM，或者用基于 JSON Schema 的請求解析器解決 Express 的低速問題。其實大多數原有工具都有類似的問題，而且它們是由 JS 開發者編寫、專為 JS 開發者服務的。用 JS 編寫，就等同于速度很慢……
于是，一些用更快語言編寫的高速工具開始流行起來。每家擁有大型 React 應用程序的企業，肯定都經歷過 WebPack 構建要花掉整整一分鐘的折磨。為此，他們必須轉向用 Go 語言編寫 esbuild。同樣的，其他語言版本的 eslint 替代方案也開始出現，比如用 Rust 重寫 Rome。
Bun 是這種趨勢的自然延續，但采取的卻是自下而上的推進路徑。這個項目的核心思路就是從零起步、以內置“batteries”的方式，用低級語言重寫整個 JavaScript 生態系統。而且到目前為止，效果還真心不錯。
如果 Bun 只是對所有 JS 輔助工具進行重寫，我當然也很歡迎，但那樣的它只能算是 Node.js 的又一個替代品。Bun 并沒有這樣偷懶，它努力讓解釋器本身也快起來。
Bun 是用 Zig 編寫的，而且配合蘋果開發的 JavaScriptCore，類似于 Node 使用 v8。Zig 是一種新興的低級語言，主要活躍在 C++占主導地位的場景。我不是低級開發者，所以沒親自用過，更多細節就留給其他技術更強的博主吧。在本文中，大家只要知道 Zig 寫的代碼很快就行了。至于 JavaScriptCore，它的作用跟 v8 一樣，只是 v8 來自谷歌、而它來自蘋果。Safari 和蘋果的很多其他項目都有用到 JavaScriptCore。
Bun 比 Node 到底快多少還沒有定論，但據稱在某些特定場景下要快得多。很多朋友可能沒經歷過 io.js 剛誕生的時代，總結來說，那時候一個單純能提高解釋器速度的分叉就足以撼動整個 JS 生態系統。而 Bun 的啟動速度又比 Node 快得多。我自己的親身實驗是 7 毫秒左右，大概比 Node.js 快了 10 倍，所以特別適合無服務器環境和邊緣計算場景。
這一波顛覆依靠的不只是速度優勢，Bun 還添加了不少優秀的標準庫函數。例如，Bun.write()就是用于編寫文件的新函數，它會返回一個承諾，而且號稱可以通過更適合的系統調用進一步加快速度。
說起 Node API，Bun 目前已經能支持約 90%的現有 Node API。Node 規模很大，其中總有一些別說沒用過、可能大家聽都沒聽過的東西（比如 new AsyncLocalStorage() ），所以能支持 90%已經很好了。誰會運行 NPM 上的所有包呢？根本不需要，而且基本不影響我們的日常開發。
順便說一句，TypeScript 在 Bun 這邊可是相當有排面，直接調用 bun my-ts-file.ts 就行。Deno 對 TS 的支持也就這個水平了。使用 Bun 對新項目進行模板化，或者把 bun-types 添加到 tsconfig 當中，IDE 中的自動補全功能就將適用于這些新函數！
Bun 項目最初目標之一就是創建一種更快、更強大的 TypeScript 編譯器。這個目標現在已經實現，同時被淹沒在其他眾多功能中。但目前，它仍然無法支持某些比較高級的 TypeScript 配置和功能，例如裝飾器、tsconfig 中將多個配置合并起來的擴展功能等。
下面來聊 Bun 最振奮人心的能力之一——替代 NPM。它真的很快，能讓人人都滿意那種快。
在 Linux 上，bun install 的包安裝速度可以達到 npm install 的 20 倍到 100 倍。在 macOS 上，也能達到 4 倍到 80 倍。
我敢肯定，沒 cache 快，有 cache 更快，總之就是快。
之前就已經有很多方案在努力幫 NPM 提速了。比如大家熟悉的 Yarn Plug-n-Play，它的思路就是徹底放棄 node_modules 文件夾來加快包安裝速度。雖然有一定效果，但在實際使用中，提速并沒有那么顯著，而且還需要處理大量 polyfill 和 escape-hatches 操作。能用是能用，但我個人實在是不想再用、也不打算向大家推薦。
Pnpm 是另一種新興的 NPM 替代方案，在繼續使用 TypeScript 編寫的同時實現了一部分智能優化。在 pnpm 中，node_modules 是通過符號鏈接從全局緩存中訪問的，每個包都能在自己的獨立時間內完成安裝，無需等待其他包完成當前操作。
Bun 的基本思路跟 NPM 一樣，但速度卻更快。它有自己的 lockfile 格式，而且其中的 node_modules 和 package.json 看起來沒什么變化。如果大家對文件系統調用比較熟悉，可以結合低級訪問和快速語言實現極快的安裝效果，而且無需任何花哨的技巧。
現在，Bun 還不提供工作空間支持，所以暫時沒法對接那些期待它來拯救的大型單體 repo（我們的項目也屬于這類）。但好在 Bun 正保持著迅猛的發展速度，幾周前剛公布的路線圖也提到了工作空間支持。
請注意，大家不用全面轉向 Bun 也能把它當成包管理器、轉譯器或者解釋器。只需要選擇我們需要的部分，丟棄其余的部分就行。我猜 Bun 的初步普及可能也會走這條道路，就是先當個好用的包管理器，其他的以后再說。這樣接受門檻會變得更低一些。
Bun 當中包含一個用于網絡瀏覽器的轉譯器，這明顯是把矛頭指向了 webpack 和 esbuild。順帶一提，Bun 中的解析器就是 esbuild 解析器的一個 Zig 端口，輕松愉快。
Bun 已經支持多種文件類型，css、svg、tsx、jsx、ts 之類的都行。JS 中的 CSS 等高級選項似乎也能在 Bun 上正常工作。
由于 Bun 包含一個帶有幾套內置模板的項目腳手架，所以這里我們可以直接調用：
bun create react my-app
之后，我運行 bun dev 并在瀏覽器里運行了一個 react 應用程序。我猜可以把 react-scripts 直接添加到 Bun 替換過的工具列表當中。
把文件擴展名從 jsx 改成 tsx，程序就立刻生效了。導入 svg，沒有問題。開發模式似乎還支持 HMR，也就是前端開發者在使用 webpack 時的一大必備工具。
那么，轉譯器方面還缺什么嗎？缺的還多，畢竟生產環境的要求可不簡單。首先就是最小化了，這是實際用戶最希望在后續發展路線圖上看到的功能。對于大型插件生態系統來說，還必須要有能夠支持不同文件格式的打包工具。例如，目前.vue 文件和.scss 還沒有實際落地，特別是.scss，這東西幾代開發者都在用，必須趕緊實現。目前我還不確定 Bun 捆綁器的可插拔性怎么樣，而且最重點的是要直接在框架之內解決問題，不要依賴大量外部開源包。
Bun 還把不少傳統意義上的框架元素添加到了標準庫當中。就個人而言，我對那些庫類型功能不太感興趣，畢竟 Node 中已經有很多適用于 http server 的功能長城了。
Bun 的 webserver 看起來非常簡單。Express 雖然有點落后于時代，但對大多數開發者來說仍然夠用（開發團隊今年還剛剛提供了對承諾的支持）。Bun server 好像跟 Cloudflare Worker 頗為相信。只要 JavaScript 生態中的其他問題逐一得到解決，也許 Bun 的開發團隊會轉回頭好好打磨一下 webserver 吧。需要注意的是，在某些情況下，巧用系統調用可以讓 Bun webserver 的速度提高一倍，特別是在文件處理過程中。
至于新的 SQLite 適配器，我覺得之前 Node 中的 sqlite 實現思路有點脫離正常人的腦洞。現在大多數開發者會把舊有 sqlite 3 包跟 sqlite 打包器結合使用，借此實現對承諾的支持。Bun 的解決方案看起來更簡潔，所以就算速度上沒啥大優勢，我也愿意用。
我最擔心的是，Bun 的這么多優點難以轉化成對社區成員的實際吸引力。Bun 本身就是 JS 生態系統的完整替代品，這么巨大的轉變一般人恐怕很難快速接受。
Bun 還很年輕，目前沒有完整的說明文檔。對于大多數問題，我們只能查閱長長的自述文件。但創建一個 docusaurus 站點，再配合具備完整內聯注釋的 TypeScript 類型生成相應的 typedoc 并不困難，所以我猜這一點應該很快就能解決。
服務端渲染 React 每秒 HTTP 請求數 (Linux AMD64) 對比，來自 Bun 官網
如果你從來沒聽說過 Deno、也不打算了解，直接跳過這章也行。而且就個人而言，我覺得 Bun 比 Deno 更有搞頭、更有前途。
來自 Node 締造者的 Deno 宣稱解決了一些長期困擾開發者的老大難問題。它把 es-modules 設定成默認值，引入了第一方 TypeScript 支持（無需在發布前轉譯 NPM 模塊）等等。但在我看來，Deno 在解決老問題的同時，也引入了不少新問題。
首先，Deno 對包解析和語法做的變更過于大刀闊斧，導致沒法跟原有 NPM 生態系統兼容。換言之，Deno 需要培養起自己的全新庫生態。雖然 Deno 慢慢開始支持一些早期庫，但我覺得一個項目的影響力會直接決定它的發展上限，所以 Deno 的邊界估計也就到這了。當然也有一些變通方法，比如把 NPM 包轉換成 Deno 包的 CDN，但我覺得這不是什么好招。
Deno 還有不少在我看來暴露其半成品身份的問題，比如缺少 package.json。無論是從模塊解析的角度來看，還是從缺少 manifest 文件出發，Deno 都不允許開發者為自己的包編寫可擴展元數據。GoLang 甚至專門為此引入了 go.mod。
另外，我覺得 Deno 設計中的沙箱/權限系統應該是正確的思路，只是粒度不夠細。它位于整個項目的頂層、脫離了包層次，這意味著大型應用程序最終還是需要所有權限，于是問題又回到了原點。而且作為一家安全公司，我們對 Deno 無法保護大型應用免受供應鏈攻擊而頗感失望。當然，Bun 也沒說打算如何解決這個問題，我這里只是發泄一下自己的不滿。
所以總結起來：Bun 擁有遠超 Deno 的發展潛力。具體原因如下：
如上所述，Rome 就是個驗證器。Rome 的維護者們已經開始用 Rust 代替 JS 進行重寫了，而且 79 秒的驗證時長也有點夸張。（不騙人，我們的 eslint 就是用了 79 秒。）
從路線圖來看，Rome 還打算引入捆綁器、文檔生成器、壓縮器、類型檢查器、測試框架等等。但這一切尚未完成，而 Bun 明顯已經走得更遠。至少 Rome 還沒開始重寫 Node 核心本身，所以我覺得它的影響力也就差不多這樣了。
總之，很多項目都發現了 Node 生態系統中的現有問題，而且各自嘗試在統一的高性能框架中將其一舉解決。接下來，就看誰發展得更快了。
這里我想把視野縮小一點，通過具體案例聊聊開源世界中的生態陣營是怎么產生的。
相信很多 Node 開發者都知道 Jest 是怎樣力壓 Mocha 測試框架，一路迅猛崛起的。Mocha 想當年也是人們首選的測試運行程序，效果不錯而且語法優秀，但只要涉及更復雜的需求或者斷言，就得引入其他模塊和插件。好在有了社區協作，插件也不算太難找。總之，開發者需要具備更廣泛的知識才能引入相應的庫。
后來 Facebook 搞出了 Jest，一套內含“batteries”的測試框架。它借鑒了 Mocha 語法和庫，并把一切整合到了單一框架中。Jest 什么都能解決，從偽造時間到需求的檢測和模擬。Jest 也有擴展空間，但我在實際工作中就用過一次。大部分概念驗證和設計都是由 Mocha 承擔的，作為后來者的 Jest 只是把成果統一了起來并使其變得更易于訪問。雖然 Mocha 也不乏鐵桿粉絲，但 Jest 確實更受歡迎。
開源世界中有很多這樣的案例。首創解決方案拿下先發優勢，而后續一旦增長乏力，就會有熱心的開發商把功能整合起來。這也讓我想到了 Linux 大家族還未統一時的 systemd。如今，systemd 幾乎可以管理大多數 Linux 發行版上的所有內容，而 Bun 也許會以同樣的方式席卷整個 JavaScript 世界。
我意識到從開源的角度來看，這種合并和統一似乎與開源精神相悖，但用大量庫實現簡單需求確實已經成為折磨開發者們的痛點。而且如果每個庫都有相應的維護團隊，那惡意黑客通過簡單的偽造郵件域就能實施供應鏈攻擊。我們不想這樣，但現實就是如此殘酷。老手尚且容易中招，更遑論剛接觸大量名稱、還不熟悉種種語言的新人了。所以從務實的角度出發，我覺得很多朋友應該跟我一樣，并不覺得把更多常用功能引入標準庫、將多種開發工具整合進統一框架屬于歷史的倒退。
截至 2022 年 7 月，Bun 還是沒有做好進軍生產環境的準備，但我強烈建議大家自己裝上試一試。整個流程非常便捷，而且我覺得現在的 Bun 已經足夠應付小型子項目或者公司里的簡單內部儀表板了。
我不敢說 Bun 在未來幾年能否甚至如何重塑 JavaScript 的面貌，但我真心對它的發展充滿期待。
原文鏈接：
https://www.lunasec.io/docs/blog/bun-first-look/
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
