5 ms·

I wonder how it compares to http://vanilla-js.com/ http://vanilla-js.com/

Blackthorn 4y ago
This was downvoted but as someone not too familiar with modern frontend design I'm actually wondering about the comparison myself. When would you use this?
- deleted 4y ago
  [deleted]
- enjoyyourlife 4y ago
  It's a joke website mocking the proliferation of JavaScript frameworks
  - Blackthorn 4y ago
    I know what the vanilla-js website is. I'm wondering what the virtual dom library actually does for you.
  - richardfey 4y ago
    I think it's more subtle than that: it's mocking specifically the small size boast of JavaScript frameworks.
- bob1029 4y ago
  We use Vanilla JS exclusively these days. It is staggering to me the quantity of developers who are still made uncomfortable by the notion that you can construct a high-quality, modern web experience without pulling down a single 3rd party javascript or css dependency. I really hope the pendulum starts to swing back the other way. It is so fast & easy now. MDN makes life a breeze. In 2022, there really isn't an excuse to not use direct DOM manipulation and bare-ass JS, other than pedantic ideological arguments such as "why is my hammer this shitty color?" and "My monster.com filter can't find 'vanilla js' skilled employees". As noted by other posters, VDOM is essentially just overhead. It is both faster & easier to grab that element by its id and change it directly. Playing around with intermediate UI representations, 3rd party frameworks and splitting state between client & server is where 99% of your hell comes from on web development. When you understand 100% of your javascript, setting breakpoints and tracing things in devtools has a lot more power. Hiding from the realities of the open web is only going to cause a prolonged suffering for the junior web developer. Frameworks will come and go. document.getElementById() will be here until the end of time.
  - isbvhodnvemrwvn 4y ago
    How many people are working with you on the project?
  - leeoniya 4y ago
    bare js, or bare DOM specifically has no way of doing declarative changes. if you're okay writing purpose-specific imperative dom manip logic, it gets quite tedius and long in the tooth. your app that could have been 2k lines with a framework is now 10k lines without one, and will grow at 5x the rate, and amount of JS parsed and executed needed to do the same thing. bare DOM works fine up to a certain size/complexity app, and up to a certain size dev team in the single digits.
    - morrvs 4y ago
      Did some research on this a while ago and I‘d wager that 5x in LOC & growth is a bit off: https://github.com/morris/vanilla-todo https://github.com/morris/vanilla-todo - probably it’s more around 1.5x (which can still be problematic). Would be interesting to rewrite the study declaratively and compare again.
      - leeoniya 4y ago
        yes, 5x is probably off, but 2x is likely typical, even if you create optimizing mutation helpers like setAttrs(el, prevAttrs, nextAttrs)
      - Blackthorn 4y ago
        Wow, I really love that experiment. Really explains a lot about frameworks to me, despite being an exercise in not using them. Thank you so much for making that. When I look at what you've written under those restrictions, the biggest problem I flag as a general software engineer is how the events get created, defined, listened to, etc. This tells me that if I was building something "large" like that, the first third-party library I'd want to integrate is something for handling those event streams in a more rigorous and robust fashion.
    - bob1029 4y ago

This was downvoted but as someone not too familiar with modern frontend design I'm actually wondering about the comparison myself. When would you use this?

deleted 4y ago
[deleted]
enjoyyourlife 4y ago
It's a joke website mocking the proliferation of JavaScript frameworks
- Blackthorn 4y ago
  I know what the vanilla-js website is. I'm wondering what the virtual dom library actually does for you.
- richardfey 4y ago
  I think it's more subtle than that: it's mocking specifically the small size boast of JavaScript frameworks.
bob1029 4y ago
We use Vanilla JS exclusively these days. It is staggering to me the quantity of developers who are still made uncomfortable by the notion that you can construct a high-quality, modern web experience without pulling down a single 3rd party javascript or css dependency. I really hope the pendulum starts to swing back the other way. It is so fast & easy now. MDN makes life a breeze. In 2022, there really isn't an excuse to not use direct DOM manipulation and bare-ass JS, other than pedantic ideological arguments such as "why is my hammer this shitty color?" and "My monster.com filter can't find 'vanilla js' skilled employees". As noted by other posters, VDOM is essentially just overhead. It is both faster & easier to grab that element by its id and change it directly. Playing around with intermediate UI representations, 3rd party frameworks and splitting state between client & server is where 99% of your hell comes from on web development. When you understand 100% of your javascript, setting breakpoints and tracing things in devtools has a lot more power. Hiding from the realities of the open web is only going to cause a prolonged suffering for the junior web developer. Frameworks will come and go. document.getElementById() will be here until the end of time.
- isbvhodnvemrwvn 4y ago
  How many people are working with you on the project?
- leeoniya 4y ago
  bare js, or bare DOM specifically has no way of doing declarative changes. if you're okay writing purpose-specific imperative dom manip logic, it gets quite tedius and long in the tooth. your app that could have been 2k lines with a framework is now 10k lines without one, and will grow at 5x the rate, and amount of JS parsed and executed needed to do the same thing. bare DOM works fine up to a certain size/complexity app, and up to a certain size dev team in the single digits.
  - morrvs 4y ago
    Did some research on this a while ago and I‘d wager that 5x in LOC & growth is a bit off: https://github.com/morris/vanilla-todo https://github.com/morris/vanilla-todo - probably it’s more around 1.5x (which can still be problematic). Would be interesting to rewrite the study declaratively and compare again.
    - leeoniya 4y ago
      yes, 5x is probably off, but 2x is likely typical, even if you create optimizing mutation helpers like setAttrs(el, prevAttrs, nextAttrs)
    - Blackthorn 4y ago
      Wow, I really love that experiment. Really explains a lot about frameworks to me, despite being an exercise in not using them. Thank you so much for making that. When I look at what you've written under those restrictions, the biggest problem I flag as a general software engineer is how the events get created, defined, listened to, etc. This tells me that if I was building something "large" like that, the first third-party library I'd want to integrate is something for handling those event streams in a more rigorous and robust fashion.
  - bob1029 4y ago