[HN Gopher] VanJS (Vanilla JavaScript): smallest reactive UI fra...
___________________________________________________________________
VanJS (Vanilla JavaScript): smallest reactive UI framework
Author : Lwrless
Score : 234 points
Date : 2023-05-25 07:31 UTC (15 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| WesSouza wrote:
| Cute.
| ricardobeat wrote:
| Throwback to ten years ago and libraries like Mercury:
| https://www.npmjs.com/package/mercury
|
| This is what we were doing before React and Babel came along. No
| dependencies, no transpiling, light weight, no IDE setup, were
| all a given and not special features.
| montroser wrote:
| Very cool! See also El, which is similarly sized, with an
| arguably more natural reactive interface:
| https://github.com/frameable/el
| yoyoyu wrote:
| You can try this plugin to quickly land UI animations.
| https://pag.art/
| pyrolistical wrote:
| What does "unopinionated Reactive UI framework" even mean?
| progx wrote:
| Use it as you want, it will not force you to build your UI in a
| specific way.
| hu3 wrote:
| But it does force: const Hello = () => div(
| p("Hello"), ul( li("World"),
| li(a({href: "https://vanjs.org/"}, "VanJS")), ),
| )
| pyrolistical wrote:
| Neither does react?
| pjmq wrote:
| To my eye, this makes vanilla JS more like React rather than
| making vanilla JS reactive. I'm basically looking for an even
| lighter Svelte if I can get it. Maybe this just isn't for me!
| pfg_ wrote:
| If you just want to make vanilla js reactive, you can use solid
| js but without jsx (or something similar). This library could
| likely do the same. import { createRoot,
| createSignal, createRenderEffect } from "solid-js";
| function SomeComponent() { const [count, setCount]
| = createSignal(0); const result =
| document.createElement("button");
| createRenderEffect(() => result.textContent = "++ (" + count()
| + ")"); result.onclick = () => setCount(count() +
| 1); return result; }
| createRoot(cleanup => { const appv =
| document.getElementById("app");
| appv.appendChild(SomeComponent()); });
| spyke112 wrote:
| > VanJS has the vision to be the scripting language for UI, just
| like bash is the scripting language for terminal.
|
| I find this quite strange. Wouldn't javascript be to the browser
| what Bash is for the terminal? This is after all just another
| library.
| madmoose wrote:
| Bash?
|
| So VanJS will make the simple things easy and anything else
| nigh-on impossible?
| SquareWheel wrote:
| 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.
| rob74 wrote:
| 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?
| alex_suzuki wrote:
| Hey, that's actually a pretty cool name.
| mbork_pl wrote:
| Or Null.js. Or undefined.js.
|
| And now I want to create a library/framework/whatever called
| NaN.js...
| mbork_pl wrote:
| Or even better: objectObject.js! Also, Infinity.js sounds
| like a really cool name, too...
| usrbinbash wrote:
| Would that be equal to zero.js?
| rawoke083600 wrote:
| 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.
|
| Anywhoo congrats on shipping something.
| ptx wrote:
| > _Also it 's almost immoral calling "a new" project
| "lightweight" and "small". Of course it is lightweight and
| small, it's a new project !_
|
| Unless it's Swing, where a "lightweight" component is one
| that uses enormous piles of slow Java code to duplicate
| native platform functionality.
| Sohcahtoa82 wrote:
| Never understood why Java duplicated (poorly) native
| platform functionality rather than merely acting as a
| wrapper around the native platform.
| aspyct wrote:
| Yes, please be that guy. Or I'll do it.
|
| Vanilla Javascript refers indeed to "javascript without a
| framework". So creating a framework and calling it "vanilla
| javascript" is... wrong?
| ajd1988 wrote:
| 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
| aigoochamna wrote:
| I'd like to suggest my new reactive JS framework called
| "react.js" not to be confused with reactjs.
| steren wrote:
| I agree with you and I opened https://github.com/vanjs-
| org/van/issues/18
| modinfo wrote:
| Suggestion 2: call it IceCreamJS or just IceJS/CreamJS
| gs17 wrote:
| jsAlaMode?
| FrankyHollywood wrote:
| A framework build not to be a framework, it's almost
| philosophical :)
|
| https://plato.stanford.edu/Archives/Fall2012/entries/liar-
| pa...
| jitl wrote:
| 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.
| ohgodplsno wrote:
| Minified React is 1 line, line length isn't exactly a great
| judge of how much it does.
|
| It's 3KB of barely documented code.
| not_your_vase wrote:
| Seems pretty vanilla compared to the full fat, popular
| alternatives? Absolutely!
|
| Does it seem vanilla compared to vanilla? Haha..
| nailer wrote:
| That's nice but still: don't do that. VanillaJS is already
| a thing. Make your thing have a different name.
| jwarren wrote:
| You're mixing metaphors there! It might be lightweight but
| it's still a flavour.
|
| It's still not part of the common browser API, so yes it's
| easy to add, but no, it's not vanilla.
| Anon4Now wrote:
| > it's still a flavour.
|
| > it's not vanilla.
|
| Hate to interrupt, but vanilla is a flavor. And it's a
| pretty good one, dammit!
| rgoulter wrote:
| Insofar as the discussion on the name "vanilla
| javascript" goes, this mixes metaphors.
|
| "Vanilla JavaScript" implies "without anything added".
| nextlevelwizard wrote:
| If I tell someone to "just use vanilla js" and they go
| googling and end up using VanJS instead.... that aint good.
| usrbinbash wrote:
| > Seems pretty vanilla
|
| 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.
| rawoke083600 wrote:
| ^^^100%
| zambal wrote:
| 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.
| NoWizards wrote:
| 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.
| usrbinbash wrote:
| > so that's Vanilla JS, right
|
| 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))
|
| This isn't: awesomeLib().goesBrrrrr()
|
| > Trying to make Vanilla JS a strict definition seems
| pointless to me in the first place.
|
| Being able to name things, and having clarity in a
| community about what names denote, is anything but
| pointless.
| svachalek wrote:
| The important part is that if you don't copy VanJS into a
| script tag, or use it all, you're still doing Vanilla JS.
| amelius wrote:
| Suggestion: call it Bourbon JS. Wikipedia:
|
| > The majority of the world's vanilla is the V. planifolia
| species, more commonly known as Bourbon vanilla.
| meigwilym wrote:
| Already taken. I know it's not JS but it's front end
| tooling.
|
| https://www.bourbon.io/
| amelius wrote:
| Vanilla was already taken too:
|
| https://github.com/idevz/vanilla
| abirch wrote:
| Wait people write JavaScript without drinking bourbon?
| tipiirai wrote:
| I prefer Scotch
| usrbinbash wrote:
| My goto JS drink is Absinthe.
| mikeryan wrote:
| You writing your front ends in Elm then?
| jcpst wrote:
| Please create a PR for my library goto-drink.js which
| uses labels for each libation so you can continue or
| break your drink.
| WorldMaker wrote:
| 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.
| elgenie wrote:
| The etymology is legit and comes from ice cream, for
| which vanilla is considered the default or "plain"
| flavoring.
|
| 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.
| Onewildgamer wrote:
| No thanks, I get high with Javascript alone and a
| hangover so bad that lasts the entire weekend.
| egeozcan wrote:
| 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.
| dahwolf wrote:
| I will up you. Using the word "vanilla" to refer to anything
| neutral, default, or basic is wrong.
|
| Vanilla is a sophisticated flavor, not to mention a precious
| and expensive ingredient. Most people have never consumed
| real vanilla in their lifetime.
| dheera wrote:
| Similarly, using the word "original" to describe plain
| potato chips is wrong. It's the most unoriginal flavor of
| the lot. Just call it "plain".
| brabel wrote:
| Vanilla.js is the most popular framework in the world!!!!
|
| http://vanilla-js.com
|
| Also has the smallest footprint:
|
| 0 bytes uncompressed, 25 bytes gzipped!
| pqdbr wrote:
| This is hilarious. I lost it at the empty line for loading
| it in production.
| robby_w_g wrote:
| > 0 bytes uncompressed, 25 bytes gzipped!
|
| Compression Considered Harmful
| Max-q wrote:
| I came to be that guy. Vanilla JavaScript is the term for plain
| JS without any framework, library or plugins.
| tracker1 wrote:
| window.$ = (selector) => applyExtendedTools(Array.f
| rom(document.querySelectorAll(selector)));
|
| Oh noes, I'm now using a defacto Framework, even if I wrote
| the applyExtendedTools and the $ function to give me
| something like a lighter jQuery.
| [deleted]
| progx wrote:
| That is why the name is only half vanilla: van ;-)
| rob74 wrote:
| They could have taken another part of vanilla and called it
| nilJS, but unfortunately JS uses null and not nil, so it
| doesn't quite work...
| BerislavLopac wrote:
| Could have named it StraciatellaJS then. ;)
| progx wrote:
| A following JS-Framework ;)
| nathell wrote:
| This. I originally thought this was a rebranding of
| http://vanilla-js.com/ and I'm disappointed.
| vmfunction wrote:
| what is interesting about that is when I saw solid.js
| performance chart, it is the closest to vanilla js in terms
| of performance.
| MrJohz wrote:
| 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.
| stcg wrote:
| I agree.
|
| 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.
| mattigames wrote:
| Yeah, just call it VanJS everywhere and never call it "Vanilla
| JavaScript" and that would be good enough.
| campbel wrote:
| 100% I thought this was a meme repo like nocode
| not_your_vase wrote:
| It was created by a Googler. I don't know this guy, there is a
| real possibility that he is the exception, I don't want to
| judge him. However Google and Googlers have been historically
| quite arrogant and inconsiderate of others when it came to
| naming and renaming projects. I wouldn't hold my breath to see
| this project renamed.
| duxup wrote:
| I feel like saying that you don't want to judge someone and
| then generalizing about people like them is pretty much
| putting that judgment out there.
| not_your_vase wrote:
| Saying "I don't want to judge" doesn't mean that I can
| avoid doing it (unless I avoid writing the thing down
| completely).
|
| There are things that can't be written down without hidden
| (or obvious) judgement. This is one of those.
| duxup wrote:
| Why would you say you don't want to judge if that's what
| you're going to do anyway?
| pessimizer wrote:
| 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.
| duxup wrote:
| >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.
| tracker1 wrote:
| 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.
| duxup wrote:
| 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....
| jatins wrote:
| I also thought this was a "joke" on how you don't need a
| framework. But looks like it is indeed a framework so
| definitely confusing name.
|
| 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
| paulddraper wrote:
| People are running their code on servers calling it
| "serverless."
|
| We've somehow accepted that nomenclature.
| dreamcompiler wrote:
| Kinda like calling a cloud server "serverless."
|
| 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."
| Waterluvian wrote:
| I love your suggestion and slogan.
| croes wrote:
| How about an alternative name like Pure JS (already taken), JS
| Only, No-Framwork framework
| ironmagma wrote:
| Don't you know, it's 2023 and we've decided words don't mean
| anything?
| BiggerBio2 wrote:
| [dead]
| hrnn wrote:
| Might be of interest as well https://github.com/zserge/o
|
| Would seem that it's not difficult to come by a framework tiny
| and functional. The question is, how long are they valuable to
| maintain and how tiny they keep if you cater for all the corner
| cases and fix bugs
| cutler wrote:
| It can do "Hello world". How cool is that?!
| ano88888 wrote:
| Until i run into a big bottleneck in react and cannot find a way
| to overcome it, i am not gonna switch from react to yet another
| new framework. Time is better allocated for more important
| things.
| mbork_pl wrote:
| That's not the point. Imagine wanting to do a quick prototype,
| for example. A miniframework like this could be a great fit. Or
| when you code something (probably not too big) from scratch.
| keb_ wrote:
| I think the API is quite nice. I've always been a fan of the Elm-
| like `div`, `p`, `span`, etc. individual html element functions
| for templating.
|
| The approach to local state is also similar to Preact Signals,
| which is cool.
| pier25 wrote:
| Some day browsers will implement native data binding with
| reactivity and the current dark ages of front end development
| will end.
| mathgladiator wrote:
| This is my dream! I started RxHTML with the premise that
| something was missing from HTML, so I just added it:
| https://news.ycombinator.com/item?id=36067280
|
| It's working surprisingly well for a client that I'm working
| for.
| winrid wrote:
| I thought this was gonna be terrible but it actually looks pretty
| nice. It reminds me of Nim's Karax.
| shanghaikid wrote:
| nice project, very cool, but I don't see the meaning to do this.
|
| nowadays, most small project can use vanilla javascript, if they
| don't need a framework, they really don't need it.
|
| if we are building a large project, why not use react/vue/svelte
| ? better docs, better features, better community.
| JodieBenitez wrote:
| > if they don't need a framework, they really don't need it.
|
| I don't think it's an "all or nothing" situation. I do UIs
| without big frameworks, but that doesn't mean I don't use any
| library for some needs. I personally appreciate anything that
| needs no transpiling.
| robertoandred wrote:
| Not sure how this is any more natural than JSX/HTML. It looks
| much messier and harder to follow.
|
| Also I'd like to see how they handle mount/unmount logic like
| event listeners.
| _old_dude_ wrote:
| No shadow dom, so no mount/unmount logic ! A whole new DOM sub-
| tree is re-created each time a value change.
|
| There is an example in the tutorial about how state are handled
| [1]. [1] https://vanjs.org/tutorial#state-binding
| paulddraper wrote:
| s/shadow/virtual/
| robertoandred wrote:
| So how do you clean up global event listeners, clear
| intervals and timeouts, etc when a component unmounts?
| RGBCube wrote:
| I was expecting this to be a prank project saying that you should
| use vanilla JS, my disappointment is immeasurable.
| onion2k wrote:
| The "Hello World" example is a really good example of why React,
| Vue, etc are better than something more minimal like this library
| if you're optimizing for speed. The page will show nothing until
| the script runs, which requires downloading the VanJS lib and the
| script itself. You could inline them into the page, but that gets
| seriously messy at scale. A modern React app that's using some
| serverside rendering for the initial page load will send the user
| a page of HTML that can be streamed (rendered as it downloads) so
| it'll display pretty much instantly (if you're concerned about
| styles you could inline for the important stuff and defer for
| rest). The React "Hello World" will be a lot bigger but it'll
| display _a lot_ faster on a slow connection, and it 'll work if
| the user has JS disabled.
|
| Obviously it's early days for VanJS and the authors could add all
| sorts of fancy SSR and clever scheduling, but if they do they'll
| lose the tiny size and end up making something that starts
| looking very like React (or more likely, Preact).
|
| It's all a trade off. Sacrificing speed and complexity for size
| and DX is fine. You just need to be aware that's what you're
| doing, and neither is 'better' for all aspects of web app dev.
| keb_ wrote:
| You are comparing apples to oranges. The author could probably
| couple their library with https://vite-plugin-ssr.com/ and have
| something comparable within a day.
|
| The reality is most running React apps today are still
| traditional SPAs, and chances are likely the same apps can be
| rewritten with VanJS (or any other SPA framework) and the users
| would not notice a difference.
| austin-cheney wrote:
| _The page will show nothing until the script runs_
|
| If you know what you are doing you can achieve full state
| restoration of a large SPA before CSS paints to the screen. In
| my personal app I am able to complete state restoration within
| the first 80ms of page load on old hardware. Vue and React are
| not capable of providing this.
| digging wrote:
| Can you elaborate as if I didn't know what I was doing?
| austin-cheney wrote:
| https://github.com/prettydiff/wisdom/blob/master/performanc
| e...
| holoduke wrote:
| Just encapsulating css and js inside the html works perfectly
| fine. In a SPA you nowadays use history api for navigation
| and make dynamic dom changes on the fly. You only have to
| make sure than you serve the minimum amount of js and css on
| an initial page load. Then when the page is loaded you load
| the rest. Slight inefficient cache model when lots of initial
| page loads from different urls, but usually that's never
| happening (people are entering a site at one specific url) I
| have a SPA, full size is about 3mb of js files. Separate html
| files containing only that page are max 20kb. Super fast
| rendering. Nothing server side.
| tracker1 wrote:
| I often find splitting the difference is useful...
| embedding the CSS with the HTML, as different routes from
| the server, delivering the same html will still result in
| more cache being used, and lack of caching if a user
| shares/bookmarks something different from what a user may
| already have cached. async loading for routes and splitting
| on the bundler can help a lot as well. Similar to async
| load any graphing/charting libs only on components that
| need them too.
|
| In the end, it depends on what you are doing... if you're
| wanting to do paged records against a database, then client
| rendering can help... The direction of React server
| components, next.js and the like bridge these gaps well.
| Combined with edge services like deno deploy, cloudflare
| pages/workers and others make this even more of a no
| brainer for many use cases.
|
| There's also a place for pre-rendering most content... I
| don't know why any marketing or content sight like blogs
| wouldn't be static rendered at this point. JS enhancement
| for things like sharing or comments.
| winrid wrote:
| They list SSR as a feature.
|
| Also, using rollup would be trivial.
| SadWebDeveloper wrote:
| You have pretty much described the "php way" of developing
| things, is funny js-driking cool-aid guys talk about "SSR"
| being the thing to have, when we already had that, we already
| found that it can't scale without lots of money and started
| pushing computation to the client and now we are bring them
| back because it's not fast on the initial load...
|
| damned we have come to full circle whats next, an assembly
| language so we can run binary code inside the browser kinda the
| way activex and applets just used do it... wait isn't that the
| whole point webassembly? _sight_ you f** javascript developers
| have done it again _sight_
| MrJohz wrote:
| This is fairly reductive. SSR is less about rendering HTML on
| the server, and more about having both the initial render and
| the client-side updates use the same process. Contrast this
| with other ways of rendering the front-end where either the
| client needs to build the entire view itself, or you need to
| write a separate application to do any client-side
| manipulation that might be necessary.
|
| As with everything in software, it's all about tradeoffs.
| Using PHP to render your templates works great if there's
| limited client-side interaction (say, blogs, forums,
| documents, marketing pages etc), while frontend rendering
| allows you to build much more complicated applications that
| can react much quicker to user interaction, but will be
| slower to load the more complicated they become. And SSR
| tools try and have the best of both worlds, but make other
| aspects more complex in exchange.
| threatofrain wrote:
| I'd argue that SSR is somewhat orthogonal to React or VanJS. I
| don't see preliminary reasons to suspect that VanJS will be
| unable to plug into meta frameworks and eventually get SSR.
| onion2k wrote:
| There's a bit of work to do to make a JS framework work
| server side. You need a mechanism to render in Node, which
| assumes you don't use any browser APIs that aren't available
| in whatever DOM library you use. Then you need a way to
| stream the HTML to the client, but that's easy with Express.
| Then when the page has loaded on the client you need a way to
| know what the server rendered and attach listeners to the
| reactive bits (and optionally to rerender in the background
| on the client to check things are working properly). That's
| assuming you don't bother with things like lazy loading and
| dynamic imports, which will make devs a bit cross because
| those are really nice things to have.
|
| It's not a huge amount of effort and it's definitely
| achievable by a single dev leaning on some existing
| libraries, but it would mean giving up on some of the
| lightweight aspects of Van, and, like I said, you'll end up
| half way to building your own React library...
| _old_dude_ wrote:
| Given that van replace the whole tree each time a value
| changed, SSR for van is simpler. You run chrome server
| side, capture the DOM once van has finished its first
| execution and modify the HTML of the page to includes the
| new nodes.
| flagrant_taco wrote:
| Don't run chrome on the server for SSR, I beg you. That's
| a massive performance hit and scales terribly with all
| the memory usage.
| _old_dude_ wrote:
| In this case, you can do it on your CI as part of the
| deployment, so it's not that bad.
| flagrant_taco wrote:
| Sure that's doable if the site is static only. I was
| going off the SSR terminology which usually means the
| html is rendered at the time of request instead of built
| one ahead of time (SSG)
| holoduke wrote:
| The clieent lib could be 2kb and the speed difference between
| first render vs server side render is less than 10ms. In fact
| the client side render version could be faster if the compiled
| output is larger than 2kb. Which then normally must be pushed
| from the server
| omegabravo wrote:
| Two way different scenarios where this would be used, so
| different I wouldn't even compare them.
|
| I'd use this to prototype a basic web interface to interact
| with something like an IoT device. React would be overkill, and
| I doubt React would be faster to render than this for that
| scenario.
|
| On a slow connection, the fully rendered interface could well
| be more bytes than this plus some data. I would say first to
| render depends entirely on what you're doing.
|
| React is used in _way_ more places than a blog or ecommerce
| site.
| tracker1 wrote:
| There's a "mini-van" renderer and examples on usage for
| node/deno on the library's website. I actually found that
| probably more compelling than the JS client library usage.
|
| For me what's missing is wiring with a larger state machine
| (jotai or similar) and async importing of components at
| runtime.
|
| In the end, I'm not completely convinced this is better than
| React/Preact/Inferno, and even then, adding a UI library like
| mui will get even bigger. It's the patterns and the size/scale
| of what you're building and how many other devs you would have
| to develop with that should determine things like this. Are
| your using on generations old phones where access is akin to
| slow 3g, or is everyone on a modern 1440p+ desktop with over
| 30mbps of bandwidth?
| 10xDev wrote:
| Web development is going to come full circle once everyone comes
| to terms with the fact that web development has been
| overcomplicated and you don't need 1000 packages and abstractions
| on top of abstractions just to interact with some DOM elements.
| zamalek wrote:
| But that's only because the frameworks guided the direction of
| the specifications. You couldn't use vanilla in this way 10
| years ago.
| onion2k wrote:
| _you don 't need 1000 packages and abstractions on top of
| abstractions just to interact with some DOM elements_
|
| I don't think many developers believe that you do. Most of the
| complexity around 'modern web dev' isn't about achieving the
| basics of moving DOM nodes around. If that's what you're doing
| then it's hard to argue that a framework adds much benefit.
|
| Frameworks bring two benefits:
|
| Firstly, they push you down a specific path around the shape of
| the code. When you're on a team of 20 working on part of an app
| that shares data across n other components then you need
| something to keep the code from turning into a swamp.
| Frameworks bring that experience. You don't need it on a small
| app or if you're a lone dev, but even then it _kind of helps_
| if you 're not especially disciplined. If you want an example,
| have a look at some of the demos from the react-three-fiber
| team. It's _so much nicer_ to work with a declarative API than
| imperative vanilla Three.js code.
|
| Secondly, frameworks _used well_ enable you to eek out
| additional perf. Building an app that renders a complex page in
| under 16ms isn 't _that_ easy if there 's a lot going on, and
| leaning on a scheduler like the one in React makes it simpler.
| It's still far too easy to get it wrong and kill all your perf
| even in a framework though.
| smarkov wrote:
| > Building an app that renders a complex page in under 16ms
| isn't that easy if there's a lot going on
|
| We struggle to render a few boxes and some text under 16ms
| while games with vastly more complex sound, network, physics,
| UI and whatever else systems render frames in < 8ms at 4k.
| onion2k wrote:
| _We struggle to render a few boxes and some text under
| 16ms_
|
| Only if a dev has screwed up. _Most_ simple sites are fine.
| You have to push the DOM quite hard for _the browser_ to be
| the bottleneck. I 've worked on apps that have DOM trees
| with 60,000+ nodes that remain under 16ms (because very few
| were actually changing at any given time..)
|
| _games with vastly more complex sound, network, physics,
| UI and whatever else systems render frames in < 8ms at 4k_
|
| The Servo project is bringing a lot of what makes game UIs
| fast to browsers. It's a _massive_ shame that it 's not a
| Mozilla/Firefox backed idea any more but it's still going.
| Hopefully it'll get a bit more mainstream one day.
| smarkov wrote:
| > Only if a dev has screwed up. Most simple sites are
| fine. You have to push the DOM quite hard for the browser
| to be the bottleneck. I've worked on apps that have DOM
| trees with 60,000+ nodes that remain under 16ms (because
| very few were actually changing at any given time..)
|
| You mentioned that frameworks like React make it simpler
| to get better performance but based on my observations
| it's quite the opposite and React is often a double
| barreled gun where one of the barrels is constantly
| pointing at your feet. With vanilla JS (not the one from
| this post) you have to put effort to get everything to
| update properly. With React you put effort to get the
| least amount of things to update. It's not even about DOM
| size but about managing state and how much code gets run
| on state change.
|
| To give you an example - Reddit is a simple website. You
| have a list of posts which are either text, image, or a
| video and each of them has comments. Absolutely nothing
| complicated about that, yet the performance on their
| React frontend, even with all analytics JS and ads
| blocked, is horrendous. You would assume that at Reddit's
| scale they'd be able to hire competent React developers.
| onion2k wrote:
| FWIW the app that pushed 60,000 DOM nodes around at 60fps
| was entirely in React.
|
| I keep seeing an advert for a Principle Frontend Dev at
| Reddit on LinkedIn. Maybe I should apply...
| giancarlostoro wrote:
| The day they make native web components as useful as using Vue
| or React without needing a single third party library, that is
| when this might happen. Until then, I dont think its happening
| any time soon.
| purerandomness wrote:
| Already happening, see the current popularity of htmx [1]
|
| [1] https://htmx.org/examples/infinite-scroll/
| chrsjxn wrote:
| This narrative (https://vanjs.org/about#story) about modern JS
| tooling being opaque, exclusive, and hard to learn is
| frustrating.
|
| If all you need is HTML rendering and basic state, any modern web
| framework will do that extremely simply. The barrier to entry is
| really not that high!*
|
| *Except maybe at Google. I hear their internal tooling is a huge
| pain to work with.
| jehna1 wrote:
| Glad to see jsx-less approaches to declaring dom!
|
| Very similar to: https://github.com/jehna/longwood
| paddw wrote:
| You are not really getting anything in the size difference
| between this and something like preact, you are going to end up
| bottlenecked on something else like waiting for CSS to load. This
| is fine if you just want to write the code in a minimalist style,
| but I really doubt cutting things back to this extreme has
| tangible performance benefits for like 99% of applications.
| glutamate wrote:
| Since the other comments are complaining about something or
| other, I just want to say that this looks great! I can imagine
| using this for something that needs more than jQuery and less
| than react.
|
| I use the same Html-in-JS syntax for my own project and it works
| really well. The good folks at solenya have written a converter:
| https://www.solenya.org/convert
| areknawo wrote:
| [dead]
| tasubotadas wrote:
| Why is everybody so obsessed with size? 100kB means nothing these
| days.
| ilrwbwrkhv wrote:
| Because of people like you we will have the collapse of
| civilization, global warming and apps like Slack.
|
| Not caring about memory usage, data usage, speed is the reason
| why software is so brittle and broken these days.
| zuprau wrote:
| Wrong. You know it never ends up being 100kb, and when it
| reaches 1MB (it always does) then you get the real issues.
|
| It's because of your thinking that we got bloated webpages.
| 130e13a wrote:
| i'm also a bit confused why e.g. they have an explicit rule
| that they only use `let` instead of `const` when declaring
| variables, "for reducing the bundle size", which seems like a
| bad trade-off in order to save maybe a couple dozen bytes at
| most?
| pfg_ wrote:
| Don't minifiers convert these anyway? const
| a = 1; let b = 2; console.log(a, b);
|
| bun build --minify a.js // bundles this to:
| var o=1,l=2;console.log(o,l);
|
| It's not even using const or let, it's flattened these
| multiple statements into one 'var' statement
| robertoandred wrote:
| Only if you're targeting super old browsers.
| ra1231963 wrote:
| I'm a bit confused why they made it in the first place given
| the dozens of similar ultra minimal spartan frameworks to
| choose from that nobody uses (every other comment here is
| plugging one).
| jhp123 wrote:
| This library actually has some pretty unique ideas, like
| the use of Proxy objects which is not commonplace in
| javascript frameworks. Even if it didn't, sometimes it's
| just nice to build your own take on something.
| paulddraper wrote:
| They pretend it matters as they download thirty 10MB Tictok
| videos.
| vmfunction wrote:
| The syntax is more like mithril.js, think would just stick with
| that or go with solidjs.
| graup wrote:
| Hard to see a real-world use for this but reading the code and
| docs is pretty interesting. The code taught me some cool tricks.
| Good job!
|
| Some of the binding API is a bit weird, like that object with
| `deps` (State-derived properties). Maybe providing a function for
| this would be more ergonomic.
| benatkin wrote:
| That's cool but my favorite vanilla js framework by far is
| vapor.js. https://github.com/madrobby/vapor.js
| thunderbong wrote:
| Fantastic! It even has 200 forks!
| FireInsight wrote:
| The website for this is top-notch. It always turns me off when
| frameworks have bad websites, thankfully this amazing project
| doesn't.
|
| http://vaporjs.com/
| duxup wrote:
| I got an error trying to go to their website.
| benatkin wrote:
| It's been vapoorized.
| https://www.youtube.com/watch?v=cpads8s5mik
|
| Very on brand. (>_<)
| benatkin wrote:
| https://web.archive.org/web/20120322223910/http://vaporjs.co.
| ..
| xigoi wrote:
| Looks nice, but does it support Internet Explorer?
| Technotroll wrote:
| I really love the documentation for this project! Super-
| intuitive!
| tobr wrote:
| I appreciate that they offer a vapor.packed.js version, for
| those of us who care about keeping bundle size down.
| nologic01 wrote:
| Makes me think that jquery may have missed a boat to integrate
| reactive elements (as there was clearly a need for them for a
| long time before angular, react etc took of) and retain
| relevance.
|
| Maybe for projects that don't aim to replicate desktop app
| functionality there is a "small-is-beautiful" yet all-inclusive
| js library that is missing.
| jefozabuss wrote:
| We probably saw since React came up at least 20-30 of these
| "smallest reactive UI frameworks" with similar API but none of
| them named itself "Vanilla" for a reason.
|
| I share the opinions of others in this thread that the current
| name is an unlucky one.
| esprehn wrote:
| This is really just a DSL to make dom:
|
| https://github.com/vanjs-org/van/blob/3f98060971a8ff141179ef...
|
| And a very simple system that replaces the dom from scratch each
| time any data changes:
|
| https://github.com/vanjs-org/van/blob/3f98060971a8ff141179ef...
|
| That's bad for performance (recomputing the style/layout and
| repainting even for minor changes), bad for accessibility, breaks
| focus, etc.
|
| It's unlikely the smaller bundle size compared to preact and
| friends wins anything once you've abandoned all reuse of the
| rendering engine computations.
| rictic wrote:
| Using tagged template literals with Lit or Preact + htm is more
| readable than Van.js, is much faster on update, and is also
| completely vanilla JS (no JSX and so no build step needed)
| ssdspoimdsjvv wrote:
| While that's true, I wonder how many websites really benefit
| from smart diffing algorithms instead of just directly updating
| the dom.
| 5Qn8mNbc2FNCiVV wrote:
| The diffing algorithm for preact is super simple, I think
| it's along the lines of a dozen lines of code. I'd wager the
| code to directly updating the DOM will be larger than preact
| + usage code
| mathgladiator wrote:
| In my world, I just directly update the DOM which I described
| recently in https://news.ycombinator.com/item?id=36067280
| 0thgen wrote:
| seems like a cool, intuitive library. surprised how much
| discussion time on here was spent on "the name" relative to the
| framework itself
| nektro wrote:
| do not call this vanilla js, that's what using no js is called
| agumonkey wrote:
| ha, the good old html construction functions, i don't know but it
| relaxes me to see that after a year of jsx
| hhthrowaway1230 wrote:
| I like it! Its minimal, super straight forward and easy to
| understand, dont need a transpiler. I'll use it with my next
| upcoming project and see how it fares.
| spankalee wrote:
| HTML-builder APIs like this are a pretty bad idea, IMO.
|
| They assume that HTML is a closed system with no new tags, and
| don't account for custom elements or new tags. It doesn't even
| have support for existing tags like <track>, <b>, or <i> (<i> is
| used by some systems now for icons). It doesn't appear to have a
| way to emit comments.
|
| We have the ability to embed real HTML strings, with expressions,
| directly into JS, which means that the rendering library doesn't
| have to have any knowledge or opinion of what the tags are.
|
| This is what Lit does with lit-html templates. The example in the
| Van readme would be: const Hello = () => html`
| <div> <p>Hello</p> <ul>
| <li>World</li> <li><a
| href="https://vanjs.org/">VanJS</a></li> </ul>
| </div> `;
|
| Such template strings can contain any HTML - any tag, comment,
| attribute, entities, SVG, etc.
| tomtheelder wrote:
| You can just add a generic version tag function that takes a
| tag name as its first param to solve that issue. Lets you
| create your own generator functions with ease for tags that
| aren't included by default. Don't see any reason you can't add
| a comment() function either.
|
| If you use a template string like that then you lose a lot in
| terms of type checking/IDE tooling/etc unless you add a ton of
| complexity, which is antithetical to this library's goals. I
| definitely think they went with the right option.
| masswerk wrote:
| > <i> is used by some systems now for icons
|
| This is somewhat alarming. <i> is still a valid tag and used,
| e.g., for marking up titles of artistic works, etc. (which is
| not a use case for <em>, nor for <cite>.) Similar goes for <b>,
| which is (semantically) different from <strong>.
| bakugo wrote:
| For most icon libraries that use <i> for their icons, it's
| usually just a suggestion and using <span> instead works
| fine. They mainly use <i> because it's "pretty".
| masswerk wrote:
| Actually, it should be a label (or a button, depending on
| the use case).
| bpierre wrote:
| Interestingly the `tags` object seems to support any tag name:
| https://github.com/vanjs-org/mini-van/blob/57b686ced075754ee...
|
| And it still allows to provide specific types for the known
| HTML elements: https://github.com/vanjs-org/mini-
| van/blob/57b686ced075754ee...
|
| Cool stuff
| pcthrowaway wrote:
| I like this, but https://github.com/vanjs-org/van#ultra-
| lightweight should really list svelte, which is only 1.6-1.8kB
| compiled last I checked (though it's possible it makes some of
| the compiled markup that gets shipped larger than the source due
| to component style scoping)
| AbraKdabra wrote:
| > Programming with VanJS feels a lot like React.
|
| _closes tab_
| mattigames wrote:
| If I was making this kind of mini framework instead of this
| a({href: "https://vanjs.org/"}, "VanJS")
|
| I would have gone with this shorter way
| a("VanJS").href("https://vanjs.org/")
|
| And make it chainable and allow class names as second argument as
| in a("About us",
| ".big.red").href("/about.html").target("_blank")
| chrsjxn wrote:
| Tag functions being implemented with a Proxy
| (https://vanjs.org/tutorial#api-tags) could make that a little
| cumbersome, and would break the abstraction that `div(...)`
| just returns an HTMLDivElement you can do whatever you want
| with.
| mattigames wrote:
| Yeah, plus I realized after posting that for nesting children
| it would mean having the properties at the end, not very dev-
| friendly, maybe the way this lib does it is the best way
| (without JSX or anything like that)
| nailer wrote:
| Chaining is very... 2010? Mainly because it's
| used().to().make().awful().APIs().like().this(). It got popular
| then seems to have died out.
|
| href() isn't a function name. One doesn't 'href()' anything.
| mattigames wrote:
| You know what promises are right?
| nailer wrote:
| Yes I do.
|
| Do you use JS or TS currently? We've had async/await since
| ES2017, it's supported everywhere you want, and there's no
| reason to see .then() chains anymore outside jokes
| regarding early 2000's film classic "Dude, Where's My
| Car?".
|
| Pasting some code and cutting out the boring bits:
| const transaction = await makeTransaction(...); const
| signature = await sendAndConfirmTransaction(...);
| const tokenAccountsByOwner = await
| getTokenAccountsByOwner(...);
|
| Even back when .then() chaining was used: chaining only
| existed because that was the only way we had to handle
| promises, rather than because it was a desirable syntax.
| ra1231963 wrote:
| Why would you be so snarky in your answer? Always better to
| be humble and assume you might be wrong. In this case you
| are: Nobody chains promises anymore.
| jamil7 wrote:
| I think the way it's done is correct, an object passed as a
| parameter with key value pairs for attributes seems a lot more
| logical.
| mattigames wrote:
| Maybe, but I bet this way would be slightly faster, because
| the library wouldn't have to loop through keys if they write
| functions for all the most common attributes (href, rel,
| className, type, etc)
| jehna1 wrote:
| Here's one for React:
|
| https://github.com/jehna/nosx
| cynicalsecurity wrote:
| [flagged]
| wingi wrote:
| Please check out https://github.com/jorgebucaran/hyperapp
| rauli_ wrote:
| Now that everyone is advertising their own similar frameworks,
| I guess I'll have to do that too:
| https://github.com/RauliL/pakertaja
| cynicalsecurity wrote:
| [flagged]
| dsego wrote:
| For comparison, similar tiny JS view libraries
|
| - https://redom.js.org 2kB
|
| - https://nanojsx.io 1kB
| jsniffen wrote:
| Another one, https://github.com/jsniffen/tinyjs
| jhp123 wrote:
| My library https://github.com/jhp/imperative is also under 2kB
| eole666 wrote:
| nanojsx looks great! I don't really get why mini-van don't use
| JSX.. Maybe some people just don't want any html tags in their
| project ? Or maybe their template engine allows a lighter
| approach.
| brabel wrote:
| I suppose the idea is to not have to do transpilation.
| keb_ wrote:
| You can avoid a build step by not using JSX.
___________________________________________________________________
(page generated 2023-05-25 23:02 UTC)