I don't think that server side frameworks will become irrelevant. There is still a lot of value they add between the database and the HTTP interface. The part that will become irrelevant is the servlet/ASP/JSP/ERB and similar view-layers, where page-rendering policy is executed on the server. With more & more clients getting ever more powerful processors (including iPhone, Blackberry, Palm and Android), the client can do the job of executing the page-rendering policy.
This will mean that many applications will be able to stuff their JS (which will have to codify page-rendering policy), CSS, and static files on S3, and use the server just for authentication, authorization, activation, and data. My coding experience with Rails, ASP.Net, and PHP tells me that the most frustrating and error-prone part of using web frameworks is the templating language where you have client-side code and server-side code mixed in in the same source code file in three or four different languages (e.g. Ruby, JS, ERB, CSS).
Authentication is the big issue here, but don't all of the cool kids use OAuth, FB Connect, JanRain Engage or something like that these days? If so, then once you authenticate yourself to your applications via your identity provider, only a session token between a client and server is needed to authenticate per request. (Or you could use an additional challenge-response token to one-up the man-in-the-middle attackers).
The SEO side of this has some interesting possibilities. Of course, this technology will hurt the search engines, because your content will be much harder for them to index. Most folks will find it hard (at least initially) to use Google's prescribed tricks to make your AJAX page bot-friendly. On the other hand, it also means that your application gains some information asymmetry (because your content cannot be easily found and compared with similar content on the web), and you could use that to your financial advantage. The key here is to give the search engine enough static content as index-bait to get your site's name "out there" and on page 1 of the search engine rankings, but not so much that all of your valuable content is indexed and commoditized to the advantage of Google/Yahoo/Bing.
I think that VC in its current form will be a casualty of the recession. In its current form, the VC grabs a chunk of cash as a management fee, and another chunk of cash to put "adult supervision" of seasoned executives on the management team. Also, VCs are not able to manage the kinds of small investments that startups need because VC partners have limited time. Because their of their high overheads in the form of management fees, "adult supervision" the small investments simply will no longer pay them what they need to profit. Therefore, from that perspective, I think that VCs are going to be forced out of the web startup sector.
In addition, they will also get booted out of sectors that use successful web startups to bootstrap other kinds of businesses. Let's face it...just as you can use a consulting business to bootstrap a company, you can also use a successful web startup to do the same.
I think that a new trend that will emerge is that large enterprises will start buying up web startups to take over the product for use in their internal operations. Think of it...suppose you are a large enterprise who wants to build some fancy web based software to improve some business process. You have a choice between funding an internal group that may take 12 months using "Cadillac" components and cost $600k , or you could just troll the 'net and look for a startup that does something similar and buy them up for $300k, which gives them rights to working software and the talents of the developers (using appropriate golden handcuffs). It also gives YC a the proverbial 10x return on its proverbial $15k investment and each of the proverbial 3 founders a $50k equity bonus. This will diminish the influence of VCs because web startups that have taken in even a million in VC funding will not be able to sell out for less than $10 million...a price too high for enterprises to spend on business process improvement.
This will mean that many applications will be able to stuff their JS (which will have to codify page-rendering policy), CSS, and static files on S3, and use the server just for authentication, authorization, activation, and data. My coding experience with Rails, ASP.Net, and PHP tells me that the most frustrating and error-prone part of using web frameworks is the templating language where you have client-side code and server-side code mixed in in the same source code file in three or four different languages (e.g. Ruby, JS, ERB, CSS).
Authentication is the big issue here, but don't all of the cool kids use OAuth, FB Connect, JanRain Engage or something like that these days? If so, then once you authenticate yourself to your applications via your identity provider, only a session token between a client and server is needed to authenticate per request. (Or you could use an additional challenge-response token to one-up the man-in-the-middle attackers).
The SEO side of this has some interesting possibilities. Of course, this technology will hurt the search engines, because your content will be much harder for them to index. Most folks will find it hard (at least initially) to use Google's prescribed tricks to make your AJAX page bot-friendly. On the other hand, it also means that your application gains some information asymmetry (because your content cannot be easily found and compared with similar content on the web), and you could use that to your financial advantage. The key here is to give the search engine enough static content as index-bait to get your site's name "out there" and on page 1 of the search engine rankings, but not so much that all of your valuable content is indexed and commoditized to the advantage of Google/Yahoo/Bing.