Nyhedsbrev

Få it-nyheder og blogs hver dag og
vind en Nintendo Wii.



feeds RSS Nyhedsfeed
Ajax, RIA og usability | Allan Ebdrup
Enterprise Architect

Et Interrupt, en pipeline og en kø. Så sparker selv JavaScript r..

  

Diagram


 
 
Som du kan se på diagrammet, består løsningen af en kombination af interrups, en pipeline og en kø.

Kommentarer (9)
af Erik Cederstrand, 3. februar 2010 12:33

Rigtig godt eksempel på en enkel og velfungerende data-browser. Tak for det!

Det lader ikke til, at du selv vil promovere linket, så nu gør jeg det: http://www.obsurvey.com

Har du noget kode, man må kigge på, eller holder du kortene tæt til kroppen?
af Allan Ebdrup, 3. februar 2010 12:38

Jeg har før set blogger blive beskyldt for at være for selvpromoverende med deres egne projekter, så jeg prøver at lade være.
Ang. Kode, så holder jeg kortene til kroppen indtil videre, mit JavaScript framework er ikke open source, indtil videre.

Hvis du selv vil prøve en version af obsurvey, hvor du har de udviklerknapper "double answers", skal du logge på obsurvey, og bagefter tilføje &Test=true i URL'en. Test skal være med stort T.

V8 i Chrome? :)

Ja, men IE8 kan sagtens klare 200.000 svar også.
Men du kan prøve det selv som jeg skrev ovenfor. Jeg vil gerne høre hvad andres erfaring er med hvad deres browser kan klare.
af Peter Müller, 3. februar 2010 13:14

Ville det ikke netop være sådan et sted hvor det ville være en stor fordel at benytte sig a web workers (HTML5), worker pools (Google Gears) eller lignende og kun ved deres fravær benytte javascript egen hovedtråd til beregning?

Hvis vi snakker om hastighedsoptimeringer, så er der i hvert fald noget hente der, såvel på beregning, som på hvor responsiv brugerfladen vil være under beregning.
af Allan Ebdrup, 3. februar 2010 13:26

Jo, det kan godt være at web workes eller worker pools ville være en mere elegant løsning, men jeg skal have noget der virker i alle browsere. Jeg har lavet en generel løsning, der kan genbruges. Det hele fylder 200 linjer kode og virker som det skal. Så spørgsmålet er om fordelen ved web workes eller worker pools i dette tilfælde er så stor. I så tilfælde skulle jeg have flere kodebaser til de forskellige løsninger. Men nu har jeg mit eget API, så kan jeg jo altid portere det til web workers, når alle har en browser med HTML5.
af Peter Müller, 3. februar 2010 13:34

Det hedder progressive enhancement og webudviklere lever med det hver dag :)

I praksis er der kun en kodebase med nogle conditions afhængigt af understøttelse. Klart, der er stadig mere kode. Men det er som regel det værd at være på forkant med udviklingen.

Det er jo altid rart at brugeren med det samme kan mærke forbedringer når der skiftes browser il en nyere version.
af Allan Ebdrup, 3. februar 2010 13:44

Peter, jeg skal ikke afvise at jeg benytter web workes eller worker pools i maven på min kø hvis browseren understøtter det, hvis behovet skulle være der. Jeg ville i så fald bevare mit API, men køre forskellig kode i maven på køen.
af Peter Müller, 3. februar 2010 14:00

Det er også den måde det helst skulle pakkes ind på. I hvert fald hvis det er meningen at det her er en del af et framework som andre skal benytte.

E-mail:   Adgangskode:  
Ikke bruger? Opret en brugerkonto og deltag i debatten
Emner i denne blog