Front-end scritto nelle lingue utilizzate per il back-end! [chiuso]


10

Dalla mia esperienza nello sviluppo web, so che linguaggi come PHP, Java, Python..etc sono usati per cose di sviluppo back-end (software che gira su server), e per le lingue front-end, vengono usati JS / HTML / CSS.

Ma vedo che molte aziende affermano che usano, ad esempio, PHP per lo sviluppo front-end e Python per il back-end.

Significa che PHP è front-end per chiamare altri servizi scritti in altre lingue tramite REST, RPC ..etc?


3
questo post è piuttosto difficile da leggere (wall of text). Ti dispiacerebbe modificarlo in una forma migliore?
moscerino del

Risposte:


36

Hai confuso i termini "front-end" e "back-end" con "lato server" e "lato client". "Back-end" di solito si riferisce a sistemi che non sono direttamente esposti all'utente (server di database, middleware e così via), mentre "front-end" di solito si riferisce all'applicazione (nel caso del Web, ciò significa normalmente statico e pagine Web dinamiche) accessibili direttamente dal client.

In un'applicazione Web, il client (il browser dell'utente) accede alle pagine Web che vengono archiviate o generate dinamicamente "lato server" mediante tecnologie "front-end". Tali componenti front-end possono, a loro volta, estrarre dati o altre informazioni dai componenti "back-end". Quindi un'applicazione web scritta in PHP sarebbe "front-end" ma "lato server". Tuttavia, se le pagine Web contenessero javascript da eseguire dal browser dell'utente, quel codice javascript verrebbe eseguito "lato client".

Spero di aver rimosso un po 'di confusione, ma ora rischio di crearne un altro.

Innanzitutto, abbiamo AJAX , che è il codice (di solito JavaScript) eseguito nel client (quindi lato client), per creare le pagine Web che vedi estraendo informazioni dai servizi rivolti a Internet che non generano esse stesse pagine web. I servizi stanno generando le loro informazioni sul lato server sul front-end (poiché sono pubbliche e puoi puntare il browser direttamente verso di loro se conosci l'URL).

In secondo luogo, ovviamente, JavaScript non si limita all'uso lato client. È diventato sempre più popolare come linguaggio "lato server" (vedi node.js per un esempio). Come tale, il suo uso più comune è proprio per il tipo di servizi di connessione a Internet che ho descritto nel paragrafo precedente.

Le cose erano molto più semplici prima del Web 2.0 . All'epoca, nel contesto delle applicazioni Web , il front-end era il luogo in cui venivano generate le pagine Web, mentre JavaScript funzionava solo sul lato client e rendeva meno estetiche le pagine Web come immagini ad alta illuminazione quando si spostava il mouse su di esse. Tuttavia, quella semplicità ha reso le persone pigre sulle loro definizioni. Ora la situazione è più complessa, quindi è importante essere precisi su questi termini.

(Oh, e se si dispone di usare PHP, si prega di tenerlo sul front-end. E 'decisamente non è una tecnologia di buon back-end. E se mai trovare qualcuno la creazione di un browser che esegue PHP lato client, fucilarli.)


Data la tua ultima frase, potresti goderti code.google.com/p/php-to-js :-P
Andrea

se ogni lingua può essere usata sul frontend e ogni lingua può essere usata sul backend la distinzione non è inutile nel modo in cui è stata chiesta? si può rispondere solo in un contesto di un'applicazione.
Claudiu Creanga,

7

Penso che la tua domanda possa essere molto specifica per PHP, dato che non riesco a vedere nessuna delle altre tecnologie di back-end di cui dici che viene utilizzata in questo modo.

PHP è un esempio divertente in quanto può essere (in un modo piuttosto brutto che posso aggiungere) visto come una lingua all-in-one per quanto riguarda molti progetti web. È possibile eseguire le attività " back-end " tradizionali, ad esempio operazioni su file e database, creando al contempo mark-up " front-end ".

Questo può chiaramente portare a un pasticcio di spaghetti in cui non c'è una vera separazione delle preoccupazioni, quindi dovrebbe essere davvero malvisto nella mia mente. Per un ottimo esempio, se sfogli la fonte di wordpress puoi spesso perderti - e questo è un progetto in cui biasimo la lingua, l'organizzazione del codebase è in realtà molto buona.

Questo può essere risolto, in qualche modo, usando un " motore di template " (come Smarty )) - ma è ancora PHP che sta costruendo il "front-end" fornendo allo stesso tempo la funzionalità "back-end". Questa è stata una decisione intenzionale alla base della progettazione di PHP, dopo tutto è un " processore ipertestuale "!

Quindi PHP può facilmente adattarsi sia agli usi " front-end " che " back-end ", il che dovrebbe chiarire il tuo esempio. Quindi probabilmente hai ragione nel dire che PHP elaborerà e costruirà tutto il mark-up per un front-end, ma farà richieste altrove per raccogliere i dati richiesti - molto probabilmente un servizio scritto in una delle lingue sopra menzionate .

Personalmente, ritengo che l'intera terminologia "back-end" e "front-end" sia un po '.. forse obsoleta. Preferirei che le cose fossero semplicemente riferite al lato client e lato server; allora non c'è vera ambiguità. *

Di recente ho visto una specifica del client che richiedeva un sistema back-end scritto in node.js e strumenti associati, ma desiderava la build del front-end usando un framework PHP (Laravel). Ciò comporta molti costi associati e, a mio avviso, non è una soluzione elegante e può causare alcuni problemi.

Personalmente, questo tipo di configurazioni sembra che qualcuno abbia inutilmente inserito il PHP in un altro stack - il che significa che sono necessarie più risorse di quelle effettivamente necessarie, il personale di manutenzione deve essere esposto a una gamma più ampia di tecnologie e ci sono più punti di errore.

Inoltre, penso anche che ci siano pochissimi scenari che giustificano questo tipo di stack intermedio; la maggior parte dei linguaggi / framework di back-end sono perfettamente in grado di generare il mark-up richiesto per il front-end. Anche se sto per essere corretto lì.

* Anche se, per girare la tua domanda sulla testa ... Che dire dei sistemi di back-end costruiti usando Javascript? (node.js;))

Modificare:

Dopo aver letto un commento di @itsbruce, ho deciso di chiarire cosa intendo per ambiguità della mia terminologia "front-end" / "back-end".

Tradizionalmente questa terminologia sarebbe andata bene, dal punto di vista architettonico le applicazioni web erano molto più semplici - e oserei dirlo, molto più stupido. Nella mia mente è molto più pulito dire "Server Side" e "Client Side", e questo sta diventando più chiaro man mano che l'attuale tendenza a spingere più elaborazione e logica nel client sta diventando comune.

Sta diventando accettabile fare una buona quantità di elaborazione dei dati lato client (basta guardare alcuni dei framework javascript attualmente in trend), ma è davvero un front-end? L'utente non lo vede, ne vede i risultati - e secondo criteri tradizionali che sarebbero generalmente visti come "back-end"; ma questo sta accadendo nel browser ora ..

Allo stesso modo, e incredibilmente rilevante per questa domanda, costruire il mark-up in PHP è davvero un compito front-end? Ne dubito, una rapida consultazione delle bacheche di lavoro mostra che alcune posizioni degli sviluppatori front-end si aspettano esperienza o conoscenza di PHP; tuttavia l'intuizione suggerirebbe che il mark-up per l'interfaccia sia intrinsecamente front-end.

Il fatto stesso che questa domanda esista costituisce un esempio di come " front-end " e " back-end " siano intrinsecamente ambigui e continueranno ad esserlo.

Riferendosi ad attività come "lato server" o "lato client" per cui si perde l'ambiguità, si sa dove viene eseguito il codice e quali lingue verranno utilizzate. Se hai detto " front-end " nell'esempio fornito dall'OP, dubito che molte persone andrebbero " Oh, quindi PHP sul server giusto? ".


3
Non ti ho votato, ma la tua risposta è quasi difficile da leggere come la domanda e in realtà non affronta la confusione sui termini (semmai la peggiora). Ancora più importante, semplicemente non vi è alcuna ambiguità tra "front-end v. Back-end" e "lato client v. Lato server"; descrivono relazioni diverse e distinte. Potresti anche dire "Preferirei che smettessimo di prendere il colore e la forma; è ambiguo che le cose possano essere verdi o blu e rotonde o quadrate e alcune cose siano verdi e quadrate".
itsbruce,

Doh, non ho avuto abbastanza tempo per rileggere perché dovevo tornare al lavoro. Saluti per il commento, però, mi ha dato un avvertimento per la modifica. Mi attengo ai miei pensieri sulla terminologia, ma mi espanderò un po 'su di essa. Ta.
Fergus A Londra,

non necessariamente - considero un linguaggio web-server parte del client (considerando la frequenza con cui i server web vengono hackerati al giorno d'oggi dovrebbe essere considerato compromesso dal primo giorno), quindi è necessario distinguere le lingue lato server che fanno parte della presentazione livello da lingue lato server che forniscono servizi a livello di applicazione. Quindi PHP potrebbe essere considerato un linguaggio "front-end, lato server".
gbjbaanb,
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.