It is like every other package manager (yarn, NuGet, Bower, RubyGems, etc.). I focused on Webpack because it's widely used, has active 3rd party loader/plugin development, and a developer I trust said that Webpack had won and we should just use it despite the configuration headaches! You could instead look at a Webpack competitor (like Gulp or Grunt) to get similar functionality. Once you get used to the new features, programming in "old" JavaScript is painful! Even aside from that, I'd argue that Webpack is worth the effort just to use the new features available in Typescript (or ECMA script 2015) and have it compiled back to browser safe JavaScript. First off, you will need it (or something similar) in your build chain for any modern framework. Given that (arguably big) downside, should you use Webpack? I'd say absolutely. I eventually got where I wanted to go, but not without some frustration along the way. I fell into plenty of rabbit holes with Webpack and 3rd party loaders. It has notoriously poor documentation, and while it has a lot of configurability, you can expect to spend hours setting up the proper configuration and debugging your build chain. Webpack is not without downsides however.
#Npm build webpack stop minify download
They would only need to download a main script and the script for the first area, instead of all 10 areas. This is pretty easy to enable, and adds a huge performance boost when users first load your application.
#Npm build webpack stop minify code
You can use code splitting to put the code for each area in different bundles, which can be downloaded dynamically only when the area is actually accessed. Imagine you have a Single Page Application (SPA) with 10 different areas (or views or whatever) in it. This is also used to support an advanced feature called code splitting.
This makes your JavaScript code more self-contained and easier to maintain. When using #import, you can bring in only the functions or classes you actually need, and if the same code is imported by multiple locations, it will ensure you only get one copy in the output. Those dependency chains will be resolved by Webpack and used to process only the files that are actually in use by your application. You can use require() calls-or better, the new #import statement-in your script files to load other scripts using relative paths. Webpack also helps solve module dependencies. It does have some extra challenges associated, but for the most part works pretty well. You write your web app to load scripts from the Webpack dev server, and it automagically refreshes your scripts, CSS (and templates for a framework that supports it) every time the files change, without refreshing the browser! It's pretty cool to edit a file, save it and then see it appear in your browser instantly. This basically runs Webpack as a local web server, which monitors your input files and reprocesses them each time they change. Webpack has a neat development time feature called Hot Module Replacement.
At its most basic, you process files with Webpack, transform them with various 3rd party loaders and plugins, and then output something different. Webpack is a "module bundler," but I think of it as a highly configurable build tool that can be plugged into your project's tool chain.
Both of these are tools that can be used with any tech stack (Angular, React, Vue.JS, etc.), and they bring their own benefits and pain! Volume 4 will review my selected framework, (spoiler: it's Vue.JS), but before I get there I want to write a bit about Webpack and NPM. Tech Stack Modernization Volumes 1 and 2 covered my thought process behind modernization and a review of Angular. sass ( 'source/_assets/sass/main.scss', 'css' ). js ( 'source/_assets/js/main.js', 'js' ). setPublicPath ( 'source/assets/build' ) mix. Const mix = require ( 'laravel-mix' ) const MinifyJigsawOutput = require ( 'webpack-minify-jigsaw-output' ) require ( 'laravel-mix-jigsaw' ) mix.
0 kommentar(er)
