Somewhat off-topic rant: This isn't so much a dig at Rails but a
critique of HTML in general. I've done web development with PHP,
ColdFusion, and ASP, and being able to use Ruby in doing so (especially
with Rails' well-designed database interactivity) is certainly a
welcome change. However, the general model is still the same, in terms
of using code to write out HTML to an essentially-static page. The HTML
interface is still such a far cry from the things you can do with a
rich client. For ordering airline tickets on Travelocity or books on
Amazon, the web works great, but imagine trying to emulate Adobe
Photoshop via a web browser, or a spreadsheet like Excel.
It seems to me that there needs to be a next-generation of HTML that
enables web apps to truly be like rich client apps, and
I don't think the solution needs to be a faster connection that sucks
down the entire application in the form of massive Java applets every
time I want to use the program. Perhaps the solution does need to be a
"computer" that's designed from the ground up as a web-enabled dumb
terminal, but that has forms and controls optimized so that they
require minimal data inflow to tell them what to do.
To me, this would make the web incredibly more useful (and would put
serious potential into the claim that Google wants to become a web
operating system). If I've purchased Adobe Photoshop (or rented it, as
I'm sure will be the more likely model), instead of loading it on every
computer I use, why can't I get to Photoshop at any computer in the
world merely by logging into my personal website and getting access to
every software program I own or am renting? Why would it need to be
reloaded at every computer? This is particularly annoying when you're
visiting a friend in another city for a weekend, and jump onto his
computer to check email or show him how to do something useful, and
think, "I wish I had App X loaded on here right now."
I was disappointed to see Google Suggest being touted as innovative; it
seems to indicate that Google's going to stay within the existing web
realm and not try anything really new (as I read on the web somewhere,
"for a web app, Google Suggest is neat; for a desktop app, it's so
1995"). For all of Google's deep pockets and reputation as innovative,
I expected to see them partner up with a hardware manufacturer and try
something dramatically different.
That's what Macromedia is trying to sell you!
Flash MX with Flash Communication Server.
It isn't quite fast enough to write photoshop in it, but that's what
people are trying to do.
On the other end, if we could get programmable SGV (imo we need a
"canvas" of some sort to get close to excel apps) there might be
something there, or you could try XBL/XUL of some sort. (I'd love to
be able to do client side Ruby XBL interfaces...)
Douglas
···
On 4/13/05, James Toomey <jamesvtoomey@yahoo.com> wrote:
Somewhat off-topic rant: This isn't so much a dig at Rails but a
critique of HTML in general.
There's an inherent trade-off: Compared to desktop apps, web apps are pretty crappy interaction-wise, but you can use web apps in a lot more places. There are lots of efforts to bring more rich interactivity to web apps: Java, Flash, AJAX, XForms, even Mozilla's XUL might count depending on how you look at it. There's no clear standard for how to do these things, so there's a lot of messiness and it might take some time for everything to get sorted out.
Personally I'm also a little concerned about how highly dynamic sites push back against other web efforts. AJAX-y sites are hard to make accessible to the blind, and from what I've seen they tend to break REST, as well. REST used to be a largely academic concern, but it's only now that we're starting to pass around URIs as permanent tokens (technorati, del.icio.us, etc.) and that's a big part of REST. If I never see another session variable in a URI it'll be too soon ...
Anyway, getting Photoshop in an online app is going to take some doing. When you're running a gaussian blur on a 2 MB image, you want to be as close to the metal as possible. You wouldn't want to do that in Javascript.
p.s. Rich Kilmer's Flash app Alph was supposed to help with this whole issue, Rich are you still working on it?
···
On Apr 13, 2005, at 3:24 PM, James Toomey wrote:
Somewhat off-topic rant: This isn't so much a dig at Rails but a
critique of HTML in general. I've done web development with PHP,
ColdFusion, and ASP, and being able to use Ruby in doing so (especially
with Rails' well-designed database interactivity) is certainly a
welcome change. However, the general model is still the same, in terms
of using code to write out HTML to an essentially-static page. The HTML
interface is still such a far cry from the things you can do with a
rich client. For ordering airline tickets on Travelocity or books on
Amazon, the web works great, but imagine trying to emulate Adobe
Photoshop via a web browser, or a spreadsheet like Excel.
It seems to me that there needs to be a next-generation of HTML that
enables web apps to truly be like rich client apps, and
I don't think the solution needs to be a faster connection that sucks
down the entire application in the form of massive Java applets every
time I want to use the program. Perhaps the solution does need to be a
"computer" that's designed from the ground up as a web-enabled dumb
terminal, but that has forms and controls optimized so that they
require minimal data inflow to tell them what to do.
To me, this would make the web incredibly more useful (and would put
serious potential into the claim that Google wants to become a web
operating system). If I've purchased Adobe Photoshop (or rented it, as
I'm sure will be the more likely model), instead of loading it on every
computer I use, why can't I get to Photoshop at any computer in the
world merely by logging into my personal website and getting access to
every software program I own or am renting? Why would it need to be
reloaded at every computer? This is particularly annoying when you're
visiting a friend in another city for a weekend, and jump onto his
computer to check email or show him how to do something useful, and
think, "I wish I had App X loaded on here right now."
I was disappointed to see Google Suggest being touted as innovative; it
seems to indicate that Google's going to stay within the existing web
realm and not try anything really new (as I read on the web somewhere,
"for a web app, Google Suggest is neat; for a desktop app, it's so
1995"). For all of Google's deep pockets and reputation as innovative,
I expected to see them partner up with a hardware manufacturer and try
something dramatically different.
Francis Hwang
Yeah we all hate HTML I'm sure, us programmer types (ruby programmers no less). SGML is the worst man, but thats what we're stuck with, it aint going away any time soon.
You share my same vision, of applications like photoshop being written for a web browser, a subscription model, those are the kind of apps I'm interested in developing. Use google maps as an example of an innovative application. Get real good at Javascript.
I have a DHTML version of lemmings bookmarked on my browser at home. Its pretty impressive for a DHTML only app but it runs slow as hell, for LEMMINGS! Lemmings ran faster on my old sega game gear as a kid. It's a real shame we're stuck with this mess of semi-interoperable technologies. Flash seems to be the best thing to use if you want to write a truly immersive app, credit goes to the last guy to mention this.
-Jeff
···
----- Original Message ----- From: "James Toomey" <jamesvtoomey@yahoo.com>
Newsgroups: comp.lang.ruby
To: "ruby-talk ML" <ruby-talk@ruby-lang.org>
Sent: Wednesday, April 13, 2005 1:24 PM
Subject: What's beyond Rails?
Somewhat off-topic rant: This isn't so much a dig at Rails but a
critique of HTML in general. I've done web development with PHP,
ColdFusion, and ASP, and being able to use Ruby in doing so (especially
with Rails' well-designed database interactivity) is certainly a
welcome change. However, the general model is still the same, in terms
of using code to write out HTML to an essentially-static page. The HTML
interface is still such a far cry from the things you can do with a
rich client. For ordering airline tickets on Travelocity or books on
Amazon, the web works great, but imagine trying to emulate Adobe
Photoshop via a web browser, or a spreadsheet like Excel.
It seems to me that there needs to be a next-generation of HTML that
enables web apps to truly be like rich client apps, and
I don't think the solution needs to be a faster connection that sucks
down the entire application in the form of massive Java applets every
time I want to use the program. Perhaps the solution does need to be a
"computer" that's designed from the ground up as a web-enabled dumb
terminal, but that has forms and controls optimized so that they
require minimal data inflow to tell them what to do.
To me, this would make the web incredibly more useful (and would put
serious potential into the claim that Google wants to become a web
operating system). If I've purchased Adobe Photoshop (or rented it, as
I'm sure will be the more likely model), instead of loading it on every
computer I use, why can't I get to Photoshop at any computer in the
world merely by logging into my personal website and getting access to
every software program I own or am renting? Why would it need to be
reloaded at every computer? This is particularly annoying when you're
visiting a friend in another city for a weekend, and jump onto his
computer to check email or show him how to do something useful, and
think, "I wish I had App X loaded on here right now."
I was disappointed to see Google Suggest being touted as innovative; it
seems to indicate that Google's going to stay within the existing web
realm and not try anything really new (as I read on the web somewhere,
"for a web app, Google Suggest is neat; for a desktop app, it's so
1995"). For all of Google's deep pockets and reputation as innovative,
I expected to see them partner up with a hardware manufacturer and try
something dramatically different.
The underlying issue is that HTTP was never designed to do what it is being used to do. Much like HTML is now doing things it was never designed to do. Designers took HTML and starting using it for layouts, like they were used to with Desktop publishing tools. After the mess of nested tables and FONT tags, CSS came around and became an elegant solution. HTTP is being asked to pretend it's not stateless. Fortunately people have spent a lot of time thinking about this. Unfortunately not all of the ideas are good.
1. Post-backs
I have wasted plenty of time trying to work around ASP.NET's postback architecture. For simple apps it indeed will ostensibly work like a WinForm. For anything moderately complex, you can get into a mess of issues when designing controls and components. Blech. I think the entire premise of postbacks is flawed (hopefully I'm not naively soured just by MS's implementation). Rather, relying on a postback paradigm to mimic statefulness is flawed.
2. Ajax
Ah, asynchronous requests, in-page, you say? Beautiful. No more posting back (at least not continuously)? Great. I can see the faces of a thousand web developers as they anxiously got their invite to gmail (back before they were being given away in wheelbarrows), and watched in awe as the 'view source' command produced not much more than a gigantic javascript library. We've since seen other things like Google maps, and Tada list, and so on. Beyond giant companies dedicating teams of people for specific apps like Google does, I expect RoR to be the 'platform' pushing the envelope with this.
Unfortunately, Javascript is not going to be doing Photoshop-like work anytime soon.
3. RIA
Macromedia has been pushing what it calls 'Rich Internet Applications'. The idea is simple. 99% of browsers have Flash installed, with PLENTY of spare CPU cycles to do the graphics work. Flash can make asynchronous calls like Ajax's HTTPXmlRequest.
Recent versions of Flash (MX, MX 2004) have moved in the direction of App development, with form controls, theming, and more powerful ActionScript. You can either write directly in Actionscript, or you can also use it's developer IDE Flex to write in an XML spec Macromedia developed (cleverly dubbed MXML). The RIA platform is setup like so (correct me if I'm wrong here): You get Flex Server running, and develop RIAs using MXML (MacromediaXML), and Flex server turns them into Flash forms. Neat. It's still maturing, but I think ultimately it's quite promising.
Macromedia even has a desktop wrapper for flash RIA apps called Central. You can download modules like a weather checker, etc. It sort of has an OS X Expose widget look about it. It's a resource pig and it's slow, but again, so was (er.. is) Java. That's what happens when you build your own graphics layer.
4. Dumb Terminals / Thin Clients
This one has been tried again and again and there's no great solution. Microsoft released a version of Windows for thin clients. IBM dumped a ton of money into this. Ultimately people don't want to have just thin clients. They want a hard drive, music, etc. Google's ability to make cheap server farms is just as important as their ability to make searches effective. I wouldn't rule them out from trying anything right now, but I don't think they're after desktop software like photoshop. Their position seems to be that the overall paradigm has changed from desktop-run to Internet run. Just read Paul Graham's 'The Other Road Ahead').
http://www.paulgraham.com/road.html
So what comes after? I don't know. HTTP is an inherently flawed way to use the Internet if you want desktop-like apps like photoshop, but the web has such saturation that people have and will continue to try to make it work.
James Toomey wrote:
···
Somewhat off-topic rant: This isn't so much a dig at Rails but a
critique of HTML in general. I've done web development with PHP,
ColdFusion, and ASP, and being able to use Ruby in doing so (especially
with Rails' well-designed database interactivity) is certainly a
welcome change. However, the general model is still the same, in terms
of using code to write out HTML to an essentially-static page. The HTML
interface is still such a far cry from the things you can do with a
rich client. For ordering airline tickets on Travelocity or books on
Amazon, the web works great, but imagine trying to emulate Adobe
Photoshop via a web browser, or a spreadsheet like Excel.
It seems to me that there needs to be a next-generation of HTML that
enables web apps to truly be like rich client apps, and
I don't think the solution needs to be a faster connection that sucks
down the entire application in the form of massive Java applets every
time I want to use the program. Perhaps the solution does need to be a
"computer" that's designed from the ground up as a web-enabled dumb
terminal, but that has forms and controls optimized so that they
require minimal data inflow to tell them what to do.
To me, this would make the web incredibly more useful (and would put
serious potential into the claim that Google wants to become a web
operating system). If I've purchased Adobe Photoshop (or rented it, as
I'm sure will be the more likely model), instead of loading it on every
computer I use, why can't I get to Photoshop at any computer in the
world merely by logging into my personal website and getting access to
every software program I own or am renting? Why would it need to be
reloaded at every computer? This is particularly annoying when you're
visiting a friend in another city for a weekend, and jump onto his
computer to check email or show him how to do something useful, and
think, "I wish I had App X loaded on here right now."
I was disappointed to see Google Suggest being touted as innovative; it
seems to indicate that Google's going to stay within the existing web
realm and not try anything really new (as I read on the web somewhere,
"for a web app, Google Suggest is neat; for a desktop app, it's so
1995"). For all of Google's deep pockets and reputation as innovative,
I expected to see them partner up with a hardware manufacturer and try
something dramatically different.
James Toomey wrote:
Somewhat off-topic rant: This isn't so much a dig at Rails but a
critique of HTML in general. I've done web development with PHP,
ColdFusion, and ASP, and being able to use Ruby in doing so (especially
with Rails' well-designed database interactivity) is certainly a
welcome change. However, the general model is still the same, in terms
of using code to write out HTML to an essentially-static page.
First of all, the web is a big hyperlinked document.
The HTML interface is still such a far cry from the things you can do with a
rich client.
The internet is a network of information. You can pretty well distribute information with hyperlinked text.
You can critize the kind of how HTML is made but not in this way.
Rich interfaces require users to work a lot with them, to learn to use them. Simple, so mostly easy to use interfaces dont.
Text is black, Links are blue, that is simple, and if there is a good hypertext "author" behind that, it works very well. (See Wikipedia or DMoz)
For ordering airline tickets on Travelocity or books on
Amazon, the web works great
This is already an extension to the basic "task" of the web.
FORMs let the normal user put in some information back onto the network.
but imagine trying to emulate Adobe
Photoshop via a web browser, or a spreadsheet like Excel.
First of all, why should I?
It seems to me that there needs to be a next-generation of HTML that
enables web apps to truly be like rich client apps,
There is SVG, but I don't see the need.
and
I don't think the solution needs to be a faster connection that sucks
down the entire application in the form of massive Java applets every
time I want to use the program.
Massive flash applets - god how I like flash-click-to-play Firefox extensions. Gone, all the trash that burns my eyes.
Perhaps the solution does need to be a
"computer" that's designed from the ground up as a web-enabled dumb
terminal, but that has forms and controls optimized so that they
require minimal data inflow to tell them what to do.
Now what do you want? Rich User Interfaces? Or Simple, easy ones? I don't get you now?
To me, this would make the web incredibly more useful (and would put
serious potential into the claim that Google wants to become a web
operating system).
Web What? DMoz / Wikipedia / Leo ... > Google.
And IF, then Apache ( 
+ Internet Explorer is the "OS of the Web" 
If I've purchased Adobe Photoshop (or rented it, as
I'm sure will be the more likely model),
OMG even more rental things :<
instead of loading it on every
computer I use, why can't I get to Photoshop at any computer in the
world merely by logging into my personal website and getting access to
every software program I own or am renting?
why would I want to rent software. if I am forced to use close software I am already dependent enough on the manufacterer.
Why would it need to be
reloaded at every computer? This is particularly annoying when you're
visiting a friend in another city for a weekend, and jump onto his
computer to check email or show him how to do something useful, and
think, "I wish I had App X loaded on here right now."
Get a notebook. (I can recommend 12" a iBook G4 =)
I was disappointed to see Google Suggest being touted as innovative; it
seems to indicate that Google's going to stay within the existing web
realm and not try anything really new (as I read on the web somewhere,
"for a web app, Google Suggest is neat; for a desktop app, it's so
1995"). For all of Google's deep pockets and reputation as innovative,
I expected to see them partner up with a hardware manufacturer and try
something dramatically different.
I can't figure out what you want to say.
About HTML. Basically there are features missing in regards to forms. You cant have "float values" in forms (no sliders, knobs or anything), you cant do sliders with steppings (fixed value steps) and some of these things need you to create workarounds.
Worst of all is that there is no interactivity without javascript - what a pain.
xul is a nice approach but works only on GRE (gecko runtime engine) atm afaik and yes there is SVG and SMIL - go write a browser (XUL + ruby renderer ;p) the techniques are mostly there.
anyway I still don't see that there is such big need for these things.
there is still the possibility to use client<->server architectures with OS native applications written in ruby or other languages communicating with a server that is on the internet (but not www).
What we do need more is software that let people, everywhere, even those not to familiar with the web, attach content they have to the web WITH metadata, and LINKED into logical structures.
And in regards to this, there are some limits, even IF browser supported current standards, with the current standards cause they do not offer as many layout features as professional news paper designing applications do offer. HTML just does not offer enough structure elements (only 6 levels deep headers?) and CSS does not offer enough layouting power. (try to have a text with an image floating centered, vertically and horizontally... I didnt manage that yet =)
what has all this to do with rails or ruby?
James Toomey wrote:
Somewhat off-topic rant: This isn't so much a dig at Rails but a
critique of HTML in general. I've done web development with PHP,
ColdFusion, and ASP, and being able to use Ruby in doing so
(especially
with Rails' well-designed database interactivity) is certainly a
welcome change. However, the general model is still the same, in
terms
of using code to write out HTML to an essentially-static page. The
HTML
interface is still such a far cry from the things you can do with a
rich client. For ordering airline tickets on Travelocity or books on
Amazon, the web works great, but imagine trying to emulate Adobe
Photoshop via a web browser, or a spreadsheet like Excel.
It seems to me that there needs to be a next-generation of HTML that
enables web apps to truly be like rich client apps, and
I don't think the solution needs to be a faster connection that sucks
down the entire application in the form of massive Java applets every
time I want to use the program. Perhaps the solution does need to be
a
"computer" that's designed from the ground up as a web-enabled dumb
terminal, but that has forms and controls optimized so that they
require minimal data inflow to tell them what to do.
To me, this would make the web incredibly more useful (and would put
serious potential into the claim that Google wants to become a web
operating system). If I've purchased Adobe Photoshop (or rented it,
as
I'm sure will be the more likely model), instead of loading it on
every
computer I use, why can't I get to Photoshop at any computer in the
world merely by logging into my personal website and getting access
to
every software program I own or am renting? Why would it need to be
reloaded at every computer? This is particularly annoying when you're
visiting a friend in another city for a weekend, and jump onto his
computer to check email or show him how to do something useful, and
think, "I wish I had App X loaded on here right now."
I was disappointed to see Google Suggest being touted as innovative;
it
seems to indicate that Google's going to stay within the existing web
realm and not try anything really new (as I read on the web
somewhere,
"for a web app, Google Suggest is neat; for a desktop app, it's so
1995"). For all of Google's deep pockets and reputation as
innovative,
I expected to see them partner up with a hardware manufacturer and
try
···
something dramatically different.
Well, I guess I have a dissenting opinion:
1.) You could do photoshop via http.
It may interest you to skim http://opensource.adobe.com/ and realize
that for a couple versions now, photoshop's UI logic has been written
with declairative sublanguages of their own design. It's fairly
straightforward to imagine treating the UI componant as a declariative
document in xml, that specifies logic for preparing computational
transactions that are relayed via http. It's quite accurrate to think
of applications as a giant spreadsheet, where when a cell is notified
it's invalid it dispatches the requests necessary to re-evaluate it's
contents via http post or xmlhttprequest.
The only real barrier to photoshop via http is not http, it's the lack
of a toolkit for the client side portions. Once uppon a time I would
have said there's no high performance client side language, but these
days, I imagine javascript and most browsers html rendering would
actually be fast enough to handle the various graphics rendering tasks
a photoshop like application does.
2.) REST is good.
Statelessness is good. It's not just an annoyance. It's key to why the
web's architecture works so well. Ask yourself why didn't a rich
document format and snazzy browsers get made on top of protocols that
existed at the time, like nttp?
3.) Thick clients and local applications arn't going to go away.
But you will see a transition in that direction, particularly when part
of the applications target usage is communication. S5Presents and the
similar tools are a great example.
4.) So what's next?
I think it's going to be html + javascript. As ugly as that sounds, the
standards process of the web has always been to try to standardize some
sanity after the fact. Pro-active standards making like SVG has yet to
really work. The key is what the browser makers do. And at the moment,
html + javascript is what they do, and I don't foresee that changing
signifigantly for at least 5 years. Flash is the only thing I really
think has a chance of competing. XUL and some of the other things out
there are quite cool on a technical level, and are really better
solutions. But I don't think they can pierce the barrier to entry. Not
unless someone very big forces the issue (read as: Microsoft, US .gov,
etc).
It's a first past the post situation. Html+Javascript made it past the
post. It's a shame that the horse is lame, blind, insane and infested
with fleas, but it's what managed to win.
So for ruby specificly, what I'd like to see personally is some ruby
tools for abstracting over the guts of html + javascript rich clients.
That's certainly no small task. But it's definately what we can see
already happening all over the place. Look at Rails, it gives you
simple ajax without needing to know javascript. Look at ruby web
dialogs. Look at hobix.
Douglas Livingstone wrote:
That's what Macromedia is trying to sell you!
What about interpreting XUL in Ruby? A Google search on <<ruby xul>> does turn up some material. There is this intersting blog post about a fellow experimenting with Rails + XUL:
http://www.zedshaw.com/blog/programming/ruby_xul.html
Or one could use a YAML version of XUL, I suppose.
Cheers,
--binkley
Yes indeed I am...but first...
I am working on implementing on open-source set of components in Flash (
http://actionstep.org ). Its a port of Cocoa/NextStep/OpenStep to
ActionScript. Its a big project, but its going to be the focus of my
efforts (in my day job) so IT IS going to advance quickly.
Alph will bridge into this component set (rather than Macromedia's
bug-ridden slow set). If we implement NIBs (serialized user interfaces) and
an Interface Builder type of app, then it would be possible to load a remote
UI and control it from a rails app via Alph...that would be a kick-ass long
term solution for RIAs.
Best,
Rich
···
On 4/13/05 4:09 PM, "Francis Hwang" <sera@fhwang.net> wrote:
p.s. Rich Kilmer's Flash app Alph was supposed to help with this whole
issue, Rich are you still working on it?
* Matt Pelletier <pelletierm@eastmedia.net> [2005-04-14 05:38:56 +0900]:
The underlying issue is that HTTP was never designed to do what it is
being used to do. Much like HTML is now doing things it was never
designed to do. Designers took HTML and starting using it for layouts,
I've been real impressed with the mozilla framework. I wonder if
anyone has gotten around to writing ruby binding yet. I'm suprised
more application aren't written using it to be honest.
···
--
Luke | PGP: 0xFBE7D8AF
goseigen@comcast.net | 2A44 9EB2 F541 C1F2 D969 56E3 8617 5B7F FBE7 D8AF
*brain search: web os*
1 Result found: myWebOs.com <http://myWebOs.com>
Does somebody remembers something about mywebos.com <http://mywebos.com>? It
was a project to develop an "entire" OS web-based. Obviously, you still
needs a "real OS" to boot, but everything was on myWebOs: spreasheets,
"word" documents, email client, etc etc etc. I don't know when exactly they
were gone, and where exactly they stopped, but that was a great idea.
Some URL's that I found on google, to make sure I'm not nuts =)
http://www.xent.com/nov99/0465.html
http://www.pcworld.com/news/article/0,aid,14077,00.asp
regards,
juca
···
On 4/13/05, Matt Pelletier <pelletierm@eastmedia.net> wrote:
The underlying issue is that HTTP was never designed to do what it is
being used to do. Much like HTML is now doing things it was never
designed to do. Designers took HTML and starting using it for layouts,
like they were used to with Desktop publishing tools. After the mess of
nested tables and FONT tags, CSS came around and became an elegant
solution. HTTP is being asked to pretend it's not stateless. Fortunately
people have spent a lot of time thinking about this. Unfortunately not
all of the ideas are good.1. Post-backs
I have wasted plenty of time trying to work around ASP.NET<http://ASP.NET>'s
postback
architecture. For simple apps it indeed will ostensibly work like a
WinForm. For anything moderately complex, you can get into a mess of
issues when designing controls and components. Blech. I think the entire
premise of postbacks is flawed (hopefully I'm not naively soured just by
MS's implementation). Rather, relying on a postback paradigm to mimic
statefulness is flawed.2. Ajax
Ah, asynchronous requests, in-page, you say? Beautiful. No more posting
back (at least not continuously)? Great. I can see the faces of a
thousand web developers as they anxiously got their invite to gmail
(back before they were being given away in wheelbarrows), and watched in
awe as the 'view source' command produced not much more than a gigantic
javascript library. We've since seen other things like Google maps, and
Tada list, and so on. Beyond giant companies dedicating teams of people
for specific apps like Google does, I expect RoR to be the 'platform'
pushing the envelope with this.Unfortunately, Javascript is not going to be doing Photoshop-like work
anytime soon.3. RIA
Macromedia has been pushing what it calls 'Rich Internet Applications'.
The idea is simple. 99% of browsers have Flash installed, with PLENTY of
spare CPU cycles to do the graphics work. Flash can make asynchronous
calls like Ajax's HTTPXmlRequest.Recent versions of Flash (MX, MX 2004) have moved in the direction of
App development, with form controls, theming, and more powerful
ActionScript. You can either write directly in Actionscript, or you can
also use it's developer IDE Flex to write in an XML spec Macromedia
developed (cleverly dubbed MXML). The RIA platform is setup like so
(correct me if I'm wrong here): You get Flex Server running, and develop
RIAs using MXML (MacromediaXML), and Flex server turns them into Flash
forms. Neat. It's still maturing, but I think ultimately it's quite
promising.Macromedia even has a desktop wrapper for flash RIA apps called Central.
You can download modules like a weather checker, etc. It sort of has an
OS X Expose widget look about it. It's a resource pig and it's slow, but
again, so was (er.. is) Java. That's what happens when you build your
own graphics layer.4. Dumb Terminals / Thin Clients
This one has been tried again and again and there's no great solution.
Microsoft released a version of Windows for thin clients. IBM dumped a
ton of money into this. Ultimately people don't want to have just thin
clients. They want a hard drive, music, etc. Google's ability to make
cheap server farms is just as important as their ability to make
searches effective. I wouldn't rule them out from trying anything right
now, but I don't think they're after desktop software like photoshop.
Their position seems to be that the overall paradigm has changed from
desktop-run to Internet run. Just read Paul Graham's 'The Other Road
Ahead').So what comes after? I don't know. HTTP is an inherently flawed way to
use the Internet if you want desktop-like apps like photoshop, but the
web has such saturation that people have and will continue to try to
make it work.James Toomey wrote:
> Somewhat off-topic rant: This isn't so much a dig at Rails but a
> critique of HTML in general. I've done web development with PHP,
> ColdFusion, and ASP, and being able to use Ruby in doing so (especially
> with Rails' well-designed database interactivity) is certainly a
> welcome change. However, the general model is still the same, in terms
> of using code to write out HTML to an essentially-static page. The HTML
> interface is still such a far cry from the things you can do with a
> rich client. For ordering airline tickets on Travelocity or books on
> Amazon, the web works great, but imagine trying to emulate Adobe
> Photoshop via a web browser, or a spreadsheet like Excel.
> It seems to me that there needs to be a next-generation of HTML that
> enables web apps to truly be like rich client apps, and
> I don't think the solution needs to be a faster connection that sucks
> down the entire application in the form of massive Java applets every
> time I want to use the program. Perhaps the solution does need to be a
> "computer" that's designed from the ground up as a web-enabled dumb
> terminal, but that has forms and controls optimized so that they
> require minimal data inflow to tell them what to do.
> To me, this would make the web incredibly more useful (and would put
> serious potential into the claim that Google wants to become a web
> operating system). If I've purchased Adobe Photoshop (or rented it, as
> I'm sure will be the more likely model), instead of loading it on every
> computer I use, why can't I get to Photoshop at any computer in the
> world merely by logging into my personal website and getting access to
> every software program I own or am renting? Why would it need to be
> reloaded at every computer? This is particularly annoying when you're
> visiting a friend in another city for a weekend, and jump onto his
> computer to check email or show him how to do something useful, and
> think, "I wish I had App X loaded on here right now."
> I was disappointed to see Google Suggest being touted as innovative; it
> seems to indicate that Google's going to stay within the existing web
> realm and not try anything really new (as I read on the web somewhere,
> "for a web app, Google Suggest is neat; for a desktop app, it's so
> 1995"). For all of Google's deep pockets and reputation as innovative,
> I expected to see them partner up with a hardware manufacturer and try
> something dramatically different.
>
>
>
>
--
juraci krohling costa
http://jkcosta.info
You could take a peek at amf4r. It's on the raa. This lib lets you write your front end in flash and use ruby on the server instead of macromedia's proprietary communication server. amf stands for action message format and its a binary format used to ferry objects back and forth between actionscript and ruby. You can pass just params or arrays or hashes but the coolest thing is you can basically instantiate your server side ruby objects in actionscript and call methods on them from flash. It's pretty cool because of the flexibility of flash interfaces. It's not going to let you write server side photoshop any time soon but its a huge leap forward as far as interfaces go above html.
-Ezra
···
On Apr 13, 2005, at 1:01 PM, Douglas Livingstone wrote:
On 4/13/05, James Toomey <jamesvtoomey@yahoo.com> wrote:
Somewhat off-topic rant: This isn't so much a dig at Rails but a
critique of HTML in general.That's what Macromedia is trying to sell you!
Flash MX with Flash Communication Server.
It isn't quite fast enough to write photoshop in it, but that's what
people are trying to do.On the other end, if we could get programmable SGV (imo we need a
"canvas" of some sort to get close to excel apps) there might be
something there, or you could try XBL/XUL of some sort. (I'd love to
be able to do client side Ruby XBL interfaces...)Douglas
-Ezra Zygmuntowicz
Yakima Herald-Republic
WebMaster
509-577-7732
ezra@yakima-herald.com
For those of us who don't know, care to post a quick explanation of what a post-back is? I Googled it but only got a bunch of ASP.NET pages. And if I'm gonna read about Microsoft APIs, somebody better be paying me.
Francis Hwang
···
On Apr 13, 2005, at 4:38 PM, Matt Pelletier wrote:
1. Post-backs
I have wasted plenty of time trying to work around ASP.NET's postback architecture. For simple apps it indeed will ostensibly work like a WinForm. For anything moderately complex, you can get into a mess of issues when designing controls and components. Blech. I think the entire premise of postbacks is flawed (hopefully I'm not naively soured just by MS's implementation). Rather, relying on a postback paradigm to mimic statefulness is flawed.
Don't forget DHTML (Javascript + HTML).
Look, here is an impressive DHTML GUI framework : http://bindows.net
Demo : http://bindows.net/bindows/samples/applauncher/
Cheers,
.... zimba
Hi Francis.
Francis Hwang wrote:
REST used to be a largely academic concern,
For those non-web developers (like me) that still
want to follow along, see
http://www.xfront.com/REST-Web-Services.html
for a description of REST (REpresentational State Transfer).
Later,
···
--
Bil Kleb
http://fun3d.larc.nasa.gov
What's beyond rails?
~>ruby -e 'puts "rails".succ'
railt
Not very sexy, I'll grant you that.
The problem is that there are no high-performance libraries for javascript to munge image data. To do arbitrary edits to an image in javascript, you need to use a single div(or somesuch element) per pixel, and do all the calculation in js. Even when it's a small 640x480 image with a single layer, it's going to be 307200 pixels. And that's going to be slow going in dhtml. The browsers'll probably blow up at around hundred thousand elements.
When you can run Quake 1 with software rendering in a 320x240 window with html + javascript, it'll be about fast enough for Photoshop. (Maybe there is there a port of q1?)
Maybe if there was a fast VM for javascript and direct rendering access in DOM...
*shrug* who knows what the future brings
···
On 16.4.2005, at 00:09, jason_watkins@pobox.com wrote:
Well, I guess I have a dissenting opinion:
1.) You could do photoshop via http.
It may interest you to skim http://opensource.adobe.com/ and realize
that for a couple versions now, photoshop's UI logic has been written
with declairative sublanguages of their own design. It's fairly
straightforward to imagine treating the UI componant as a declariative
document in xml, that specifies logic for preparing computational
transactions that are relayed via http. It's quite accurrate to think
of applications as a giant spreadsheet, where when a cell is notified
it's invalid it dispatches the requests necessary to re-evaluate it's
contents via http post or xmlhttprequest.The only real barrier to photoshop via http is not http, it's the lack
of a toolkit for the client side portions. Once uppon a time I would
have said there's no high performance client side language, but these
days, I imagine javascript and most browsers html rendering would
actually be fast enough to handle the various graphics rendering tasks
a photoshop like application does.
Luke Renn wrote:
* Matt Pelletier <pelletierm@eastmedia.net> [2005-04-14 05:38:56 +0900]:
The underlying issue is that HTTP was never designed to do what it is being used to do. Much like HTML is now doing things it was never designed to do. Designers took HTML and starting using it for layouts,
I've been real impressed with the mozilla framework. I wonder if
anyone has gotten around to writing ruby binding yet. I'm suprised
more application aren't written using it to be honest.
It was started, but it has not been active for a couple years. From what I recall, it was to the point where you could write XPCOM components in Ruby. What was still needed was to be able to use Ruby along with JavaScript in handling the XUL UI scripting.
Curt