Perché JavaScript non viene utilizzato per lo sviluppo di applicazioni classiche (software compilato)? [chiuso]


14

Durante i miei anni di sviluppo web con JavaScript, sono giunto alla conclusione che è un linguaggio incredibilmente potente e puoi farci cose incredibili.

Offre un ricco set di funzionalità, come:

  • Digitazione dinamica
  • Funzioni di prima classe
  • Funzioni nidificate
  • chiusure
  • Funziona come metodi
  • Funziona come costruttori di oggetti
  • Prototype-based
  • Basato su oggetti (quasi tutto è un oggetto)
  • regex
  • Letterali di array e oggetti

Mi sembra che quasi tutto possa essere realizzato con questo tipo di linguaggio, puoi anche emulare la programmazione OO, poiché offre grande libertà e molti stili di codifica diversi.

Con più funzionalità personalizzate orientate al software (I / O, FileSystem, dispositivi di input, ecc.) Penso che sarà fantastico sviluppare applicazioni con.

Anche se, per quanto ne so, è usato solo nello sviluppo web o nei software esistenti solo come linguaggio di scripting.

Solo di recente, forse grazie al motore V8, è stato usato di più per altri tipi di attività (vedi ad esempio node.js).

Perché fino ad ora è relegato solo allo sviluppo web? Cosa lo tiene lontano dallo sviluppo del software?


8
Se lo sviluppo web non è (un caso speciale di) sviluppo software, di cosa si tratta esattamente? ...
Péter Török,

@Péter Török: penso che tu abbia capito il punto. Quello che voglio dire è che fino ad ora è stato utilizzato solo come linguaggio di scripting dai software, per migliorare le funzionalità. Non è mai stato utilizzato per programmare effettivamente un'applicazione software per un sistema operativo.
Jose Faeti,

4
Vedo la digitazione dinamica come un grosso svantaggio e vorrei anche liberarmi di valori nulli.
Jonas,

2
Intendi "sviluppo di applicazioni classiche", non "sviluppo di software", giusto? Meglio cambiare di conseguenza la rotta.
Doc Brown,

2
@JoseFaeti per il record di Windows 8 ti permette di fare un po 'di sviluppo in HTML5 e JS
Raynos

Risposte:


14

Di recente node.js ha portato avanti lo sviluppo lato server. Quindi, ora è possibile scrivere JavaScript, per lo sviluppo.

È vero. Nella storia, non è stato usato come linguaggio di sviluppo. Ma, ehi, anche lo scripting nell'ambiente client (User Agent) è un tipo di sviluppo. No?

Il motivo principale che ho sentito e letto in molti blog, è che le persone non sapevano del suo potere e della sua unicità fino agli ultimi anni . Ciò che fece accadere questo, fu forse che altre lingue stavano facendo il loro lavoro abbastanza bene, e nessuno aveva mai pensato di fare qualcosa di parallelo.


Deve essere così, e sembra che qualcosa si stia muovendo adesso :)
Jose Faeti,

15

Da qui :

Nota che sto basando tutti i miei argomenti su casi d'uso reali. Gli argomenti controversi di cui non è possibile eseguire il backup con un esempio di utilizzo in applicazioni reali, complete, interessanti e utili non sono validi. Ho visto le piccole "dimostrazioni linguistiche" che hanno tutti gli altri, ho visto i post sul blog che descrivono in dettaglio come prototipi e tipizzazione dinamica rendono un piccolo esempio banale alcune righe più brevi di quanto sarebbe in C #, ma quelli semplicemente non sono rilevanti ai problemi che si incontrano nella scrittura di codice reale anziché in micro-demo e giocattoli. Quindi ecco le mie lamentele con JS:

a) Magia "questo". Questo è questo, tranne quando questo è quello. JavaScript ti spinge a utilizzare funzioni anonime in tutto il luogo, tranne per il fatto che finiscono sempre per perdere il contesto appropriato per la variabile 'this', quindi finisci per avere un codice sciocco come "var _this = this" in tutto il luogo e quindi usarlo all'interno dei callback o di altre funzioni. Alcuni giorni giuro che il numero di funzioni che riesco a scrivere che non usano un rinominato 'this' sono in realtà inferiori al numero che lo fanno.

b) 1 + "1" - 1 = 10. Inoltre, "1" + 0 = "10". Sì, questo ha effettivamente causato bug per le nostre applicazioni, in cui i dati che si prevede fossero un numero sono stati caricati da un file JSON come stringa a causa di un bug in un'altra applicazione e il risultato non è stato buono. Tutto il nostro codice di caricamento ha dovuto essere aggiornato per aggiungere un sacco di conversioni di tipo in tutto il luogo. Quando ho bisogno che qualcosa sia un numero, voglio davvero che sia un numero, non una stringa o un oggetto o null o altro. Lua, che è molto simile a JavaScript per molti aspetti, ha risolto questo problema semplicemente non essendo ritardato abbastanza da usare lo stesso operatore per l'aggiunta e la concatenazione di stringhe.

c) Global per variabili di default. Quindi, anche se prendi l'argomento che la digitazione dinamica è semplicemente "più facile" perché non devi pensare alle dichiarazioni delle variabili, JavaScript lancia quell'argomento fuori dalla finestra facendoti mettere 'var' davanti a nuovi identificatori ovunque . E poi ti avvita in silenzio se te lo dimentichi.

d) Prototipi anziché classi. Esistono pochissime applicazioni JavaScript nel mondo reale su larga scala che non collegano il proprio sistema di classe per aggirare l'inutilità intrinseca dei prototipi nell'architettura di applicazioni di grandi dimensioni. Quelle stesse app fanno un uso minimo dei prototipi per estendere i tipi JavaScript di base e solo perché JS è stato progettato in modo così poco accurato che anche i due interessanti tipi incorporati che ne derivano mancano della metà delle funzionalità che ti aspetteresti di avere.

e) Impossibilità di creare tipi pass-by-value. Questo è un problema frequente in quasi tutte le lingue a parte C ++ / D, in realtà. Per coloro che utilizzano JavaScript per scrivere app WebGL, dai un'occhiata a tutte le librerie di algebra lineare per JavaScript. Nelle app 3D, usi quasi sempre i vettori più spesso degli scalari. Immagina se ogni numero intero nella tua app è stato passato per riferimento, in modo che "a = 1; b = a; b ++" rendesse sia a che b pari a 2. Ogni piccolo vettore a tre componenti è un oggetto completo completo. Sono passati per riferimento (la fonte di quasi la metà dei bug nel nostro gioco WebGL finora, in effetti). Esistono in grande quantità, sono allocati in heap e vengono raccolti in modo inutile, il che esercita un'intensa pressione sul GC che può e provoca pause GC anche in semplici giochi WebGL, a meno che lo sviluppatore non salti attraverso cerchi ridicolmente complicati per evitare di creare nuovi vettori in tutti i luoghi in cui è logico creare nuovi vettori. Non puoi avere un sovraccarico da parte dell'operatore, quindi hai espressioni molto grandi e brutte per eseguire le operazioni di base. L'accesso ai singoli componenti è lento. Gli oggetti non sono impacchettati in modo nativo e quindi sono incredibilmente lenti a inserirsi in un buffer di vertici, a meno che non li implementi come istanze Float32Array, che attualmente confondono la merda degli ottimizzatori di V8 e SpiderMonkey. Ho già detto che sono passati per riferimento? L'accesso ai singoli componenti è lento. Gli oggetti non sono impacchettati in modo nativo e quindi sono incredibilmente lenti a inserirsi in un buffer di vertici, a meno che non li implementi come istanze Float32Array, che attualmente confondono la merda degli ottimizzatori di V8 e SpiderMonkey. Ho già detto che sono passati per riferimento? L'accesso ai singoli componenti è lento. Gli oggetti non sono impacchettati in modo nativo e quindi sono incredibilmente lenti a inserirsi in un buffer di vertici, a meno che non li implementi come istanze Float32Array, che attualmente confondono la merda degli ottimizzatori di V8 e SpiderMonkey. Ho già detto che sono passati per riferimento?

f) Nessuna funzionalità integrata inclusa o richiesta. Seriamente, ancora. Esistono librerie di terze parti, ma quasi tutte hanno qualche tipo di bug o un altro, non ultimo il che è un problema di caching confuso in almeno Chrome che rende lo sviluppo reale un problema nel culo.

g) Digitazione dinamica. Sì, sono disposto a iniziare questa discussione. Inizi a notarlo al massimo nel momento in cui smetti di scrivere piccole app Web o pagine Web e inizi a scrivere app di grandi dimensioni in cui hai effettivamente dati che persistono più a lungo di un singolo clic del mouse o ciclo di richiesta / risposta: aggiungi un tipo di oggetto errato a un array da elaborare in seguito e ottenere un arresto in seguito da un metodo o membro mancante in un bit di codice completamente diverso rispetto a dove si trovava l'errore effettivo. Momenti divertenti. Sì, Java rende la digitazione statica malvagia. No, Java / C # / C ++ non è l'unico modo per eseguire la digitazione statica. L'inferenza del tipo, l'associazione implicita dell'interfaccia, ecc. Offrono tutti i vantaggi "facili da gestire e non molti tasti" della digitazione dinamica senza tutti i bug. Il secondo linguaggio Web più popolare - ActionScript 3 - è tipicamente statico, in realtà, sebbene diversamente identico a JS / ECMAScript. A parte questo, ottengo più arresti anomali dalle app Python sul mio desktop Fedora rispetto alle app C / C ++ (in realtà, nessuna delle app C / C ++ sul mio desktop crash, ora che ci penso). Eccezioni dei membri mancanti == molto più semplice da sviluppare e gestire app, giusto?

h) Velocità. Sì, c'è stata una quantità ridicolmente immensa di sforzi da parte di un gran numero di sviluppatori super-maledetti messi nei runtime linguistici per rendere JS quasi la metà più veloce di un compilatore C di basso livello che un singolo college universitario potrebbe scrivere in pochi mesi. E LuaJIT è nella stessa barca di JS in termini di limiti linguistici fondamentali, ma riesce comunque a fare meglio di ogni implementazione JavaScript. Le persone che non capiscono cosa fanno effettivamente tutte le ottimizzazioni di JS in V8 o similipiace affermare che JS può fare cose sorprendenti in termini di velocità, ma la realtà è che tutte queste ottimizzazioni sono fondamentalmente solo "provate molto molto duramente per analizzare il codice per capire i tipi di variabili e quindi compilarlo come un tipo statico leggermente ritardato il compilatore di language lo farebbe ". Oh, e c'è traccia, ma poi la traccia funziona anche su linguaggi tipicamente statici (e funziona meglio a causa della mancanza di protezioni dei tipi nel codice macchina generato). In realtà, nessuna di quelle ottimizzazioni di whizbang è stata inventata da o per JS; la maggior parte sono stati presi dalla ricerca JVM (Java è il male!) o dai linguaggi OOP classici (i prototipi sono fantastici!).

i) Nessun IntelliSense è nemmeno possibile. Vuoi vedere quali metodi esistono su quella variabile che hai nella riga 187 di foo.js nel tuo editor di testo? Peccato. Segui il codice fino a quando non scopri dove è stato inizializzato, quindi segui il codice per scoprire che cosa contiene il suo prototipo. E poi spero che non ci sia codice che cambi dinamicamente il prototipo alle tue spalle. In effetti, basta eseguirlo in un browser e impostare punti di interruzione, perché scoprire qualcosa di utile sul valore in qualsiasi altro modo è praticamente impossibile per qualsiasi base di codice più grande dei siti toy_web_app.html che gli apologeti JavaScript utilizzano per glorificare la facilità e la semplicità di JavaScript. Alcuni editor di codici si sforzano davvero di fare meglio, e quasi in qualche modo riescono per i casi davvero semplici, a volte, una volta.

j) Nessun vantaggio. JavaScript non è nemmeno speciale rispetto ad altri linguaggi tipizzati dinamicamente. Non è in grado di fare nulla di interessante affatto che non può essere fatto anche da Lua, Python, Ruby, ecc. Nessuna delle implementazioni JS è più veloce di LuaJIT o PyPy o varie altre implementazioni JIT avanzate di altre dinamiche le lingue. JS non ha lati positivi rispetto ad altre lingue comunemente disponibili. Oh, tranne che funziona nativamente in un browser Web senza plug-in. Qual è l'unica ragione al mondo per cui è così popolare. In effetti, è l'unica ragione per cui esiste un evento. Se qualcuno 10 anni fa aveva appena pensato "diamine, lasciamo cadere nel nostro browser un linguaggio ben progettato e consolidato e facciamo in modo che gli altri ragazzi facciano lo stesso invece di far usare a tutti questo stupido hackjob con cui NetScape ha inventato , "il Web sembrerebbe molto diverso (meglio) oggi. Immagina il futuro se Chrome rilascia Python in Chrome come lingua supportata. O in realtà, immagina questo: Google rilascia C / C ++ in Chrome come lingua supportata (http://code.google.com/p/nativeclient/).


Questo è un post davvero interessante. Sarei curioso di vedere i suoi casi d'uso che costituiscono la base dei suoi argomenti. Non sono in disaccordo con i suoi punti, ma ho sviluppato applicazioni JS di dimensioni aziendali per quasi 10 anni e non ho sperimentato alcune delle cose che ha menzionato (in particolare, il suo primo punto su "questo magico"). Seguendo la mia esperienza, argomenti contro javascript come quelli in questo post tendono a essere fatti da persone con un pesante background tradizionale oop ... nel qual caso, capirei la sua confusione.
Mr. JavaScript

È abbastanza interessante vedere che nel 2016 la risposta è ora completamente obsoleta dall'evoluzione del linguaggio.
Stephan Bijzitter,

@Sig. JavaScript Ciao. Conoscete una serie di tutorial che si concentrano sulla risoluzione di esempi di problemi del mondo reale piuttosto che sull'esplorazione di JavaScript e delle sue caratteristiche e meccanismi? Non ho avuto fortuna con le ricerche di parole chiave. Ad esempio, invece di passare attraverso un link tutorial così dettagliato e i suoi milioni di esempi e funzionalità, dove trovo un repository di piccoli tutorial su come realizzare un'applicazione GUI per gestire alcuni sistemi assicurativi o medici o scuole o una parte operativa di un supermercato? Grazie
Giosuè l'

12

Perché?

JavaScript è il linguaggio più frainteso

Eravamo nell'era buia e siamo ancora alla comunità di sviluppo generale ad accettare che JavaScript è un linguaggio potente e versatile. Semplicemente non è mainstream.

L'unico progresso recente è che node.js è diventato vivace e le persone stanno iniziando ad accettare che javascript abbia altri usi.

Ho tenuto d'occhio lo sviluppo di JS e HTML5 per Windows 8 e la reazione della comunità .NET è stata "caro dio perché?".

È semplicemente un dato di fatto che la maggior parte degli sviluppatori non web continua a vedere JavaScript come quel linguaggio giocattolo che usi per far scorrere i menu nei tuoi browser.

Certamente JavaScript non si allinea alle "pratiche di sviluppo moderne". Per me JavaScript è ancora un linguaggio di hacking che creo con Vim e Internet è la mia documentazione. Non esiste un IDE, non ci sono strumenti di sviluppo, non c'è il completamento automatico o "intellisense", non ci sono GUI click and drag.

Nel mondo degli sviluppatori Java e .NET sono collegati alle loro GUI e IDE e non sarebbero in grado di programmare in vim.


1
Sono d'accordo con te ad eccezione di "Non esiste un IDE, non esistono strumenti di sviluppo, non esiste il completamento automatico o" intellisense ", non vi sono GUI con clic e trascinamento." In realtà puoi ottenere tutto ciò usando molti vari IDE là fuori, io uso Visual Studio per esempio ed è semplicemente fantastico.
Jose Faeti,

1
@JoseFaeti scusate, Visual Studio non è un IDE javascript. Sono più veloce in vim che in VS2010. Ciò significa che VS2010 è un IDE JS che perde.
Raynos,

2
@Raynos, "Sono più veloce in vim che in VS2010. Ciò significa che VS2010 è un IDE JS che perde." - o forse questo significa semplicemente che non conosci VS e vim.
Péter Török,

2
Assolutamente no, ma non costruirò un frontend RIA in Silverlight perché adoro Resharper e LINQ, o l'app ASP.Net MVC con un sottile livello jQuery, perché di nuovo è .Net friendly, quando ci sono linguaggi Javascript lato client ricchi a portata di mano che sono più adatti per il lavoro.
sa93,

1
Sto solo aggiungendo la mia voce al coro di persone che affermano che ci sono IDE JavaScript. È francamente sciocco affermare il contrario. Gli IDE potrebbero non piacerti e potrebbero non essere perfetti, ma sono comunque IDE. O ho immaginato il completamento dell'intelligenza e del codice di VS quando lavoravo con JS?
Ian Newson,

10

Il tuo elenco non contiene nulla sulla scrittura di file sul sistema, che è una parte enorme dello sviluppo del software.

Le persone non penserebbero di usare JS per creare un'applicazione perché è il linguaggio di script di fatto per il web e useresti sempre lo strumento giusto per il lavoro.

Perché scrivere acri di JS per scrivere un file quando si tratta di un'operazione banale in Java / .NET / C / C ++?

Detto questo, come altri hanno già detto, node.js e le sue librerie hanno reso banali le operazioni lato server e con node.js stanno diventando popolari, imparando che diventerà un'abilità per un CV, dal momento che sarai in grado di mantenere / estendere / costruire applicazioni con esso.


1
+1 ha completamente dimenticato quanto sia importante una libreria stdio.
Raynos,

1
Per quanto riguarda il filesystem, come abbiamo messo, ora disponiamo di API di archiviazione locale, anche se non ci si affiderebbe ad esse per una lunga durata. Tuttavia, non è necessario che la scrittura su un filesystem sia diretta, il tuo javascript potrebbe effettuare chiamate riposanti verso un server che (scritto in LOLCode o C o JS stesso) che scrive su una qualche forma di archiviazione.
sa93,

1
Sul lato server. L'API del file NodeJS è semplicemente banale come C etc ... <- se stai eseguendo IO correttamente in C (non bloccando). Anche una chiamata Ajax con qualsiasi wrapper sano può essere di 2-3 linee. MyLib.Ajax.post ('/ persistence / Something', {data: blahObj})
sa93,

@ sa93, per favore non confondere gli ambienti host del browser con JavaScript. localStorage è un'API host nei browser. Non è definito nelle specifiche ES5.
Raynos,

1
@reinierpost Writing files to the file system has been replaced with HTTP POST.Non se stai scrivendo le API che gestiscono i post.
StuperUser

5

La maggior parte delle lingue di uso comune sono più potenti e progettate meglio di JavaScript. Tutte le funzionalità che menzioni sono supportate da altri linguaggi dinamici come Python o Ruby, che sono complessivamente meglio progettati. E alcune delle caratteristiche che menzionate non sono necessariamente desiderabili in ogni caso - se lo si desidera, molti considererebbero la digitazione statica con deduzione del tipo preferibile alla digitazione dinamica.

Non sto dicendo questo per diss JavaScript. Mi piace molto lavorare con JS durante lo sviluppo del web. Ma osservandolo in modo obiettivo, JS presenta numerosi inconvenienti rispetto ad altre lingue:

  • Numerosi difetti irreversibili. Durante lo sviluppo di JS sono stati commessi molti errori. Non è necessario elencarli qui, sono ben documentati. Tutte le lingue presentano errori nella progettazione iniziale che vengono successivamente corretti. La differenza con JS è che il linguaggio è stato sviluppato e rilasciato molto rapidamente e questi errori non possono mai essere riparati a causa del requisito di compatibilità con le versioni precedenti nei browser.
  • Processo estremamente lento per l'introduzione di miglioramenti e nuove funzionalità. Dal momento che tutti i fornitori di browser devono essere d'accordo e potrebbero anche per vari motivi politici voler rallentare lo sviluppo della lingua. Guarda C # che in realtà è un linguaggio più recente di JS. Quando è stato introdotto C # non aveva ad es. chiusure o funzioni di ordine superiore come JS, ma dopo più iterazioni ora ha tutto questo e inoltre funzionalità come Linq e sintassi asincrona che gli sviluppatori JavaScript possono solo invidiare.
  • Libreria standard impoverita. I linguaggi moderni come Python, Ruby o qualsiasi altro basato su Java o .net hanno librerie standard estese per quasi tutto ciò di cui potresti aver bisogno. In JS non puoi nemmeno leggere un file senza librerie di terze parti. Citi Regex, ma tutte le lingue moderne hanno questo e mille altre cose.
  • Altre lingue hanno raggiunto i pochi vantaggi di JavaScript. Funzionalità come chiusure e funzioni di prima classe erano potenti se paragonate a grossi linguaggi statici come Java dieci anni fa, ma i linguaggi dinamici e funzionali hanno da tempo queste caratteristiche e persino Java, un linguaggio piuttosto conservatore, lo ha aggiunto in Java 8.

L'unica caratteristica che distingue davvero JavaScript dagli altri linguaggi moderni è l'ereditarietà basata sui prototipi (al contrario della classe), e il vantaggio di questo modello è dubbio poiché tutti lo usano solo per emulare l'eredità basata sulla classe.

Semplicemente non c'è motivo di scegliere JavaScript se si ha la possibilità di scegliere un'altra lingua moderna. L'unica ragione sarebbe se fosse l'unica lingua che conosci.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.