AngularJS가 정말 그렇게 완벽한가요? Anglejs의 여러 문제에 대한 자세한 분석

AngularJS의 장점에 대해서는 이야기하지 않겠습니다. 적어도 대부분의 프런트엔드 작업자는 여전히 AngularJS에 대해 열광적인 존경심을 갖고 있습니다. 개발이 쉬워지기 때문입니다. 그렇다면 문제는 왜 많은 유명 웹사이트에서 Angular를 사용하지 않는 걸까요? 이 글을 함께 살펴볼까요

몇 가지 포인트부터 시작해보겠습니다:

1. 최악의 SEO 친화성

이것은 의심할 여지 없이 매우 치명적이며, 이로 인해 많은 젊은 스타트업이 쉽게 시도하지 못하게 되었습니다. JavaScript를 사용하여 렌더링된 페이지는 검색 엔진 크롤러 및 소셜 미리보기 스크린샷에서 인식되지 않으며 기존 솔루션은 복잡하고 매우 느립니다.

실제로 페이지 로딩은 일반적으로 다섯 부분으로 구성됩니다(예: Java 사용).

1. 브라우저는 서버에 Http 요청을 보냅니다.

2. 서버는 이 요청을 처리하여 결과를 얻습니다. Jsp 템플릿을 얻어서 이 데이터를 템플릿을 통해 브라우저가 인식하는 HTML 텍스트로 구성하여 브라우저로 전송합니다

3. 브라우저는 HTML 텍스트를 파싱하여 페이지 콘텐츠를 표시합니다

마지막 단계는 브라우저가 HTML 텍스트를 얻는 때입니다. 즉, 이 프로세스가 끝나면 필요한 데이터가 표시됩니다. Angular를 사용하는 과정은 다음과 같습니다. 브라우저는 프런트 엔드 서버에 Http 요청을 보냅니다. Http request

1. 서버는 이 요청을 처리하여 결과 데이터를 얻고, 결과 데이터를 Json 형식으로 캡슐화하여 보냅니다. the browser

2. 브라우저는 Json을 파싱하여 페이지에 데이터를 표시합니다

3. 이 두 프로세스 중 하나는 페이지 작성 작업을 서버에 두는 것이고, 다른 하나는 브라우저에 두는 것입니다. 이것이 가장 분명한 차이점입니다. 추가 상호 작용 수는 말할 것도 없고, 검색 엔진의 관점에서는 브라우저에서 얻은 정적 콘텐츠만 볼 수 있으며 js 코드는 실행되지 않습니다.

전자 검색엔진에서는 기사가 보이고, 후자 검색엔진에서는 중괄호가 차례로 보입니다! 이는 Angular에서 렌더링한 페이지가 Baidu의 "블랙리스트"에 포함되는 이유이기도 합니다. 그렇다면 어떻게 해결해야 할까요?

4. 인용문:

5. 크롤러가 웹사이트에 액세스하도록 허용하는 방법에는 두 가지가 있습니다. 서버에서 브라우저 인스턴스를 실행한 다음 JavaScript 실행 후 DOM을 기반으로 HTML 페이지를 생성할 수 있습니다. 또는 검색 크롤러를 위한 또 다른 HTML 정적 페이지 세트를 구축할 수 있습니다.

   이전 솔루션을 사용하려면 WebKit(및 Xvfb도 가능)을 설치한 다음 로드된 후 페이지를 생성해야 합니다(캐싱을 사용할 수도 있지만 이로 인해 복잡성이 더해집니다.). 이로 인해 페이지 로드 시간이 늘어나고 이는 검색 엔진 순위에 영향을 미칩니다. .

   후자의 솔루션(다른 서버측 웹사이트를 만드는 것)은 간단한 웹사이트를 만족시킬 수 있지만 페이지가 매우 다양하다면 악몽이 될 것입니다. 그리고 백업 웹사이트가 기본 웹사이트와 완전히 일치하지 않는 경우 Google은 귀하를 엄중하게 처벌하고 트래픽이 급락할 것입니다.

2. 최악의 사용자 경험

AngularJS를 사용한 후 페이지 렌더링 방법이 여러 프로세스로 분할되어 있으므로 페이지를 방문했는데 페이지에 콘텐츠가 많으면 브라우저의 렌더링에서 분명히 느낄 것입니다. 로드할 콘텐츠가 너무 많습니다. 이 프로세스는 매우 좋지 않습니다. 특히 로드 프로세스가 클라이언트에 배치되면 지연이 매우 커집니다.

리치 JavaScript 애플리케이션에서는 일반적으로 페이지 전환이 즉시 발생한 다음 서버에서 다양한 요소가 로드됩니다. 서버 측 애플리케이션에서는 클라이언트가 모든 데이터를 다운로드할 때까지 기다리지 않고 페이지가 데이터 렌더링을 시작합니다.

클라이언트 애플리케이션이 더 나은 것처럼 들리지만 사실 이것은 환상입니다.

사용자가 링크를 클릭하면 클라이언트의 JS 애플리케이션에 로딩 애니메이션이 즉시 나타나지만 데이터를 로드하는 데 5초가 걸린다고 상상해 보세요. 얼핏 보기에는 애플리케이션이 빨라 보이지만,
이 한 페이지에 얼마나 많은 프로그래머가 기능을 추가하고 싶어하는지 논하지 않겠습니다. 사람들에게 콘텐츠를 비동기식으로 빠르게 표시하도록 요구하는 것은 어렵습니다. 실제로 사람들은 페이지 아래의 내용이 나중에 로드되는지 신경 쓰지 않을 것입니다.

서버 측 애플리케이션에서 API 호출이 느리면 전체 페이지가 느리게 로드됩니다. 서버 측 속도 저하는 모든 사람에게 영향을 주기 때문에 무시할 수 없습니다. 그러나 클라이언트의 느린 속도는 쉽게 간과됩니다.

서버는 귀하가 구성한 머신에서 제어 가능하고 실행되기 때문에 서버의 속도 저하를 쉽게 해결할 수 있습니다. 또한 대부분의 서버는 내부 클러스터 네트워크에 있으므로 서버 간 정보 전송이 매우 빠릅니다. 작업에 여러 정보 전송이 필요한 경우에도 즉시 완료할 수 있습니다. 그러나 이러한 전송을 클라이언트에 넣으면 여러 가지 요인으로 인해 속도가 느려집니다.
사용자가 사용하는 브라우저나 사용자 컴퓨터의 구성을 엄격하게 제어할 수는 없지만 자체 서버에 대한 모든 것을 제어할 수 있습니다.

3. 제일 중요한건 너무 맛이없다

맛없다? 어떤 사람들은 AngularJS가 '유지 관리가 쉽다', '코딩이 편리하다' 등 다양한 장점이 있다고 말할 것입니다. 그러나 이는 성능과 사용자 경험의 희생을 기반으로 합니다. 그리고 소위 '의존성 주입' 및 기타 백엔드 아이디어가 프런트엔드에 강제로 도입됩니다. 이것은 고상해 보이지만 무엇이 잘못된 것 같습니까? 백엔드는 구조와 서비스로 구분되어 있으며, 보다 간단한 개발을 위해 다양한 프레임워크를 사용하고 있습니다. 웹 프론트엔드 자체는 브라우저에 나타나는 HTML 텍스트일 뿐이며 비즈니스와 관련이 없을 것 같습니다. 그에게 어떤 진정한 도움이라도요.

이러한 편리성에서 쓸모없다고는 할 수 없지만, 어떠한 경우에도 AngularJS를 완벽하게 대체하고 그보다 더 나은 성능을 발휘할 수 있는 솔루션은 거의 존재합니다. 이것. . . 이건 부끄러운 일이에요! 예를 들어 freemaker.

Freemaker는 비동기적으로 데이터를 얻기 위해 ajax를 통해 http 요청을 실행하는 대신 Java에서 제공하는 freemakerApi 함수를 직접 호출할 수 있습니다. 마찬가지로 성능도 AngularJS를 능가합니다. 성능에 비하면 다소 부담스러울 수도 있지만 템플릿 엔진으로서 freemaker는 실제로 성능 측면에서 AngularJS를 압도할 자격이 있습니다.

사용 편의성 측면에서 Freemaker는 Java 함수를 직접 호출하는 것 외에도 http를 통해 데이터를 얻을 수도 있지만, 얻은 데이터를 HTML 텍스트로 구축한 다음 분석을 위해 브라우저에 전달하는 것이 가장 중요합니다. 그렇습니다. 종속성 주입 및 기타 관련 기능도 지원하며 백엔드 프로그램과 완벽하게 통합됩니다. 위의 점을 결합하면 확장성, 유지 관리성, 전반적인 성능, 사용자 경험 등의 측면에서 AngularJS를 압도합니다. AngularJS만큼 좋지 않은 유일한 것은 개발 단계입니다. 앵귤러에 비해 프리메이커 개발은 더 복잡하다, 즉 개발 과정에서 앵귤러가 훨씬 단순하다는 것, 단지 개발이 즐겁고 많은 성능 요소가 버려진다는 점 때문이라면 매우 무서운 일이다. 성능 메커니즘을 추구하기 위해 지속적으로 최적화하는 반면, 일부 사람들은 단순한 개발을 위해 최적화하고 있습니다. 누가 옳고 그른지 말할 수는 없지만 전자를 선호합니다.

Freemaker는 제쳐두고 nodejs에는 교체 가능한 솔루션과 MVC 프레임워크도 많이 있으므로 여기서는 자세히 설명하지 않겠습니다.

브라우저에서 js의 역할은 콘텐츠 표현보다는 상호작용에 더 있어야 한다고 생각합니다. 그것은 올바른 해결책이 아닙니다.

4. 애플리케이션 시나리오 문제

프론트엔드와 백엔드가 분리된 시나리오에서는 AngularJS가 좋은 선택인 것 같지만 위에서 언급한 것처럼 프론트엔드와 백엔드가 분리된 경우 AngularJS의 고려 사항이 너무 좁습니다. 분리, 개발 변경과 더불어 편리하지만 원래의 성능과 경험을 잃어버리게 되는데, 이는 의심의 여지가 없는 실패입니다. 이러한 이유와 함께 AngularJS를 사용할 수 있는 시나리오는 거의 없을 것 같습니다. 백그라운드(백엔드 관리 제어판) 및 WEBApp 여러 시나리오에서 사용할 수 있습니다.

그러면 관리 콘솔 페이지를 개발할 때 성능을 너무 많이 고려할 필요도 없고 SEO에 최적화할 필요도 없다는 것이 사실입니다. 하지만 이 시나리오의 중간 지점은 콘텐츠가 아니라 상호 작용입니다. 표시하다. AngularJS는 프런트엔드 템플릿 엔진으로서의 위치를 ​​잃었습니다. 그의 역할은 미미해서 당황스러웠다.

WebApp을 개발할 때 성능 측면에서는 SEO를 고려할 필요가 없을 수도 있습니다. App 프레임워크는 사용자가 사용하는 클라이언트 버전을 엄격하게 제어할 수 있기 때문에 성능을 최적화할 수 있습니다. 앱 프레임워크를 선택할 수도 있지만 앱 개발 프레임워크를 직접 선택할 수 있기 때문에 거의 모든 앱 프레임워크에는 성능과 사용 편의성 측면에서 AngularJS를 능가하는 솔루션이 있습니다. 따라서 이는 관리 콘솔 페이지를 개발하는 것보다 더 나쁜 것 같습니다.

이러한 점을 볼 때 AngularJS의 입장은 매우 당황스럽다고 생각합니다.

충돌이 없는 유일한 시나리오는 기업의 내부 애플리케이션을 개발하는 시나리오일 수 있습니다.

이것이 AngularJS가 훌륭해 보이지만 이를 선택하는 회사가 거의 없는 이유일 수 있습니다. 성능 추구는 모든 프로그래머가 가져야 할 의무이며, 특히 백엔드 개발에 종사하는 사람들은 겉보기에 편리한 개발을 위해 더 많은 것을 고려하고 경험을 포기할 수 없습니다. 정말 포기한다면 중학교와 고등학교는 어떤 구분을 두게 될까요? 건축가는 어디서 왔나요? 일련의 코드 상담을 시작하십시오.

마찬가지로, 이는 인터뷰 중에 일부 프론트엔드 엔지니어들에게도 당혹감을 안겨주었습니다.

Q: AngularJ를 사용하는 방법을 알고 계십니까?
대답: 그렇습니다! 잘. . 하지만 많이 사용되지는 않았습니다. . 하지만 정말 그렇습니다. . 어

AngularJS의 장점에 대해서는 이야기하지 않겠습니다. 적어도 대부분의 프런트엔드 작업자는 여전히 AngularJS에 대해 열광적인 존경심을 갖고 있습니다. 개발이 쉬워지기 때문입니다. 그렇다면 문제는 왜 많은 유명 웹사이트가 Angular를 사용하지 않는가 하는 것입니다.
몇 가지 사항부터 시작하겠습니다.

1. 최악의 SEO 친화성

이것은 의심할 여지 없이 매우 치명적이며 이로 인해 많은 젊은이들이 시작해야 하는 중요한 이유입니다. 기업은 감히 시도하지 않습니다. JavaScript를 사용하여 렌더링된 페이지는 검색 엔진 크롤러 및 소셜 미리보기 스크린샷에서 인식되지 않으며 기존 솔루션은 복잡하고 매우 느립니다.

사실 일반적으로 페이지 로딩은 다섯 부분으로 구성됩니다(예: Java 사용).

1. 브라우저에서 이를 보냅니다. 서버 HTTP 요청과 같습니다

2. 서버는 이 요청을 처리하여 결과 데이터를 얻고, Jsp 템플릿을 얻은 다음, 해당 데이터를 브라우저에서 인식하는 HTML 텍스트로 빌드합니다. 템플릿을 만들어 브라우저로 보냅니다.

3. 브라우저는 HTML 텍스트를 구문 분석하고 페이지 콘텐츠를 렌더링합니다.

마지막 단계는 브라우저가 HTML 텍스트를 얻을 때, 즉 프로세스가 끝나면 필요한 데이터가 표시된다는 것을 알 수 있습니다. Angular를 사용하는 과정은 다음과 같습니다:

1. 브라우저가 프런트 엔드 서버에 Http 요청을 보냅니다

2. #🎜 🎜#Front-end 서버가 HTML 템플릿을 브라우저로 보냅니다

3. 브라우저가 HTML을 구문 분석하고 js 스크립트를 실행한 후 비즈니스 서버로 Http 요청을 보냅니다.

4. 서버는 이 요청을 처리하여 결과 데이터를 얻고, 결과 데이터를 Json 형식으로 캡슐화하여 브라우저로 보냅니다
   #🎜 🎜#
브라우저는 Json을 구문 분석하고 페이지에 두 가지 프로세스가 있습니다.
에서 페이지 빌드 작업을 실행합니다. 서버, 다른 하나는 브라우저에서 실행하는 것입니다. 이것이 가장 분명한 차이점입니다. 추가 상호 작용 수는 말할 것도 없고, 검색 엔진의 관점에서는 브라우저에서 얻은 정적 콘텐츠만 볼 수 있으며 js 코드는 실행되지 않습니다.

전자 검색엔진에서는 기사가 보이고, 후자 검색엔진에서는 중괄호가 하나씩 보입니다! 이는 Angular에서 렌더링한 페이지가 Baidu의 "블랙리스트"에 포함되는 이유이기도 합니다. 그렇다면 어떻게 해결해야 할까요?

인용문:

크롤러가 웹사이트에 액세스하도록 허용하는 방법에는 두 가지가 있습니다. 서버에서 브라우저 인스턴스를 실행한 다음 JavaScript 실행 후 DOM을 기반으로 HTML 페이지를 생성할 수 있습니다. 또는 검색 크롤러를 위한 또 다른 HTML 정적 페이지 세트를 구축할 수 있습니다.

이전 솔루션을 사용하려면 WebKit(및 Xvfb도 가능)을 설치한 다음 로드된 후 페이지를 생성해야 합니다(캐싱을 사용할 수도 있지만 이로 인해 복잡성이 더해집니다.). 이로 인해 페이지 로드 시간이 늘어나고 이는 검색 엔진 순위에 영향을 미칩니다. .

후자의 솔루션(다른 서버측 웹사이트를 만드는 것)은 간단한 웹사이트를 만족시킬 수 있지만 페이지가 매우 다양하다면 악몽이 될 것입니다. 그리고 백업 웹사이트가 기본 웹사이트와 완전히 일치하지 않는 경우 Google은 귀하를 엄중하게 처벌하고 트래픽이 급락할 것입니다.

2. 최악의 사용자 경험

AngularJS를 사용한 후 페이지 렌더링 방법이 여러 프로세스로 분할되어 페이지를 방문하면 이 페이지에 콘텐츠가 너무 많으면 브라우저의 렌더링 프로세스로 인해 로드할 콘텐츠가 너무 많다는 것을 분명히 느낄 것입니다. 특히 로딩 프로세스가 클라이언트에 배치되면 지연이 발생합니다. 매우 크다.

리치 JavaScript 애플리케이션에서는 일반적으로 페이지 전환이 즉시 발생한 다음 서버에서 다른 요소가 로드됩니다. 서버 측 애플리케이션에서는 클라이언트가 모든 데이터를 다운로드할 때까지 기다리지 않고 페이지가 데이터 렌더링을 시작합니다.

클라이언트 애플리케이션이 더 좋을 것 같지만 사실 이것은 착각입니다.

사용자가 링크를 클릭하면 클라이언트의 JS 애플리케이션에 로딩 애니메이션이 즉시 나타나지만 데이터를 로드하는 데 5초가 걸린다고 상상해 보세요. 이 애플리케이션은 얼핏 보면 빨라 보입니다.

얼마나 많은 프로그래머가 이 페이지에 기능을 추가하고 싶어하는지 논하지 않겠습니다. 사람들에게 콘텐츠를 비동기식으로 빠르게 표시하도록 요구하는 것은 어렵습니다. 실제로 사람들은 페이지 아래 항목이 나중에 로드되는지 신경 쓰지 않을 것입니다.

서버측 애플리케이션에서는 API 호출이 느리면 전체 페이지가 느리게 로드됩니다. 서버 측 속도 저하는 모든 사람에게 영향을 주기 때문에 무시할 수 없습니다. 그러나 클라이언트의 느린 속도는 쉽게 간과됩니다.

서버는 귀하가 구성한 머신에서 제어 가능하고 실행되기 때문에 서버의 속도 저하를 쉽게 해결할 수 있습니다. 또한 대부분의 서버는 내부 클러스터 네트워크에 있으므로 서버 간 정보 전송이 매우 빠릅니다. 작업에 여러 정보 전송이 필요한 경우에도 즉시 완료할 수 있습니다. 그러나 이러한 전송을 클라이언트에 넣으면 여러 가지 요인으로 인해 속도가 느려집니다.
사용자가 사용하는 브라우저나 사용자 컴퓨터의 구성을 엄격하게 제어할 수는 없지만 자체 서버에 대한 모든 것을 제어할 수 있습니다. (자세한 내용은 PHP 중국어 홈페이지AngularJS 개발 매뉴얼을 참고하세요.)

3. 제일 중요한 건 너무 맛이 없다

맛이 없다? 어떤 사람들은 AngularJS가 '유지 관리가 쉽다', '코딩이 편리하다' 등 다양한 장점이 있다고 말할 것입니다. 그러나 이는 성능과 사용자 경험의 희생을 기반으로 합니다. 그리고 소위 '의존성 주입' 및 기타 백엔드 아이디어가 프런트엔드에 강제로 도입됩니다. 이것은 고상해 보이지만 무엇이 잘못된 것 같습니까? 백엔드는 구조와 서비스로 구분되어 있으며, 보다 간단한 개발을 위해 다양한 프레임워크를 사용하고 있습니다. 웹 프론트엔드 자체는 브라우저에 나타나는 HTML 텍스트일 뿐이며 비즈니스와 관련이 없을 것 같습니다. 그에게 어떤 진정한 도움이라도요.

이러한 편리성에서 쓸모없다고는 할 수 없지만, 어떠한 경우에도 AngularJS를 완벽하게 대체하고 그보다 더 나은 성능을 발휘할 수 있는 솔루션은 거의 존재합니다. 이것. . . 이건 부끄러운 일이에요! 예를 들어 freemaker.

Freemaker는 비동기적으로 데이터를 얻기 위해 ajax를 통해 http 요청을 실행하는 대신 Java에서 제공하는 freemakerApi 함수를 직접 호출할 수 있습니다. 마찬가지로 성능도 AngularJS를 능가합니다. 성능에 비하면 다소 부담스러울 수도 있지만 템플릿 엔진으로서 freemaker는 실제로 성능 측면에서 AngularJS를 압도할 자격이 있습니다.

사용 편의성 측면에서 Freemaker는 Java 함수를 직접 호출하는 것 외에도 http를 통해 데이터를 얻을 수도 있지만, 얻은 데이터를 HTML 텍스트로 구축한 다음 분석을 위해 브라우저에 전달하는 것이 가장 중요합니다. 그렇습니다. 종속성 주입 및 기타 관련 기능도 지원하며 백엔드 프로그램과 완벽하게 통합됩니다. 위의 점을 결합하면 확장성, 유지 관리성, 전반적인 성능, 사용자 경험 등의 측면에서 AngularJS를 압도합니다. AngularJS만큼 좋지 않은 유일한 것은 개발 단계입니다. 앵귤러에 비해 프리메이커 개발은 더 복잡하다, 즉 개발 과정에서 앵귤러가 훨씬 단순하다는 것, 단지 개발이 즐겁고 많은 성능 요소가 버려진다는 점 때문이라면 매우 무서운 일이다. 성능 메커니즘을 추구하기 위해 지속적으로 최적화하는 반면, 일부 사람들은 단순한 개발을 위해 최적화하고 있습니다. 누가 옳고 그른지 말할 수는 없지만 전자를 선호합니다.

Freemaker는 제쳐두고 nodejs에는 교체 가능한 솔루션과 MVC 프레임워크도 많이 있으므로 여기서는 자세히 설명하지 않겠습니다.

브라우저에서 js의 역할은 콘텐츠 표현보다는 상호작용에 더 있어야 한다고 생각합니다. 그것은 올바른 해결책이 아닙니다.

4. 애플리케이션 시나리오 문제

프론트엔드와 백엔드가 분리된 시나리오에서는 AngularJS가 좋은 선택인 것 같지만 위에서 언급한 것처럼 프론트엔드와 백엔드가 분리된 경우 AngularJS의 고려 사항이 너무 좁습니다. 분리, 개발 변경과 더불어 편리하지만 원래의 성능과 경험을 잃어버리게 되는데, 이는 의심의 여지가 없는 실패입니다. 이러한 이유와 함께 AngularJS를 사용할 수 있는 시나리오는 거의 없을 것 같습니다. 백그라운드(백엔드 관리 제어판) 및 WEBApp 여러 시나리오에서 사용할 수 있습니다.

그러면 관리 콘솔 페이지를 개발할 때 성능을 너무 많이 고려할 필요도 없고 SEO에 최적화할 필요도 없다는 것이 사실입니다. 하지만 이 시나리오의 중간 지점은 콘텐츠가 아니라 상호 작용입니다. 표시하다. AngularJS는 프런트엔드 템플릿 엔진으로서의 위치를 ​​잃었습니다. 그의 역할은 미미해서 당황스러웠다.

WebApp을 개발할 때 성능 측면에서는 SEO를 고려할 필요가 없을 수도 있습니다. App 프레임워크는 사용자가 사용하는 클라이언트 버전을 엄격하게 제어할 수 있기 때문에 성능을 최적화할 수 있습니다. 앱 프레임워크를 선택할 수도 있지만 앱 개발 프레임워크를 직접 선택할 수 있기 때문에 거의 모든 앱 프레임워크에는 성능과 사용 편의성 측면에서 AngularJS를 능가하는 솔루션이 있습니다. 따라서 이는 관리 콘솔 페이지를 개발하는 것보다 더 나쁜 것 같습니다.

이러한 점을 볼 때 AngularJS의 입장은 매우 당황스럽다고 생각합니다.

충돌이 없는 유일한 시나리오는 기업의 내부 애플리케이션을 개발하는 시나리오일 수 있습니다.

이것이 AngularJS가 훌륭해 보이지만 이를 선택하는 회사가 거의 없는 이유일 수 있습니다. 성능 추구는 모든 프로그래머가 가져야 할 의무이며, 특히 백엔드 개발에 종사하는 사람들은 겉보기에 편리한 개발을 위해 더 많은 것을 고려하고 경험을 포기할 수 없습니다. 정말 포기한다면 중학교와 고등학교는 어떤 구분을 두게 될까요? 건축가는 어디서 왔나요? 일련의 코드 상담을 시작하십시오.

마찬가지로, 이 문제는 프론트엔드 엔지니어 인터뷰에서도 당황스러웠습니다.

Q: AngularJ를 사용하는 방법을 알고 있나요? ​

답변: 네! 잘. . 하지만 많이 사용되지는 않았습니다. . 하지만 정말 그렇습니다. . 어

이 기사는 여기서 끝납니다. (자세한 내용을 보려면 PHP 중국어 웹사이트 AngularJS 사용자 설명서 로 이동하세요.) 질문이 있으시면 아래에 질문을 남겨주세요.

위 내용은 AngularJS가 정말 그렇게 완벽한가요? Anglejs의 여러 문제에 대한 자세한 분석의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!