Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> They have a URI, but only for the whole thing, not for all of those valuable things that are inside of it.

This isn't always true, and I wouldn't actually find it to be false more most SPAs I use. Its straightfoward to sync the URL with Javascript state. Most high grade SPAs takes URIs seriously, because they are still the primary way users share views with each other. Traditional URIs point to static resources, but most SPAs contain at least a record identifier, and possibly even a view state. Google Slides is a SPA, but I can easily share a URL with another person, and if they have access they will end up on the same slide as the one I was viewing when I copied the link.

> Business logic does not belong in the client, unless you like having to redundantly maintain the same logic in every kind of client you support (in addition to maintaining it on the server, of course — remember that you can never trust any client).

I don't see how moving view state management from the client to server solves this issue. Of course you can't trust the client, anyone can spoof API calls. But even basic forms have this issue. You can't trust a form just because you generated options on the server.

Also view logic is tightly coupled with the client UX. Moving it to the server does not magically make it reusable. Additionally, having client side logic often is more about displaying a list of possible options, than validating correct choices. Just writing server side validation does not eliminate the need for client side business logic.



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

Search: