웹 개발에서 클라이언트쪽으로 돌진

지난 몇 달 동안 웹 개발에서 클라이언트 측 스크립팅에 대한 큰 흥분을 인식했습니다. 그러나 서버 측 기술은 백엔드 개발자가 성숙하고 안정적이며 잘 수용하는 반면 클라이언트 측 기술은 미숙하고 (즉, 큰 서버 측 프레임 워크와 비교하여) 많은 노련한 개발자가 싫어합니다. 그럼에도 불구하고 모든 사람들이 요즘 클라이언트 측 개발을하고 있습니다. 개인적으로 이러한 대형 서버 측 프레임 워크가 2-5 년 안에 사라져 현재 추세를 지켜 볼 것으로 기대합니다.

왜 이렇게이다? HTML5 / JS로 개발 된 새롭고 "확산 된"클라이언트 측이 서버 측 솔루션보다 우수 할 수있는 방법은 무엇입니까?

이것은 사실이다 :

웹 개발에서 클라이언트쪽으로 돌진

그러나 클라이언트 측에 국한되지 않고 전체 스택 이동입니다.

나는 이것이 놀랍다는 것을 안다. 제발 들어 줘

왜 이렇게이다? HTML5 / JS로 개발 된 새롭고 "확산 된"클라이언트 측이 서버 측 솔루션보다 우수 할 수있는 방법은 무엇입니까?

우선, 둘 다 잘 생각됩니다.

둘째, 더 낫기 때문입니다.

좋은 질문.

그러나 "더 나은"것은 주관적이므로 귀하의 질문에 대한 답변은 구체적으로 무엇이 더 낫습니까?

질문을 다시 방문하십시오.

HTML5 / JS에서 "확산 된"클라이언트 측 개발이 어떻게 큰 서버 측 솔루션보다 우수 할 수 있습니까?

Because small is nimble.
And big is clunky.

유연성입니다.

큰 일처럼 보이지 않습니다. 그렇습니까? 적응성.

그러나 유연성은 모든 것의 기초가됩니다. 유연성 향상-모든 것이 향상됩니다.

유지 보수성. 확장 성. 확장 성. 모듈성. 사용성. UX.

그리고 구현하는 것이 더 빠릅니다. 이것이 현실입니다. 더 빠르고.

This is why Windows 8 made JS a first-class citizen.

HTML5-JS는 유행이 아니며 사라지지 않습니다. 우리는 태블릿에 컴퓨팅 콘텐츠 및 상호 작용 동작을 제공하기 위해 성장할 기술의 씨앗만을보고 있습니다. 정제.

스마트 폰은 1950 년대 TV 이후 가장 빠른 대중 매체 채택이었습니다. 이제 스마트 폰뿐만 아니라 태블릿도 있습니다.

모질라와 윈도우에서 이미 시장에서 미래의 장치에서 실행될 OS-> HTML / JS에서 개발 중입니다.

많은 솔루션과 혁신이 남아 있습니다.

유연성을 바탕으로 JS의 전체 스택이 등장하고 있습니다.

도움이 되길 바랍니다.

이 이야기에는 항상 두 가지 측면이있었습니다. 서버 측 코드와 클라이언트 측 코드 모두 장단점이 있습니다.

클라이언트 측 스크립팅의 장점은 다음과 같습니다.

• 서버 왕복 없이도보다 신속하게 대응하고 광범위한 변경이 가능합니다.
• 코드는 클라이언트에서 실행되므로 서버의 리소스 사용량이 줄어 듭니다.
• 논리와 표현의 분리는 물리적이됩니다.
• 특히 요청 당 인증이 사용되는 경우 때때로로드 밸런싱이 더 쉽습니다.

그러나 서버 측 스크립트에는 많은 장점이 있습니다.

• 코드가 실행되는 머신을 제어합니다.
• 거의 아무것도 서버가 그것을 할 수 있다면, 그래서 스크립트 수 - 수 있습니다.
• 사용자는 스크립트를 실행하기 전에 수정할 수 없습니다.
• 사용자는 스크립트 차단기를 사용하여 스크립트가 실행되지 못하게 할 수 없습니다.
• 사용자는 스크립트의 기능을 볼 수 없으며 출력 만 관찰 할 수 있습니다.
• 코드는 스크린 리더, 텍스트 웹 브라우저, 검색 엔진 스파이더, 스크레이퍼, 누산기, IRC 봇, 초저가 시스템, 스크립트 차단 브라우저 등 상상할 수있는 모든 클라이언트에서 안정적으로 작동합니다.
• 사용자 플러그인이 깨질 가능성이 적습니다.

매우 역동적 인 웹 응용 프로그램의 경우 클라이언트 중심 접근 방식은 항상 인기있는 선택이었습니다. 클라이언트 측 스크립팅없이 모든 사용자의 작업은 라운드마다 트립은 적어도 1/2 초의 지연을 의미하며, 일반적으로 그 이상입니다. 그러나 기본적으로 데이터베이스에서 제공되는 정적 페이지가 많은 정보 사이트 (예 : Wikipedia)의 경우 이점은 미미하지만 서버 측 스크립팅의 이점은 여전히 ​​압도적입니다.

관찰 된 과대 광고는 두 가지 최근 개발의 조합에서 비롯됩니다.

1. HTML5 및 관련 기술의 코로나. 시간이 너무 오래 걸렸지 만 이제는 해킹을 피하지 않고 동적 데스크탑과 같은 웹 응용 프로그램을 만드는 데 필요한 모든 것을 포함하는 표준과 올바르게 구현하는 주류 브라우저가 있습니다.
2. 사용 가능한 처리 능력. 오늘날의 상용 데스크탑 PC는 엔트리 레벨 웹 서버만큼 강력하고, 고객 급 휴대폰은 실제로 2005 년 데스크탑 컴퓨터이며, 최신 자바 스크립트 구현은 성능 균형을 기울일만큼 충분히 효율적입니다. 자원.

실제로, 서버 중심 및 클라이언트 중심 접근 방식의 장점에 대해서는 아무런 변화가 없습니다. 변화된 것은 클라이언트 중심이 이제 더 쉽고 저렴 해졌으며 몇 년 전보다 더 나은 성능을 제공하여 이전보다 훨씬 더 많은 응용 프로그램에 적합한 선택이 될 수 있다는 것입니다.

서버 측은 항상 주변에 있습니다. 모든 것을 위해 클라이언트 측에 앉을 수는 없습니다. 예를 들어, 생산 현장 오버 헤드 크레인에서 실시간으로 파라미터를 전송하는 마이크로 컨트롤러에 Backbone.js MVC 설계를 사용하고 싶지 않을 것입니다.

과대 광고를 믿지 마십시오.

2009 년에 서버 측 PHP 프레임 워크에서 서버 측 웹 서비스와 연결된 클라이언트 측 ExtJS 솔루션으로 전환했습니다.

나를 위해 이주한 이유는 다음과 같습니다.

1. 서버의 엔드 포인트 및 코드 양을 줄임으로써 보안 향상
   웹 서비스로 이동하면 웹 서비스 경계에서 입력을 검증하고 서버의 I / O를보다 정확하게 제어 할 수 있습니다. 보안 아키텍처를 방해하는 서버 측 UI 계층이 없습니다.
2. 서버 왕복 횟수 감소로 인한 성능 향상
   아키텍처 변경으로 인해 데이터 가져 오기가 덜 발생하고 UI 렌더링을 통해 데이터를 로컬로 캐시 할 수 있으므로 왕복이 전혀 필요하지 않습니다. 왕복은 웹 앱 성능을 저하시키는 원인입니다.
3. UI의 캐시 가능성으로 인한 성능 향상
   UI 계층은 CDN에서 완전히 호스팅 될 수 있습니다. UI 코드를 HTML5 앱 캐시에 넣음으로써 오프라인 웹 앱도 만들었습니다.
4. 더 높은 충실도의 UI (풍부한 클라이언트 측 컨트롤)
5. 타사 개발자는 내 프런트 엔드에서 사용하는 것과 동일한 API를 사용할 수 있으며 기능을 공유하는 경우 여러 모듈에서 API를 쉽게 재사용 할 수 있습니다.
   이것은 개발, QA, 문서화가 적다는 것을 의미합니다 ...
6. PHP, Python 또는 Java보다 JavaScript로 프로그래밍하는 것이 더 좋습니다.

그러나 실수하지 마십시오. 현재 일어나고있는 일은 과대 광고입니다. 많은 웹 응용 프로그램이 서버 측 UI 아키텍처를 다시 사용합니다.

클라이언트 측 솔루션에 대한 열정을 불러 일으키는 또 다른 요소는 모바일 앱의 성장입니다. 클라이언트 측 JavaScript 및 AJAX를 기반으로 웹 사이트를 많이 만들고 기본 iOS 및 Android 앱을 빌드하는 경우 세 가지 모두 동일한 REST 서비스를 사용하여 모든 데이터를 처리하기 위해 동일한 REST 서비스를 사용할 수 있습니다. .

우선, 사용자는 서버가없는 것을 보지 못하고 때로는 신경 쓰지 않습니다. 서버 측 코드가 아무리 잘 작성 되더라도 클라이언트 부분이 제대로 수행되지 않으면 사용자는 응용 프로그램에 감사하지 않습니다. 때로는 멋진 UI조차 기능보다 중요합니다.

크고 강력한 서버 호스팅은 상당히 비쌉니다. 클라이언트 측에서 일부 로직 (유효성 검사 제외)을 구현하는 것이 훨씬 저렴합니다. 따라서 더 적은 (따라서 더 저렴한) 서버 호스팅을 사용할 수 있습니다.로드가 많지 않기 때문입니다.

이것이 불안정성에도 불구하고 클라이언트 측 기술이 더 인기를 얻고있는 이유입니다. 또한 JS 및 HTML / CSS는 거의 모든 최신 브라우저에서 지원됩니다.

이 두 부분의 응용 프로그램은 별도로 존재할 수 없습니다. 그리고 인터넷은 가까운 시일 내에 아무 데나 떠날 것 같지 않습니다.
나는 그것이 big server-side frameworks사라질 것이라고 생각하지 않습니다 . 이를 감당할 수있는 회사가 항상 존재할 것이며 그들의 큰 장점을 사용할 것입니다.

클라이언트 측 웹 개발은 웹 브라우저와 강력하게 결합되며 시간이 지남에 따라 변경됩니다. 웹 브라우저의 페이지 렌더링 엔진이 크게 변경되어 현재 제공하는 솔루션이 몇 달 안에 작동하지 않을 수 있습니다. 일부 브라우저는 표준과 호환되지 않으므로 예상 결과를 얻기 위해 개발자의 노력이 더 필요합니다.

이 문제를 해결하려는 몇 가지 솔루션이 있습니다. 예를 들어 jquery를 사용하면이 특정 jquery 라이브러리가 지원하는 브라우저에서 스크립트가 작동합니다. 그러나 일부 / 대부분 / 모든 브라우저와의 호환성을 제공하는 것은 작성자에게 달려 있습니다. 문제는 어느 팀이 당신을 더 잘 지원할 것인가입니다. motools 팀, jquery 팀, 다른 팀입니까? 특정 웹 브라우저를 지원하지 않으면 프로젝트가 해당 브라우저에서 작동하지 않을 수 있습니다.

당신이 가진 흥분은 오랫동안 주변에 있었다. Shockwave와 그 후속 플래시가 소개되었을 때, 복잡한 js 라이브러리가 일단 motools와 함께 그리고 jquery와 함께 제공된 후에 풍부한 사용자 인터페이스의 "대형 복귀"가있었습니다 (이 순서대로 사용하기 시작했습니다). Flex와 JavaFX가있었습니다. 그러나 그 누구도 시장에서 큰 점유율을 차지할 수는 없습니다. 일부는 종종 최종 사용자를 보안 취약점에 노출시키는 플러그인을 필요로하며, 일부는 일부 사용자 지정 설정 (예 : 클라이언트의 브라우저에서 JavaScript가 비활성화 됨)으로 인해 클라이언트 측에서 작동하지 않을 수 있습니다.

반면 서버 측 솔루션은 일반적으로 한 번만 작성됩니다. 새로운 Firefox / Chrome / IE / Opera가 출시되면 모든 것이 실패 할 것이라고 걱정할 필요가 없습니다. 또한 클라이언트가 앱을 무단 변경하거나 데이터를 손상 시키려고한다고 걱정할 필요가 없습니다.

당신의 감정에 절대적으로 동의하십시오. 또한 귀하가 말하는 것 이상으로 사이트가 서버와 다시 통신하는 주요 방식으로 REST가 급격히 감소하고 웹 소켓이 급격히 증가 할 것이라고 믿습니다. Vert.x, Node.js 등 전체 서버 측과 클라이언트 측이 이벤트 중심 프로그래밍으로 이동하고 있습니다. Java EE, PHP, Rails 등은 모두 적응해야하거나 매우 빨리 잃게됩니다.