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
person
Blogindlæg3. februar 2010 kl. 11:39
errorÆldre end 30 dage
person

  

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
Erik Cederstrand
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?

  • more_vert
    • insert_linkKopier link
2
Allan Ebdrup
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.

  • more_vert
    • insert_linkKopier link
5
Peter Müller
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.

  • more_vert
    • insert_linkKopier link
6
Allan Ebdrup
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.

  • more_vert
    • insert_linkKopier link
7
Peter Müller
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.

  • more_vert
    • insert_linkKopier link
8
Allan Ebdrup
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.

  • more_vert
    • insert_linkKopier link
9
Peter Müller
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.

  • more_vert
    • insert_linkKopier link
4
Allan Ebdrup
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.

  • more_vert
    • insert_linkKopier link