Hacker News Reader

Comment by uryga | Hacker News Reader

how are an editor and a code preprocessor comparable here? they serve entirely different purposes, unless you stretch "producing code" reaally far

View on HN

They're both tools. As in webpack is a tool that allows you to use a preprocessor like babel but you don't have to if you don't want to.

yeah, so is git. would it make sense to say "So I guess using Git isn’t vanilla either cause it’s not part of the language spec?"?

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)

That is exactly the point, using a tool like git has absolutely nothing to do with how you interact with the DOM.

Just like using webpack has nothing to do with how you interact with the DOM.

true, it doesn't. but imo when people say "vanilla js" they mean both no framework to abstract DOM manipulation and no build steps, whether they be transpiling from ES7 or bundling stuff. perhaps webpack can be used to just minify+concatenate a few files together, but that's not how it's usually used, and i guess not what most people mean when they talk about webpack.

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 :)

So vanilla js must be ES5 if you want to support legacy browsers? Because babel and other build tools aren't considered to be "vanilla"?

I thought vanilla means not using front end view framework/library such as Vue, React, jQuery...

i'm sure it means many things to many people :) obv i only speak myself here

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!

whoops, meant to write:

  i'd say your js qualifies as "vanilla"

in the first paragraph, can't edit anymore

Reply on news.ycombinator.com