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
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?
| [reply] [Watch: Dir/Any] |
|
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
| [reply] [Watch: Dir/Any] |
|
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
| [reply] [Watch: Dir/Any] |
|
| [reply] [Watch: Dir/Any] |
|
Re: There is probably just one way to do it
by GrandFather (Saint) 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
| [reply] [Watch: Dir/Any] |
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).
| [reply] [Watch: Dir/Any] |
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?
| [reply] [Watch: Dir/Any] |
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. | [reply] [Watch: Dir/Any] |
Re: There is probably just one way to do it
by jdporter (Paladin) on Jan 02, 2011 at 13:09 UTC
|
| [reply] [Watch: Dir/Any] |
Re: There is probably just one way to do it
by ait (Hermit) 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
| [reply] [Watch: Dir/Any] |
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 :-) | [reply] [Watch: Dir/Any] |
|
|