라벨이 javascript인 게시물 표시

Javascript의 Defer vs async

스크립트는 다운로드 된 후에야 실행될 수 있다. 너무나 당연한 얘기다. 그렇기 때문에 때로는 원하는 순서대로 브라우저가 동작하지 않고 사용자 경험을 떨어뜨릴 수 있는 요인이 되기도 한다. 파싱 도중 script를 만날 때 <script> browser는 HTML을 읽다가  <script></script> 구간을 만나면 script를 먼저 순차적으로 실행하기 위해 파싱을 멈춘다. src 속성이 있는 외부스크립트 <script src="..."></script>를 만났을 경우도 마찬가지다. 이 경우에는 외부 스크립트를 다운받고 실행한 후에야 남은 page를 처리할 수 있다. <script async> 파싱 도중 <script async>를 만나면 문서 파싱 + 스크립트 다운로드를 같이 진행한다. 스크립트는 백그라운드에서 다운된다. 스크립트 다운이 완료되면 파싱을 멈추고 다운받은 스크립트를 실행한다. async의 의미답게 마치 비동기 이벤트처럼 동작한다. 다운받은 스크립트 실행이 끝나면 남은 문서를 마저 파싱한다. 돔이 100% 형성되지 않아서 dom 객체 존재하지 않는 context에서 html 객체를 참조하려고하면 오류를 raise한다. 방문자 수 카운터, 광고 블록과 같은 독립적인 script처럼 실행 순서가 중요하지 않은 경우에 적용한다. <script defer> defer 스크립트 또한 백그라운드에서 스크립트 다운로드를 진행하기 때문에 파싱 작업을 막지 않는다. defer로 받은 script의 실행시점은,  </html>을 만났을 때, 즉, 문서의 끝에 도달했을 때 실행된다. </html> - (실행 시점)  - DOMContentLoaded script를 실행할 때 html 요소들이 반드시 선행적으로 필요한 경우 defer를 사용한다. defer 속성은 기본적으로 true이다. script에 src속성이 없다면 d...

Before handling networking methods in JS

이미지
비동기 통신을 위한 환경, JS Engine 브라우저가 JS를 해석하여 사용하거나 애플리케이션 서버에서 Node.js를 통해 사용할 때 Asynchronous request 처리는 JS 자체가 아닌 JS를 실행하는 환경에서 담당한다. <JS Engine> - Call stack - Microtask queue <Environment support> - Event Loop - Web API - Macrotask queue 즉, JS Engine이 가진 공간인 Heap, Callstack만으로는 비동기 요청을 해결하지 않는다. 예를 들어, 구글 크롬의 V8 JS Engine에서는 함수가 호출될 때, 하나의 Call stack에 순차적으로 보관하고 Last In First Out 순서로 처리하는데 return 될 때, 스택으로부터 pop up할 뿐이다. 스택에 쌓여있는 함수가 실행되는 동안에는 다른 작업이 이를 방해할 수 없는데, 예를 들어,  Bottom |   a   |   b   |   c   | Top 1. C->B 순서로 함수 처리가 완료되었다. 2. A를 실행하려는 찰나, D라는 함수가 호출되어 Call stack에 쌓인다. Bottom |   a   |   d    | Top 3. D->A 순으로 실행한다. 위 예시에서,  D가 실행되는 와중, A의 코드를 실행하다가 다시 D의 Context로 돌아와서 마저 실행하는 작업을 JS 환경에서는 하지 않는다. 즉, 한 함수가 끝날 때까지 다른 작업의 방해를 받지 않는다. 그리고 작업 종류와 스케줄링 방식에 따라 이는 병목이 될 수도 있다. JS Engine은 스케줄링을 위해 다음 환경 2개를 필요로 한다. 비동기 통신을 위한 환경, 이벤트 루프(MacroTask, MicroTask) ...

백엔드 개발자가 Djnago fullstack 사이드 프로젝트를하며 ( html, css, vanillaJS 그리고 JS프레임워크 )

서론 웹 개발 환경에서 FE 개발자와 BE 개발자는 상대의 업무를 서로 이해하게된다면  좀 더 총괄적인 서비스의 흐름과 병목지점을 파악할 수 있다. 때문에 이 둘의 협업 과정은 자연스럽게 Full-stack을 지향하고 있는 과정이라고 생각한다. 24년 12월부터 Django fullstack 사이드 프로젝트를 시작했다. 본론 시행착오 python django 코드 뿐 아니라 html + css + js도 함께 커버하기에 작업에 상당한 context switch가 있었다. 머릿속에 그린 것을 도식화나 문서화하지 않고 무작정 뛰어들었기 때문에  디자인 중인 화면을 확인할 곳이 없었다는 흠이 있었다. 특히 wireframe, 화면설계서가 없으니까  백엔드 작업시 하나의 기능을 완성하기 전까지 제대로 빌드가 되지 않기 때문에  dribble이라는 디자인 사이트를 많이 참고했다. 중복 작업과 반복 작업 중복, 반복 작업 django template language에서 상속을 지원하기 때문에 베이스 템플릿을 상속받아서 페이지를 제작할 수 있다. 템플릿에서 내부에서 여러번 쓰이는 컴포넌트가 불편하다면 공통 컴포넌트를 만들어주면된다. 그러나 컴포넌트를 FE 프레임워크 레벨 정도로 관리하기는 쉽지 않다. 공통 컴포넌트를 관리하려면 프레임워크의 틀을 따라가야하는데 이 시점이 프론트엔드 프레임워크 선정을 할 타이밍이라고 생각한다. JS로 모든 것을 control한다는 것의 간결함 FE UI 프레임워크에서는 html로 작성한 class, id 명을 js에서 검색하여 따르기보다 js로 직접 동적으로 문서 객체를 생성한다. 참조하기도 간편하고 관리하기도 쉽다. js는 bom(부분적으로)과 dom을 컨트롤 할 수 있다. 결론 결국 아주 간결한 landing page 외에는 JS 기반 프레임워크를 사용해야한다. 나는 왜 바로 FE 프레임워크로 뛰어들지 않았나? 더 깊고 가파른 학습을 위해 컴퓨터공학이나 소프트웨어학과의 교육 커리큘럼도 그렇고 프레임워크 이...

이 블로그의 인기 게시물

실무진 면접 경험으로 정리하는 백엔드 (1) : 에듀 테크 기업 면접

Blogger 커스터마이징 : CSS 수정 (sticky-header)

Intel 14th gen CPU의 칩 충돌 사태와 해결 방법