1樓：
雖然這是乙個墳帖，但是不影響2023年我仍然選擇grunt+babel+browserify搭建專案。置於publicPath什麼的babel做替換。
2樓：
簡直是前端的福音，早就被webpack各種玄學配置搞煩了，自己寫了個parcel的demo，修復了實際開發中遇到的幾個坑，需要的朋友可以看下：daoket/parcelProjectDemo
3樓：
使用了一下，簡潔和快速是最大的賣點。
不過一上來，官網最簡單的例子都不能執行成功。查了一下，是node版本不是8以上的問題。
自己玩玩可以，真的要在專案中跑還是有點慌的。
4樓：lqs469
幾乎所有框架都會向兩個方向去發展: 乙個方向功能強大, 穩定有效, 但是配置複雜, 學習成本高, 乙個方向配置簡單, 即開即用, 但是功能有限. 無非是看開發者針對不同場景選哪個罷了.
5樓：司徒正美
應該能從webpack下搶到許多肉，就像rollup那樣，但專案中還是需要各種處理，只有像webpack 那樣豐富的生態圈才能滿足大家層出不窮的奇葩需求
6樓：
一直在等這種零配置（少配置）的構建工具，一周時間star數暴增6k多的事實證明不少人都喜歡更簡單一點的工具。webpack實在是看著就頭疼，你作為乙個構建工具，連最基本的js.css這些都要配外掛程式才能用，真的好嗎？
不管parcel未來如何，至少讓大家知道webpack這種重配置的不是唯一的選擇，競爭能促進大家都變得更好
7樓：大空
被吐槽了，更新一下，昨天看了看也嘗試了一下。發現不支援sourcemap.....瞬間就萎了然後我搜了一下issue 提到sourcemap太慢所以暫時也沒支援具體link現在爪機不好補上去然後有人提到了可以借鑑cheap eval方式。
嘛，原理具體的還麼搞的很清楚，但是目前來看，我肯定不會在正式專案中用的。
0配置的話，約束和限制以及一些潛在需要自定義的配置項都可能存在(尤其是環境和場景限制時)。
樓上有大大回答中也提到了還有一些其它的功能特性需要支援。
嘛我是很看好的(雖然我只是個喳猹
8樓：大大大豬豬
parceljs 是 fis3 的改進版，將 webpack 的優點融合進了 fis3，再優化下了使用體驗。
parceljs 說自己是0配置有點誇張，0配置的東西是不可能做到廣範圍使用的。如果處理簡單的專案 webpack 其實也接近於0配置。
webpack 最大的優點其實在於它龐大的社群，parceljs 也提供了 Packagers 和 Plugins 機制，但這需要時間的積累。
目前看來parceljs無法勝任專案的需要。
webpack 以 js為入口，parceljs以html為入口，這方面我更贊成webpack，因為 js 運用範圍越來越廣。
以上：我覺得 parceljs 的前景不會很好。
9樓：陳成
看到 ParcelJS 還是眼前一亮的。
新建 index.html、index.js 和 index.
css，然後 parcel index.html，就能拿到可執行的 html、js 和 css 組合。html可以作為入口正是我期望的，這讓前端開發回歸到本來的狀態，很舒服。
ParcelJS 是以 assets 方式組織的，assets 可以是任意檔案，所以你可以構建任意檔案。而在 webpack 中，只有 JS 是一等公民（webpack@4 會增加 CSS 為一等公民），所以必須是以 JS 為入口去組織其他檔案，這很彆扭。
速度是 ParcelJS 主要賣點。體驗下來確實快，原因是多核（通過 worker 平行構建）和檔案系統快取（二次構建會快，和 webpack 的 dll 異曲同工）。不過 webpack 也有多核處理 loader 和壓縮的外掛程式，沒對比過，不知道差異如何。
另外 webpack 的構建速度慢在 dev 模式下還是可以的，主要還是壓縮慢，在壓縮速度上沒有突破，僅提公升編譯速度，只能解決一部分問題。
關於 0 配置。ParcelJS 本身是 0 配置的，但 HTML、JS 和 CSS 分別是通過 posthtml、babel 和 postcss 處理的，所以我們得分別配 .posthtmlrc、.
babelrc 和 .postcssrc。
功能上，Code Splitting 和 Hot Module Replacement 沒啥新的，和 webpack 等工具相同。對於我來說，功能目前還缺 SourceMap、公共檔案提取、publicPath 配置（Code Splitting 需要）、Tree Shake 和 Scope Hoist 等。
很好的開始，持續維護的話應該不缺使用者。
10樓：周左左
約定大於配置的新產物
但是對於打包工具來說速度不是最首要的，生態才是。
下面從實踐出發談談我個人對打包工具的理解
曾經
打包工具的出現，很大程度上緩解了傳統的手動引入資源檔案(css, js等)到html帶來的不便。從。從最初的require.
js模組載入庫以及相關規範出現開始，社群就開始進行各種嘗試。到gulp利用pipe以及watch概念來構建前端自動化流程，之後引入了browserify打包作為構建工具中的一環，最終到了現在webpack集大成者。
webpack當年首先是作為一款與browserify功能相當的打包工具/庫，出現在社群中的。所以你會常常看見社群裡的教程/問答貼:gulp + webpack或是gulp + browserify。
當然還有但是風韻猶存的grunt，以上組合可以自行想象。
之後webpack重點開發了自身作為乙個構建工具的作用，而不是僅僅作為乙個打包庫寄人籬下。在這之前，我們都沒見過打包工具需要去監聽檔案變動而觸發打包動作(例子乙個)，他們都只是從gulp/grunt這種構建工具的pipe來獲取到具體變化，再去執行打包動作。所以一句話，像監聽變化、assets資源優化等等這種事情，在以往打包工具/庫是觸及不到的。
打包工具只針對js作為入口檔案，遞迴獲取依賴，建立依賴樹，逐個利用自帶的或第三方的中介軟體來最終輸出bundle js。
當下
剛剛提到webpack不滿足於自己僅僅只是一介打包工具而存活於世，或是說社群本意就是將它打造成為一款前端專案構建工具。webpack推出了一系列的功能，漸漸發覺，gulp能做的事情，現在webpack都能做到了，甚至還多了一系列的gulp配合打包庫才能做到的功能。Parcel無配置，從assets出發的構建工具，嶄露頭角。
我超喜歡在webpack的個個loader、plugin都是人才說話又好聽
未來
未來肯定是屬於操作簡單便捷的構建工具的，它要能支援js、html、css三劍客的打包，速度足夠快，生態夠好。但是依然要有定製性：
一半是傳統多頁面應用，一半是SPA的業務場景。
新增各種稀奇古怪的js語言。
針對css進行優化，像js那樣能夠提取出common chunk。webpack 4新增了許多特性對css打包進行了支援。我們拭目以待。
針對業務進行分組打包，而不是所有的entry都要強制打包（目前可以利用多config特性來解決，但是要小心webpack-dev-server的坑）。
思考：針對場景的配置成本但是如果你不用前端框架，或者嫌這些cli太重了，或不透明（其實不然），當然可以用parcel。
但是如果你又要引入typescript或者一些其他神奇的plugin到parcel中，那麼又成了鐵頭娃、填坑俠。
如何評價NCT DREAM的迷你三輯《We Boom》及其MV？
主打歌很中毒仁俊的高音part很吸睛說明傻帽很重視他的主唱實力熊依舊很穩每一句都是killing part 娜的part ice cream雖然很亮眼但是來的太刻意了 因為是00line要畢業所以中輸真的很強但是初動16w 中輸12w可以看出10個月的摳腳nh真的少了很多粉啊這次沒有中文版的操作有點...
如何阻止web網頁上的操作修改伺服器上的資料？
這個邏輯上無法避免，所以網遊反作弊才那麼麻煩。關於鑑權什麼都是答非所問。網頁本來就缺乏一些自身驗證能力，而作為CS架構，只要徹底破解了C端，那麼必然可以傳送任意資料給S端，S端不能從邏輯上判斷資料的合法性。換句話說，你的這個情況，甚至不需要修改JS，只要偽造乙個HTTP請求就可以了。而對策，兩方面，...
如何評價堅果 Pro 的配置？
好的設計需要好的硬體做支援。先說soc。任何手機公司都沒有辦法把626優化到835的程度，甚至660都不可能，否則驍龍就倒閉了。所以老羅也在說他的系統優化的好，也只是譁眾取寵。再說螢幕。我沒曾想到老羅敢有這樣一塊螢幕來欺騙消費者，這是我用過的手機裡面最差的螢幕，沒有之一。攝像頭，拍照就是湊數，有了這...