Mina Markham과 함께하는 스매싱 팟캐스트 에피소드 18: React를 어떻게 배울 수 있나요?

이번 Smashing Podcast 에피소드에서는 React 학습에 대해 이야기하고 있습니다. React는 어떤 작업을 하며 숙련된 개발자는 어떻게 시작할 수 있나요? 알아보기 위해 Mina Markham과 이야기했습니다.

메모 표시

• 트위터의 미나 마컴
• 미나 개인 홈페이지

주간 업데이트

• Bryan Robinson의 FaunaDB를 사용하여 정적 사이트에서 최종 사용자 JAMstack 앱으로
• 귀하의 웹사이트가 방문자에게 스트레스를 주고 있습니까? 수잔나 스카카
• Mirage JS 심층 분석: Kelvin Omereshone의 타이밍, 응답 및 통과(3부) 이해
• Adeneye David Abiodun의 React로 안면 인식 웹 애플리케이션 구축
• Timi Omoyeni의 Vue I18n 플러그인을 사용한 Vue의 국제화

성적 증명서

Drew McLellan: 그녀는 프론트엔드 건축가이자 회의 연사이자 주최자이며 디자인 시스템을 사랑하는 사람입니다. Hillary Clinton의 Hillary for America 대선 캠페인을 위한 Pantsuit 특허 라이브러리에 대한 그녀의 작업은 업계 내 디자인 시스템의 분수령이 되었으며 Wired, Fast Company 및 Communication Arts와 같은 출판물에 실렸습니다. 우리 중 많은 사람들과 마찬가지로 그녀는 현재 Slack의 수석 엔지니어로 생활용 코드를 작성합니다. 그래서 우리는 그녀가 재능 있고 미래 지향적인 개발자라는 것을 압니다. 하지만 그녀가 한때 Patrick Swayze로 오인되었다는 사실을 알고 계셨습니까? 내 스매싱 친구, Mina Markham을 환영하십시오. 안녕 미나. 잘 지내고 있나요?

Mina Markham: 굉장합니다.

드류: 반갑습니다. 이제 때때로 Smashing Podcast에서 우리는 사람들에게 가장 잘 알려진 주제에 대해 이야기합니다. 그리고 가끔은 약간 관련이 있는 것에 대해 이야기하는 것이 재미있습니다. 이제 패턴 라이브러리, 디자인 시스템, 해당 특정 영역에서 수행한 놀라운 작업에 대해 하루 종일 이야기할 수 있으며 이벤트와 같은 이벤트에 대해 이야기할 수 있습니다. 그 외에 아트 디렉션 같은 것들. 그리고 우리는 소들이 집에 돌아올 때까지 CSS에 대해 분명히 이야기할 수 있습니다. 하지만 당신은 며칠 전에 트윗을 했고 우리 둘 다 경험이 풍부한 프론트엔드 엔지니어이고 최근에 React로 작업하기 시작했다는 점에서 우리가 실제로 같은 배에 있다는 것을 깨달았습니다. 그래서 React 자체를 다루기 전에 이 시점까지 어디까지 오셨습니까? JavaScript 개발을 위해 다른 라이브러리 및 프레임워크를 사용하고 있었습니까?

Mina: 아니요, 사실 저는 한동안 주로 바닐라 JavaScript를 해왔습니다. 그리고 그 이전에는 물론 JavaScript에 입문했습니다. 다시 말하겠습니다. 저는 jQuery를 사용하여 Java 스크립트 작업을 시작했습니다. 왜냐하면 그것이 제게 가장 합리적이었기 때문입니다. 무슨 일이 일어나고 있는지 파악하기 위해 내가 구문 분석하기가 매우 쉬운 것이었습니다. 그런 다음 거기에서 나는 그냥 바닐라, 일반 JavaScript, ESX를 수행하는 것으로 되돌아갔고 프레임워크 전쟁에 너무 많이 참여하지 않았습니다. 좋아하는 사람이 없었던 것처럼 없었습니다. 나는 싸움에 개가 없었다. 나는 "당신을 위해, React, 무엇이든. 난 별로 상관없어.” 하지만 시대는 변합니다.

Drew: 그리고 바닐라 자바스크립트로 작업하는 이런 방식에서요. 왜냐하면 나 자신도 그 일을 많이 했기 때문입니다. 다양한 프레임워크로 작업했습니다. 나는 예전에 jQuery로 많은 일을 했다. 나는 YUI, Yahoo 사용자 인터페이스 라이브러리와 함께 일했습니다. React의 아키텍처와 같은 것이 해결하려고 하는 많은 문제점을 느꼈습니까?

미나: 그런 적이 없는 것 같아요. 저는 대부분의 경력을 웹사이트와 웹 앱 등을 만드는 데 보냈습니다. 그래서 내가 한 모든 것은 어느 정도까지는 꽤 정적이었습니다. 그래서 저는 국가 관리와 같은 일을 다룰 필요가 없었습니다. 그래서 React가 해결하려고 하는 고충점은 제가 한 작업에 실제로 적용한 적이 없었습니다.

Drew: 일반적으로 말해서 지금까지 React로 진행한 프로젝트의 성격은 어떤가요?

미나: 사실 제가 현재 진행하고 있는 프로젝트는 단 하나의 프로젝트였습니다. 공기업과 좋은 것들 때문에 너무 많은 세부 사항을 알려드릴 수는 없습니다.

드류: 물론이죠.

Mina: 하지만 본질적으로 내가 하려고 하는 것은 React를 사용하려는 것입니다. 사람들이 특정 상태에 데이터를 입력하고 저장한 다음 조작할 수 있어야 하는 매우 상호작용적인 제품입니다. 해당 데이터로 다른 것을 생성합니다. 그리고 그것은 그 시점에서 단순한 DOM 조작이 아니라는 것입니다. 실제로 훨씬 더 복잡한 프런트 엔드 데이터 관리 및 해당 데이터 상태 관리입니다. 따라서 그 문제를 해결하기 위해 일종의 라이브러리를 사용하는 것 외에는 다른 대안이 없었습니다. 평범한 JavaScript로는 지나칠 수 없다는 것을 알고 있었습니다. 나는 아마도 서버 측에서 뭔가를 처리할 수도 있다고 생각했지만, 다시 말하지만, 내가 작업하는 작업의 매우 상호 작용적인 특성으로 인해 클라이언트에 있어야 합니다. 그래서 우리는 이미 다양한 다른 것들을 위해 Slack에서 React를 사용하고 있습니다. 그래서 저는 "좋아, 우리는 계속해서 나머지 모회사가 사용하고 있는 것과 동일한 것을 채택하고 거기에서 떠나야 한다"고 생각했습니다.

Drew: 사람들이 React를 선택할 때 제가 항상 고민하는 것 중 하나는 작업을 수행하는 데 필요한 도구 체인을 파악하는 것입니다. Webpack은 이 공간의 명백한 코끼리입니다. 당신은 도구 체인의 많은 구성을 수행해야 했거나 나처럼 동료가 당신을 위해 그것을 해준다면?

Mina: 아, 저는 Slack 데이터의 인프라 팀을 사랑합니다. Slack의 프론트엔드 인프라 팀이 이 모든 것을 처리했습니다. 나는 그것에 대해 생각할 필요가 없었다. 그것은 훌륭했다. 예전에 React를 배우려고 했기 때문입니다. 일반적으로 내가 가장 잘 배우는 방법은 실제로 작업하고 구현하는 것입니다. 그리고 우리는 React를 사용하여 2016년에 Hillaryclinton.com을 많이 구축했습니다. 따라서 내가 그것을 사용하는 사람들과 일한 적이 없는 것은 아닙니다. 단지 내 일에 직접 관여할 필요가 없었을 뿐입니다. 그러나 그 코드 기반은 매우 복잡하고 매우 정교했으며 React와 Redux 및 그 모든 것이 어떻게 작동하는지 아직 알지 못한다면 거기에서 무엇이든 배우려고 시도하는 진입 장벽이 너무 많습니다. 하지 않았다. 그래서 저는 그 환경에서 공부하는데 별로 효과가 없었습니다.

Mina: 운 좋게도 여기에는 복잡한 부분을 조금 더 좋아하는 사람들이 있습니다. Webpack 구성에 대해 전혀 걱정할 필요가 없습니다. 설정이 완료되었습니다. 그것은 시도되고 테스트되었으며 사용할 준비가되었습니다. 나는 React 외에 Redux도 사용하는 비슷한 배에 있습니다. 두 가지 다른 점을 깨닫지 못했습니다. 어느 부분이 어떤 부분을 담당했는지 알 수 없었습니다. 그런 코드 베이스에 빠지면 그것들이 모두 같은 것이라는 것을 깨닫지 못했기 때문에 약간 혼란스러웠습니다. 저는 노련한 React 개발자들이 저에게 이렇게 말했습니다. "오, 우리도 Redux를 사용하고 있습니다. 그래서 처음부터 시작한다면 React가 무엇을 할 수 있는지 실제로 배우기가 조금 더 어렵습니다." 그리고 나는 그들이 말하는 내용을 몰랐기 때문에 그것이 무엇을 의미하는지 전혀 알지 못했습니다.

Mina: 원래 질문에 답하자면, React를 배우는 것이 아니라 진입 장벽이 조금 더 있습니다. React와 Redux 스토어 사용법도 배워야 합니다. 그래서 그 두 가지가 동시에 조금 많을 수 있습니다.

Drew: 예, Redux를 사용하는 첫 번째 React 프로젝트와 정확히 동일한 것이 기존 코드 기반에 들어오는 것을 발견했습니다. 그리고 제 생각에는 이러한 종류의 기술이 젊었을 때의 특성과 마찬가지로 매우 빠르게 반복되며 한 시점에서 모범 사례가 6개월 후로 옮겨갔고 일을 하는 다른 방식이 있다고 생각합니다. 그리고 몇 년에 걸친 코드 기반이 있을 때 때때로 거기에 다른 스타일을 구현하는 경우가 있습니다. 항상 동기화를 유지하지는 않습니다. 그리고 물론, 튜토리얼이나 배울 내용을 따르거나 책을 읽고 리소스를 사용하는 경우 작업 방법의 가장 현대적인 버전이 될 것입니다. 그리고 그것이 기존의 성숙한 제품을 볼 때 보이는 것과 반드시 ​​일치하는 것은 아닙니다. 경험한 적이 있습니까? 아니면 코드 기반을 최신 상태로 유지할 수 있었습니까?

미나: 그건 제가 확실히 겪었던 일인 것 같아요. React를 혼자 배우려고 할 때, 다양한 튜토리얼과 그런 것들을 보았습니다. 그리고 저는 알아차렸거나 적어도 저와 함께 일해 온 사람들이 저에게 우리가 하는 일부 또는 일종의 안티패턴 또는 현재 일이 제대로 작동하지 않는다고 말했습니다. 왜냐하면 이 코드 기반이 약간, 잘 우리를 상대적으로 성숙하지만 몇 년 전입니다. 그리고 몇 년 전에 작성된 것이기 때문에 현재 우리가 하고 있는 방식보다 일을 더 쉽게 할 수 있는 몇 가지 방법이 있습니다. 따라서 현재 시간을 따라잡고 최선의 방법으로 일을 하고 싶은지 확인하기 위해 노력하는 약간의 디딜 방아이지만, 또한 나는 물건을 가지고 놀고 싶기 때문에 확립된 코드 기반을 깨고 싶지 않습니다.

Drew: 분명히, 저와 같은 사람들이 React를 사용하는 것 중 하나는 JSX에서 이 모든 것이 약간 거북하게 느껴질 수 있습니다. 프로젝트에서 JSX를 사용하고 있습니까?

미나: 우리는. JSX를 사용하고 있습니다.

드류: 그걸로 화해했습니까?

Mina: 나는 그 파일 중 하나를 열 때마다 내 작은 조각이 죽는 것처럼 떨어졌습니다. 내 HTML을 JavaScript 파일에 넣는 것은 여전히 ​​신성 모독으로 느껴집니다. 그것이 일종의 혁신적이고 요점이라는 것을 알고 있지만, JavaScript 파일에 마크업을 작성하고 있다는 사실이 저에게는 기분이 좋습니다. 나는 그것으로 평화를 이뤘지만 그것을 할 때마다 나는 그냥 "..." 이별 문제, 그것은 일입니다. 돌려주세요.

드류: 타당한 지적이군요, 그렇죠? JavaScript로 더 진지하게 작업하기 시작했을 때의 제 배경은 아마도 제가 Yahoo로 돌아갔을 때였을 것입니다. 서버에서 렌더링된 HTML 페이지의 모델에 관한 것이 많았고 그 다음에는 JavaScript를 맨 위에 레이어링하여 향상되었습니다. 인터페이스. 그리고 인터페이스에 있는 어떤 상태를 변경해야 하는 경우 코드는 업데이트해야 하는 인터페이스의 모든 부분에 대해 알아야 합니다. 주변의 다른 모든 코드에 대해 알아야 합니다. 그리고 그것은 패턴 라이브러리나 디자인 시스템으로 작업할 때 취하는 구성 요소화된 접근 방식에 적합하지 않다고 생각합니다. 이는 특정 전문 분야에 더 가깝습니다. 제 생각에는 React가 그 접근 방식에 더 적합하지 않습니까?

Mina: 특히 매우 특정한 CSS를 하나의 JSX 또는 하나의 React 구성 요소에 연결할 수 있다는 점에서 그렇습니다. 그렇게 하면 라이브러리에 필요한 것만 분리하거나 나머지는 남겨두는 것이 훨씬 쉬워집니다. 반면에 하나의 큰 스타일 CSS 파일 또는 이와 유사한 것으로 더 모놀리식한 작업을 시도하는 패턴 라이브러리 또는 디자인 시스템 , 그것은 매우 어렵게 만듭니다. 당신은 그것을 전부 또는 전혀 취해야합니다. 그래서 저는 프리젠테이션 레이어와 콘텐츠 레이어를 인터랙티브 레이어에서 진정으로 분리할 수 있는 방법이 있었으면 하는 바람에도 불구하고 React를 통해 보다 개별화되고 구성 요소화된 개발 방식을 수행할 수 있다는 점에 감사합니다. 하지만 그건 내가 그런 의미에서 약간 올드 스쿨이 된 것일 수도 있습니다.

드류: 확실히 고통이 느껴집니다. 제 생각이 틀렸다면 와서 정정해 주십시오. 제 이해는 기술, CSS, JavaScript, HTML을 분리하는 것이 아니라 기능을 분리하는 것입니다. 그래서 하나의 구성 요소인 모든 것이 함께 존재합니다.

미나: 네.

Drew: ... 해당 구성 요소가 더 이상 필요하지 않은 경우 유용할 것 같습니다. 삭제하기만 하면 사라지며 앱 주변에 발자국을 남기지 않습니다. 하지만 CSS가 항상 그런 것은 아닙니다. React에서 CSS로 작업하는 방법은 무엇입니까? styled-component 또는 이와 유사한 것을 본 적이 있습니까?

미나: 아니요. 나는 styled-components에 대해 들어 보았지만 완전히 정직하기 위해 완전히 조사한 적이 없습니다. 따라서 React로 CSS를 작업하는 방법은 Less를 작성하고 해당 구성 요소로 가져오는 개별 구성 요소에 Less 파일을 첨부하기만 하면 됩니다. 그런 다음 Webpack을 통해 결합되어 클라이언트에 제공됩니다.

Drew: BEM과 같은 시스템을 사용하여 네임스페이스를 전환하고 있습니까?

미나: 네. 우리는 BEM을 네임스페이싱에 사용하고 있지만, BEM에 대한 준수는 누가 무엇을 작성하는지에 따라 다릅니다. 그러나 우리는 각 개별 클래스와 구성 요소의 목적이 무엇인지 조금 더 명확하게 하기 위해 BEM 네임스페이스 패턴을 사용하려고 합니다.

Drew: 그리고 그것이 당신을 위해 성공적으로 작동하는 것 같습니까?

미나: 그런 것 같아요. 때로는 이름을 지정하는 방법을 모르는 것과 같은 오래된 문제가 있습니다. 시간이 지나면 일상적인 일은 항상 주인에게 어려운 일이었고 앞으로도 계속 될 것입니다. 그래서 내가 가진 유일한 문제는 때때로 특정 구성 요소를 무엇이라고 불러야할지 모르겠다는 것입니다.

드류: 확실히. 그것은 끊임없는 싸움입니다. 그렇지 않습니까? 이름을 어떻게 말해야합니까?

미나: 네.

Drew: 저는 항상 새로운 기능이나 그와 비슷한 작업을 할 때 끝납니다. 구성 요소와 모든 클래스 및 현재 기능에 있는 모든 이름을 지정합니다. 그리고 나서 출시할 즈음에는 다른 이름으로 바뀌었습니다. 따라서 코드에 이전 이름에 대한 참조가 있고 인터페이스에 새 이름이 있습니다. 그리고 …

Mina: 저는 항상 기능이나 목적에 따라 이름을 지정하려고 합니다. 이 구성 요소의 실제 목적이 변경될 가능성이 적기 때문입니다. 언급하는 것을 잊었지만 BEM을 사용하는 것 외에도 익숙하다면 BEMIT를 사용하는 것 같습니다. 그것은 기본적으로 ITCSS와 BEM이며 둘 다 Harry Roberts에 의해 만들어졌습니다. 그래서 헝가리 표기법을 사용하여 구성 요소인지, 레이아웃 개체인지, 여러 구성 요소로 구성된 더 큰 패턴인지를 나타냅니다. 그런 다음 거기에서 BEM 규칙을 사용하여 블록 요소와 같은 것을 나타냅니다.

Drew: 그리고 코드 기반에서 구성 요소와 항목을 많이 리팩토링하고 삭제해야 했고 CSS가 뒤처지는 문제를 처리해야 했습니까?

미나: 네. 따라서 slack.com을 유지 관리하는 제 작업의 React가 아닌 부분은 CSS용으로 컴파일되는 Less 파일의 묶음에 불과합니다. 그리고 거기에 많은 좀비 코드가 있음을 보장합니다. 왜냐하면 제가 거기에 있었던 시간 동안 우리는 위의 것들을 많이 반복했기 때문입니다. 그리고 페이지나 무언가를 다시 디자인할 때와 비교하여 다시 돌아가서 정리할 시간이 항상 있는 것은 아닙니다. 그래서 감사 기한이 지났습니다. 그렇게 말하겠습니다.

Drew: 이것은 우리가 CSS에 접근하는 방법을 살펴보고 있는 React 프로젝트에서 살펴봤던 것입니다. 현재 우리는 앱 전체에 대한 몇 개의 큰 글로벌 CSS 파일을 가지고 있으며, 우리의 번들 크기가 점점 커지고, 커지고, 상황이 나아지더라도 결코 더 작아지지 않는 상황이 발생합니다. 제거됨. 그래서 우리는 styled-components와 같은 것들을 살펴보았고 Tailwind 역시 우리가 정말로 진지하게 고려하고 있는 또 다른 옵션입니다. 테일윈드 많이 보셨나요?

미나: 많이 안 봤어요. 나는 그것에 대해 궁금했지만 다시 말하지만, 그것이 내가 우리 코드 기반으로 가져오려고 하는 것인지 실제로 알아보기 위해 파고들 시간이 없었습니다.

Drew: 나는 사실 꽤 놀랐습니다. 왜냐하면 저는 당신처럼 이런 일을 하는 방법에 대해 약간 구식이기 때문입니다. 나는 좋은 관심사의 분리를 좋아한다. 그리고 저는 CSS로 CSS를 작성하는 것을 좋아합니다. 물론 Tailwind를 사용한 접근 방식은 이러한 모든 클래스 이름을 가지고 있다는 것입니다. 그리고 더럽게 느껴진다면.

미나: 네.

Drew: 그리고 저는 팀 내에서 자원 봉사를 했습니다. 우리 각자는 기술을 사용하여 우리 문제에 적합한지 조사했습니다. 그리고 저는 제가 Tailwind를 싫어할 것이라고 확신했기 때문에 Tailwind를 보기로 자원했습니다.

미나: 아니요.

Drew: 하지만 실제로 많은 문제를 해결한다고 생각합니다. 나는 꽤 감동했다.

미나: 네. 과거에는 Tailwind가 하는 것처럼 속성별로 클래스를 수행하지 않고 특정 구성 요소에 필요한 모든 스타일을 하나의 클래스로 구성하는 것을 훨씬 선호했기 때문에 비슷한 방식으로 생각하게 되었습니다. 또는 이와 유사한 언어. 비슷한 이유로 "음, 지금은 인라인 CSS를 실행하고 있습니다. 내가 왜 이러지?” 그러나 Slack 디자인 시스템 내부에서 점점 더 개발하면서 패턴으로 약간의 여백을 추가하는 것과 같은 작업을 수행하는 유틸리티 클래스라고 부르는 많은 것을 만들었습니다. 나는 점점 더 많은 부분을 구성 요소 클래스와 함께 사용하고 있음을 알게 되었습니다. 그래서 저는 "좋아, 아마도 한 번에 하나의 선언으로 CSS를 수행하기 위해 이 전체를 다시 방문해야 할 것"이라고 생각합니다. 내가 그렇게 멀리 갈지는 모르겠지만 확실히 고려할 가치가 있습니다.

Drew: 컴퓨팅은 씬 클라이언트와 팻 클라이언트 솔루션 간의 추세 측면에서 플립플롭(flip flop)인 것 같습니다. 우리는 터미널이 있는 메인프레임으로 시작했고, 그 다음에는 Windows와 사무실이 있는 PC 시대, 그리고 이러한 모든 종류의 큰 응용 프로그램이 있었습니다. 그리고 그것들은 모두 정말 느려지고 있었고 웹이 등장한 것보다 훨씬 더 느려졌습니다. 그것은 단지 브라우저일 뿐이었고 모든 작업은 서버에서 수행되고 있었습니다. 그리고 다시 모든 것이 빠르고 신속했습니다. 이제 우리는 모든 작업을 JavaScript로 수행하는 모든 작업을 브라우저에 다시 넣는 것으로 돌아갔습니다. React 및 JAMstack 접근 방식과 같은 일종의 뚱뚱한 클라이언트로 돌아갑니다. 나는 때때로 우리가 브라우저에 너무 많은 것을 요구하고 있다는 것을 걱정합니다. 실수인가요? React에서 이 모든 작업을 수행하기 위해 브라우저에 너무 많은 것을 요구하고 있습니까?

Mina: 다시 한 번 말씀드리지만 제 경험은 대부분 정적인 웹사이트에 포함되어 있습니다. 저는 제품 개발을 많이 하지 않습니다. 그래서 아마도 그 영역에서는 이것이 더 합리적일 것입니다. 하지만 내 관점에서 우리는 버터 나이프가 필요할 때 도끼를 사용하는 경우가 많다고 생각합니다. 왜 우리가 이 모든 것을 브라우저에 넣어야 하는지, 클라이언트에게 너무 많은 작업과 압박을 가해야 하는지 모르겠습니다. 훨씬 간단하게 할 수 있을 것 같습니다. 항상 React를 사용하는 것을 약간 주저하게 만드는 것 중 하나, 또는 주저했다고 말하지만, 그것이 나를 본능적으로 화나게 만들고 적극적으로 반대했을 때 의미하는 바는 웹사이트에 가서 말 그대로 아무 것도 렌더링되지 않을 때였습니다. "정말요? 하나의 기능이 고장나서 전체 페이지가 깨졌습니까?”

Mina: 많은 경우 그것이 전부 아니면 전무(all or nothing) 방식이라는 것이 저를 짜증나게 했습니다. 과거 AEA와 과거 다른 장소에서 제가 했던 강연 중 하나는 점진적인 향상을 포함하는 방법과 귀하의 개발뿐만 아니라 아트 디렉션 및 사이트 디자인에 대한 이야기였습니다. 그리고 점진적인 향상이나 어떤 종류의 우아한 저하도 하지 않은 웹사이트의 예를 구체적으로 지적하겠습니다. 브라우저에서 JavaScript를 실행하거나 아무것도 얻지 못하는 것과 같았습니다. 그리고 1990년대부터 지금까지의 웹디자인의 역사, 실제로 이야기되는 사이트 중 하나인 웹디자인의 역사에 대한 정보를 나타내는 단순한 사이트와 같을 것입니다. 많은 타임라인과 애니메이션이 있는 아름다운 웹사이트였습니다. 그러나 목록만 있으면 정적으로 렌더링될 수도 있습니다. 아무것도 표시하지 않는 것과 현재 현대적인 웹 개발에 접근하는 방식 때문에 잃어버렸던 아름답게 향상된 경험을 보여주는 사이에는 단계가 있습니다.

Drew: 그렇다면 React와 같은 솔루션에 적합한 프로젝트 범주가 절대적으로 있고 실제로 사용해서는 안 되며 보다 전통적인 방법을 사용해야 하는 범주가 있다고 말씀하시겠습니까?

Mina: 내 생각에 귀하의 사이트가 특히 대부분 정적이라면 정보를 제공하는 것이었습니다. DOM 조작 외에 상호작용이 많지 않은 것을 렌더링하기 위해 React와 같은 프로젝트가 필요한 이유를 이해하지 못하는 것 같습니다. . 나는 당신이 그것으로부터 얻는 이익을 보지 못하는 것 같아요. 다시 말하지만, 나는 적절한 프로젝트에서 일하지 않을 수 있습니다. 나는 그 사용 사례를 보거나 찾은 것이 아닐 수도 있지만, 조작된 DOM 및 애니메이션을 넘어서는 많은 상호 작용이 아니라 많은 상호 작용이 아니라 콘텐츠를 제공하는 대부분의 정적 사이트인지 확인하는 데 어려움을 겪고 있습니다. React 라이브러리를 갖는 것이 그 목표를 달성하는 데 어떻게 도움이 되는지 모르겠습니다.

Drew: 실제로 사용하지 않았기 때문에 말하는 것이 나쁘지 않기 때문에 흥미롭습니다. 그러나 많은 Gatsby 프로젝트와 Gatsby가 React 프론트엔드를 사용하는 정적 사이트 생성기인 것을 봅니다. 그리고 저는 테마의 모든 예와 그들이 사용할 수 있는 모든 콘텐츠 기반 사이트 또는 블로그, 레시피 사이트, 포트폴리오 및 이러한 종류의 것들을 봅니다. 그리고 실제로 이것이 React와 같은 것에 꼭 맞는 것은 아니라고 생각하는 것이 있습니다. 이것이 정적으로 렌더링된 다음 점진적으로 향상되지 않는 이유는 무엇입니까?

미나: 네.

Drew: 소프트웨어가 아닙니다.

미나: 네. 저도 사실 개츠비를 써본적이 없습니다. 나는 그것에 대해 좋은 말을 많이 들었지만 아마도 내가 생각하는 예 중 하나일 것입니다. " 다시, 나는 모른다. 아마도 더 많은 사람들이 새로운 것을 작성할 때 React로 작성하는 것을 편안하게 여기고 그들이 있는 곳에서 사람들을 만나는 도구를 제공하기 때문일 수 있습니다. 나는 그것을 사용하고 그것을 사랑하는 사람들을 위해 React를 사용하는 정적 사이트 생성기에 대해 훌륭하다는 이야기를 들었지만 즉시 "오, 말이 되는군요."라고 생각했을 사용 사례는 아닙니다.

Drew: 우리가 웹사이트라고 부르는 것과 웹 앱이라고 부를 수 있는 것 사이에 항상 이 싸움이 있었던 것 같습니다. 그리고 이 둘 사이의 틈은 점점 더 넓어지고 있는 것처럼 보이지만 점진적인 향상 접근 방식은 정적인 것을 취하고 JavaScript를 추가하고 상호 작용을 추가하여 격차를 메우려고 합니다. React와 같은 것들은 브라우저에서 실행 중인 소프트웨어에 이상적으로 적합한 것 같습니다. 동의하시겠습니까?

Mina: 나는 그것이 환경 유형에 맞게 만들어진 것처럼 느껴지기 때문에 확실히 동의할 것입니다. 소프트웨어를 실행하기 위해 만들어졌습니다. Facebook에서 Facebook용으로 만들었습니다. 그래서 그것은 제품을 위해 만들어졌습니다. 그것은 브라우저에서 웹 앱이라고 하는 모든 것을 실행하기 위해 만들어졌으며 언급했듯이 내가 하는 데 익숙한 작업 유형을 위해 반드시 필요한 것은 아닙니다. 따라서 이러한 시나리오에서 브라우저 내부에서 실행되는 더 복잡하고 정교한 소프트웨어를 구축하는 경우 사용하는 것이 확실히 합리적이라고 생각합니다. 그러나 마케팅 사이트나 무엇이든 구축하고 있다면 왜 그곳에서 필요한지 이해하기 위해 여전히 고심할 것입니다.

Drew: 그래서 사람들에게 여전히 정적으로 렌더링된 괜찮은 웹사이트를 만들 수 있는 권한을 부여하고 있습니까?

미나: 그런 일이 더 많이 일어났으면 좋겠어요. 나는 그것이 일종의 길을 잃은 것처럼 느껴지고 그것이 멋지거나 무엇이든 잃어버린 것 같습니다. 웹 개발의 그 부분을 잃어버린 것 같습니다. 너무 웃기네요. 당신과 나는 둘 다 우리가 일종의 구식이라고 말했고, 저는 실제로 웹 개발을 6년 동안 해왔기 때문에 웃습니다. 나는 어떻게 올드 스쿨입니까? 그렇게 오래되지 않았습니다. 하지만 어쩐지 나는 새롭고 반짝이는 것을 좋아하지 않는 늙은 경비원의 일원이다. 나는 그것을 이해하지 못한다.

Drew: 사실 React는 당신이 웹 개발자로 있는 동안 실제로 존재해 왔습니다.

Mina: 어쩌면 나는 단지 오래된 영혼을 가지고 있을지도 모릅니다. 모르겠어요.

드류: 아마 그럴 것 같아요. 나는 개인적으로 살펴보지 않았지만 React 앱으로 취할 수 있는 서비스 측 렌더링 접근 방식이 있습니다. 당신은 그 중 하나를 경험 했습니까?

Mina: 나는 그들을 경험한 적이 없습니다. 현재 작업 중인 프로젝트에 대해 간단히 살펴보았습니다. 클라이언트에서보다 서버에서 더 잘 작동하는 작업의 일부가 있다고 느끼기 때문입니다. 그러나 내 제한된 지식과 코드 기반이 내가 이해할 수 있는 것보다 조금 더 복잡하다는 사실 때문에 그 부분을 작동시키는 방법을 잘 알 수 없었습니다. 나는 결국 그것을 알아내고 싶지만, 나는 그것을 파헤치는 데 하루를 보냈다. 나는 "그거 알아? 나는 이것을 멀리 grokking하지 않습니다 내가 있어야합니다. 그래서 나는 후진해서 다른 길을 택할 것입니다.”

드류: 네. 우리 모두가 거기에 있었다고 생각합니다.

미나: 네. 나는 길을 갔다. 나는 "오, 이것은 어둡고 무섭습니다. 반대로 하자. 역전하자.”

Drew: 코드에서 물러나십시오.

미나: 네.

Drew: 지금까지 React에 대해 매우 외교적이고 예의 바르셨습니다. 나는 표면 아래에서 약간의 긴장이 부글부글 끓고 있다는 것을 느낍니다. 어서 해봐요. 당신이 정말로 느끼는 것을 우리에게 말하십시오.

미나: 저는 예의 바르고 외교적이었습니다. 그 이유는 주로 Reacts 팬 기반이 때때로 약간 비열할 수 있고 그들이 저를 위해 오지 않기를 원했기 때문입니다. 그러니 제발, React는 훌륭합니다. 멋지네요. 사용하고 싶은 용도로 사용하세요. 농담이지만, 이 팟캐스트의 시작 부분에서 언급한 트윗조차도 당신이 말한 것이 싫지 않다는 것입니다. 나는 그것을 사랑하지 않지만 싫어하지 않습니다. 그 말조차도 사람들을 얻었고 비판은 없었지만 더 많은 사람들이 수비에 뛰어 들고 "글쎄, 나는 X, Y, Z 때문에 그것을 좋아한다"고 말할 준비가 된 곳이었습니다. 나는 "나쁘다고 말하지 않았다. 나는 단지 내가 모든 것에 대해 멍청하다고 말했다.” 그러나 분명히 meh되는 것은 옳지 않습니다. 나는 그것을 사랑해야합니다.

Mina: 그래서 내가 평소보다 조금 더 외교적이었던 것 같아요. 사람들이 내가 입으로 말하는 게 나쁘다고 생각하지 않기를 바랐기 때문입니다. 그것은 더 많은 웹 개발의 자리를 가지고 있습니다. 기능을 합니다. 그것은 그 역할을 잘 수행합니다. 사람들은 그것을 좋아합니다. 지금까지 내가 가지고 있거나 사용하고 싶었던 도구가 아닙니다.

드류: 네. 상황이 매우 부족해질 수 있습니다. 사람들이 한쪽 또는 다른 쪽을 택해야 한다고 느끼고 당신은 무언가에 절대적으로 찬성하거나 반대합니다. 그리고 그것이 좋은 목적에 부합하는지 확신할 수 없고, 그것이 우리를 산업 및 커뮤니티로서 실제로 그렇게 하도록 움직이게 하지 않는다고 생각합니다.

미나: 네. 정말 이상해요. 그냥 사회학적인 관점에서 보는 것은 매혹적이지만, 관찰하는 것은 종종 정말로 이상한 것과 같습니다. 내가 말했듯이 특정 문제에 대해 중립적인 것은 허용되지 않는 것과 같습니다. 나는 건강하지 않다고 생각하는 강한 의견을 가져야 합니다. "강력한 의견, 느슨한 주장"이라는 용어는 무엇입니까? 그런 식으로 일을 처리합니다. 나는 어떤 것에 대해 강하게 느끼지만, 당신이 내 마음을 바꿀 수 없는 것은 아닙니다. 내가 어떤 사람들처럼 느끼는 곳에서 그들의 정체성은 그것의 특정 측면에 싸여 있습니다. 만약 당신이 그들이 동일시하기로 선택한 것과 일치하지 않는다면 그것은 개인적인 경미함과 정당함입니다. 저는 이 특정 주제에 대해 신경 쓰지 않습니다. 또는 도구, 또는 무엇이든.

드류: 네. 우리 모두가 스택의 특정 부분을 더 많이 전문화하는 경향이 있다는 사실 때문에 상황이 더 악화되었는지 모르겠습니다. 그리고 React 개발자인 사람들이 있다는 것을 알고 있습니다. 그들은 그들이 일하는 분야이기 때문에 스스로를 React 개발자라고 부를 것입니다. 그리고 그들은 바닐라 자바 ​​스크립트를 작성하지 않거나 Vue 등을 사용하지 않을 것입니다. 반응은 그들의 세계입니다. 그래서 "나는 React를 좋아하지 않아"라고 말하는 것이 전체 경력에 대한 공격처럼 느껴질 것입니다. 글쎄요, 그들은 당신을 React나 그 기술이 무엇이든 좋아하게 만드는 데 정말로 투자하고 있습니다.

미나: 과거에 그런 사람이었음을 인정합니다. 사실, 아마도 대부분 SASS에 관한 것이었으리라 생각합니다. 나는 전처리기로 SASS를 하는 팀에 있었고 다른 모든 전처리기는 쓰레기입니다. 나는 그들에 대해 이야기하고 싶지 않습니다. 나는 그들과 거래하고 싶지 않습니다. 그리고 그것이 사물을 바라보는 매우 좁은 시각이라는 것을 깨달았습니다. 작업에 적합한 도구를 사용하십시오. 생산성을 높이는 것이 무엇이든 그것이 올바른 도구입니다. 그것이 무엇인지는 별로 중요하지 않습니다.

Drew: 그런 종류의 부족 느낌이 없는 우리가 작업하는 기술이 있습니까? 사람들이 그냥 사용하거나 사용하지 않는 것이 있습니까? 나는 아무 생각도 할 수 없습니다.

미나: 와. 사실 마크업에 대한 의견이 있는 사람은 아무도 없습니다.

드류: 아니.

Mina: 아무도 실제 HTML과 마크업과 같은 의견을 갖고 있지 않은 것 같습니다. 그들은 그것을 사용합니다. 그러나 사람들은 CSS와 CSS가 얼마나 끔찍하거나 멋진지, 더 이상 실제로 발생하지 않는 전처리기 전쟁, 그리고 물론 다양한 JavaScript 라이브러리 내의 모든 부족주의에 대해 강한 의견을 가지고 있습니다.

Drew: 따라서 지금까지 React를 사용한 여정은 여전히 ​​"도구입니다. 제 역할을 합니까?”

미나: 만연하고 불필요하다는 이유로 호기심에서 능동적이고 본능적인 혐오로 바뀌었다. 나는 지금 meh와 함께 있습니다. 다시 말해서 내가 그것을 싫어한다는 의미는 아닙니다. 그것은 단지 의미 ...

Drew: 좋은 곳이라고 생각합니다. 특정 기술의 목적에 대한 가치를 이해한다면 우리는 아마도 기술자로서 더 강해질 것입니다. 어떤 상황에서 무엇이 좋은지 평가하고 작업에 적합한 도구를 선택할 수 있습니다.

미나: 네. 그리고 그것이 바로 제가 특정 언어나 기술 또는 그 밖의 어떤 것에도 투자하지 않는 내 경력의 이 시점에 도달한 곳입니다. 하려고 한 다음 그것을 사용하십시오.” 나는 모든 것을 위한 장소가 있다는 것을 배웠습니다. 모든 것을 할 때와 장소가 있습니다. 그리고 최근까지 이 React 사서를 사용할 수 있는 실시간 또는 장소가 없었고 지금은 있습니다.

Drew: 좋은 곳이라고 생각합니다. 그래서 나는 당신이 직장에서 하는 것처럼 최근에 React에 대해 모든 것을 배우고 있습니다. 최근에 배운 다른 것이 있습니까?

Mina: 저는 실제로 아이러니하게도 배웠습니다. Facebook에서 시작된 또 다른 언어라고 생각합니다. 저는 Hack 개발을 많이 해왔습니다. 주로 Slack에서 일상 업무에서 사용하는 것이기 때문입니다. Learning Hack은 하나는 서버 측이고 다른 하나는 그렇지 않다는 점을 제외하고는 매우 유사한 패턴을 따르기 때문에 React를 더 편안하게 사용할 수 있는 길을 열었습니다. 그래서 저는 일반적으로 백엔드와 백엔드가 다양한 이유로 작동하는 방식에 대해 더 많이 배웠습니다. 그리고 나는 지난 몇 년 동안 나 자신을 스트레칭했고 점점 더 내 편안한 영역을 벗어났습니다. 디자인 시스템, 라이브러리, 그것은 거의 제 세계이고 저는 그 세계에서 매우 기분이 좋고 편안합니다. 하지만 저는 그것에서 벗어나 훨씬 더 많은 서버 측 로직, API 개발, 데이터 모델링 등을 하고 있습니다. 저도 지난 1년 동안 그 일을 많이 했습니다.

Drew: 프론트엔드에서 백엔드에 대한 전체 스택에 대해 더 많이 이해할수록 서로에 대한 지식이 도움이 됩니다. 나는 백엔드 코드를 작성하고 이해함으로써 더 나은 프론트엔드 코드를 작성한다는 것을 알게 되었습니다.

미나: 네. 저도 같은 느낌인 것 같아요. 이제 우리가 말했듯이 데이터에서 최종 클라이언트로 이동하는 방법의 전체 스택에 대한 더 나은 아이디어가 생겼습니다. 실제로 어떤 부분에서 작업하고 있는지에 관계없이 전체 파이프라인에 대해 생각하고 있다는 것을 알게 되었습니다. 템플릿에 도달했을 때 다음을 수행할 필요가 없도록 이 API를 구성하는 가장 좋은 방법은 그 끝에서 내가받는 데이터를 너무 많이 조작합니다. 확실히 저를 전반적으로 더 나은 엔지니어로 만들었습니다.

Drew: 청취자 여러분, Mina의 소식을 더 듣고 싶다면 Twitter에서 @MinaMarkham을 팔로우하고 mina.codes에서 개인 사이트를 찾을 수 있습니다. 오늘 함께해주셔서 감사합니다, 미나. 이별의 말이 있나요?

Mina: Have a smashing night?

Drew: Great.