eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Readers weighed in on a recent story about support for Ruby in the browser, some 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?
Indeed, that is exactly what Taft Software founder Troy Taft, who was quoted in the article, said.
In the story about ARAX (Asynchronous Ruby and XML), I described how Microsoft’s John Lam is proposing the use of Ruby instead of JavaScript in the AJAX (Asynchronous JavaScript and XML)-style development paradigm. But readers weighed in suggesting going further. 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.”
Meanwhile, Troy Taft said, “My guess is that the real change event is going to be the ‘liberation of the browser.’ What I mean by that is that it will no longer have to be programmed in JavaScript. Because 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 VB and C# programmers will suddenly have access to the client side of the Web for the first time.”
Taft said as a programmer, he knows what it feels like “to not be bound by the stateless Web server and 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. 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 great worked. It also naturally strengthens the SOA [service-oriented architecture] model by allowing a stateless connection to any service provider.”
Moreover, Taft said he is seeing “a possible return to client/server development inside the browser using more powerful languages and plug-in frameworks that download automatically, and it will make Ruby an option (as well as VB, C# and Python). I think that more than a few programmers will be smiling.”
Taft said he believes ARAX with Microsoft’s IronRuby is one example of this return to the client. “But will VB be a bigger thing? Who knows,” he added.
A commenter on the ARAX article on eWEEK’s site named Gary Edwards said, “It seems to me that Adobe and Microsoft are using the browser plug-in model as a distribution channel for their proprietary run-time engines. Or should we call them VMs [virtual machines]?
“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 run-time plug-in like Adobe AIR or Microsoft Silverlight. IMHO, the ‘browser’ quickly fades away once this direct development sets in.”
Moreover, Edwards said, “Although there are many ways to slice this discussion, it might be useful to compare Adobe RIA [Rich Internet Applications] and Microsoft Silverlight RIA in terms of Web-ready, highly interactive documents. The Adobe RIA story is quite different from that of Silverlight. Both however exploit the shortcomings of browsers; shortcomings that are in large part, I think, due to the disconnect the browser community has had with the W3C [World Wide Web Consortium]. The W3C forked off the HTML-CSS [Cascading Style Sheets] path, putting the bulk of their attention into XML, RDF and the Semantic Web. The Web developer community stayed the course, pushing the HTML-CSS envelope with JavaScript and some rather stunning CSS magic.
“Adobe seems to have picked up the HTML-CSS-JavaScript trail with a Microsoft innovation to take advantage of browser cache, DHTML (Dynamic HTML). DHTML morphs into AJAX, (which [is] so wild as to have difficulty scaling). And AJAX gets tamed by an Adobe-Apple sponsored WebKit.”
In a blog post entitled “Same McNuggets, Different Sauce,” former eWEEK writer Peter Coffee 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 what’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, who is now director of platform research at Salesforce.com, 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?
“The whole point of Apex Code, in particular, is that code 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 eWEEK site, who identified himself as Frank Lygato, said he had 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 Microsoft’s, I’m unhappy.”
Finally, another commenter, who identified himself simply as Jay, was a bit more sarcastic. “It’s good to see Microsoft hasn’t changed,” he wrote. “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.”