[JS] Veel objecten, autoloading?, best-practice?

[SvMp]

Ik ben een back-office systeem in Javascript aan het schrijven. Gegevensuitwisseling met database verloopt via Ajax en PHP.

Voor elk user-interface onderdeel heb ik een class, bijvoorbeeld invoervelden, selecties, maar ook geavanceerdere dingen zoals een datum-picker en een interface om afbeeldingen te linken aan content. Elke ui heeft ook weer ui-objecten in zich, zo bestaat de ui om users toe te voegen uit een flinke verzameling invoervelden.

Het werkt allemaal prima.

Maar.. het aantal objecten wordt wel groot. Ik laad nu alle Javascript-files in via de html. Dat is voor de definitieve site niet wenselijk (veel te veel requests naar server) maar tijdens development wel gemakkelijk.

Ik moet een keuze maken voor als ik 'live' ga:
- Alle Javascript-bestanden in één groot bestand plaatsen
- Kleinere Javascript-bestanden handhaven, maar dan alleen laden als ze nodig zijn

Ik neig naar alles in één groot bestand, maar vreet dat geen geheugen. Ik heb namelik het idee dat klassen definiëren ook veel geheugen kost.

Bijvoorbeeld:

JavaScript:

// UI abstract class

ui = function() { }

ui.prototype.set_error = function(msg) {
 // code
}

ui.prototype.destroy = function() {
 // code
}


// UI-class voor invoerveld

ui_invoerveld = function(jqo, params) {
    // constructor code
}

ui_invoerveld.prototype = new ui();

ui_invoerveld.prototype.select_all = function() {
 // code
}

ui_invoerveld.prototype.val = function(nieuw) {
 // code
}


// UI-class voor selectie

ui_selectie = function(jqo, params) {
    // constructor code
}

ui_selectie.prototype = new ui();

ui_selectie.prototype.optie_toevoegen = function(waarde, tekst) {
 // code
}

Code is fictief puur om te laten zien wat mijn overweging is.
Ik wil abstract klassen gebruiken. Dat gebeurt in Javascript met prototype. Om een prototype te geven moet ik van een abstract klasse bij overerving iedere keer een object maken om te voorkomen dat (in dit voorbeeld) de ui_invoerveld en ui_selectie elkaars methoden krijgen.

Stel ik heb een stuk of 30 ui-classes, wordt het geheugengebruik dan niet groot? Zelfs als ik geen objecten maak (een dialoog gebruikt maar een klein deel van de beschikbare ui-componenten), nemen de klassen al geheugen omdat bij de definitie van de overerving objecten worden gemaakt.

Als ik er voor zorg dat klassen van ui's alleen worden geladen als ze nodig zijn, dan is dat bezwaar weg, maar dan krijg je wel veel requests naar de server.

Wat is in dit geval de beste optie?

[R4gnax]

SvMp schreef op zaterdag 16 maart 2013 @ 16:44:
Wat is in dit geval de beste optie?

Het Aysnchronous Module Definition (AMD) patroon is wat je zoekt.
Kijk eens naar RequireJS.

[NMe]

SvMp schreef op zaterdag 16 maart 2013 @ 16:44:
Ik neig naar alles in één groot bestand, maar vreet dat geen geheugen. Ik heb namelik het idee dat klassen definiëren ook veel geheugen kost.

Meten is weten. Zit je nou niet moeilijk te doen voordat je weet of het nodig is? Ik zou eens beginnen met het maken van een pagina waarop je twee keer zo veel als gemiddeld aan UI-elementen aanmaakt, gebruik makend van dat grote JS-bestand. Kijk even wat dat doet met je geheugengebruik en als dat niet acceptabel is kun je dan altijd nog exotische dingen gaan doen.

[NiteSpeed]

Duidelijk een gevalletje AMD dit. Niet alleen houd je rekening met load/bandwidth, je maakt het ook makkelijk voor jezelf om het overzicht te bewaren door allemaal losse JS files te hanteren.

[curvemod]

AMD lijkt me in dit geval een mooie oplossing, waarschijnlijk wordt je code daar ook een stukje overzichtelijker van tov. één groot bestand. Als je echt exotisch wilt zou je voor de aardigheid eens naar 'Architect' van Cloud9 kunnen kijken, naar de manier waarop daarin dependencies gebruikt worden.

[pingwings]

Je zou eventueel ook een buildtool kunnen gebruiken (bijvoorbeeld http://gruntjs.com/), waarmee je de bestanden samenvoegd en minified.

Het inladen via een AMD achtige oplossing maakt het aantal requests naar de server niet minder, maar verdeeld het alleen. Een AMD-oplossing is alleen efficienter als je de meeste resources maar in sommige edge-cases inlaadt.

Wat ik meestal doe is een map maken (logic.js oid) met daarin verschillende files, zodat je de logica alsnog kan verdelen in logische stukken.

[ Voor 16% gewijzigd door pingwings op 20-03-2013 22:01 ]

[R4gnax]

pingwings schreef op woensdag 20 maart 2013 @ 22:00:
Het inladen via een AMD achtige oplossing maakt het aantal requests naar de server niet minder, maar verdeeld het alleen. Een AMD-oplossing is alleen efficienter als je de meeste resources maar in sommige edge-cases inlaadt.

*kuch*

[Anoniem: 2935]

NMe schreef op zaterdag 16 maart 2013 @ 20:25:
Meten is weten. Zit je nou niet moeilijk te doen voordat je weet of het nodig is? Ik zou eens beginnen met het maken van een pagina waarop je twee keer zo veel als gemiddeld aan UI-elementen aanmaakt, gebruik makend van dat grote JS-bestand. Kijk even wat dat doet met je geheugengebruik en als dat niet acceptabel is kun je dan altijd nog exotische dingen gaan doen.

Ik vond dat dit nog wel herhaald mocht worden.