Che cosa rende (o perché) una lingua lato server?

the solid, defining line on can/can't be server-side by taking requests and returning a database call, that is puzzling.

Abbastanza sconcertante, immagino, dato che una tale linea non esiste per le lingue.

Come sottolineato nel commenti , "lato server" non è un aspetto di una lingua. Non è nemmeno un aspetto di un'implementazione linguistica (cioè se è interpretata, compilata, o entrambe sono irrilevanti).

"Lato server" è un aspetto dei singoli usi . Quando chiami un codice "lato server", significa semplicemente che viene eseguito sul server, anziché funzionare sul client. Se non c'è distinzione tra client e server per un programma, allora "lato server" potrebbe benissimo essere un termine senza senso in quel contesto.

Al massimo, in riferimento a un'intera lingua invece di un uso specifico di quella lingua, "lato server" potrebbe suggerire che la lingua è spesso utilizzata per la programmazione lato server o dispone di funzioni o librerie disponibili che sono particolarmente programmazione lato server. Ma niente di tutto ciò lo rende così la lingua può essere utilizzata solo su un server.

Qualsiasi lingua completa di Turing può essere utilizzata sia sul lato server che sul lato client, ma alcuni linguaggi sono più adatti per alcuni ruoli. Questa idoneità dipende anche dalle implementazioni esistenti del linguaggio e dal suo ecosistema, dato che di solito non si desidera ri-implementare tutto solo per il proprio progetto.

Java e C #, ad esempio, sono adatti per il lato server perché molti dei loro punti deboli sono molto limitati sul server. Richiedono una grande macchina virtuale e amp; runtime da installare e le applicazioni scritte in essi tendono a utilizzare molte librerie di terze parti, ma sul server non sono problematiche poiché è possibile impostare gli strumenti e gli utenti non devono preoccuparsi di installare questi requisiti. Inoltre, le VM (almeno la JVM - .NET non è poi così male) impiegano molto tempo ad avviarsi e caricano tutte le librerie (questo si vede in realtà in linguaggi basati su JVM come Scala e Clojure), ma questo non conta su un server che esegue sempre e gestisce le richieste.

Hanno anche tute forti che sono importanti per la programmazione lato server. Hanno un buon modello di concorrenza, quindi il tuo server può gestire più richieste allo stesso tempo, e hanno una riflessione che è importante per i framework dei server delle applicazioni.

Ora, diamo un'occhiata a linguaggi più adatti per il lato client, come Javascript. JS ha qualità che lo rendono buono per il lato client - il principale tra questi è la sua ampia disponibilità, essendo supportato al giorno d'oggi da praticamente qualsiasi browser (OK, forse non quelli testuali ...). È inoltre progettato per disabilitare le interferenze con l'ambiente tranne per ciò che l'host espone esplicitamente ad esso, consentendo ai browser di impedire che rovinino le macchine dell'utente (è comunque possibile utilizzare Javascript per far confusione con gli utenti stessi - come con i popup - ma può anche essere bloccato)

I punti deboli di Javascript sono meno fastidiosi nelle applicazioni lato client. Non supporta la concorrenza, ma l'architettura lato client è di solito basata sugli eventi e JS lo supporta (specialmente con ES6), e la mancanza di moduli non è così dolorosa sul lato client, che tende ad essere più piccola del server -side.

Come altri e me stesso hanno detto, qualsiasi linguaggio può essere utilizzato per qualsiasi ruolo, ma alcune lingue non si adattano molto bene ad alcuni ruoli. Java può essere usato per il lato client, ed era nel passato, ma i suoi punti deboli si mostrano quando vengono usati in quel modo e non lo si vede spesso per il lato client nei progetti moderni. Javascript può essere usato per server-side, e NodeJS è abbastanza popolare, ma il team NodeJS ha dovuto passare attraverso diversi loop per risolvere i problemi JS fondamentali e renderlo possibile.

Quindi, quelli di noi che si aggrappano all'idea che qualsiasi linguaggio può essere usato per qualsiasi cosa sono invitati ad usare Brainfuck sia dal lato client che dal lato server. Per tutti gli altri, suggerisco di provare a scegliere una lingua con le tute forti che corrispondono al ruolo che userete per quando le debolezze sono meno dolorose in quel ruolo.

What makes (or why is) a language Server-Side?

Risposta: Il fatto che venga eseguito sul lato server, ovvero: qualcosa che serve pagine Web è scritto in qualche lingua . Semplice come quello .

Al contrario, l'unica lingua lato client in uso - significa: esecuzione in un browser - oggi è Javascript . Non c'è altro che una ragione storica per questo. Fa il suo lavoro. Fine della storia.

Tuttavia ci sono lingue che sono transpiled (= "tradotto") in Javascript: come Script Clojure , Elm , emscripten (nessuna lingua, richiede codice LLVM e ne fa JS) o altri.

Forse quando Web Assembly è in uso, Javascript come lingua perderà il suo predominio come lingua per il browser.

D'altra parte dal 2009 quando Ryan Dahl ha creato NodeJS , Javascript è diventato popolare come lingua serveride. E con l'avvento di Meteor , il termine » isomorfo web app" è stato coniato.

So... why is Java with Grails a thing, but you never hear of C++ running a database request as "Full stack dev?"

Lo stesso vale per: perché così poche persone usano Haskell per lo sviluppo web; sebbene ci siano framework come Yesod ? È una miscela di ciò che viene visto come "lo strumento giusto per il lavoro di righello", facile da usare, comunemente conosciuto, ha un marketing migliore ecc.

Inoltre: Kore , che è scritto in C. È in una certa misura utile, ma ha una posizione difficile contro Rails, Flask, Spring-Boot, Phoenix, NancyFX e quant'altro.

Quando le persone parlano di lingue lato client, di solito si riferiscono a lingue che si trovano all'interno del software client all'interno (invece di essere usate per scrivere software client). JavaScript, Lua, Tcl e Lisp sono esempi di queste lingue.

Penso che sia più illuminante osservare perché le altre lingue non sono utilizzate nei client:

• Vuoi un linguaggio che possa essere eseguito in un ambiente di runtime. Ciò consente al tempo di esecuzione di astrarre le differenze di piattaforma e di imporre restrizioni di sicurezza. Questo è più difficile per alcune lingue rispetto ad altri. Le lingue compilate sono problematiche a causa del sovraccarico del costo di "avviamento" della compilazione. Anche le lingue che si aspettano memoria diretta e accesso IO sono inadatte.
• Molti linguaggi di scripting sono personalizzati su misura per i loro clienti e hanno solo funzionalità limitate. Molti client supportano solo un linguaggio di scripting.

Questi motivi rendono alcuni linguaggi buoni candidati (a volte l'unico candidato) come lingue "lato client"; all'interno dei rispettivi programmi client. necessariamente non li rende cattivi linguaggi lato server. Tuttavia:

• Alcune lingue interpretate sono molto più lente delle lingue compilate. Ciò li rende candidati meno probabili alle applicazioni critiche per le prestazioni, sui server o altrove.
• A volte è necessario accedere alle funzionalità specifiche dell'hardware o del sistema operativo che potrebbero non essere disponibili nell'ambiente di runtime (spesso in base alla progettazione).