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.
Re:Not to be a pain...
GAVollink on 2005-03-08T18:21:53
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?
Re:Not to be a pain...
ziggy on 2005-03-08T18:44:48
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, where you have a super-lightweight client side interface using ajax (JavaScript + XMLHttpRequest). That goes far beyond the original Java vision, and redefines apps as something much more lightweight. The similarity is that it's all in pursuit of the same holy grail; the Java model (and mindset) really isn't what we're looking for here.
The only problem with ajax is the context switching costs for developers. There's a server world, and there's a client world, and they share a common protocol but otherwise have pretty much nothing to do with each other. What would it be like if you had the same kind of ajax style app, but didn't need to switch between JavaScript + HTML + DOM and your-back-end-of-choice all the time?
Re:Not to be a pain...
GAVollink on 2005-03-08T19:29:40
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 direction of "trusted computing" (too limiting, and I am opposed to it - not that I matter).
C# brings some of what you are looking for to the table, in fact the whole
.NET suite. However, this merely obfuscates some of the back-end from the programmer (which is probably not what you want - certainly not what I want), and again re-iterates the Java/sandbox mentality ( need to run and install .NET generic services on each client ). Then again, if I could get my head around exactly what you mean, then that would be the answer wouldn't it? I.e., I know I don't have the answers - but I'm trying to figure out what you don't mean, see?
Again - didn't mean to be a pain. And yes, I kind of jump around a bit mentally - sorry.
Re:Not to be a pain...
ziggy on 2005-03-09T04:16:08
Well, yes. And no.Just as content and layout are different (or should be)... client and server are different.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 back to the server (through links, forms, etc.) So nothing about "Web 3.0" precludes trusted computing, or even subverts it.
What we're starting to see emerge is the same old-style web app -- code running on the server spewing back text to a client. Except that some of that text is a JavaScript program that munges the document returned, without requiring a full page reload. (This is the AJAX model that Gmail and other sites use.)
So there is no conceptual difference between 1993-style CGI scripts and Gmail, except that Gmail uses JavaScript to fetch partial pages without requiring the entire page to be reloaded. As an added benefit, you get some extras, like vi-style keybindings, more responsive apps, and less time spent waiting for the browser to construct an entire page from scratch for every click.
In that light, most of what's going on at the client side is the same kind of XML slinging and HTTP fetching that's done on the server side, with a few extra things added in for good measure (like keybindings). So why shouldn't you be able to use one programming language to do similar tasks on both sides of the pipe?
There will still be differences -- clients won't worry about tweaking the database directly, and servers won't spend nearly so much time tweaking CSS attributes. But in the end, there's no real reason why you need two totally different languages to do these tasks. Different libraries and frameworks, sure, but not completely different languages. It's not like mixing Prolog and Assembly.
;-) Java and lack of speed
bart on 2005-03-08T19:51:07
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.Java infrastructure is in place - and fairly ubiquitous [ though not totally ] but gravely underutilized due to lack of speed).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 much lower.
And YetiSports and TeaGames prove that Flash can do really nifty stuff.
Re:Java and lack of speed
ziggy on 2005-03-08T20:10:48
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.
Re:Java and lack of speed
GAVollink on 2005-03-08T20:41:58
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...
Re:To be a pain
ziggy on 2005-03-09T04:22:46
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 client are almost always written in JavaScript. (I'm focusing on AJAX, ignoring Flash and applets for simplicity.)
So, if you're doing XML munging on both sides -- one to munge data, and one to munge a user interface -- why do you need two totally different languages?
(Yes, using JavaScript everywhere is a valid answer. It's just not a very satisfying one.
;-) Re:To be a pain
Dom2 on 2005-03-09T10:05:36
JavaScript is probably a whole lot better for XML munging than most other choices, assuming that E4X actually gets deployed in any sensible fashion. As usual, it's a lot easier to deploy to a server.-Dom
