Why is using webpack not considered “vanilla”?
my point is, i can't understand why you would bring VSCode up at all in a discussion about webpack's relationship to "vanilla js" (whatever that is).
(btw i was using the term "preprocessor" loosely - i meant source-transforming tools in general)
Just like using webpack has nothing to do with how you interact with the DOM.
i am a bit biased, based on my recent experience of trying to load a webpacked library's `dist/foobar.js` into a WordPress thing via a normal <script src="..."> and having it barf all over the console, yelling about `window.module` missing and loaders and stuff. i never managed to get the bundled version to load, which reinforces my opinion - it's not "vanilla" if it needs some custom infrastructure and can't just be dropped into an existing plain js environment.
i did however manage to load the unbundled source with a native ES6 <script type="module">, and it worked great! vanilla js can be pretty pleasant these days :)
I thought vanilla means not using front end view framework/library such as Vue, React, jQuery...
ignoring framework stuff (bc everyone seems to agree there) i'd say if your js qualifies as "vanilla" if it can run in a relatively recent browser without a build step or other transformations. you might further ES5-ify, uglify and minify it for practical reasons, but that must be an optional thing
---
since we're splitting hairs, we could also distinguish "theoretically vanilla js" - js that's standard ECMAScript so it'll run fine when browser catch up, but it's not supported just yet and thus needs transforming. this would exclude non-standard extensions like JSX
and note that i don't mean "vanilla" as any sort of value judgement! it's a practical description of how it works, not some kind of platonic ideal to aspire to – frameworks, webpack, Babel etc provide useful solutions for the shortcomings of the browser platform and ecosystem. the thing i was talking about is a single-file internal tool, and compat isn't a problem; if it was user-facing, i'd probably use some ES5-ifying tool myself. and i'd probably use JSX if i was doing a React thing, because it's great - inline HTML is an underappreciated convenience in PHP!
i'd say your js qualifies as "vanilla"
"Vanilla" language or tool has a precise meaning of using the official tool without external customizations. If you are importing a library that is not part of the language standard specification, that's by definition not vanilla.
Using a development environment is not a "customization" of the language, because javascript has no official development environment that you could customize by using a different one, so the environment is not a part of the language.
For languages like Smalltalk implementations that have an IDE+runtime that is THE official development environment and specification, switching the code to a different IDE+runtime would indeed be using a non-vanilla version.
index.js var foo = document.body.getElementById("bar");
That is dom manipulation using vanilla javascript in all modern browsers. I can use webpack, rollup, parcel, or load it in a script tag, it doesn't matter it's still just plain old javascript.
It is how Webpack works, actually. Webpack does not support bundling to native ES6 modules [0], it has to bundle into a format which requires runtime code being injected to execute properly, handling imports, and whatnot instead of relying purely on native ES6 modules.
Have you ever looked at the contents of a bundle? [1]
Long story short, Webpack circumvents native ES6 modules in favor of other module formats. It provides a great amount of utility, but it is not Vanilla JS.
[0] https://github.com/webpack/webpack/issues/2933 [1] https://pastebin.com/C2qPunwV
Serious questions, please don’t dance around them:
How is what I described above still Vanilla JS?
Would you consider using TypeScript to be Vanilla JS? Why or why not?
Would you consider using lo dash to be Vanilla JS? Why or why not?
Also, Vanilla JS is pedantic. The point is that you don’t need any of these tools to make a website or web app.
I personally like the tools I use, I don’t care about vanilla js. But you can’t just try to argue it’s not obviously meant to not include a bundling or transpiration step.
Furthermore, making a site/app with everything being vanilla js EXCEPT for also using Webpack is certainly as admirable— but it makes it not vanilla js.