Hvad olebole skriver er helt korrekt, dog vil jeg tillade mig at komme med en enkelt rettelse:
PHP er serverside(eksekverer PÅ serveren) og Javascript er clientside(eksekverer PÅ klienten). Hvad olebole skriver er reelt set det samme, men: Dog kan den sidste del af forklaringen til Javascript let misforstås: "kan intet gøre på serveren".
Dette er ikke helt korrekt. Godt nok eksekveres javascript jo ikke på serveren, men javascript kan jo via klientens netværkslag, requeste FRA serveren, og derigennem interagere med serveren uden at brugeren reelt set har foretaget et nyt request. Dette er et tvetydigt svar og egentlig ikke forkert hvis man skal betragte det ud fra din forklaring, men den er bare FOR simpel, da den kan lede til den misforståelse at Javascript er begrænset til kun at kunne manipulere med browseren.
Det er ikke korrekt. JavaScript kan intet på serveren og er netop begrænset til at manipulere med browseren.
Derimod kan brugeren via JavaScript få et XMLHttpRequest objekt (der som bekendt intet har med JavaScript at gøre) til at oprette en request mod serveren - men det er jo langtfra det samme, som at brugeren ikke 'reelt' har foretaget en request. Han har bare ikke brugt en HTML-form med efterfølgende sideskift - men det er heller ikke JavaScript, der foretager forespørgslen - og JavaScript gør intet på serveren.
Min forklaring er ikke for simpel - til gengæld er din for rodet ;o)
Så det du siger er at Javascript er begrænset til browseren, og at det via et object kan foretage et request og derved er det altså objektet der kan kommunikere med andet end browseren?
Så hvis jeg skriver en C# applikation som gør brug af nogle af de samme objekter(for eksempel DOM, filsystemet, SOCKETS(IP) etc.) så er mit C# program/applikation begrænset til min egen host, da det er et andet objekt der gør mig i stand til at læse og udpakke en XML fil fra en anden host?
Det at benytte et objekt som er del af et API betyder da om noget at det netop ikke er begrænset til en specifik applikation.
Derudover benytter jeg selv javascript til IDM, og det er absolut ikke i forbindelse med en browser. I så fald er IDM en hoax, og Javascripten ved IDM er blot til pynt. Men nu glemte jeg også at nævne at det jo egentlig ikke er en Javascript interpreter du gør brug af i en browser, men en ECMA script interpreter eller en Jscript interpreter. Så hvis nu jeg helt teoretisk set installerede en interpreter(for eksempel FESI), så er det ligepludselig ikke længere JavaScript(SUN har patent på JavaScript, derfor hedder det enten Jscript(microsoft) eller ECMAscript(ECMA foundation)) som denne interpreter fortolker?
KKrasmussen: Lad os lige få et par ting på det rene her. Jscript er Microsofts udgave af JavaScript som er så godt som identisk med ECMAScript som er den officielle standard. JavaScript er det navn ECMAScript havde (og har) i Mozilla(-baserede) browsere. JavaScript har intet med Java at gøre ud over at folkene på Netscape ville have noget af den buzz som Java havde dengang og derfor med Suns velsignelse kaldte deres afskyelige sprog for JavaScript. JavaScript er udelukkende et sprog og det kan implementeres i et hvilket som helst miljø. DOM er det API som browseren stiller til rådighed for JavaScript som køres i en browser, og det har for så vidt ikke noget direkte med JavaScript at gøre.
Igen har du ret i det meste af det du skriver, men mangler dog blandt andet, den lille detalje at vi alle er klar over hvad JavaScript er, men at JavaScript faktisk ER ejet af sun(navnet i hverttilfald). Dette har jo netop åbnet muligheden for at en spade ikke bare kaldes en spade, men også nogle gange en skovl(Jscript vs. ECMAscript).
Nej, JavaScript(i den form vi alle benytter til WEB programmering som script sprog til den indbyggede interpreter) har intet med sproget Java at gøre, men det har alt at gøre med Sun.
Det næste: Det ændrer bare ikke det faktum at JavaScript(bare for at holde os til det vi alle kender) sagtens kan være total browser uafhængig, og derfor kan bruges på nøjagtig samme måde som VB script, da de begge kan tilgå forskellige API'er og objekter. Og VB script er IKKE begrænset til kun at kunne benyttes til macro programmering eller login scripts. Den mest NORMALE måde at benytte JavaScript er blot igennem en browser og dennes Interpreter/fortolker. Men selv her kan man(igen ved at tilgå system objektet), kalde en applikation eller et script på klienten som gør noget uden browseren. Ja undskyld mig men så sort og hvidt anskuer jeg ikke programmering at jeg mener JavaScript ikke i webprogrammerings sammenhænge kan bruges til andet end client side programmering.
Jeg giver dig helt fuldstændig ret i at det netop ER client site EKSEKVERET. Men set i lyset af de fakta som jeg har fremlagt mener jeg stadig at JavaScript godt kan "gøre" noget på serveren. Derfor mente jeg dit udsagn var lidt FOR simpelt.
Ja, JavaScript kan bruges i alle mulige sammenhænge, men det, vi plejer at tale om i denne kategori, er websider, som afvikles i en browser =)
Ja, den version af XMLHttpRequest objektet, som bl.a. Mozilla's browsere bruger, er den version, som W3C er ved at udarbejde en ny standard for. Microsoft's version er en ActiveX kontrol - også selvom de med IE7 har lavet en wrapper, der ligner W3C's.
Ingen af delene har det ringeste med JavaScript at gøre, men kan - ligesom DOM - ligeså godt betjenes af f.eks. VBScript. Derfor er det heller ikke JavaScript, der gør noget på serveren - ikke engang XMLHttpRequest objektet gør noget på serveren! Ingen af delene er bare i remote nærhed af serveren. Kun sprog, der afvikles på serveren kan gøre noget på serveren!
Det ville svare til at påstå, at HTML kan udrette noget på serveren, hvis requesten i stedet var blevet foretaget via en HTML-form - og det, ville du jo til hver en tid (forhåbentlig) sige, er noget vrøvl ;o)
Det forventes at der svares på spørgsmålet og ikke på forudtagelser. Læs spørgsmålet igen og fortæl mig hvordan jeg skulle have den fjerneste chance for at vide at der menes i specifikt i forbindelse med web programmering.
Jeg så spørgsmålet som et overordnet spørgsmål, da det er defineret således. Hvis jeg har misforstået spørgsmålet har du min uforbeholdne undskyldning. :-)
kkrasmussen: JavaScript har altså ikke altså ikke alt med Sun at gøre. De har ikke som du påstår patent på det, de har ingen implementation, de har intet at gøre med udformning eller udvikling af sproget, de har kun et registreret Trade Mark, hvilket altså er noget helt helt andet.
Og for at gøre tingene endnu værre, så er JavaScript faktisk embedded i Java JRE (fra version), så man kan køre JavaScripts i alle sine applikationer, inkl. server apps. Til det bruges i øvrigt Mozilla Rhino (http://www.mozilla.org/rhino/) som _ikke_ er den fortolker som er i Firefox.
kkrasmussen >> Jeg ved ikke, hvad du forventer, men vi andre, som har brugt Eksperten længe, ved, hvad de forskellige kategorier anvendes til - og det er _ekstremt_ sjældent, der stilles spørgsmål i JavaScript kategorien (som i øvrigt også plejer at dække JScript), der ikke handler om JS til webbrug. De seneste 9 år tror jeg ikke, jeg har set 5 =)
schwarz84 >> Ja, JavaScript kan godt køre på en server, hvis fortolkeren er installeret. Der var ganske få, der brugte det i slutningen af 90'erne, men det slog aldrig rigtig an - og jeg tvivler på, man finder ret mange servere (om nogen overhovedet), hvor JavaScript anvendes. Men det _kan_ bruges ;o)
Det har muligvis fremgået som om jeg mente at JavaScript(i form a scriptsproget) var det Sun ejede, dette er en fejl. Jeg mente at de holder retten til navnet, og derfor er det principielt forkert at kalde det JavaScript, da det godt nok kaldes JavaScript, men er enten Jscript eller ECMAScript(som jo begge egentlig er "JavaScript". Forvirret? ;-) Det er jeg). Det OPRINDELIGE JavaScript som olebole kommer ind på er udviklet af Netscape i tidernes morgen, danner grundlag for ECMAScript. Men JavaScript er det ikke længere. Nok nærmere ECMAScript vers. 3.et-eller-andet. Derfor vil jeg være ked af at blive citeret for at sun "ejer" JavaScript, men kun for at de ejer navnet.
Vi kan godt blive enige om at jeg da også kalder det JavaScript, men at det stadig er pricipielt forkert at blive ved med at kalde det JavaScript. Sun kunne i morgen frigive et ligth scripting sprog til J2EEE appliikationer(eller noget andet) og give det navnet JavaScript, og så ville det være slut med at klade det JavaScript.
Jeg er af den overbevisning at når man begiver sig ind i den verden der hedder programmering, så skal man navigere forbandet sikkert når det er programmering af noget som ikke kun skal bruges af en selv. For man kan komme ud for en masse problemer ved at gøre dette. Et godt eksempel er billeder. Hvor mange af de fritids programmører du kender, har spurgt om lov eller indhentet tilladelse til at må benytte GIF som fil type til de billeder de bruger på deres hjemmeside? Jeg kender kun to. Men alligevel er det den mest benyttede filtyppe til billeder på private sites idag(eller næstmest, måske er jpg oftere benyttet), og ked af at må sige det, men .gif er licensbeskyttet, og ikke under en "fri" licens.
Bottomline er at JavaScript ikke er et sprog, det er et navn. Men begrebet JavaScript(Jscript/ECMAScript) er et scriptingsprog. Det er derfor jeg forsøger at dække mig ind når jeg svarer på et spørgsmål herinde, ved at prøve og slå fast at JavaScript(og altså ikke Javascript) er ejet af Sun.
Du må såmænd gerne kalde det ECMAScript, hvis det er, hvad du tænder på, men vi er stadig langt flere - herunder Mozilla, som vedligeholder sproget JavaScript - der kalder det java script: https://developer.mozilla.org/en/JavaScript
JavaScript _burde_ overholde ECMA standarden, men det gør det ikke - og er derfor ikke 'lig med ECMAScript'. Faktisk er JavaScript bagud i overholdelsen af ECMA i forhold til JScript.
Bottomline er, at du gerne vil gøre dig pokkers klog på noget, du ikke helt har tjekket ud! Dine 'akademiske' betragtninger er sikkert ganske sjove, men de har ikke hold i virkeligheden - og så er det jo så som så med det akademiske ;o)
kkrasmussen: Det er lidt fjollet at du bliver ved med at bringe endnu mere forplumring ind i debatten her. GIF-patentet udløb for 5 år siden og var kun på indkodning af filer, ikke på at anvende og læse filerne. Som almindelig web-designer var du dengang dækket af den licens som programmøren som havde lavet indkodningsprogrammet havde indhentet.
olebole: På hvilke måder er JavaScript forskellig fra ECMAScript? Jeg er aldrig støt på nogen forskelle og jeg ved at fx Chrome's V8 er implementeret direkte ud fra specifikationen (+ nogle konventioner som alle forventer overholdt).
Nu skal man for tiden nok passe lidt på med ordet 'specifikationen' i forbindelse med ECMA. De seneste par år har der raset en mindre 'krig' i og omkring organisationen. Man har mildt sagt ikke været enige om, hvordan en ny version af ECMAScript skal se ud =)
JavaScript 1.8 bygger således på ECMA 4, som allerede er forældet (forkastet), inden den er færdig. Dog har Mozilla ikke været så forhastede som Adobe med deres AS3, som har en del flere features implementeret, som er blevet skrottet fra ECMAScript.
Derudover skriver Mozilla selv i referencen, når properties og metoder ikke er del af ECMAScript. Alene object Object har således 10-12 nonstandard metoder.
Jeg er med på det med krigen, men den seneste eksisterende specifikation er ECMAScript 3 og den er stort set ens understøttet i alle moderne browsere. Selvom den er rent ud sagt elendigt skrevet, så er det dog en fast specifikation af sproget, så jeg ser ingen grund til at passe på med ordet 'specifikation'. ECMAScript 4 er i øvrigt tilsyneladende stendødt og jeg kan da også kun være enig i at man ikke skal ændre så meget på sproget. Vi har brug for et nyt sprog i stedet. Når jeg siger 'implementerer specifikationen', så tænker jeg på at implementationen indeholder alt hvad der står i specifikationen. Det er klart at alle browserne hver for sig også har implementeret noget mere. At have mere API en påkrævet er ikke som sådan en afvigelse fra specifikationen eller en forskel i implementationen af specifikationen browserne imellem. Selve sproget er også helt ens mellem browserne.
Jeg tror at vi er langt ud over hvad spørgeren spurgte om nu...
Der er nu også en del fejl og afvigelser fra ECMA forskellige steder i alle 'de store' browsere. Jeg har et dokument somewhere, hvor jeg har samlet en masse afvigelser - dels nogen, jeg selv er stødt ind i - og dels nogen jeg har fundet i noter og kommentarer.
En enkelt sjover fra hoften er:
<script type="text/javascript"> var sNoGo = "Dette er i strid \ med ECMA!"; alert(sNoGo); </script>
- hvilket er en decideret fejl i forhold til ECMA. Ikke desto mindre fejler både IE, FF og Opera (kan ikke lige teste i Safari på denne maskine) med glans
Hm. Må indrømme at min viden er kommet til kort her. Har en kursusafholder jeg skal have fortalt en ting eller to og have en hel del penge tilbage.
Jeg brugte hele aftenen på at undersøge det javascript snask. Jeg må bøje mig og desværre indrømme at omend jeg i mit daglige arbejde er totalt ligeglad med historien bag disse ting, trods alt havde modtaget kompendier og kursus materiale som understøttede mine påstande. Dette kursus materiale må jeg så sende tilbage konstruktiv kritik. Men intet er så skidt så det ikke er godt for noget, det betyder jo blot at det næste kursus bliver med en som ved hvad han faktisk snakker om, og de næste som får det udulige kursus materiale er fri for så kritiske fejl.
Ja, sådan ser verden desværre endnu ud. Teknologien er stadig meget ny, og der er ikke rigtig opstået en ordentlig faglighed, som det kendes fra mange andre fag.
Én forklaring kan være, at indlæringskurven for webkode er meget flad, og der derfor sidder en masse (næsten!) halvstuderede røvere med alt for store kasketter på.
En anden, at de, der sætter standarderne for uddannelserne, slet ikke er kompetente til at lave IT-uddannelser. Godtnok hører webintegrator uddannelsen til på laveste niveau i fødekæden, men det er da intet mindre end fantastisk, at W3C ikke er nævnt med ét eneste ord i Undervisningsministeriets bekendtgørelse om uddannelsen! For et lille årstid siden var jeg selv med til at planlægge nogle undervisningsforløb for webintegratorer på en teknisk skole og fik et shock, da det gik op for mig, hvor elendigt et grundlag, man forventes at undervise kommende webfolk på =8-O
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
Ny bruger
Nybegynder
Opret
Preview
