Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

ziggy (25)

ziggy
  (email not shown publicly)
AOL IM: ziggyatpanix (Add Buddy, Send Message)

Journal of ziggy (25)

Tuesday March 08, 2005
11:56 AM

Web 3.0? Web 2.5?

[ #23551 ]
David Ascher asks an intriguing question:

Here’s a fun thought experiment: what kind of programming language would you want in a Web 3.0 universe, assuming (please!) that you’re not stuck with JavaScript on the client, and that (please?) you could write one program, not one per web page on the client and one (or more) on the server? Wouldn’t it be nice?

That's a really interesting idea. Let's ignore the five or ten years it'll take to upgrade the infrastructure for the moment. Let's focus instead on what it would be like to program for the web in this scenario. What kinds of interesting apps could we deliver? And how do we get there from here? (And will it actually take five to ten years?)

Here's another idea to ponder: what does the path to Web 3.0 look like? I'm not sure, but I think iTunes is on that path -- one app that's got the web wired in (CDDB, iTunes Music Store, single sign-on (with AppleIDs), and commerce). Maybe to get to Web 3.0, we need to take half a step back, to Web 2.5 -- the custom client that can deliver an entire rich app in a single framework with (theoretically) a single programming language for both the front end and back end.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • You are almost describing what Sun wanted Java to be back in 1996 - and it almost made it (oddly, the Java infrastructure is in place - and fairly ubiquitous [ though not totally ] but gravely underutilized due to lack of speed).
    • In fact the closest we have to a utilized ubiquitous environment is (I hate to say this) Flash. Flash is available on all major platforms - and with it's extreme ease of installation across the board (especially on Firefox/Linux) - it's become the rich-media technology of choice for web.

      But - that's where we are - not where we need to be. I haven't read enough about it - but is this what folks want Parrot to become?

      • Hm. Can you do a big honkin' server-side app in Flash?

        What David describes is one environment where you sit and write code on the server, and have some of it executing server side, and some of it executing client side.

        It sounds vaguely like what Java promised in 1995, but the mindset back then was to write monolithic apps that didn't need installers (or upgrades, or patches), and used old-style clunky GUI toolkits. What David and I are talking about are things like Gmail, Flicker and Google Maps, wher

        • See, pain... Thus my subject line.

          Just as content and layout are different (or should be)... client and server are different.

          The rich-layout that enables an application to look fancy, _and_ quick - that's what I was driving at - but no, Flash itself doesn't have a server-side component.

          One of the primary reasons for the difference between client and server side computing (thus the context switching) is security. And to bypass security gets into the "sandbox" mentality (restrictive) or the opposite direc

          • Just as content and layout are different (or should be)... client and server are different.

            Well, yes. And no.

            As you sketch it out, security and sandboxes are something of a red herring. Sure, you don't want to ship ActiveX controls about (or whatever Microsoft is shipping this week). But web apps as we know them today are just server-side apps that ship text from web servers. Except that the text is HTML (or XHTML, or XML + CSS, or ....) that melds instructions to display content and communicate

    • Java infrastructure is in place - and fairly ubiquitous [ though not totally ] but gravely underutilized due to lack of speed).

      I disagree. Java isn't slow. But Java is slow to start up in a browser. For most pages, it's just unacceptable. Even a small applet takes 1/2-2 minutes to launch, if Java wasn't already running.

      Flash, OTOH, is a quick starter, typically taking only the time to actually load the "applet" even on broadband. Hence, the threshold to use something using Flash on a web page is

      • I saw a first person shooter in Flash (or the moral equivalent) pop up on del.icio.us recently. It's certainly a really cool way to push at the edges, but somehow I doubt that's going to lead to the next Gmail, Google Suggest or Google Maps. ;-)

        Things like 10x10 are going to be taking the web in a different direction. Interesting in its own right, but not the kind of application development I'm trying to describe above.

      • Like my momma always says, "Slow is as slow does".
  • Why, exactly, would one want to use just the one language... I'm quite certain that the best mini language for user-interface generation isn't the same as the best language for user-scripting, and isn't the best language for back-office transaction processing.

    Now, the best glue between each of them...

    • That's a good point. Web interfaces aren't moving away from HTML/XML/CSS/etc. any time soon. You could call that a language if you wanted -- especially compared to some of the alternatives (e.g. writing UIs in Java against SWT.)

      But when you look at the structure of the AJAX model, you've got some XML munging at the server, and some XML (for all practical purposes) munging on the client. The server is typically written in Perl, Python, PHP, Ruby, Java, C#, or Befunge, and the interactive bits on the cli

      • JavaScript is probably a whole lot better for XML munging than most other choices, assuming that E4X [ecma-international.org] actually gets deployed in any sensible fashion. As usual, it's a lot easier to deploy to a server.

        -Dom