PHP on the client side of the browser
Moderator: General Moderators
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:
Would be enough to please me.
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>- RobertGonzalez
- Site Administrator
- Posts: 14293
- Joined: Tue Sep 09, 2003 6:04 pm
- Location: Fremont, CA, USA
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.
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.
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.
-
thinsoldier
- Forum Contributor
- Posts: 367
- Joined: Fri Jul 20, 2007 11:29 am
- Contact:
Re: PHP on the client side of the browser
Which is why I think it's time they dropped <script type="javascript">...</script> and just use <javascript>...</javascript>The Phoenix wrote: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?yacahuma wrote:Why do we keep using javascript? It is a terrible language in my opinion.
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)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 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?
- The Phoenix
- Forum Contributor
- Posts: 294
- Joined: Fri Oct 06, 2006 8:12 pm
Re: PHP on the client side of the browser
Just because its ubiquitous, we should change the way you reference it, and as a result make it more backwards-incompatible for existing sites?thinsoldier wrote: Which is why I think it's time they dropped <script type="javascript">...</script> and just use <javascript>...</javascript>
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.
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.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>
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.
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.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">
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.
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).thinsoldier wrote: and maybe someday make it possible for multiple libraries to be used in the same page without conflicting with each other?
- Kieran Huggins
- DevNet Master
- Posts: 3635
- Joined: Wed Dec 06, 2006 4:14 pm
- Location: Toronto, Canada
- Contact:
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 