They said it's an apples to oranges comparison unless both things do <the two facets that dapps offer>. Which is absolutely correct. You could compare apples to oranges if you wanted to... but usually there's no point in doing so.
You can't wave away the serious issues by saying "there's no point in comparing them"
Lots of things offer different functionality and tradeoffs. If you want to play in the space of "web app", you can and should be compared to things that are solutions for producing "web apps". We compare codeless web apps to code ones, etc.
The same way people compare gas and electric vehicles. Or minivans and suvs and trucks. Or, well, everything in a solution space.
Any solution for a given use case can and should get compared with other solutions for that use case.
I'm really sorry that it doesn't seem (judging by this thread) to compare particularly well for most developers, but that doesn't invalidate the comparison.
And the current use cases are sufficiently different that it's like comparing apples and oranges.
> I'm really sorry that it doesn't seem (judging by this thread) to compare particularly well for most developers, but that doesn't invalidate the comparison.
Again, do you think the same of Tor? It doesn't compare particularly well by most mainstream metrics. High latency, low bandwidth. And yet it serves a lot of value to a lot of people.
But then some smartass goes and says "It's completely useless tech, I can host a simple static website on clearnet for much less hassle." Yeah, duh, but that's not the point of Tor. Go use the clearnet if that's what you're looking to do.
Uh, what? This whole thread and post is about the argument that replacing existing apps with dapps will be better (or worse).
They specifically said that it has advantages over current apps, and compared what happens with your current apps when you don't pay your AWS bill.
They then later, after lots of comments pointing out that nobody cares, said "well you can't really compare it to any of those things".
You seem more sane in the sense of what you think this stuff will do.
Immutability and resistance to shutdown are not features that the vast majority of apps, present and in the future, will ever need. My main dispute with the original article is that the author argues every single use case of a Web3 app can be done with a traditional app, and I argue that's simply not true. The case where that breaks down is precisely when your app requires immutability and resistance to shutdown.
To use an analogy: Most people will never need to own or use an armored car, and if you evaluated an armored car based on its viability as a consumer vehicle, you would say that its fuel requirements and maintenance costs are impractical, because you don't need the assurance of having a bulletproof vehicle in your everyday life. It would be overkill.
Similarly, these Web3 technologies are not being designed to replace YouTube or Facebook. If you're building a service like that, you don't need the armored car. On the other hand, if you're designing an app that performs financial transactions, then the armored car may be something you can use. Or not! But the option is there.
99% of developers will never need to build an app this way. But there are use cases outside of ponzi schemes and fraud that seem to be overlooked and which I think are worth drawing attention to.