«

I have been reading through RAILS and builing the Depot Application
ect. And been very impressed with the RAILS framework.

But I cannot help feeling that I seem to be writing a lot of HTML
fragements and <% Ruby inserts for realisable web pages, when I move
away from the scaffold. What Web design Editors do people use with
RAILS development ?

With the MVC concept and heavy use of HTML, I am having doubts that
this is the way to develop those compelling highly graphical web pages.
I can use AJAX and RAILS on the server side, but if I want dynamic
graphics I still need heavy JavaScript, Flash or Java Applet code on
the client side. In which case I don't see where RAILS fits in. So I
am comming to the conclusion that RAILS is really for Server side
development for the 90% of 'typical', and rather dreary, web
applications development.

Just my views/ feelings so far.

Jules

On 1/8/06, Jules <> wrote:
> I have been reading through RAILS and builing the Depot Application
> ect. And been very impressed with the RAILS framework.
>
> But I cannot help feeling that I seem to be writing a lot of HTML
> fragements and <% Ruby inserts for realisable web pages, when I move
> away from the scaffold. What Web design Editors do people use with
> RAILS development ?

A lot of people use vim, emacs, or textmate (for OS X).

> With the MVC concept and heavy use of HTML, I am having doubts that
> this is the way to develop those compelling highly graphical web pages.
> I can use AJAX and RAILS on the server side, but if I want dynamic
> graphics I still need heavy JavaScript, Flash or Java Applet code on
> the client side. In which case I don't see where RAILS fits in. So I
> am comming to the conclusion that RAILS is really for Server side
> development for the 90% of 'typical', and rather dreary, web
> applications development.

I'm not sure what you mean here.

On 1/8/06, Jules <> wrote:
> I have been reading through RAILS and builing the Depot Application
> ect. And been very impressed with the RAILS framework.
>
> But I cannot help feeling that I seem to be writing a lot of HTML
> fragements and <% Ruby inserts for realisable web pages, when I move
> away from the scaffold. What Web design Editors do people use with
> RAILS development ?
>
> With the MVC concept and heavy use of HTML, I am having doubts that
> this is the way to develop those compelling highly graphical web pages.
> I can use AJAX and RAILS on the server side, but if I want dynamic
> graphics I still need heavy JavaScript, Flash or Java Applet code on
> the client side. In which case I don't see where RAILS fits in. So I
> am comming to the conclusion that RAILS is really for Server side
> development for the 90% of 'typical', and rather dreary, web
> applications development.

You might find people who can make a more compelling argument for
Rails on the rails mailing list. Not everyone here likes/uses/works
with rails.

That having been said, there are a number of very dynamic and
not-so-dreary web applications built in Rails, such as Typo and
Basecamp and other projects.

> With the MVC concept and heavy use of HTML, I am having doubts that
> this is the way to develop those compelling highly graphical web pages.
> I can use AJAX and RAILS on the server side, but if I want dynamic
> graphics I still need heavy JavaScript, Flash or Java Applet code on
> the client side. In which case I don't see where RAILS fits in. So I
> am comming to the conclusion that RAILS is really for Server side
> development for the 90% of 'typical', and rather dreary, web
> applications development.

Rails sits on the server ('server-side' development), whereas you're talking
about 'client-side' design. Even with scripting to allow graphics to behave
in a certain way, unless those graphics are talking to the server then
they're what I would call 'scripted design'. Design and development are
linked, but are different. So I suppose I'm saying, for the use you're
wanting, I would stick with Flash, or JavaScript. You can use Flash and
JavaScript in Rails, but if dynamic graphics is all you desire there would
be little point.

I think you're a little confused about what modern websites are. Flash was
modern 7 years ago. Dynamic graphics, probably older. A good guess at what
is popularly regarded as modern these days is outlined in this article from
the Wikipedia http://en.wikipedia.org/wiki/Web_2.0, particularly these
ideas: "...referring to an approach to creating and distributing Web content
itself, characterised by open communication, decentralization of authority,
freedom to share and re-use... a transition of websites from isolated
information silos to sources of content and functionality, thus becoming a
computing platform serving web applications to end users." and can be
achieved with no graphics whatsoever, dynamic or otherwise.

Of course, what is truly modern is up to you, you're part of its authorship
afterall.

Luke

Most Web Applications don't use Heavy Dynamic Graphics. You're starting by
arguing whether Rails is suitable yet you're actually arguing on the
differences between Thin HTML clients and Thick clients. Rails, JSF, JSP,
Struts, Shale, Tapestry: these are frameworks, tools if you will, that you
use on web applications, whether they be CRUD types or otherwise.

Don't disregard a wrench as completely useless when you currently need a
screwdriver. It may not be suitable for that particular use, but that
doesn't make the wrench worthless for other things.

-Zach

-----Original Message-----
From: luke [private.php?do=newpm&u= (dot)]
Sent: Sunday, January 08, 2006 5:08 AM
To: ruby-talk ML
Subject: Re: Is Ruby RAILS really suitable for modern Web Development ?


> With the MVC concept and heavy use of HTML, I am having doubts that
> this is the way to develop those compelling highly graphical web pages.
> I can use AJAX and RAILS on the server side, but if I want dynamic
> graphics I still need heavy JavaScript, Flash or Java Applet code on
> the client side. In which case I don't see where RAILS fits in. So I
> am comming to the conclusion that RAILS is really for Server side
> development for the 90% of 'typical', and rather dreary, web
> applications development.

Rails sits on the server ('server-side' development), whereas you're talking
about 'client-side' design. Even with scripting to allow graphics to behave
in a certain way, unless those graphics are talking to the server then
they're what I would call 'scripted design'. Design and development are
linked, but are different. So I suppose I'm saying, for the use you're
wanting, I would stick with Flash, or JavaScript. You can use Flash and
JavaScript in Rails, but if dynamic graphics is all you desire there would
be little point.

I think you're a little confused about what modern websites are. Flash was
modern 7 years ago. Dynamic graphics, probably older. A good guess at what
is popularly regarded as modern these days is outlined in this article from
the Wikipedia http://en.wikipedia.org/wiki/Web_2.0, particularly these
ideas: "...referring to an approach to creating and distributing Web content
itself, characterised by open communication, decentralization of authority,
freedom to share and re-use... a transition of websites from isolated
information silos to sources of content and functionality, thus becoming a
computing platform serving web applications to end users." and can be
achieved with no graphics whatsoever, dynamic or otherwise.

Of course, what is truly modern is up to you, you're part of its authorship
afterall.

Luke

Thanks Luke

I guess was asking how RAILS could relate to any dynamic graphical
displays on client side.

Yep I can understand Flash and Java Applets as being dated, and so I am
questioning whether I should be using Thick Clients, with highly
dynamic/compelling displays using Web Services, rather than using
standard Web/scripts which don't give the end user a compelling
experience.

Thanks

Jules

I guess was asking how RAILS could relate to any dynamic graphical
displays on client side.

Yep I can understand Flash and Java Applets as being dated, and so I am
questioning whether I should be using Thick Clients, with highly
dynamic/compelling displays using Web Services, rather than using
standard Web/scripts which don't give the end user a compelling
experience.

Thanks

Jules

Thanks Luke

I guess was asking how RAILS could relate to any dynamic graphical
displays on client side.

Yep I can understand Flash and Java Applets as being dated, and so I am
questioning whether I should be using Thick Clients, with highly
dynamic/compelling displays using Web Services, rather than using
standard Web/scripts which don't give the end user a compelling
experience.

Thanks

Jules

Thanks Luke

I guess was asking how RAILS could relate to any dynamic graphical
displays on client side. I mean the V in MVC is all about the Page
design on the client side. Somehow I cannot see how raw HTML and <%
Ruby editing will become mainstream without a decent web designer
support.

Yep I can understand Flash and Java Applets as being dated, and so I am
questioning whether I should be using Thick Clients, with highly
dynamic/compelling displays using Web Services, rather than using
standard Web/scripts which don't give the end user a compelling
experience.

Thanks

Jules

On Mon, Jan 09, 2006 at 06:08:02PM +0900, Jules wrote:
> Thanks Luke
>
> I guess was asking how RAILS could relate to any dynamic graphical
> displays on client side.
>
> Yep I can understand Flash and Java Applets as being dated, and so I am
> questioning whether I should be using Thick Clients, with highly
> dynamic/compelling displays using Web Services, rather than using
> standard Web/scripts which don't give the end user a compelling
> experience.

In other words . . . you're looking for Flash and Java applets without
Flash or Java?

--
Chad Perrin [ CCD CopyWrite | http://ccd.apotheon.org ]

"Real ugliness is not harsh-looking syntax, but having to
build programs out of the wrong concepts." - Paul Graham