This same story works for images as well using the url loader plugin. If it’s small, it’ll inline the stylesheet! If it’s long, it’ll minify the file and give it a unique name for cache busting. Require(“./stylesheet.css”) Huh? Why not simply reference CSS the old way? Well, Webpack will consider the size of this file. You can simply include these assets like you do with JavaScript today. Webpack is smart enough to dynamically inline your CSS and images when it makes sense. The integrated nature of Webpack really shines when you consider the stories for working with other assets like images and CSS. And you’re manually wiring together two totally separate technologies. Sure, you can do all this via Browserify and Gulp, but you have to do more wiring yourself. It assumes you’ll want to compile various formats using a long list of loaders. It assumes you want to work with JavaScript libraries in various module formats like CommonJS, and AMD. Webpack assumes you need to move files from a source directory to a destination directory. But configuration isn’t necessarily a bad thing.Ĭonfiguration-based systems are preferable to imperative systems if they make the right assumptions about your goals up front.
#WHY USE WEBPACK VS GULP OR GRUNT CODE#
Woah, a config file? Yes, if you migrated from Grunt to Gulp because you prefer code over configuration, that may sound like a step backward. With Webpack you can declare a simple config file to define your build process. Welcome to life on the front-end.īut hey, that’s the price of progress.
Yep, sorry, that shiny new skill you just mastered is already nearly useless. Webpack offers enough power out of the box that you typically don’t need Grunt or Gulp at all. In Browserify you use Gulp/Grunt and a long list of transforms and plugins to get the job done. Webpack Webpack attacks the build problem in a fundamentally more integrated and opinionated manner. If you think of your build process like a unique log cabin, then Browserify with Gulp/Grunt is like starting off here:
Wouldn’t it be nice to start with a more powerful and opinionated tool that made more assumptions about your build process? For Web designing services visit Vivid Designs
After you’ve worked with Grunt or Gulp for long, you start to realize a long list of things you do for every project. These tools work great, but configuring them properly is a time-consuming process. So you’re going to reach for a JavaScript build automation tool like Grunt or Gulp. But to wire all this up, you’re on your own. Sure, Browserify has a rich ecosystem of transforms to help get things done. Chances are you have a long list of other things you need to get done like minifying, bundling, linting, running tests, etc. Thanks Browserify! Yet this simplicity is also its Achilles heel. Hey, see all these cool packages on npm? Let me wrap those up for ya so you can use those in the browser. Let’s consider the merits of each approach.īrowserify (and friends…) Browserify is conceptually simple.
Is there truly a compelling reason to change your front-end build process yet again? And now, just as Gulp and Browserify are finally reaching critical mass, Webpack threatens to unseat them both. Just last year Grunt was effectively dethroned by Gulp. In the land of JavaScript, no one is king for long.
0 kommentar(er)
