Hacker News 의견

• 많은 JS 개발자들에게는 이단일 수 있지만, 'state' 변수는 안티 패턴이라고 생각함

  • 웹 컴포넌트를 사용하며 '평면' 변수 타입에 대해 state 변수를 추가하는 대신 DOM 요소의 value/textContent/checked 등을 유일한 진실의 원천으로 사용함
  • 필요한 경우 setter와 getter를 추가함
  • 코드의 양이 적어도 자연스럽게 많은 것이 올바르게 작동함
  • WebComponents를 사용하면 객체와 인접한 HTML 템플릿의 분리가 이루어져서 스파게티 코드가 아닌 퓨실리나 마카로니 같은 세분화가 이루어짐

• 이 접근 방식이 매우 유지보수 가능하다고 설명서에 나와 있지만, 동의하지 않음

  • 디자인 패턴이 오직 관례에 기반하고 있음
  • 복잡한 앱에서 여러 개발자가 동시에 작업할 때, 적어도 한 명은 관례에서 벗어날 가능성이 높음
  • iOS의 UIKit 같은 클래스 기반 UI 프레임워크는 모든 개발자가 표준 API 세트를 사용하도록 강제하여 코드가 예측 가능하고 유지보수가 쉬움

• 최근에 vite와 함께 순수 '바닐라' TypeScript로 애플리케이션을 작성하고 있으며, 프론트엔드 '최고' 관행에 대해 점점 더 의문을 가짐

  • 확장성은 결론지을 수 없지만, 성능 면에서 큰 이점이 있음
  • 재미있고, 많은 것을 배우며, 디버깅이 간단하고, 아키텍처를 이해하기 쉬움
  • 템플레이팅이 가장 그리움

• 이 접근 방식은 오래된 backbone js 라이브러리를 떠올리게 함

  • 웹 플랫폼에 적응된 MVC 패턴의 예시가 있는 GitHub 저장소도 있음

• 최근에 비슷한 것을 생각해냈지만, 템플릿 요소를 사용하지 않음

  • 함수와 템플릿 리터럴을 사용하여 문자열을 반환하고, 기존 요소의 innerHTML에 넣거나 새로운 div 요소를 생성하여 넣음
  • 함수가 중첩되어 합리적인 방식으로 구성하기 어려움

• 이 코드는 반응형 뷰 라이브러리가 대체하려는 수동 업데이트 코드와 정확히 같아 보임

• 약 20년 동안 프로그래밍을 해왔지만 프론트엔드 프레임워크에 익숙해지지 않음

  • 백엔드에 더 강해서 보안 관련 상호작용은 서버를 통해야 한다고 생각함
  • JS는 견고한 HTML 및 CSS 기반에 클라이언트 측 기능을 추가하는 것으로 봄

• React.createElement와 유사한 헬퍼를 사용함

  • 모의 서버 대시보드의 작동 예시가 있음

• HTML 기반 도구를 위한 JS 툴킷을 구축하려는 시도로 deja-vu.junglecoder.com에서 작업 중임

  • 적절한 반응형/양방향 데이터 바인딩은 아직 해결하지 못했지만, grab/patch가 꽤 괜찮음
  • 템플릿을 사용하는 방식이 템플릿의 일부를 이동하기 매우 쉬움

• 대학 졸업 후 첫 공식 직장에서 Delphi 소프트웨어의 웹 버전을 만드는 작업을 했음

  • 팀은 이미 프론트엔드를 세 번째로 다시 작성 중이었고, 프레임워크를 변경해야 했음
  • 자체 프레임워크를 작성해야 한다고 주장했지만, 팀은 내 제안을 좋아하지 않았음
  • 이후 다른 회사에서 더 나은 제안을 받아 떠남
  • 이후 tiny.js라는 또 다른 프레임워크를 시도했으며, 개인 프로젝트에 사용 중임