Web Three Point Zero

AjaxWebApplications, a.k.a. WebTwoPointOh, deeply suck. Here's why:

Multiple implementation languages (JavaScript {or is that EcmaScript or hey is JscriptDotNet alive?} + a soft language {PythonLanguage, RubyLanguage, PerlLanguage, PhpLanguage [call that a language?] ...} + Webserver configuration + a hard language {yeah right, you don't need to AlternateHardAndSoftLayers, all that I/O means you're never CPU bound ... right? Um, I said right? Um, is this thing on?} + SqlLanguage wrapped in one of a million almost identical ObjectRelationalBridges {because, heck, you really don't know which database is going to perform best this week, or which one is legacy from last week, do you?}
Multiple data interchange languages {ExtensibleMarkupLanguage / JavaScriptObjectNotation / SimpleObjectAccessProtocol [whaddya mean SOAP? SOAP's the RemoteProcedureCall language, not the data interchange language ... well, unless you use it as the data interchange language; it all depends on where you want to encode your semantics today ...]}
Multiple representation formats {HTML, DHTML, CascadingStyleSheets, XsltLanguage, XformsTechnology [Hey, you dope, this is all open hooey, what you really want is MacromediaFlash! AFLAX! or, um, what is Adobe doing now?]
You're not cool if you're not ExtremelyInterstrangled with RssFeeds/RdfLanguage/MicroFormats/IJMTAUAIGA {I'm Just Making These Acronyms Up As I Go Along}
The WebArchitecture is broken. No, I don't mean just badly implemented, or all fscked up with commercial and open pissing matches, or just difficult to visualize. I mean it's the wrong architecture for most of the apps it hosts. Its address oriented where everything we're writing is content oriented. The only way you can host a content oriented site like, say, this here wiki, and all them there wikis, is to glom stuff together inside a single server and rely on GoogleSearches / inextensible InterWiki hacks that don't even support BackLinks and don't scale ...
Because the architecture is broken, there are lots of StrangeLoops in it. For example, Google is a proprietary application server rather than, as it obviously wants to be, a protocol!
Need I go on? TimBernersLee invented a panacea and we all know that AllPanaceasBecomePoison. Always.

In other words what we have here is a royal PatternOfBabel. Let's chuck it and start over. This page is about trying to figure out a simple WebArchitecture that does everything the ShonkyVille approach above does, but simply, with elegance, and without a trace of the backward compatibility that has caused the ExtremelyInterstrangled-ment to occur.

Start with the architecture. What we intend when we use a browser is to see current information. We're not interested in stale information. And we're not interested in navigating to get it - hence the need for Google and its kin.

Therefore,

The fundamental should be PublishAndSubscribe. A web address and a search string will be one and the same thing. We simply upgrade DNS with RDF and cut out about a dozen layers of middlemen. Well, we have to Sweeten RDF. Then dump Google in the ocean as a legacy boat anchor.

UniformResourceLocators have arbitrary semantics. This sucks because we never know how to map to them - hence the whole mess of REST/SOAP/CherryPy/what-have-you conventions not to mention various layers of obscurantism on top of that. And now, with AjaxWebApplications, much worse, more layers in front of them too, all written in bigomegahelpus JavaScript!

Therefore,

3-part Turing complete URLs. If the first part of a URL names a collection of resources - courtesy of our RDFDNS (RNS?) - then the next part can be a program that translates them into another resource. And the last part can be a set of tags on which you publish that resource.

Ah, but what is the ProgrammingLanguage? That's easy: XSLT. But, hey, XSLT is ugly as sin! Sure, but it's Turing compatible. Consequently we need merely pick another Turing-compatible language as the standard, and stick to it. And that choice is damn simple: SmalltalkLanguage. There's not a soul here who'll argue with this. All that's wanted is a bit of syntax extension to understand RDF and We're Done.

XmlSucks so much that people are falling back into JSON (JavaScriptObjectNotation) for AJAX. But JSON isn't anywhere near so powerful as XML, and that pushes way too much work down into the private programmatics inside your servlets (a.k.a. CGI blahblahblah, don't get hung up on the buzzwords).

Therefore,

What we need is to beef up JSON until it can represent all the XML semantics - but with generality and SyntacticSugar. Then write a translator and forget XML forever. What motivates people to ditch XML? Well, maintainability, readability, speed, reduced staff churn ...

Others?

I detect the telltale traces of PeterMerel above. What is that phrase? Oh yeah - LetsBlowUpTheUniverse!

I cannot tell a lie, it was me. I blew up the universe. Okay, let's start by replacing all the front end junk with AjaxSmalltalk. We then replace the XML/XSLT/XForms junk with ... SmalltalkLanguage via SeasideFramework. And then on the back end, let me see, what about oh, I dunno ... SmalltalkLanguage? There's lotsa connectivity/persistence choices there but GemStone anyone? Oh, and there's still that RDFDNS google-killer thingy ... how about we implement that in SmalltalkLanguage? Hey, and one more idea: let's have the server provide P2P access by mapping its RDFDNS to the respective client IP #s. Add the CocktailPartyMetaphor and ManaMana to that and away! --Pete going "Woo Woo!" like SteveBallmer. And then "Kapwing!" like CalvinAndHobbes.

Ya know, just a hint, but it may be time to ReFactor this page. Just a little. So maybe someone could understand it. If that's not too much trouble ...

You're forgetting that this page is a PeterMerel production. It's not supposed to make sense. Oh, hey, Pete! We were just talking about you. How's it been? :-)

In all seriousness, I believe PhilipWadler is working on some language implementation where you write in a SINGLE language, and it compiles to server-side Java, client-side Javascript, and handles all the IPC requirements between the two on its own. The problems that Pete declares above are already well know (at least to Wadler). --SamuelFalvo?

You do it all in RubyOnRails these days. Works great so long as you stick to the synchronous stuff. If you want asynchronous you just bolt a message queue onto the model. And with Rubinius a month or two from launch that's that, everything makes sense again.

Except, well, you're working with (shudder) Ruby. Java is markedly faster than Ruby, which makes it more suitable for large-scale business use. There's a reason why Google doesn't use Ruby. --SamuelFalvo?

For observational, consumption, and archiving of WebContent?, I just use OneNote: It captures a page I am interested in with a ReasonableRendering? and finishes off with the NavigationUrl? where it originated, while making its contents reachable with its own SearchEngine. That may not have been the original idea of what it is supposed to do, but that is how I use it. It is a terrific way of gathering "favorites" as well as a way of storing information of interest which is searchable and making it reachable at the same time. -- DonaldNoyes.20100822

CategoryWebThreePointZero, naturally.