allan ebdrup bloghoved ny

Aspx, Jsp og Php er dødt: Lav hele dit website i JavaScript.

Skørt?

Ja, det lyder som et skørt indfald, men lyt til min tossede idé, måske kan det sætte nogle tanker i gang hos dig.

Jeg foreslår at

  • Skifte alle dine Aspx-, Jsp- eller Php-sider ud med .html sider
  • Lave hele den dynamiske del af præsentationen af dit website i JavaScript. Dvs. generering af html udfra data, der fx kommer fra en database.
  • Lad den eneste kommunikation med webserveren være:
  • - Download af statisk indhold. Dvs. JavaScript, Css, billeder og .html filer
  • - Webservice eller Rest, kald der kun returnerer rå dynamisk data, enten som JSON eller som XML
  • Brug stadig inkluderede Css-filer til at syle dit website

Hvorfor?

Der er følgende fordele ved denne metode:

  1. Du bliver mere uafhængig af miljøet på din server, da du kun har lidt forretningslogik og nogle webservices på den, dvs. det bliver nemmere at skifte mellem dotNet, Java, PHP eller Python, som fx Google apps kører med (Java support er vist lige kommet).
  2. Ovenstående fordel kan du udnytte til nemmere at få din applikation ud i skyen.
  3. Når du har din applikation i skyen, bliver du mindre afhængig af din sky-hostingprovider, da du nemmere kan skifte til en sky-hostingprovider, der benytter en anden teknologi. Når du skifter, behøver du nemlig ikke omkode dit JavaScript.
  4. Skalerbarheden og performance på dit website bliver større, da klienten kan cache dit JavaScript og kun skal downloade nyt indhold. Derudover skal din webserver ikke bruge energi på at generere html.
  5. Du får bedre mulighed for at styre browserens cache, du kan sætte cache expires til uendeligt på dit JavaScript og styre at klienter skal genloade, ved at versionere filnavnet på filen med JavaScriptet.
  6. Du får større udbytte af et Content Delivery Network (CDN), dvs. et netværk af geografisk spredte servere, der leverer dit statiske indhold med høj hastighed, uanset hvor i verden brugeren sidder. Grunden til at du får større udbytte er, at dit JavaScript og dine .html-filer kan ligge på dit CDN.
  7. Metoden giver også en unik mulighed for at flytte dynamiske data, der ikke ændrer sig voldsomt ofte, op på dit CDN og udnytte browserens cache optimalt. En mulighed du kun har med JavaScript. Specielt hvis du tækker data fra flere kilder til siden, kan du få nogle fordele. Det kunne fx være en blog, hvor der både er selve blogindlægget og længere nede kommentarer. For at forklare dette nærmere, vil jeg snart publicere et separat blogindlæg om emnet.
  8. Du skal alligevel lave en del JavaScript for at implementere AJAX-kald på dit website. Det er noget smukkere, at hele din frontend ligger i én teknologi, i stedet for både JavaScript og C#, Java eller Php.
  9. Fremtidens websites bliver alligevel så dynamiske, at den eneste måde at lave dem på, er at programmere dem.
  10. Alle websites i dag har så meget AJAX og dynamisk html, at der alligevel ikke er nogen der, kører med JavaScript slået fra.

Der findes allerede en masse tiltag til at lave WYSIWYG-editorer i browseren, som genererer output via JavaScript i stedet for html. Nu mangler vi bare at disse værktøjer bliver bedre, og vi får et stort widget-bibliotek og et udviklingsmiljø, der har intellisense, som selvfølgelig også er skrevet i JavaScript og kører i browseren.

Udfordringer ved løsnigen

Der er nogle udfordringer ved løsningen, men dem vil jeg ikke røbe. Jeg håber at du kan bidrage med dem.

Hvad siger du til det?

Skal du hjem og omkode dit website? Følg fortsættelsen i mit blogindlæg 'JavaScript og CDN i skøn forening' snart.

Kommentarer (117)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Henrik Schmidt

Svarer det ikke til en (mere arbejdskrævende) form af rige klienter? Fx. GWT, hvor du laver det hele i Java, som derefter bliver kompileret til browseruafhængig JavaScript. Eller Adobe Flex, hvor du laver det hele i MXML og Action Script, som derefter bliver kompileret til noget, som Adobe Flash VM'en kan forstå. Jeg formoder Silverlight fungerer tilsvarende.

  • 0
  • 0
Allan Ebdrup

Tja, det er at ligge hele håndteringen af generering af HTML ud på klienten, så klienten bliver ihvertfald tykkere. GWT er et tool du kunne bruge til at implementere ovenstående.
Nu er det mere arbejdskrævene, men lur mig om der ikke kommer bedre tools snart.
Normalt bliver teknikken kun brugt til at lave små AJAX widgets på et normalt website. Det nye er at jeg foreslår at bruge det til hele dit website, i stedet for dit aspx, jsp eller php. Det bliver specielt attraktivt hvis du skal flytte applikationer ud i skyen.
Jeg tror de færreste har lyst til at hele deres website ligger i flex eller silverlight, om ikke andet så fordi du er i lommen på Adobe/Microsoft, men det er en anden diskussion.

  • 0
  • 0
Anonym

Jeg tror ikke, at du har ret ang. performance. I dit skitserede eksempel: Hent statisk side > javascript http-kald til webservice > parsing af xml/json > update af DOM. Dvs. mindst to http kald, samt en tidskrævende parsing/DOM manipulation (alt efter data og CPU på klienten). Det vil være meget hurtigere at genere den færdige side på serveren. Det vil også være langt simplere og du undgår problematikken om cross-domain http-kald. Jeg mener, at det handler om at vælge den rigtige løsning til hver enkel side. Din metode bruges jo i dag af rigtig mange sites hvor det giver mening, som fx sider, der asynkront skal opdateres.

Derudover er serverside sprog ikke døde. Du skal stadig skrive dine web-services. Der kan du jo så selvfølgelig vælge Javascript.

  • 0
  • 0
Henrik Schmidt

Nu kender jeg ikke lige til GWT, men både Flash og Silverlight kræver at du har installeret et separat plugin for at virke, og kræver derfor noget ud over browseren, hvilket ren javascript ikke gør.

GWT (Google Web Toolkit) kræver ikke andet, end at browseren forstår javascript.

Jeg forstår bare ikke helt, hvad det nye er. Det er klart, at man i princippet kan blive mere uafhængig af sin serverteknologi ved at bruge XML/JSON-webservices, men det er vel bare en af pointerne ved webservices?

  • 0
  • 0
Emil Refn

Sådan som jeg forstår det så når du laver din hjemmeside, så laver du blot et skelet, og dit javascript. Derefter laver du dine webservices der returnere alt indholdet til klienten i form af JSON/XML når den beder om det, som så bliver lagt ind de rigtige steder af dit javascript. Du bruger altså ikke direkte dit serverside sprog til at generere (x)html.

  • 0
  • 0
Christian Melchior

Selvom det lyder fristende er der dog nok et par småting man lige skal overveje først:

  • Inputvalidering: Du slipper ikke for inputvalidering på serversiden, så ved større applikationer er det måske begrænset hvor let du kan gøre serveren.

  • Cross-browser problemer: Slipper du ikke for ved at flytte det hele til JavaScript (selv ved brug af Prototype, JQuery etc.)

  • Javascript som sprog: Det har både fordele og ulemper, men velegnet til store programmer kan man næppe kalde det. Uden pakkestyring og statiske typer skal man være yderst struktureret for ikke at få problemer.

  • 0
  • 0
Anonym

Jeg forstår ikke argumentet med caching (Punkt 5). Det er da ikke mulighed, men en nødvendighed ved den metode. Hvis du lader din web-server kalde dine web-services, har du mere styr på cachingen, som vil ske server-side i stedet for i brugeren web-browser. Ved at levere færdige, statiske sider (som kan være cached på serveren), behøver du ikke at bekymre dig om client-side caching.

  • 0
  • 0
Emil Refn

Inputvalidering: Du slipper ikke for inputvalidering på serversiden, så ved større applikationer er det måske begrænset hvor let du kan gøre serveren.

Du bør altid lave input validering på server siden, også selvom du gør det via javascript hos klienten, simpelt hen fordi det er muligt at lave fake http kald.

Javascript som sprog: Det har både fordele og ulemper, men velegnet til store programmer kan man næppe kalde det. Uden pakkestyring og statiske typer skal man være yderst struktureret for ikke at få problemer.

Med PHP skal du jo også være meget struktureret, det er også typeløst.

  • 0
  • 0
Henrik Schmidt

Tja, det er at ligge hele håndteringen af generering af HTML ud på klienten, så klienten bliver ihvertfald tykkere. GWT er et tool du kunne bruge til at implementere ovenstående.
Nu er det mere arbejdskrævene, men lur mig om der ikke kommer bedre tools snart.

Der vil jeg så påstå, at GWT og Flex er bedre tools, selvom jeg personligt ikke er den helt store fan af GWT.

Normalt bliver teknikken kun brugt til at lave små AJAX widgets på et normalt website. Det nye er at jeg foreslår at bruge det til hele dit website, i stedet for dit aspx, jsp eller php. Det bliver specielt attraktivt hvis du skal flytte applikationer ud i skyen.

Både i Flex, Silverlight og GWT er idéen, at lave hele sider i teknologien. Der ud over kan man, i GWT og Flex tilfælde vælge, hvordan man kommunikerer med serveren (kender ikke silverlight).

Jeg tror de færreste har lyst til at hele deres website ligger i flex eller silverlight, om ikke andet så fordi du er i lommen på Adobe/Microsoft, men det er en anden diskussion.

Mht. Flex, så er det temmeligt Open Source, så det er begrænset, hvor meget i lommen på Adobe, man er. Udover det, så har jeg indtrykket af, at der er en del .NET programmører i Danmark, så nogle virksomheder må allerede have taget den tilsvarende beslutning ifb. Microsoft :)

  • 0
  • 0
Allan Ebdrup

@Martin Høgh
Performance er jo en ret avancered ting. Men et ekstra http-kald gør ikke den store forskel, hvert billede på siden er et http-kald og en webside bliver ikke væsentligt langsommere af at tilføje eet billede.
Parsing af Xml/Json: foregår i millisekunder.
Update af DOM: arbejdsbyrden kan sammenligned med den serveren skal lave for at generere HTML'en, nu kører det bare på klienten i stedet.
Og jeg er uenig i at det er hurtigere at generere HTML'en på serverne, sende den HTML'en som tekst til browseren, og så få browserne til at parse HTML'en og opbygge DOM'en.
Performance på dit website bliver ikke afgjort af ovenstående faktorere, det der virkeligt batter er hvor meget af dit indhold klienten har i cache når den browser rundt på dit site. Og for internationale sites er det ultra vigtigt at så meget som muligt ligger i et CDN.
Det betyder rigtigt meget for performance hvis dit JavaScript ligger i cache.
Derudover kan du også lave caching af dine webservicekald. Så du får en finkornet cache styring, hvor hver datakilde kan konfigureres seperat.
Det kunne for eksempel være denne side, hvor datakilden der henter selve blog indlægget har en lang cache-expires på klienten, mens datakilden til kommentarene har en kortere cache-expires.
Jeg lover dig for at du ville kunne se en bedre performance, hvis det eneste du skulle hente for at se det svar jeg skiver nu, var kommentarene som data.

  • 0
  • 0
Allan Ebdrup

[quote]
Jeg forstår ikke argumentet med caching (Punkt 5). Det er da ikke mulighed, men en nødvendighed ved den metode. Hvis du lader din web-server kalde dine web-services, har du mere styr på cachingen, som vil ske server-side i stedet for i brugeren web-browser. Ved at levere færdige, statiske sider (som kan være cached på serveren), behøver du ikke at bekymre dig om client-side caching.
[/qoute]
Du SKAL bekymre dig om client side caching, det er en af de allervigtigste features til at få sit website til at sprøjte afsted fra brugerens synspunkt. Derfor kan du selvfølgelig stadig cache på serveren, det gør du oveni hvis det giver mening. Når det er en JavaScript løsning cacher du svarene fra dine webservices hvis det giver mening.
Du kan ikke styre cachen særligt godt når du sender hele HTML-dokumentet afsted.
Hvad gør du med serverside cache af en html side siden ændrer udseende når en bruger logger ind? Eller hvis den som på denne side har kommentare der ændrer sig hele tiden? Der er ganske vist nogle features i fx dotNet til at cache dele af en side, men det er ofte noget rod, og cachen virker kun på servern. Hvis du skal have performance der batter skal du styre klientens cache.

  • 0
  • 0
Allan Ebdrup
  • Inputvalidering: Du slipper ikke for inputvalidering på serversiden, så ved større applikationer er det måske begrænset hvor let du kan gøre serveren.

Korrekt, din inputvalidering skal ske på serveren, nu plejer inputvalidering til et webservice kald jo ikke at være den største del af at udvikle.
Til gengæld får dit website en komplet service enabling så andre måske kan integrere med dit website.

  • Cross-browser problemer: Slipper du ikke for ved at flytte det hele til JavaScript (selv ved brug af Prototype, JQuery etc.)

Hvis du bare skal generere HTML, attache events og kalde webservices er problemerne minimale.

  • Javascript som sprog: Det har både fordele og ulemper, men velegnet til store programmer kan man næppe kalde det. Uden pakkestyring og statiske typer skal man være yderst struktureret for ikke at få problemer.

Vi taler ikke om store programmer, hvor meget kode ligger der i en normal aspx, jsp eller php side? Men det kunne være rart med nogle bedre udviklingsmiljøer til JavaScript.

  • 0
  • 0
Anonym

Ja, hvis de ligger på samme domain, så er der ikke noget problem, men ideen er vel, at en webservice kan bruges af flere forskellige sites eller ligge på en anden http-server end den som serverer de statiske html/javascript sider? Det kan selvfølgelig løses med et proxy-script på den sidst nævnte server.

  • 0
  • 0
Jacob Larsen

Der er vel ikke nogen robotter der eksekverer javascript og slet ikke ajax baseret.
Så dette er en god måde at undgå at blive set i google:-(
Desuden er der en masse mennesker der går og snakker om semantisk web. Dette er vel et godt skridt i den forkerte retning.

  • 0
  • 0
Baldur Norddahl

Jeg har overvejet at opbygge et website på denne måde og lige præcis Google var årsagen til at jeg droppede det.

Der går nok en rum tid inden Google regner ud at indeksere javascript-generede sider og hele ideen falder på det.

Men må nøjes med at bruge teknikken til de dele af websitet som ikke behøves indekseres (indkøbskurv og lignende).

  • 0
  • 0
Jacob Larsen

Tak for de 10.

Google burde vel kunne crawle javascript genereret af Google Web Tool kit?????

Hvis du gerne vil udnytte klienterne lidt bedre, kunne man jo lade sine websider bestå af client-side xslt transformerede XML dokumenter. Hvis disse var lavet efter nogle enkelte semantiske regler, kunne vi jo prøve at opdrage google og de andre til at læse dette.
Regler kunne være simple.
* links i en link sektion af XML dokumentet (Så kan google stadig lave page ranking)
* Nanve / adresser / events mm. i standard formater, og trukket ud i relevante sektioner af dokumentet, så google kunne om det er Jacob Larsen der har skrevet dette, eller om der er nogle der skriver om Jacob Larsen.

  • 0
  • 0
Anonym

"Der går nok en rum tid inden Google regner ud at indeksere javascript-generede sider og hele ideen falder på det."

Viser vel, man ikke har forstået, hvad det handler om, når man tænker søgemaskiner som det allerførste, fremfor ens brugere. Selv Google, hvis de en dag skulle understøtte javascript, anbefaler, man tænker brugerne først.

Hvad gavn har du af en indeksering, hvis dine brugere ikke kan se din side, fordi de er blinde eller af sikkerhedsgrunde har slået Javascrippt fra?

Hvad med mobiltelefoner?

Eller andre media, som ikke understøtter javascript?

Dårligt, dårligt forslag, som jeg absolut ikke håber spreder sig. Det er IKKE at tænke på sine brugere.

Så kan man lige så godt lave sine hjemmesider i PDF, som visse steder har været foreslået.

Hjemmesider skal laves med HTML til mark up, javascript er til funktioner ikke til sideopbygning eller styling.

Og med funktioner, så mener jeg: Siden skal kunne fungere, navigeres, læses og forstås UDEN javascript. Og iøvrigt også uden CSS. Javascript skal assistere de allerede indbyggede funktioner, og dermed hjælpe brugeren.

Arg modstander af hele denne idé, og ligeså stor tilhænger af unobtrusive scripting.

  • 0
  • 0
Jacob Larsen

Viser vel, man ikke har forstået, hvad det handler om, når man tænker søgemaskiner som det allerførste, fremfor ens brugere. Selv Google, hvis de en dag skulle understøtte javascript, anbefaler, man tænker brugerne først.

Du har gode pointer med mobiltlf, læsbarhed mm. Jeg arbejder på et universitets bibliotek og mine brugere finder ting gennem google. Hvis mine sider ikke findes via google har jeg ingen brugere. Derfor er det at tænke på brugerne når jeg mener at google indeksering er vigtig.

  • 0
  • 0
Anonym

"Derfor er det at tænke på brugerne når jeg mener at google indeksering er vigtig."

Din argumentation er bagvendt.

Du bliver indekseret, fordi dine brugere kan lide dine sider, og fordi de derfor linker til dig. Hvis ikke de kan læse dine sider, kan de heller ikke afgøre, om de kan lide dem. Altså ingen links.

Godt indhold har aldrig kunnet slå ren SEO. fordi godt indhold ALTID vil blive indekseret godt.

I hvert fald i Google, om ikke andet.

Tænk på dine brugere, lav indhold efter dem og du vil få en god indeksering.

Google har været meget klar på det punkt i mange år, og iflg. deres seneste informationer, er det noget de vil stå ved mange år endnu.

Hvis du er i tvivl, om det er korrekt, hvad jeg skriver, så lav en statistik over, hvor mange besøgernde der er på din side, og så hvor mange som i virkeligheden er interesseret i indholdet. Det er de sidste, som tæller.

Jeg kan se det af min egen side, der er faktisk en del besøgende, men (og det ved jeg godt) en del indhold sutter fordi det ikke er lavet færdigt eller er dårligt formuleret eller har faktuelle fejl. Plus at indholdet er dårligt struktureret. Så fint med Google, jeg har høj placereing (faktisk rigtigt højt på mine søgeord), men mange forlader altså også siden fra index-siden.

  • 0
  • 0
Anonym

Hmmm. Jo, jeg er nok inde i noget med hønen og ægget, men altså...

SEO, (for selvfølgelig skal man også lave søgeoptimering) skal foregå udfra brugernes krav, ikke udfra søgemaskinernes krav. Det er nok bare det.

;)

Men... efter de seneste meldinger, så tyder det på, at Google Bot godt kan parse javscript. Jeg er i tvivl, om det er en "gimmick" fra Google, eller om det er reelt.

For hvis Google kan, vil det vel i princippet også være muligt at lave teknologier for blinde, som kan læse tekst genereret af JS. Her er det nok mere læseretningen og inddelingen af teksten i de rigtige strukturer, som kan blive et problem. I øjeblikket bruger JAWS f.eks. alene HTMLen og ikke andet.

Noget andet er AJAX, som så vidt jeg ved kun én mobilbrowser understøtter (kan ikke huske navnet). Men det er så muligt at lave.

  • 0
  • 0
Anonym

Jeg kom til at tænke på en ting.

Nu er jeg ikke helt klar over, hvor meget du ville bruge javascript til indholdsgenerering.

Men hvis man laver sin side udelukkende i AJAX, så forsvinder brugerens muligheder for at se i adressefeltet, hvor han er vel også? Og hvordan med bogmærkning?

  • 0
  • 0
Allan Ebdrup

Hvad gavn har du af en indeksering, hvis dine brugere ikke kan se din side, fordi de er blinde eller af sikkerhedsgrunde har slået Javascrippt fra?

De blinde kan skam godt bruge siden selvom den er genereret af JavaScript, den bliver stadig præsenteret som HTML.
Hvis du har slået JavaScript fra duer det ikke, så hvis du vil have fat i den målgruppe dur det heller ikke, men dem bliver der færre og færre af. Jeg prøvede lige for sjov at gå på facebook med JavaScript slået fra, man kan ikke registrere sig og man kan ikke poste en statusopdatering.

Hvad med mobiltelefoner?
Eller andre media, som ikke understøtter javascript?

10 point, det var også en af ulemperne jeg ledte efter. Men mon ikke vi kan løse det?

Hjemmesider skal laves med HTML til mark up, javascript er til funktioner ikke til sideopbygning eller styling.

Tja, forslaget bruger stadig HTML til præsentation, det er bare genereret af JavaScript. Styling er med Css. Men det er nok fornuftigt at adskille det.

JavaScript der generere siden fra resten.
Og med funktioner, så mener jeg: Siden skal kunne fungere, navigeres, læses og forstås UDEN javascript. Og iøvrigt også uden CSS. Javascript skal assistere de allerede indbyggede funktioner, og dermed hjælpe brugeren.

Ja det er der mange der siger, men hvorfor? Er det fordi man skal understøtte at folk har JavaScript slået fra? Så kan man vel lave en fallback-løsning hvor det JavaScript der generere siden køres på serveren i disse 0.001% af tilfældene.
Er det fordi Google ikke kan indeksere? Det må vi da kunne løse. Andre grunde?

  • 0
  • 0
Allan Ebdrup

Det er ikke sikkert at man ønsker at klienten skal besidde alt det data (fra databasen) der er nødvendigt for at generere det der skal vises til brugeren...

Det tror jeg lige du skal komme med et konkret eksempel på.
Umiddelbart vil jeg sige at dette netop er en fordel, for hvis du har sådan noget kode i din aspx-side er det nok fordi du har fået puttet noget forretningslogik ned i dit view. Når siden genereres af JavaScript tvinges du også til at lave en meget skapere opdeling af forretningslogik og præsentation. Ville det ikke være dejligt at vinke farvel til alt din forretningslogik i dine aspx-sider og få lagt det op i dit class library? Her menere jeg selvfølgeligt alt det forretningslogik de andre udviklere har lagt der ;-)

  • 0
  • 0
Allan Ebdrup

Men hvis man laver sin side udelukkende i AJAX, så forsvinder brugerens muligheder for at se i adressefeltet, hvor han er vel også? Og hvordan med bogmærkning?

Sidenavigering ændres der ikke ved, du har nøjagtigt de samme links som før og reloader siden som før, forskeller er blot at nu hedder sidene .html i stedet for .aspx/.jsp/.php

  • 0
  • 0
Allan Ebdrup

Men... efter de seneste meldinger, så tyder det på, at Google Bot godt kan parse javscript. Jeg er i tvivl, om det er en "gimmick" fra Google, eller om det er reelt.

Smukt, så skal vi bare have en fallback-løsning til mobiltelefoner og andet uden JavaScript, så kører vi!
Andre ulemper?

  • 0
  • 0
Anonym

OK, så det er kun selve indholdet, som vises med javascript?

Noget er jeg godt inde i hvad amgår kode, men på nogle punkter er jeg lidt en teknik-noob (eller hvad det hedder), og det gælder lige her Javascript, så:

Hvor meget af indholdet ville du så have skulle være Javascript, og hvor meget AJAX? Og hvor meget HTML?

Det, jeg er skeptisk overfor, er jo ikke, hverken brugen af Javascript eller AJAX, men hvordan det bruges.

Kunne du overføre idéen til denne side v2.dk f.eks.?

  • 0
  • 0
Anonym

"Smukt, så skal vi bare have en fallback-løsning til mobiltelefoner og andet uden JavaScript, så kører vi!
Andre ulemper?"

Nu skriver du fall-back... det ændrer 100% det hele. I hvert fald for mig. En fallback-løsning vil kunne forsvare rigtigt meget. Det er faktisk alfa og omega ved unobtrusive scripting, så...

Men ang. at Google kan parse Javascript. Hvis du ser denne video, vil du måske også være lidt i tvivl om, hvordan det skal tolkes (det er så i en lidt anden sammenhæng, men meningen er klar nok: Vi kan parse Javascript, hvornår vi vil):

http://www.youtube.com/watch?v=Wzu9mUJj9GU

  • 0
  • 0
Allan Ebdrup

Hvis du gerne vil udnytte klienterne lidt bedre, kunne man jo lade sine websider bestå af client-side xslt transformerede XML dokumenter.

Ja det er også en mulighed, men det er vigtigt at du lader JavaScript hente din XML fra webservices, så du får finkornet caching. Om du så bruger XSLT til at omformere til HTML er et valg man kan tage som man nu lyster, hvis du er XSLT-haj er det nærliggende. Jeg ved ikke hvordan XSLT-understøttelsen er på de forskellige platforme og browsere?

  • 0
  • 0
Martin Høgh

@Allan Ebdrup Du spørger om andre ulemper, men jeg er ikke overbevist om fordelene. For hvem er fordelene så indlysende, at de burde skrotte deres CMS og starte forfra? Hvilke fordele har fx Version2.dk ved oplægningen og hvad vil det koste? Er der ikke forskel på et dansk IT-magasin og Facebook?

  • 0
  • 0
Allan Ebdrup

jeg er ikke overbevist om fordelene. For hvem er fordelene så indlysende, at de burde skrotte deres CMS og starte forfra? Hvilke fordele har fx Version2.dk ved oplægningen og hvad vil det koste? Er der ikke forskel på et dansk IT-magasin og Facebook?

Ja nu er det jo ment som en provokation, der er helt sikkert ikke økonomi i at gøre det for alle websites.
Fordelene har jeg opremset i artiklen, dertil kommer at du får en pænere separation af forretningslogik og du får nogle unikke muligheder med et CDN som jeg vil komme ind på i et senere blogindlæg.

  • 0
  • 0
Allan Ebdrup

Nu skriver du fall-back... det ændrer 100% det hele. I hvert fald for mig. En fallback-løsning vil kunne forsvare rigtigt meget. Det er faktisk alfa og omega ved unobtrusive scripting, så...

Det tricky er at få skruet sin fallback sammen så den er helt seperat fra resten af dit website; så du stadig kan høste de fordele der ved nemmere at komme ud i skyen og senere flytte sky-hostingprovider.

  • 0
  • 0
Anonym

Nu kan jeg så godt se, det måske er lige i overkanten teknisk, noget af det, i skriver her, så måske har jeg ikke forstået alt, du/i vil. Men det hele kommer vel af, hvad man vil opnå som resultat, og hvilke muligheder man har.

Hvis det man vil kun kan laves med teknologier, som ikke pt. er tilgængelige for alle, må det være populariteten, som afgør, om der senere kommer en mulighed for f.eks. folk med handicaps, eller om idéen dør.

HTML var bestemt heller ikke brugervenligt i starten. Ingen semantisk betydning, ingen logik andet end farver og skriftstørrelser, som jo ikke kan forstås af blinde. For ikke at sige frames og tabeller-i-tabeller-design..

Men det afhænger også af, om resultatet kan laves på anden måde, som er mere tilgængelig, eller om du kun har de (altså utilgængelige) muligheder.

Jeg tror, én nævnte det rigtige værktøj til opgaven, kan bare ikke finde indlægget. Men for nu vil jeg sige, en hjemmeside laves mest tilgængelig, principielt også mest brugervenlig, og følgelig med mulighed for at nå flest, med de standarder for webdesign, som er oficielle. Altså HTML til mark-up, CSS til styling og javascript som et lag ovenpå disse med funktioner.

Men klart, det vil være dumt at afvise, som eksemplet med Skyfire, der ikke kan dukke teknologier op, som kan forsvare en ... skal vi sige ikke-standard-løsning, som senere kan danne standard.

Samtidig kan der jo opstå behov, som ikke kan dækkes af de tilgængelige metoder vi bruger nu, som sagt..

Mere ville jeg, (og her er jeg nok enig med dig i en eller anden grad), at man forskede mere i de hjælpemidler, som bruges til blinde og andre handicappede, så deres teknologi også fulgte med. de forskellige teknologier skulle meget gerne følges lidt ad.

Jeg mener jo, at nettet skal være for alle uanset alder, race, køn eller handicaps. Men samtidig ser jeg nødigt, det står stille, fordi en ny idé ikke lige kan nå 100%, det ville jeg bestemt også være ked af. Så det er lidt en balancegang.

  • 0
  • 0
Allan Ebdrup

Men for nu vil jeg sige, en hjemmeside laves mest tilgængelig, principielt også mest brugervenlig, og følgelig med mulighed for at nå flest, med de standarder for webdesign, som er oficielle. Altså HTML til mark-up, CSS til styling og javascript som et lag ovenpå disse med funktioner.

Jeg ved ikke om der er nogle oficielle standarder der direkte siger at HTML'en ikke må genereres af JavaScript. Det har dog i lang tid været god latin at dit site skulle fungere uden JavaScript. Det er det jeg udfordrer lidt og peger på de ret store uhøstede potientialer, der forbliver uhøstede så længe man holder sig til den doktrin. Måske kunne man lave noget intelligent fallback, der stadig gjorde det muligt at lave sit site som jeg skriver i indlægget. Altså afhængigt af JavaScript for den almindelige bruger. Det er ihvertfald noget man bør tænke over, derfor den provokerende titel.

Du kan godt tilgodese folk med handikap selvom du generere HTML med Javascript. Fx AJAX frameworket Bindows, der opfylder den amerikanske Section 508
http://www.bindows.net/508/

  • 0
  • 0
Anonym

"Du kan godt tilgodese folk med handikap selvom du generere HTML med Javascript. Fx AJAX frameworket Bindows, der opfylder den amerikanske Section 508
http://www.bindows.net/508/"

Det må jeg sige... du har da gjort dit hjemmearbejde.

Tak mange gange for det link, ender vel med, jeg installerer Jaws bare for at prøve, he.

Meget værdifuld viden, helt sikkert. Og det udrydder jo en ret dyb barriere, vil jeg mene.

;)

  • 0
  • 0
Anonym

Et par ting har jeg dog.

Det er et framework, og egentlig er jeg ikke så meget for sådan noget, da det altid kræver mere indlæst, end der bruges.

På den anden side, kan jeg sagtens se et større firma bruge det, i og med, man sjældent (formentlig aldrig) har tid til at lave alt fra grunden.

Det svarer vel meget godt til at bruge et CMS i stedet for at kode hver enkel side i hånden (OK, meget groft sagt).

Så... jeg tror ikke idéen vil virke alle steder, men hvor det er nødvendigt at man ikke går ned i mindste detalje, f.eks. en stor avis, der kan jeg se en fordel. Specielt hvis det samlede resultat ikke nødvendigvis er valid kode, men stadig tilgængelige websider.

Noget andet er, at når der er lavet et framework, så må det også være muligt selv at splittte delene op, og lave de nødvendige funktioner, så det passer til ens eget site (altså lave helt egne funktioner udenom frameworket). Frameworket er vel stadig lavet i JS, formoder jeg.

Til sidst, så... ja, jeg er altså af den gamle skole, og jeg ville have uendeligt svært ved at skulle hive både styling og mark up samt funktioner ud af et javascritpt eller en javascript-generator (som et framework vel er). Så jeg ville nok aldrig bruge det, alene fordi jeg skulle først lære et helt nyt sprog, dernæst hvis jeg så skulle følge de skitserede idéer for kodning, skulle lægge min kodestil 180 grader om, fordi jeg er vant til at separere tingene fuldstændigt.

Det ville nok være i overkanten.

Men... måske andre, og engang i fremtiden.

  • 0
  • 0
Martin Høgh

Ja nu er det jo ment som en provokation, der er helt sikkert ikke økonomi i at gøre det for alle websites.

Ja, det fornemmer jeg. Provokationen må så bestå i, at du outliner en metode, som går i mod xml/xslt tænkegangen i fremtidens "semantic Web".

Hvis du lader din web-server foretage xslt-tranformationen af xml'en istedet for javascript i browseren og serverer en ren html-side til browseren, har du samtidig klaret de problemer, der er med asynkron loading af indhold i browsere (som dokumenteret i tidligere indlæg). I fremtiden, når browsere bliver bedre til xslt og der kommer semantiske søgemaskiner, så kan vi jo også skippe html-endelserne. Så brug tiden på at skrive xslt-filer i stedet for gammeldags html/javascript templates. Kør dem på serveren i dag og flyt dem ud i browseren i morgen.

  • 0
  • 0
Allan Ebdrup

Ja, det fornemmer jeg. Provokationen må så bestå i, at du outliner en metode, som går i mod xml/xslt tænkegangen i fremtidens "semantic Web".

Jeg kan ikke lige se hvorfor det semantiske web kræver at du benytter xslt? Kan du forklare?

Kør dem på serveren i dag og flyt dem ud i browseren i morgen.

Hvis jeg ikke tager meget fejl kan du allerede i dag køre xslt i IE, så flyt det ud i dag.

Men for at høste de fordele jeg opremser skal du have en webservice for hver datakilde på din webside, det er vigtigt for at få finkornet caching af dine datakilder.

Jeg tænker man kunne hente sit xslt via en webservice?

  • 0
  • 0
Allan Ebdrup

Til sidst, så... ja, jeg er altså af den gamle skole, og jeg ville have uendeligt svært ved at skulle hive både styling og mark up samt funktioner ud af et javascritpt eller en javascript-generator (som et framework vel er). Så jeg ville nok aldrig bruge det, alene fordi jeg skulle først lære et helt nyt sprog, dernæst hvis jeg så skulle følge de skitserede idéer for kodning, skulle lægge min kodestil 180 grader om, fordi jeg er vant til at separere tingene fuldstændigt.

Ja, jeg er måske lidt vel tidligt ude med min profesi. Og det jeg foreslår skal pt nok kun prøves af folk der kan lide at eksperimentere. Jeg kan godt forstå du venter til der kommer bedre tools. Men teknologi flytter sig hele tiden og vi alle flytter med :-)

  • 0
  • 0
Anonym

Mit udsagn: "Javascript skal assistere de allerede indbyggede funktioner, og dermed hjælpe brugeren."

Som allan svarer på:

"Ja det er der mange der siger, men hvorfor? Er det fordi man skal understøtte at folk har JavaScript slået fra? Så kan man vel lave en fallback-løsning hvor det JavaScript der generere siden køres på serveren i disse 0.001% af tilfældene.
Er det fordi Google ikke kan indeksere? Det må vi da kunne løse. Andre grunde?"

Primært, så er det ikke helt sådan der tænkes, men du er alligevel inde på noget af det. Man inddeler det i 4 lag, og hvor hvert lag lægger noget selvstændigt til, sådan

1+2. Først har man indholdet, teksten, råt, ingen opmærkning. Man mærker så op, fordi så kan man se, hvad der er hvad. Det er også strukturen det gælder.
3. Man styler med CSS (som er for seende mest)
4. Man lægger funktioner på

For det første, så viser man her, at man har fokuseret på indholdet, fordi det er det første. Hvis hver del slås fra, kan man stadig navigere siden. Indholdet er fuldt forståeligt. Det gør det nemt at vise siden i hvilketsomhelst medie, som bare fatter HTML.

Samtidig kan hvertt lag 2-3 afprøves og fejlfindes for sig, og de kan slås til og fra uafhængigt.

Det er nemt at tilføje et udseende, det er ligeså nemt at tilføje eller fjerne en funktion. Alle dele skal rettes ét sted. Det gør koden ultrastruktureret.

Til sidst, så bliver HTMLen, som er det, som skal hentes flest gange af både brugere og Google jo kortet så meget ned, det overhovedet kan. Det kan ikke andet end gøre siderne hurtigere i sidste ende.

Bagdele er der absolut også. Det kræver en anden måde at se tingene på, hvis det skal være helt unobtrusive scripting... når man ikke må bruge inline eventhandlers som f.eks. onclick. Og det tager tid at lære. Mange har allerede lært ikke at bruge inline CSS-styles. Her gælder det både inline styles og inline javascript. Det skal alt sammen lægges i selvstændig fil. Desuden, så er jeg udmærket godt klar over, den ikke går altid. Men jeg er stor tilhænger af selve princippet.

  • 0
  • 0
Martin Høgh

Jeg kan ikke lige se hvorfor det semantiske web kræver at du benytter xslt? Kan du forklare?

Nej, det gør det vel heller ikke. Men er ideen ikke, at gennem en webservice, at servere en xml-file med indhold og semantik. Hvis xml-filen kaldes af en browser, indlæses xslt-arket af browseren, som transformere xml'en til html vha. en template. Derved slipper du for at skrive html-sider og (semantiske) søgemaskiner inddeksere selvsamme xml-fil?

Hvis jeg ikke tager meget fejl kan du allerede i dag køre xslt i IE, så flyt det ud i dag.

Jo, og Firefox kan også. Opera + nogle minor browsere kunne ikke sidste gang jeg tjekkede. Jeg har (for noget tid siden) oplevet forskellige resultater i IE og FF og har derfor valgt at foretage transformationer på serveren. Vi er også tilbage til Google problematikken: Crawler den xml-filer og forstår den semantikken, indlæser den xslt-arket og kigger på html'en? Aner det ikke.

Jeg tænker man kunne hente sit xslt via en webservice?

Jo, det giver mulighed for at tilpasse det dynamisk. Men lægger du en statisk xslt-fil på din server med cache expires sat til uendeligt, får du de fordele du nævner. Det gælder selvfølgelig også CSS-arket.

  • 0
  • 0
Anonym

"Ja, jeg er måske lidt vel tidligt ude med min profesi. Og det jeg foreslår skal pt nok kun prøves af folk der kan lide at eksperimentere. Jeg kan godt forstå du venter til der kommer bedre tools. Men teknologi flytter sig hele tiden og vi alle flytter med :-)"

Jamen, jeg afviser skam heller ikke noget, som sagt vil jeg meget gerne at nettet udvikler sig hele tiden ;)

Og hvis idéen griber om sig, er jeg da også parat til at (forsøge at) lære det. Men... jeg er ikke fuldbefaren. Jeg er ikke en ørn til f.eks. javascript, og det i skriver om f.eks. XSLT, det er nok lidt for kompliceret for mig. Så lige min position er nok ikke optimal... Men derfor kan der sagtens være erfarnee eller helt nye i faget, som gerne vil lære det. Det er vel bare, om man kan se fordelene i forhold til den tid det tager at lære. Vel også en af grundene til, de fleste lærer sig CSS i dag.

  • 0
  • 0
Allan Ebdrup

1+2. Først har man indholdet, teksten, råt, ingen opmærkning. Man mærker så op, fordi så kan man se, hvad der er hvad. Det er også strukturen det gælder.
3. Man styler med CSS (som er for seende mest)
4. Man lægger funktioner på

Jeg er ikke helt sikke på hvad du mener med 1+2, at man har teksten råt og så mærker op, men det er måske fordi jeg ikke skal tænke på det som i eet dokument i begge trin?
Men denne lagdeling vil jeg ikke ødelægge, blot augmentere.
Den processering der foregår på servere der spytter HTML'en ud i trin 1+2 vil jeg ligge i JavaScript. Dette JavaScript kan stadig holdes helt adskilt fra den JavaScript du bruger i lag 4. Og du kan stadig teste og rette i lag 3+4 uafhængigt af hinanden. Selvom dit JavaScript i lag 4 vel godt kan være afhængigt af dine styles i lag 3 hvis det tilføjer/fjerner classes dynamisk?

Som jeg skrev i en anden kommentar betyder det at lag 1+2 kører på klienten, at du virkeligt får separeret din forretningslogik fra din præsentation. Hvis noget kode ikke tåler at ligge på klienten af sikkerhedsgrunde, så burde du nok flytte det til din forretningslogik aligevel. Dvs. i dette tilfælde ind bag en webservice. Det tror jeg faktisk jeg har lært af denne diskussion. Umiddelbart er det et rigtigt godt kriterie for om noget skal ligge i din aspx/jsp/php fil eller ikke, uanset om man ikke omkoder til JavaScript.

Lagdeling er kæmpe fan af, hvis det er de rigtige lag ;-)

  • 0
  • 0
Allan Ebdrup

Hvis xml-filen kaldes af en browser, indlæses xslt-arket af browseren, som transformere xml'en til html vha. en template. Derved slipper du for at skrive html-sider og (semantiske) søgemaskiner inddeksere selvsamme xml-fil?

Dvs. at browseren har direkte understøttelse for xml filer og henter transformationen direkte, ikke noget med xmlHttpRequest?
Du slipper vel ikke for at skrive html-sider, du skal vel skrive dine HTML-tags i xslt'en?
Hvis jeg har forstået det rigtigt er du begrænset til een xml-fil og een xslt.
Jeg har prøvet at kode HTML i XSLT'er for et kæmpe website, jeg vil sige det er for et specielt folkefærd af kodere og jeg er ikke en af dem. Så ville jeg hellere droppe xslt'en og lave transformationen i JavaScript. JavaScript er fremtiden for generering af HTML :-)

  • 0
  • 0
Jacob Christian Munch-Andersen

Efter at den gamle version havde torteret en databaseserver halvt ihjel kom jeg ind i Maptrick projektet (en statistikservice som samler data fra onlinespillet Hattrick).

Ud over at jeg skrev et system som flyttede mange små portioner data fra databasen ud i mere kompakte filer, så lavede jeg også et stykke JavaScript til at skrive den komplette side ud fra de rå data i en streng. Resutatet er ekstremt små filer som serveren stort set bare skal sende som de er.

http://maptrick.org/botmap.php?country=11&type=1

Der er rigtigt mange måder at bruge JavaScript på til at optimere ydelsen, dette eksempel er ikke præcis hvad Allan beskrev, men helt klart relateret.

Jeg vil lige gennemgå nogle få pointer.

Ovenstående eksempel bruger slet ikke AJAX, der var ikke rigtigt noget at hente i en AJAX løsning, og det tror jeg i øvrigt generelt gælder i mange tilfælde hvor AJAX er brugt, læg i stedet data som kunne sendes asynkront i HTML filen til at starte med. Kun hvis den løsning giver for store sider, eller de relevante data ikke eksisterer når siden hentes bør man overveje en AJAX løsning. (Som vel at mærke i modsætning til hvad navnet antyder efter min mening ikke bør laves med XML, det er rent overhead.)

Optimere serverydelsen, eller brugeroplevelsen? Et spørgsmål som for de fleste nok ikke er svært at svare på, selvfølgelig skal brugerne have det bedste, koste hvad serverkraft det måtte. Men er det overhovedet et relevant spørgsmål? Jeg vil påstå at der i de fleste tilfælde er positiv korelation mellem disse to optimeringer, når opsætningen flyttes ud på klient siden sparer det ikke kun regnekraft på serveren, det sparer også båndbredde, og selvom JavaScript langt fra er verdens hurtigste sprog så kan de simple operationer som her er tale om typisk udføres langt hurtigere end den mertid som det vil tage at hente HTML elementer sammen med den relevante data.

Omkring links; man kan sagtens skære en god bid overhead væk vha. JavaScript selvom man holder en sidestruktur med individuelle HMTL filer. Alternativt hvis man har smækket flere "views" ind i samme fil så kan man sætte #-værdien i urlen til at referere til et view, og på den måde opnå en måde at linke til en side på.

Det er altid forskelligt fra side til side hvilke metoder der giver mening, i mit eksempel er den JavaScript genererede del af siden meget søgemaskine-uvenlig uanset hvordan den er frembragt, det eneste stykke tekst som en søgemaskine vil få noget ud af er skrevet direkte i HTML-filen. Tænk over det, der er rigtigt mange måder at fifle på, ingen af dem er velegnede til alle opgaver, men til tider kommer der en opgave hvor de virkelig kan gøre en forskel.

  • 0
  • 0
Allan Ebdrup

1) Kan man ikke kigge på useragent headeren når du laver en fallback løsning? Alle useragents der potientielt understøtter JavaScript løsningen får JavaScript versionen med en noscript tag der henviser til fallback løsningen (Ville det ikke være smukt hvis der var en JavaScriptEnabled true/false header?)

2) En crazy idé mere, hvad med at lave din fallback ved at tage Chrome koden - den hurtigste open source browser - og lave en version der ikke renderer til skærmen. Ligge den på en server, få den til at hente JavaScript versionen, vente til alle Webservicekald var færdige og så returnere HTML'en i dokumentet.
Ja det ville nok performe ret dårligt, men det skal jo også kun bruges når JavaScript ikke er understøttet. Jeg har søgt lidt på nettet og fundet tal på 3% til 0.3% med JavaScript disabled, nogen der har nogle tal?

  • 0
  • 0
Jan K. Hansen

Allan,

Umiddelbart vil jeg sige at dette netop er en fordel, for hvis du har sådan noget kode i din aspx-side er det nok fordi du har fået puttet noget forretningslogik ned i dit view.

Ja ok, havde nok lige overset dit "lidt forretningslogik på serveren" under punkt 1.
I min erfaring er der dog som regel en allerhelvedes masse forretningslogik, så uafhængigheden af serveren er så som så når den skal blive liggende dér.

  • 0
  • 0
Allan Ebdrup

læg i stedet data som kunne sendes asynkront i HTML filen til at starte med.

Jeg ville nok foretrække at ligge data som en JavaScript fil med JSON som du inkluderer for at kunne styre caching på klienten bedre.
Så du kan sætte cache-expires til uendeligt på din JSON fil og opdatere ved at versionere JSON-filens navn.

Men godt input, det er faktisk noget af det jeg vil komme ind på i mit fremtidige blogindlæg om CDN og JavaScript.

  • 0
  • 0
Allan Ebdrup

I min erfaring er der dog som regel en allerhelvedes masse forretningslogik, så uafhængigheden af serveren er så som så når den skal blive liggende dér.

Ja du har ret, træerne vokser ikke ind i himlen. Men hvis du gør alt det kode du har i dine aspx/jsp/php filer platformsuafhængigt er det stadig en stor klump kode. Men det er selvfølgeligt afhængigt af systemet. For rene web-tjenester batter det selvfølgeligt mere. Hos Multidata hvor jeg arbejder, der laver lønsystemer og HR løsninger vil det være en meget lille del.

  • 0
  • 0
Anonym

"Jeg er ikke helt sikke på hvad du mener med 1+2, at man har teksten råt og så mærker op, men det er måske fordi jeg ikke skal tænke på det som i eet dokument i begge trin?"

Jeg var også lidt i tvivl om hvordan det skulle skrives. Men... reelt, så er 1+2 jo ikke adskilt fra hinanden, når browseren læser det. Ellers ville det have været en ren .txt-fil med indholdet, ikke en .html-fil. Man kan heller ikke rigtigt slå HTMLen fra ;) Det er mere det, for jo, det er selvfølgelig 2 fordskellige lag, indholdet=1, markuppen=2, ligger bare i samme fil. Derimod, så er både javascript og CSS adskilt helt, idét de ligger i selvstændige filer.

"Den processering der foregår på servere der spytter HTML'en ud i trin 1+2 vil jeg ligge i JavaScript. Dette JavaScript kan stadig holdes helt adskilt fra den JavaScript du bruger i lag 4."

OK, nu kan det være, der er noget. Hm.. Det betyder, at man skal have alle includes med også? header.inc footer.inc osv?

Jeg ved altså ikke rigtig.. Den kræver nok lidt tænkning, hvis den skal glide ned som generel model.. Det er stadig meget afhængig af brugerens indstilling af browseren. Så er det måske det, i mener med XSLT? At man kan definere sådan noget der?

"Og du kan stadig teste og rette i lag 3+4 uafhængigt af hinanden. Selvom dit JavaScript i lag 4 vel godt kan være afhængigt af dine styles i lag 3 hvis det tilføjer/fjerner classes dynamisk?"

Det burde der ikke være noget i vejen for som sådan. Det er ikke altid, man kan klare sig uden at indsætte en class ell. lign. i sin HTML for at nå et bestemt element med javascripten. Hovedsagen er bare, at selve funktionerne holdes i sit eget lag. Om den tilføjer noget synamisk, det tror jeg mange unobtrusive scripts gør.

Men bliver det så ikke svært at fejlfinde i den dynamisk genererede HTML? Og hvordan vil du validere det? Fordelen ved HTML det er jo også, det er rimeligt nemt at lave for selv begyndere.

Jeg kan godt se idéen, sagtens, men stadig er der nogle issues..

Jeg har så prøvet for sjov at kigge lidt på XSLT, som i også snakker om, og selv om jeg kan se, der er en mening, så forstår jeg ikke det bagvedliggende (endnu, det kræver lang tids læsning, kan jeg se).

  • 0
  • 0
Martin Høgh

Jeg vil lige følge op på mit indlæg om det semantiske web og XML/XSLT. Som det blev nævnt kan IE og FF læse XSLT-ark. Jeg fandt et eksempel, som jeg engang skrev: http://wms.mapuse.net/cal.old3/toxml.xml?statefilter[]=04

Se på kildekoden (brug FireFox, da IE ikke vil vise kildekoden for xml)

Kilden er ren xml med data og semantik. Helt separeret fra præsentationen, som ligger i XSLT og CSS ark, som bliver cached i det uendelige i browseren. Her er der ingen http_request_objects.

Derved er det kun XML'en, som skal genindlæses, når cachen udløber. Her er der kun én URI, ligegyldigt om du læser XML'en med din browser eller en XML-parser. Designet hjælper også udviklingerne: Ingeniøren skriver webservicen, web-programøren skriver XSLT og grafikkeren skriver CSS. De behøver slet ikke holde et møde om det.

Er det ikke fremtiden?

  • 0
  • 0
Jacob Christian Munch-Andersen

Jeg ville nok foretrække at ligge data som en JavaScript fil med JSON som du inkluderer for at kunne styre caching på klienten bedre.
Så du kan sætte cache-expires til uendeligt på din JSON fil og opdatere ved at versionere JSON-filens navn.

Om det er mest hensigtsmæssigt at placere et stykke data i HTML filen eller en fil for sig kommer igen meget an på situationen, der er altid ekstra overhead ved at lave flere filer, man kan nok regne med at hver ekstra fil lægger i omegnen af 100 ms til sidens load tid, så kriteriet for at vælge at placere data i en seperat fil bør være et kombination af datamængden og antallet af gange som man forventer at brugeren får brug for pågældende stykke data. Der er ikke nogen ide i at flytte et stykke data som kun bruges på en enkelt side ud i sin egen fil.

Jeg har i øvrigt aldrig rigtigt forstået ideen i JSON. Hvor kommer behovet for pludselig at overholde en arbitrært defineret substandard af JavaScript fra?

  • 0
  • 0
Anonym

"Er det ikke fremtiden?"

Jeg synes, det lyder meget spæændende. Hele idéen, som du forklarer den, lyder ret tillokkende.

Jeg følger lige lidt med på sidelinjen ;)

  • 0
  • 0
Jacob Christian Munch-Andersen

Designet hjælper også udviklingerne: Ingeniøren skriver webservicen, web-programøren skriver XSLT og grafikkeren skriver CSS. De behøver slet ikke holde et møde om det.

Endnu mere optimalt kunne de bare lade være med at lave noget arbejde overhovedet og så lade studentermedhjælperen som skal sætte det sammen og få det til at virke skrive hele molevitten fra bunden, det bliver alligevel ikke meget ekstra arbejde for ham.

Er XML med XSLT filer ikke at gå lidt over gevind med opdeling? XML filen bliver ikke stort forskellig fra en almindelig HTML fil, måske i nogle tilfælde en anelse mindre, men så skal XSLT filen jo oveni.

XSLT gør intet som man ikke kunne have gjort med et serverside sprog eller JavaScript, derimod tvinger XSLT data til at blive serveret på den ikke specielt kompakte XML form, og du misser de ekstra muligheder som et rigtigt programmeringssprog giver.

  • 0
  • 0
Jacob Larsen

Jeps. XML / XSLT er fremtiden.

Når man først har skrevet sine første 10 xslt stylesheets bliver det lige så nemt javascript. Det er dog vigtigt med et værktøj med code-completion.

Lidt erfaringer med teknologien, som jeg fik over frokosten i dag fra en kollega der er xslt fanatisk. Google indekserer hans client side xslt sider. Han har dog haft problemer med at lade browseren lave google analytics javascript. Det slår FF ihjel.

XML/XSLT er i øvrigt en super måde at gøre sine RESTfull webservices "human readable".

  • 0
  • 0
Mathias Larsen

Rune

Jeg var nødt til at oprette en profil herinde bare for at rette op på de misforståelser du fodre folk med.

Please FOLK STOP OP OG LÆS DET HER.

Rune tager så grueligt fejl at det gør ondt helt ned i maven.

Du blander tog helt grundliggende begreber sammen.
Indeksering og Ranking.

Det er korrekt links er vigtige for hvor godt du ranker men med et javascript baseret site vil du i mange tilfælde aldrig nogensinde blive "indekseret" i Google. Det vil sige at der ikke er en side du kan ranke på!!!!!!!

Tænk ALTID SEO ind. Jeg ville seriøst ligge sag an mod en programmør der afleverede en hjemmeside til mig der ikke engang kunne indekseres i google.

Christ altså.

  • 0
  • 0
Martin Høgh

Endnu mere optimalt kunne de bare lade være med at lave noget arbejde overhovedet og så lade studentermedhjælperen som skal sætte det sammen og få det til at virke skrive hele molevitten fra bunden, det bliver alligevel ikke meget ekstra arbejde for ham.

Det forstår jeg ikke. Det handler om at spare tid og lade de forskellige faggrupper gøre det de er bedst til.

XML filen bliver ikke stort forskellig fra en almindelig HTML fil, måske i nogle tilfælde en anelse mindre, men så skal XSLT filen jo oveni.

Nej, XML-filen er meget forskellig fra HTML: Den er nemlig ikke HTML! Der er ikke en eneste HTML-tag i den. XML og HTML er forskellige. HTML er præsentation, XML er struktur og semantik.

XSLT gør intet som man ikke kunne have gjort med et serverside sprog eller JavaScript, derimod tvinger XSLT data til at blive serveret på den ikke specielt kompakte XML form, og du misser de ekstra muligheder som et rigtigt programmeringssprog giver.

Du har ret - delvis. Selvfølgelig kan du alt på serveren. Du skal ikke kigge på html-outputtet fra mit eksempel, det kunne have været præsenteret meget bedre. Både xml og xslt er lavet vha. PHP på serveren. XSLT'en er fyldt med JavaScript og der er AJAX-kald til en webservice i den øverste dialog. XML/XSLT handler ikke om extra muligheder, men om at separere indhold fra præsentation. Derved gøres indholdet tilgængelig for andre klienter end web-browsere og du kan fylde det med mening (semantik) og undgå præsentationslaget fuldstændig. Bare en H1 tag er præsentation, som er unødvendig udenfor en webbrowser.

Lige en tilføjelse: XML/XSLT handler ikke om performance. Men prøv at parse de ca. 28.000 linjer XML, som mit eksempel giver i browser-javascript og lave en DOM-update. Det vil tage lang tid.

  • 0
  • 0
Martin Høgh

Jeg har i øvrigt aldrig rigtigt forstået ideen i JSON. Hvor kommer behovet for pludselig at overholde en arbitrært defineret substandard af JavaScript fra?

Fordi det er en substandard af JavaScript. Lav en JSON serializering af fx dine PHP arrays serverside - Javascript eval() dem clientside. Det er nemmere end XML-serializering/XML-parsing.

  • 0
  • 0
Jacob Christian Munch-Andersen

Min føste kommentar refererer selvfølgelig til din påstand om at de forskellige personer som arbejder på den samme side ikke behøver at holde møde om sagen. Let sarkastisk antyder jeg så at deres arbejde nok bliver temmelig ubrugeligt hvis de ikke snakker sammen for at synkronisere.

Hvis du kigger på de mest opdelte sider skrevet i HTML og CSS så er der godt nok ikke meget præsentation tilbage i HTML delen, men i stedet stakke af generiske div tags som kan formes på alverdens måder, i sådan et tilfælde er HTML filen meget lig en XML fil til XSLT transformation, det er ren struktur.

Hvor regner du med at dine XML filer vil blive brugt udenfor din webside? Hvor mange af disse XML filer tror du nogensinde vil blive brugt til noget fornuftigt uden deres tilhørende XSLT fil?

  • 0
  • 0
Jacob Christian Munch-Andersen

Fordi det er en substandard af JavaScript. Lav en JSON serializering af fx dine PHP arrays serverside - Javascript eval() dem clientside. Det er nemmere end XML-serializering/XML-parsing.

Hvorfor laver jeg ikke bare en JavaScript serialisering uden at bekymre mig om JSON?

  • 0
  • 0
Martin Høgh

Hvis du kigger på de mest opdelte sider skrevet i HTML og CSS så er der godt nok ikke meget præsentation tilbage i HTML delen, men i stedet stakke af generiske div tags som kan formes på alverdens måder, i sådan et tilfælde er HTML filen meget lig en XML fil til XSLT transformation, det er ren struktur.

Du har ret. Men html'en indeholder heller ingen mening, kun en masse div-tags.

Hvor regner du med at dine XML filer vil blive brugt udenfor din webside? Hvor mange af disse XML filer tror du nogensinde vil blive brugt til noget fornuftigt uden deres tilhørende XSLT fil?

Men det er web-service, som bliver brugt internt/eksternt. En XSLT laver html, en anden RSS, en trejde KML (til google maps), en fjerde GML osv. Eksterne brugere kan så vælge hvad de har brug for.

  • 0
  • 0
Anonym

"Rune"

Ja?

"Jeg var nødt til at oprette en profil herinde bare for at rette op på de misforståelser du fodre folk med."

Jamen, OK, lad høre

"Please FOLK STOP OP OG LÆS DET HER.

Rune tager så grueligt fejl at det gør ondt helt ned i maven."

Aha...

"Du blander tog helt grundliggende begreber sammen.
Indeksering og Ranking."

OK. Men så kunne du jo stille og gelinde bare oplyse, hvor du mener der er fejl... i stedet for at fare med bål og brand.

"Det er korrekt links er vigtige for hvor godt du ranker men med et javascript baseret site vil du i mange tilfælde aldrig nogensinde blive "indekseret" i Google. Det vil sige at der ikke er en side du kan ranke på!!!!!!!"

Jeg læser, hvad du skriver. Jeg ser også, du gerne vil have, man lægger mærke til, hvor yderst seriøs, du selv er, og understreger dette ved at bruge udråbstegn. Ikke bare et men mange. Ligeså bruger du store bogstaver, som spammere også gør.

Du må meget gerne dokumentere, hvor jeg har skrevet, at man kan indekseres med et Javascript site. Eller ranke. Alt efter hvad du selv vælger.

"Tænk ALTID SEO ind. Jeg ville seriøst ligge sag an mod en programmør der afleverede en hjemmeside til mig der ikke engang kunne indekseres i google."

Det er også, hvad jeg skriver. Hvis du nu læste mine indlæg. Men nu havde du jo så travlt med at oprette en account... Hvad jeg derimod finder dybt useriøst er, hvis du tænker på søgemaskiner først, brugerne derefter. Kan du finde mine indlæg, og så finde den passus? Jeg skal gerne hjælpe lidt...

"Godt indhold har aldrig kunnet slå ren SEO. fordi godt indhold ALTID vil blive indekseret godt."

Hvis du VIL lave black-hat, og optimere til søgemaskiner i stedet for brugerne, så fint nok med mig. Jeg skal ikke købe sider af dig så. Sidst, jeg læste om nogen, der gjorde det, blev de banned. BMW var det vidst.

Og en anden:

"SEO, (for selvfølgelig skal man også lave søgeoptimering) skal foregå udfra brugernes krav, ikke udfra søgemaskinernes krav. Det er nok bare det."

Hvilket kan læses af Googles egne webmaster guidelines. du kan med nemhed fædre Google Bot med falske oplysninger, intet problem. Spørgsmålet er bare om det er smart.

Til din oplysning: Nej, jeg har ikke søgeoptimeret mange sider. til gengæld, så ligger de rigtigt eigtigt godt, dem jeg har søgeoptimeret på. Faktisk indenfor de tre første på alle søgeord. Og jeg har ikke gjort stort andet end at tænke på brugerne først.

"Christ altså."

Ok, så du er troende, jeg er ateist. Andet du vil vide?

Helt ærligt... dit indlæg bærer præg af at

1: du har ikke læst overhovedet hvad jeg har skrevet. Overhovedet.

  1. Når så du har skimmet 2 eller 3 ord af mine indlæg, er det første du har gjort - at oprette en account, så du kunne komme af med din galde. Jeg kan godt se, det er meget gennemtænkt. Og iøvrigt en ganske glimrende debatteknik, du har. Jeg er meget imponeret.
  • 0
  • 0
Baldur Norddahl

Hvis du kigger på de mest opdelte sider skrevet i HTML og CSS så er der godt nok ikke meget præsentation tilbage i HTML delen, men i stedet stakke af generiske div tags som kan formes på alverdens måder, i sådan et tilfælde er HTML filen meget lig en XML fil til XSLT transformation, det er ren struktur.

Der er stadig en masse støj i form af menuer og andet snask som skal ind på hver side. Det kan du naturligvis klare nemt med en include hvis du laver det som PHP, men så er det ikke længere en HTML fil (på serveren) og på klienten vil html'en være fyldt af alt snavset.

En XML som processeres af XSLT er så dejligt renset for den slags. Den indeholder (f.eks.) kun en artikel uden noget uvedkommende. Den kan hentes direkte fra en database eller man kan benytte filsystemet som en database. XML filen er det rene objekt (artikel).

Webservere er som regel ekstremt hurtige til at servicere statiske filer. Ved at overlade XSLT processering til klienten kan man få et meget hurtigt system, også selvom der skal downloades en ekstra fil (XSLT filen).

Men så vidt jeg har kunne finde frem til, så vil Google ikke indeksere XML filer. Derfor har jeg været tvunget til at bruge serverside XSLT, hvilket lidt fjerner pointen. Er der nogen der ved hvordan Google håndterer XML+XSLT i dag?

  • 0
  • 0
Anonym

"Du må meget gerne dokumentere, hvor jeg har skrevet, at man kan indekseres med et Javascript site. Eller ranke. Alt efter hvad du selv vælger."

Nåhja... indekseret kan man nok blive, der kræves ikke meget tekst, hvis bare der er link til siden. Jeg har fået indeksertet en side med kun to ord.

derimod, hvis man forestiller sig man har en menu i ren Javascript, eller i JAVA eller Flash (Den kan så nok diskuteres), ja, så har Google ikke nogen mulighed for at følge de links, der naturligt ligger i menuen, da den ikke kan gennemtrawle koden.

Hvis så også indholdet er javascriptgenereret, så kan den heller ikke se indholdet, og der er ikke rigtigt noget at gå efter i en ranking. Måske lige med undtagelse af en title.

Derimod kan Google altid følge rene tekst-links i a href. Og de er også det mest brugervenlige samtidig. Hvis man vælger den synsvinkel.

Google påstår så de kan parse javascript. Men hvis du lægger mærke til det, så skrev jeg det med forbehold. En ting er de påstår, de kan. Men jeg tror, i den video, jeg linkede til, der handler det om en side, som er blevet anmeldt, og det er på den måde, de har opdaget det. Jeg har selv anmeldt sider, som har haft stuffed CSS-hidden links, og de blev taget af nærmest med det samme. Jeg er så selv ultra modstander af blackhat, men man skal ikke undervuderdere konkurrenter heller, hvis de kan finde noget om modparten, så er det da bare med at melde det konkurrerende firma.

  • 0
  • 0
Anonym

"Sidst, jeg læste om nogen, der gjorde det, blev de banned. BMW var det vidst."

Den har en forhistorie. Tyskerne havde lavet en hjemmeside som var i den grad utilgængelig for brugerne. Det betød, der ikke var nok kunder (efetr deres mening), og samtidig at Google ikke kunne trawle siden, når brugerne heller ikke ku. Og i stedet for at tænke på brugerne først og få lavet en mere tilgængelig side - så hyrede de en blackhatter til at lave en side, som serverede specielt indhold for Google, noget andet for brugerne. Sådan en slags lappeløsning, som ikke gavnede brugerne. Jeg kan ikke helt huske hvordan, men det var noget med både hidden tekst og Javascript redirect.

Det blev opdaget - naturligvis - og bortset fra de blev hånet godt og grundigt af diverse bloggere, og nyhedsservices, samt egentlig også af Google selv, så tog det dem en del tid at komme på igen.

Så man kan sagtens optimere til søgemaskinerne først, og man kan også komme rigtigt højt op. Men jeg synes det er uklogt.

  • 0
  • 0
Jacob Christian Munch-Andersen

@Martin hvornår har du sidst haft brug for et RSS feed som indeholder den samme information som en side? Hvordan en KML fil på nogen som helst måde skulle kunne dele data med noget som helst andet forstår jeg ikke. Hvem i alverden ville finde på at lave deres websideindhold til en GML fil, hvad skulle den bruges til?

Det lykkedes dig ikke at finde et realistisk scenarie hvor en XML fil kombineres med flere forskellige XSLT filer, behovet er praktisk talt ikke eksisterende.

@Baldur din snak om renhed er noget ævl, en alm. CMS struktur holder også tingene adskilt hvor der er brug for det, nemlig i udviklingslaget, om det er PHP, JavaScript, CS XSLT eller SS XSLT der samler trådene gør ingen forskel. Argumentet om at undlade at køre kode på serveren derimod er god logik, dog er CS XSLT langt fra den eneste mulighed for at opnå dette. Man kan for en stor del præfabrikere siderne på serveren, gem en sammenskrivning af indhold og templates således at simple includes og opsætning af indholdet er rydet af vejen når siden serves. Det hele kan gøres i JavaScript som artiklen foreslår, det kan give mange flere muligheder end CS XSLT.

  • 0
  • 0
Allan Ebdrup

Er det ikke fremtiden?

Muligvis. Jeg ser dog nogle ting der er mindre uhensigtsmæssige. Det er muligt jeg tager fejl med noget af det, men så må du rette mig
1) Du bliver nød til at lave een XML fil for hver webside, dvs de webservices du laver afspejler hvilke websider du vil lave, det er ikke helt at adskille tingene.
2) Caching kan ikke styres for delelementer af siden som du kan med JavaScript løsningen, hver gang et element på siden opdaterer skal hele xml filen genloades.
3) Som du skriver er der forskelle mellem browserunderstøttelse og sågar forskelle på hvordan xslt er implementeret. Det er noget man glemmer ved JavaScript, implementationen af selve sproget er ekstremt ens i alle browsere, personligt er jeg aldrig stødt på nogen derhar oplevet browserforskelle i selve JavaScript sproget, det er altid DOM'en eller CSS der er forskel på.
Det er faktisk en ikke uvæsentlig fordel ved det meget udskældte JavaScript, og en af grundende til at det har så stor success.
4) Hvornår tror du at mobiltelefoner får understøttelse for xslt? Jeg tror de får understøttelse for JavaScript først :-) JavaScript er baseline.

  • 0
  • 0
Martin Høgh

hvornår har du sidst haft brug for et RSS feed som indeholder den samme information som en side? Hvordan en KML fil på nogen som helst måde skulle kunne dele data med noget som helst andet forstår jeg ikke. Hvem i alverden ville finde på at lave deres websideindhold til en GML fil, hvad skulle den bruges til?

HTML for browsere:
http://www.toposhare.org/sharedroutes?permalink=1043

RSS for rss readers:
http://www.toposhare.org/services/routes/rss?permalink=1043

KML til Google Earth:
http://www.toposhare.org/services/routes/kml?permalink=1043

HTML:
http://politiken.dk/

RSS:
http://politiken.dk/rss/senestenyt.rss

Det der RSS er vist meget almindeligt:)

Og forresten: GML bruges på samme måde som KML, men typisk i mere professionelle kortapplikationer. Dog er der indlejret GML i GeoRSS, som eksemplet viser.

  • 0
  • 0
Allan Ebdrup

Kom i tanke om et punkt mere ved din XML løsning:

5) Hvad hvis du har et element du pager på siden, så skal google indekserer hele siden for hver page du har. Og brugeren skal reloade hele siden for hver page? Men du skrev at du brugte AJAX, bruger du det også til paging?
Eller endnu værre, hvad nu hvis du har to datakilder du pager på samme side? Så skal google indeksere alle kombinationer af sidevisninger.
Det indhold du skal levere til google og andre søgemaskiner skal selvfølgeligt indeholde alle data fra alle pages. Dvs. søgemaskinerne skal alligevel have en speciel version af dit site, hvis de skal indeksere optimalt. Eller hvad?

  • 0
  • 0
Jacob Larsen

@Allan

Hvornår tror du at mobiltelefoner får understøttelse for xslt? Jeg tror de får understøttelse for JavaScript først :-) JavaScript er baseline.

Opera mini på min Nokia E51 har allerede understøttelse for xslt.

  • 0
  • 0
Mathias Larsen

Hej igen Rune

Ja mine kommentarer igår bar stærkt præg af at skulle af med noget Galle.

Jeg skulle have qoutet det jeg ville kommentere på, det gør jeg så nu i stedet:

Du bliver indekseret, fordi dine brugere kan lide dine sider, og fordi de derfor linker til dig. Hvis ikke de kan læse dine sider, kan de heller ikke afgøre, om de kan lide dem. Altså ingen links.

DET er forkert. Links handler om ranking, ikke indeksering.

Godt indhold har aldrig kunnet slå ren SEO. fordi godt indhold ALTID vil blive indekseret godt.
I hvert fald i Google, om ikke andet.

Det var jo det her der gjorde mig sur.
især "godt indhold ALTID vil blive indekseret godt".
ØHHH nej!! Hvis google ikke kan læse det vil det netop IKKE blive indekseret.
Ren SEO slår godt indhold hvis det gode indhold ikke kan indekseres pga javascript og ajax. Det kan jeg garantere dig.

That beeing said, så kan jeg da godt se at jeg har argumenteret mod dig uden at have gennemlæst alle dine posts. Kan se at du på ingen måde er ukritisk overfor javascript.
Det gør dog ikke dine påstande mindre forkerte. Bare forkerte med omvendte fortegn.

Desuden kan jeg lige fortælle dig at i min google analytics med lidt over 14 millioner unikke besøg, der har 98.31% Javascript Enabled.

Dig med BMW eksemplet er desværre også way off. Firmaer på størrelse med BMW kan idag gøre hvad de vil. Google er et internationalt aktieselskab hvor aktionærene bestemmer og de smider altså ikke en International virksomhed af BMWs størrelse ud af indekset igen. Det var tilbage i de politisk/etiske korrekte dage for Google.

  • 0
  • 0
Baldur Norddahl

@Baldur din snak om renhed er noget ævl, en alm. CMS struktur holder også tingene adskilt hvor der er brug for det, nemlig i udviklingslaget, om det er PHP, JavaScript, CS XSLT eller SS XSLT der samler trådene gør ingen forskel.

Ikke alle websites er så store og avancerede. Jeg har et site der ikke består af andet end XML, XSLT, CSS og lidt billeder med menustruktur og alt andet man forventer af et website. Det kan hostes af en ren statisk webserver (f.eks. Amazon S3).

Der er ikke brug for noget CMS system fordi filsystemet med XML er CMS systemet.

Jeg har ikke set andre løsninger der ligeså elegant klarer den opgave.

  • 0
  • 0
Anonym

"Links handler om ranking, ikke indeksering."

Øh, OK. Så du tilmelder dig *Google hver gang du vil indekseres for første gang? Og Yahoo? Og Live AKA BLING? Jeg smider bare et link i min signatur i en nyhedsgruppe, og jeg har _aldrig_ tilmeldt sider til Google. Samtidig ryger linket på en link-database, hvis det er en kunde under relevant sektion.

Linkdatabaser virker beviseligt, men er mest for virksomheder, man skal bare finde dem, som ikke ødelægger værdien af linket fra datasen til ens side, jeg har f.eks. brugt Klik og Find, Danske Links, gulex.dk .. lang tid siden, jeg har kigget på det, men gulex lader staig til at være god.

Og så er det lovlig SEO, eftersom det er en service efterspurgt af brugerne. Og gratis.

Det kombinerer både de første links ind og indekseringen... gør det ikke? Virker i hvert fald for mig. Og brugerne benytter de databaser også til at søge på (viser min statistik), så det er dobbelt op efter min mening. Og meget optimalt også.

Men fint nok, hvis nu man synes det er sjovt at sidde og udfylde små telmeldingsformee, så... Kan ikke engang huske hvordan man gør ;)

"Det var jo det her der gjorde mig sur.
især "godt indhold ALTID vil blive indekseret godt".
ØHHH nej!! Hvis google ikke kan læse det vil det netop IKKE blive indekseret.
Ren SEO slår godt indhold hvis det gode indhold ikke kan indekseres pga javascript og ajax. Det kan jeg garantere dig."

OK, men vores udgangspunkt er nok forskelligt, og ja, min formuleringsevne er ikke altid skide god, manglede den med indgående links. Ellers, så stpr jeg nu ved, hvad jeg skriver.

Jeg er til unobtrusive scripting, som, alt andet lige, serverer det mest rene indhold for botterne, som det er muligt uden at bruge uforholdsmæssigt meget tid, og det er også, alt andet lige, den mest brugeroptimerede måde at kode på. Det er tilgængeligt, hvorfor det er nemt at indeksere.

Hvad jeg gjorde var - for et øjeblik - at forsøge at tænke over, om man kunne komme ud over problemet med javaascriptsider, som ikke kan indekseres korrekt. Men jeg har aldrig selv benyttet metoder, som gjorde det sværere for brugerne at læse, navigere og forstå indholdet, nærmest tværtimod, eftersom jeg er usability-nørd også. Derfor mener jeg, at Google har så meget nemmere ved at indeksere siderne, når de er optimeret til brugerne.

Med ren SEO, der tænker jeg f.eks. på dem, som går ind og analyserer, om et ord skal placeres anderledes, for at siden teoretisk kan opnå bedre placering. Det gavner ikke brugeren, og har du set sådanne "optimerede" sider, lyder det som noget, der er forfattet af en maskine. Ganske hæsligt, og ikke læseværdigt. Og så kan jeg ikke se en grund til at have siden heller, hvis brugerne ikke kan læse den. Høj placering, ja, men interessant for brugeren - nej.

"Desuden kan jeg lige fortælle dig at i min google analytics med lidt over 14 millioner unikke besøg, der har 98.31% Javascript Enabled."

Igen er vi nok forskellige. Jeg vil meget gerne have den mulighed for javascript til/fra. Men det har også noget at gøre med, jeg jævnligt har behov for at besøge .cn og .ru-sider.

Sørger man for, ens side kan ses også uden JS, så får man lige de sidste procent i din analytics med også.

Et sidespørgsmål: Har du din analytics-kode liggende i body, som mange har? For er der noget, som kan sløve en side, og dermed irritere brugerne, så er det da Google Features som analytics.. Jeg har set et genialt eksempel på indhentning af den kode via en slags AJAX, og det var en enorm forbedring af hastigheden. Men ok, sidespring..

"Dig med BMW eksemplet er desværre også way off. Firmaer på størrelse med BMW kan idag gøre hvad de vil."

Ja, det var dengang.. Ikke desto mindre, så er der stadig muligheden for, at man bliver anmeldt af en konkurrent, og er man bare et mindre firma, så skrider Google ind. Man kan ikke være helt sikker på de ikke gør det, vel? Så hvorfor forsøge? Det gavner jo heller ikke brugerne, som er dem, man skal tjene på. Det er den tankegang med, at man tjener på botten, ikke brugerne, som jeg er så forbandet meget imod. Google Bot har aldrig købt nogle produkter af mig.

  • 0
  • 0
Anonym

"Hvis google ikke kan læse det vil det netop IKKE blive indekseret.
Ren SEO slår godt indhold hvis det gode indhold ikke kan indekseres pga javascript og ajax. Det kan jeg garantere dig."

Hvis Google Bot ikke kan læse ens indhold, så har man nok også problemer med at brugerne ikke kan.

Det er jo nøjagtigt, hvad der er problemet med rene AJAX eller javascript-sider vs. ren HTML. Der mangler dem, som har slået JS fra.

Den tror jeg altså bliver sværet at argumentere imod, men man kan da forsøge..

Sidst jeg tjekkede var de kommet ret langt med Flash, som også har problemer, men jeg ville aldrig nogensinde bruge en Flash-menu i stedet for en HTML-menu, hvor gode Google så end påstår, de er til at indeksere Flash.

Om ikke andet, så fordi en ren HTML-menu er sindsygt nemt ar tilrette, og kan styles ligeså nemt. Kræver ikke specialkendskab til særlig kode udover det grundlæggende heller.

  • 0
  • 0
Martin Høgh

1) Du bliver nød til at lave een XML fil for hver webside, dvs de webservices du laver afspejler hvilke websider du vil lave, det er ikke helt at adskille tingene.

Det er korrekt. XML-filen er jo siden du indlæser. Men XML'en vil ikke være en fil, men komme fra fx en RESTful webservice. Og ifølge det princip er der forskellige URIs til de forskellige "sider".

2) Caching kan ikke styres for delelementer af siden som du kan med JavaScript løsningen, hver gang et element på siden opdaterer skal hele xml filen genloades.

Der er korrekt. Men i XSLT kan du indlejre JavaScript og ved en event (OnDOMReady fx) lave XHR kald til en webservice, som du foreslår. Altså kombinere de to metoder.

3) Som du skriver er der forskelle mellem browserunderstøttelse og sågar forskelle på hvordan xslt er implementeret. Det er noget man glemmer ved JavaScript, implementationen af selve sproget er ekstremt ens i alle browsere, personligt er jeg aldrig stødt på nogen derhar oplevet browserforskelle i selve JavaScript sproget, det er altid DOM'en eller CSS der er forskel på.
Det er faktisk en ikke uvæsentlig fordel ved det meget udskældte JavaScript, og en af grundende til at det har så stor success.

Ja, det er problemet, og jeg har ikke hørt om cross-browser-XSLT? Jeg tror også det er grunden til at udviklingen er gået i stå og man så opfandt xhtml i stedet. Men mon ikke XSLT understøttelse er blevet bedre?

4) Hvornår tror du at mobiltelefoner får understøttelse for xslt? Jeg tror de får understøttelse for JavaScript først :-) JavaScript er baseline.

Som dokumenteret, er det understøttet i Opera's version til håndholdte terminaler.

5) Hvad hvis du har et element du pager på siden, så skal google indekserer hele siden for hver page du har. Og brugeren skal reloade hele siden for hver page? Men du skrev at du brugte AJAX, bruger du det også til paging?
Eller endnu værre, hvad nu hvis du har to datakilder du pager på samme side? Så skal google indeksere alle kombinationer af sidevisninger.
Det indhold du skal levere til google og andre søgemaskiner skal selvfølgeligt indeholde alle data fra alle pages. Dvs. søgemaskinerne skal alligevel have en speciel version af dit site, hvis de skal indeksere optimalt. Eller hvad?

Ok, så er vi nede i konkrete løsninger. Men jeg ser ikke forskelle i Javascript og XML metoden her. Enten loader man alt data fra en service på en gang og laver paging vha. dhtml. Eller så loader man hver enkelt page fra serveren - synkront eller asynkront. Her vil jeg nok vælge Javascript/XHR metoden. Webservicen vil være den samme.

Jeg synes, at vi skal adskille i dag fra i morgen. I dag er der en masse tekniske problemer forbundet med begge løsninger. Men det interessante spørgsmål er hvordan morgendagens www vil virke og hvordan vi i dag kan starte med at designe det. Du indleder med at skitsere en løsning for fremtidens websites. Jeg er langt hen ad vejen enig, men jeg synes du bruger de forkerte argumenter. Jeg skylder nok at forklare hvorfra jeg ser tingene: Jeg er ikke programmør eller udvikler, men byplanlægger og arbejder med at gøre byplaner tilgængelig på www. En "plan" kan være et website på 3.000 sider og der er mange planer. Læg dertil relevante retlige bindinger, byrder, arealdatabaser osv. Det bliver millioner af html-sider, PDF-sider, arealudpegninger i GML mv. Selve indholdet er svært tilgængeligt, selv for fagfolk. Fyldt med jura og fagterminologi. Og er bare det lille hjørne af www, som hedder plandata i Danmark.

Her kommer dagens teknologier til kort. Manglen på mening og sammenhænge i html, gør søgninger til vildskud. Problemet skal løses gennem visionen om det semantiske web, og det er derudfra jeg mener, at vi skal designe fremtidens hjemmesider. Hvad hjælper det, at en side loader på 1 sek. i stedet for på 2, hvis du skal loade de første 20 sider inden du finder det du søger? Og lad mig understrege, at det ikke handler om SEO! I det kommende semantiske web søger man ikke, men laver opslag. Www går fra at være en gigantisk rodebutik til en standardiseret, struktureret database, hvori du kan lave opslag.

Din Javascript metode er fin, så længe du kan eksponere din webservice til omverden og xml-outputtet følger standarder og er forsynet med korrekt metadata mv. Derved får du samme fordele som med XML/XSLT metoden, nemlig total adskillelse af præsentation og data samt muligheden for at forsyne data med mening og sammenhænge.

  • 0
  • 0
Per Thomsen

Jeg sidder dagligt med en applikation, der gør som foreslået.
Der er lavet et framework til håndtering af diverse gui-elementer, der ikke som udgangspunkter er understøttelse for i JavaScript (faneblade, menuer, træ-strukturer, mdi-vinduer, combobokse, etc). En dialog består af statisk html og en række js filer. For hver dialog betragtes window.onload som 'main' funktionen, og heri generes diverse objekter til brug for dialogen.
Dialogen tegnes dynamisk, og alt data til dialogen hentes via webservice. Dialogen generes ved en kombination af XML/XSLT og DOM manipulation. Typisk generes html til store tabeller via a XSLT, og indsættes via DOM. Alt forretningslogik foregår på mainframe, webservices bruges udelukkende til gennemstilling af data fra mainframe til klienten.

Alt dette blot for at sige, at ikke blot kan det lade sig gøre, det er også (ihvertfald til dels) gjort. Vores applikation har kørt på denne måde siden 2001.

Vores applikation er dog til en specifik målgruppe, den skal fungere på de to nyeste version af Internet Explorer på de to nyeste versioner af Windows, og den kører på et lukket net.
Der er ikke noget med at det skulle kunne fungere uden JavaScript, eller på mobil telefoner, eller andre enheder. Det skal ikke (og bliver ikke) indekseres af nogen søgemaskiner, da det er ikke et website. Det er en applikation til en begrænset brugerskare. Så nogle af de problemer der er bragt op her, er vi afskåret fra og nogle af dem har vi fravalgt. Jeg tror f.eks. ikke en blind person ville have en chance for at benytte vores applikation.

Det er dog ikke alt sammen rosenrødt, for selv med vores begrænsede platform oplever jeg nu og da, at nu er afhængigheden til serveren flyttet til klienten, og der er er den langt sværere at håndtere. Det er dog heldigvis kun yderst sjældent et problem.

  • 0
  • 0
Jacob Christian Munch-Andersen

Du må aldrig aldrig aldrig udvikle til kun Internet Explorer. Du står med håret i postkassen når din kode ikke virker i IE 9. Hvis du udvikler til de andre udbredte browsere også undgår du ikke blot vendor lock-in, chancen for at din kode virker i IE 9 er også betydeligt meget større når du har sikret dig at dit produkt virker i flere browsere.

  • 0
  • 0
Allan Ebdrup

Jeg sidder dagligt med en applikation, der gør som foreslået.
Der er lavet et framework til håndtering af diverse gui-elementer, der ikke som udgangspunkter er understøttelse for i JavaScript (faneblade, menuer, træ-strukturer, mdi-vinduer, combobokse, etc).

Det du beskriver lyder som en RIA, det er ikke helt det jeg mener. Selvom din RIA selvfølgelig bruger samme teknik. Jeg vil have at du skal bruge JavaScript til at generere alt din HTML, også selvom det bare er fx en blog som denne sider. Simpelthen bruge JavaScript til at lave alt det man normalt laver i sin aspx/jsp/php fil.

  • 0
  • 0
Martin Høgh

personligt er jeg aldrig stødt på nogen derhar oplevet browserforskelle i selve JavaScript sproget, det er altid DOM'en eller CSS der er forskel på.

Det har jeg. I exception handling. Nedenstående 'if' bliver altid sand i IE. Det er som om, at e.name ikke har nogen type. Selvom den castes til string. Alert() viser i IE 'TypeError'. Det virker i FF.
try {}
catch(e){
if (String(e.name) != "TypeError")
{
alert("Der opstod desværre en fejl: " + String(e.name));
}
}

  • 0
  • 0
Allan Ebdrup

Det har jeg. I exception handling. Nedenstående 'if' bliver altid sand i IE

Kom i tanke at jeg faktisk selv har prøvet det een enkelt gang, der var engang noget kode der virkede fint i FireFox men ikke i IE, der var en boolean der indeholdt værdien true men selv og jeg lavede step-through debugging i IE og så at der stod true opførte min if sig somom den var false, jeg endte med at lave en isTrue funktion for at løse problemet.
Så vidt jeg husker var det i datidens nyeste browser IE6, tilbage i 2002-3 stykker :-)
Hvis du bruger JSLint kan du undgå den slags problemer http://www.jslint.com/

  • 0
  • 0
Anonym

"Du må aldrig aldrig aldrig udvikle til kun Internet Explorer. Du står med håret i postkassen når din kode ikke virker i IE 9."

Det er klart nok. I hvert fald, hvis man bruger den sunde fornuft. Ikke desto mindre, så har Microsfot jo tvisted sandheden en del gange, og her, der siger de direkte, at de ikke giver en sk.. for W3C-valid kode, men pakker det alligevel pænt ind - prøv at læse, og tænk over, hvad de i virkeligheden mener med det:

Overskrift: Compatibility

Check (IE er den eneste, som "opnår" et point iflg M$)

"Internet Explorer 8 is more compatible with more sites on the Internet than any other browser."

Taget fra deres "test" af IE8 imod andre browsere, som de selv har betalt, og som beviseligt er bedrag og svindel og falsk markedsføring, som de burde idømmes en så klækkelig bøde for, de ville være nødt til at lukke i hvert fald halvdelen af "firmaet" (læs: svindelforetagendet).

  • 0
  • 0
Allan Ebdrup

try {}
catch(e){
if (String(e.name) != "TypeError")
{
alert("Der opstod desværre en fejl: " + String(e.name));
}
}

Prøv med !== i stedet for !=

se
http://javascript.crockford.com/code.html

=== and !== Operators.
It is almost always better to use the === and !== operators. The == and != operators do type coercion. In particular, do not use == to compare against falsy values.

og se så denne video:
http://www.youtube.com/watch?v=hQVTIJBZook

Doug Crockford var manden der viste verden hvordan man kunne lave klassisk OO nedarvning i JavaScript

  • 0
  • 0
Allan Ebdrup

Jeg har i øvrigt aldrig rigtigt forstået ideen i JSON. Hvor kommer behovet for pludselig at overholde en arbitrært defineret substandard af JavaScript fra?

Det er Doug Crockford der har fundet på JSON (se videon jeg linker til ovenfor)
Fordelen ved JSON er at du kan parse det med en eval, det performer helt sindsygt godt. Derudover får du en meget pæn måde at få fat i data, ikke noget med mærkelige XPaths og en DOM (.firstChild osv.), du får en skræddersyet objektmodel med de meningsfyldte navne du har valgt
http://www.json.org/

  • 0
  • 0
Jacob Christian Munch-Andersen

Allan, Martin Høgh har allerede givet mig stort set det samme svar. Jeg kunne da aldrig drømme om frivilligt at vælge XML til noget som helst.

Jeg kan måske omformulere mit spørgsmål lidt. Hvorfor vælger du at kalde din kode JSON frem for JavaScript? Eval er ikke en JSON parser, det er en JavaScript parser, JSON er en ide som findes i dit hoved, det har ingen relevans om dit JavaScript overholder JSON specifikationen eller ej. Så hvorfor skriver du alligevel JSON og ikke JavaScript?

  • 0
  • 0
Jonas Høgh

Forskellen på JSON og JavaScript er at JSON ikke understøtter funktioner på objekterne, kun data. Dette er essentielt for ikke at muliggøre cross-site-scripting ved import af JSON fra kilder du ikke stoler på.

Af samme grund bruger man heller aldrig en rå eval() til at parse JSON, da denne netop er designet til at evaluere JavaScript kode.

P.t. er du nødt til at bruge hjemmerullede funktioner som fx Prototypes evalJSON http://prototypejs.org/api/string/evalJSON, i FireFox 3.5 er JSON evaluering understøttet direkte i JavaScript motoren:

https://developer.mozilla.org/En/Using_native_JSON

  • 0
  • 0
Allan Ebdrup

Du har ret i at du bør bruge en JSON parser hvis du henter JSON fra en kilde du ikke stoler på (andre end dig selv :-).

Af samme grund bruger man heller aldrig en rå eval() til at parse JSON, da denne netop er designet til at evaluere JavaScript kode.

Aldrig? Du kan vel godt bruge eval hvis du konsumerer JSON du selv leverer?

Det er også vigtigt at JSON ikke har fuld JavaScript kode hvis dem der skal konsumere din JSON ikke lige kan køre JavaScript.

Why JSON isn’t just for JavaScript:
http://simonwillison.net/2006/Dec/20/json/

  • 0
  • 0
Per Thomsen

@Jakob:
Hvis det var et website, ville jeg ubetinget være enig med dig, men som jeg skrev er det ikke et website, det er en applikation. Applikationen kører på et lukket netværk, og det er til en specifik målgruppe. Internet Explorer er blot den valgte platform at implementere applikationen på. Applikationen er solgt på kontrakt og specificeret til altid at skulle fungere i to nyeste versioner Internet Explorer.

@Allan:
Lad mig konkretisere hvad jeg mener:
Det eneste HTML vi sender fra webserveren til klienten, er det HTML, der sørger for at hente de scripts vi skal bruge. En sådan html side ser typisk således ud:
<html>
<head>
<script type="text/javascript" src="xxx.js"/>
<script type="text/javascript" src="xxx.js"/>
<script type="text/javascript" src="xxx.js"/>
...
<style type="text/css" rel="stylesheet" href="y.css"/>
<style type="text/css" rel="stylesheet" href="yyy.css"/> <style type="text/css" rel="stylesheet" href="yyy.css"/>
</head>
<body>
</body>
</html>

Med de inkluderede script genereres der, MDI vinduer, faneblade, tabeller, træstrukturer, knapper og alt, hvad du ellers kunne forestille dig at finde i en desktop applikation.

Når det hele er tegnet, så hentes data via XML services, og indsættes i dialogerne. Ved tabeller så genereres HTML (client-side) vha af XSLT transformation og indsættes i dialogen vha af DOM.

Så med det du foreslår i din artikel:

"Skifte alle dine Aspx-, Jsp- eller Php-sider ud med .html sider" - done!

"Lave hele den dynamiske del af præsentationen af dit website i JavaScript. Dvs. generering af html udfra data, der fx kommer fra en database." - done!

"Lad den eneste kommunikation med webserveren være:
- Download af statisk indhold. Dvs. JavaScript, Css, billeder og .html filer
- Webservice eller Rest, kald der kun returnerer rå dynamisk data, enten som JSON eller som XML" - done!

"Brug stadig inkluderede Css-filer til at syle dit website" - done!

  • 0
  • 0
Peter Müller

Jeg synes denne debat mudrer meget til med folk der snakker i øst og vest fordi de har forskellige udgangspunkter.

Min egen holdning til indlægget: Fantastisk. Jeg har siddet og lavet en masse af den slags allerede, og du ridser en lang række punkter op som er yderst relevante. En ting mangler dog. Distinktionen mellem website og webapplikation.

På et website skal alting virke 100% for alle brugere der besøger den. Dette gør du for at lokke kunder til i stedet for at skræmme dem væk. Usability er i højsædet her, og som konsekvens også søgemaskineoptimering. Derfor kan du ikke kræve javascript, og du SKAL gøre din side læsbar i rå html.

I en webapplikation har folk allerede en interesse i at benytte applikationen. De har valgt den til, og det gør en forskel for om du kan kræve noget af brugeren eller ej. Har brugeren eksempeltvis valgt javascript fra, kan man gøre opmærksom på dette, og brugeren kan indsætte en undtagelse for den specifikke applikation.

Det giver naturligvis derudover mest mening at skifte til javascriptgenereret DOM hvis man i forvejen har tænkt sig at lave en applikation som er meget javascriptafhængig. Har jeg blot en applikation som minder om visning af statiske data, er javascriptgenereret DOM en dårlig ide. Hvis man derimod skal have alverdens muligheder for dynamiske opdateringer af delmængder, drag/drop og diverse andre interaktionsmuligheder, så har du sandsynligvis sparet en masse tid ved at lave det hele i javascript fra bunden.

Angående XML/XSLT så kan jeg kun sige at jeg selv har udviklet webapplikationer i det, og konklusionen er at teorien er god, men praksis umulig. Browseres understøttelse af xslt er endnu værre end html, css og javascript. I praksis blev vi nødt til at vælge severside fortolkning af xslt, hvilket blot giver os et større load end at generere html direkte. Derudover er der ret mange begrænsninger i xslt og det er enormt besværligt at skrive. I teorien er det fremtiden. Og til statiske sider er det utvivlsomt godt. Men til dynamiske webapplikationer er det noget man skal gå en stor bue udenom.

Jeg glæder mig til at se det opfølgende blogindlæg.

  • 0
  • 0
Jacob Christian Munch-Andersen

Jonas og Allan, JSON blev født til eval, uden eval var JSON aldrig belevet til noget, for uden eval er JSON bare en besværlig datastreng som skal parses, ligesom XML, bare generelt lidt mere kompakt.

Som kode til eval funktionen er det ikke andet end JavaScript, med tilhørende sikkerhedsproblemer. Som dataformat i alle andre sammenhænge er det en standard til overholdelse for standardens skyld.

  • 0
  • 0
Allan Ebdrup

På et website skal alting virke 100% for alle brugere der besøger den. Dette gør du for at lokke kunder til i stedet for at skræmme dem væk. Usability er i højsædet her, og som konsekvens også søgemaskineoptimering. Derfor kan du ikke kræve javascript, og du SKAL gøre din side læsbar i rå html.

Jeg tror godt vi kan konkludere at der skal være en fallback løsning. Af to årsager:
- indeksering af siden af søgemaskiner
- devices og browsere uden JavaScript
Den første er den vigtigste.

Men lad mig så stille et spørgsmål:
Hvorfor skal det at et website skal virke for alle betyde at man ikke kan udnyttte fordelene ved at JavaScript opbygger siden for de 98% af folk der HAR JavaScript understøttelse?
Hvorfor skal de 2% sætte standarden for hvordan løsningen teknisk fungerer for de 98%. Hvorfor ikke lave en optimeret version til de 98% og så lave en fallback løsning til de 2%?

  • 0
  • 0
Peter Lundsby

Jeg tror ikke at metoden med ikke at bruge .aspx, .jsp vil gør det bemærkelsesværdigt nemmere at flytte imellem forskellige Cloud-leverandører.

For de fleste webapplikationer, er mængden af kode der afvikles på serversiden (altså ikke js, html, css kode) der ligger i disse filer begrænset.
Derfor er lagt den største hurdle konvertering af forretningslogikken som metode overhovedet ikke angriber. Der er her man finder de største forhindringer idag, med forskellige storage modeller etc.

Derudover betyder metoden efter min bedste overbevisning også et performance tab, fordi indsætning af indhold hente via services, først kan ske efter DOM'en er loadet. Hvor det hvis man serverer det i selve kan renderes parallelt med resten af html'en.

  • 0
  • 0
Peter Müller

Hvorfor skal det at et website skal virke for alle betyde at man ikke kan udnyttte fordelene ved at JavaScript opbygger siden for de 98% af folk der HAR JavaScript understøttelse?
Hvorfor skal de 2% sætte standarden for hvordan løsningen teknisk fungerer for de 98%. Hvorfor ikke lave en optimeret version til de 98% og så lave en fallback løsning til de 2%?

Selfølgelig skal man benytte de værktøjer man har til at forbedre brugeroplevelsen.

Men lad os nu antage at vi har valgt at lave en side som kan ses af alle, hvilket giver mig fordele overfor brugere uden javascript, brugere med screenreadere, søgemaskiner osv.

Så skal jeg under alle omstændigheder lave en version i servergenereret rå HTML. Jeg er ikke interesseret i at give menneskelige og seende personer en markant ringere oplevelse ved at besøge min side, så jeg er også interesseret i at style det hele med CSS.

Nu er sagen så at hvis jeg vælger din løsning så skal jeg faktisk lave et dobbeltbogholderi. Et site med servergenereret HTML, og et med Javascriptgenereret HTML. Pludselig dør argumentet om lettere vedligeholdelse. Specielt når vi også skal tilføje hacks for at få bookmarking, history osv til at fungere på den rent javascriptgenererede side, naturligvis med de samme url'er som ikke-javascriptklienten bruger.

Det er derfor man i senere tid i usabilitykredse ikke længere taler om gracefull fallback (tilbagefald til en verion der virker for ikke-javascript klienter), men progressive enhancement (fungerende side med ekstra lag af forbedringer til føjet sidenhen me Javascript).

Progressive enhancement giver dig det bedste af begge verdener. Læsbarhed, brugbarhed, indexerbarhed og fancy dynamiske features. Det er et must for sider hvor brugere endnu ikke har købt konceptet.

Til webapplikationer vil jeg ganske uden at tvivle ty til Javascript uden fallback. Her kan man forvente mere af brugeren, og du vinder alle de nævnte fordele.

  • 0
  • 0
Allan Ebdrup

Men lad os nu antage at vi har valgt at lave en side som kan ses af alle, hvilket giver mig fordele overfor brugere uden javascript, brugere med screenreadere, søgemaskiner osv.

Så skal jeg under alle omstændigheder lave en version i servergenereret rå HTML. Jeg er ikke interesseret i at give menneskelige og seende personer en markant ringere oplevelse ved at besøge min side, så jeg er også interesseret i at style det hele med CSS.

Tja måske kunne man gøre det sådan at de ikke fik en ringere oplevelse, bare en anden oplevelse?
Hvad nu hvis jeg påstår at du muligvis kunne gøre det link du får fra google til din side endnu bedre ved at det linker ind på din side med en #anchor til den del af siden der passer på søgningen?
Jeg er ked af det, men det ville være for omfattende at gå i detaljer. Og jeg vil gerne lave et Proof-of-concept for at se at min idé virker først.

Nu er sagen så at hvis jeg vælger din løsning så
skal jeg faktisk lave et dobbeltbogholderi. Et site med servergenereret HTML, og et med Javascriptgenereret HTML. Pludselig dør argumentet om lettere vedligeholdelse.

Jeg siger ikke jeg har alle svarene i denne artikel, den er ment som en skør idé der kan sætte tankerne og debatten i gang.
Er du nu også sikker på at man ikke kan lave en løsning så man ikke kræver dobbeltbogholderi? Det er vildt hvad man kan med IT hvis man tænker lidt kreativt.

Specielt når vi også skal tilføje hacks for at få bookmarking, history osv til at fungere på den rent javascriptgenererede side, naturligvis med de samme url'er som ikke-javascriptklienten bruger.

Ovenstående løsning har nøjagtigt samme bookmarking, history osv. som en ikke javascript løsning, der er ikke ændret ved side-konceptet, hver aspx/jsp/php side er nu en .html side

  • 0
  • 0
Jacob Christian Munch-Andersen

Peter Lundsby:

Derudover betyder metoden efter min bedste overbevisning også et performance tab, fordi indsætning af indhold hente via services, først kan ske efter DOM'en er loadet. Hvor det hvis man serverer det i selve kan renderes parallelt med resten af html'en.

Det er sjovt at du vælger at angribe ydelsen i en gren af diskussionen om mit pivhurtige eksempel.

Jeg bruger sådan set ikke asynkron indlæsning i mit eksempel, men din argumentation holder heller ikke imod applikationer som gør. Indsætning af indhold sker umådeligt hurtigt vha. JavaScript, det er nedhentningen der tager tid, og man kan fint initiere et asynkront kald længe før siden er hentet færdig.

  • 0
  • 0
Peter Lundsby

Hej Jacob

Det er mig der har sjusket med, hvad jeg svarende på, mente det egentligt som et svar på det oprindelige indlæg.

Men vi kan sagtens være enige om at det nedhentning der tager den største del af tiden.
Men man må ikke undervurderer, hvor meget tid javascript maniplulation af DOM tager, specielt i ældre browsere.

Men da det jo antageligt er samme mængde data der skal hentes og så forskellen bliver den lille bid DOM manipulation der sker til sidst.

Man kan ihvertfald ikke regne med at den asynkrone hentning af en del af indholdet vil gøre nedhentningen hurtigere. Fordi browsere kun bruger et meget begrænset tråde (vist nok 2) til at hente data. Derudover skal der betales tid for opkaldet.

Derudover er der også en problematik omkring, nedhentning af billeder i det indsætte html, dette kan jo først påbegyndes når dom'en er klar.

Så alt-i-alt tror jeg helt klart i langt de fleste tilfælde at javascript indsætning af html vil være langsommere end den normale metode.

  • 0
  • 0
Jacob Christian Munch-Andersen

Der findes også metoder til JavaScript caching af billeder som eleminerer genindlæsning mm.

Anyway, jeg tror konklusionen må være at det er stærkt afhængigt af applikationen hvad man får ud af avanceret JavaScript. Og selvfølgelig er det ikke et enten-eller valg, men et spørgsmål om hvilke dele man bruger og hvordan.

  • 0
  • 0
Jacob Christian Munch-Andersen

Et kig på fejl, mangler og uhensigtsmæssigheder på Morfik forsiden var alt hvad der skulle til for at overbevise mig om at jeg har bedre ting at spilde min tid på.

Mange foretagender kan slippe af sted med den slags, men hvis man vil levere et troværdigt webprogrammeringsværktøj må man da lave sig en ordentlig hjemmeside.

  • 0
  • 0
Jacob Christian Munch-Andersen

Omtalte Tetris klon er da vist mindstemålet for hvad man kan tillade sig at kalde et spil. Den genererede kode er overordentligt fyldig, hele 90 kB, jeg ville forvente 5 til 10 kB for en lignende applikation skrevet direkte i JavaScript uden nogen speciel fokus på minimalisme. Mangler sproget mons tro en mapper til at sortere i keydown events, eller har de bare ikke brugt den?

Spillet kører umiddelbart fint, men det er ikke rigtigt i nærheden af at afprøve Morfiks grænser.

Omtalte spil: http://www.morfik.com/downloads/Sample%20Projects/Tetris

  • 0
  • 0
Morten Marquard

På Netscape Developers Conference i 1996, jeps!, talte Marc Andreessen netop om denne model for at skabe sider. Dengang var det tanken at bruge CORBA - nu er det web services.

Vi har de sidste 4-5 år arbejdet med at skabe web-sider med indlejret funktionalitet hvor dele af siderne skabes på netop denne måde. Konsekvensen er markant forbedret performance, da det nu er klienten som laver beregningen fremfor serveren - og de fleste klienter har idag rigeligt med CPU kraft.

Kan godt se problemstillingen omkring SEO - vi udvikler imidlertid en applikation hvorfor dette ikke er et issue.

Jeg har den tommelfingerregel at udviklingstiden i AJAX (eller GWT) er 10 gange så hurtig som i .NET og at brugergrænsefladen er 10 gange så avanceret.

Vi har to versioner af nogle sider, nogle baseret på ASPX og andre på AJAX. Det er vores erfaring at AJAX opleveres hurtigere og mere fleksibelt af brugerne.

Udfordringen er at de fleste udviklere har arbejdet med ASP.NET og nu istedet skal til at skabe web services på den ene side og skabe klient, dvs javascript, applikationer på den anden side. På nogle punkter komplicerer det udviklingen - på andre sikrer det en højere standardisering af tjenester.

I relation til sky/hosting er jeg lidt i tvivl om de pågældende web services som betjener AJAX siderne også kan placeres flere steder. På den anden side sikrer opdelingen at sider/kode/billeder placeres på nogle servere (ofte flere og replikeret) mens data og logik placeres på andre.

Hvad angår mobile devices er det vores erfaring at man her alligevel skal skabe separate sider pga størrelse og funktionalitet. Fremfor at forsøge at lave web-sider til en iPhone har vi istedet skabt en specifik iPhone applikation som bruger samme web services som AJAX-web-siderne. Dermed forbedres brugergrænsefladen. Men det koster naturligvis i udviklingstid.

  • 0
  • 0
Allan Ebdrup

[quote]Nu er sagen så at hvis jeg vælger din løsning så
skal jeg faktisk lave et dobbeltbogholderi. Et site med servergenereret HTML, og et med Javascriptgenereret HTML. Pludselig dør argumentet om lettere vedligeholdelse.

Jeg siger ikke jeg har alle svarene i denne artikel, den er ment som en skør idé der kan sætte tankerne og debatten i gang.
Er du nu også sikker på at man ikke kan lave en løsning så man ikke kræver dobbeltbogholderi? Det er vildt hvad man kan med IT hvis man tænker lidt kreativt.
[/quote]

Så er løsningen jeg efterlyste kommet.
Med Node.JS og serverside JavaScript er der en der har lavet progressive enhancement med kun een JavaScript løsning:
http://ajaxian.com/archives/progressive-enhancement-using-nothing-but-ja...

Han har gjort det med Node.JS, en sindsygt spændede teknologi hvor du kører JavaScript på serveren vi Googles V8 JavaScript engine. (det foreslog jeg forresten også i denne diskusion :-)
Node.JS er desuden spændende fordi den implementerer en event-kø tankegang men non-blockin I/O oa. Det gør at der performer temmeligt godt og kan håndtere rigtigt mange requests, fordi den ikke skal holde styr på en masse tråde.

For en introduktion til Node.JS kan du se:
http://www.yuiblog.com/blog/2010/08/30/yui-theater-douglas-crockford-cro...
eller:
http://www.youtube.com/watch?v=F6k8lTrAE2g

  • 0
  • 0
Log ind eller Opret konto for at kommentere