Re: [naviserver-devel] hosting java-script server-side?

[Mike <nee...@gm...>]

On 9/17/06, Zoran Vasiljevic <zv...@ar...> wrote:
> Following a recent discussion on the sister-project, I just wanted
> to check what would you think about integrating javascript as an
> alternate language to Tcl ?
>
> I'm long time user of Tcl (over 12 years) and I still preffer it
> to any other scripting language, buI I see that most of the
> younger people are actually already fluent in javascript
> whereas they are not fluent in (mostly even do not know about) Tcl.
>
> This is at the moment not an issue for us but it may be one in the
> future....
>
> I do not know what would need to be done and to what extent a
> "foreign" language could/should be integrated in the server;
> I just wanted to hear what people would think about this.

Vote: -1
Explanation: waste of time

Of the vast sea of scripting languages out there, I am most fluent in
Tcl and Javascript.  I consider both very good languages (with Tcl
having a slight edge).  If NaviServer's underlying language was
JavaScript - I wouldn't complain.  But it isn't.  It's Tcl.
In the end, a programming language is just a tool.  Unless it's
absolutely horrendous (e.g. php or csh) there's no real reason to
switch other than a time-consuming exercise.  Adding more language
bindings is just going add complexity and require more maintenance,
take developer time, and have very few benefits.  If someone is
serious about using a tool, they will learn the language - and Tcl is
not a bad language to learn.
That's purely language-specific.  Now, for the Javascript technical
part.  Tcl is deeply rooted in NaviServer code - trying to stick
another language's interface in is just not going to be an easy task.
Furthermore, there is no "one good and supported" Javascript
interpreter.  Most of them have problems - the the "more maintained"
ones having more problems and bloat than the less maintained ones
(double-edged sword).  If you really insist on going down this path,
my recommendation would be to look at the Tcl binding that was created
for BrowseX...  Alas, that interpreter falls into the "less
maintained" category.