This is unacceptably huge compared to the similarly named Vanilla JS.
It took me a minute to get it.
0 bytes uncompressed, 25 bytes gzipped
25 bytes is the size of a gzipped empty file.
<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>
Honestly, I am biased and think Vanilla JS wins :D
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.
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.
count.innerText =
up.onclick =
down.onclick =