Archief - Grafische widgets

Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.

WHiSPy

Legacy Member
Hetgeen ik mij nu al 'n tijdje af vraag: wat zou er eigenlijk 't efficiëntste zijn: de widgets van ajax frameworks gebruiken om grafieken voor te stellen of gewoon in de back-end van je applicatie eenmalig die grafiek genereren en deze telkens doorsturen?

widgets:

voordelen
- Geen extra schijfruimte nodig op je filesystem.
- Dynamisch: als je 'n wijziging aan je algoritme aan brengt, dan zijn er geen grafieken in het oude formaat.
- Je kan er indien nodig een paar fancy dingen mee in proberen te stoppen.

nadelen
- Elke keer weer zoveel data over the wire sturen om dezelfde grafieken te genereren.
- Verlies van functionaliteit bij disabled javascript of trage pc/verbinding.
- Kan eventueel error-prone zijn als je 'n network hickup hebt en dus niet alle data wordt doorgestuurd.
- Je hebt geen garantie dat die widget 100% zeker cross-browser en backwards compatible is.
- Geen zekerheid dat de widget ook 100% bugvrij is.

Generatie in back-end

voordelen
- Je kan 't asynchroon in gang zetten en gaat dus de gebruiker minder lang moeten laten wachten.
- Caching van de grafieken op zowel client als server-kant mogelijk.
- Je weet op voorhand hoeveel data je over the wire moet sturen (en deze is telkens hetzelfde voor dezelfde image).
- Gegarandeerd cross-browser.

nadelen
- Indien je applicatie qua data serieus groeit, dan heb je veel meer schijfruimte nodig.
- Images kunnen ook vrij groot zijn waardoor je misschien toch nog meer data over the wire moet sturen.
- Zou perfect kunnen dat je na verloop van tijd met 2 verschillende stijlen van images zit in je applicatie. Dit zou je echter kunnen vermijden door alle images misschien even opnieuw te laten genereren om de x tijd. (ten koste van extra cpu-time)
- Beperkte mogelijkheid tot "fancy" dingen.

Zitten er hier web 2.0 mensen die zich ook al deze vraag gesteld hebben en hun oordeel hierover hebben kunnen vellen? Ter illustratie voor de mensen die mijn profiel niet kennen: ik ben zelf een developer die liefst aan de back-end van een systeem werkt. Echter besef ik ook wel dat alles in de back-end steken niet altijd de ideaalste manier van werken is, dus stel ik de vraag hier maar even.

Momenteel neig ik naar het back-end idee omdat schijfruimte nog altijd goedkoper is dan bandbreedte.

Enlighten me! Ik hoop dat er hier ondertussen sinds de periode dat ik hier vaak kwam en postte de nodige talenten zijn opgedoken waar ik de nodige dingen van kan leren. (waar is de tijd met brainscan, symbi, lo_fi, etc :))

n00bslayer

Legacy Member
Je voor- en nadelen kloppen niet helemaal, maar m.i. wordt pure data nog altijd het best via de back-end aangeleverd waar de client het presentatiewerk voor z'n rekening neemt.

Waarom zou svg er anders zo hard zitten aankomen.

Op dit moment nemen Flash & Html + Javascript dit nog voornamelijk voor hun rekening, in de toekomst zullen er nog meer alternatieven voorhanden zijn. De server hoeft imho maar tot op een bepaalde hoogte het rekenwerk van een client te verrichten, en een presentatielaag bovenop aangeleverde data hoort volgens mij ook bij.

Op kleine schaal is het geen probleem om voor alle mogelijke weergaven van data een afbeelding te genereren, maar eens je een bepaald plafond bereikt hebt zal er weinig anders opzitten dan dat rekenwerk uit te besteden vrees ik.

WHiSPy

Legacy Member
n00bslayer zei:
Je voor- en nadelen kloppen niet helemaal, maar m.i. wordt pure data nog altijd het best via de back-end aangeleverd waar de client het presentatiewerk voor z'n rekening neemt.

Waarom zou svg er anders zo hard zitten aankomen.

Op dit moment nemen Flash & Html + Javascript dit nog voornamelijk voor hun rekening, in de toekomst zullen er nog meer alternatieven voorhanden zijn. De server hoeft imho maar tot op een bepaalde hoogte het rekenwerk van een client te verrichten, en een presentatielaag bovenop aangeleverde data hoort volgens mij ook bij.

Op kleine schaal is het geen probleem om voor alle mogelijke weergaven van data een afbeelding te genereren, maar eens je een bepaald plafond bereikt hebt zal er weinig anders opzitten dan dat rekenwerk uit te besteden vrees ik.

Open discussie op zich, hé. Dat bepaald plafond is ook altijd relatief: je kan perfect programmatorisch alles asynchroon laten gebeuren waardoor je requests op 'n normale manier afgehandeld worden. (ik denk maar aan 'n grid architecture waar je grote hoeveelheden data kan laten verwerken)

Moet eerlijk zijn: als developer heb ik 't nog een beetje moeilijk om zo'n handelingen uit handen te geven. Vooral omdat ik geen garantie heb dat die widget 100% failsafe gaat werken. (en 'n gebruiker haat natuurlijk wel functionaliteit die niet volledig werkt)

Conclusie is dat 'k dus een PoC ga maken waarbij 'k zelf een grafiek genereer van 'n hoeveelheid data en 'k dus een beetje load daarop ga zetten om te zien hoe performant dat is. :)
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
Terug
Bovenaan