왜 웹 프레임 워크가 프로그래밍 언어처럼 단순하고 우아하며 재미 있지 않습니까? [닫은]

C, C ++, PHP, SQL, JavaScript, Python, ActionScript, Haskell, Lua, Lisp, Java 등과 같은 거의 모든 프로그래밍 언어를 생각할 때 어떤 것을 사용하여 컴퓨터 응용 프로그램을 개발하고 싶습니다. 그 언어 중.

그러나 Cake, CI, Symfony, Laravel, Zend, Drupal, Joomla, Wordpress, Rails, Django 등과 같은 웹 프레임 워크를 생각할 때 나는 신과 같습니다.

프로그래밍 언어와 같이 단순하고 재미 있고 강력한 구성을 제공하는 웹 프레임 워크가없는 이유는 무엇입니까?

파이썬쪽에 있지만이 질문도 몇 년 동안있었습니다. 이 현상에 대한 단일 설명은 없지만 다음은이 주제에 대한 내 생각입니다.

• 웹 프레임 워크는 클라이언트-서버 방식으로 현재 웹 트라이어드 HTML-CSS-JavaScript의 일부인 XML 마크 업 언어 (HTML)를 처리해야합니다. 이는 서로 상호 작용하는 3 가지 언어, 즉 브라우저 DOM과 실행 모델 (및 보안 모델)을 의미합니다. 실제로 각 기능 ( "모듈")은 세 가지 언어로 된 코드를 가져야합니다. 또한 jQuery의 선택기 언어는 처리해야 할 언어가되고 있습니다.

• HTML + CSS에는 객체를 배치하기위한 직관적이고 수학적으로 건전한 모델이 없습니다. Tcl / Tk조차도 지오메트리 관리자를 정의하는 데 IMHO가 더 좋습니다. 이것은 프로그래머가 엄격한 용어로 HTML 렌더링을 정의하는 것을 막고 대신 행운을 의지합니다. "아마도이 div는 대부분의 브라우저에서 대부분 작동합니다." HTML5와 Twitter Bootstrap과 같은 긍정적 인 발전이 있습니다.

• 웹 기술은 유기적으로 성장했고 프레임 워크도 함께 발전해 왔기 때문에 그 모양이 우아하지 않아도됩니다. 이는 프로그래머가 API를 기억해야한다는 것을 의미합니다.이 API는 차선책이며 더 이상 사용되지 않을 예정입니다.

• 웹 브라우저에는 여전히 약간의 비 호환성이 있으며 웹 프레임 워크에 불필요한 복잡성을 추가합니다

• 전반적인 아키텍처는 혼란입니다. 백엔드 및 프론트 엔드의 분할 사고로, 백엔드 측의 요청 / 응답 및 프론트 엔드 측의 데이터 중심 렌더링과 함께 연결됩니다. 실행 순서가 잘 정의되어 있지 않고 (동기화에 노력이 필요함) 스타일, 적절한 슬롯에 스크립트를 배치해야합니다 (거의 모든 js 스크립트는 body 태그의 끝에 배치해야합니다). 캐싱은 백엔드에서 프록시 (프론트), 프론트 엔드에 이르는 또 다른 측면입니다. 그리고 폼 핸들링도 언급하지 않았습니다!

• 웹 프레임 워크는 많은 개념과 처리 파이프를 추가하여 이러한 복잡성을 대부분 처리합니다.

• 웹 산업에서는 일반적으로 최소한의 역할 집합으로 그래픽 디자이너, 웹 디자이너 / 웹 프로그래머 및 백엔드 프로그래머로 나누어집니다. 전자는 프로그래밍 기술이 반드시 필요한 것은 아니므로 서로 다른 추상화와 도구가 필요하며 프레임 워크도이를 촉진해야합니다.

요약하면, 웹 프레임 워크는 많은 복잡성을 추상화하려고 시도하지만 (단순하게 성장하고 있음) 표준 및 기타 움직이는 부분의 빠른 개발로 인해 달성하기가 매우 어렵습니다. 프로그래밍 언어는 일반적으로 새로운 기능을 사용하지 않는 것이 문제가되지 않기 때문에 훨씬 더 성숙합니다.

GUI 표준을 적용한 후에 (모바일 장치와 같은 다양한 작동 모드를 포함) 편리한 웹 프레임 워크를 만드는 것이 가능하며 기본 기술은 충분히 안정적이라고 생각합니다.

웹 프레임 워크에는 웹 기술 영역에 그러한 것들이 없기 때문에 간단한 구조가 없습니다. 하위 레벨 추상화는 반드시 상위 레벨로 누출됩니다.

WWW의 한계와 관련이 있다고 생각합니다. 특히 서버와 클라이언트 사이에 상태를 저장하는 방법은 없습니다. 클라이언트는 일부 데이터를 요청하고 서버가이를 제공하며 연결이 닫힙니다. 따라서 이러한 모든 웹 플랫폼은 서버 호출간에 상태를 유지하는 고유 한 방법을 구성해야합니다.

작은 웹 응용 프로그램을 한 번 만들어야했고 당시에는 서버 / 클라이언트 프로그래밍을 한 적이 없었습니다. 모든 것을 알아내는 데 몇 주가 걸렸으며 가장 어려운 부분은 클라이언트와 서버가 어디에 있는지 추적하는 데 머리를 돌리려고했습니다.

이것도 바뀔까요? 나는 그것을 의심한다. 웹 아키텍처의 근본적인 변화가 필요합니다.

일반적으로 말하면 원인은 여러 가지 일 수 있습니다.

1. 프레임 워크의 경우 추상화 간격이 더 큽니다. 현대 절차 / OOP 언어는 기계에 대한 추상화를 제공하지만 일부 기계 구조를 유지합니다 (예 : 변수에 일부 데이터 할당 / 메모리 장치에 일부 데이터 쓰기 또는 프로 시저 호출 등). 그 차이는 그리 크지 않지만 프레임 워크는 훨씬 더 많은 개념으로 작동하는 웹 응용 프로그램을 개발하기위한 추상화를 제공하려고합니다.
2. 프레임 워크는 프로그래머의 관점에서 더 복잡 할 수 있습니다. 이것은 첫 번째 요점의 결과와 같습니다. 프로그래밍 언어는 다소 단순하며 간단한 구조 (변수, 프로 시저 등)를 가지고 있습니다. 또한 표준 라이브러리는 IO에 쓰기 또는 컬렉션 사용과 같은 간단한 것을 추상화합니다. 표준 라이브러리는 모듈과 모듈 간의 연결이 거의 없거나 전혀없이 매우 모듈화되어 있습니다. 콜렉션을 사용하거나 그 반대로 IO를 알 필요는 없습니다. 표준 라이브러리의 일부가 다소 복잡한 경우 미니 프레임 워크 (예 : Java Collections Framework 또는 Executors 프레임 워크)에 배치됩니다. 프레임 워크의 경우 프레임 워크를 최대한 활용하기 위해 전체 흐름, 모든 부분을 알아야합니다. 또한 프레임 워크는 이미 구축 된 응용 프로그램입니다.
3. 프로그래밍 언어 에서처럼 많은 리소스가 프레임 워크에 배치되지 않습니다. 나는 이것이 설명이 필요 없다고 생각합니다.

아, 그러나 당신은 그것이 정확히 문제라는 것을 알 수 있습니다. 프레임 워크는 튜링이 완료되어서는 안됩니다. 그것들은 간결한 방식으로 특정 작업 세트를 수행하기 위해 함께 구성 될 수있는 더 제한된 추상화로 구성되어야합니다. 따라서 언급 한 모든 프레임 워크는 제한된 추상화 세트를 제공하지 않기 때문에 재미가 없습니다. 이들은 튜링이 완료된 것보다 추상적 인 기계를 구성하는 것보다 누출 된 추상화를 제공합니다. " 이상한 기계 " 의 개념은 내가 생각하는 가장 가까운 것입니다. 이러한 모든 프레임 워크는 웹 애플리케이션에 대한 "이상한 기계"이고 "이상한 기계"는 프레임 워크의 반대입니다.