[대비] 웹 패키지야, 소포야, 뭐가 더 좋아?
10120 단어 webpackjavascriptwebdevparcel
거의 모든 현대 웹 개발자들은 웹 팩을 사용한다. 의도적이든 무의식적이든 그들이 사용하는 프레임워크는 웹 팩에서 도움을 받아 그들의 응용 프로그램을 묶는다.
또 다른 번들을 Parcel이라고 하는데, 이것은 제로 설정 번들이라고 주장한다.
우리 이 두 사람이 행동하는 것을 봅시다.
내가 이 글을 쓸 때, 나는 최신 안정적인 버전의 웹팩 and Parcel을 사용하고 있었다.웹 버전은 4.41.5이고 패키지 버전은 1.12.4입니다.
이것은 점에 기초한 문장이 될 것입니다. 따라서 이 점들을 추적하고 마지막에 어느 것이 더 좋은지 볼 수 있습니다.
모든 부분에는 10점 표시가 있는데, 이 묶음 중 어느 것이든 0에서 10 사이의 모든 숫자를 얻을 수 있다.
이것은 단지 나의 관점일 뿐, 너의 관점은 다를 수 있다.그래서 이것은 단지 개인의 관점일 뿐이다.(나도 몇 가지 이유를 포함할 수 있지만)
무엇이 묶음기입니까?
만약 당신이 bundler가 무엇인지 모른다면, bundler는 간단한 개념을 따른다. 예를 들어 Sass, Less, Stylus, 이미지, 글꼴, 자바스크립트 파일 등 스타일 파일을 포함하여 파일을 주면 빈틈없는 방식으로 조립할 수 있기 때문에 생산에서 완벽하게 작업할 수 있다.추가 작업 없이 CSS 사전 프로세서를 컴파일하고 포함할 수 있습니다.
입문
이 패키지를 사용하기 시작하려면 먼저 설치해야 합니다. (이것은 좋지 않습니까?)그러나 몇 가지 절차가 있다. 우리는 그 중에서 시작할 것이다.
Webpack을 설치한 후, webpack.config.js라는 파일을 만들어야 합니다. 여기에는 웹 팩이 패키지를 어떻게 처리하는지 알 수 있도록 설정을 포함해야 합니다.
매우 기본적인 웹 페이지 설정은 다음과 같다.
const path = require('path');
module.exports = {
entry: './src/index.js',
output: {
filename: 'main.js',
path: path.resolve(__dirname, 'dist'),
},
};
그리고 웹 패키지를 시작해서 파일을 감시할 수 있습니다.
그러나 Parcel에서 일어난 일은 매우 미친 짓입니다. index.html 파일을 만들고 평소와 같이 상대적인 경로를 사용하여 스크립트를 포함하면 다음과 같습니다.
<html>
<body>
<script src="./index.js"></script>
</body>
</html>
그리고 당신의 index.html 파일을 보기 시작합니다. 이렇게.Parcel에서는 HTML 파일이 아닌 JavaScript 파일도 볼 수 있습니다.
나는 10번 소포를 표시했지만, 웹 페이지는 반드시 여기에 8번 소포를 표시해야 한다.
웹 페이지: 8
소포: 10
종속 및 사전 프로세서 설치
bundler 사용에 관해서, 우리가 앞으로 해야 할 주요 일은 Sass 또는 더 적은 프로세서를 사용하는 것을 돕는 것입니다.
좋습니다. 이것이 바로 웹 패키지를 어떻게 설정하여 당신의 프로세서를 식별해야 하는지입니다.
module.exports = {
module: {
rules: [
{
test: /\.s[ac]ss$/i,
use: [
'style-loader',
'css-loader',
'sass-loader',
],
},
],
},
};
필요한 npm 패키지:
npm i --save style-loader css-loader sass-loader
무섭게 보이지만 솔직히 어렵지 않아요.
소포 어때요?당신은 소포의 클레임 명세서를 기억합니까?제로 구성!그러니까 아무것도 안 해도 돼.필요한 모든 물건은 자동으로 설치되어 먼지를 털지 않는다.
Parcel은 10점, Webpack은 8점을 받았다.
웹 페이지: 16
소포:20
스피드
본고가 당신을 끌어들이는 가장 중요한 일 중 하나는 성능 테스트입니다.
이 묶음 중 어느 것이 더 빠른지 간단한 묶음 패키지를 시험해 봅시다.
나는 귀속기마다 세 번, 귀속기마다 세 개의 귀속 요청을 처음부터 실행할 것이다.app.js 은 포장 중인 파일입니다.그것은 단지 하나의 의존항, 즉 Vue만 있다.js와 aconsole.log.app.js :
import Vue from 'vue';
console.log('I\'m a bundle');
다음 차트에서는 처음 바인딩 (깨끗한 디렉터리) 하고 둘 다 생산 모드를 사용할 때 이 바인딩기가 어떻게 작동하는지 보여 줍니다.
묶는 기계
첫 번째 실행
두 번째 실행
세 번째 달리기
평균적
웹 패키지
272ms
261ms
262ms
265ms
소포
2440ms
2510ms
2470ms
2473.33ms
보시다시피 처음 연결할 때 웹 팩의 성능은 Parcel보다 훨씬 좋습니다 (거의 x9배).
같은 파일을 다시 보고 연결할 때 결과가 무엇인지 보여 줍니다.
이 테스트에 대해 저는 lorem ipsum 주석을 두 번 추가하고 삭제할 것입니다. 그래서 네 번입니다.
묶는 기계
첫 번째 실행
두 번째 실행
세 번째 달리기
제4라운드
평균적
웹 패키지
202ms
246ms
130ms
104ms
170.5ms
소포
71ms
69ms
67ms
54ms
65.25ms
이 예에서 Parcel은 웹 팩을 인수하여 웹 팩보다 더 빨리 실행한다(거의 2.5배).
웹 팩보다 패키지의 성능이 빠르지만 초기 묶음보다 더 중요합니다. 보통 한 번만 보고 실행하기 때문에 초기 묶음의 차이가 너무 큽니다.
나는 이 부분에서 웹 페이지 10과 소포 a9을 줄 것이다.
웹 페이지:26
소포:29
개발 서버
응용 프로그램을 구축할 때, 개발 서버를 검색하고 있을 가능성이 높습니다.
이 두 패키지는 모두 개발 서버를 제공하지만, 웹 팩을 단독 패키지로 설치하고 설정해야 합니다.
이 파일은 다음과 같습니다.
var path = require('path');
module.exports = {
//...
devServer: {
contentBase: path.join(__dirname, 'dist'),
compress: true,
port: 9000
}
};
웹 페이지는 여기에서 9, 소포는 10을 얻는다.
웹 페이지: 35
소포:39
코드 분할
그것이 현실 세계에 들어갔을 때, 코드 분할은 진정한 문제이다.거대하고 무거운 파일은 신속하게 불러올 수 없고, 사이트의 운행이 느린 것도 고객이나 방문자가 원하는 것이 아니다.
앞에서 말한 바와 같이, Parcel은 제로 설정의 코드 분할을 지원한다고 주장한 것은 사실이다.
그러나 웹 패키지는 약간의 설정이 필요하다.
그것들은 모두 동적 가져오기를 지원하는데, 이것은 매우 좋다.
하지만 이것은 얄미운 문제다.
코드를 묶으면 웹 패키지webpack.config.json 폴더의 모양입니다.
이것은 매우 깔끔하고 깨끗하다. 비록 동적 구성 요소를 분할하기 위한 설정이 필요하지만, 이것은 결코 어렵지 않다.
모든 컨텐트는 해당 폴더, 이미지, CSS, JavaScript 또는 글꼴에 있습니다.
이것이 바로 소포dist 폴더의 모습이다.패키지가 이 파일들을 관리하는 방식을 제어할 수 없습니다. dist 폴더가 완전히 평평해졌고, 더 심각한 것은 당신의 dist 폴더도 이 파일에 있습니다.이건 정말 엉망이야!
공평하게 말하자면, 설정 기능이 없기 때문에, 나는 그것에게 2를 주었는데, 이 절에서 웹 팩은 9를 얻었다.
웹 페이지: 44
소포:41
커뮤니티 및 사용
Webpack은 매우 유명합니다. 많은 프레임워크는 Webpack을 묶음으로 사용합니다. 예를 들어 제가 사랑하는 Nuxt를 사용합니다.js.지금까지 나는 어떤 프레임이 Parcel을 사용하는지 아직 모른다.
웹팩 뒤에는 더 큰 커뮤니티가 있습니다. 따라서 웹팩을 사용할 때 문제를 해결하는 방법을 더 많이 찾을 수 있습니다.
웹 패키지는 확장이 많고 좋은 설정을 사용할 수 있다.
그러나 이것은 소포가 미지의 묶음이라는 것을 의미하지는 않는다.
나는 여기서 웹 페이지에 10을 주고 소포는 7을 얻는다.
웹 페이지: 54
소포:48
옵션 및 사용자 정의
나는 너희들이 이 절에 무슨 일이 일어날지 이미 알고 있다고 생각한다.
맞춤형 제작에 있어서 웹팩은 왕이다.Parcel은 제로 설정 귀속기라고 주장하는데, 이것은 매우 좋지만, 기업급 응용 프로그램에서 그것을 필요로 할 때, 당신은 너무 많은 맞춤형 설정을 얻지 못했다.
Webpack은 필요에 따라 구성할 수 있는 수천 개의 옵션을 제공합니다.
웹팩은 10점, 소포는 2점을 받는다.
웹 페이지: 64
소포:50
결론
Webpack은 이곳의 우승자입니다. 앞으로 번거로움을 방지하기 위해 Webpack을 사용하는 것을 권장합니다.웹 패키지는 매우 안정적이고 믿을 만하다. 왜냐하면 나는 이미 수천 번을 사용했기 때문이다.
나는 소포를 좋아한다. 왜냐하면 그것은 매우 간단하지만, 웹 팩이 제공하는 모든 옵션을 희생해서, 나는 한 항목만 완성한 후에 소포를 더 이상 사용하지 않는다.Parcel이 플랫index.html 폴더 문제를 해결하고 추가 구성 옵션을 제공하면 Parcel을 다시 사용할 수 있습니다.
나는 구축 시간을 비교하고 도표를 그렸다.폴더 구조와 본문의 모든 그림과 상하문은 진실이다.만약 이 페이지를 연결하고 싶다면, 이것이 당신에게 아무런 문제가 되지 않도록 그것을 사용하십시오.
나는 네가 이 문장을 좋아하길 바란다.
아래의 평론 부분에서 당신의 생각을 저에게 알려주세요.
Reference
이 문제에 관하여([대비] 웹 패키지야, 소포야, 뭐가 더 좋아?), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다
https://dev.to/adnanbabakan/comparison-webpack-or-parcel-which-one-is-better-43jo
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념
(Collection and Share based on the CC Protocol.)
이 패키지를 사용하기 시작하려면 먼저 설치해야 합니다. (이것은 좋지 않습니까?)그러나 몇 가지 절차가 있다. 우리는 그 중에서 시작할 것이다.
Webpack을 설치한 후,
webpack.config.js라는 파일을 만들어야 합니다. 여기에는 웹 팩이 패키지를 어떻게 처리하는지 알 수 있도록 설정을 포함해야 합니다.매우 기본적인 웹 페이지 설정은 다음과 같다.
const path = require('path');
module.exports = {
entry: './src/index.js',
output: {
filename: 'main.js',
path: path.resolve(__dirname, 'dist'),
},
};
그러나 Parcel에서 일어난 일은 매우 미친 짓입니다.
index.html 파일을 만들고 평소와 같이 상대적인 경로를 사용하여 스크립트를 포함하면 다음과 같습니다.<html>
<body>
<script src="./index.js"></script>
</body>
</html>
index.html 파일을 보기 시작합니다. 이렇게.Parcel에서는 HTML 파일이 아닌 JavaScript 파일도 볼 수 있습니다.나는 10번 소포를 표시했지만, 웹 페이지는 반드시 여기에 8번 소포를 표시해야 한다.
웹 페이지: 8
소포: 10
종속 및 사전 프로세서 설치
bundler 사용에 관해서, 우리가 앞으로 해야 할 주요 일은 Sass 또는 더 적은 프로세서를 사용하는 것을 돕는 것입니다.
좋습니다. 이것이 바로 웹 패키지를 어떻게 설정하여 당신의 프로세서를 식별해야 하는지입니다.
module.exports = {
module: {
rules: [
{
test: /\.s[ac]ss$/i,
use: [
'style-loader',
'css-loader',
'sass-loader',
],
},
],
},
};
필요한 npm 패키지:
npm i --save style-loader css-loader sass-loader
무섭게 보이지만 솔직히 어렵지 않아요.
소포 어때요?당신은 소포의 클레임 명세서를 기억합니까?제로 구성!그러니까 아무것도 안 해도 돼.필요한 모든 물건은 자동으로 설치되어 먼지를 털지 않는다.
Parcel은 10점, Webpack은 8점을 받았다.
웹 페이지: 16
소포:20
스피드
본고가 당신을 끌어들이는 가장 중요한 일 중 하나는 성능 테스트입니다.
이 묶음 중 어느 것이 더 빠른지 간단한 묶음 패키지를 시험해 봅시다.
나는 귀속기마다 세 번, 귀속기마다 세 개의 귀속 요청을 처음부터 실행할 것이다.app.js 은 포장 중인 파일입니다.그것은 단지 하나의 의존항, 즉 Vue만 있다.js와 aconsole.log.app.js :
import Vue from 'vue';
console.log('I\'m a bundle');
다음 차트에서는 처음 바인딩 (깨끗한 디렉터리) 하고 둘 다 생산 모드를 사용할 때 이 바인딩기가 어떻게 작동하는지 보여 줍니다.
묶는 기계
첫 번째 실행
두 번째 실행
세 번째 달리기
평균적
웹 패키지
272ms
261ms
262ms
265ms
소포
2440ms
2510ms
2470ms
2473.33ms
보시다시피 처음 연결할 때 웹 팩의 성능은 Parcel보다 훨씬 좋습니다 (거의 x9배).
같은 파일을 다시 보고 연결할 때 결과가 무엇인지 보여 줍니다.
이 테스트에 대해 저는 lorem ipsum 주석을 두 번 추가하고 삭제할 것입니다. 그래서 네 번입니다.
묶는 기계
첫 번째 실행
두 번째 실행
세 번째 달리기
제4라운드
평균적
웹 패키지
202ms
246ms
130ms
104ms
170.5ms
소포
71ms
69ms
67ms
54ms
65.25ms
이 예에서 Parcel은 웹 팩을 인수하여 웹 팩보다 더 빨리 실행한다(거의 2.5배).
웹 팩보다 패키지의 성능이 빠르지만 초기 묶음보다 더 중요합니다. 보통 한 번만 보고 실행하기 때문에 초기 묶음의 차이가 너무 큽니다.
나는 이 부분에서 웹 페이지 10과 소포 a9을 줄 것이다.
웹 페이지:26
소포:29
개발 서버
응용 프로그램을 구축할 때, 개발 서버를 검색하고 있을 가능성이 높습니다.
이 두 패키지는 모두 개발 서버를 제공하지만, 웹 팩을 단독 패키지로 설치하고 설정해야 합니다.
이 파일은 다음과 같습니다.
var path = require('path');
module.exports = {
//...
devServer: {
contentBase: path.join(__dirname, 'dist'),
compress: true,
port: 9000
}
};
웹 페이지는 여기에서 9, 소포는 10을 얻는다.
웹 페이지: 35
소포:39
코드 분할
그것이 현실 세계에 들어갔을 때, 코드 분할은 진정한 문제이다.거대하고 무거운 파일은 신속하게 불러올 수 없고, 사이트의 운행이 느린 것도 고객이나 방문자가 원하는 것이 아니다.
앞에서 말한 바와 같이, Parcel은 제로 설정의 코드 분할을 지원한다고 주장한 것은 사실이다.
그러나 웹 패키지는 약간의 설정이 필요하다.
그것들은 모두 동적 가져오기를 지원하는데, 이것은 매우 좋다.
하지만 이것은 얄미운 문제다.
코드를 묶으면 웹 패키지webpack.config.json 폴더의 모양입니다.
이것은 매우 깔끔하고 깨끗하다. 비록 동적 구성 요소를 분할하기 위한 설정이 필요하지만, 이것은 결코 어렵지 않다.
모든 컨텐트는 해당 폴더, 이미지, CSS, JavaScript 또는 글꼴에 있습니다.
이것이 바로 소포dist 폴더의 모습이다.패키지가 이 파일들을 관리하는 방식을 제어할 수 없습니다. dist 폴더가 완전히 평평해졌고, 더 심각한 것은 당신의 dist 폴더도 이 파일에 있습니다.이건 정말 엉망이야!
공평하게 말하자면, 설정 기능이 없기 때문에, 나는 그것에게 2를 주었는데, 이 절에서 웹 팩은 9를 얻었다.
웹 페이지: 44
소포:41
커뮤니티 및 사용
Webpack은 매우 유명합니다. 많은 프레임워크는 Webpack을 묶음으로 사용합니다. 예를 들어 제가 사랑하는 Nuxt를 사용합니다.js.지금까지 나는 어떤 프레임이 Parcel을 사용하는지 아직 모른다.
웹팩 뒤에는 더 큰 커뮤니티가 있습니다. 따라서 웹팩을 사용할 때 문제를 해결하는 방법을 더 많이 찾을 수 있습니다.
웹 패키지는 확장이 많고 좋은 설정을 사용할 수 있다.
그러나 이것은 소포가 미지의 묶음이라는 것을 의미하지는 않는다.
나는 여기서 웹 페이지에 10을 주고 소포는 7을 얻는다.
웹 페이지: 54
소포:48
옵션 및 사용자 정의
나는 너희들이 이 절에 무슨 일이 일어날지 이미 알고 있다고 생각한다.
맞춤형 제작에 있어서 웹팩은 왕이다.Parcel은 제로 설정 귀속기라고 주장하는데, 이것은 매우 좋지만, 기업급 응용 프로그램에서 그것을 필요로 할 때, 당신은 너무 많은 맞춤형 설정을 얻지 못했다.
Webpack은 필요에 따라 구성할 수 있는 수천 개의 옵션을 제공합니다.
웹팩은 10점, 소포는 2점을 받는다.
웹 페이지: 64
소포:50
결론
Webpack은 이곳의 우승자입니다. 앞으로 번거로움을 방지하기 위해 Webpack을 사용하는 것을 권장합니다.웹 패키지는 매우 안정적이고 믿을 만하다. 왜냐하면 나는 이미 수천 번을 사용했기 때문이다.
나는 소포를 좋아한다. 왜냐하면 그것은 매우 간단하지만, 웹 팩이 제공하는 모든 옵션을 희생해서, 나는 한 항목만 완성한 후에 소포를 더 이상 사용하지 않는다.Parcel이 플랫index.html 폴더 문제를 해결하고 추가 구성 옵션을 제공하면 Parcel을 다시 사용할 수 있습니다.
나는 구축 시간을 비교하고 도표를 그렸다.폴더 구조와 본문의 모든 그림과 상하문은 진실이다.만약 이 페이지를 연결하고 싶다면, 이것이 당신에게 아무런 문제가 되지 않도록 그것을 사용하십시오.
나는 네가 이 문장을 좋아하길 바란다.
아래의 평론 부분에서 당신의 생각을 저에게 알려주세요.
Reference
이 문제에 관하여([대비] 웹 패키지야, 소포야, 뭐가 더 좋아?), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다
https://dev.to/adnanbabakan/comparison-webpack-or-parcel-which-one-is-better-43jo
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념
(Collection and Share based on the CC Protocol.)
module.exports = {
module: {
rules: [
{
test: /\.s[ac]ss$/i,
use: [
'style-loader',
'css-loader',
'sass-loader',
],
},
],
},
};
npm i --save style-loader css-loader sass-loader
본고가 당신을 끌어들이는 가장 중요한 일 중 하나는 성능 테스트입니다.
이 묶음 중 어느 것이 더 빠른지 간단한 묶음 패키지를 시험해 봅시다.
나는 귀속기마다 세 번, 귀속기마다 세 개의 귀속 요청을 처음부터 실행할 것이다.
app.js 은 포장 중인 파일입니다.그것은 단지 하나의 의존항, 즉 Vue만 있다.js와 aconsole.log.app.js :import Vue from 'vue';
console.log('I\'m a bundle');
묶는 기계
첫 번째 실행
두 번째 실행
세 번째 달리기
평균적
웹 패키지
272ms
261ms
262ms
265ms
소포
2440ms
2510ms
2470ms
2473.33ms
보시다시피 처음 연결할 때 웹 팩의 성능은 Parcel보다 훨씬 좋습니다 (거의 x9배).
같은 파일을 다시 보고 연결할 때 결과가 무엇인지 보여 줍니다.
이 테스트에 대해 저는 lorem ipsum 주석을 두 번 추가하고 삭제할 것입니다. 그래서 네 번입니다.
묶는 기계
첫 번째 실행
두 번째 실행
세 번째 달리기
제4라운드
평균적
웹 패키지
202ms
246ms
130ms
104ms
170.5ms
소포
71ms
69ms
67ms
54ms
65.25ms
이 예에서 Parcel은 웹 팩을 인수하여 웹 팩보다 더 빨리 실행한다(거의 2.5배).
웹 팩보다 패키지의 성능이 빠르지만 초기 묶음보다 더 중요합니다. 보통 한 번만 보고 실행하기 때문에 초기 묶음의 차이가 너무 큽니다.
나는 이 부분에서 웹 페이지 10과 소포 a9을 줄 것이다.
웹 페이지:26
소포:29
개발 서버
응용 프로그램을 구축할 때, 개발 서버를 검색하고 있을 가능성이 높습니다.
이 두 패키지는 모두 개발 서버를 제공하지만, 웹 팩을 단독 패키지로 설치하고 설정해야 합니다.
이 파일은 다음과 같습니다.
var path = require('path');
module.exports = {
//...
devServer: {
contentBase: path.join(__dirname, 'dist'),
compress: true,
port: 9000
}
};
웹 페이지는 여기에서 9, 소포는 10을 얻는다.
웹 페이지: 35
소포:39
코드 분할
그것이 현실 세계에 들어갔을 때, 코드 분할은 진정한 문제이다.거대하고 무거운 파일은 신속하게 불러올 수 없고, 사이트의 운행이 느린 것도 고객이나 방문자가 원하는 것이 아니다.
앞에서 말한 바와 같이, Parcel은 제로 설정의 코드 분할을 지원한다고 주장한 것은 사실이다.
그러나 웹 패키지는 약간의 설정이 필요하다.
그것들은 모두 동적 가져오기를 지원하는데, 이것은 매우 좋다.
하지만 이것은 얄미운 문제다.
코드를 묶으면 웹 패키지webpack.config.json 폴더의 모양입니다.
이것은 매우 깔끔하고 깨끗하다. 비록 동적 구성 요소를 분할하기 위한 설정이 필요하지만, 이것은 결코 어렵지 않다.
모든 컨텐트는 해당 폴더, 이미지, CSS, JavaScript 또는 글꼴에 있습니다.
이것이 바로 소포dist 폴더의 모습이다.패키지가 이 파일들을 관리하는 방식을 제어할 수 없습니다. dist 폴더가 완전히 평평해졌고, 더 심각한 것은 당신의 dist 폴더도 이 파일에 있습니다.이건 정말 엉망이야!
공평하게 말하자면, 설정 기능이 없기 때문에, 나는 그것에게 2를 주었는데, 이 절에서 웹 팩은 9를 얻었다.
웹 페이지: 44
소포:41
커뮤니티 및 사용
Webpack은 매우 유명합니다. 많은 프레임워크는 Webpack을 묶음으로 사용합니다. 예를 들어 제가 사랑하는 Nuxt를 사용합니다.js.지금까지 나는 어떤 프레임이 Parcel을 사용하는지 아직 모른다.
웹팩 뒤에는 더 큰 커뮤니티가 있습니다. 따라서 웹팩을 사용할 때 문제를 해결하는 방법을 더 많이 찾을 수 있습니다.
웹 패키지는 확장이 많고 좋은 설정을 사용할 수 있다.
그러나 이것은 소포가 미지의 묶음이라는 것을 의미하지는 않는다.
나는 여기서 웹 페이지에 10을 주고 소포는 7을 얻는다.
웹 페이지: 54
소포:48
옵션 및 사용자 정의
나는 너희들이 이 절에 무슨 일이 일어날지 이미 알고 있다고 생각한다.
맞춤형 제작에 있어서 웹팩은 왕이다.Parcel은 제로 설정 귀속기라고 주장하는데, 이것은 매우 좋지만, 기업급 응용 프로그램에서 그것을 필요로 할 때, 당신은 너무 많은 맞춤형 설정을 얻지 못했다.
Webpack은 필요에 따라 구성할 수 있는 수천 개의 옵션을 제공합니다.
웹팩은 10점, 소포는 2점을 받는다.
웹 페이지: 64
소포:50
결론
Webpack은 이곳의 우승자입니다. 앞으로 번거로움을 방지하기 위해 Webpack을 사용하는 것을 권장합니다.웹 패키지는 매우 안정적이고 믿을 만하다. 왜냐하면 나는 이미 수천 번을 사용했기 때문이다.
나는 소포를 좋아한다. 왜냐하면 그것은 매우 간단하지만, 웹 팩이 제공하는 모든 옵션을 희생해서, 나는 한 항목만 완성한 후에 소포를 더 이상 사용하지 않는다.Parcel이 플랫index.html 폴더 문제를 해결하고 추가 구성 옵션을 제공하면 Parcel을 다시 사용할 수 있습니다.
나는 구축 시간을 비교하고 도표를 그렸다.폴더 구조와 본문의 모든 그림과 상하문은 진실이다.만약 이 페이지를 연결하고 싶다면, 이것이 당신에게 아무런 문제가 되지 않도록 그것을 사용하십시오.
나는 네가 이 문장을 좋아하길 바란다.
아래의 평론 부분에서 당신의 생각을 저에게 알려주세요.
Reference
이 문제에 관하여([대비] 웹 패키지야, 소포야, 뭐가 더 좋아?), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다
https://dev.to/adnanbabakan/comparison-webpack-or-parcel-which-one-is-better-43jo
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념
(Collection and Share based on the CC Protocol.)
var path = require('path');
module.exports = {
//...
devServer: {
contentBase: path.join(__dirname, 'dist'),
compress: true,
port: 9000
}
};
그것이 현실 세계에 들어갔을 때, 코드 분할은 진정한 문제이다.거대하고 무거운 파일은 신속하게 불러올 수 없고, 사이트의 운행이 느린 것도 고객이나 방문자가 원하는 것이 아니다.
앞에서 말한 바와 같이, Parcel은 제로 설정의 코드 분할을 지원한다고 주장한 것은 사실이다.
그러나 웹 패키지는 약간의 설정이 필요하다.
그것들은 모두 동적 가져오기를 지원하는데, 이것은 매우 좋다.
하지만 이것은 얄미운 문제다.
코드를 묶으면 웹 패키지
webpack.config.json 폴더의 모양입니다. 이것은 매우 깔끔하고 깨끗하다. 비록 동적 구성 요소를 분할하기 위한 설정이 필요하지만, 이것은 결코 어렵지 않다.
모든 컨텐트는 해당 폴더, 이미지, CSS, JavaScript 또는 글꼴에 있습니다.
이것이 바로 소포
dist 폴더의 모습이다.패키지가 이 파일들을 관리하는 방식을 제어할 수 없습니다. dist 폴더가 완전히 평평해졌고, 더 심각한 것은 당신의 dist 폴더도 이 파일에 있습니다.이건 정말 엉망이야!공평하게 말하자면, 설정 기능이 없기 때문에, 나는 그것에게 2를 주었는데, 이 절에서 웹 팩은 9를 얻었다.
웹 페이지: 44
소포:41
커뮤니티 및 사용
Webpack은 매우 유명합니다. 많은 프레임워크는 Webpack을 묶음으로 사용합니다. 예를 들어 제가 사랑하는 Nuxt를 사용합니다.js.지금까지 나는 어떤 프레임이 Parcel을 사용하는지 아직 모른다.
웹팩 뒤에는 더 큰 커뮤니티가 있습니다. 따라서 웹팩을 사용할 때 문제를 해결하는 방법을 더 많이 찾을 수 있습니다.
웹 패키지는 확장이 많고 좋은 설정을 사용할 수 있다.
그러나 이것은 소포가 미지의 묶음이라는 것을 의미하지는 않는다.
나는 여기서 웹 페이지에 10을 주고 소포는 7을 얻는다.
웹 페이지: 54
소포:48
옵션 및 사용자 정의
나는 너희들이 이 절에 무슨 일이 일어날지 이미 알고 있다고 생각한다.
맞춤형 제작에 있어서 웹팩은 왕이다.Parcel은 제로 설정 귀속기라고 주장하는데, 이것은 매우 좋지만, 기업급 응용 프로그램에서 그것을 필요로 할 때, 당신은 너무 많은 맞춤형 설정을 얻지 못했다.
Webpack은 필요에 따라 구성할 수 있는 수천 개의 옵션을 제공합니다.
웹팩은 10점, 소포는 2점을 받는다.
웹 페이지: 64
소포:50
결론
Webpack은 이곳의 우승자입니다. 앞으로 번거로움을 방지하기 위해 Webpack을 사용하는 것을 권장합니다.웹 패키지는 매우 안정적이고 믿을 만하다. 왜냐하면 나는 이미 수천 번을 사용했기 때문이다.
나는 소포를 좋아한다. 왜냐하면 그것은 매우 간단하지만, 웹 팩이 제공하는 모든 옵션을 희생해서, 나는 한 항목만 완성한 후에 소포를 더 이상 사용하지 않는다.Parcel이 플랫index.html 폴더 문제를 해결하고 추가 구성 옵션을 제공하면 Parcel을 다시 사용할 수 있습니다.
나는 구축 시간을 비교하고 도표를 그렸다.폴더 구조와 본문의 모든 그림과 상하문은 진실이다.만약 이 페이지를 연결하고 싶다면, 이것이 당신에게 아무런 문제가 되지 않도록 그것을 사용하십시오.
나는 네가 이 문장을 좋아하길 바란다.
아래의 평론 부분에서 당신의 생각을 저에게 알려주세요.
Reference
이 문제에 관하여([대비] 웹 패키지야, 소포야, 뭐가 더 좋아?), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다
https://dev.to/adnanbabakan/comparison-webpack-or-parcel-which-one-is-better-43jo
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념
(Collection and Share based on the CC Protocol.)
나는 너희들이 이 절에 무슨 일이 일어날지 이미 알고 있다고 생각한다.
맞춤형 제작에 있어서 웹팩은 왕이다.Parcel은 제로 설정 귀속기라고 주장하는데, 이것은 매우 좋지만, 기업급 응용 프로그램에서 그것을 필요로 할 때, 당신은 너무 많은 맞춤형 설정을 얻지 못했다.
Webpack은 필요에 따라 구성할 수 있는 수천 개의 옵션을 제공합니다.
웹팩은 10점, 소포는 2점을 받는다.
웹 페이지: 64
소포:50
결론
Webpack은 이곳의 우승자입니다. 앞으로 번거로움을 방지하기 위해 Webpack을 사용하는 것을 권장합니다.웹 패키지는 매우 안정적이고 믿을 만하다. 왜냐하면 나는 이미 수천 번을 사용했기 때문이다.
나는 소포를 좋아한다. 왜냐하면 그것은 매우 간단하지만, 웹 팩이 제공하는 모든 옵션을 희생해서, 나는 한 항목만 완성한 후에 소포를 더 이상 사용하지 않는다.Parcel이 플랫index.html 폴더 문제를 해결하고 추가 구성 옵션을 제공하면 Parcel을 다시 사용할 수 있습니다.
나는 구축 시간을 비교하고 도표를 그렸다.폴더 구조와 본문의 모든 그림과 상하문은 진실이다.만약 이 페이지를 연결하고 싶다면, 이것이 당신에게 아무런 문제가 되지 않도록 그것을 사용하십시오.
나는 네가 이 문장을 좋아하길 바란다.
아래의 평론 부분에서 당신의 생각을 저에게 알려주세요.
Reference
이 문제에 관하여([대비] 웹 패키지야, 소포야, 뭐가 더 좋아?), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다
https://dev.to/adnanbabakan/comparison-webpack-or-parcel-which-one-is-better-43jo
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념
(Collection and Share based on the CC Protocol.)
Reference
이 문제에 관하여([대비] 웹 패키지야, 소포야, 뭐가 더 좋아?), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://dev.to/adnanbabakan/comparison-webpack-or-parcel-which-one-is-better-43jo텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념
(Collection and Share based on the CC Protocol.)
좋은 웹페이지 즐겨찾기
