Hacker News new | past | comments | ask | show | jobs | submit login

I think it's time to question what "necessary" means for a product/service delivered online.

If it's unnecessary to use React et al, why is it necessary to complicate your application server with UI concerns so that it can build a big html UI string that is sent over the wire? And this only works for web browsers and no other clients?

Instead, it could be a simple API server that doesn't need to know about the UI at all.

There are obviously trade-offs in either direction, but to talk about necessary vs unnecessary doesn't seem to reflect that. There is nothing more necessary about one set of them over the other.




Simple problems call for simple solutions. The vast, overwhelming majority of webpages are simple problems, solved by a server serving HTML.

A 'simple API server' sounds lovely, but it's not getting your website to anybody without a frontend - and the complexity of the frontend offsets any savings made by simplifying the backend. I'd also very respectfully push back on this 'simple API server' business - serving /fie/fo/fum.json really isn't very much simpler than serving /fie/fo/fum.html; you have identical business logic, plus you've now got messy bi-directional JSON objects and hundreds of Ajax calls over unreliable end-user connections to contend with. It's the voluntary introduction of hundreds of unnecessary failure points. For most 'simple API servers' there's an alternative, and much simpler, much safer, much saner HTML server.

For that tiny number of websites that do require accompanying apps (mobile, etc), 97% of these could be solved with a thinly wrapped web-view. Those that cannot generally have special needs, and therefore cannot be solved by simply serving the same API endpoints across web and app anyway. If you're already separating your web and app APIs, plus now you've got a tangled web frontend to contend with, I'm really not seeing the benefits of reorienting your backend around APIs to begin with. A backend serving HTML to web, and a custom API to mobile is much more elegant and flexible (and doesn't actually require a soup of Javascript anywhere).

But we're already in the 3% of the 3% here - truly unusual applications. The vast, vast, vast majority of use cases were already solved by a server serving HTML.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: