Content area
Abstract
What I mean by that is that it will no longer have to be programmed in Java- Script. Because [Micro- soft] Silverlight 2.0 comes with a 'bridge' to the DOM [Document Object Model] programming model, all .Net languages will be able to program in the browser.
Full text
Not everyone is excited about the prospect of Ruby on Rails in the browser
THE DEVELOPment community weighed in on a recent story about support for Ruby on Rails in the browser - with some readers saying they liked the idea and one going so far as to ask, "Why stop at Ruby? Why not add support for more established languages such as Visual Basic?" Not everyone thinks such a move is a step in the right direction, however.
The story described how Microsoft's John Lam, creator of the IronRuby project at Microsoft, is proposing the use of Ruby instead of JavaScript in the AJAX-style development paradigm -creating "ARAX" (Asynchronous Ruby and XML).
In a blog post responding to the article, Frank Fischer, manager for technical evangelism at Microsoft Germany, said: "The DLR [Dynamic Language Runtime] can not only run Ruby (ARAX) but also Python (APAX) or - and this is a community project-PHP (APhpAX). ... You can go down the line with dynamic languages as far as you can."
Taft Software founder Troy Taft said he believes the big change will be the "liberation of the browser. What I mean by that is that it will no longer have to be programmed in Java- Script. Because [Micro- soft] Silverlight 2.0 comes with a 'bridge' to the DOM [Document Object Model] programming model, all .Net languages will be able to program in the browser. This means that the droves of [Visual Basic] and C# programmers will suddenly have access to the client side of the Web for the first time."
Taft said that as a programmer he knows how great it feels to be permitted to write code on the client again, where state is welcome.
"The Web server doesn't want to remember who you are and why you were there; the browser is another story," said Taft. "It belongs to just one user at a time, and it is actually beneficial to keep state about the application with the user. This is how the old client/server technology that made VB [Visual Basic] great worked. It also naturally strengthens the SOA [service-oriented architecture] model by allowing a stateless connection to any service provider."
Taft added that he is seeing a possible return to client/server development inside the browser using more powerful languages and plug-in frameworks that download automatically. This, he said, will make Ruby - as well as VB, C# and Python - an option. "I think that more than a few programmers will be smiling," he said.
Gary Edwards, a commenter on the ARAX article on eWEEK's site, said he thinks the browser plug-in model is being used as a distribution channel for Microsoft's and Adobe's proprietary run-time engines.
"The easiest way for Web developers to sidestep problematic browser wars, and still be able to push the envelope of the interactive Web, may well be to write to a universal runtime plug-in like Adobe AIR or Microsoft Silverlight," Edwards wrote. "The 'browser' quickly fades away once this direct development sets in."
Another commenter on the eWEEK site, who identified himself as Frank Lygato, said he has no interest at all in seeing Ruby in the browser.
"I have zero interest in running Ruby in my browser unless it becomes an official standard for browsers (i.e., not dependent on a plug-in from one supplier). I hate Flash for similar reasons," Lygato wrote. "When the security of my browser starts depending on complex third-party plug-ins like Adobe's and Microsoffs, I'm unhappy."
Salesforce.com Director of Platform Research Peter Coffee said the focus on JavaScript versus Ruby is misplaced.
In his blog post "Same McNuggets, Different Sauce," Coffee, a former eWEEK advanced technologies analyst, wrote, "Proposing the use of Ruby rather than JavaScript, it seems to me, is like introducing a new dipping sauce for fast-food chicken: It doesn't change whaf s inside the coating of crumbs - and the problem with getting all excited about ARAX versus AJAX is that it accentuates a minor difference while overlooking a shared crucial flaw."
Coffee added, "When Microsoft's John Lam went to RailsConf to talk about his IronRuby project, he asserted that developers would gain by avoiding a mental shift between two different languages on either side of the client/server boundary. 'At some point,' he said, 'you might have to add some JavaScript code that adds some custom functionality on the client - but my question is, Why are we still talking about client-side code at all?"
Coffee compared this model with Salesforce. corn's Apex Code, which, he said, "doesn't have to run in the variegated environments of different browsers on different fat-client stacks: The application's logic runs in the cloud, with consistency guaranteed as an inherent property of having only one execution environment."
Another commenter on the ARAX story, identified simply as "Jay," sees the traditional Microsoft model at work.
"Its good to see Microsoft hasn't changed," said the commenter. "They're still promoting the use of closed, proprietary tools over open standards. Thank goodness we can count on them in a rapidly changing world. That pesky, 'quirky JavaScript lets anybody look at and learn from code. It's far better to hide it away and achieve your security through obscurity."
Copyright Ziff Davis Enterprise Inc. Jun 16, 2008