allan ebdrup bloghoved ny

JavaScript måske på vej med observable objekter

I 2009 skrev jeg et blogindlæg med titlen Den feature jeg savner allermest i JavaScript.
Det handlede om, at gøre de indbyggede JavaScript objekter observable.

Nu ser det ud til at jeg måske får min vilje. Object.observe er ihvertfald i spec development

Hvad synes du?

Vil du også gerne have observable indbyggede JavaScript objekter?

Opdatering: Jeg fandt en video der viser hvad det går ud på:

Opdatering 2: Der er også mulighed for at lytte på DOM'en, og det er allerede i Chrome of FireFox:

Kommentarer (11)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Ole Østergaard

Har du prøvet Angular? Det 'løser' problemet med helt almindelige 'POJSOs' (eller hvad man nu skal kalde dem... helt almindelige JS-objekter). Det er fikst, og jeg savner ikke 'observables'.

  • 0
  • 0
Allan Ebdrup Blogger

Ja, den teknik er de ikke de første med, det har været brugt i mange år. Min anke ved metoder er blandt andet:

1) Koden bliver ikke lige så elegant og du skal overholde diverse hjemmestrikkede konventioner og implementationer, der er forskellige for hvert framework

2) Når du modtager JSON fra serveren bliver du nød til at transformere det resulterende objekt til dit frameworks model, med komplekse modeller kan det godt både kræve meget kode og være errorprone. Det tilfører unødig kompleksitet og du skal gøre det igen og igen.

3) Du kan ikke lytte på ændriner i objekter styret af tredieparts biblioteker.

  • 0
  • 0
Ole Østergaard

Øhh... jeg er ikke helt med. Hvad er det for en metode du refererer til? Der er netop ikke noget specielt du skal overholde i Angular. Og hvorfor vil du transformere JSON? Og hvad har det med tredjepartslibraries at gøre?

Jeg tror du tænker på Backbone, Ember, Knockout eller nogen af de andre (i min optik mere kluntede) frameworks som netop kræver at du bruger deres kode til at implementere 'observables'?

  • 0
  • 0
Allan Ebdrup Blogger

Ja der var jeg lidt for hurtig. AngularJS bruger dirty checking varianten og er en lille smule anderledes end de andre. Angular har sine egne konventioner, der som med alle frameworks er lidt forskellig fra de andre. Den har dog sine egne begrænsninger (Det bliver også nævnt i den første video).

Et af dem er performance, hvis man er uheldig får man pluselig en app der er langsom.

Et andet er detaljegraden, når du lytter præcist på de operationer der bliver lavet på en model kan du sige præcist hvordan et objekt er blevet ændret, det gør at du kan lave mere optimale (og minimale) ændringer af DOM'en

Et tredie er humkommense, angular bliver nød til at have en ekstra kopi af din model for at checke om noget er ændret.

Et fjerde er at dirty checking kan give udfordringer hvis du har kaskader af ændringer i mere komplekse modeller.

Jeg har bygget applikationer hvor angulars metode ikke kan bruges pga modellens størrelse og kompleksitet.

Alle disse problemer ville forsvinde fra angular, hvis de brugte indbyggede JavaScript observables.

Edit: Jeg vil faktisk være overrasket hvis ikke dem der bygger AngularJS har en finger med i spillet i denne spec.

  • 0
  • 0
Ole Østergaard

Detaljegraden kan også være et problem, og kan give performanceproblemer hvis man reagerer på enhver lille ændring i fx et array.

Hukommelse tvivler jeg på er et problem. At modellen gemmes to gange, tror jeg kun i meget ekstreme tilfælde er et problem i forhold til hvad der ellers genereres af objekter, DOM-manipulation osv. i sådan nogle JavaScript-frameworks (men det er rent gæt, jeg har ingen tal).

Der er en meget god beskrivelse af hvorfor det kan være et problem med "change listeners" og hvorfor Angulars tilgang performancemæssigt er fin her: http://stackoverflow.com/questions/9682092/databinding-in-angularjs

(Jeg ved godt at anken om syntaks i det refererede indlæg ikke er relevant i denne diskussion.)

Selvfølgelig har Angulars tilgang også sine problemer, men umiddelbart er jeg rigtig godt tilfreds med den. Og savner af den grund heller ikke rigtige "observables". Men de fleste andre tilsvarende frameworks vil da helt klart blive noget kønnere hvis "observables" blev bygget ind i sproget.

  • 0
  • 0
Allan Ebdrup Blogger

Detaljegraden kan også være et problem, og kan give performanceproblemer hvis man reagerer på enhver lille ændring i fx et array.

Helt sikkert, men med inbyggede observable objekter skulle du gerne have valget om du vil eller ikke vil have detaljerne.

Hukommelse tvivler jeg på er et problem. At modellen gemmes to gange, tror jeg kun i meget ekstreme tilfælde er et problem i forhold til hvad der ellers genereres af objekter, DOM-manipulation osv. i sådan nogle JavaScript-frameworks (men det er rent gæt, jeg har ingen tal).

Som sagt så har jeg bygget applikationer hvor hukommelsen spiller en rolle, en fordobling af hukommelsesforbruget er i visse tilfælde ikke en mulighed. Men det er nok en af de mindre ting.

Der er en meget god beskrivelse af hvorfor det kan være et problem med "change listeners" og hvorfor Angulars tilgang performancemæssigt er fin her:

Ja det er en god forklaring. Jeg vil nu udlægge det som at gennemgangen forklarer hvor tilgangen i de fleste tilfælde er fin. Men vi presser hele tiden grænserne i browseren, og til nogle ting vil det ikke virke.

Min påstand vil være at du, pga de issues jeg nævner, ikke kan bygge en applikation som fx google docs i AngularJS. Ihvertfald ikke uden at gøre seriøst vold på den måde det fungerer.

Selvfølgelig har Angulars tilgang også sine problemer, men umiddelbart er jeg rigtig godt tilfreds med den. Og savner af den grund heller ikke rigtige "observables".

Det kan jeg godt forstå, der virker også som et framework med mange fordele. Det er dog godt at kende dets begrænsninger og vælge det rigtige framework til opgaven.

(Eller vente på observable objekter, så kan du bygge det hele i AngularJS :-)

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