141–150 of 214 posts
Earlier quoted context omitted.
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.
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.
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…
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…
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.
That's cool but my favorite vanilla js framework by far is vapor.js. https://github.com/madrobby/vapor.js
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/
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…
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.
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
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…
While that's true, I wonder how many websites really benefit from smart diffing algorithms instead of just directly updating the dom.
Some day browsers will implement native data binding with reactivity and the current dark ages of front end development will end.
It's working surprisingly well for a client that I'm working for.
Earlier quoted context omitted.
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/
I got an error trying to go to their website.
Very on brand. (˃̣̣̥‿˂̣̣̥)
Earlier quoted context omitted.
> 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 wor…
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.
Earlier quoted context omitted.
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?
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…