Asp Forum - What's beyond Rails?

James Toomey

4/13/2005 7:23:00 PM

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.

35 Answers

Douglas Livingstone

4/13/2005 8:01:00 PM

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

B. K. Oxley (binkley)

4/13/2005 8:07:00 PM

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/rub...

Or one could use a YAML version of XUL, I suppose. :)

Cheers,
--binkley

Francis Hwang

4/13/2005 8:10:00 PM

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
http://f...

Jeffrey Moss

4/13/2005 8:21:00 PM

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.
>
>

Richard Kilmer

4/13/2005 8:34:00 PM

Yes indeed I am...but first...

I am working on implementing on open-source set of components in Flash (
http://acti... ). 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

4/13/2005 8:39:00 PM

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...

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.
>
>
>
>

Luke Renn

4/13/2005 8:46:00 PM

* 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

Curt Hibbs

4/13/2005 9:00:00 PM

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

Juraci Krohling Costa

4/13/2005 9:07:00 PM

*brain search: web os*

1 Result found: myWebOs.com <http://myWeb...

Does somebody remembers something about mywebos.com <http://mywebo... 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...
http://www.pcworld.com/news/article/0,aid,14...

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...
> 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...
>
> 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://jk...

Ezra Zygmuntowicz

4/13/2005 9:18:00 PM

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

comp.lang.ruby

What's beyond Rails?