-1

In an MVC project, I tried 2 ways to include jQuery:

  1. download the jQuery files and include them in the project like this: enter image description here

with bundle setting in BundleConfig.cs like this:

bundles.Add(new ScriptBundle("~/bundles/jquery").Include("~/Scripts/JQuery/jquery-{version}.js"));
  1. use NPM, in the repo, I did npm install jquery@3.1.0, then in BundleConfig.cs, set up the bundle like this:
bundles.Add(new ScriptBundle("~/bundles/jquery").Include("~/node_modules/jquery/dist/jquery.min.js"));

Both 1 and 2 works. Obviously I should use 2, cause people say NPM is better. However, I'm not using the latest jQuery version, I do not have the need to upgrade jQuery at the moment, and I will use jQuery 3.1.0 for a long time. I thought about upgrading jQuery to the latest but here it says I should not: Practical approach to keeping jQuery up to date?, also tried it and broke the entire website.

Why is 2 better than 1? All I can see is 2 includes jQuery from a different path. Am I missing anything?

one-hand-octopus
  • 2,229
  • 1
  • 17
  • 51
  • It's easy to argue that using NPM is actually worse, because when a disgruntled contributor removes their code from NPM, it can break your product. This has already happened at least twice, quite famously. Better to bundle with your app or use your own repository with whatever you need mirrored from other places. – TylerH Sep 25 '19 at 15:46
  • @TylerH so should I abandon use of NPM due to these 2 famous incidents? – one-hand-octopus Sep 25 '19 at 15:51
  • Personally my opinion is yes; I would not use direct NPM links in production, preferably ever. It's the same principle as SO requiring you to put code in your question rather than linking to a JSFiddle or CodePen. SO content loses its usefulness when JSFiddle or CodePen goes down in that case. In these two famous cases, the entire web and a company with tens of thousands of customers basically *broke* due to one dev saying "I'm removing my code". Could easily have been prevented by having their own (auto-updating) intermediary repository for libraries instead of linking to NPM. – TylerH Sep 25 '19 at 15:55
  • It is a low-risk, high-impact consideration. On the flip side, the only benefit of using NPM is you get to save a few milliseconds due to caching as many people likely already have jQuery loaded. However, the value of caching (and whether it actually *is* cached) depends on your environment/target audience, and even in cases where you're pushing something to the public, it probably still doesn't matter. If your product is public and someone needs to visit it, even a 2- or 3-second load time is fine and not really noticeable. Repeat visitors will have resources cached from your repo already. – TylerH Sep 25 '19 at 15:57
  • @TylerH Just read here https://www.theregister.co.uk/2016/03/29/npmgate_followup/ saying NPM prevents developers from unpublishing an open-source module if the code is older than 24 hours, does this make using NPM in production safer? – one-hand-octopus Sep 25 '19 at 15:57
  • That's a good change, and it does make it safer, though you're still risking your content relying on a private organization elsewhere. It ultimately depends on your values consideration... if your website is up but npm is down, even for an hour, is that a good tradeoff for *potentially* saving your repeat visitors a half-second load time once every few months? If yes, then OK, use NPM. If not, consider hosting your own company repository that links to NPM and updates when new versions come out (but alerts you rather than deleting libs when the NPM source lib is removed or reduced drastically). – TylerH Sep 25 '19 at 16:01

1 Answers1

1

Using NPM (or any package manager) allows you to keep track of dependencies in singular managed way. This allows for:

  • Specific versions to be installed, based on your needs (for instance jQuery 3.1.0).
  • Easy updates.
  • Specific ranges of versions to be installed, useful for automatically upgrading versions within the semver range whenever, for example, a security patch is released (NPM will also inform you about security issues).
  • Keeping your version control clear of unneeded assets.

The benefits increase whenever a project grows. If all you need is jQuery the benefits are slim, however when you need to keep track of various other dependencies you'll soon most likely see that having them specified in a requirements file (package.json) is a pretty nice thing.

Also, certain tools (like Webpack) may be aware of your node_modules directory removing the need foor any bundles.add (depending on what your stack looks like). Some editors might also be able to inspect those modules providing code suggestions or even type information.

On a sidenote:

I would suggestion not sticking too much to older versions of libraries, especially of your defining libraries in a global scope (one again, check your stack) at some point in the future someone might need a feature from the next version and this might be problematic if a another versions sits in its way.

Sven van de Scheur
  • 1,809
  • 2
  • 15
  • 31
  • In terms of point 2: Easy updates, do you mean for example it updates jQuery from 3.1.0 to 3.4.1? – one-hand-octopus Sep 25 '19 at 10:17
  • For example, (I don't use jQuery so I'm unaware of actual compatibility between versions), but according to server 3.1.0 and 3.4.1 should be compatible. A dependency in NPM can bet set to stick to breaking/major version (3) but update feature/minor (4) and fix/patch releases (1). This will give developers the latest compatible version. – Sven van de Scheur Sep 25 '19 at 12:56