I really don't want to be that guy, but... Vanilla JavaScript already exists as a popular term for JavaScript without any framework. No jQuery, no React - just JavaScript. Calling a library VanJS (as short for "Vanilla JavaScript") is just going to cause confusion.
The repo's own description uses the phrase vanilla JavaScript in this way, and even mixes both meanings within a single sentence.
If the author likes the theme, I'm sure they can still use it indirectly. eg. "icecream.js: add a scoop of vanilla to your project". Or "Go nuts and sprinkle in some Reactive syntax". It's still very punnable, I assure you.
I clicked the download link to see what would happen, and it did indeed download a zero byte vanilla.js file. Zipping it using the OS X 'compress file' menu option gave me a 713 byte zip file however.
> Most people have never consumed real vanilla in their lifetime
What exactly is the "vanilla extract, vanilla beans" in Ben & Jerry's ice cream then?
Supposedly Haagen-Dazs ice cream is made from "5 simple ingredients": cream, milk, eggs, sugar, and Madagascar (sic) vanilla (which is "real" vanilla I assume?)
And what about the vanilla extract which I have on my shelf, whose ingredients are "vanilla bean extractions in 35% alcohol?"
Have we all fallen victim to a diabolical vanilla conspiracy?
Even though the main character of the universe, you, has consumed real vanilla, the point stands. Almost everything labeled "vanilla" does not actually contain real vanilla.
It's not similar. Unfortunately, "original" is one of the words with a couple of very close but different meaning. This one even goes first in the dictionary:
> Existing at the beginning of a particular period, process or activity.
The original meaning of the root "origin" comes from Latin: to rise -> beginning, source birth.
The relationship between Bourbon (spirit), primarily distilled and aged in Kentucky, and Bourbon (vanilla plant), primarily grown in Madagascar is one of fascinating cross-convergence of "things rich French speakers loved", plus the coincident accident of Bourbon, Kentucky being a shipping port (and Oak as an aging vessel high in imparting vanillins). Both are a reminder that vanilla as a flavor was long a spice for (and named after) kings and to be enjoyed mostly by the rich. It is still hilarious to see things like "vanilla JS" meant to imply "boring" or "cheap" when historically that's very inaccurate.
Also, yes, bourbon (spirit) is a good accompaniment to late nights in JavaScript.
Vanilla historically being fancy but then becoming an attainable and cheap additive is probably somewhat responsible for it becoming the default ice cream flavor, and thus flipping the idiomatic meaning.
Though note it was primarily the invention of artificial vanilla substitutes that made vanilla seem cheap/attainable. (Real Bourbon vanilla from Madagascar, for instance, is still far more expensive than most people realize.) There may even be a larger useful metaphor there, too, that "plain" vanilla is most often "fake vanilla".
Lots of dessert / ice cream recipes use vanilla as an ingredient regardless of what the final flavor is meant to be. This also leads to the vanilla === plain misconception, imo.
I've been managing that since more than a decade. Having neither jQuery nor bourbon was a challenge at first but browser APIs evolved and I fell in love with green tea.
It’s 93 lines, less than most CSS resets. Small enough to copy paste to the top of your index.html in a script tag. You can use it without NPM, webpack, a special compiler pass, or a template language. Seems pretty vanilla compared to the full fat, popular alternatives.
No it doesn't, same as "automobile" doesn't seem pretty Saturn-5, despite the fact that both are moving under their own power.
Terms have meaning, including meaning derived from communities by and large accepting that a certain term has a certain semantic meaning. And the accepted semantic meaning of "Vanilla Javascript" is "runs without a framework besides the browsers own API".
If my code works out of the box in an unmodified browser, then it is Vanilla JS. If I have to load a framework for it to work, then it isn't, period. And it matters exactly nothing whether the framework in question has 900,000 or 9 lines of code.
So loading an external library or framework isn't Vanilla JS, but if I copy/paste the VanJS source into a script tag, nothing gets loaded, there's no syntax magic, just some function calls, so that's Vanilla JS, right? If the latter isn't Vanilla JS by your definition, can I at least copy/paste something from stackoverflow?
Trying to make Vanilla JS a strict definition seems pointless to me in the first place.
I think we don't have to argue about the distinction between the library code and the application code. It doesn't matter how the library is loaded. You can get it from a CDN at runtime, load it from a scriptbundle, copypaste it into a <script> tag, it doesn't matter.
It's still library code that the rest of the application depends on. As soon as that is the case, it's no longer what the JS community by and large calls "Vanilla JS".
When you do it this way isn't even a framework is just a helper library (at his best). There is another concept for this kind of micro-libraries but calling "framework" to something that will not establish a frame of work for you.
> If my code works out of the box in an unmodified browser, then it is Vanilla JS. If I have to load a framework for it to work, then it isn't, period.
Minor nitpick, third party library and framework does not modify your browser. They all still run on unmodified browsers.
I understand the confusion, given the existing terms but it seems the intent behind the name 'VanJS' is to highlight the simplicity and 'bare-bones' nature of this new framework, aligning it with the 'vanilla' aspect.
While it might lead to some confusion initially, with clear and transparent communication about what 'VanJS' offers, it could still work as a brand that distinguishes itself by simplicity - or pivot to Van rentals
Might ?? Come now, be an adult and a thinking person ! Go down the hall find 10 js/frontend programmers. Ask them what do they think "Vanilla JS" might mean ?
SolidJS is probably the closest thing to a vanillaJS framework that you can get, in that 90% of the time it's doing the same DOM manipulations you would be doing, but with a nicer interface. So if an update causes a class to change, there's no tree to diff - that class attribute gets changed directly.
The non-Vanilla stuff is the signals implementation, which is kind of an RxJS-esque observable system, but more lightweight, and more push-based. It's very similar to Svelte, but with a React/hooks-like API (although far fewer rules to remember!) As I understand it, this system is pretty efficient, which means for simple use-cases, it's not adding much overhead over basic vanilla stuff.
The disadvantages (because there are always some) mainly come from the small ecosystem - there's not many off-the-shelf design toolkits, the documentation is a bit scratchy, etc. That community is still growing though, so that stuff will get there.
Or a software development platform a "no-code" solution.
Apparently all the cool marketing kids now want you to call your widget company "widgetless." Paraphrasing EJD's critique of Ada, "This stupid idea will take 5 years and a billion dollars to kill."
Yea kinda felt the same, when reading the name and desc. Whats the value of names or terms if we keep reassigning a different meaning to it ? Especially in the tech industry.
Also it's almost immoral calling "a new" project "lightweight" and "small".
Of course it is lightweight and small, it's a new project ! Wait for bug submissions, feature requests, feature parity, time, edge cases etc.
So now we have a framework that doesn't want to be a framework? They might call it "VoidJS" instead, as in void = vacuum = so lightweight it's almost as if there's nothing there?
It's very effective naming strategy. It's called VanJS not Vanilla JavaScript. But it's kinda hard to remember Van, or any letters really. By association of it's main quality which is small size/simplicity with common term such as vanilla JavaScript, suddenly VanJS becomes memorable.
Similarly vanilla js was named like that, after common term describing plain flavor of icecream. Which was weird to me, and I learned that as a non-native speaker only after I heard about vanilla js.
It's been explained well. If you want to point out a fact that paints someone in a bad light, but you are concerned about the fact rather than making people feel bad, you say "I don't want to judge, but [what I say here implies a judgement.]"
For example: "I don't want to judge, but I bought a gallon of milk three days ago and didn't get to use a drop of it." My concern isn't that you feel bad about drinking the milk or to paint you as a milk thief to others, my concern is that I bought milk and I didn't get to drink it. I'm being forced to offer a judgement in order to talk about my own experience.
>If you want to point out a fact that paints someone in a bad light, but you are concerned about the fact rather than making people feel bad
What you do is that you just don't say it... that's what you do if you're actually concerned about painting someone in a bad light / don't know if the fact applies at all.
No. Reality is that people will disagree with other people. And pretending that an opinion has no value because it might upset someone or apply to a generalization or group that isn't intended to mean "all of Group X" so much as "many/most of Group X, from my experience" as a disclosure doesn't mean that the rest of the statement, that could be impersonal or even offensive to some has no value.
If the only person being discussed is the author of the library, and you don’t know them…. what relevance is someone’s experience with other people who share a trait?
The idea of “pretending” here is interesting, I find the whole “ I don't want to judge him” to be its own form of dishonesty….
I am happy to see that the guy has rejected the idea of renaming the project. I am judging him: he is just as arrogant as any other Googlers. I'm sorry I didn't wanted to judge him, or that I even implied it. He deserved all the judgement. Long live the new definition of Vanilla JavaScript!
The repo's own description uses the phrase vanilla JavaScript in this way, and even mixes both meanings within a single sentence.
If the author likes the theme, I'm sure they can still use it indirectly. eg. "icecream.js: add a scoop of vanilla to your project". Or "Go nuts and sprinkle in some Reactive syntax". It's still very punnable, I assure you.