왜 n- 계층 개발의 코드 기반이 같은 양의 JavaScript 코드를 사용합니까?

나는 오랫동안 웹 프로그래밍을 해왔고 어딘가에서 우리가 오늘하고있는 일을하는 이유 (또는 어떻게 이런 일을했는지)를 잃어 버렸는가?

나는 기본적인 ASP 웹 개발로 시작했고, 초기에는 디스플레이와 비즈니스 로직이 페이지에서 혼합되었습니다. 클라이언트 측 개발은 매우 다양했으며 (VBScript, 다양한 종류의 JavaScript) 서버 측 유효성 검사에 대해 많은 경고가있었습니다 (따라서 클라이언트 측 로직에서 멀리 떨어져 있음).

그런 다음 잠시 ColdFusion으로 옮겼습니다. ColdFusion은 아마도 태그를 사용하여 디스플레이와 비즈니스 로직을 분리 한 최초의 웹 개발 프레임 워크 일 것입니다. 그것은 매우 분명해 보였지만 매우 장황했으며 ColdFusion은 시장 수요가 높지 않았으므로 계속 진행했습니다.

그런 다음 ASP.NET 밴드 마차를 타고 MVC 방식을 사용하기 시작했습니다. 또한 Java가 엔터프라이즈 시스템의 상아탑 언어 인 것처럼 보이고 MVC 접근 방식도 시도했습니다. 나중에 ASP.NET은이 MVVM 디자인 패턴을 개발했으며 Java (정확히 J2EE 또는 JEE)도 MVC2 접근 방식으로 어려움을 겪었습니다.

그러나 오늘 내가 발견 한 것은 백엔드 프로그래밍이 흥분과 진보가 더 이상 존재하지 않는다는 것입니다. 또한 서버 측 기반 MVC 사례는 더 이상 사용되지 않는 것 같습니다 (더 이상 사람들이 실제로 JSTL을 사용합니까?). 현재 제가 진행하고있는 대부분의 프로젝트에서 JavaScript 프레임 워크와 클라이언트 측 개발이 모든 흥미롭고 혁신적인 발전이 이루어지는 곳임을 알게되었습니다.

서버에서 클라이언트 측 개발로이 이동이 발생한 이유는 무엇입니까? JEE 프로젝트 중 하나를 간단한 행 수로 수행했으며 Java보다 타사 코드가 더 많습니다 (타사 라이브러리 제외). Java 또는 C #과 같은 프로그래밍 언어를 사용하는 대부분의 백엔드 개발은 단순히 REST와 유사한 인터페이스를 생성하는 것이므로 디스플레이, 시각화, 데이터 입력 / 출력, 사용자 상호 작용 등의 모든 노력이 해결되고 있습니다. Angular, Backbone, Ember, Knockout 등과 같은 클라이언트 측 프레임 워크를 통해

jQuery 이전 시대에는 n-tier 개발에서 MVC의 M, V 및 C 사이에 명확하고 개념적 선이있는 많은 다이어그램을 보았습니다. Post-jQuery,이 선들은 어디에 그려 집니까? MVC와 MVVM은 클라이언트 측 JavaScript 코드에 모두있는 것처럼 보입니다.

내가 알고 싶은 것은 왜 우리가 서버 측 프로그래밍의 강조에서 클라이언트 측으로, 컴파일 된 언어 선호에서 스크립팅 언어로, 명령형에서 함수형 프로그래밍으로, 이러한 모든 전환이 동시에 일어난 것처럼 보입니다. ) 및이 전환 / 시프트로 해결 된 문제

서버와 클라이언트간에 컴퓨팅로드를 이동시키는 것은 주기적 현상이며 꽤 오랫동안 진행되었습니다.

내가 커뮤니티 칼리지에있을 때 개인용 컴퓨터는 증기를 just습니다. 그러나 이더넷은 아직 널리 사용되지 않았으며 아무도 LAN을 가지고 있지 않았습니다. 당시 대학에는 학생 기록을 처리하고 프로그래밍 수업을위한 플랫폼 역할을하는 메인 프레임이있었습니다. 관리국은 시간 공유 기반으로 메인 프레임에 연결된 터미널을 가지고 있었지만 학생들은 프로그래밍 과제를 완수하기 위해 카드를 펀칭해야했습니다. 결국 그들은 학생들이 터미널에서 시간을내어 등록 할 수있는 실험실에 갔지만 여전히 반 인치 정도의 오류를 출력하는 데 30 분 정도 걸렸습니다. 모든 처리 작업은 메인 프레임 (서버)에서 수행되었습니다.

그러나 메인 프레임은 비 쌌기 때문에 회사는 로컬 영역 네트워크를 설치하기 시작했으며 처리 부하가 서버에서 개별 클라이언트 시스템으로 이동했습니다. 개별로드 처리는 개별 워드 프로세싱, 스프레드 시트 및 업무용 응용 프로그램을 실행할 수는 있지만 강력하지는 않았습니다. 처리 능력을 다른 사람들과 공유하십시오. 서버는 유사한 기능 (아마도 더 많은 메모리 및 하드 드라이브 공간)을 가진 유사한 시스템 이었지만 대부분 파일을 공유하는 데 사용되었습니다. 이를 클라이언트 / 서버라고합니다. 대부분의 처리가 클라이언트 컴퓨터로 옮겨졌습니다.

클라이언트 시스템에서 모든 처리를 수행하는 데 따른 단점 중 하나는 소프트웨어 설치 및 업그레이드의 끊임없는주기와 그에 따른 모든 골치 거리에 잠겨 있다는 것입니다. 이러한 기계의 프로그래밍 모델 (이벤트 기반의 코드 숨김 사용자 인터페이스)은 프로그램을 지저분하고 유지하기 어려운 프로그램 (큰 공의 진흙)을 장려했습니다. 대부분의 최종 사용자는 하드웨어와 소프트웨어를 올바르게 유지 관리 할 수있는 기술이 없었기 때문에 IT 유지 관리 인력이 필요했습니다.

컴퓨터가 점점 더 강력 해짐에 따라 분업이 가능해졌습니다. 이제 파일 서버, 데이터베이스 서버, 웹 서버, 인쇄 서버 등을 가질 수 있습니다. 각 기계는 제공된 작업에 대해 다소 최적화되고 필요한 전문 지식을 가진 사람이 유지 관리 할 수 ​​있습니다. 웹 브라우저에서 실행되는 프로그램을 작성할 수 있으므로 클라이언트 설치가 더 이상 필요하지 않습니다. 이를 다중 계층 또는 n 계층이라고합니다. 메인 프레임 시절과 마찬가지로 브라우저는 기본적으로 바보 터미널로 사용되었지만 서버와의 통신 방법은 더 정교하고 덜 독점적이며 시간 공유 및 폴링보다는 인터럽트 메커니즘을 기반으로합니다. 처리가 서버로 다시 이동했습니다.

그러나 웹 개발에는 완전히 새로운 두통이 발생했습니다. 브라우저 용으로 작성된 대부분의 비즈니스 응용 프로그램은 정적 양식 및 보고서였습니다. UI에서 사용 가능한 상호 작용은 거의 없었습니다. Javascript는 아직 두 번째 바람을 찾지 못했으며 브라우저 비 호환성에 대한 주요 문제로 인해 널리 채택되지 않았습니다. 그러나 상황이 훨씬 좋아졌습니다. HTML5와 CSS3는 브라우저 프로그래밍 모델에 실질적으로 새로운 기능을 제공하며, jQuery가 나오고 전체 프로그래머가 Javascript가 얼마나 유용한 지 발견하는 데 도움이되었습니다. 새로운 프론트 엔드 UI 프레임 워크가 등장했습니다. 브라우저에서 대화 형 UI를 작성하고 완전한 게임을 만들 수있게되었습니다. 처리가 다시 클라이언트로 이동되었습니다.

오늘날, 클라우드에서 처리 능력을 원하는만큼 구입하고 서버에서 프로그램을 실행할 수 있습니다. 우리는 이제 소프트웨어 개발자로서 클라이언트와 서버 모두에서 처리 능력을 실행할 수있는 곳을 많이 선택할 수 있다고 말하고 싶습니다.

두 가지 매우 다른 개념을 혼합 한 것 같습니다.

1. 프리젠 테이션 및 비즈니스 로직 (MVC) 분리 => 유지 보수성 향상
2. 노드에 실행을 할당하면 효율이 증가합니다.

예전에는 클라이언트가 일반적으로 서버와 비교할 때 많은 컴퓨팅 성능을 제공하지 않았기 때문에 클라이언트 / 서버 컴퓨팅은 종종 처음을 암시하는 것으로 혼동되었습니다. 따라서 "가벼운"비즈니스 로직 계산 (M)을 서버로 옮기는 동시에 "가벼운"뷰 처리 (V)를 클라이언트에 유지하는 것은 자연스러운 것처럼 보였습니다. 결과적으로 두 가지를 번역하기 위해 일종의 중재자 (C)를 구현해야했습니다.

클라이언트는 이제 공정한 기능을 쉽게 제공함으로써 고가의 서버 하드웨어를 암시 한 바 있으며, 비즈니스 로직을 클라이언트 측 또는 서버 측에서 어디에서 실행할 것인지에 대한 경계가 흐려졌습니다. 실제로 답변은 특정 사용 사례 및 선택한 트레이드 오프에 따라 다릅니다.

• 클라이언트 대기 시간 대 복잡성 : 서버 측 처리는 클라이언트에 코드를 배포 / 다운로드 할 필요가 없기 때문에 시스템을 단순하게 유지하지만 계산 중에 클라이언트 측 대기 시간이 발생합니다.

• 복잡성 대 서버로드 : 클라이언트 측 컴퓨팅은 시스템 복잡성을 증가시킬 수 있지만 서버로드를 줄이는 데 도움이 될 수도 있습니다.

• 분산 애플리케이션 탄력성 vs 중앙 실행 : 모바일 앱 세계에서는 네트워크 연결 끊김에도 불구하고 클라이언트 작업을 유지하는 것이 중요 할 수 있습니다. 그러나 배포 된 여러 버전의 비즈니스 논리를 관리하는 비용이 발생합니다.

이것은 많은 트레이드 오프의 전체 목록입니다.

사용자는 항상 동일한 기능을 원했기 때문에 데스크톱 응용 프로그램과 동일한 웹 응용 프로그램 (웹 사이트뿐만 아니라)을 사용합니다. 이 모든 것을 브라우저 (실제로 여러 브라우저)에서 실행하는 것은 VB 양식을 코드가 거의없는 데이터베이스에 연결할 수 있었던 옛날과 다릅니다. 서버로 다시 이동할 필요가 없을 때 쉽게 달성 할 수 있습니다.

Java 또는 C #과 같은 프로그래밍 언어를 사용하는 대부분의 백엔드 개발은 단순히 REST와 유사한 인터페이스를 생성하는 것입니다. 디스플레이, 시각화, 데이터 입력 / 출력, 사용자 상호 작용 등의 모든 노력은 클라이언트를 통해 해결됩니다. Angular, Backbone, Ember, Knockout 등과 같은 사이드 프레임 워크

아마도 백엔드 프로그래밍 / 서비스가 똑같은 오래된 것처럼 보이지만 응용 프로그램의 핵심입니다. 이러한 영역에서는 코딩 방법이 더 효율적일 수 있습니다. 도구, 언어, 브라우저 및 프레임 워크는 여전히 발전하고 있으므로 UI ​​/ UX를 개발하기가 어렵습니다. 기존 ASP에는 없었던 새로운 것들입니다. 간단한 양식과 html 테이블을 사용하여 사용자 인터페이스를 피할 수 있다면 해당 영역에도 관심이 많지 않지만 드래그 앤 드롭, 애니메이션, 전환, 팝업 등을 원합니다.

현재 제가 진행하고있는 대부분의 프로젝트에서 JavaScript 프레임 워크와 클라이언트 측 개발이 모든 흥미롭고 혁신적인 발전이 이루어지는 곳임을 알게되었습니다.

서버에서 클라이언트 측 개발로이 이동이 발생한 이유는 무엇입니까?

실제로 두 가지 질문이 있습니다.

1. 진행 상황이 발생하는 클라이언트 쪽 프로그래밍이 왜 필요한가요?
2. 애플리케이션이 서버가 아닌 클라이언트에서 실행되도록 작성된 이유는 무엇입니까?

둘은 실제로 구별됩니다.

진행 상황이 발생하는 클라이언트 쪽 프로그래밍이 왜 필요한가요?

런타임, 환경 및 에코 시스템은 지난 3 년 동안 실질적으로 발전했기 때문에 혁신가들이 이용하기를 기다리는 새로운 틈새 시장을 열었습니다.

프론트 엔드 개발은 어려웠다 . 씩 클라이언트 애플리케이션을 구축하기위한 선행 기술이나 툴링이없는 에코 시스템에서 ECMAScript 3의 제한된 기능을 사용하여 브라우저를 항상 적대적인 환경으로 프로그래밍해야했습니다. 모듈 로더가 없습니다. 종속성을 올바르게 처리 할 수 ​​없습니다. 보푸라기 도구가 부족했습니다. 프레임 워크는 미숙하고 프론트 엔드의 열악한 평판으로 인해 이러한 문제를 해결할 수있는 혁신가였습니다.

이러한 요소가 점진적으로 변경됨에 따라 리치 클라이언트 응용 프로그램을 신속하게 개발하고 일관되게 실행하는 데 중요한 요소를 만들었습니다.

귀하의 질문에 대한 답변으로, 새로운 프론트 엔드 기술이 병목 현상을 풀고 고객이 사용자의 열망을 따라 잡을 수 있도록 발전을 추진 한 것은 아닙니다.

애플리케이션이 서버가 아닌 클라이언트에서 실행되도록 작성된 이유는 무엇입니까?

근사 원인은 많이 있지만 최근 몇 년 동안 가장 두드러진 것은 스마트 폰의 부상입니다.

스마트 폰은 적당하고 강력한 컴퓨팅을 저렴하고 어디에나 유용하며 유용하게 만듭니다. 그들은 전 세계 수십억의 사람들이 소유하고 있으며, 컴퓨팅을 중산층의 신흥 경제국에 가져 왔습니다. 그러나 모바일 네트워크는 지리학 적, 공학적, 정치적 어려움으로 인해 느리고 부패하며 제약을받습니다. 이 환경에서는 애플리케이션이 상태를 로컬에 저장하고 마지 못해 상태 비 저장 작업에서 데이터를 패치하는 것이 불가피합니다.

어떻게 다를 수 있습니까? 스마트 폰이 바보 같은 단말기라고 상상해보십시오. 모든 상태 돌연변이는 비동기적이고 오류가 있어야합니다. 모든 콘텐츠로드에는 귀중한 센트가 필요합니다. 가동 시간이 5-9 인 거대한 서버 팜에 투자해야합니다. 컴퓨팅 비용은 사용자가 직접 부담하므로 갑작스런 인기 급상승은 실제로 비즈니스를 방해 할 수 있습니다.

클라이언트 측 응용 프로그램을 사용하면 개별 사용자와 관련된 상태를 빠르고 동 기적으로 처리 할 수 ​​있습니다. 컴퓨팅 비용을 사용자에게 오프로드 할 수 있습니다. 다운 타임과 네트워크 연결 불량으로 벗어날 수 있습니다. 이들은 서버 코드를 너무 바보로 만들어 네트워크 인프라 자체에 정적 HTML 및 JS 파일 또는 모바일 앱에 대한 미리 준비된 응답으로 캐시 할 수 있습니다.

매우 광범위한 용어로 말하면 : 클라이언트 측 개발은 저전력 중간 컴퓨팅의 저비용을 이용하고 고전력 중앙 집중식 컴퓨팅의 고비용을 피합니다.

몇 가지 질문을했는데 그 중 일부는 이미 좋은 답변을 받았습니다. 몇몇은 아직 답변을 얻지 못했습니다.

내가 알고 싶은 것은 왜 서버 측 프로그래밍의 강조에서 클라이언트 측으로의 전환이 있었습니까?이 모든 것이 동시에 일어난 것처럼 보입니다.이 전환 / 전환으로 어떤 문제가 해결 되었습니까?

로버트 하비는 훌륭한 대답을했습니다.

... 컴파일 언어 선호에서 스크립팅 언어에 이르기까지

스크립트 언어는 많은 제공하는 장점을 ( 또한 )를 통해 컴파일 된 언어, 예를 들면 :

• 배우고 사용하기 쉽다
• 컴파일 시간 제거 (빠른 개발)
• 더 많은 기능 제공 (고급 애플리케이션 제어)
• 실행 코드를 빠르게 변경할 수 있습니다
• 기타

... 명령에서 기능 프로그래밍에 이르기까지

여기 에 좋은 비교가 있지만 분산 소프트웨어 (클라우드 컴퓨팅 생각)에서는 상태 변경 관리 (많은 노드에서 동기화)가 큰 문제가 될 수 있다고 말하면 요약됩니다. 함수형 프로그래밍에서는 상태 변경을 처리해야 할 필요성이 훨씬 적습니다.