JavaScript는 언제 HTML을 생성해야합니까?

JavaScript에서 가능한 한 작은 HTML을 생성하려고합니다. 대신 Ajax를 사용하기에 적합하지 않은 요소를 동적으로 삽입해야 할 때만 HTML을 생성 할 수있을 때마다 기존 마크 업을 조작하는 것을 선호합니다. 따라서 마크 업을 쉽게 읽고 추적 할 수 있기 때문에 코드를 유지 관리하고 코드를 훨씬 빠르게 변경할 수 있습니다. 내 경험에 따르면 HTML은 문서 구조, CSS는 프리젠 테이션, JavaScript는 동작입니다.

그러나 전체 양식과 내용이 많은 모달 대화 상자를 포함하여 많은 HTML을 생성하는 많은 JS 코드를 보았습니다. 일반적으로 어떤 방법이 모범 사례로 간주됩니까? 어떤 상황에서 JavaScript를 사용하여 HTML을 생성해야합니까?

자바 스크립트에서 HTML 생성이 많이 발생할 때마다 거의 독립형 UI 플러그인이었습니다. 전체 플러그인을 단일 .js 파일 (스타일을 사용자 정의하기위한 .css)로 캡슐화 할 수 있으므로 응용 프로그램에 사용 된 프레임 워크와 쉽게 재사용, 배포 및 독립적으로 만들 수 있습니다.

따라서 다른 응용 프로그램에서 사용하려는 독립형 Javascript 플러그인 또는 일반 UI 구성 요소를 작성하는 경우 이러한 접근 방식에는 단점이 있습니다. 그렇지 않으면 HTML 생성을 자바 스크립트와 서버 측에서 멀리 유지할 때 더 깨끗하고 작성하기 쉽고 유지 관리하기 쉽다고 생각합니다.

문제는 깨끗하게 작성된 서버 측 템플릿을 잘못 작성된 임시 클라이언트 측 HTML 생성과 비교하는 것입니다. 물론 깔끔하게 작성된 코드는 읽기, 유지 관리 및 추적이 더 쉽습니다.

클라이언트 측 코드를 "Mounds of HTML"이라고 부르지 만 생성되는 모든 HTML은 물론 동일합니다. "마운드"는 실제로 코드의 큰 덩어리입니다.

클라이언트 측 템플릿 라이브러리가 많이 있습니다. 그들은 서버 쪽과 비슷하게 작동합니다. 어느 쪽을 선호하든 성능 상충 관계는 복잡하지만 JSON은 일반적으로 HTML보다 더 컴팩트하며 클라이언트에 템플릿이 있으면 일부 서버 호출 이 제거 될 수 있습니다 . 반면에 클라이언트가 JS를 사용하지 않도록 설정했거나 실용하기에는 너무 느릴 수 있으므로 대상 고객에 따라 다릅니다. 전반적으로 접근 방식이 상당히 유사하다고 생각합니다. 가장 큰 요인은 대상 고객의 브라우저 기능입니다.

그러나 서버 환경보다 JS를 선호하는지, 원하는 템플릿 솔루션 등을 수행하는지에 따라 다릅니다.

클라이언트 측 템플릿을 사용하는 경향이 있습니다. 극단적 인 경우 모든 렌더링 클라이언트 측을 수행하는 동안 서버가 JSON 형식으로 RESTful API 만 제공하는 경우가 있습니다. 이 접근 방식의 장점은 JS 코드와 템플릿이 CDN을 통해 캐시, 프록시 및 배포 할 수있는 정적 리소스라는 것입니다. 서버 측에서 생성 된 동적 HTML이있는 경우 수행 할 수 없습니다. 또한 RESTful API에서 경량 형식으로 데이터 만 반환하면 서버 측 리소스가 훨씬 적게 사용되므로 응답 속도가 빨라집니다. 또한 가벼워지면 네트워크 전송이 줄어들어 다시 더 빨라집니다. 이런 식으로 3G와 같은 느린 연결에서도 응답 속도가 짧은 저 응용 프로그램을 사용할 수 있습니다. 따라서이 방법은 모바일 페이지 및 응용 프로그램에 널리 사용됩니다.

JS 템플릿을 구현하는 수많은 라이브러리가 있으며 인기있는 라이브러리 중 하나는 Pure , Mustache 및 dust.js 입니다. 나중에 LinkedIn에서 사용하며 "먼지에서 JSP를 떠나기 : LinkedIn을 dust.js 클라이언트 측 템플릿으로 이동" 기사의 장점을 설명했습니다 .

클라이언트에서 HTML을 생성하는 이점은 렌더링 작업을 각 클라이언트에 오프로드하여 응답을 기다리는 유휴 상태라는 것입니다. 더 많은 서버 리소스를 확보하여 JSON 데이터 및 정적 컨텐츠 (HTML, JS 및 CSS) 만 제공합니다.

우리는 Javascript로 HTML을 독점적으로 생성하는 웹 앱을 수행합니다. 서버 적중의 87 %는 JSON 데이터이며 정적 콘텐츠는 일반적으로 한 번로드 된 다음 브라우저 캐시에서로드됩니다.

그러나 SEO가 필요한 경우 적어도 쉽게 사용할 수는 없습니다. 또는 자바 스크립트를 사용 중지 한 인구를 대상으로했지만 유튜브, 트위터, 페이스 북, Gmail 등과 관련이 있는지 확실하지 않습니다.

동적 페이지 로딩과 관련하여 모든 "JQuery AJAX Cloud!" 마술, 가능한 두 가지 일이 일어나고 있습니다.

1. 요소의 코드가 div (나쁜)에 주입되고 있거나
2. 콘텐츠가 iframe에로드되고 있습니다 (더 나은 것은 아니지만 동일하지는 않습니다 ...)

원래 질문에 관해서는 서버에 저장된 XML 또는 JSON 데이터를 읽는 웹 응용 프로그램을 만들 때 Javascript를 통해 HTML 내용 만 만들며 많이 변경됩니다.

자바 스크립트를 사용하여 페이지에 정적 콘텐츠를로드하는 것은 의미가 없습니다. 항상 제대로로드되지 않을 가능성이 있거나 클라이언트가이를 비활성화 할 수 있기 때문입니다 ( "성가신 광고"). 또한, 추악 document.write()하거나 체인 안에 HTML 콘텐츠가 밀려 들어가면 변경하기가 매우 어렵습니다 document.createElement().

그래서 당신은 옳습니다. 원시 HTML을 입력하거나 동적 컨텐츠가 필요한 경우 서버 측 스크립트를 사용하여 필요한 것을 출력하십시오. 사이트가 인터넷에 연결되지 않은 경우 또는 이와 유사한 경우에만 Javascript를 사용하여 HTML을 삽입하십시오.

마지막으로, xmlhttprequests, er, AJAX를 웹 사이트에 구현하려면 데이터를 XML과 같은 데이터 형식으로 저장하고로드하여 그에 따라 출력하는 것이 가장 안전하고 안전한 방법 일 것입니다 클라이언트에서. document.write그리고 element.innerHTML정말로 (그 이유는 무엇입니까? 내 깨진 실행이 스크립트없는 내용을 조작에 대해 갈 수있는 가장 좋은 방법이 아니며, 미래의 잠재적 인 두통을 일으킬 수밖에 없다 <i>태그가 모든 것을 이탤릭체입니다! 등).

그것에 대한 나의 진언은 : 더 쉽고 아무도 마크 업에 신경 쓰지 않을 때입니다.

마크 업을 관리하기가 너무 어려워 DOM 트리에 중점을 두는 한계를 정의 할 수도 있습니다. 예를 들어, 동적 행이있는 양식 (예 : "다른 첨부 파일 추가") 인 경우 HTML 형식, "행 추가"버튼 및 제출 버튼을 원할 것입니다. 서버 측 언어 또는 HTML이 포함 된 HTML

경험의 또 다른 규칙은 재사용 성일 수 있습니다. 클라이언트 쪽의 다른 문제에 솔루션을 적용 할 수 있으면 js로 캡슐화하십시오.

Google은 단일 페이지 앱 (ala Google Mail)을 구축하며 문자 그대로 앱에 서버 측 HTML 생성이 없습니다 . 대신 Backbone.js를 사용하여 클라이언트 측과 Handlebars를 구성하여 JSON을 페이지로 이동하는 템플릿으로 렌더링합니다. 실제로 잘 작동하며 앱을 사용하는 첫 번째 앱이 닫히고 앞으로 더 큰 프로젝트를 처리 할 것입니다.

서버가 데이터를 유지하고 쿼리 결과를 반환하는 데만 사용되는 모든 종류의 뚱뚱한 클라이언트는 JavaScript가 HTML을 생성하기를 원하는 포스터 아이입니다. 좋은 템플릿 엔진을 사용하여 깨끗하고 쉽게 만드십시오.

포틀릿을 사용하고 있기 때문에 jquery에서 html 코드를 생성하고 있으며 jsp 코드 실행 후 html 코드로 루프를 작성해야합니다. 그래서 자바 배열에 자바 배열 목록을 렌더링하고 문자열을 사용하여 html을 생성합니다.