Rendering JavaScript lato server

Naviga le tue risposte
1

Ho quasi una domanda sulle "migliori pratiche" che mi ha tormentato per un po '.

Quando utilizzo librerie e API JavaScript come JQGrid o Google Maps, tendo a trovarmi creando librerie lato server per rendere il JavaScript per me.

Ad esempio potrei avere: 

$map->setZoom(10);
$map->setDimensions(200,250);

in PHP, che renderebbe internamente il JS pertinente quando chiamo $map->render(); , ad esempio.

Ciò significa che posso generare facilmente JavaScript in base allo stato delle mie applicazioni. Trovo anche più facile lavorare con i dati che ho già nei miei controller ecc.

Questo è un modo appropriato di utilizzare le funzionalità comuni all'interno di una libreria JavaScript o sarebbe meglio scrivere JS come standard?

    
posta James 01.02.2013 - 19:01
fonte

3 risposte

3

Primo problema: qualità del codice

Come stai:

  • unit test,

  • di debug,

  • esamina per problemi di sicurezza,

questo codice generato?

Il problema è lo stesso per tutti i codici generati. Ecco perché gli strumenti di generazione del codice vengono utilizzati solo per attività semplicistiche in cui il codice è per lo più boilerplate.

Ad esempio, nel mondo .NET, Visual Studio genera codice per Windows Form ed è limitato al posizionamento e alla personalizzazione dei controlli, ma non è tecnicamente impegnativo. Allo stesso modo, Entity Framework genera i mapping per il database, che significa linee e righe di codice piatto, non interessante, monotono.

Secondo problema: prestazioni

Se il codice viene generato, come lo metti in cache? E 'almeno in cache? In caso contrario, hai misurato l'impatto preciso sulle prestazioni, rispetto al codice JavaScript statico correttamente inserito nella cache? Che dire dell'impatto sul server che deve generare questo codice e in che modo scala?

In alcuni casi questo problema potrebbe essere inesistente (o almeno il leggero impatto sulle prestazioni è molto limitato dal caching grave e pochi millisecondi spesi dal server che genera i file è superato dai guadagni in termini di tempo che si spendono scrittura del codice), ma è comunque necessario misurare l'impatto per sapere esattamente come influisce sulla tua applicazione.

Terzo problema: minore interoperabilità

Il codice JavaScript scritto in JavaScript può essere utilizzato indipendentemente dal framework utilizzato sul lato server. Il codice JavaScript che ho scritto per un sito Web ASP.NET MVC due anni fa può ancora essere utilizzato per un nuovo sito Web in Python.

Se il codice viene generato lato server utilizzando il linguaggio di programmazione lato server, non sarà possibile riutilizzare lo stesso codice in siti web alimentati da altri linguaggi di programmazione. Inoltre, anche la migrazione a versioni più recenti dello stesso framework può essere dolorosa.

    
risposta data 01.02.2013 - 19:34
fonte
0

Converto i dati in JSON sul server utilizzando una serie di "plug-in" che convertono i set di dati standard in più stili di JSON. Ciò mi consente di convertire i dati in oggetti, array di array o formati personalizzati (come quelli usati da DataTables). Il mio livello dati non deve cambiare, ho appena spento il formattatore JSON quando necessario.

    
risposta data 02.02.2013 - 00:21
fonte
0

La latenza della rete deve essere la principale preoccupazione dello sviluppo web. Quindi non è saggio cambiare i file js memorizzati nella cache dal browser in base agli input dell'utente.

I dati e la logica comprendono il mondo. Lo stato della tua applicazione è in realtà i dati, lascia che i dati cambino nel tempo istruendo la tua logica per fare il lavoro. Questo non ti sta dicendo di spingere tutta la logica verso i clienti, ma di spingere ciò di cui hanno bisogno.

    
risposta data 02.02.2013 - 02:43
fonte

Leggi altre domande sui tag

Test per confermare il messaggio con un componente casuale Se sei uno sviluppatore .NET, ottenere il certificato Microsoft Certified Master SQL Server 2008 ha senso? [duplicare]