3 ms·

Great points. The attack surface is something I didn't consider, and presents a tough challenge. If the framework were to implement the transport layer in a pr

Great points. The attack surface is something I didn't consider, and presents a tough challenge. If the framework were to implement the transport layer in a predictable way, I think it still might be a net win. It could build in all sorts of automatic good protection against XSS and CSRF and have even better control than today's frameworks since it can validate on both sides and know what to expect. The ever changing attack surface is a problem without a doubt, but the usual vectors can be better protected against, and the visibility and control issues can be mitigated with inline directives. With regards to SEO, I disagree. There are two issues at heart here. Firstly, some web applications are single user apps with no publicly indexable data (ex Mockingbird, Basecamp), and optimize landing pages to direct users to use the application and explain why it is worthwhile. That's the data they want in Google, not the data from within the application. For these types of apps the issue SEO isn't that big. The issue is big with apps like Hunch, where as you say there are many states and non page-like semantics. Take a moment to examine the data that these kinds of apps want indexed and searchable. It's usually central to the app, the meat of the whole thing, and in the case of Hunch, available as a discrete page because it makes sense. This leads me to believe that you can without too much difficult come up with a URL scheme for representing it that either does or doesn't have an anchor in it. Thats the central idea, is that the routing table is the same on both sides of the wire. The first page they visit can be rendered server side and all ensuing pages can be rendered client side using fragments after the "#", and the Googlebot can index the pages as they are all renderable server side. This also ties into your third point, that the routing paradigm used by Google and everyone now is the only way to go. I really don't know how to solve the multiple state vs url segments problem while remaining indexable, but I believe it can be done. Do you disagree that the paradigm is no longer as useful?

Joeri 16y ago
The attack surface mostly has to do with input validation. Good security presupposes that you validate all input and escape all output. That means that you have to be aware of the semantics of all server I/O, which is difficult to automate effectively. Regarding SEO, the point is irrelevant to most SPA's. If your data is private, whether google can index it is not a relevant topic. I suspect the validation probably should be developed twice. We build our server-side framework to be client-agnostic, published as web services. It is reused across multiple clients: a full desktop web front-end, a mobile web front-end, and a set of third-party interfaces. The use cases and needs of every front-end are very different, so I have a difficult time imagining a way that the validation logic could automatically be integrated into the different front-ends.
boucher 16y ago
New Twitter is really the example to look at here (and they aren't the first). New Twitter doesn't have unique pages anymore for tweets, and everything is happening in a single page. But each of those tweets also has a real HTML version generated separately for SEO. That is a perfectly valid way to do it, especially when you think of New Twitter as a content creation app, and each individual tweet as its own random piece of content. Granted, the simplicity of Twitter's content makes that choice easier than it might be for a lot of people, and I agree that hopefully we'll converge on tools and frameworks that will make this more automatic. But in a world where your app is largely running on the client, and data exchange is done largely via some kind of simple REST AJAX API, writing an additional (likely quite simple) HTML template for the same data doesn't seem like an impossible challenge for most web apps.
- joe_the_user 16y ago
  I'm not sure New Twitter is good model in its implementation however. I don't think I'm the only one who's noticed that the new interface is a client-side pig, taking all the CPU time it can grab.

Joeri 16y ago

The attack surface mostly has to do with input validation. Good security presupposes that you validate all input and escape all output. That means that you have to be aware of the semantics of all server I/O, which is difficult to automate effectively. Regarding SEO, the point is irrelevant to most SPA's. If your data is private, whether google can index it is not a relevant topic. I suspect the validation probably should be developed twice. We build our server-side framework to be client-agnostic, published as web services. It is reused across multiple clients: a full desktop web front-end, a mobile web front-end, and a set of third-party interfaces. The use cases and needs of every front-end are very different, so I have a difficult time imagining a way that the validation logic could automatically be integrated into the different front-ends.

boucher 16y ago

New Twitter is really the example to look at here (and they aren't the first). New Twitter doesn't have unique pages anymore for tweets, and everything is happening in a single page. But each of those tweets also has a real HTML version generated separately for SEO. That is a perfectly valid way to do it, especially when you think of New Twitter as a content creation app, and each individual tweet as its own random piece of content. Granted, the simplicity of Twitter's content makes that choice easier than it might be for a lot of people, and I agree that hopefully we'll converge on tools and frameworks that will make this more automatic. But in a world where your app is largely running on the client, and data exchange is done largely via some kind of simple REST AJAX API, writing an additional (likely quite simple) HTML template for the same data doesn't seem like an impossible challenge for most web apps.

joe_the_user 16y ago
I'm not sure New Twitter is good model in its implementation however. I don't think I'm the only one who's noticed that the new interface is a client-side pig, taking all the CPU time it can grab.