[sha90]

This is extremely hyperbolic, and I'm sure you know this. Here's how you set a variable in React:

const foo = 1;

What you're doing in your complicated sample is not _just_ setting a variable, you're also exposing it to a KVO subscription system that you could never represent succinctly in ASM.

What's sad is how programmers communicate programming concepts right now, with quick digs and hot takes and zero actual critical thought to what is being compared. I'm disappointed that you're spreading FUD in your internal talks.

[JoeAltmaier]

Yes, still its a way to set a value. And don't be so sure you can't make an entry in a KVO subscription system in asm - of course at bottom that's exactly what's happening.

I'm disappointed at the zero-attempt-to-understand-the-point digs made on hacker news (like the one I'm responding to). The point is, how is multi-layered abstraction an unalloyed good? Its heavy, slow, complicated to author and explain, and not doing all that much of value.

[bcheung]

Yes, it's an apple to oranges comparison, but the point is more why are we using an orange when an apple will suffice?

The real question is, is all that really needed?

We keep building abstraction layers on top of abstraction layers when often times, there is already tried and proven solution that works and is much simpler.

I've been doing some experimenting creating a single page application (SPA) without a web framework and turns out you can get 90% of what React offers with a tiny amount of code.

https://github.com/brennancheung/volgenic/blob/master/13-IDE...

My current iteration is just to do a:

    State.update(() => { state.foo = 123; state.other = 456;  })

I just use plain javascript objects to store data and wrap it in a function that will trigger re-rendering the VDOM / repaint.

And even if we do need that additional layer of abstraction we can always make it appear simpler and provide a cleaner interface to the programmer. A Proxy object setter could be used to eliminate the boilerplate of State.update.

Good abstractions simplify the problem by creating a mental paradigm that is closer to the problem domain. Poor abstractions do the opposite, they take away what is needed to solve the problem and create additional steps that are not really germane to the problem.

Many abstractions are well intentioned, but after we toss layer on top of layer, we often get so far removed from the problem domain, we have to ask ourselves if it is not simpler to just build up another set of abstractions that allow us to get closer to the problem domain (i.e., "First Principles").