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

> I see a picture emerge where the back-end will become purely an API component

Not so fast.

That makes sense for highly interactive apps with private content (Trello, Gmail, etc), not so much for public-facing and content-driven sites.

That is, unless you're OK with sacrificing that organic Google traffic to your site?

If not, you have two options: do the entire rendering + biz logic on the server (in which case Rails still makes a lot of sense, though some Node frameworks are getting there), or duplicate your client-side code on the server so that Google's hashbangs work.

The bigger picture is that the web + search engines are kind of broken right now: There's a tremendous opportunity to make progress and use the architecture pointed out by the OP, but as of today there is no simple solution to make the architecture play nicely with Google without duplicating the work on the server (Meteor seems to be making progress there).

Until a simple solution is found, I think we're stuck with the dilemma and will have to continue to do MVC both on the client and on the server.

It sucks.




I assume he's talking about web apps, not web sites.


> I have abandoned Ruby and Rails in its entirety

So I thought he was talking about both. (As I once considered doing, too).

Also very frequently the distinction is rather blurry: Is Twitter an app or a site?


When you have a content-driven site that has to be indexable while supporting user interaction, usually server-side generated HTML with client-side AJAX (preferably with graceful degradation) can be an effective pattern.

For line-of-business apps or apps in general that can benefit from a rich interface and possibly local storage, full client-side presentation layer (HTML or native) coupled to server-side pure web services can be effective.




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

Search: