Comment by caseymarquis | Hacker News Reader

Comment by caseymarquis | Hacker News Reader

I recently built a small side project in vanilla js for fun. I just didn't want to break out webpack and waste an hour getting it set up.

I got pretty far, did all the design. I wanted to run a client side simulation in javascript though, and found I needed to host a local server as chrome refused to read modules from a file due to CORS permissions (running chrome with the usual arguments didn't fix it).

At this point, since I needed an outside piece of software to run things anyway, I figured I might as well switch to webpack dev-server and get the whole modern frontend ecosystem. I then quickly started replacing my home grown dom syncing with vuejs, and snowballed from there.

I definitely learned a couple things, so time well spent, but I'm also going straight to webpack next time. I know it'll only take a few hours before I start hitting the limits of what vanilla js can do, and while reinventing the wheel was fun and educational, it didn't result in a better wheel.

Alternatively, you can use a simple web-server without needing all of webpack:

using npx (included with npm):

    npx serve .

using the php CLI:

    php -S localhost:5000 -t .

You weren't hitting the limits of vanilla JS, you were hitting the limit of reading files directly from disk instead of through a web server.

This is a good point, the fact that browsers won’t load JS modules over the file:// protocol is not the fault of JavaScript.

or in python 2 (should be on installed by default on most distro):

   python -m SimpleHTTPServer

or python3 :

    python -m http.server

Seriously, the poster is going to have to host their files somewhere eventually if they intend anyone else to ever see it. I can't believe they rewrote all their JS because they were forced to access over http:// instead of file://. This seems nonsensical.

Hey, never used python's http server, that's just as nice and easy as the two solutions I proposed, thanks for the tip!

A simple web-server only does that: serving a website. With a proper webpack setup, you get imports/exports, (node) module bundling, live reloading which all massively improve your development speed.

However I wouldn't recommend anyone to build their own webpack config if you don't know exactly what you're doing. Just use parcel: https://parceljs.org/

There's also Parcel: https://parceljs.org/

It does many things an advanced Webpack project does, but without any config. I use Parcel as long as possible and then switch to lower-level Webpack when I need more control. Easier way to start a new project.

If you want to spin up a project without doing config first then https://parceljs.org/ is a really good place to start. It does 95% of what most people use Webpack for, but with no config.

It's also worth noting that if you just want a bundler (with no server or hot module reload stuff) then Webpack with no config usually works for most projects that aren't doing anything advanced.

Why is using webpack not considered “vanilla”?

Because the code you write is not what is loaded into the browser, it’s bundled and loaded in chunks.

I still don’t see how that’s not vanilla.js

Because webpack is not part of the language specification.

So I guess using VSCode isn’t vanilla either cause it’s not part of the language spec?

Epic point being made here. TypeScript is Vanilla JS as well because it outputs JS.

So now VSCode only writes TypeScript just like Webpack only bundles React?

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

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

The programming environment usually is not deployed to the runtime environment, so it's not a part of the built program. Libraries are.

"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.

https://en.wikipedia.org/wiki/Vanilla_software

Technically the runtime is the browser.

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.

Because you end up with Webpack runtime code in your bundles. No different than if you included a library’s source code in your code— it would not be vanilla JS.

Is JSONP vanilla.js?

No you don't, that's not how webpack works. You can use webpack's live reloading during development, but that's it. It's just a module bundler

> It's just a module bundler.

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

Internet Explorer isn't Vanilla.js either.

Agreed. Internet Explorer was almost certainly not written in JavaScript at all— most likely C++.

I want to give you the benefit of the doubt that you're being sardonic but just in case I meant IE doesn't support ES6 modules so thereby following your narrowly pedantic definition it isn't very vanilla.js

My point was not that you must use ES6 modules— my point was that webpack does NOT use ES6 modules so it must include a framework for importing, exporting, and otherwise consuming the bundles.

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.

I started trying to answer your first question, when I realized it’s a reasonably good question. Webpack doesn’t automatically change your JavaScript, so it is possible to use vanilla js and also Webpack. Colloquially though, “vanilla” is also referring to not using a pre-processing step of any kind, and not having project dependencies, basically directly writing the files that are loaded by browser.

And yet people wonder why HN has a reputation as a community of pedantic dorks.

... why would people wonder that? You expect a community of hackers to not nitpick? A group largely populated by programming people who are entirely accustomed to a single character changing the entire function of a statement and who frequently expect natural language to work the same way?

Hey dammit, we’re autistic programmers, not pedantic dorks! ;) But seriously, I’m not sure that’s entirely fair. I do think Webpack feels not-vanilla, even if it doesn’t change how you manipulate the DOM.

Fine I'll use rollup instead.

I had similar question and found Web Server for Chrome

https://chrome.google.com/webstore/detail/web-server-for-chr...

And it works

At least React doesn't require you to use packaging.

Just require it via script tag and create your app.

If you don't like the size, Preact is a good tiny alternative.

If you want JSX like syntax, try htm or t7.

Reply on news.ycombinator.com