Smarter Clients Via ReverseHTTP and WebSockets 235
igrigorik writes "Most web applications are built with the assumption that the client / browser is 'dumb,' which places all the scalability requirements and load on the server. We've built a number of crutches in the form of Cache headers, ETags, and accelerators, but none has fundamentally solved the problem. As a thought experiment: what if the browser also contained a Web server? A look at some of the emerging trends and solutions: HTML 5 WebSocket API and ReverseHTTP."
Re:A problem that I can see. (Score:3, Interesting)
Are you trusting the site you connect to. That is the Active X mentality. If you went to the site then it is OK.
Re:Connection, yes. Server, no. (Score:4, Interesting)
The web-application-forever-trend? (Score:2, Interesting)
May I politely ask WHY anyone would one to continue making browsers "heavier" and "thicker" all the time, instead of simply making a good old fashioned rich client (thick client if you prefer)???
I am not looking to start a "Wep-app-vs-client-app" war here. I think there is a time and place for both thick client applications and web applications. And I am a very happy G-Mail user (among other web-app-things). But sometimes I am REALLY amazed when I see the lengths some web-developers will go to, in order to achieve PRECISELY the same goals that thick clients has been able to do for literally several decades!
The platforms and standards for making web applications are continuously MOLESTED in order to give them primitives abilities which, at the end of the day, are STILL only a shadow of the power a rich client has.
Stuff like AJAX hits the scene, and people call it a "milestone" or a "revolution". Wow. Now a user can get his screen updated async without hitting a "submit" button. Big stuff there.
Next thing will be ... what? Better graphics? Actual integration between applications? Easy third-party data integration? Ah, wait, maybe it will be an continuous (and actually working) user session? No no ... wait ... I got it ... it will be model-based programming. Yes. The revolutionary new "model-view-controller" design will totally change the landscape of web applications. It will be ground-breaking stuff to any web developer! Yeah!
The finest achievement any web application can get, is being described like it is "just as good as a rich client". Hasn't anybody stopped a moment to think about WHY that is? Perhaps it would be better just to use web clients where they make sense, and rich clients where they make sense?
Why on earth do some people continue to abuse the thin (read: skinny and bone-rattling) web standards for tasks that are clearly more suited for a traditional rich client application?
This is an honest question - technical answers are more than welcome. I genuinely want to understand what is going on in the minds of all these "progressive" web developers who are seriously proposing the introduction of advanced server-processes as part of a browser...
- Jesper
Re:Connection, yes. Server, no. (Score:3, Interesting)
> But accepting incoming HTTP connections in the browser is just asking for trouble.
Exactly, transparent caching proxies would seem to solve issue in a simpler and easier to manage way. Then again, providers trying to implement caching proxies that I know of have all abandoned the idea after trying it. Their customers complained to much and it brings all sort of problems with the transactional behavior of an application.
So people do not like caching proxies, why would they like one in their browser ? Why would they like getting content from another user browser instead of from the original source ?
Also, we live in a economy where we try to boost demand. I observed this trend many years ago: The more we go into the future, the less we seem to be concerned about bandwidth. Bandwidth is getting cheaper and cheaper and providers want to sell more bandwidth ;-)
Bandwidth usage is meant to go up anyway so I do not see their concept fly. I mean if we are really concerned about bandwidth that much, let's start by design application properly and use what is already in place (cache, expiry headers, etc.) properly, which is seldom the case in the applications that I have seen.
FAT CLIENT is NOT the right FIX (Score:3, Interesting)
What's needed is a "GUI Browser" standard that is meant for C.R.U.D. screens (business screens and forms) instead of what HMTL is: An e-brochure format bent like hell to fit everything else. You can only bend the e-brochure model so far. We don't need "fat clients" really to solve most of the problem, but really just a better GUI browser so that we are not sending over 100,000 lines of version-sensitive JavaScript just to emulate (poorly) a combo-box, data grid, or folder/file outline tree widget. That's like inventing a cell-phone just to call your next-door neighbor.
Re:Sockets (Score:3, Interesting)
Does this mean we're finally getting proper sockets, instead of having to do everything through HTTP requests? I've been advocating this for years ...
Yes. And no. The HTML5 spec includes a sockets-like API. However, it's intentionally crippled so that you can't use it to communicate with an application that hasn't been specifically enabled to communicate with it (i.e. it uses its own handshake protocol to ensure it's talking to a system that's designed to talk to it).