- #Stackoverflow why use webpack software#
- #Stackoverflow why use webpack code#
- #Stackoverflow why use webpack download#
#Stackoverflow why use webpack software#
We’re going to talk about front-end frameworks a bunch (you might have gotten a hint from the title), so let’s get on the same page around terminology:Ī software framework is a pre-written app structure for you to build on top of. However, your app has a “front end”-noun, no hyphen. Quick aside: “front-end framework” gets a hyphen since it’s a compound adjective.
How a front-end framework might help address these. The architecture problems you might encounter as it scales. In this post, we’ll take a bird’s eye view of the problem front-end frameworks are trying to solve and when you might want to use one. (We’ll come back to how that turned out at the end of the article.) This is the explanation I wish had then. I had a loose sense that implementing a framework was the right next step, but I had little idea about what they did. A few years ago, while working on a side project, Hackterms, my own front end became unwieldy. If you’ve wondered why and when these frameworks are used and whether it’s time you implement one in your project, you’re not alone. Names like React, Vue, and Angular abound in tutorials and Hacker News debates. However, I still had the Dependencies Problem: dependencies weren’t explicitly declared, yet the ordering of files had to satisfy dependency requirements.You’ve likely heard about front-end frameworks. I fixed that by wrapping each file in an IIFE to keep its scope local. 
#Stackoverflow why use webpack code#
Then there was the Scoping Problem: all of that code was run in the global scope, leading to name collisions.
To fix that, I used a build tool to concatenate Javascript files into one big bundle so I’d only need one tag. This led to the Speed Problem: loading that many files is too slow. In the beginning, I just included tags for every Javascript file I had. Check out the Webpack docs to learn more. Webpack and most of its alternatives actually do a lot more than just simple module bundling, but that’s outside the scope of this post. There’s no more need to manually maintain ordering, and dependencies are explicitly declared. In other words, Webpack fixes the Dependencies problem. Here’s an example of what Webpack lets you do:Īnd Webpack will generate a bundle that satisfies the dependencies of each module. If only I’d read a blog post explaining why I should use Webpack… One of the most interesting bugs I’ve fixed in my time was caused by these IIFEs - want to see if you can spot it? Stage 4: WebpackĢ years after starting work on GeoArena, I finally decided to rewrite my entire codebase to use Webpack. To make matters worse, I now also had to care about stuff like not using playSingleplayer before assigning it. However, this didn’t fix the Dependencies problem: I still had to manually order files to satisfy all dependencies. #Stackoverflow why use webpack download#
The Speed problem had the easiest fix: just put everything into one huge file and download that instead! I used Gulp, a popular build tool, to concatenate all of my files into one giant bundle: Dependencies weren’t explicitly declared anywhere, yet my ordering had to satisfy all of them.
For example, geoarena-networking.js depended on socket.io, so I had to ensure the socket.io include appeared above the geoarena-networking.js include. I had to manually maintain an ordering of includes that satisfied my dependencies. That meant anything I declared had to have a unique name- otherwise, there’d be a collision! Can you see how that’s problematic? More code = More variables = More Wait, have I already used this name before? Each file ran in the same global scope, so any variable I declared was available on the global window object. What seems more efficient to you: asking for 10 lines of code 100 times, or asking for 1000 lines of code once? Web performance matters - its importance has long been well-known and documented. Requesting this many scripts was a network bottleneck, and as a result my site was somewhat slow to load (keep in mind this was in 2016, before the HTTP/2 era). There are several big problems with this approach:
0 kommentar(er)
