왜 바닐라프론트를 만들었나!! 8

VanillaFront는 왜 Shadow DOM을 선택했는가?

웹 컴포넌트 시대의 View 격리 — 그 결정 배경과 실전 효과도입브라우저 UI 프레임워크를 만들 때 가장 먼저 마주하는 문제는 화면과 화면 사이의 간섭입니다. 스타일이 뒤섞이고, id 값이 충돌하고, 이벤트가 엉키고, 다른 라이브러리와 부딪히죠. 이 문제는 웹이 30년 넘게 안고 온 근본 문제입니다.VanillaFront는 이 문제를 Shadow DOM으로 정면 돌파한 프레임워크입니다. 지금은 이 결정이 자연스럽고 표준적으로 보이지만, 프레임워크 설계 관점에서는 신중한 트레이드오프 계산이 있었습니다. 이 글은 그 배경과 실전 효과를 정리한 글입니다.Shadow DOM이 무엇인가Shadow DOM은 W3C 웹 표준(Web Components 표준의 일부)으로, 특정 DOM 요소에 캡슐화된 별도의 DOM ..

AI 시대에 B2B UI Framework의 선택

왜 이 글은 상용 3사(Nexacro / WebSquare / eXBuilder)와만 비교하는가먼저 오해가 없도록 짚고 갑니다. 이 글은 React·Vue·Svelte 같은 범용 오픈소스 프론트엔드 라이브러리를 비교 대상에서 의도적으로 제외합니다. 이유는 세 가지입니다.시장 성격이 다릅니다. React/Vue는 범용 UI 라이브러리이고, 국내 B2B/공공 SI에서 "UI Framework"라는 이름으로 도입 검토되는 대상은 대부분 엔터프라이즈 그리드·트리·차트·리포트·폼 검증까지 하나의 스택으로 묶어 납품·유지보수 계약이 가능한 상용 UI Framework입니다. 도입 결재 라인, 요구되는 인증(GS인증 등), 하자보수 책임 구조 자체가 다릅니다.패키지 완결성 관점의 비교가 무의미해집니다. React/V..

국내 UI Framework (Nexacro, WebSquare, eXBuilder) 와 VanillaFront 상세 비교

시작하며한국 엔터프라이즈 웹 개발 시장에서 자리 잡은 세 개의 상용 UI Framework와 VanillaFront를 항목별로 비교합니다.Nexacro (넥사크로) — 투비소프트(TOBESOFT)WebSquare (웹스퀘어) — 인스웨이브 시스템즈(Inswave Systems)eXBuilder (엑스빌더) — 토마토시스템(Tomatosystem)세 제품은 국내 SI 시장에서 오랜 실적을 축적한 표준급 도구들이고, VanillaFront는 다른 축에서 같은 시장을 겨냥합니다. 각 제품이 서로 다른 특성을 가지므로 개별 제품으로 나눠서 특성을 정리한 뒤 항목별로 비교합니다.1. 각 제품 개요1.1 Nexacro (넥사크로) — 투비소프트계보XPlatform·MiPlatform의 후속 제품국내 SI 시장에서 ..

왜 VanillaFront는 웹팩을 버리고 Dynamic Import 방식을 채택했나?

시작하며2015년 무렵부터 프론트엔드 개발의 표준은 Webpack 이었습니다. React·Vue·Angular 어느 쪽을 쓰든 결국 Webpack config를 만지고, dist/main.[hash].js 를 배포하는 흐름이었죠. Webpack이 없으면 모던 프론트엔드 개발이 안 된다는 인식이 굳어질 만큼 표준이었습니다.VanillaFront는 그 표준을 의도적으로 벗어난 프레임워크입니다. Webpack 없이, 번들러 없이, 브라우저가 ES6 모듈을 직접 로드하는 구조로 설계했습니다. 이 선택의 배경에는 단순히 "번들러 세팅이 귀찮아서" 라는 이유가 아닌, 번들 스플리팅이 야기하는 복잡도, 모던 브라우저의 성숙, HTTP/2 이후 성능 모델의 변화 라는 세 축이 있습니다.이 글에서는 Webpack의 장점..

React vs ExtJs vs VanillaFront

React vs ExtJS vs VanillaFront프론트엔드 개발 도구를 검토할 때 자주 저울에 오르는 이름 React와 글로벌 엔터프라이즈 UI Framework인 ExtJs입니다. 여기에 VanillaFront를 같이 비교해봅니다. 세 도구는 성격이 다르고 각자 잘 맞는 자리가 있습니다. 이 글에서는 항목별 특성과 실제 코드를 함께 비교합니다.한눈에 요약 구분ReactExtJsVanillaFront성격UI 렌더링 라이브러리통합 프레임워크통합 프레임워크클래스 시스템함수·클래스 컴포넌트자체 클래스 시스템표준 ES6 class모듈 시스템ES6 import + 번들러자체 모듈 시스템ES6 import (No-Build)그리드·차트·다이어그램별도 라이브러리 조합내장내장상태 관리라이브러리 조합자체 Store..

React vs VanillaFront — 유사점과 차이점

한 줄 요약: 둘은 서로 다른 시장과 문제를 푸는 다른 방향의 접근입니다. 그런데 놀랍게도 ES6 클래스·모듈·async/await 같은 밑바닥이 완전히 같고, React 개발자가 VanillaFront에 자연스럽게 진입할 수 있는 유사점이 많습니다. 이 글은 React 개발자 관점에서 **이미 아는 것 90%, 새로 배울 것 10%**를 정직하게 짚습니다.시작하며 — 대체가 아니라 서로 다른 방향먼저 이 글의 톤을 명확히 합니다. VanillaFront는 React를 대체하려는 프레임워크가 아닙니다. React는 세계 최대 프론트엔드 라이브러리이자 압도적 생태계·커뮤니티·자료를 가진 훌륭한 도구입니다. 컨슈머 앱·랜딩 페이지·이커머스·글로벌 서비스 등 자유로운 UI 표현이 우선인 시장에서 React의 ..

ExtJS 사용자를 위한 다음 단계: VanillaFront

시작하며ExtJS는 훌륭한 프레임워크였고, 지금도 많은 한국 기업의 사내 시스템·관리자 페이지·대시보드를 돌리고 있습니다. 그리드·폼·레이아웃이 한 세트로 제공되는 "batteries included" 철학은 사내 시스템처럼 화면 수가 많고 시각적 통일성이 중요한 프로젝트에 정확히 맞았습니다.하지만 2020년대 중반, ExtJS를 유지하는 개발팀은 몇 가지 무거운 질문에 직면합니다.Sencha가 Idera에 인수된 후 라이선스 정책·가격이 강화되었고,ExtJS 4/5는 사실상 EOL, 모던 브라우저 대응·보안 패치가 부담이 되며,모던 개발 워크플로우 (AI 코드 생성, VSCode 통합) 와 거리가 멀어졌습니다.이 글은 그런 팀들에게 VanillaFront가 왜 자연스러운 다음 단계가 되는지 — 익숙한 ..

왜 VanillaFront를 만들었나?

왜 VanillaFront를 만들었나?한국 UI 프레임워크 시장의 현실한국의 사내 시스템·엔터프라이즈 웹 개발에는 오랜 관행이 있다. 그리드·차트·다이어그램 같은 전문 컴포넌트가 필요하면 사실상 몇 개 안 되는 상용 UI 프레임워크 중 하나를 고른다. 대안이 없어서가 아니다. 이 도구들이 오래 자리를 잡아서 "일단 이거로 시작" 이 표준이 되어버렸기 때문이다.문제는 이 표준의 진입 비용이다.라이선스 벽정확한 가격은 벤더별·계약별로 다르지만, 시장에서 통용되는 대략의 감각은 이 정도다:카테고리대표 제품가격대 (대략)종합 UI 플랫폼국내의 N제품, W제품, eX제품프로젝트/도메인당 수천만 원 ~ 수억 원 이 가격표를 보는 세 부류의 개발팀이 있다:대기업·공공 SI — 프로젝트 예산에 라이선스가 이미 편성되어..