Perché i framework web non sono semplici, eleganti e divertenti come i linguaggi di programmazione? [chiuso]

10

Quando penso a quasi tutti i linguaggi di programmazione, come C, C ++, PHP, SQL, JavaScript, Python, ActionScript, Haskell, Lua, Lisp, Java, ecc. Sono fantastico, mi piacerebbe sviluppare un computer applicazione utilizzando una di queste lingue.

Ma quando penso a framework web (io principalmente PHP) - come Cake, CI, Symfony, Laravel, Zend, Drupal, Joomla, Wordpress, Rails, Django, ecc. - Sono come Dio no.

Perché non ci sono framework web che mi forniscono costrutti semplici, divertenti e potenti come un linguaggio di programmazione?

    
posta Ryan 13.10.2013 - 08:50
fonte

4 risposte

19

Anch'io ho avuto questa domanda per anni, anche se sono su Python. Non ho una singola spiegazione per questo fenomeno, ma ecco i miei pensieri sull'argomento:

  • I framework web devono occuparsi del linguaggio markup XMLish - HTML, parte dell'attuale web-triad HTML-CSS-JavaScript in un modo client-server. Significa tre lingue, che interagiscono tra loro, un DOM del browser e un modello di esecuzione (e un modello di sicurezza). In effetti, ogni parte della funzionalità (un "modulo") dovrebbe avere il suo codice in tutte e tre le lingue. Per aggiungere a ciò, il linguaggio di selezione di jQuery sta diventando un altro linguaggio a cui badare.

  • HTML + CSS manca del modello intuitivo e matematico per il posizionamento degli oggetti. Persino Tcl / Tk è IMHO meglio nella definizione dei responsabili della geometria. Ciò impedisce al programmatore di definire il rendering HTML in termini rigorosi e si affida invece alla fortuna: "forse questo div lavorerà il più delle volte nella maggior parte dei browser". Ci sono alcuni sviluppi positivi su questo versante, ad esempio, HTML5 e Twitter Bootstrap.

  • La tecnologia Web è cresciuta in modo organico e le strutture sono cresciute con esso, quindi la loro forma non è necessaria elegante. Significa che il programmatore dovrebbe ricordare le API, che sono subottimali, che saranno deprecate e così via

  • I browser Web hanno ancora lievi incompatibilità e aggiungono complessità non necessaria ai framework web

  • L'architettura generale è un disastro. È una visione spaccata del back-end e del frontend, che sono legati insieme alla richiesta / risposta sul lato back-end e al rendering basato sui dati sul lato front-end. L'ordine di esecuzione non è molto ben definito (la sincronizzazione richiede uno sforzo) e l'inserimento degli stili, gli script negli slot appropriati sono necessari (quasi tutti gli script js devono essere posizionati prima della fine del tag body e così via). Il caching è ancora un altro aspetto, che va dal backend al proxy (i) al front-end. E non menziono nemmeno la gestione dei moduli!

  • Il framework web tratta necessariamente la maggior parte di queste complessità aggiungendo molti concetti e processando pipe.

  • Nell'industria del web il lavoro è solitamente suddiviso tra designer grafico, web designer / programmatore web e programmatore back-end come set minimo di ruoli. I primi due non hanno necessariamente competenze di programmazione, quindi hanno bisogno di astrazioni e strumenti diversi, e le strutture dovrebbero facilitare anche loro

In sintesi, i framework web cercano di astrarre molta complessità (crescendo complessi essi stessi), ma è molto difficile da raggiungere a causa del rapido sviluppo degli standard e di altre parti mobili. I linguaggi di programmazione sono molto più maturi, perché di solito non è un problema non utilizzare nuove funzionalità.

Penso che rendere possibile un framework web conveniente solo dopo che saranno stati applicati gli standard della GUI (che coprono diverse modalità operative, come i dispositivi mobili) e che le tecnologie sottostanti saranno abbastanza stabili.

I framework web mancano di semplici costrutti perché non ci sono cose simili nel dominio della tecnologia web. Le astrazioni di livello inferiore perdono necessariamente a un livello più alto.

    
risposta data 13.10.2013 - 09:48
fonte
3

Penso che molto abbia a che fare con i limiti del WWW. In particolare, non esiste un modo integrato per memorizzare lo stato tra il server e il client. Un client richiede alcuni dati, il server lo fornisce e la connessione viene chiusa. Pertanto, tutte queste piattaforme Web devono mettere insieme il proprio metodo per mantenere lo stato tra le chiamate del server.

Ho dovuto creare una piccola app Web una volta e al momento non avevo mai fatto alcuna programmazione server / client. Mi ci sono volute alcune settimane per capire tutto e la parte più difficile era cercare di capire come si trovavano il client e il server.

Questo cambierà mai? Ne dubito. Richiederebbe un cambiamento fondamentale nell'architettura del web.

    
risposta data 13.10.2013 - 09:21
fonte
2

In generale, le cause potrebbero essere molteplici:

  1. Il divario di astrazione è maggiore nel caso quadro. Un linguaggio procedurale / OOP moderno fornisce l'astrazione su una macchina ma mantiene alcuni costrutti della macchina (come l'assegnazione di una variabile di alcuni dati / la scrittura di alcuni dati in un'unità di memoria, o la chiamata di una procedura, ecc.); il divario non è così grande, mentre un framework cerca di fornire l'astrazione per lo sviluppo di un'applicazione web che funzioni con molti più concetti.
  2. I quadri possono essere più complessi dal punto di vista del programmatore; questo è come una conseguenza del primo punto. Un linguaggio di programmazione è piuttosto semplice, ha costrutti semplici (se, per, variabili, procedure, ecc.). Anche la libreria standard astrae cose semplici come scrivere su IO o usare le collezioni. La libreria standard è anche molto modulare, con poche o nessuna connessione tra il modulo e l'altro; non è necessario conoscere l'IO per utilizzare le raccolte o viceversa. Da notare che se alcune parti della libreria standard sono piuttosto complesse, vengono inserite in un mini-framework (ad esempio framework Java Collections Framework o Executors). Nel caso del framework hai bisogno di conoscere l'intero flusso, tutte le parti per poter utilizzare il framework al suo pieno vigore. Inoltre, un framework è un'applicazione già costruita; un programmatore ha solo bisogno di personalizzare alcune parti ma ha bisogno di conoscere prima l'applicazione, cosa fa.
  3. Non vengono messe così tante risorse in un framework come in un linguaggio di programmazione. Credo che questo non abbia bisogno di spiegazioni.
risposta data 13.10.2013 - 09:48
fonte
0

Ah, ma vedi che è esattamente il problema. I framework non dovrebbero essere completati da Turing. Si suppone che siano composti da astrazioni più ristrette che possono essere composte insieme per eseguire una serie specifica di compiti in modo succinto. Quindi tutte quelle strutture che hai menzionato non sono divertenti esattamente perché non forniscono un insieme limitato di astrazioni. Forniscono astrazioni che perdono di per sé compongono una macchina astratta che è più che probabile Turing completa. Il concetto di " macchine strane " è la cosa più vicina a cui sto pensando. Tutti questi framework sono "macchine strane" per le applicazioni web e una "macchina strana" è l'opposto di quello che dovrebbe essere un framework.

    
risposta data 13.10.2013 - 09:08
fonte

Leggi altre domande sui tag