HTML / JavaScript 전용 웹 앱의 장단점 [닫기]

ASP.NET 양식 배경에서 왔으며 과거에는 서버 측 코딩이 매우 강력하다는 것을 알았습니다. 그러나 최근에는 프론트 엔드의 서버 측 코드를 단계적으로 제거하고 JSON 웹 서비스를 통해 데이터에 액세스하는 순수한 HTML / JavaScript로 대체하려고했습니다. 나는 이것에 대한 실제 경험이 없으므로 이것이 시도되고 테스트 된 모델인지 듣고 싶습니다. 또한, 그 주위의 함정은 무엇입니까?

ASP.NET 사용자 컨트롤이 매우 유용하다는 것을 알게되었으므로 마크 업 템플릿을 서버의 별도 HTML 파일에 저장하여 이론을 유지하고 싶습니다. 이들은 jQuery AJAX 및 jQuery HTML 템플릿 플러그인을 통해 각각 검색 및 사용됩니다.

모든 의견은 대단히 감사하겠습니다.

추신 : 멍청한 질문에 대해 죄송하지만이 유형의 웹 아키텍처가 web-2.0이라고 불리는 것입니까?

이 기술을 우리가 작업하는 웹 응용 프로그램에만 사용했습니다. 백엔드는 Java SDK를 사용하여 Google App Engine에서 호스팅되며 프론트 엔드는 HTML, CSS 및 JavaScript (jQuery 포함)를 사용합니다.

이 프로젝트는 나 자신과 웹 디자이너 만있는 소규모 프로젝트이며,이 방법을 사용하면 훨씬 빠르게 작업하고 훨씬 더 빨리 제품을 출시 할 수 있다고 생각합니다.

장점 : 웹 디자이너 작업

이 기술의 주요 장점은 PHP를 알고 있지만 자신을 프로그래머로 생각하지 않는 웹 디자이너는 수많은 JSP, taglib 태그 및 기타 서버 측 라인을 거치지 않고도 HTML과 CSS에서 방해받지 않고 작업 할 수 있다는 것입니다. 우리가 몇 년 동안 들었던 마크 업은 프론트 엔드 개발자의 삶을 훨씬 더 쉽게 만들어 줄 것으로 기대 됩니다.

모든 서버 측 마크 업이 없으면 더 민첩 해졌습니다. 웹 디자이너는 원래 디자인을 3-4 회 직접 교체하고 수정했으며 내 부분은 거의 변경하지 않았습니다.

그의 의견은 HTML을 편집 한 다음 동적 데이터를 사용하여 컴퓨터의 변경 사항을 즉시 볼 수 있다는 점에서 HTML이 살아 있다고 느꼈습니다. 통합이 대부분 자동이라는 점에서 이점이 있습니다.

서버 측 코드 및 HTML / CSS 핸드 오프

과거 프로젝트에서 그는 HTML과 CSS를 Java 개발자에게 전달한 다음 HTML과 CSS를 가져 와서 JSP 기술을 사용하여 완전히 다시 작성해야했습니다. 이 작업에는 많은 시간이 걸리며 일반적으로 실제 페이지 렌더링 및 W3C 유효성 검사기의 유효성 검사에 미묘하지만 중요한 차이점이 있습니다.

전반적으로 우리는이 기술에 매우 만족하며 HTML 페이지에 JSP 페이지가 없거나 서버 측 코드가 없습니다.

REST / JSON 기술의 함정

아마도 가장 큰 함정은 우리가 아직 경험하지 못한 것입니다. 필자는 아파치 재단과 스프링 팀이 태그 라이브러리를 사용하여 프론트 엔드 개발자가 코드를 쉽게 사용할 수있는 방법에 대해 세뇌를 겪은 숙련 된 Java 개발자와 의견이 다를 것으로 예상합니다. 이 프로젝트가 확장됨에 따라 학습 곡선이 기대되며, 필자는 경험에 따라 웹 디자이너의 작업을 더욱 어렵게 만든 구식 기술을 익혀야하는 더 많은 개발자를 고용하고 있습니다.

또 다른 함정은 JavaScript 코드가 매우 커졌다는 것입니다. 이 기술을 처음 사용하고 있기 때문에 빠른 릴리스를 위해 약간의 기술적 빚을 졌기 때문에 이것은 아마도 더 큰 문제입니다. 더 나은 프레임 워크를 선택하면 많은 양의 코드를 완화하는 데 도움이되었을 것입니다. 제 생각에는 이것 중 어느 것도 쇼 토퍼가 아니 었습니다.이 기술을 계속 사용 하고이 분야의 기술을 향상시키는 것이 좋습니다.

장점 : 플랫폼에 다른 애플리케이션을 구축 할 수 있음

마지막으로 숨겨진 이점을 언급해야합니다. 백엔드 RESTful 웹 서비스와 프론트 엔드 사이에 상당한 분리가 있기 때문에 쉽게 확장 할 수있는 플랫폼을 만들었습니다.

운영 담당자 중 한 명이 다른 응용 프로그램에서 개념 증명을 시도하고 싶었고 RESTful 서비스 덕분에 완전히 다른 문제를 해결하기 위해 응용 프로그램과 완전히 다른 프런트 엔드를 만들 수있었습니다. 빠르게 개발 된 개념 증명은 자체 HTML, CSS 및 JavaScript를 사용했지만 RESTful 서비스를 백엔드 및 데이터 소스로 사용했습니다.

결국 다른 프로젝트 관리자는 내가 한 일을 보았고 그 기능이 단순한 개념 증명 이상의 것이 필요하다는 것을 즉시 알게되었으므로 그의 팀은 그것을 구현했습니다.

응용 프로그램 수준과 HTML / CSS / 자바 스크립트 수준에서이 아키텍처가 얼마나 재사용 가능한지 강조 할 수 없으므로 다음 프로젝트에서이 아키텍처를 사용해 보도록 권장합니다.

확실히 실행 가능한 전략이지만 은색 총알이 아닙니다.

찬성 :

• 올바르게 수행하면 이러한 방식으로 개발 된 응용 프로그램은 매우 반응이 빠릅니다
• 논리 (서버)와 프레젠테이션 (클라이언트)이 명확하게 분리되어 있습니다. 서버는 응용 프로그램의 표현 측면에 전혀 신경 쓸 필요가 없습니다.
• 잠재적으로 네트워크 대역폭을보다 효율적으로 사용할 수 있습니다 (원시 데이터 만 전송하고 프레젠테이션 용 상용구는 제공하지 않음)
• 요청 / 응답 패러다임에 덜 의존하기 때문에 데스크탑과 유사한 GUI를 쉽게 개발할 수 있습니다.

단점 :

• 클라이언트 코드를 Javascript 또는 Javascript로 컴파일 할 수있는 언어로 작성해야합니다. 브라우저에서 사용할 수있는 유일한 언어이기 때문입니다.
• 클라이언트의 리소스 사용량이 높을 수 있으므로 응용 프로그램이 하위 표준 장치 (모바일 브라우저 등)에서 제대로 작동하지 않을 수 있습니다.
• 자바 스크립트가 비활성화되어 있으면 전혀 작동하지 않습니다. 공개 웹 사이트가있는 경우이 위험을 기꺼이 감수할지 여부에 대해 열심히 생각해야합니다 (특히 SEO와 접근성을 고려할 경우 자바 스크립트가 많이 사용되는 접근 방식은 일반적 으로이 두 가지 측면에서 파괴적입니다)
• 많은 논리를 두 번 작성해야합니다. 클라이언트에 한 번, 서버에 다시 한 번 (클라이언트를 신뢰할 수 없기 때문에)
• 동시성은 지옥 일 수 있으므로 클라이언트 측 코드를 매우 신중하게 설계하고 모든 종류의 동시성 문제에 대비해야합니다.

확실히 가능하고 아마도 모범 사례로 권장 할 수 있습니다. 당신이 제안하는 것은 UI를 비즈니스 로직에서 분리하여 관심사를 명확하게 분리하는 것입니다. 정말 좋습니다.

너무 자주 우리가 문제를 모 으려고 시도하는 프레임 워크는 UI, 비즈니스 로직 및 데이터가 서로 얽혀있는 모 놀리 식 소프트웨어로 끝납니다. 따라서 유지 관리 및 수정이 더 어려워집니다.

응용 프로그램을 2 개로 분할하면 UI를 데스크톱 프로그램 또는 데스크톱 브라우저와 비교하여 모바일 용 다른 UI로 완전히 대체 할 수 있습니다.

이 작업을 수행 할 때 발견 할 까다로운 비트는 이론적으로 서버에 있어야하는 약간의 코드가 클라이언트에 더 잘 배치된다는 것입니다. 예를 들어 사용자가 유효성 검사 코드를 예를 들어, 텍스트 필드에는 영숫자 문자 만 포함되어 있는지 확인하기 위해 서버를 누르는 것보다 클라이언트에서 양식을 작성합니다. 데이터 및 비즈니스 계층에도 동일하게 적용됩니다. 레이어 간 구별을 위반할시기에 대한 정보를 제공하고 실용적인 결정을 내려야합니다.

한 가지 단점은 JavaScript와 ASP.net에서 일부 논리를 복제해야합니다. 응용 프로그램에 따라 큰 문제가 아닐 수 있습니다. 서버에 모든 작은 것을 확인하도록 요구하지 않기 때문에 종종 발생합니다 ( "이 상황에서 사용자 가이 버튼을 누르 거나이 옵션을 선택할 수 있습니까?"). 사용자가 클라이언트를 제어하기 때문에 유효성 검사를 수행하는 유일한 클라이언트로 클라이언트에서.

여전히 ASP.NET WebForms를 사용하고 있고 응용 프로그램 속도를 높이려면 다음과 같이해야합니다.

• SOLID 를 염두에두고 응용 프로그램 설계
• ViewState모든 페이지 및 사용자 컨트롤에서 비활성화

• 서버 측 컨트롤을 사용하지 마십시오

  <asp : Literal id = "Title"runat = "server"> 대신 <% : VeiwModel.Title %>

• 백엔드에서 OnInit 메소드를 대체하고 모든 초기화를 수행하십시오.

  보호 재정의 void void OnInit (System.EventArgs e) {CreateViewModel (); base.OnInit (e); }

• SquishIt를 사용하여 모든 .css 및 .js 파일을 1로 압축

• 지연로드 이미지
• 복잡한 객체 캐시

마지막으로 www.porsche.se를 확인하십시오. 망할 빠른 웹 사이트 아닌가요?