Page 3 of 3

Posted: Sat Aug 25, 2007 4:52 am
by Ollie Saunders
:lol:

Posted: Tue Sep 04, 2007 10:17 am
by Bon Bon
Sorry to spoil the party but this sounds like a great idea, PHP is already being used to develop applications when people said this was not a possibility.

The only real problem I see is Microsoft and Internet Explorer.

I think rather than specifically saying use PHP on the client side, using the PHP syntax as opposed to Javascripts would be a PHP developers dream.

So something like:

Code: Select all

<script type="text/php">$document->body->div['id="test"']->insertElement($text);</script>
Would be enough to please me.

Posted: Tue Sep 04, 2007 11:05 am
by RobertGonzalez
Honestly, if what you want is Javascript to work like PHP, why not code a JS library that works like PHP?

And Kieran, you can take your number down to two for the steak knives. You had me at 'I heart'.

Posted: Tue Sep 04, 2007 1:13 pm
by Bon Bon
Everah wrote:Honestly, if what you want is Javascript to work like PHP, why not code a JS library that works like PHP?
Simple, I have never got into Javascript, I only know basics but even then I am lame. This is why I would love PHP syntax hehe.

Posted: Thu Sep 13, 2007 12:08 am
by swiftouch
Learning Javascript shouldn't be too hard. That's the initial hurdle. The cool thing about Javascript are it's client side functions. The only thing that I disagree with is how it is widely used to validate with popups. I hate popups, in every form. But I understand your reasoning for thinking there should be a way to make client-side php available. The trouble is, there's just not enough need for it.

Posted: Thu Sep 13, 2007 2:06 am
by Luke
Very few people who take the time to properly learn javascript keep their opinion that it is not a very good language. I used to hate it myself until Kieran converted me. I also heart jQuery.

PHP would, in my opinion, be a really lame client-side language. It just isn't geared for client-side development. Although PHP is a great language, and I am glad it has gained so much popularity, I don't think it's the best. In fact, it's far from it. There are many better languages. What makes PHP so great, in my mind, is that it is open-source, it has a great community, great documentation, huge userbase, huge install-base (is that a word?), and it is easy to learn.

Re: PHP on the client side of the browser

Posted: Fri Oct 19, 2007 10:24 am
by thinsoldier
The Phoenix wrote:
yacahuma wrote:Why do we keep using javascript? It is a terrible language in my opinion.
Because it is installed on 95% (+) of browsers, it is standard, and it enables a tremendous amount of functionality. Its tested, understood, and has been in wide use for over a decade. What makes it a terrible language in your opinion?
Which is why I think it's time they dropped <script type="javascript">...</script> and just use <javascript>...</javascript>

The Phoenix wrote: Each language is designed for something specific. PHP isn't a client side language, so couldn't do many of the things that javascript does.
I've been able to do much of the same document object model tree climbing with php's DOMDocument class that I do with prototype(js library)

I thought of JS as a poor language because it's syntax is just so ugly and before finding mozilla's good documentation of JS it was a pain trying to find a JS equivalent of php's foreach(), while() and other things which just made it hard to use. If not for prototype I wouldn't be doing anything involving javascript.

Now that we have prototype and similar libraries I think ECMA needs to have a look at the 2 most popular ones and start integrating all these brilliant, simple, time saving ideas into the next Javascript version and the w3c should remove <script> and add <javascript>

... although if the ecma doesn't do that, maybe the browser devs can impliment
<script type="javascript_lib:prototype:1.5">
<script type="javascript_lib:jquery:2.0">
etc. and make it standard practice for the browser itself to contain multiple stable versions the library files instead of having to download them over and over from site after site.

... or...
<javascript library="prototype" version="1.5">
<javascript library="yui" version="1.9">

and maybe someday make it possible for multiple libraries to be used in the same page without conflicting with each other?

Re: PHP on the client side of the browser

Posted: Fri Oct 19, 2007 11:53 am
by The Phoenix
thinsoldier wrote: Which is why I think it's time they dropped <script type="javascript">...</script> and just use <javascript>...</javascript>
Just because its ubiquitous, we should change the way you reference it, and as a result make it more backwards-incompatible for existing sites?

Besides, thats not the correct script type. The correct type (today, for this discussion, in this context) is type="language/javascript". However, there is widespread confusion and downright argument about what it really should be.

Those discussions are based around four variations of existing suggested correct types, not adding an entirely new html tag, which would be unsupported by all existing browsers, and cause backwards compatibility problems for authors of new code.

Bad idea. Lets get them just to standardize on an existing mime type based on the real-world implementations already fighting it out.
thinsoldier wrote:Now that we have prototype and similar libraries I think ECMA needs to have a look at the 2 most popular ones and start integrating all these brilliant, simple, time saving ideas into the next Javascript version and the w3c should remove <script> and add <javascript>
They won't be removing script, because we have about a dozen other really useful (and widely deployed) scripting languages using it. Not to mention, the w3c is already eating crow over being unrealistic with Xhtml to the point that they are now working on an html5 - they aren't likely to go in that direction again.

Adding javascript as a tag would be more likely, if it weren't likely to cause more confusion in an already confused market, and possibly cause new code authors more harm than good (see: xhtml). But in the end, I'd give up that dream. :)
thinsoldier wrote: ... although if the ecma doesn't do that, maybe the browser devs can impliment
<script type="javascript_lib:prototype:1.5">
<script type="javascript_lib:jquery:2.0">
etc. and make it standard practice for the browser itself to contain multiple stable versions the library files instead of having to download them over and over from site after site.

... or...
<javascript library="prototype" version="1.5">
<javascript library="yui" version="1.9">
They could, but they aren't likely to. The key gain would be faster caching, perhaps on the order of a couple seconds for most javascript libraries. Worse, that means they are the stewards of those files. If they are broken, compromised, have a security flaw, etc - does firefox then do an update for that library when they come out? Some of the larger libraries had almost weekly updates at various points.

Next there is the issue that then developers wouldn't target newer, better versions of those libraries - they'd be encouraged to use whatever shipped. And browser vendors would be encouraged to ship what everyone used - not newer versions. Not good for progress.

Of course, those are technical issues that ignore the very impossible licensing issue in many cases, where the vendor (Opera, IE?) could not ship those libraries legally.

And all that for a couple seconds gain in speed? Not likely.

Besides, for one of the examples you gave, all you have to do is point at the public version (Yahoo hosts a page specifically for their yui to speed up access to it). That way its up-to-date, offers multiple versions, lets the script author pay for the hosting and bandwidth, and so forth. Its really quite ideal as-is.
thinsoldier wrote: and maybe someday make it possible for multiple libraries to be used in the same page without conflicting with each other?
That depends on the scripts, and what they try to do. Thats not a language issue - thats a script issue. You *can* write scripts that can all run on the same page without conflict. Many can't because of what they try to accomplish. (As an example, you can write a replacement for document.onload, and then any function can use it - but you can't have multiple scripts do so).

Posted: Fri Oct 19, 2007 5:49 pm
by Kieran Huggins
According to The Crockford the type attribute is only required for valid xhtml, but should be left out entirely for HTML. He suggests "text/javascript" as well, so i don't know what to do anymore :(