Dette indlæg er alene udtryk for skribentens egen holdning.

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

10 kommentarer.  Hop til debatten
Blogindlæg3. februar 2010 kl. 11:39
errorÆldre end 30 dage

  

Diagram


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

10 kommentarer.  Hop til debatten
Fortsæt din læsning
Debatten
Log ind for at deltage i debatten.
settingsDebatindstillinger
1
3. februar 2010 kl. 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?

2
3. februar 2010 kl. 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.

5
3. februar 2010 kl. 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.

6
3. februar 2010 kl. 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.

7
3. februar 2010 kl. 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.

8
3. februar 2010 kl. 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.

9
3. februar 2010 kl. 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.

4
3. februar 2010 kl. 13:12

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.