프론트엔드 프레임워크: 솔루션 또는 부풀려진 문제?

최신 프론트 엔드 프레임워크를 사용하려면 브라우저에서 보기 전에 개발 환경을 다운로드하고, 종속성을 포함하고, 코드를 컴파일해야 합니다. 좋은 일입니까? 우리가 더 복잡한 사이트를 구축하는 것이 문제입니까, 아니면 프레임워크 자체가 복잡하여 불필요한 수준의 복잡성을 초래하는 것입니까?

오늘날 웹 개발은 90년대 이후로 많이 발전했습니다. 우리는 모든 기본 애플리케이션이 할 수 있는 것과 매우 유사한 전체 경험을 만들 수 있으며 개발 프로세스도 변경되었습니다. 프론트엔드 웹 개발자가 되는 것이 메모장을 열고 몇 줄의 코드를 입력하고 브라우저에서 확인하고 FTP 폴더에 업로드하는 문제였던 시대는 지났습니다.

과거의 프론트엔드 웹 개발

나는 분명한 사실부터 시작해야 합니다. 세상은 10년 전과 같지 않습니다. (충격적, 나도 안다.) 변하지 않는 것은 변화뿐이다. 예전에는 브라우저가 거의 없었지만 호환성 문제가 많았습니다. 오늘날에는 "Chrome 43.4.1에서 가장 잘 표시됨"과 같은 항목을 많이 볼 수 없지만 당시에는 꽤 일반적이었습니다. 이제 더 많은 브라우저가 있지만 호환성 문제는 적습니다. 왜요? jQuery 때문에 . jQuery는 각 브라우저와 각 브라우저 버전에서 실행되는 방식에 대해 걱정할 필요 없이 DOM을 조작하는 JavaScript 코드를 작성할 수 있는 표준 공통 라이브러리의 필요성을 충족시켰습니다. 2000년대의 진정한 악몽이었습니다. .

최신 브라우저는 DOM을 표준으로 조작할 수 있으므로 이러한 라이브러리의 필요성은 최근 몇 년 동안 크게 감소했습니다. jQuery는 더 이상 필요 하지 않지만 이에 의존하는 매우 유용한 플러그인을 많이 찾을 수 있습니다. 즉, 웹 프레임워크는 필요하지 않을 수 있지만 여전히 대중적이고 널리 사용될 만큼 유용합니다. 이것은 React, Angular, Vue 및 Ember에서 Bootstrap과 같은 스타일 및 형식 지정 모델에 이르기까지 널리 사용되는 대부분의 웹 프레임워크에 공통적인 특성입니다.

사람들이 프레임워크를 사용하는 이유

인생에서와 마찬가지로 웹 개발에서 빠른 솔루션을 갖는 것은 항상 편리합니다. 이전에 JavaScript에서 라우터를 수행한 적이 있습니까? 문제를 극복하기 위해 프론트엔드 프레임워크를 npm으로 설치할 수 있는데 왜 고통스러운 학습 과정을 거쳐야 합니까? 클라이언트가 어제 작업을 완료하기를 원하거나 특정 프레임워크를 위해 설계된 다른 개발자로부터 코드를 상속받거나 주어진 프레임워크를 이미 사용 중인 팀과 통합하는 경우 시간은 사치입니다. 프레임워크가 존재하는 데는 이유가 있습니다. 그들에게 이익이 없다면 아무도 그것을 사용하지 않을 것입니다.

그렇다면 웹 개발 프레임워크를 사용할 때의 이점과 고유한 속성은 무엇입니까?

시간은 돈이다. 당신이 프로젝트를 개발할 때 클라이언트는 당신이 어떤 프레임워크를 사용하는지 신경 쓰지 않을 것입니다. 실제로, 아마도 당신이 무엇을 사용하는지조차 알지 못할 것입니다. 확립된 프레임워크를 사용하면 처음부터 고객이 갈망하는 진행 상황에 대한 즉각적인 감각을 생성할 수 있습니다. 또한 프레임워크에서 확보한 시간을 더 많은 작업을 수행하는 데 사용할 수 있으므로 개발이 빠를수록 더 많은 돈을 벌 수 있습니다. 프로젝트.

커뮤니티에 관한 모든 것입니다. 프레임워크를 선택할 때 이것은 매우 중요한 포인트입니다. 문제가 발생했을 때 누가 도와줄까요? 당신과 나는 둘 다 그것이 어느 시점에서 일어날 것이라는 것을 알고 있습니다. 프레임워크가 의도하지 않은 작업을 수행해야 하거나 프레임워크가 액세스 권한을 부여하도록 설계되지 않은 작업을 수행해야 하는 지점에 도달하게 되므로 커뮤니티를 지원하는 것이 필수적입니다. 개발(특히 프리랜서)은 가상 세계에 빠져 있기 때문에 어려울 수 있습니다. 팀의 유일한 프론트엔드 웹 개발자라면 이를 찾을 수 있는 경험과 전문 지식이 있는 유일한 사람입니다. 해결책. 그러나 사용하는 프론트엔드 프레임워크가 확고한 지원을 받는다면 지구 반대편에도 같은 문제에 직면해 있고 당신을 도울 수 있는 누군가가 있을 것입니다.

기준은 아름답습니다. 자신의 코드의 오래된 부분을 볼 때 꽤 쉽게 탐색할 수 있다는 것을 알아차린 적이 있습니까? 아니면 적어도 다른 사람이 작성한 코드보다 더 쉽게? 당신은 특정한 방식으로 생각하고 사물의 이름을 지정하고 코드를 구성하는 자신만의 방법이 있습니다. 그것은 표준입니다. 그것이 우리 자신을 위한 것일지라도 우리 모두는 그것들을 따릅니다. 우리는 아침에 비슷한 음식을 먹고, 특정 시간에 일어나며, 매일 같은 장소에 열쇠를 두는 경향이 있습니다. 그리고 실제로 우리가 매일 일상을 바꾼다면 어떻게 해야 하는지 알아내는 오버헤드로 인해 삶이 ​​훨씬 더 힘들어질 것입니다. 평소와 다른 장소에 열쇠를 두어서 열쇠를 분실한 적이 있습니까? 표준은 삶을 더 쉽게 만듭니다. 팀이나 개발자 커뮤니티의 일원으로 일할 때 그들은 절대적으로 필요합니다.

프레임워크는 설치하는 순간부터 표준을 제공하여 특정 방식으로 생각하고 코딩하도록 안내합니다. 팀과 함께 표준을 만드는 데 시간을 할애할 필요가 없습니다. 프레임워크에서 작업이 수행되는 방식을 따를 수 있습니다. 이렇게 하면 함께 작업하기가 더 쉽습니다. 함수는 SPA에 경로를 추가하기 위해 빌드되고 프레임워크에서 모든 경로가 해당 이름을 가진 파일에 배치되기 때문에 함수가 특정 파일에 있어야 한다는 것을 알 때 함수를 찾는 것이 더 쉽습니다. 이 수준의 표준화가 있으면 다른 기술 수준을 가진 사람들이 함께 작업할 수 있습니다. 고급 코더는 작업이 왜 그런 식으로 수행되는지 알고 있지만 주니어 개발자도 표준 자체를 따를 수 있기 때문입니다.

프레임워크가 실패할 때

몇 년 전만 해도 "나는 프레임워크를 사용하지 않습니다. 프레임워크에서 실질적인 이점이 보이지 않습니다."와 같은 말을 하면 횃불과 갈퀴를 든 사람들이 방문하게 될 것입니다. 그러나 오늘날 점점 더 많은 사람들이 “왜 프레임워크를 사용해야 합니까? 나는 정말로 그것들이 필요합니까? 그것들 없이 코딩하기가 그렇게 어렵습니까?”

저는 확실히 그들 중 하나입니다. 저는 특정 프레임워크의 팬이 된 적이 없으며 평생 동안 프레임워크 없이 코딩을 해왔습니다. 문제에 대해 선택의 여지가 있다면 항상 "아니요, 감사합니다."라고 선택합니다. 저는 수년간 JavaScript로 개발했으며 그 전에는 ActionScript로 개발했습니다. 대부분의 사람들이 이미 죽었다고 생각했을 때 나는 Flash로 코딩하고 있었습니다. (알아, 나도 알아... 하지만 나는 많은 애니메이션을 하고 있었고 일반 HTML로 된 애니메이션은 어렵습니다.) 따라서 프레임워크 없이 코딩하는 것에 대해 생각해 본 적이 없는 많은 사람들 중 한 명이라면 고군분투.

"원 사이즈는 모두에게 적합합니다"는 거짓말입니다. 당신의 경력에서 성취한 모든 것을 할 수 있는 단일 소프트웨어를 작성하는 것을 상상할 수 있습니까? 이것이 웹 개발 프레임워크의 주요 문제 중 하나입니다. 귀하의 프로젝트에는 프레임워크의 범위를 확장하기 위해 라이브러리, 플러그인 또는 애드온을 추가하여 해결하는 경향이 있는 매우 구체적인 요구 사항이 있습니다. 어떤 프레임워크도 당신이 필요로 하는 것을 100% 제공하지 않으며, 어떤 프레임워크도 당신이 유용하다고 생각하는 것들로 100% 구성되지 않습니다.

사용하지 않는 코드가 너무 많으면 사이트의 로드 시간 지연이 발생할 수 있으며 이는 사용자가 추가될 때마다 더욱 중요해집니다. 또 다른 문제는 "모든 것이 적합하다"는 사고방식이 코드를 비효율적으로 만든다는 것입니다. 예를 들어 $('sku-product').html('SKU 909090'); , 이것은 결국 우리 모두가 document.getElementById('sku-product').innerHTML = 'SKU 909090'; .

한 줄에 이런 종류의 차이는 중요하지 않은 것처럼 보일 수 있지만 페이지의 특정 요소의 내용을 변경하는 것은 바로 React의 장점입니다. 이제 React는 DOM 표현을 만들고 렌더링하려는 항목의 차이점을 분석하는 과정을 거칩니다. 변경하고 싶은 콘텐츠를 처음부터 타겟으로 하는 것이 더 쉽지 않을까요?

당신이 걷고 있는 잡초의 엉킴은 가시를 자라고 있습니다. 필요한 라이브러리 버전이 사용 중인 프레임워크 버전과 잘 작동하지 않는다는 사실을 깨닫기 위해 프레임워크를 사용 중이고 라이브러리를 추가하려는 상황에 처한 적이 있습니까? 때로는 코드를 직접 작성하는 것보다 두 개의 코드를 함께 작동시키는 데 더 많은 노력이 필요합니다. 또한 사용하는 프레임워크와 라이브러리는 예상조차 할 수 없는 숨겨진 비호환성을 가질 수 있는 다른 프레임워크 및 라이브러리를 기반으로 하기 때문에 문제가 기하급수적으로 더 복잡해지고 다음과 같은 경우 관리할 수 없는 지점에 도달할 수 있습니다. 프로젝트가 계속 성장하기를 바랍니다.

Joneses를 따라 잡는 것이 중요합니다. AngularJS에서 프로젝트를 진행하면서 Angular 4가 출시될 때까지 나타나지 않은 것이 필요하다는 사실을 알게 된 적이 있습니까? Angular 5가 출시되었다는 사실, 알고 계셨나요? 이것은 또 다른 큰 문제입니다. 단일 프론트 엔드 프레임워크를 고수하더라도 새로운 주요 릴리스가 발생하면 상황이 너무 많이 변경되어 열심히 만든 코드가 새 버전에서도 실행되지 않을 수 있습니다. 이로 인해 많은 파일에서 수행해야 하는 성가신 작은 변경에서부터 코드의 완전한 재작성에 이르기까지 무엇이든 될 수 있습니다.

프레임워크의 최신 빌드를 따라가는 것은 어려운 일이지만 동일한 메모에서 다른 프레임워크는 업데이트가 완전히 중지되고 나머지 기술을 따라갈 수 없을 때 어려움을 겪습니다. 2010년에 AngularJS와 Backbone이 처음으로 출시되었습니다. 오늘날 Angular는 다섯 번째 주요 버전이며 Backbone은 완전히 주목을 받지 못했습니다. 7년은 긴 시간인 것 같습니다. 웹사이트를 구축한다면 미학과 기능면에서 완전히 달라졌을 것입니다. 앱을 구축하는 경우 잘못된 프레임워크에 베팅하면 나중에 다시 작성해야 하는 힘든 상황과 비용이 많이 드는 상황에 놓이게 될 수 있습니다.

망치만 있으면 모든 것이 못처럼 보입니다. 웹 개발 프레임워크를 자주 사용해 왔다면 단일 코드베이스가 주변적으로만 관련되어 있더라도 미래에 사용할 코드의 모양을 정의하는 경우가 있을 수 있습니다. YouTube와 같은 플랫폼을 구축하고 Framework X를 사용하려는 경우 프레임워크에 내장되어 있습니다.

프레임워크에는 의견이 있으며 강력합니다. 예를 들어 React는 특정 방식으로 JSX를 사용하도록 강제합니다. 어디에서나 그런 식으로 사용되는 코드를 볼 수 있습니다. 대안이 있습니까? 네. 하지만 누가 그것을 사용합니까? 이것이 항상 나쁜 것은 아니지만 복잡한 애니메이션을 수행해야 하는 경우 React 전체가 아닌 애니메이션을 위한 프레임워크만 필요할 수 있습니다. 나는 사람들이 페이지에 jQuery를 추가하여 요소에 노드를 추가하는 것과 같은 미친 짓을 하는 것을 document.getElementById('id_of_node').appendChild(node); .

Eval은 사악하지만 .innerHTML 은 마키아벨리안이다

나는 이것이 더 많은 사람들이 프레임워크 없이 코딩하지 않는 이유 중 하나라고 생각하기 때문에 이 점을 별도로 살펴보는 시간을 갖고 싶습니다. DOM에 무언가를 추가하려고 할 때 대부분의 코드가 작동하는 방식을 보면 .innerHTML 속성에 의해 삽입된 HTML 무리를 찾을 수 있습니다. 우리 모두는 eval 이 자바스크립트 코드를 실행하는 데 좋지 않다는 데 동의하는 것 같지만 저는 여기에서 .innerHTML 을 주목하고 싶습니다. HTML 코드를 일반 문자열로 삽입하면 생성한 노드에 대한 참조가 손실됩니다. getElementsByClassName 을 사용하거나 id 를 할당하여 다시 가져올 수 있지만 이것은 실용적이지 않습니다. 노드 중 하나의 값을 변경하려고 할 때 전체 HTML을 다시 렌더링해야 하는 자신을 발견하게 될 것입니다.

코딩을 시작할 때 좋습니다. 많은 경험 없이도 간단한 것을 많이 만들 수 있습니다. 문제는 앱에 더 가까운 경향이 있는 최신 웹사이트의 복잡성으로 인해 발생합니다. 즉, 노드의 값을 지속적으로 변경해야 합니다. 이는 전체 구조를 다시 연결하여 수행하는 경우 고비용 작업입니다. .innerHTML 을 통해 React는 shadow DOM을 통해 이 문제를 효율적으로 해결하고 Angular는 페이지에 표시된 값을 수정하는 쉬운 방법으로 바인딩을 사용하여 이 문제를 해결합니다. 그러나 생성한 노드를 추적하고 재사용하거나 업데이트할 노드를 변수에 저장하면 상당히 쉽게 해결할 수도 있습니다. 일반적으로 .innerHTML 을 멀리해야 하는 다른 이유도 있습니다.

프레임워크 없는 코딩에 대한 가장 큰 오해

시간은 돈이다. 예, 이전에서 이 개념을 다시 가져오고 있습니다. 많은 사람들은 인기 있는 웹 프레임워크 사용을 중단하면 <marquee> 가 모두가 가장 좋아하는 태그였고 Geocities 사이트에서 회전하는 GIF가 힙하고 날카롭던 90년대 인터넷으로 즉시 넘어갈 것이라고 생각합니다. Alta Vista가 최고였습니다. 에 대한 웹 검색 및 적중 카운터는 유비쿼터스했습니다.

웹 프레임워크를 사용하면 첫 번째 코드 줄에서 많은 시간을 절약할 수 있지만 어느 시점에서 이득이 손실로 바뀝니다. 프레임워크가 빌드되지 않은 작업을 수행하도록 만드는 방법, 라이브러리를 통합하고 프레임워크와 잘 작동하도록 하는 방법, 프레임워크 표준을 따르는 동안 빌드한 코드가 제대로 작동하지 않는다는 것을 찾는 데 시간을 할애합니다. 전혀 작동하지 않고 이제 다시 작성해야 합니다. 프레임워크 없이 작업을 수행하면 시작은 더디지만 꾸준히 진행됩니다. 결국, 쉬운 부분을 원하는 위치에 관한 모든 것입니다. 전체 시간에는 큰 차이가 없습니다.

내 코드는 만리장성보다 길 것입니다. 프레임워크 없이 글을 쓰는 것은 스트리밍 서비스에 가입하는 대신 영화를 사는 것과 같습니다. 보고 싶은 수백 편의 영화에 즉시 액세스할 수는 없지만 스토어에서 다운로드할 생각조차 하지 않은 수천 편의 다른 영화에 돈을 쓸 필요도 없습니다. 필요한 것만 쓰시면 됩니다.

중개인이 유용합니까? 확신하는. 그러나 일반적으로 필요 하지 않습니다. 프레임워크의 요구 사항에 적응할 필요가 없기 때문에 작성하는 모든 코드 줄에는 더 많은 의미가 있습니다. DOM 요소를 생성하는 방법은 한 줄의 JSX의 코드. 그러나 jQuery나 React와 같은 라이브러리를 사용하여 코드를 비교하면 바닐라 JS의 길이가 꽤 비슷할 수 있습니다. 더 길 때도 ​​있지만 더 짧을 때도 있습니다.

바퀴를 재발명할 필요가 없습니다. 어디에서나 컴퓨터 공학 교수들의 만트라. 그리고 사실입니다. 프레임워크를 특별히 의미할 필요는 없습니다. 예를 들어 데이터를 로드하거나 저장하기 위해 Ajax 요청을 보내는 것은 거의 모든 웹 앱의 요구 사항이지만 프레임워크가 없다고 해서 매번 코드를 새로 작성해야 하는 것은 아닙니다. 자신만의 라이브러리나 코드베이스를 만들거나 다른 사람의 코드를 추출할 수 있습니다. 작을수록 필요에 따라 수정하거나 조정하기가 더 쉽기 때문에 프로젝트에 특정한 것이 필요할 때 편리합니다. 타사 라이브러리나 프레임워크에 포함될 수 있는 수많은 파일을 탐색하는 것보다 100-200줄의 코드를 수정하는 것이 더 쉽습니다.

소규모 프로젝트에서만 작동합니다. 이것은 매우 흔한 신화이지만 전혀 사실이 아닙니다. 현재 저는 Google 드라이브와 같은 모듈을 포함하여 한 곳에서 온라인으로 회사의 모든 측면을 관리하기 위해 전체 시스템을 작업하고 있습니다. 프레임워크가 있든 없든 저는 매우 유사한 단계를 거치고 매우 유사한 문제에 직면합니다. 그 차이는 미미합니다. 그러나 프레임워크가 없으면 전체 코드가 더 작아지고 더 쉽게 관리할 수 있습니다.

나는 증거를 원한다

괜찮아. 이론에 대한 이야기는 그만하고 실제 사례로 넘어가겠습니다. 며칠 전, 나는 상점의 로고가 있는 브랜드 목록을 보여줘야 했습니다. 초기 코드는 jQuery를 사용했지만, Mozilla에서 로드할 때 아직 로고가 업로드되지 않은 브랜드에 대해 깨진 이미지 아이콘이 표시되는 문제가 있었습니다. X 회사가 아직 작업을 끝내지 않았지만 기능을 활성화하려면 기능이 필요했기 때문에 상점이 미완성인 것처럼 보일 수 없습니다.

다음 코드는 .innerHTML 에 해당하는 jQuery를 사용합니다.

 var list_brand_names = ['amazon', 'apple', 'nokia']; var img_out = ''; for (i=0;i<list_brand_names.length;i++) { var brandName = list_brand_names[i].toLowerCase(); img_out += "<a href='/pages/" + brandName + "'><img src='images/" + brandName + "' /></a>"; } jQuery("#brand-images").html(img_out);

jQuery의 장단점에 대해 너무 깊이 들어가지 않으면 여기서 문제는 우리가 만든 이미지에 대한 참조가 없다는 것입니다. 코드 변경을 포함하지 않는 솔루션이 있지만 이 기회를 사용하여 라이브러리 없이 수행할 수 있는 방법을 살펴보겠습니다.

 var brands = ['amazon', 'apple', 'nokia']; var brand_images = document.getElementById("brand-images"); for (var iBrand = 0; iBrand < brands.length; iBrand++) { var link = document.createElement('a'); link.setAttribute('href', '/pages/' + brands[iBrand]); link.style.display = 'none'; brand_images.appendChild(link); var image = new Image(); image.src = "images/" + brands[iBrand] + "png"; image.onload = function(){ this.parentNode.style.display = ''; } link.appendChild(image); }

원래 jQuery 코드는 6줄이었지만 바닐라 JS 솔루션은 12줄이었습니다. 문제를 해결하려면 로드될 때까지 각 이미지를 숨기면 코딩하는 데 두 배의 시간이 걸립니다. 그럼 대안을 살펴보겠습니다. jQuery에서도 해결할 수 있습니까? 확인 해봐:

 img_out += "<a href='/pages/" + brandName + "'><img src='images/" + brandName + "' onload="showImage(this)"/></a>"; function showImage(image){ image.parentNode.style.display = ""; }

몇 줄의 코드를 추가하면 이제 jQuery와 바닐라 사이에 세 줄만 차이가 나지만 jQuery에서는 img_out 줄이 매우 복잡해져서 일시 중지해야 하는 지점까지 빠르게 성장하고 있음을 알 수 있습니다. 당신이하고있는 일에 대해 신중하게 생각하십시오. 노드 기능을 사용하여 속성, 기능 등을 추가하여 DOM을 직접 코딩하는 것은 더 길 수 있지만 각 행은 더 명확하고 정확한 의미를 가지고 있어 향후 읽고 유지 관리하기가 더 쉽습니다.

React를 살펴보겠습니다.

 function BrandLink(props) { var url = "images/" + props.brand + ".png"; return (<a href="{props.brand}"><img src={url}/></a>); } class Brands extends React.Component { constructor() { super(); this.state = {brands: ['amazon', 'apple', 'nokia']}; } render() { const links = this.state.brands.map((step, move) => { return (<BrandLink brand={step} key={step}/>); }); return (<div className="brands">{links}</div>); } } ReactDOM.render(<Brands />, document.getElementById("root"));

이 버전은 분명히 차선책입니다. 코드는 바닐라보다 짧지 않으며 내부 이미지가 로드될 때까지 문제를 해결하고 링크를 숨길 수 있는 단계에 이르지 못했습니다.

모든 예에서 결과는 다를 것입니다. 때로는 jQuery가 더 짧을 것입니다. 때로는 React가 이길 것입니다. 바닐라 JS가 둘 다보다 짧을 수 있는 경우가 있습니다. 어쨌든 여기의 목표는 하나가 본질적으로 다른 것보다 우수하다는 것을 증명하는 것이 아니라 코드 길이에 있어 기본 JS를 사용하는 것과 프레임워크를 사용하는 것 사이에 큰 차이가 없다는 것을 보여주기 위함입니다.

결론

실생활의 모든 문제와 마찬가지로 검은색이나 흰색은 없습니다. 웹 개발 프레임워크 없이 코딩하는 것이 일부 프로젝트에는 최상의 솔루션이 될 수 있고 다른 프로젝트에는 악몽이 될 수 있습니다. 모든 도구와 마찬가지로 핵심은 사용 방법뿐만 아니라 사용 시기와 사용의 장단점을 배우는 것입니다. 순수 JavaScript로 코딩하는 것은 모든 프레임워크와 같습니다. 사용하는 데 익숙해지기까지는 시간이 걸립니다.

그러나 적어도 저에게 있어 가장 중요한 차이점은 프레임워크는 왔다가 사라지는 것입니다. 프레임워크가 오랫동안 인기가 있더라도 버전마다 크게 바뀔 수 있습니다. 순수 JavaScript는 완전히 관련성이 없어지고 다른 언어가 등장할 때까지 훨씬 더 오랫동안 옵션이 될 것입니다. 그렇다 하더라도 주어진 프레임워크에서 다른 언어로 직접 마이그레이션할 수 있는 것보다 한 언어에서 다른 언어로 직접 마이그레이션할 수 있는 개념과 전략이 더 많을 것입니다. 단일 프로젝트와 관련하여 시간과 노력이 거의 동일하다는 점, 지식 감가상각의 감소 및 다음 과제에 대해 배울 수 있는 교훈은 고려해야 할 매우 중요한 요소입니다.