And now I want to create a library/framework/whatever called NaN.js...
Vanilla Javascript refers indeed to "javascript without a framework". So creating a framework and calling it "vanilla javascript" is... wrong?
Does it seem vanilla compared to vanilla? Haha..
It's still not part of the common browser API, so yes it's easy to add, but no, it's not vanilla.
> it's not vanilla.
Hate to interrupt, but vanilla is a flavor. And it's a pretty good one, dammit!
"Vanilla JavaScript" implies "without anything added".
It's 3KB of barely documented code.
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.
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".
This is Vanilla JS:
fetch('/readme.txt')
.then(response => response.text())
.then(data => console.log(data))
.catch(error => console.log(error))
awesomeLib().goesBrrrrr()
Being able to name things, and having clarity in a community about what names denote, is anything but pointless.
Minor nitpick, third party library and framework does not modify your browser. They all still run on unmodified browsers.
https://plato.stanford.edu/Archives/Fall2012/entries/liar-pa...
> The majority of the world's vanilla is the V. planifolia species, more commonly known as Bourbon vanilla.
Also, yes, bourbon (spirit) is a good accompaniment to late nights in JavaScript.
https://en.wikipedia.org/wiki/Plain_vanilla
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.
bourbon.js it is?
Also has the smallest footprint:
0 bytes uncompressed, 25 bytes gzipped!
Compression Considered Harmful
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 ?
Vanilla is a sophisticated flavor, not to mention a precious and expensive ingredient. Most people have never consumed real vanilla in their lifetime.
> 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.
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?
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.
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.
Anywhoo congrats on shipping something.
Unless it's Swing, where a "lightweight" component is one that uses enormous piles of slow Java code to duplicate native platform functionality.
I do like the idea of it. A lot of value of React for me is in the composition model and could see this being useful for small projects
window.$ = (selector) =>
applyExtendedTools(Array.from(document.querySelectorAll(selector)));
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."
I was confused reading the page and expected a description of a pattern I could use in actual vanilla JavaScript without any dependencies.
The term 'zero-dependency' played a role in my confusion. "VanJS" is a dependency.
There are things that can't be written down without hidden (or obvious) judgement. This is one of those.
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.
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.
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….
We've somehow accepted that nomenclature.
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.
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.