6 ms·

Try to replicate a sample app made by VanJS with Vanilla JS and check the difference

qayxc 3y ago
challenge accepted (app #2, since #1 is just static), BEHOLD: <script> const Counter = () => { let counter = 0; const updCounter = (delta) => { counter += delta; document.getElementById('count').innerText = `♥ ${counter}`; }; document.getElementById('up').addEventListener('click', () => updCounter(1)); document.getElementById('down').addEventListener('click', () => updCounter(-1)); updCounter(0); }; Counter(); </script> <span id="count"></span> <button id="up">*thumbs-up*</button> <button id="down">*thumbs-down*</button> 15 LoC vs 7 LoC, zero dependencies vs. 0.9kB gzipped or 2.7kB minified. Additional learning curve: 0h vs 1h (allegedly). Honestly, I am biased and think Vanilla JS wins :D
- fs_tab 3y ago
  Elements with an id are globals, so you do this (not that it's recommended): count.innerText = up.onclick = down.onclick = etc
  - qayxc 3y ago
    Technically, every element that's not in the shadow DOM is a global. But yes, there's plenty of ways to implement this and an argument to had for most of them.
    - fs_tab 3y ago
      Right, I should have clarified that they're properties of the window object.
- flying-pig 3y ago
  The fact that you have to manually maintain the binding between states and UI elements and propagate state changes to UI elements is exactly the thing offered by VanJS, or other popular reactive frameworks (despite with a much larger bundle size)
  - qayxc 3y ago
    Sure thing. But it's also one of those things that comes back to bite you when you least expect it: https://vanjs.org/advanced#why-not-dom-valued-states https://vanjs.org/advanced#why-not-dom-valued-states
    - flying-pig 3y ago
      I don't get you. Could you elaborate?
      - qayxc 3y ago
        In the example I linked, the VanJS state cannot contain an element reference. This would lead to unexpected results. So you have to be careful with state management, regardless of whether it's automated or not. There are similar pitfalls, including performance issues, with any state management system, hence dedicated state management solutions like Redux exist to address this. The core of the argument is that complexity sometimes cannot be avoided. You can quickly wind up with moving this complexity elsewhere, e.g. by pulling in an additional library dependency. This results in having to learn, master and manage additional dependencies. Whether that's fundamentally better than the explicit and straight forward way depends on the scope of the project and its specific requirements. There's no silver bullet in any case and pros and cons with every approach.
        flying-pig 3y ago
        Tbh I can't follow your logic here. You mentioned that in VanJS there are things that need to be careful with. But the same is true for other frameworks, even for plain Vanilla JavaScript. Thus what exactly the point that you're trying to make? Complexity can't be avoided for extremely complex use cases. But that doesn't mean a simple solution that can work for most of the use cases has no value.

challenge accepted (app #2, since #1 is just static), BEHOLD: <script> const Counter = () => { let counter = 0; const updCounter = (delta) => { counter += delta; document.getElementById('count').innerText = `♥ ${counter}`; }; document.getElementById('up').addEventListener('click', () => updCounter(1)); document.getElementById('down').addEventListener('click', () => updCounter(-1)); updCounter(0); }; Counter(); </script> <span id="count"></span> <button id="up">*thumbs-up*</button> <button id="down">*thumbs-down*</button> 15 LoC vs 7 LoC, zero dependencies vs. 0.9kB gzipped or 2.7kB minified. Additional learning curve: 0h vs 1h (allegedly). Honestly, I am biased and think Vanilla JS wins :D

fs_tab 3y ago
Elements with an id are globals, so you do this (not that it's recommended): count.innerText = up.onclick = down.onclick = etc
- qayxc 3y ago
  Technically, every element that's not in the shadow DOM is a global. But yes, there's plenty of ways to implement this and an argument to had for most of them.
  - fs_tab 3y ago
    Right, I should have clarified that they're properties of the window object.
flying-pig 3y ago
The fact that you have to manually maintain the binding between states and UI elements and propagate state changes to UI elements is exactly the thing offered by VanJS, or other popular reactive frameworks (despite with a much larger bundle size)
- qayxc 3y ago
  Sure thing. But it's also one of those things that comes back to bite you when you least expect it: https://vanjs.org/advanced#why-not-dom-valued-states https://vanjs.org/advanced#why-not-dom-valued-states
  - flying-pig 3y ago
    I don't get you. Could you elaborate?
    - qayxc 3y ago
      In the example I linked, the VanJS state cannot contain an element reference. This would lead to unexpected results. So you have to be careful with state management, regardless of whether it's automated or not. There are similar pitfalls, including performance issues, with any state management system, hence dedicated state management solutions like Redux exist to address this. The core of the argument is that complexity sometimes cannot be avoided. You can quickly wind up with moving this complexity elsewhere, e.g. by pulling in an additional library dependency. This results in having to learn, master and manage additional dependencies. Whether that's fundamentally better than the explicit and straight forward way depends on the scope of the project and its specific requirements. There's no silver bullet in any case and pros and cons with every approach.
      - flying-pig 3y ago
        Tbh I can't follow your logic here. You mentioned that in VanJS there are things that need to be careful with. But the same is true for other frameworks, even for plain Vanilla JavaScript. Thus what exactly the point that you're trying to make? Complexity can't be avoided for extremely complex use cases. But that doesn't mean a simple solution that can work for most of the use cases has no value.