SDK (127.♡.0.1)
2025년 5월 9일 PM 02:08 · 수정됨(05. 28. 19:43)
개요 및 기술 스택
다모앙(※ 대한민국 종합 커뮤니티)의 자유게시판을 Svelte 기반으로 프론트엔드만 동일하게 재구현합니다. 구현 대상 기능은 글 목록 보기, 글 상세 보기, 댓글 목록/작성, 추천 (좋아요) 등으로, UI와 디자인은 다모앙 사이트와 완전히 동일하게 구현해야 합니다. 백엔드는 Go 언어로 구현된 REST API를 사용하므로, 프론트엔드는 해당 API와 통신하여 데이터 CRUD를 수행하는 구조가 됩니다.
기술 스택으로는 프론트엔드에 Svelte를 사용하고, 필요에 따라 SSR(서버 사이드 렌더링)을 고려하여 SvelteKit 프레임워크를 사용하는 것이 좋습니다. SvelteKit은 Svelte 기반의 풀스택 프레임워크로, 페이지 라우팅과 SSR 지원을 제공하며 Next.js와 유사한 역할을 합니다. 스타일링은 다모앙의 기존 UI를 최대한 똑같이 구현하기 위해 Tailwind CSS 같은 유틸리티 CSS 프레임워크를 적용하거나, Svelte의 컴포넌트 Scoped CSS를 활용하여 직접 스타일을 작성하는 두 가지 방식을 고려할 수 있습니다. 전체 구조를 요약하면: Svelte(Kit) + Tailwind CSS(또는 직접 CSS) + Go REST API 조합입니다.
Svelte 프로젝트 구조 및 폴더 구성
Svelte로 게시판 애플리케이션을 개발할 때는 프로젝트 구조를 일관성 있게 잡는 것이 중요합니다. SvelteKit을 사용할 경우, 기본적으로 제공되는 폴더 구조를 활용하면 됩니다. 예를 들어, SvelteKit 프로젝트의 전형적인 구조는 다음과 같습니다svelte.devsvelte.dev:
[code=csharp]my-project/
├ src/
│ ├ lib/ # 공통 라이브러리 코드 (컴포넌트 및 유틸리티 등)
│ │ └ server/ # 서버 전용 코드 (클라이언트에서 임포트 불가)
│ ├ routes/ # 페이지 라우트 파일들 (각 페이지를 나타내는 Svelte 파일)
│ ├ app.html # 어플리케이션 템플릿 (SSR시 사용)
│ ├ ... 기타 설정파일 (hooks, service-worker 등) ...
├ static/ # 정적 자산 (이미지, favicon 등)
├ package.json
├ svelte.config.js
└ vite.config.js
[/code]
위와 같은 구조에서, src/routes 폴더 아래에 페이지별 Svelte 파일을 배치하면 파일 기반 라우팅이 이루어집니다. 다모앙 자유게시판의 경로를 예로 들면 src/routes/free/+page.svelte가 게시판 글 목록 페이지가 되고, 특정 글 상세는 [id] 동적 세그먼트를 사용하여 src/routes/free/[id]/+page.svelte 형태로 구성할 수 있습니다. SvelteKit에서는 폴더와 파일 이름으로 자동 라우팅되므로 별도의 라우터 설정 없이 게시판 페이지들을 만들 수 있습니다.
참고: SvelteKit을 사용하지 않고 순수 Svelte로 SPA를 만든다면,
src/components폴더에 컴포넌트를 모아두고App.svelte에서 라우팅 라이브러리 (예:svelte-spa-router)를 이용해 경로별로 컴포넌트를 스위칭하는 방식을 취할 수 있습니다. 하지만 SSR, 페이지별 코드분할, SEO 등을 고려하면 SvelteKit 기반으로 구조화하는 편이 유리합니다.
또한 src/lib (또는 src/components) 디렉토리에 재사용 가능한 컴포넌트를 분리하여 작성합니다. 예를 들어 공통 레이아웃, 헤더/푸터 컴포넌트, 글 목록 아이템 컴포넌트 등을 lib 폴더에 두고 필요 시 import하여 사용하는 식입니다. 이러한 구조를 통해 코드의 모듈화를 높이고 유지보수를 쉽게 할 수 있습니다. Svelte 자체는 코드 구조에 대한 강제 규칙이 많지 않지만, 기능별로 디렉토리와 파일을 나누어 구성하는 것이 바람직합니다javascript.plainenglish.io.
UI 구현과 CSS 전략
다모앙 사이트의 UI/디자인을 동일하게 구현하기 위해 CSS 전략을 신중하게 선택해야 합니다. Tailwind CSS와 같은 유틸리티-first 프레임워크를 사용할 경우, 미리 정의된 클래스를 조합하여 빠르게 스타일링을 적용할 수 있다는 장점이 있습니다. SvelteKit 프로젝트에도 Tailwind를 쉽게 통합할 수 있으며, tailwind.config.cjs 설정과 src/app.css에 Tailwind 지시어(@tailwind base;, @tailwind components;, @tailwind utilities;)를 추가하면 전체 프로젝트에서 Tailwind 클래스를 사용할 수 있습니다gngb-tech.tistory.com. Tailwind를 적용하면 다모앙의 디자인과 유사한 UI를 구현할 때 여러 Utility 클래스로 스타일을 구성하게 되며, 별도의 CSS를 일일이 작성하는 수고를 덜 수 있습니다. 특히 폰트 크기, 색상, 간격 등을 Tailwind 클래스만으로 쉽게 조절할 수 있어 생산성이 높습니다.
한편, 직접 CSS를 작성하는 방법도 고려할 수 있습니다. Svelte의 경우 각 컴포넌트의 <style> 블록에 작성한 CSS는 해당 컴포넌트에 **자동으로 범위 지정(Scoped)**되기 때문에 전역 클래스 충돌 없이 안전하게 스타일을 적용할 수 있습니다codesignal.com. 예를 들어 PostList.svelte 컴포넌트의 <style>에 .title { color: blue; }라고 쓰면, 해당 컴포넌트 내부의 .title 요소에만 스타일이 적용되고 다른 컴포넌트에는 영향이 없습니다. 이러한 특성을 활용하면 다모앙 사이트의 CSS를 분석하여 유사한 클래스 이름과 스타일을 Svelte 컴포넌트 내에 정의함으로써 원본과 똑같은 룩앤필을 얻을 수 있습니다. 필요하다면 전역적으로 적용해야 하는 스타일(예: <body> 배경색이나 기본 폰트 등)은 Svelte의 :global() 선택자를 사용해 전역 CSS로 지정할 수도 있습니다.
어떤 방식을 선택하든, 디자인 픽셀 퍼펙트에 신경 써야 합니다. Tailwind를 쓰는 경우에도 다모앙의 색상 코드나 여백 값을 그대로 반영하도록 커스텀 Tailwind 설정을 할 수 있고, 직접 CSS를 작성하는 경우 브라우저 개발자 도구로 다모앙 사이트의 CSS 규칙을 참고하여 동일하게 구현하면 됩니다. UI 구성요소별로 CSS를 모듈화해두면 유지보수가 편하므로, 예를 들어 버튼, 카드, 리스트 아이템 등에 대한 CSS를 공통화하거나 Svelte 컴포넌트로 캡슐화하는 것이 좋습니다.
기능별 Svelte 컴포넌트 설계
게시판 애플리케이션은 여러 UI 요소와 기능들로 이루어지므로, 컴포넌트를 기능별로 분리하여 설계합니다. Svelte 컴포넌트 구조는 유연하지만, 각 컴포넌트를 하나의 책임만 맡도록 분리하면 재사용성과 관리성이 높아집니다javascript.plainenglish.io. 다모앙 게시판 클론의 경우 다음과 같은 컴포넌트들로 나눌 수 있습니다:
글 목록 페이지 컴포넌트 (
FreeBoardPage.svelte): 자유게시판의 글 목록 화면 전체를 구성하는 페이지 컴포넌트입니다. 글 목록 데이터를 fetch하여 목록을 렌더링하고 페이지네이션이나 정렬 옵션 등을 포함합니다.글 목록 아이템 컴포넌트 (
PostItem.svelte): 개별 게시글 목록 항목을 나타내는 컴포넌트입니다. 제목, 작성자, 작성일, 조회수, 댓글수, 추천수 등을 표시하며, 클릭 시 상세 페이지로 이동하는 링크를 포함합니다. 목록 페이지 컴포넌트에서#each블록으로 여러PostItem을 렌더링하게 됩니다.글 상세 페이지 컴포넌트 (
PostDetailPage.svelte): 게시글의 제목, 본문 내용을 표시하고, 댓글 컴포넌트를 포함하는 상세 화면 컴포넌트입니다. 이 컴포넌트는 마운트 시 해당 글 ID에 대한 상세정보와 댓글 목록을 API로부터 가져옵니다.댓글 목록 컴포넌트 (
CommentsList.svelte): 해당 글의 댓글 전체를 보여주는 컴포넌트입니다. 내부에서 여러 개의 댓글 아이템 컴포넌트를 렌더링합니다. 필요한 경우 대댓글(threaded comment)을 지원한다면 계층 구조로 comment를 출력할 수 있습니다.댓글 아이템 컴포넌트 (
CommentItem.svelte): 단일 댓글 (또는 대댓글)을 나타내는 컴포넌트입니다. 댓글 작성자, 작성일, 내용 등을 표시하고, 대댓글 작성 기능이나 답글 버튼을 포함할 수 있습니다.추천 버튼 컴포넌트 (
RecommendButton.svelte등): 게시글 추천수를 표시하고 사용자가 추천을 누를 수 있는 버튼 컴포넌트입니다. 클릭 이벤트 핸들러를 통해 Go API의 추천 처리 엔드포인트를 호출하고, 성공 시 UI 상의 추천수 상태를 업데이트합니다. (이 컴포넌트는 글 상세 화면에 포함하거나, 목록 아이템에 포함하여 바로 추천 가능하게 할 수도 있습니다.)
위 컴포넌트 구조를 통해 **관심사 분리(Separation of Concerns)**를 달성할 수 있습니다. 각 컴포넌트는 자기 영역의 HTML/CSS와 데이터를 다루며, 필요한 경우 상위 컴포넌트로 이벤트를 디스패치하여 상호 작용합니다. 예를 들어, RecommendButton에서 추천 클릭 이벤트가 발생하면 상위의 PostDetailPage 컴포넌트로 이벤트를 보내 해당 글의 추천수를 증가시키는 식입니다. Svelte에서는 컴포넌트 간에 데이터를 전달할 때 **프롭스 (props)**와 **이벤트 디스패치 (createEventDispatcher)**를 사용할 수 있습니다. 또한 전역적으로 공유되는 상태(예: 현재 로그인 사용자 정보나 전체 게시판 목록 캐시 등)가 필요하다면 Svelte의 스토어(store) 기능을 활용해 Writable 스토어로 관리할 수 있습니다. 예를 들어, 사용자가 글 상세 페이지에서 추천수를 눌렀을 때 목록 화면의 추천수도 반영하고 싶다면, 해당 글 목록 데이터를 전역 스토어에 저장해두고 상세 페이지와 목록 페이지가 그 스토어를 참조하도록 구현하면 상태 일관성을 유지할 수 있습니다.
컴포넌트 분리 전략의 또 다른 포인트는 재사용성입니다. 다모앙 사이트에는 게시판 이외에도 여러 메뉴(소모임, 공지사항 등)가 존재하지만, 기본적인 게시판 컴포넌트 구조는 유사할 것입니다. 따라서 컴포넌트를 잘 분리해두면 자유게시판 외의 게시판에도 쉽게 확장하거나 사용할 수 있습니다. 예를 들어 PostListPage, PostDetailPage, CommentList 등을 범용적으로 설계하면 다른 카테고리의 게시판에도 같은 컴포넌트를 활용하고 데이터만 바꾸어 쓸 수 있을 것입니다.
Go API 연동 및 데이터 Fetch 예제
프론트엔드 Svelte에서 백엔드 Go API와 통신하기 위해 Fetch API 등을 사용합니다. Svelte 컴포넌트가 화면에 처음 마운트될 때 데이터를 불러와야 한다면, Svelte의 onMount 라이프사이클 훅 안에서 네트워크 요청을 수행하는 것이 권장됩니다beomy.github.io. onMount 훅은 해당 컴포넌트가 초기 렌더된 후 실행되며, 여기서 API 호출을 하면 초기 화면이 빠르게 그려진 뒤 백엔드 데이터를 받아와 화면을 업데이트할 수 있습니다. (SSR을 사용한다면 onMount는 클라이언트에서만 실행되고 SSR 단계에서는 실행되지 않으므로, SSR 모드에서는 대신 SvelteKit의 load 함수를 사용해야 합니다. 아래에서 SSR 관련 설명을 덧붙입니다.)
Svelte에서는 HTTP 요청을 위해 JavaScript의 기본 Fetch API나 Axios 같은 라이브러리를 사용할 수 있습니다sitepoint.com. Fetch API를 활용하는 간단한 예를 들면 다음과 같습니다:=
[code=svelt]<script>
import { onMount } from 'svelte';
let posts = [];
onMount(async () => {
const res = await fetch('https://api.example.com/posts'); // Go API 호출 (예시 URL)
if (res.ok) {
posts = await res.json(); // JSON 형식의 게시글 목록 데이터 수신
} else {
console.error('글 목록을 불러오는 중 오류 발생:', res.status);
}
});
</script>
<!-- 게시글 목록 렌더링 -->
<ul>
{#each posts as post}
<li>{post.title} - {post.commentCount}댓글 - {post.recommendCount}추천</li>
{/each}
</ul>
[/code]
위 코드에서 onMount 내부에서 fetch를 사용하여 /posts API로부터 게시글 목록을 받아오고, 응답 데이터를 posts 변수에 할당하면 Svelte의 반응형 특성에 의해 UI가 자동으로 갱신됩니다. (Svelte 컴포넌트의 상태인 posts가 변경되면 해당를 참조하는 템플릿 부분이 다시 렌더링됩니다.) 마찬가지 방법으로 글 상세 페이지 컴포넌트에서는 fetch('/posts/{id}')로 특정 글 상세정보와 댓글을 불러오고, 추천 버튼 클릭 시에는 fetch('/posts/{id}/recommend', { method: 'POST' }) 등의 요청을 보내는 형태가 될 것입니다. Go로 구현된 API가 RESTful하게 제공된다면, HTTP 메서드와 엔드포인트를 정해서 fetch로 호출하면 됩니다 (GET /posts, GET /posts/{id}, POST /posts/{id}/comments, POST /posts/{id}/recommend 등).
에러 처리와 로딩 상태에 대한 UX도 고려해야 합니다. 예를 들어 fetch 요청 전후로 로딩 중임을 나타내는 스피너나 메시지를 표시하고, 에러가 발생하면 사용자에게 알림창 또는 에러 메시지를 보여주는 처리가 필요합니다. 위 예시 코드를 확장해서 {#await} 블록을 쓰거나, try/catch로 오류를 잡아 error 변수를 표시하는 식으로 구현할 수 있습니다.
SSR 모드에서의 데이터 로드: SvelteKit을 이용하는 경우, onMount는 브라우저에서만 실행되므로 SSR 단계에서 데이터를 미리 가져오려면 src/routes/[...]/+page.js (또는 +page.server.js) 파일의 load 함수를 활용합니다. load 함수 내에서 fetch를 호출하면 SvelteKit이 서버 측에서 API를 호출해 초기 HTML을 생성해줍니다svelte.dev. 이때 주의할 점은, SvelteKit의 SSR에서는 외부 API 호출 시 상대경로(/api/...)를 쓰면 프록시로 동작하므로, 필요한 경우 절대경로 또는 환경변수를 사용해야 합니다. load 함수가 데이터를 반환하면 해당 데이터가 페이지 컴포넌트에 props로 전달되어 초기 렌더링 시 사용되며, 클라이언트에서는 하이드레이션(hydration) 과정을 거쳐 이어받습니다.
정리하면, Go API 연동은 Svelte에서 비교적 간단합니다. fetch로 요청 -> .json()으로 파싱 -> 변수에 할당 -> 화면 출력 순서로 진행되며, 이는 Svelte의 반응형 디자인 덕분에 데이터 수신 후 별도 DOM 조작 없이 자동 업데이트됩니다. 추가로, API 통신시 인증이 필요한 경우(예: 로그인 토큰) Fetch 호출 시 Authorization 헤더를 추가하는 등의 작업도 고려해야 합니다. Go API와 도메인이 다르다면 CORS 설정도 뒷단에서 필요하지만, 이는 백엔드 설정 문제이므로 전제하에 진행합니다.
성능 최적화 및 SSR 고려사항
성능 최적화와 SSR(Server-Side Rendering) 여부는 프로젝트의 요구사항(SEO, 초기 로딩속도 등)에 따라 결정됩니다. 다모앙과 같은 공개 커뮤니티 게시판은 검색 엔진에 게시글이 노출될 가능성이 높고, 콘텐츠 SEO가 중요할 수 있습니다. 이 경우 SvelteKit의 SSR을 활용하여 초기 HTML에 콘텐츠를 포함시켜 주는 것이 유리합니다. 실제 Svelte 공식 문서에서도 “검색 엔진이 클라이언트 사이드 자바스크립트로 렌더된 콘텐츠도 최근에는 색인을 잘 하지만, 서버사이드 렌더링된 콘텐츠가 더 빈번하고 신뢰성 있게 색인된다”고 명시하고 있습니다svelte.dev. SvelteKit은 기본값으로 SSR을 활성화하며, 특별한 이유가 없다면 SSR을 유지할 것을 권장하고 있습니다. SSR을 사용하면 초기 페이지 로드 시 서버가 완성된 HTML을 제공하므로 사용자는 빠르게 콘텐츠를 볼 수 있고, JS가 로드되기 전에 콘텐츠가 보이므로 초기 응답성이 높아집니다.
반면, **클라이언트 사이드 렌더링(CSR)**을 선택하면 프론트엔드가 완전히 정적 파일로 구성되어 배포 및 호스팅이 단순해지고, 초기에는 가벼운 HTML + JS만 전달한 뒤 데이터는 클라이언트가 받아와 그리는 방식이 됩니다. 만약 게시판이 로그인한 사용자 전용의 비공개 공간이라 검색 엔진 크롤링이 중요하지 않거나, 혹은 트래픽이 매우 많아 SSR 서버 부하가 걱정된다면 CSR도 고려할 수 있습니다. 한 개발자 의견으로는 SEO가 불필요한 경우 굳이 SSR을 쓰지 않고 CSR로도 충분하다는 견해도 있습니다forum.golangbridge.org. 요컨대, SEO와 초기 렌더링 속도가 최우선이라면 SSR을 도입하고, 배포의 단순함과 서버 부하 관리가 중요하다면 CSR로 갈 수도 있습니다. SvelteKit을 사용하면 이 둘을 혼용하는 것도 가능한데, SvelteKit은 특정 페이지별로 export const ssr = false를 설정하여 SSR을 비활성화할 수도 있으므로, 일부 페이지는 SSR, 일부는 CSR로 구성하는 세분화도 가능합니다.
기본적인 성능 튜닝으로는 코드 분할과 캐싱 전략을 들 수 있습니다. SvelteKit은 페이지 단위로 번들을 분리하여 필요한 코드만 로드하므로 초기 번들 크기를 최적화해줍니다. 또한 정적 자산(.js, .css)에 대해 브라우저 캐싱을 활용하도록 설정할 수 있고, API 데이터에 대해서는 SvelteKit의 load 함수에서 setHeaders를 통해 캐시 제어 헤더를 설정할 수 있습니다. 예를 들어 게시글 목록 API 응답에 대해 적절한 캐시 만료 시간을 지정하면, 동일한 데이터를 재요청할 때 성능이 향상됩니다svelte.dev. 다만 게시판 데이터는 수시로 변동되므로 너무 aggressive한 캐싱은 피하고, ETag나 Last-Modified를 활용한 조건부 요청 정도가 적절합니다 (이 부분은 주로 Go API 쪽 구현 사항입니다).
Svelte 자체는 가상 DOM 없이 컴파일 시 최적화를 수행하기 때문에 런타임 성능이 우수합니다. 특히 재활용 가능한 리스트 렌더링이나 반응형 업데이트가 매우 효율적이어서, 게시판 글 목록 100개를 표시하고 일부만 변경되어도 변경된 부분만 DOM 업데이트가 이루어집니다. 이를 더욱 최적화하려면 #each 블록에 key를 지정하여 리스트 업데이트 성능을 높이고, 불필요한 상태 변경을 줄이는 식으로 코드를 작성하면 됩니다. 예를 들어 {#each posts as post (post.id)}처럼 key를 사용하면 Svelte가 각 항목을 고유 식별자로 추적하여 변경 사항만 업데이트합니다.
페이지네이션 또는 무한 스크롤 전략도 고려됩니다. 한 페이지에 너무 많은 게시글이나 댓글을 한꺼번에 불러오면 렌더링에 부담이 될 수 있으므로, 보통 게시판은 페이지당 20개 등의 페이징을 합니다. Go API에서 페이지 단위로 데이터를 주도록 하고, 프론트에서는 페이지 전환 시 이전 데이터는 버리거나 필요하면 보존하면서 새로운 페이지 데이터를 불러오도록 구현합니다. 최근 트렌드인 무한 스크롤을 적용할 수도 있지만, 구현 복잡도가 올라가므로 우선은 전통적인 페이징으로도 충분합니다. 댓글 역시 많이 달릴 경우 페이지를 나누거나 접기 기능을 제공해 초기 렌더링 부담을 줄입니다 (다모앙 자유게시판도 댓글을 페이지로 나누는 것을 볼 수 있습니다).
마지막으로, SSR 환경에서의 성능은 서버 측 랜더링 + 클라이언트 하이드레이션 과정 전체를 최적화하는 것을 의미합니다. SvelteKit SSR을 도입하면 초기 HTML은 서버에서 제공하지만, 이후에 클라이언트 JS가 로드되어 Svelte 애플리케이션을 하이드레이션해야 합니다. 이 과정에서 서버와 클라이언트 렌더 결과가 일치하도록 관리해야 하며, 가능하면 불필요한 JavaScript 실행을 줄이는 것이 좋습니다. SvelteKit은 개발 모드에서 SSR 결과 불일치를 경고해주므로, 데이터를 다룰 때 시간이나 랜덤값 같이 클라이언트/서버가 달라지는 부분이 없도록 유의하세요.
정리하면, SvelteKit 기반 SSR + Go API 조합은 다모앙 게시판 같은 사이트에 매우 적합하며, 초기구현은 다소 복잡할 수 있지만 장기적으로 SEO와 퍼포먼스에서 이점이 있습니다svelte.dev. 성능 최적화를 위해서는 Svelte의 모범 사례(컴포넌트 분리, 반응형 최소화, 리스트 키 활용 등)를 따르고, 필요한 경우 브라우저 캐시와 CDN을 활용한 정적 자산 서빙을 병행하면 됩니다. 또한 Lighthouse 등의 도구로 성능 진단을 하면서 병목을 찾아 개선해주는 과정도 권장됩니다.
참고 자료 및 링크
Svelte 공식 문서: Project Structure, Loading data, SEO, Performance 가이드svelte.devsvelte.dev – SvelteKit 프로젝트 구조와 SSR/SEO 모범 사례에 대한 참고.
Svelte 라이프사이클 및 데이터 패칭: Beomy님의 Svelte 라이프 사이클 블로그beomy.github.io – onMount에서의 데이터 가져오기 권장 사항.
TailwindCSS 공식 문서 및 적용 방법: (TailwindCSS Integration 예시)gngb-tech.tistory.com – SvelteKit에 TailwindCSS 적용하여 UI 스타일링 하는 방법.
Svelte에서 Fetch API 사용 예시: SitePoint의 How to Fetch Data in Sveltesitepoint.com – onMount에서 Fetch/Axios로 데이터 가져오는 방법 정리.
컴포넌트 구조화와 모범 사례: JavaScript in Plain English의 Svelte 앱 아키텍처 글javascript.plainenglish.io – 컴포넌트 단위로 책임을 분리하는 원칙 등에 대한 설명.
Go + SvelteKit SSR 논의: Go Forum의 Go + SvelteKit vs Svelte (SSR) 토론forum.golangbridge.org – SSR 사용 여부에 대한 실무자의 의견 참고. (필요에 따라 SSR 결정에 도움)
댓글 (12)
-
푸푸른지붕
25.05.09 · 1.♡.216.5
오~~ 좋은글 감사합니다.. 스벨트 저두 함 공부해 봐야 겠네요. - S
SDK
→ 푸른지붕 작성자 25.05.09 · 127.♡.0.1
감사합니다 {emo:damoang-emo-002.gif:100} -
예예지
25.05.09 · 116.♡.254.67
{emo:DINKIssTyle-3d-ang-001.webp:100} 다재다능하시네요 - S
SDK
→ 예지 작성자 25.05.09 · 127.♡.0.1
이닙니다..감사합니디 -
위위즈덤
25.05.09 · 180.♡.164.192
우왕...지금 스벨트 공부하고 있긴 한데 도움이 될거 같습니다 - S
SDK
→ 위즈덤 작성자 25.05.28 · 127.♡.0.1
아직 시작도 못했네요
많은 도움 부탁드립니다. -
RRealtime
25.05.10 · 75.♡.158.112
스벨트 5 부터는 들여다 볼 기회가 없었는데, 요즘은 어떤지 모르겠네요.
룬 관련해서 생긴 변경점 때문에 호불호가 갈릴 수 있다던데....
그래도 리액트, 뷰, 알파인, 등등등에 비하면 스벨트가 손에 제일 잘 붙는 것 같습니다 ㅎㅎ - S
SDK
→ Realtime 작성자 25.05.28 · 127.♡.0.1
룬 이 무엇인지 모르겠지만 ~ 다모앙 10년 사용으로 보고 있습니다
오픈소스로 누구나 자유롭게 사용가능하게 하는 것이 목표입니다 - 홍
홍시남
25.05.10 · 110.♡.177.211
먼가 리액트랑 방식이 비슷한것 같기도 하네요 - S
SDK
→ 홍시남 작성자 25.05.28 · 127.♡.0.1
리엑트 예전에 책한권 따라친적이 있었는데 , 그때 이해를 잘 했어야 했는데 아쉽습니다
댓글을 작성하려면 이 필요합니다.