WebThreePointZero

Last edit August 22, 2010
AjaxWebApplications, a.k.a. WebTwoPointOh, deeply suck. Here's why:

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.