[nsonha]

you may think they're equal but to me one of the two is fundamentally flawed. I speak from the experience of developing for Android and web, but I suspect in all UI platforms, it's best practice to have the source of truth out of the views and treat states in the native views (checked) as derivative throwaways

[Zababa]

I don't think they are equal. On the web, the "react approach" is seems to be really good if not the best for medium-complexity apps. Under that, it creates more complexity than it solves and over that it can affect the performance too much. The thing is, we work in a industry that has to deal a lot with change. Using the "react approach" from the beginning when your website is not that complex can be a way to future-proof it. But you're going to pay a cost of increased complexity at the beginning. I think that's the opposite of technical debt in a way. Technical investment maybe?

[nsonha]

There is no cost, these are just 2 diferent styles of code, there is no reason for one way to be more expensive than the other. If you find react cumbersome then find a better way, a library, or vanila. Just because you dont do react doesnt mean you should write vanilla js in a spagetti manner. The "react approach" is only awkward if you fixated on the mindset that there is something special about "the platform", that you should write code in such a way that spread the platform dependencies all over the place.

In all of my programming exp, back-end or front-end, "the platform" is what people try to restrict access to and abstract away so that they can think about the problems they're solving. Only on the web, after decades of putting up with a then crappy platform, now better, that developers now have a Stockholm syndrome for it.

[Zababa]

There is a cost though, the browser already knows HTML so using it for state has no cost, while adding something in pure JS does. For example, look at payload sizes.

> In all of my programming exp, back-end or front-end, "the platform" is what people try to restrict access to and abstract away so that they can think about the problems they're solving.

You're assuming that writing code for your abstraction will be faster than server-side rendered HTML with a sprinkle of JS. Sometimes it is, sometimes it's not.

[nsonha]

> You're assuming that writing code for your abstraction will be faster

Strawman, I didn't even say "fast" at any point, there are many other reasons platform should be abstracted away: better visibility of platform dependencies, easier security audit, portablity, ease of refactoring/deprecation of platform APIs

[Zababa]

If writing code for your abstraction isn't faster and the resulting code isn't faster, then surely not using it is useful sometimes? "better visibility of platform dependencies, easier security audit, portablity, ease of refactoring/deprecation of platform APIs" don't really matter that much for web browsers if you're not using the latest new shiny things, the backbone of the web is really stable.

[nsonha]

I guess to me the reason is that I want to deconstruct problems properly and focusing on thinking inside the domain of the problem. It helps me think by pushing all the platform junk out to the edge.