과도한 JavaScript 중심 개발, 웹을 망가뜨리다
(jonoalderson.com)요약 개요
과도한 JavaScript 중심 개발, 웹을 망가뜨리다
- JS 프레임워크 남용으로 웹사이트 복잡성 심화
- 개발자 경험(DX)이 사용자 경험(UX)을 압도
- 단순한 작업에도 과도한 구조 요구
- 성능·접근성·유지보수성 모두 저하
- 웹 본연의 기능 회복이 해법
서론
개발 중심 웹의 병폐
- 대부분의 웹사이트는 지나치게 복잡하고 느림
- JS 중심 설계로 사용자보다는 개발자 중심 구조로 전환
- 간단한 변경조차 복잡한 배포 과정을 요구하는 상황이 일반화됨
본론
앱처럼 보이고 싶은 욕망이 원인
- 2010년대 이후, 모바일 앱 유행과 함께 "앱 같은 웹" 요구 증가
- Angular 등 JS 프레임워크가 도입되며 복잡도 급증
- 단순 콘텐츠도 시스템처럼 개발됨
개발자 경험(DX) 우선 문화
- 최신 프레임워크는 개발자 편의에 초점
- 구성요소 추상화가 UX와 괴리 유발
- "왜 블로그에 React를 쓰는가"라는 질문보다 SSR 호환성 논의가 우선됨
복잡성이 표준이 된 현실
- 간단한 작업에도 빌드, 라우팅, API, 캐시 등 다단계 구조 필요
- 복잡한 스택으로 인해 비개발자는 콘텐츠 수정을 하지 못함
- 기술 변화가 너무 빨라 유지보수 어려움
프레임워크 남용의 폐해
- SSR, 캐시, 메타데이터 등 기존 웹 기능을 재구현 중
- 성능은 낮고, 의존성은 늘어남
- 결과적으로 JS 프레임워크로 CMS를 재현하는 모순 발생
무의미한 반복과 비용
- 프레임워크 도입과 폐기가 반복되어 안정된 구조 부재
- 실제 사용자 문제 해결보다 내부 복잡성 해결에 집중
- 콘텐츠 마케팅, SEO, 실험 등이 늦어지고 사용자 경험은 악화됨
JS 남용으로 인한 사용자·마케터 피해
- 콘텐츠 수정에 개발자 개입 필요
- SEO와 페이지 품질 저하
- 사용자에겐 로딩 지연, 인터랙션 오류 등 불편 가중
JS는 도구일 뿐, 목적이 아니다
- JS는 강력한 도구지만, 대부분의 웹사이트에 과도함
- 정적 콘텐츠에 대해선 HTML, CSS, 약간의 JS만으로 충분
- Vanilla JS, 서버 렌더링, 최소한의 스크립트가 더 효율적
권한의 집중과 구조적 문제
- 복잡한 스택으로 인해 모든 작업이 개발자 의존
- 조직 구조상 개발자 중심으로 권력 집중
- 기술 결정이 사용자보단 개발자 편의 기준으로 이루어짐
결론
웹의 본질 회복이 해법
- 빠르게 로딩되고, 검색되며, 유지보수 쉬운 웹사이트가 필요
- 서버 렌더링 HTML, 의미론적 마크업, 최소한의 JS 등 기본 복귀가 답
- 기술보다 결과 중심 접근 필요
- “왜 이 기술을 쓰는가?”라는 질문이 필요
- 단순하고 사용자 중심적인 웹이 곧 성능, 비용 절감, 유연성을 제공함
원글이 지적한 '웹의 과도한 복잡성' 문제에는 공감합니다. 하지만 그 원인을 개발자 문화나 프레임워크 남용으로만 돌리는 진단에는 동의하기 어렵습니다. 오늘날 웹의 복잡성은 상당 부분 '비즈니스 모델'이 요구하는 필연적인 기능과 보안의 그림자이기 때문입니다. 이 점을 빼놓고는 반쪽짜리 진단에 그칠 수밖에 없습니다.
웹은 더 이상 ‘무료 전시관’이 아닙니다. 오늘날 공공 사이트를 제외한 대부분의 웹 서비스는 수익 창출이 목표입니다. 따라서 기술 선택의 핵심 질문은 “이 코드가 순수한가?”가 아니라 “이 기술이 우리 비즈니스를 성공시키는가?”가 되어야 합니다.
이 관점에서 볼 때, 원글이 이상적으로 그리는 ‘가벼운 콘텐츠 웹’은 현실의 비즈니스 요구라는 벽에 부딪히게 됩니다. 예를 들어 콘텐츠를 판매하는 비즈니스는 단순한 정적 페이지로는 운영이 불가능합니다. 유료 구독 및 결제를 처리하려면 사용자 인증, 구독 상태 확인, 권한 관리와 같은 상태 기반 로직이 필요하고, 콘텐츠 보호를 위해서는 불법 복제나 무단 접근을 막는 실시간 토큰 검증 등의 보안 계층이 필수적입니다. 나아가 개인화 및 A/B 테스트를 통해 사용자 경험과 전환율을 높이려면 동적인 데이터 처리 또한 요구됩니다.
이 모든 것은 '정교한 애플리케이션'의 영역이며, 프레임워크는 이를 구현하기 위한 현실적인 도구입니다.
물론 모든 복잡성이 정당화될 수는 없습니다. 우리는 복잡성을 두 가지로 구분해야 합니다.
-
필연적 복잡성: 비즈니스 기능(인증, 결제, 개인화 등)을 구현하기 위해 발생하는, ROI가 명확한 복잡성입니다. 이는 감수해야 할 비용입니다.
-
우발적 복잡성: 개발 편의나 과도한 기술 추상화로 인해 생기는 불필요한 복잡성입니다. 이는 지속적으로 측정하고 제거해야 할 기술적 부채이자 낭비입니다.
성공적인 서비스들은 이 두 가지를 구분하여 현실적인 아키텍처를 구축합니다. 즉, 마케팅과 SEO가 중요한 최전선은 최대한 가볍게 만들고, 핵심적인 거래나 개인화 기능이 필요한 내부 영역은 프레임워크 기반으로 안정성을 확보하는 하이브리드 전략을 통해 속도와 기능성이라는 두 마리 토끼를 모두 잡습니다.
원글은 사용자 경험 악화의 원인을 프레임워크 문화에만 집중하면서 ‘수익 모델이 불러온 필연적 요구’를 배제했습니다. 이 점을 제외하고 웹 개발을 논하는 것은, 손님 테이블에 '빠르고 맛있는 요리'를 내놓는 것만 이야기하면서, 정작 그 요리를 만드는 복잡한 주방과 돈을 받는 계산대의 존재를 없는 셈 치는 것과 다르지 않습니다.
웹이 무겁다고 해서 무작정 프레임워크를 버릴 수는 없습니다. 비즈니스가 요구하는 기능을 얼마나 효율적으로, 최소 비용으로 구현해 사용자에게 가치를 전달하느냐가 논점이 되어야 한다고 생각합니다.
한글 번역본은 아래와 같습니다.
https://junghan92.medium.com/%EB%B2%88%EC%97%AD-%EC%9E%90%EB%B0%94%EC%…
현상은 공감하되 결론은 공감하지 않습니다.
현상의 표면적인 원인은 본문에서도 언급했듯이 "앱 같은 웹"에 대한 수요가 늘어나게 되었다는 거고,
현재나 그때나 웹은 "앱 같은 무언가"를 만들기에 적절하지는 않았으나 똥꼬쑈를 벌이면 "비슷하게 만들 수는 있는" 상태라고 생각합니다.
사실 웹의 태생 자체는 논문 같은 일종의 "문서"를 공유하기 위해서 만들어진 플랫폼입니다.
HTML 의 기본 구성 요소만 봐도 알 수 있습니다.
그러다 cgi 같은 동적 컨텐츠를 생성할 수 있는 기술이 만들어지고, 브라우저 단에서도 스크립트 언어가 내장되면서 결과물에 다이나믹을 부여할 수 있게 되면서 "문서로서의 웹"에서의 탈피가 시작되었습니다.
문제는, 최초의 탈피 순간부터 현재까지 웹의 근간은 여전히 "문서" 기반의 시스템이라는 것입니다.
물론 web socket, webrtc, wasm 등 "문서"향에서 벗어난 새로운 기술들이 많이 나왔지만 현재까지도 대부분의 웹사이트들은 기존의 "문서" 기반의 플랫폼에 의존하여 개발되고 있습니다.
여전히 우리는 화면을 그리기 위해 div 태그들을 쌓아야 합니다.
여기까지가 현상 분석이고 그럼 답이 뭐냐 하는 생각이 드는데,
현실성 같은 거 전혀 생각하지 않고 이상적인 다음 플랫폼의 기능을 상상해보면 이렇습니다.
(모든 사이트가 이래야 된다는 건 아니고 애플리케이션 성격을 지닌 사이트만 한정하여)
일단 브라우저는 일종의 앱 런처가 됩니다.
한번 받아놓으면 오프라인에서도 실행될 수 있어야겠지요.
그리고 앱은 기존의 html/css/js 에서 벗어나 다른 언어로 구현이 됩니다.
그 과정에서 안드로이드 처럼 브라우저가 일종의 프레임워크를 제공할 수 있을 것 같습니다.
서버와의 통신 방식도 기존의 web 요청에서 벗어나 다른 패러다임을 사용해볼 수 있을 것 같습니다.
실시간성이 필요한 통신의 경우 기존의 tcp 통신을 그대로 쓸 수도 있을테고,
http 프로토콜을 사용하지 않는 좀 더 단순한 rpc 통신을 새롭게 만들어서 쓸 수도 있겠네요.
이싱적인 플랫폼이라며 말씀하신 마지막 내용은 무슨 말씀인지 잘 모르겠어요.
결국 네이티브 프로그램을 다운받아서 거기에 액티브X 쓰던 시절 이야기니까요.
문제의 본질은 웹 "문서"에 근간을 둔 HTTP 프로토콜 내에서 앱 같은 웹을 만들기 위한 똥꼬쇼인 셈이고,
이를 해결하기 위해 앱 레벨의 기능이 필요하다면 앱을 위한 새로운 프로토콜과 프레임워크를 만들면 어떨까 하는 의견이었습니다.
스마트폰에서 순수 네이티프 프로그램이 구동되지 않고 일종의 샌드박싱된 앱이 구동되듯이, 그것이 브라우져 레벨에서 실행되는 구조입니다.
물론 액티브 엑스 꼴이 나지 않게 개방성과 표준화가 선행되어야겠지요.
앱 같은 웹이라 하더라도 결론에 나온 것에 가깝게 추구는 해야한다고 봅니다. 자스를 많이 사용하면 클라이언트 입장에서는 무거워지지요.
실제로 그렇게 구현할 수 있는 프레임워크가 없는 것도 아니고요. 당장 Next.js도 클라이언트 컴포넌트 사용을 필요할때만 하는 식으로 최소화하면 얼추 가능하고, 다른 분이 말했던 Rails 진영에는 Hotwire(https://hotwired.dev/)는 작성자가 말한 결론에 거의 근접할 수 있도록 앱같은 웹을 지원하는 프레임워크 집합(터보, stimulus 등)이 있죠.
이 글의 근본적인 주제 의식에는 공감합니다만, 어떤 부분에서는 좀 고개를 갸우뚱하게 만드는 부분도 있군요.
예를 들어, 저희 회사에서 운영하고 있는 특정 서비스 홍보용 웹 사이트는 바로 이 글에서 찬양하고 있는 것과 같은 단순함을 유지하고 있습니다. 다행히도 이 웹 사이트는 대부분의 요소가 충분히 정적인 편입니다. 프론트엔드의 HTML과 CSS 등의 코드는 아무런 프레임워크 없이 사람이 직접 손으로 작성한 것이고, JS도 jQuery와 구글 애널리틱스 정도만 달려 있습니다. 공지사항이나 게시판 등은 jQuery를 사용한 AJAX로 구현되어 있지만, 그렇게 불합리하거나 과도하게 복잡한 수준이라고는 생각하지 않습니다. 제가 오래 전 기초 웹 개발에 입문했을 때 jQuery 기반으로 구현할 수 있었던 수준이라고 생각하거든요. 제가 알기로 이 사이트는 Internet Explorer 시절부터 운영되던 것이라 제가 직접 만든 것은 아닙니다만, 썩 나쁘지 않다고 생각합니다.
하지만 여기에는 Git 버전 관리와 CI/CD 파이프라인이 붙어 있고, 스테이징 서버와 실제 운영 서버를 분리시켜 놨습니다. Main 브랜치에 Pull Request가 병합되면 파이프라인에서 번들러를 돌린 산출물을 스테이징 서버에 자동으로 배포하고, 담당자가 스테이징 서버를 확인한 뒤 배포를 최종 승인하면 그게 다시 운영 서버에 배포되는 형태로 되어 있습니다. 과거에는 그냥 FTP를 통해 원본 파일을 운영 서버에 바로 덮어씌우는 방식이었는데, 관련 업무가 저희 팀으로 넘어온 뒤에 이렇게 변경하였습니다.
이게 정말 비합리적인 복잡성일까요? 과거에는 그 웹사이트의 제목 태그를 수정하는 것이 FTP 접속을 지원하는 AcroEdit(네, 원래 그 사이트의 HTML을 직접 작성하신 분들은 여전히 이걸 쓰시고 계셨습니다.)로 운영 서버의 HTML 파일에 바로 들어가서 한 줄만 수정하고 저장하면 모든 작업이 끝나는 일이었으니 그 분들은 아마도 그렇게 느낄 수도 있을 것 같습니다.
그러나 제가 생각하기에는 이 정도 복잡성 추가는 충분히 감내할 만한 것이었다고 봅니다. 모든 작업이 오직 제목 태그 하나 수정하는 것과 동일한 정도는 아니지 않습니까. 그리고 예전 코드가 주석 처리되어 덕지덕지 붙어 있던 것을 언제든 되돌릴 수 있으므로 부담없이 완전히 삭제할 수 있다거나, 투명한 변경내용 추적 및 롤백이 가능해진 점이나, 번들러에 의해 필요하다면 조금 더 기본적인 최적화를 추가할 수 있다는 점은 제 생각에는 충분히 장점입니다. 실제 환경에 배포되기 전에 미리보기를 할 수 있는 스테이징 서버 추가도 어떻게 보면 복잡성 아닌가 할 수 있습니다만, 저는 이것이 필요했다고 생각합니다.
저도 각종 웹 사이트 내부 코드 구조가 과도하게 복잡해지고 무거워진 것에는 불만이 많습니다. 요즘 윈도우의 아웃룩 앱은 웹 앱 기반으로 되어 있는데, 근래 들어서 특히나 더 무거워졌습니다. 그저 화면에서 메일 본문을 작성하거나 본문을 전체 선택하는 것만으로 버벅이거나 심지어는 "페이지 응답 없음"이 뜰 지경이니까요. 왜 이러지 싶어 웹 아웃룩에서 개발자 도구를 열어봤다가 깜짝 놀랐습니다. 한번 캐시를 비우고 새로고침을 했더니 1분 뒤에도 무슨 요청이 계속 뜨더라니까요. 브라우저에서 확인해 보니 MS 오피스 사이트 관련으로만 몇 기가바이트의 데이터가 저장되어 있었습니다.
그러나 이 글은 여러 가지가 뒤섞여 있으며, 어떤 부분은 공감합니다만 어떤 부분은 별로 공감이 되지 않습니다. 시맨틱 HTML이나 접근성에 대한 내용은 오히려 과거가 더 끔찍했다고 알고 있습니다. 게다가 개발자 경험 향상이 사용자 경험을 악화시킨다는 건 제가 웹 프론트엔드 개발자가 아니라서 그런지는 몰라도 전혀 공감이 되지 않네요. 심지어 개발자에게 모든 권력과 통제력이 집중되었다는 건 터무니없는 소리처럼 들립니다. 회사에서 권력은 경영진에게 있는 거 아니었습니까? 서양에서는 회사 구조가 한국과는 좀 다르기라도 한 건가요?
언제나 그렇듯 균형과 중용, 단순성과 실용성은 중요한 가치이며 이를 의사결정에서 우선시해야 한다는 점에는 전적으로 동의합니다. 하지만 이 글은 "모든 웹사이트를 소프트웨어 제품처럼 다루는 것"이 마치 전적으로 개발자의 책임인 것처럼 주장하고 있으며, 그 부분이 오히려 근본적인 문제 의식을 흐리게 만든다고 생각합니다. 그리고 체계가 잡혀 있지 않았던 '좋았던 옛날'을 미화하는 것처럼 보이는 부분은 오히려 비판받아야 하지 않나 생각합니다.
어떤 부분에서 완전히 다른 이야기라고 생각하시나요?
결국 이 글에서 비판하는 것은 과도한 복잡성과 그로 인한 부풀려짐이라고 생각합니다. 제 댓글에서 자바스크립트 이야기를 꺼내지 않았다고 하여 완전히 관련이 없는 댓글이라고는 생각하지 않습니다. 어찌 보면 지엽적인 부분에 대한 비판이니까요. 그리고 제 댓글에서 처음부터 언급했듯이, 저도 원래 글의 근본적인 주제 의식에는 공감하고 있습니다.
원 글의 의도를 잘못 이해 하신거 같아요.
"...여기에는 Git 버전 관리와 CI/CD 파이프라인이 붙어 있고, 스테이징 서버와 실제 운영 서버를 분리시켜 놨습니다. Main 브랜치에 Pull Request가 병합되면 파이프라인에서 번들러를 돌린 산출물을 스테이징 서버에 자동으로 배포하고, 담당자가 스테이징 서버를 확인한 뒤 배포를 최종 승인하면 그게 다시 운영 서버에 배포되는 형태로 되어 있습니다. 과거에는 그냥 FTP를 통해 원본 파일을 운영 서버에 바로 덮어씌우는 방식이었는데, 관련 업무가 저희 팀으로 넘어온 뒤에 이렇게 변경하였습니다.
이게 정말 비합리적인 복잡성일까요?"
라고 하셨는데 별로 관련이 없는 글 같습니다. 배포와 관리를 그렇게 하는 정도의 일과 이 글이 주장하는 바는 많이 다른거 같아서요.
원래 글의 의도는 단순히 복잡해진 JS 프레임워크만을 비판하는 것이 아닙니다.
편의를 위하여 위에 있는 한국어 번역본 링크에서 인용하도록 하겠습니다.
지금은 단순히 제목 하나를 바꾸는 데도 4명의 엔지니어, 3개의 프레임워크, 그리고 CI/CD 파이프라인이 필요합니다. 웹페이지를 게시하는 것이 이상할 정도로 복잡해졌습니다.
그렇게 점진적으로, 웹은 게시하기 전에 컴파일해야 하는 것이 되었습니다. 사용자가 필요해서가 아니라. 개발자가 현대적으로 느끼기를 원했기 때문입니다.
모든 것이 개발자를 위해 최적화되었고, 다른 모든 사람에게는 적대적입니다.
우리는 더 이상 복잡성을 단순히 감내하는 하는 것이 아니라 당연한 것으로 여깁니다. 모든 사이트에 빌드 단계, 번들러, 하이드레이션 전략, 라우팅 레이어, API 레이어, 디자인 시스템, 그리고 영리한 캐시 무효화 로직이 필요하다고 가정합니다. 마이크로서비스로 구축하고, 엣지 네트워크에 호스팅하며, 단순한 콘텐츠를 전달하기 위해 파이프라인을 배포합니다.
우리는 워드프레스와 같은 플랫폼의 기능들을 다시 만들고 있지만, 10배 더 무거우면서도 사용성은 훨씬 떨어지는 결과를 만들어내고 있습니다. 더 나쁜 것은, 모든 새로운 레이어가 새로운 버그, 새로운 호환성 문제, 새로운 인지적 부담을 도입한다는 것입니다. 이제 우리는 단순히 홈페이지를 온라인에 올리기 위해 하이드레이션 로직과 캐시 전략 그리고 빌드 파이프라인을 유지보수하고 있습니다.
컴포넌트 라이브러리가 충분히 유연하지 않아서 마케팅 캠페인이 지연됩니다. 분석 레이어가 하이드레이션 전략과 호환되지 않아서 A/B 테스트가 취소됩니다. 콘텐츠 업데이트는 빌드를 며칠씩 기다려야 합니다. 기본적인 SEO 조정은 백로그에 묻혀버립니다.
마케터들은 티켓을 올리지 않고는 카피를 업데이트하거나 실험을 실행할 수 없습니다. 콘텐츠를 미리 보거나, 레이아웃을 테스트하거나, 페이지를 내보낼 수 없습니다. 모든 변경 사항은 개발자, 파이프라인, 승인, 재구축을 거쳐야 합니다.
마케터, 콘텐츠 편집자, SEO 담당자, 디자이너 이들은 모두 프로세스에서 배제됩니다. 이제 간단한 작업조차 기술적 유창함이 필요하기 때문입니다. 타이틀 태그를 바꾸고 싶다고 하면 엔지니어와 상의하시라고 할 것이며, 캠페인을 내보내고 싶다면, 티켓을 올리고 두 스프린트를 기다리라고 할 것입니다.
모든 것이 개발팀을 통해 흘러갑니다. 즉, 개발팀이 무엇이 중요한지, 무엇이 배포되는지, 무엇이 무기한 우선순위에서 밀리는지 결정한다는 의미입니다. 그리고 그들이 더 많은 복잡성을 추가할수록, 그들은 더 불가결해집니다.
한국이 경영진->기획자->개발자로 내려오는 개발 문화와 달리 서양 같은 경우에는 한국의 기획자 개념이 없고 개발자가 적극적으로 프로덕트 기획 등에 관여하는 부분은 있습니다. 서양의 PM 등은 커버레터와 자소서가 완전히 일치하는 개념이 아니듯이 한국의 기획자와 완벽하게 일치하지 않습니다. 물론 창작 프로젝트의 성격이 강하고 재미와 게임성이 중요한 게임은 서양도 아시아보다는 수평적이지만 디렉터에서 개발자로 내려오지만요.
이 글의 요지에 동의합니다. 요새 JS를 너무 남발하고 있어서 i9-9900k를 쓰고 있어도 사이트가 버벅이는 경우가 많습니다. 게임용이나 작업용으로써는 애매한 사양이기는 하지만 이보다 사양 떨어지는 사무용 컴퓨터가 넘쳐나는게 현실이죠.
그래서 저는 인터렉티브한 부분이나 인터렉티브한 페이지 네비게비션 같은 JS가 꼭 필요할때만 쓰자는 철학의 프레임워크인 아스트로와 hotwired를 좋아합니다. 서버 사이드에서 렌더링 하자는 서버 사이드 렌더링도 좋아하고요. 반면 CSR(메타 태그만 서버 사이드로 렌더링하고 나머지 부분을 CSR로 처리하는 것도 포함합니다)은 굉장히 싫어합니다. 서버가 해야할 일을 클라이언트가 전가시키는 것으로 보고 있기 때문입니다. 개인적으로 CSR을 사용하는 전통적인 SPA 방식은 일렉트론 같은 앱에서 로컬로 프론트엔드를 실행할때 사용해야 한다고 봅니다. 물론 서버에서 프론트엔드를 로드할 경우에는 SSR을 써야 하지만요.
아래는 게시글에 대한 댓글 반응을 5가지 유형으로 분류한 요약입니다:
1. 전면 동의 및 지지
-
주요 특징: 글의 주장에 전폭적으로 동의하며, 복잡한 JS 스택의 문제를 인정함.
-
의견 예시:
- “마침내 누가 할 말을 해줬다.”
- “현실을 직시한 훌륭한 글이다.”
- “웹 성능과 접근성은 필수다.”
2. 프레임워크 남용에 대한 우려
-
주요 특징: React, Angular 등 프레임워크의 과도한 사용을 비판하며, 단순한 기술로 충분하다는 의견.
-
의견 예시:
- “React는 블로그에 필요 없다.”
- “Vanilla JS면 대부분 해결된다.”
- “Svelte, Eleventy 등 경량 대안이 더 낫다.”
3. 부분 동의 + 현실 고려
-
주요 특징: 주장에 공감하지만, 복잡성이 불가피하거나 필요하다고 보는 현실적 입장도 존재.
-
의견 예시:
- “복잡성이 문제지만 일부 상황에선 불가피하다.”
- “협업과 유지보수에는 프레임워크도 필요하다.”
- “HTML/CSS도 불완전해서 JS를 쓸 수밖에 없다.”
4. 개발 문화 및 산업 구조 비판
-
주요 특징: 프레임워크 과잉은 단순한 기술 문제가 아니라, 채용·문화·마케팅 구조의 산물이라 지적.
-
의견 예시:
- “프레임워크는 이력서용 기술이 됐다.”
- “개발자는 회사 요구를 따를 뿐이다.”
- “이건 조직문화와 고용시장의 문제다.”
5. 비판 또는 반대
-
주요 특징: 글의 전제에 동의하지 않거나, 일방적인 주장이라고 비판.
-
의견 예시:
- “웹이 느려졌다는 근거가 없다.”
- “글이 지나치게 편파적이다.”
- “WordPress로 JS 문제를 해결하는 건 오히려 후퇴다.”
근거에 벤치마크 결과가 있으면 개발자들이 더 공감할 수 있을 거라고 생각합니다. 과도한 프레임워크 코딩이 있으면 확실히 사이트가 느려지겠지만 개인적으로는 사이트 내 페이지 전환 면에서 바닐라 코드로 만든 사이트가 최적화시킨 프레임워크 사이트보다 느린 걸 더 많이 보았기 때문입니다. 물론 정적 데이터로만 된 사이트라면 HTML + CSS만 있는 게 더 빠를지 모르겠지만 현대에 정적 데이터로만 된 사이트가 흔할지는 잘 모르겠습니다.
리액트나 뷰같은게 없으면
같은 기능을 구현해도 코드를 더 복잡하게 구현 해야되는데요?
특히 팝업다룰때 props 하나 넘기는것도 순수 자바스크립트로하면 코드가 많이 복잡해집니다
이렇게 간단한거하는데도 코드가 복잡해지면 진짜
복잡한 기능은 구현하기 어려워지죠
사람들 쓰는 브라우져는 종류 몇개 되지도 않는데 프레임워크는 이리 많은건지. 브라우져 관리하는 회사에서 최적 프레임워크 만들어서 같이 관리 좀 하는게 최선 아닐까요. 언제까지 이 악순환을 반복할것인가.