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

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'applicazione per computer usando qualsiasi di quelle lingue.

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

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

Ho avuto questa domanda anche per anni, anche se sono dalla parte di Python. Non ho una sola spiegazione per questo fenomeno, ma ecco i miei pensieri sull'argomento:

• I framework Web devono gestire il linguaggio di markup XMLish - HTML, parte dell'attuale triade HTML-CSS-JavaScript in 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 funzionalità (un "modulo") dovrebbe avere il suo codice in tutte e tre le lingue. Per aggiungere ciò, la lingua di selezione di jQuery sta diventando un'altra lingua di cui occuparsi.

• HTML + CSS manca di un modello intuitivo e matematicamente valido per posizionare gli oggetti. Anche Tcl / Tk è IMHO migliore nel definire i gestori della geometria. Ciò impedisce al programmatore di definire il rendering HTML in termini rigorosi e di affidarsi invece alla fortuna: "forse questo div funzionerà la maggior parte delle volte nella maggior parte dei browser". Ci sono alcuni sviluppi positivi su questo lato, ad esempio HTML5 e Twitter Bootstrap.

• La tecnologia Web è cresciuta organicamente e i framework sono cresciuti con essa, quindi la loro forma non è necessaria elegante. Significa che il programmatore dovrebbe ricordare le API, che non sono ottimali, saranno deprecate e così via

• I browser Web presentano ancora lievi incompatibilità e aggiunge complessità inutili ai framework Web

• L'architettura complessiva è un casino. Si tratta di una suddivisione del back-end e del front-end, che sono associati alla richiesta / risposta sul lato back-end e al rendering basato sui dati sul lato front-end. L'ordine di esecuzione non è ben definito (la sincronizzazione richiede uno sforzo) e posizionando gli stili, sono necessari script negli slot appropriati (quasi tutti gli script js devono essere posizionati prima della fine del tag body, e così via). La memorizzazione nella cache è un altro aspetto, che va dal backend al proxy (i) al front-end. E non menziono nemmeno la gestione dei moduli!

• Il framework Web si occupa necessariamente della maggior parte di queste complessità aggiungendo molti concetti ed elaborando pipe.

• Nel settore web il lavoro è generalmente diviso tra designer grafico, web designer / programmatore web e programmatore back-end come un set minimo di ruoli. I primi due non hanno necessariamente capacità di programmazione, quindi hanno bisogno di astrazioni e strumenti diversi e anche i framework dovrebbero facilitarli

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

Penso che realizzare un comodo framework web sarà possibile solo dopo che saranno stati messi in atto 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 esistono cose del genere nel dominio della tecnologia web. Le astrazioni di livello inferiore perdono necessariamente a un livello superiore.

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 li 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 realizzare una piccola app Web una volta e al momento non avevo mai programmato server / client. Mi ci sono volute alcune settimane per capire tutto e la parte più difficile è stata quella di cercare di capire dove si trovavano il client e il server.

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

In generale, le cause potrebbero essere molteplici:

1. Il divario di astrazione è maggiore nel caso quadro. Un moderno linguaggio procedurale / OOP fornisce astrazione su una macchina ma mantiene alcuni costrutti della macchina (come assegnare una variabile alcuni dati / scrivere alcuni dati in un'unità di memoria o chiamare una procedura ecc.); il divario non è così grande, mentre un framework cerca di fornire astrazione per lo sviluppo di un'applicazione web che opera con molti più concetti.
2. I frame 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 estrae cose semplici come scrivere su IO o usare le raccolte. La libreria standard è anche molto modulare, con poche o nessuna connessione tra il modulo e l'altro; non è necessario conoscere 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 es. Java Collections Framework o Executors framework). Nel caso del framework, è necessario conoscere l'intero flusso, tutte le parti per utilizzare il framework alla sua massima potenza. Inoltre, un framework è un'applicazione già costruita;
3. Non ci sono così tante risorse in un framework come in un linguaggio di programmazione. Credo che questo non abbia bisogno di spiegazioni.

Ah, ma vedi che è esattamente il problema. I frame non dovrebbero essere Turing completi. Si suppone che siano composti da astrazioni più ristrette che possono essere composte insieme per eseguire una serie specifica di compiti in modo sintetico. Quindi tutti quei quadri che hai citato non sono divertenti proprio perché non forniscono un insieme limitato di astrazioni. Forniscono astrazioni che perdono che in sé e per sé compongono una macchina astratta che è più che probabile completa di Turing. 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.