Hacker News Reader

Don’t parse the HTML, just display it. That’s what the browser does best.

What if a mobile application wants to use the API?

REST systems are designed for use with "generic" clients. The generic client for REST systems on the WWW is a browser. There is probably one available for your mobile platform.

What if a native application (mobile or desktop) wants to consume the API?

This to me is the real question. I don't see how you could easily create multiple clients if you're practicing what is preached in the article.

You're really tying your server to the browser at that point so things like CLI clients and mobile clients become painful to write (not impossible but ain't nobody got time for parsing HTML when browsers do a perfectly good job of it, not to mention CSS.).

Not the parent commenter, but I believe the idea is that if the webpage uses a framework like React or Angular, then the server doesn't need to send html, it can just send the bare minimum data necessary (in JSON) and the client turns it into html and displays it.

In other words, HTML is just the standard format that the browser uses. But if you use frameworks or define your own application specific formats, you can send less information over the wire and have it properly decoded and displayed by your client-side javascript.

Reply on news.ycombinator.com