Beefy Boxes and Bandwidth Generously Provided by pair Networks kudra
Don't ask to ask, just ask
 
PerlMonks  

There is probably just one way to do it

by punkish (Priest)
on Jan 01, 2011 at 21:27 UTC ( #880036=perlquestion: print w/ replies, xml ) Need Help??
punkish has asked for the wisdom of the Perl Monks concerning the following question:

TMTOWTDI is one of the chief points (positive or negative depends on the POV) of our favorite language. I certainly find it to be a plus point. Followers of other languages sometimes use that as a strike against Perl. While tackling a programming task earlier today, it occurred to me that while we have an embarrassment of riches when it comes to languages on the server side, within the browser we have only JavaScript. The downside is that I have to work within the innovations confined by the limits of JavaScript (I was actually looking for a MVC toolkit for JavaScript, but that is another story). The plus side is that when I encounter a problem, I don't have to offer pseudocode to to others who might want to help me -- I can offer real code because if they can help me with my browser-side problem, they *have* to know JavaScript.

If there is only one way to do it, would that be a positive or a negative?

Why is it that alternatives to JavaScript have not developed or gained traction (ECMAScript and VBScript don't count -- they are all really JavaScript -- frankly, other than VBScript, I don't even know the difference between the other two).

--

when small people start casting long shadows, it is time to go to bed

Comment on There is probably just one way to do it
Re: There is probably just one way to do it
by JavaFan (Canon) on Jan 01, 2011 at 21:38 UTC
    Why is it that alternatives to JavaScript have not developed or gained traction
    Because that will only work if all major browser vendors sit together and decide what the alternative will be. Because if say, IE, implements "ReallyCoolLanguage", developers will have the choice of:
    • Writing it once, in JavaScript, and having it work on all major browsers.
    • Writing "only works on IE" pages.
    • Writing it twice: once for IE, and other time in JavaScript, for the rest.
    But why should browser vendors sit together and develop an alternative for JavaScript. What's in it for them?
      Hi JavaFan, great answer, albeit an obvious one, but that begets more questions then. The "environment" in which the language runs becomes the restriction then. For some reason, the environment in which the server side languages run (the entire operating system) is just the opposite of restrictive.

      And, for all the love and talk of open, we are perfectly happy with having a Hobson's Choice of only JavaScript on the browser side simply because the browser vendors choose to not cooperate beyond compatibility with JavaScript. Why isn't that alternative browsers have developed then? Ones that could offer alternatives to JavaScript? Perhaps, a Perl browser that implements a fully first class Perl implementation inside it. Perhaps, a Java or a Python browser.

      Definitely (at least to me) an interesting thing to think about.

      --

      when small people start casting long shadows, it is time to go to bed

        Why don't you write such a browser and make it so good it displaces all the other common browsers out there now to become the leader of the pack that everything else follows?

        This is not a question of open standards or anything of that sort, but of the historical growth of pretty much all the internet related technologies. The same sort of thing has happened many times in very many different areas. Consider Betamax and VHS for example or more recently Blu-ray Disc and HD DVD, or television video formats, or screw head types, or ... . Any place where there are trade offs affecting implementation and adoption that result in incompatible systems there tends to be a variant that succeeds and everything else falls by the wayside. That's just market forces at work and often has very little to do with the technical qualities of the technologies involved.

        So all you have to do is convince all the browser suppliers and all web content providers that Perl should be the client side scripting language, or write a browser that is so much better than everything else that you can enforce your own will, and that particular part of the world is your oyster.

        True laziness is hard work
        Why isn't that alternative browsers have developed then?
        Alternative browsers haven't been developed? I'd say, alternative browsers have been developed ever since the early 1990s. It started with a couple of line mode browsers. Then Mosaic. From Mosaic, Netscape was developed. W3C came with Arena. Microsoft entered the market with IE. Netscape became Mozilla, which became Firefox. Opera came. Apple developed Safari. Google has Chrome. And there are numerous lesser know browsers.

        Ones that could offer alternatives to JavaScript?
        I guess none of the browser makers in the past saw any advantage. Perhaps I should bounce the question back: why haven't you created an alternative?
        Ones that could offer alternatives to JavaScript?
        But why? Don't forget, there are more than a billion users of browsers who will never ever write HTML let alone any embedded code. Most browser vendors will have a business model - they don't employ a development team just for the fun of it.
        Perhaps, a Java or a Python browser.
        Both done in the previous century: Hot Java and Grail. But Joe R. User just wants a browser that works with his computers, and which is preferable the same one as he uses in his office, and which his neighbour is using.

        And why shouldn't he? Why would he care whether his browser is capable of running Python scripts?

Re: There is probably just one way to do it
by GrandFather (Cardinal) on Jan 01, 2011 at 21:53 UTC

    Whatever is provided client side is provided by the browser. Most browsers (but not all) provide a JavaScript implementation (and Java). Some browsers offer other languages, but for general use web pages the presence of other languages can't be relied on.

    You can easily find pages that require specific language or technology support and which do not render correctly if that support is not available. Often those pages will require a specific browser to ensure the required support is available. It is possible to use Perl client side for example, but it's not commonly done because very few client systems are set up to provide it.

    Server side you can use whatever language you can convince your administrator to install so there are effectively no constraints on what can be used.

    True laziness is hard work
Re: There is probably just one way to do it
by Anonymous Monk on Jan 01, 2011 at 22:29 UTC
    VBScript is not related to Javascript; it is a Visual Basic dialect imlpemented on Microsoft's browser and the Windows Scripting Host (also not to be confused with VBA). I think you're thinking of JScript, which is Microsoft's ECMAScript implementation in the browser and the WSH.
Re: There is probably just one way to do it
by ysth (Canon) on Jan 02, 2011 at 04:03 UTC
    What about ActiveX? What about Flash and Flex?
    I was actually looking for a MVC toolkit for JavaScript, but that is another story
    Jemplate?
    --
    A math joke: r = | |csc(θ)|+|sec(θ)|-||csc(θ)|-|sec(θ)|| |
    Online Fortune Cookie Search
Re: There is probably just one way to do it
by derby (Abbot) on Jan 02, 2011 at 12:38 UTC

    While I kinda understand your desire for another client side scripting language, I wouldn't be so quick to dismiss Javascript. Given the explosion of JS frameworks (JQuery, Moo, YUI, prototype, Dojo, etc), I've come to think of client side scripting as those frameworks ... so I would never look for a Javascript MVC solution, but a JQuery one (and TMTOOT -- there's more than one of those).

    -derby
Re: There is probably just one way to do it
by jdporter (Canon) on Jan 02, 2011 at 13:09 UTC
There is more than one way to do it
by detenebrator (Initiate) on Jan 04, 2011 at 20:36 UTC
    There's huge benefits to having just one language to implement, too huge to fragment the browser space any worse than it already is (just try to get consistent results across browsers, even with only "one" language). What's happened is that Javascript as *implementation* is the one way, but you can program in at least Java and Python. Look at Google Web Toolkit or Pyjamas. Both just use Javascript as the "assembly language". You can leverage a lot of the infrastructure of either language in spite of the "only Javascript" in the browser. It's just no one has tried the same for Perl (to my limited knowledge :-)
Re: There is probably just one way to do it
by ait (Friar) on Jan 04, 2011 at 20:51 UTC

    Yeah well JS is probably your best bet, unless you want to rely on the use of binary plug-ins such as Flash, or develop in Java (ugh!).

    Contrary to popular belief though, JS is actually a very powerful and fun language to work with, especially if you base your code on well designed "framework" libs such as prototype and JQuery, which take away the not-so fun parts of JS development.

    Now if you really want to have fun, and combine the power of the Perl world with JS, may I suggest you look at Jemplate and use _that_ in combination with JQuery. And if you really, really, want to have fun, use Catalyst with the Jemplate plug-in.

    Cheers,
    Alejandro Imass

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://880036]
Front-paged by Arunbear
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others pondering the Monastery: (5)
As of 2014-04-20 14:54 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    April first is:







    Results (485 votes), past polls