Come usi JavaScript? [chiuso]

L'unico paradigma JavaScript che non si presta facilmente è uno troppo bloccato. Una delle cose che trovo più offensivo di Java, ad esempio, è questa idea che tutto deve avere origine con le classi, che ogni classe è in un file, che c'è una barriera inespugnabile di incapsulamento tra il tuo codice e il clistere ... Voglio dire gli altri sviluppatori del tuo team o dei tuoi clienti.

Quando tutto è forzato OOP, IMO, ciò che si finisce è un sacco di sviluppatori (non ho detto tutti o la maggior parte di loro) che non sanno quali problemi OOP dovrebbe risolvere nel primo posto. Quindi sì, il compromesso è che a volte può essere un tocco arcano ma otteniamo tutto. Otteniamo oggetti che possono avere fabbriche costruite per emulare l'OOP classico se questo è ciò che disperatamente fa galleggiare la tua barca (Crockford ammette di non aver mai usato quello che ha scritto). Otteniamo chiusure. Otteniamo funzioni di prima classe che possiamo gironzolare ovunque. Al diavolo possiamo persino riapplicare i metodi dagli oggetti come se fossero metodi di altri oggetti per capriccio. Terribile se abusato. Incredibilmente potente se usato con saggezza. Ottieni la flessibilità e la corda per impiccarti piuttosto che avere le opzioni strappate via per paura che il minimo comune denominatore si blocchi da solo.

Il problema sul rovescio della medaglia, dove JavaScript sta ovviamente, è il codice zuppa. Devi stabilire una sorta di paradigma o quello che ti ritrovi è qualcosa che non è così bello per il prossimo ragazzo da leggere o usare o modificare. La buona notizia è che puoi praticamente scegliere qualsiasi paradigma che desideri. Trovo che ciò che funziona per me al mio attuale lavoro sono strutture di oggetti app più grandi che agiscono come fabbriche, magazzini e router di eventi per interfacce basate su eventi che abilitano il disaccoppiamento totale o qualcosa che sembra e funziona più come oggetti tradizionali ma registra un nome di evento , origine e parametri passati ogni volta che si attiva un metodo a scopo di debug. Continuo a usare JQuery per portare il benessere cross-browser e la folle velocità di sviluppo nelle cose DOM nitide e grosse, ma poi seppellisco la zuppa JQ all'interno della mia architettura di app in modo che uno strumento di back-end non debba mai avere un senso da $('#someId > .someClass :first').click(function(e){.... per capire cosa diavolo sta succedendo sul front-end. Ma anche se il tuo primo tentativo di struttura assomiglia a una serie di JavaBeans di cookie-cutter, è meglio iniziare con qualcosa piuttosto che niente. Basta non impazzire con schemi di ereditarietà. Lo dico. Ovunque. Perché è la cosa più terribile che puoi fare in qualsiasi lingua e il motivo per cui avere qualcosa di meno dell'OOP classico nativo non è un grosso problema.

Il vero trucco per JS è trovare il giusto equilibrio tra struttura e interfaccia implementata in modo coerente e dare alle persone la flessibilità necessaria per utilizzare le tue cose in una varietà di modi senza trasformare il tuo codice in un pasticcio sgraziato, illeggibile. Fortunatamente, le cose brutte sono facilmente incartate, adattate e decorate in JS. Quindi come lo usi? Lo impari. Molto bene. Quindi scrivi il codice per esplorare, inventare, affermare o assimilare altri paradigmi di sviluppo nel tuo secondo il bisogno. Quello che mi piace davvero di JS è che in genere trovo che se metto un po 'di riflessione nel design, posso avere la mia torta e mangiarla anch'io. Attaccare con ASCIUTTO, accoppiamento libero e l'eliminazione della piastra della caldaia come priorità e qualsiasi paradigma che si adotta in JS è probabile che non puzzi quando si conosce bene la propria lingua. Ma c'è molto da imparare. In parte perché le specifiche aggiungono costantemente nuove funzionalità e occasionalmente eliminano quelle vecchie e ogni nuovo browser è un'avventura che aspetta di accadere.

Riguardo al funzionale rispetto a OOP, personalmente uso entrambi ampiamente. Penso che la maggior parte degli sviluppatori JS esperti facciano, senza nemmeno rendersi conto che stanno facendo qualcosa di atipico. I miei oggetti e costruttori informano l'architettura e i blocchi che tendono ad interagire l'uno con l'altro. La natura funzionale di JS rende possibile avere la natura di come questi oggetti interagiscono essere tutto ciò che voglio.

Uso un buon framework JavaScript, come jQuery o Prototipo . Dovrebbe cambiare la tua impressione negativa di JavaScript in generale. Ha fatto molta strada nel corso degli anni e ne vale sicuramente la pena.

Direi anni fa, JavaScript era per rendere le cose lampeggianti sullo schermo e per creare fantastici trailer del mouse (per gli sviluppatori generali dell'epoca), e per insegnare pazienza agli sviluppatori ..

Quindi l'Ajax ha guadagnato popolarità, consentendo a Javascript di gestire i dati. Javascript era un vero dolore perché all'epoca era così rudimentale e quando disponevamo di strumenti come Visual Studio che fornisce grande intelligenza per i linguaggi .NET, rispetto a Javascript che aveva poco o nulla, era davvero un'esperienza orribile onestamente .. la maggior parte dei miei pari odiava JavaScript allora ..

Poi è arrivato jQuery ... Ho detto al mio capo un paio di anni fa che è meglio imparare JavaScript (io C #, lui VB), perché jQuery ha preso tutto il lavoro da JavaScript e ci ha dato alcune funzionalità davvero interessanti.

Ora abbiamo cose come Node.js, che è tutto JavaScript, sia client che server .. Non ho intenzione di entrare in quello .. e non sono sicuro di quello che provo per quello .. ma è sicuramente una piena materializzazione di JavaScript sul Web comunque ..

Ricordo di aver sentito parlare di Enyo e WebOS, che era praticamente JavaScript, e Windows 8 è piuttosto JavaScript friendly come detto ...

E ho quasi dimenticato di menzionare JSON .. JSON è un ottimo modo per trasmettere dati in giro .. di nuovo, bello lavorare con il lato client, e DB come Mongo sembrano apprezzare molto la tecnologia

Quindi per uso chiedi ?? Direi che è come un coltellino svizzero .. alcuni possono dire che HTML con JavaScript è tutto ciò di cui hai bisogno se abbinato a un buon livello di servizio Web. Penso che ci sia sicuramente spazio per un strong piattaforma base (asp.net, e altri ..) ma a ciascuno il suo

IMO, penso che abbia il suo posto sul lato client delle cose .. è ottimo per fare gli aggiornamenti dell'interfaccia utente .. ottimo per creare postback "Parziali" e accedere a un archivio dati locale (sul client) .. e ora con HTML 5, lo vedo davvero come "Flash Killer" .. probabilmente inizieremo a vedere di nuovo l'intro con un pulsante di salto .. lol .. quelli erano i giorni freddi ..

Per applicazioni e applicazioni a singola pagina come quella ... dovrebbe essere considerato con uno dei framework là fuori come backbone o uno degli altri (c'è un tono) .. La sicurezza è qualcosa da tenere a mente, così come latenza .. ma tutto cambierà di importanza in base al progetto in corso ..

Quindi direi che è un mix di preferenze e l'applicazione a portata di mano.