Dlaczego frameworki nie są proste, eleganckie i zabawne jak języki programowania? [Zamknięte]

Kiedy myślę o prawie dowolnym języku programowania - takim jak C, C ++, PHP, SQL, JavaScript, Python, ActionScript, Haskell, Lua, Lisp, Java itp. - Jestem niesamowity, chciałbym opracować aplikację komputerową przy użyciu dowolnego tych języków.

Ale kiedy myślę o frameworkach internetowych (głównie PHP) - takich jak Cake, CI, Symfony, Laravel, Zend, Drupal, Joomla, Wordpress, Rails, Django itp. - Jestem jak Bóg.

Dlaczego nie ma frameworków internetowych, które zapewniają proste, zabawne i wydajne konstrukcje, takie jak język programowania?

Miałem to pytanie również od lat, mimo że jestem po stronie Pythona. Nie mam ani jednego wyjaśnienia tego zjawiska, ale oto moje przemyślenia na ten temat:

• Frameworki internetowe muszą obsługiwać XMLish markup language - HTML, część obecnej triady internetowej HTML-CSS-JavaScript w sposób klient-serwer. Oznacza trzy języki, które współdziałają ze sobą, DOM przeglądarki i model wykonania (i model bezpieczeństwa). W efekcie każdy element funkcjonalności („moduł”) powinien mieć swój kod we wszystkich trzech językach. Aby dodać do tego, język wyboru jQuery staje się jeszcze jednym językiem, którym należy się zająć.

• HTML + CSS nie ma intuicyjnego i solidnego matematycznie modelu do umieszczania obiektów. Nawet Tcl / Tk jest IMHO lepszy w definiowaniu menedżerów geometrii. Uniemożliwia to programistom definiowanie renderowania HTML w ścisłych warunkach i zamiast tego polega na szczęściu: „może ten div będzie działał przez większość czasu w większości przeglądarek”. Istnieją jednak pewne pozytywne zmiany po tej stronie, na przykład HTML5 i Twitter Bootstrap.

• Technologia internetowa rozwinęła się organicznie, a wraz z nią ramy, więc ich kształt nie jest koniecznie elegancki. Oznacza to, że programista powinien pamiętać API, które są nieoptymalne, będą przestarzałe i tak dalej

• Przeglądarki internetowe wciąż mają niewielkie niezgodności, co dodaje niepotrzebnej złożoności ramom WWW

• Ogólna architektura to bałagan. Jest to podzielone podejście do zaplecza i interfejsu, które są powiązane z żądaniem / odpowiedzią po stronie zaplecza i renderowaniem opartym na danych po stronie interfejsu. Kolejność wykonywania nie jest bardzo dobrze zdefiniowana (synchronizacja wymaga wysiłku) i wymagane jest umieszczanie stylów, skryptów w odpowiednich gniazdach (prawie wszystkie skrypty js muszą być umieszczone przed znacznikiem końca ciała itd.). Buforowanie jest kolejnym aspektem, który rozciąga się od backendu do proxy (ów) do frontonu. I nawet nie wspominam o obsłudze formularzy!

• Struktura sieciowa koniecznie radzi sobie z większością tych złożoności, dodając wiele koncepcji i potoków przetwarzania.

• W branży internetowej praca jest zwykle dzielona między projektanta graficznego, projektanta / programistę WWW i programistę zaplecza jako minimalny zestaw ról. Te dwa pierwsze niekoniecznie mają umiejętności programowania, dlatego potrzebują różnych abstrakcji i narzędzi, a ramy powinny je również ułatwiać

Podsumowując, frameworki internetowe próbują wyodrębnić wiele złożoności (same się komplikują), ale jest to bardzo trudne do osiągnięcia ze względu na szybki rozwój standardów i innych ruchomych części. Języki programowania są znacznie bardziej dojrzałe, ponieważ zazwyczaj nie jest problemem, aby nie używać nowych funkcji.

Myślę, że stworzenie wygodnego frameworka będzie możliwe dopiero po wprowadzeniu standardów GUI (obejmujących różne tryby działania, takich jak urządzenia mobilne), a podstawowe technologie będą wystarczająco stabilne.

Struktury internetowe nie mają prostych konstrukcji, ponieważ w dziedzinie technologii internetowych nie ma takich rzeczy. Abstrakcje niższego poziomu muszą przeciekać do wyższego poziomu.

Myślę, że wiele z tego ma związek z ograniczeniami WWW. W szczególności nie ma wbudowanego sposobu przechowywania stanu między serwerem a klientem. Klient żąda danych, serwer je podaje, a połączenie zostaje zamknięte. W związku z tym wszystkie te platformy internetowe muszą opracować własną metodę utrzymywania stanu między wywołaniami serwera.

Musiałem raz stworzyć małą aplikację internetową i nigdy nie programowałem na serwerze / kliencie. Zajęło mi to kilka tygodni, aby to wszystko zrozumieć, a najtrudniejsza część próbowała mnie przekonać, gdzie jest klient i serwer.

Czy to się kiedykolwiek zmieni? Wątpię. Wymagałoby to fundamentalnej zmiany w architekturze sieci.

Ogólnie rzecz biorąc, przyczyny mogą być liczne:

1. Luka abstrakcji jest większa w przypadku ramowym. Nowoczesny język proceduralny / OOP zapewnia abstrakcję nad maszyną, ale zachowuje pewne konstrukcje maszyny (takie jak przypisywanie zmiennej danych / zapisywanie danych w jednostce pamięci lub wywoływanie procedury itp.); różnica nie jest tak duża, podczas gdy platforma stara się zapewnić abstrakcję do opracowania aplikacji internetowej, która działa z większą liczbą koncepcji.
2. Frameworki mogą być bardziej złożone z punktu widzenia programisty; jest to konsekwencja pierwszego punktu. Język programowania jest raczej prosty, ma proste konstrukcje (jeśli, dla zmiennych, procedur itp.). Również standardowa biblioteka streszcza proste rzeczy, takie jak pisanie do IO lub korzystanie z kolekcji. Standardowa biblioteka jest również bardzo modularna, z niewielkim lub zerowym połączeniem między modułami; nie musisz znać IO, aby korzystać z kolekcji lub odwrotnie. Należy zauważyć, że jeśli niektóre części standardowej biblioteki są raczej złożone, są one umieszczane w mini-ramie (np. Java Collections Framework lub Framework Executors). W przypadku frameworka musisz znać cały przepływ, wszystkie części, aby użyć frameworku z pełną mocą. Ponadto, aa framework jest już zbudowaną aplikacją;
3. Nie tak wiele zasobów jest umieszczonych w ramach, jak w języku programowania. Uważam, że nie trzeba tego wyjaśniać.

Ach, ale widzisz, że to jest właśnie problem. Ramy nie powinny być kompletne Turinga. Mają się one składać z bardziej ograniczonych abstrakcji, które można łączyć razem w celu zwięzłego wykonania określonego zestawu zadań. Więc wszystkie frameworki, o których wspomniałeś, nie są zabawne, ponieważ nie zapewniają ograniczonego zestawu abstrakcji. Zapewniają nieszczelne abstrakcje niż same w sobie i stanowią abstrakcyjną maszynę, która jest bardziej niż prawdopodobnie ukończona przez Turinga. Pojęcie „ dziwnych maszyn ” jest najbliższą rzeczą, o której myślę. Wszystkie te frameworki to „dziwne maszyny” dla aplikacji internetowych, a „dziwna maszyna” jest przeciwieństwem tego, czym powinna być frameworkiem.