• HTML부터 React까지의 제가 알고 있는 웹 프론트엔드 흐름에 대해 정리를 해보고자 합니다.
  • 웹은 HTML, CSS, Javascript로 구성되어 있습니다. DART나 KOTLIN.JS, 웹어셈블리 등이 웹을 지원하기는 한다고 합니다.

HTML

  • 가장 먼저 HTML은 HyperText Markup Language로 웹페이지를 기술하기 위한 마크업 언어입니다.
  • 웹페이지의 내용과 구조를 담당하는 언어로써 태그를 통해 정보를 구조화하는 것입니다.
  • 현재 사용 되고 있는 버전은 HTML5입니다.

CSS

  • CSS는 Cascading Style Sheets로 HTML이나 XML과 같은 구조화 된 문서를 화면에 어떻게 렌더링할 것인지를 정의하기 위한 언어입니다.
  • HTML5 이전 버전의 HTML에는 style을 컨트롤할 수 있는 태그 font, center 등이 존재하여 CSS가 없이도 어느 정도의 스타일 표현이 가능했지만, 정보와 구조를 담당하는 HTML의 본연의 역할과 동떨어진 기능까지 추가됨으로서 복잡하고 혼란스러운 언어가 되어 현재는 구분되어 사용하고 있습니다.
  • HTML과 CSS는 각자의 문법을 갖는 별개의 언어이며 HTML은 CSS를 포함할 수 있습니다. 그러나 HTML없이 단독으로 존재하는 CSS는 의미가 없습니다.
  • CSS는 기본 CSS말고도 sass, scss less, CSS-in-JS 등으로 활용 합니다.

Javascript 역사

  • 자바스크립트는 1995년 당시 약 90%의 시장 점유율로 웹 브라우저 시장을 지배하고 있던 넷스케이프 커뮤니케이션즈에서 정적인 HTML을 동적으로 표현하기 위해 경량의 프로그래밍 언어를 도입하기로 결정했습니다. 그래서 탄생한 것이 브렌던 아이크가 개발한 자바스크립트입니다.
  • Javascript에서는 더글라스 크락포드, 니콜라스 자카스(ES LINT), 존 레식, 브렌던 아이크 4명이 영향력이 있는 사람이라고 합니다.
  • 자바스크립트는 1996년 3월 넷스케이프 커뮤니케이션즈의 웹 브라우저인 Netscape Navigator 2에 탑재되었고 “Mocha”로 명명되었습니다. 그해 9월 “LiveScript”로 이름이 변경되었고, 12월 “JavaScript”로 최종 명명되었습니다.
    • Java와 구문이 유사하기도 하고 해서 이름을 JavaScript로 명명했다…는 표면상의 이유고 그 속은 Java의 유명세를 타서 묻어가려고 의도적으로 만든 것이라고 합니다.
    • 이름의 최종 선정에 혼란이 야기되었는데 이 언어가 자바 프로그래밍 언어에서 파생되었다는 인상을 심었으며 이러한 선택이 마케팅적인 특징을 보였고 이는 넷스케이프가 당시 인기있는 웹 프로그래밍 언어로서 자바스크립트를 내밀기 위한 것이었습니다.
    • 이는 사실 두 언어 모두 C 언어의 기본 구문에 바탕을 뒀기 비슷해 보이는 것이고, 실제로는 자바와 자바스크립트는 직접적인 관련성이 없습니다.
    • 이름과 구문 외에는 자바보다 셀프나 스킴과 유사성이 많습니다.
  • 1996년 8월, 마이크로소프트는 자바스크립트의 파생 버전인 “JScript”를 Internet Explorer 3.0에 탑재하였습니다. 문제의 IE의 등장이네요. 그런데 문제는 JScript와 자바스크립트가 표준화되지 못하고 적당히 호환되었습니다. 즉, 자사 브라우저의 시장 점유율을 점유하기 위해 자사 브라우저에서만 동작하는 기능을 경쟁적으로 추가하기 시작했습니다. 이로 인해 브라우저에 따라 웹 페이지가 정상 동작하지 않는 크로스 브라우징 이슈가 발생하기 시작했고 모든 브라우저에서 동작하는 웹 페이지를 개발하는 것은 무척 어려워졌습니다. 이에 자바스크립트의 파편화를 방지하고 모든 브라우저에서 동일하게 동작하는 표준화된 자바스크립트에 대한 필요성이 제기되기 시작했습니다.
  • 이를 위해 1996년 11월, 비영리 표준화 기구인 ECMA 인터내셔널에 자바스크립트의 표준화를 요청하였다. 1997년 7월, ECMA-262라 불리는 표준화된 자바스크립트 초판(ECMAScript 1)의 명세(specification)가 완성되었고 상표권 문제로 자바스크립트는 ECMAScript로 명명되었습니다.
  • 당시 Sun사가 ‘JAVA‘라는 단어를 상표 등록을 해 놨기에 ‘JavaScript’라고 부를 수 없었습니다.
  • 하지만 대외적으로 알리기 위해서 자바스크립트나 J스크립트라고 불렀다. 나중엔 표준 이나 구현 모두 ‘JavaScript’라는 이름으로 부르고 있습니다.
  • 이후 1999년 ECMAScript 3(ES3)이 공개되었고 10년 만인 2009년 출시된 ECMAScript 5(ES5)는 HTML5와 함께 출현한 표준안입니다. ES4는 사라졌습니다.
  • 2015년에는 ECMAScript 6인 ECMAScript 2015가 공개되었고 범용 프로그래밍 언어로서 갖추어야 할 기능들을 대거 도입하는 큰 변화가 있었다.
  • ES6 이후의 버전업은 작은 기능의 추가 레벨로 매년 공개할 것으로 예고되었다.
  • 흔히 버전을 ES6+ 혹은 ES2015+로 표현하는데 매년 발표하기 때문에 연도를 붙여 말하는 것이 좀 더 권장 사항 입니다.
  • ECMA 표준에 등록되기 위해선 4가지 단계를 통과 할 필요가 있으며 최종 통과가 되지 않아도 바벨을 활용해 이용하거나 타입스크립트가 우선 지원하는 경우도 있습니다.
  • 현재 웹 시장에서도 표준이 되지 않은 기능을 브라우저가 먼저 구현하고 프로포절에 던져놓는 경우가 많다고 합니다.

Javascript의 발전

  • 초창기 자바스크립트는 웹 페이지의 보조적인 기능을 수행하기 위해 한정적인 용도로 사용 되었습니다.
  • 이는 1999년, 자바스크립트를 이용해서 비동기적으로 서버와 브라우저가 데이터를 교환할 수 있는 통신 기능인 Ajax가 XMLHttpRequest이라는 이름으로 등장으로 인해 많은 것이 변화 하였습니다.
  • Ajax의 등장은 이전의 패러다임을 획기적으로 전환했습니다. 웹 페이지의 변경이 필요 없는 부분은 다시 렌더링하지 않고, 서버로부터 필요한 데이터만을 전송 받아 변경이 필요한 부분만을 한정적으로 렌더링하는 방식이 가능해졌습니다. 이로 인해 웹 브라우저에서도 데스크톱 애플리케이션과 유사한 빠른 퍼포먼스와 부드러운 화면 전환이 가능케 되었습니다.
  • 2005년, 구글이 발표한 Google Maps는 웹 애플리케이션 개발 프로그래밍 언어로서 자바스크립트의 가능성을 확인하는 계기를 마련했습니다. 웹 브라우저에서 자바스크립트와 Ajax를 기반으로 동작하는 Google Maps가 데스크톱 애플리케이션과 비교해 손색이 없을 정도의 퍼포먼스와 부드러운 화면 전환 효과를 보여주었습니다.
  • 2006년, jQuery의 등장으로 다소 번거롭고 논란이 있던 DOM(Document Object Model)을 보다 쉽게 제어할 수 있게 되었고 크로스 브라우징 이슈도 어느 정도 해결되었습니다. jQuery는 순식간에 넓은 사용자 층을 확보 했습니다. 이로 인해 당시 다소 까다로운 자바스크립트보다 배우기 쉽고 직관적인 jQuery를 더 선호하는 개발자가 양산되기도 했습니다.
  • 요즘 프론트엔드를 시작한다면 jQuery는 피하는 것이 좋아 보입니다.
  • V8 자바스크립트 엔진의 등장으로 자바스크립트는 데스크톱 애플리케이션과 유사한 사용자 경험(user experience)을 제공할 수 있는 웹 애플리케이션 개발 프로그래밍 언어로 정착하게 되었습니다.
  • V8 자바스크립트 엔진으로 촉발된 자바스크립트의 발전으로 인해 과거 웹 서버에서 수행되던 역할들이 클라이언트(브라우저)로 이동하였고, 이로써 웹 애플리케이션에서 프런트엔드 영역이 주목받는 계기가 되었습니다.
  • 2009년, 브라우저에서만 동작하던 자바스크립트를 브라우저 이외의 환경에서 동작시킬 수 있는 자바스크립트 실행 환경인 Node.js의 등장으로 자바스크립트는 웹 브라우저를 벗어나 서버 사이드 애플리케이션 개발에서도 사용되는 범용 프로그래밍 언어가 되었습니다.
  • 웹 브라우저에서만 동작하는 반쪽짜리 프로그래밍 언어 취급을 받던 자바스크립트는 이제 프런트엔드 영역은 물론 백엔드 영역까지 아우르는 웹 프로그래밍 언어의 표준으로 자리잡고 있습니다. 람다에서 Node를 많이 활용하는 것 같습니다.
  • 자바스크립트는 웹은 물론 모바일 하이브리드 앱, 서버 사이드, 데스크톱, 머신 러닝, 로보틱스 등 프로그래밍 언어로서 세계에서 가장 인기있는 프로그래밍 언어가 되었습니다. 이건 기준이 어디냐에 따라서 많이 다르더라구요. 본인이 믿고 싶은걸 믿으세요 !

Javascript 사용처

  • 웹
  • 모바일 하이브리드 앱(PhoneGap, Ionic)
  • 모바일 하이브리드 앱(NativeScript, React Native)
  • 서버 사이드(NodeJS)
  • 데스크톱(Electron)
  • 머신 러닝(TensorFlow.js)
  • 로보틱스(Johnny-Five)

Javascript 특징

  • 자바스크립트는 웹 브라우저에서 동작하는 유일한 프로그래밍 언어입니다(?) 이제는 확신이 없습니다.
  • 자바스크립트는 개발자가 별도의 컴파일 작업을 수행하지 않는 인터프리터 언어입니다.
  • 인터프리터는 소스코드를 즉시 실행하고 컴파일러는 빠르게 동작하는 머신 코드를 생성하고 최적화합니다. 이를 통해 컴파일 단계에서 추가적인 시간이 필요함에도 불구하고 보다 빠른 코드의 실행이 가능합니다.
  • 자바스크립트는 명령형, 함수형, 프로토타입 기반 객체지향 프로그래밍을 지원하는 멀티 패러다임 프로그래밍 언어입니다.
  • 클래스, 상속, 정보 은닉을 위한 키워드 private가 없어서 객체지향 언어가 아니라고 오해하는 경우도 있지만 자바스크립트는 클래스 기반 객체지향 언어보다 효율적이면서 강력한 프로토타입 기반의 객체지향 언어입니다.
  • 클래스는 ES6에서 추가 되었습니다. 하지만 흔히들 신텍스 슈거로서 클래스를 흉내내고 있을 뿐이라고 하는데 일각에서는
  • 클래스의 추가는 혁신적인 발전을 이뤘다고도 합니다.
  • 또한 자바스크립트는 함수형 프로그래밍에 적합하지 않다고 하는 사람들도 있습니다.
  • 이래저래 말이 많은 언어임은 확실합니다.

백본

  • 백본은 2012 년쯤 혜성같이 등장한 Javascript MV* 프레임워크입니다.
  • 나름 Angular 1 초창기에 대립구조를 가지다가 지금은 인지도가 많이 떨어진 프레임워크입니다.
  • 전통적인 웹 개발 패러다임인 MVC 패턴에서 Controller를 별도로 구분하지 않고, View 에다가 뷰 이벤트 로직을 다 처리할 수 있는 구조 (MV*)로 구성이 되어있습니다.
  • 기본적으로 화면 뒷단과의 통신은 JSON 기반의 REST API를 지원하고 있으며, 별도의 라이브러리들을 함께 구성하여 확장이 되게 편한 형태로 프레임워크가 구성되어 있습니다.
  • 특히 Server Side 통신은 화면에서 간단히 Javascript API 사용했을 때, 기본적인 HTTP Request 요청을 모두 내부적으로 처리하여 Data Model에 담아주기 때문에, 서버 쪽에 관한 지식이 없는 프론트엔드 입문자분들께 더 편한 부분도 있다고 합니다.
  • 배달의 민족으로 유명한 우아한 형제들에서도 Woowahan JS를 Backbone 기반으로 제작하였습니다.
  • 하지만 이전보다는 많이 진일보했지만 아직 프레임워크라고 부르기에는 기능이 조금 부족합니다.
  • Backbone.js가 인기를 끌기 시작할때 제대로 된 프론트엔드 프레임워크들이 등장합니다. Ember, Knockout등이 등장하였는데 예전부터 각자의 프로젝트에서 활용하고 있던 것들을 잘 정리하여 오픈소스로 공개하였습니다. 이러한 프레임워크들은 소스사이즈가 컸고 성능은 무겁고 기능은 복잡하고 러닝커브는 마구 올라갔습니다. 뭔가 좋아보이기는 하는데 쓰기엔 너무 무거워 보였고 굳이 프론트엔드를 MVC로 구성해야 하는 생각도 듭니다.

웹 프론트엔드 3대장

앵귤러

  • 앵귤러는 SPA 개발을 위한 구글의 오픈 소스 자바스크립트 프레임 워크 입니다.
  • 앵귤러는 크게 앵귤러1인 앵귤러제이에스와 앵귤러2이상인 앵귤러로 구분 됩니다.
  • 가장 큰 특징은 RxJS와 typescript를 기본으로 사용하며, 양방향 데이터 바인딩을 하며 리얼 돔을 사용합니다.
  • 강대 했던 앵귤러가 무너진 이유는 후속 버전과의 호완선 문제가 빈번하게 발생하여 많은 혼란을 느껴 앵귤러제이에스 개발자가 앵귤러로 넘어가지 못한 점과 이 그 이후 에도 브레이킹 체인지가 너무 많았다는 점을 꼽곤 합니다.
  • 버전 5 이후부터는 안정된 모습을 보인다고 합니다.
  • 앵귤러는 웹 개발에 필요한 모든 것을 제공하기 때문에 높은 러닝 커브를 가지고 있습니다.

뷰

  • Vue는 Google의 전 개발자 Evan You에 의해 2014년 개발되었습니다.
  • 문법이 단순하고 간결하여 초기 학습 비용이 낮고 누구나 쉽게 접근 가능합니다. 이 때문에 백엔드 개발자들이 어드민 개발에 많이 활용하는 거 같습니다.
  • 대부분 Webpack 같은 모듈 번들러를 사용하여 프로젝트를 구성해야하는 앵귤러와 리액트와 달리, 단순히 CDN 에 있는 파일을 로딩 하는 형태로 스크립트를 불러와서 사용하기도 편합니다.
  • HTML을 템플릿처럼 그대로 사용 할 수도 있어서 마크업을 만들어주는 디자이너/퍼블리셔가 있는 경우 작업 흐름이 매우 매끄럽습니다. 이 부분은 앵귤러1을 차용한거 같습니다.
  • 공식 라우터, 상태관리 라이브러리가 존재합니다.
  • vue라는 확장자를 사용하여 typescript와의 호완성이 좋지 못해서 typescript가 핫해진 근래에 조금 외면을 받은 경향도 있었습니다.
    • 최근 3.0이 나오면서 typescript 지원을 한다고 합니다.
  • 양방향 데이터 바인딩을 기본으로 합니다. 하지만 컴포넌트 간 통신의 기본 골격은 React와 같이 단방향 데이터 흐름(부모 -> 자식)을 사용합니다.
  • 다른 프런트엔드 프레임워크와 비교했을 때 상대적으로 가볍고 빠릅니다.

리액트

  • react는 Facebook이 만든 UI 컴포넌트 라이브러리입니다. 2013 년에 배포되었습니다.
  • MVC 패턴 중 V를 담당하고 있습니다.
  • 컴포넌트 기반 아키텍처를 사용합니다.
  • babel의 도움으로 인해 JSX문법을 사용합니다.
  • Virtual DOM을 사용하여 성능향상을 도모 합니다.
  • 단방향 데이터 흐름 지향 합니다.
  • React는 쉬우나 Redux가 어렵다는 말이 많이 있습니다.
  • 프레임워크가 아닌 뷰라이브러리입니다.
  • HTTP 클라이언트, 라우터, 심화적 상태 관리 등의 기능들은 내장되어있지 않습니다
  • 기본적으로 js를 사용하지만 ts 사용에도 문제가 없습니다. Jsx 확장자는 js와 tsx 확장자는 ts와 완벽히 호환합니다. 또한 라이브러리이기 때문에 다른 프레임워크와 함께 사용하거나 부분만 변경하는데에도 유연하게 적용할 수 있습니다.
  • 최근 리액트 훅스에 도움으로 큰 변화가 생겼으나 리액트에서는 기존 문법을 무기한적으로 지원하기로 했습니다.
  • React의 단방향 데이터 바인딩은 일반적으로 예측 가능성이 높기 때문에 코드가 안정적이며 디버깅이 쉽습니다. 하지만, Angular의 전통적인 양방향 데이터 바인딩 또한 작업하기가 더 단순합니다.
  • 리액트 라이브러리이기 때문에 리액트 라우터, 리덕스, 리덕스 사가, 모벡스, 넥스트 등 다양 서드 파티가 있고 이를 사용성에 맞게 적절하게 사용해야 합니다.

비교글

  • Angular는 모든 것이 준비된 주방으로우리의 Web App에 필요한 모든 tools와 재료들을 가지고 있다.만약 수 많은 개발자들이 일하는 거대한 회사라면,나는 모든 개발자들이 동일한 패턴으로 일을 하는 Angular를 좋아한다.
  • React는 oven (오븐) 이다. 케이크를 굽는 과정에서 분명히 추가적인 tools가 필요하지만 이것은 필요한 것을 만드는 과정에서 tools를 선택하는 유연함을 줄 수 있다. 내가 기술적인 회사에서 능력있는 몇몇 senior 개발자들과 함께 일을 하고 있다면 React는 좋은 선택이다.
  • Vue는 쉽고 효율적인 방법으로 요리를 정말 빠르게 만들 수 있다. 만약 startup 회사에서 새로 생긴 팀에서 엄격한 deadline을 가지고 있다면 나는 VueJS를 좋아할 것이다.

그 외

  • 웹을 개발하기 위해선 프레임워크와 라이브러리들 이외에도 파일을 하나로 모아주는 웹팩, 자바스크립트 버전을 컨트롤 해주는 바벨, 자바스크립트에 부족함을 채워주는 타입스크립트에 대한 공부도 필요합니다.
  • 그리고 서버사이드렌더링과 클라이언트사이드렌더랑과의 차이점과 SPA의 서버사이드 렌더링을 위한 학습도 필요합니다. 이에 따라 결국 서버와 인프라에 대한 공부가 필요 할수도 있습니다.
  • 이 외에도 요즘에 갑작스럽게(?) 떠오른 스벨트, preact도 있습니다.
  • 웹팩을 대신 할지도 모르는 파셀과 RESTAPI의 친구인 그라프큐엘을 지원하기 위한 아폴로에 대한 학습도 필요하게 될 수도 있습니다.
  • 또한 모바일 웹, 반응형 웹, 적응형 웹, 웹뷰에 대한 지원도 필요합니다.
  • 마지막으로 웹이 앱처럼 지원하기 위한 PWA와 PWA를 구글스토어에 배포하게 해주는 TWA라는 기술도 있습니다.

PPT

  • FRONTEND

    [2020.01.11] ‘MASH-UP BACKEND’ 세미나에서 발표한 내용입니다. 프론트엔드를 공부하며 알게 되었던 부분들을 중심으로 HTML부터 React 이후까지 간랸한 이야기를 공유하였습니다.