본문 바로가기
개발

[번역]Svelte의 원리

by 개발곰 2024. 1. 5.

이 글의 원문은 Richard Harris가 Svelte Github Repository에 올린 Tenets 입니다.

 

이 글은 Svelte의 철학 - 우리의 근간 철학이며, 우리가 설계 결정을 내린 지침을 뚜렷하게 표현하기 위한 시도입니다.

웹이 중요합니다. (The web matters)

우리는 웹이 매우 중요하고, 웹의 지속적인 생존이 보장할 수 없다고 믿기 때문에 Svelte를 개발합니다.

느낌을 최적화합니다. (Optimise for vibes)

사람들은 Svelte를 좋아하기 때문에 Svelte를 사용합니다. 자신의 미적 감각과 일치하기 때문에 좋아합니다.

가장 빠르거나, 가장 작은 것 같은 걸 추구하기보다는, 가장 좋은 느낌이 든 프레임워크가 되는 것을 명시적인 목표로 삼고 있습니다.

채택 받기 위해서 최적화하지 않습니다. (Don't optimise for adoption)

가장 대중적인 프레임워크가 되려고 하기보단, 가장 좋은 프레임워크가 되려고 하고 있습니다. 우리가 믿고 내리는 선택들이, 웹 개발 트렌드 흐름에 때때로 반할 수도 있습니다.

HTML은 모국어입니다. (HTML, The Mother Language)

HTML은 UI를 묘사하는 데 정말 좋은 언어입니다. Svelte는 HTML을 반응형 UI를 만드는데 좋은 언어가 되도록 HTML을 발전시킵니다.

대부분의 프레임워크는 JS 중심적입니다. 왜냐하면 JS는 가장 강력한 언어이기 때문입니다. 하지만 이 프레임워크들은 개발자들이 HTML을 쓰고 있다고 느끼도록 하는 데 큰 노력을 기울이고 있습니다. 이 두 가지 선택지 모두 유효하지만, HTML에 우선하여 접근하는 방식이 더 자연스럽게 느껴집니다.

발전을 받아들입시다. (Embrace progress)

웹 개발자 커뮤니티에는 번들러, 타입스크립트, 클라이언트 사이드 라우팅 및 기타 여러 현대 웹 개발의 함정에 빠지기 전 시대가 더 좋다고 생각하는 해롭고 비관적인 형태의 형수가 나타나는 경향이 있습니다.

이건 말이 안 되는 소리입니다. 커뮤니티로서 우리의 기술에 대한 입장은 낙관주의입니다. 플랫폼이 더 좋아지고, 도구가 더 좋아지고, 장비가 더 좋아지고, 우리가 그것들을 받아들인다면 더 좋은 것을 만들 수 있을 것입니다.

다른 프레임워크에서 시그널이나 서버 컴포넌트와 같은 아이디어를 도입할때, 우리는 현실에 안주하기보단 질투심과 흥미를 느끼고 좋은 아이디어를 어떻게 접목할 수 있을지 고민합니다. 항상 개선의 여지는 존재합니다.

숫자는 거짓말을 합니다. (Numbers lie)

Lighthouse는 이 세대의 웹 개발자들의 두뇌를 망가뜨렸습니다. 우리는 올바른 판단을 내리는 대신에 진단 도구로 사용되던 지표에 복종하고 있습니다.

Goodhart의 법칙은 다음과 같습니다.

어떤 지표가 목표가 되면, 그건 더 이상 좋은 지표가 아니다.

웹 개발에서 이는 매우 사실입니다. 수치적 엄밀성은 좋고, 우리는 다양한 수치에 주의를 기울이지만, Svelte를 설계할 때 우리는 정량적이기보다는 정성적으로 생각합니다.

마법이 아니라 마법적일 것. (Magical, not magic)

마법적이라고 느끼는 것과 마법 이라고 느끼는 것에는 미묘한 차이가 있습니다. 우리는 Svelte가 마법적이길 바라며, 여러분이 Svelte 코드를 작성할 때, 마법사가 된 기분을 느끼길 바랍니다. 저는 과거 Svelte는 작동 방식이 100% 명확하지 않은 마법의 영역에 너무 깊게 들어갔다고 생각합니다. 우린 이를 Svelte 5에서 바로잡고 있습니다.

꿈을 크게 꿉시다. (Dream big)

'작업에 적합한 도구를 선택하라' 현명하지만 지루한 조언입니다.

이 말은 우리의 야망을 작게 만듭니다. 저는 우리가 더 큰 꿈을 가지길 바랍니다. 제 도구들이 변화하는 요구사항을 처리하지 못한다고 느껴지거나, 새로운 분야에서 작업하기 위해서 완전히 새로운 작업방식을 배워야 한다고 느껴지길 원하지 않습니다.

설령 달성할 수 없다고 밝혀져도, 순수 정적 콘텐츠, 실시간 멀티플레이어 앱, 오프라인 우선 앱, 더 나아가 증강현실과 같은 상황들에 상관없이 "SveltKit이 최고의 프레임워크가 되려면 무엇이 필요할까? 질문을 던지는 것이 중요하다고 생각합니다.

아무도 신경 쓰지 않아요. (No-one Cares)

대부분 사람은 프레임워크에 신경 쓰지 않습니다. 그냥 뭔가 멋진 걸 만들고 싶어 할 뿐이고, Svelte는 그들을 위한 것입니다.

따라서 우린 설계 할때 한동안 문서를 읽지도 않았고, 세밀한 렌더링(fine-grained redenering)이나 빌드 도구 설정에 관심없는 사람들도 고려해야 합니다. 즉, 직관적이어야 하고, 메모이제이션과 같은 최적화에 대해 걱정할 필요가 없어야 하며, API가 가능한 한 적어야 하고, 검색이 가능해야-Rune에 마우스를 가져가면 종합 문서로 가는 링크가 제공되는 것처럼- 합니다.

이는 우리의 문서와 튜토리얼 접근 방식에도 영향을 미쳤습니다. 필요한 개념만 익히고 나머지는 걱정하지 않아도 원하는 것을 만들 수 있어야 한다는 것이죠.

합의를 통해 설계합니다. (Design by consensus)

Svelte는 커뮤니티가 주도하고 합의에 의해 진행되는 프로젝트입니다. 커뮤니티, 즉 여러분이 프로젝트의 미래에 대한 지분을 갖는 것이 중요합니다. Svelte의 최고 아이디어들 중 상당수는 코어 팀 외부에서 나온 것이빈다.

우리가 새로운 계획을 소개할 때면, 우리는 커뮤니티와 공개적으로 소통하고 모든 사람이 피드백을 할 수 있는 좋은 기회를 제공하고자 합니다.

매일 프로젝트를 진행하는 사람들은 어떤 프로젝트가 되었으면 하는 비전이 있지만, 그 비전을 사람들의 의지에 반하여 강요하고 싶지는 않습니다. 모든 변경 사항에 대해 동의를 얻을 수 없더라도, 적어도 반대 의견을 듣고 고려하고 있다고 말할 순 있습니다.