Hacker News Reader

Comment by LAC-Tech | Hacker News Reader

I feel like people severely over-estimate the level of abstraction some frontend tools give you.

Out of boredom once I went through the redux tutorial, and coded an alternate version with vanilla JS. My vanilla code was actually shorter, including the code needed to implement something like the observer pattern.

JS in 2022 is a really powerful language, and the DOM APIs have improved tremendously. Now people will hit back with "well you'll just end up re-inventing a framework" - but do you really? You just write an app against the abstraction of the DOM, instead of the parallel abstraction of the react VDOM.

I'm sure at a certain scale it makes a lot of sense to standardised on a framework so you can easily replace people who burn out after spending half their time updating libraries. But for smaller projects - I'm just not seeing it.

View on HN

One think I'm missing in vanilla JavaScript is reactivity. What's the simplest way to make it so that the page will always display the current value of a variable (or something calculated from the current value)?

Something like the observer pattern:

https://en.wikipedia.org/wiki/Observer_pattern#JavaScript

If you look at it from another angle, you might see that `setState` could take a function oldState => newState instead of a raw value. Then you have a `reducer` in the sense of redux.

You could also just make the list of observers functions, instead of objects with the signal method.

All easily done in about 20 LOC.

This is why I just love Sveltekit. There is just not that much to even learn beyond vanilla JS.

I once tried to learn Svelte, expecting to be able to write a simple webpage in HTML and JS and having Svelte make it interactive, but it asked me to clone a whole template repo. No, thanks.

Proxy [1] is one way to do it using vanilla JavaScript.

[1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

How do the frameworks you use do it?

If the value is remote, I assume a websocket or regular AJAX poll. If the value is local, simply binding an event emitter to the DOM should do it. Both would be lower load and compute than most frameworks.

https://github.com/zserge/q, an experimental minimalistic clone of Vue, uses object.defineProperty. (There has been an attempt to use Proxy instead, but there's a problem with it: https://github.com/zserge/q/issues/1) I don't think I could make it any lighter if I wanted to.

How do you manage the lifecycle of objects with the observer pattern? I saw an example of the pattern below that is crucially missing a 'remove' function to unsubscribe from the subject. Like when using events at the app/controller level, I have found a layer/glue starts to form associated with the adding and removing of subscription handlers, and it is this subscription management layer where the majority of complexity and bugs lie. Being inspired by immediate mode renderers, this is what makes React so great - it basically eliminates this entire layer. I might have PTSD working with observers and events from my AS3 days, but if I were building a single page app I wouldn't use the observer pattern over React unless there was a robust way to manage the subscriptions. Perhaps I am overcomplicating something that is actually pretty simple, but I imagine using the observer pattern by itself doesn't really scale beyond the component level?

Yeah that's an interesting problem. I mean the simple answer is you just make an unsubscribe method. But that doesn't solve the layer of adding and removing subscription handlers.

The simple answer from FrTime is to use weak references.

Using a subtree, childlist MutationObserver, you can implement a disconnectedCallback for non-custom elements. In the callback, you can clean-up any event handlers that you have added to the element yourself.

Reply on news.ycombinator.com