Well they're definitely very different technologies too, and the things that you mention, in that specific context, are what the web was actually designed to do well. Basically, the web is purpose built for digital publishing. This is really good for content, as it allows the publishers to update the content and leave the client relatively the same.
Your example of an <img> is a perfect one. Yes, if all the images are going to be loaded remotely, I would say this is a client/server messaging paradigm, and one that excels in digital publishing.
However, if you're going to build an app (which is what we're talking about), then you are probably going to want to store the app's images in one giant executable... which means all the caching and everything you want is going to be extremely fast, probably much faster than what the browser will do for the same task.
If you really want to understand what I mean, just ask yourself "what is the life-cycle of a web app", e.g. what is the "main" method? Are there clearly defined transitions between views? What is the execution/memory model?
When you answer those questions you realize that the browser was built to display pages of text and images, loaded by a server. From there it should be clear why people don't think there's any comparison when it comes to building apps, because one was designed for it and the other inherited that responsibility.
I'm not saying web development as a paradigm isn't popular, but I'm arguing against it being easier than native because it's not really. However, if you wanted to add like a digital publishing component to an app, I'd just embed it into a web view, which is the best technical choice.
Your example of an <img> is a perfect one. Yes, if all the images are going to be loaded remotely, I would say this is a client/server messaging paradigm, and one that excels in digital publishing.
However, if you're going to build an app (which is what we're talking about), then you are probably going to want to store the app's images in one giant executable... which means all the caching and everything you want is going to be extremely fast, probably much faster than what the browser will do for the same task.
If you really want to understand what I mean, just ask yourself "what is the life-cycle of a web app", e.g. what is the "main" method? Are there clearly defined transitions between views? What is the execution/memory model?
When you answer those questions you realize that the browser was built to display pages of text and images, loaded by a server. From there it should be clear why people don't think there's any comparison when it comes to building apps, because one was designed for it and the other inherited that responsibility.
I'm not saying web development as a paradigm isn't popular, but I'm arguing against it being easier than native because it's not really. However, if you wanted to add like a digital publishing component to an app, I'd just embed it into a web view, which is the best technical choice.