4 ms·

Who really needs this for their web app? Nearly 99% of heavy web apps require a login, so Google is out of the picture anyway. Anyone who is building a conten

by jarcoal 14y ago

Who really needs this for their web app? Nearly 99% of heavy web apps require a login, so Google is out of the picture anyway. Anyone who is building a content site with DOM-manipulating Javascript doing all the work have completely lost their way. Seriously, just render your templates on the server and deliver them to the client. Why does the world want app-ify everything?

mattacular 14y ago
Because server architecture and rendering is really expensive to scale whereas a client-side-dependent app could be supported for much less. It is a trade-off. The presentation layer has been moving to the client-side for the past few years, where have you been?
- jarcoal 14y ago
  Rendering templates on the server is not expensive at all, that is completely untrue. I've been keeping up like any developer, in fact I'm writing a Backbone app as we speak. But like all of the apps I write, Google doesn't need to crawl it.
  - mattacular 14y ago
    >Rendering templates on the server is not expensive at all, that is completely untrue. Vaguest statement ever. It depends on the complexity of the template and the templating system, also then that file has to be served either directly or through a cache. complexity++ It is harder to scale a server-side presentation layer. If you don't think that is the case please expand on your statement... edit; please don't cite Twitter as a case, they are not the norm.
arohner 14y ago
Fat client apps are fantastic for making some kinds of UI interactions trivial. The simplest example is the checkout form, or any kind of wizard linking multiple pages together. In a fat client app, all state for all N pages of your checkout cart are in the same page, with 5 lines of code to switch between them. Doing that in standard MVC "fat server" model is annoying, and about 10x more code. > Why does the world want app-ify everything? Think about GUI applications pre-web. They weren't written as servers that generate PDFs, with an embedded scripting language. The current webapp technology stack is a complete accident, and if we had actually sat down to design the "optimal" stack, it would look nothing like what we have.
- jarcoal 14y ago
  I completely agree with you that in some (many) cases it's useful. But your checkout example proves my point; you wouldn't want a bot crawling through there. Bots should be crawling content-rich pages (blogs, articles, marketing pages), and IMO those should rarely be handled by fat clients.
bjourne 14y ago
I have a site with lots of statistics, tables, charts and similar stuff. As you can understand, fetching all that data from the database to render the analytical charts is fairly expensive. My solution is to first render the page template and send it back to the client as quickly as possible with all statistics widgets empty. Then the page makes a few ajax calls to fetch the data from the server to render the pie and bar charts widgets. It works very well for a human visitor. The page loads extremely quickly and the widgets rendered using javascript and ajax are below the fold anyway so it doesn't matter that they are visible 500 ms later than the initial page load. Unfortunately it is crap for Googlebot which never runs the ajax calls and never "sees" my pretty graphs which leads it to think I have a much more boring site than what it really is. So that is my need to "app-ify" my site and my, as of yet unfulfilled, need for a framework that is able to provide Googlebot with an accurate view of my appified site.

by jarcoal 14y ago

mattacular 14y ago

Because server architecture and rendering is really expensive to scale whereas a client-side-dependent app could be supported for much less. It is a trade-off. The presentation layer has been moving to the client-side for the past few years, where have you been?

jarcoal 14y ago
Rendering templates on the server is not expensive at all, that is completely untrue. I've been keeping up like any developer, in fact I'm writing a Backbone app as we speak. But like all of the apps I write, Google doesn't need to crawl it.
- mattacular 14y ago
  >Rendering templates on the server is not expensive at all, that is completely untrue. Vaguest statement ever. It depends on the complexity of the template and the templating system, also then that file has to be served either directly or through a cache. complexity++ It is harder to scale a server-side presentation layer. If you don't think that is the case please expand on your statement... edit; please don't cite Twitter as a case, they are not the norm.

arohner 14y ago

Fat client apps are fantastic for making some kinds of UI interactions trivial. The simplest example is the checkout form, or any kind of wizard linking multiple pages together. In a fat client app, all state for all N pages of your checkout cart are in the same page, with 5 lines of code to switch between them. Doing that in standard MVC "fat server" model is annoying, and about 10x more code. > Why does the world want app-ify everything? Think about GUI applications pre-web. They weren't written as servers that generate PDFs, with an embedded scripting language. The current webapp technology stack is a complete accident, and if we had actually sat down to design the "optimal" stack, it would look nothing like what we have.

jarcoal 14y ago
I completely agree with you that in some (many) cases it's useful. But your checkout example proves my point; you wouldn't want a bot crawling through there. Bots should be crawling content-rich pages (blogs, articles, marketing pages), and IMO those should rarely be handled by fat clients.

bjourne 14y ago

I have a site with lots of statistics, tables, charts and similar stuff. As you can understand, fetching all that data from the database to render the analytical charts is fairly expensive. My solution is to first render the page template and send it back to the client as quickly as possible with all statistics widgets empty. Then the page makes a few ajax calls to fetch the data from the server to render the pie and bar charts widgets. It works very well for a human visitor. The page loads extremely quickly and the widgets rendered using javascript and ajax are below the fold anyway so it doesn't matter that they are visible 500 ms later than the initial page load. Unfortunately it is crap for Googlebot which never runs the ajax calls and never "sees" my pretty graphs which leads it to think I have a much more boring site than what it really is. So that is my need to "app-ify" my site and my, as of yet unfulfilled, need for a framework that is able to provide Googlebot with an accurate view of my appified site.