2017.12.06에 진행된 W3C HTML5 2017 컨퍼런스에서 발표한 자료입니다. 발표자는 스튜디오씨드의 이웅재님입니다.

1. Electron 과 TypeScript 로 만드는
Visual Studio Code,
그리고 ProtoPie
W3C 2017

2. #Electron #TypeScript
#VSCode #ProtoPie
W3C 2017

3. 안녕하세요! 이웅재 입니다.
Hello! I’m Mark.
W3C 2017

4. - Software Engineer
- ProtoPie Studio Team, StudioXID
- Microsoft MVP
- JavaScript / TypeScript
- 2nd Administrator
- Electron Korea
- Organizer
- TypeScript Korea User Group
- Organizer, Prepare Conference like Pycon
- Seoul.js
W3C 2017

5. W3C 2017
https://www.facebook.com/codebusking.show/

6. 그래서 자네는 무엇을 만들었는가 ??
W3C 2017

7. 어렸을때는 !!!
W3C 2017

8. 어렸을때는 !!!
모바일 어플리케이션을 개발 했습니다.
W3C 2017

9. 어렸을때는 !!!
모바일 어플리케이션을 개발 했습니다.
지금도 어리지만…
W3C 2017

10. 그럼 지금은 ???
W3C 2017

11. 그럼 지금은 ???
데스크탑 어플리케이션을 만들고 있습니다.
W3C 2017

12. 그럼 지금은 ???
데스크탑 어플리케이션을 만들고 있습니다.
macOS 와 Windows 에서 사용하는 툴을 만들고 있습니다.
W3C 2017

13. W3C 2017

14. ProtoPie 는 Electron 으로 만들고 있습니다.
W3C 2017

15. W3C 2017

16. - 데스크탑 어플리케이션을 만드는 용도
MASOCON 2017

17. - 데스크탑 어플리케이션을 만드는 용도
MASOCON 2017
macOS
Windows
Linux

18. - 데스크탑 어플리케이션을 만드는 용도
- HTML / CSS / JavaScript 로 UI 를 만들고,
MASOCON 2017

19. - 데스크탑 어플리케이션을 만드는 용도
- HTML / CSS / JavaScript 로 UI 를 만들고,
MASOCON 2017
Chromium’s content module
(build) => libchromiumcontent

20. - 데스크탑 어플리케이션을 만드는 용도
- HTML / CSS / JavaScript 로 UI 를 만들고,
- JavaScript 로 OS 와 연결된 Electron Api 를 사용하고,
MASOCON 2017

21. - 데스크탑 어플리케이션을 만드는 용도
- HTML / CSS / JavaScript 로 UI 를 만들고,
- JavaScript 로 OS 와 연결된 Electron Api 를 사용하고,
MASOCON 2017

22. - 데스크탑 어플리케이션을 만드는 용도
- HTML / CSS / JavaScript 로 UI 를 만들고,
- JavaScript 로 OS 와 연결된 Electron Api 를 사용하고,
- JavaScript 로 OS 와 연결된 Node.js 를 완전히 사용할 수 있고,
MASOCON 2017

23. - 데스크탑 어플리케이션을 만드는 용도
- HTML / CSS / JavaScript 로 UI 를 만들고,
- JavaScript 로 OS 와 연결된 Electron Api 를 사용하고,
- JavaScript 로 OS 와 연결된 Node.js 를 완전히 사용할 수 있고,
MASOCON 2017

24. - 데스크탑 어플리케이션을 만드는 용도
- HTML / CSS / JavaScript 로 UI 를 만들고,
- JavaScript 로 OS 와 연결된 Electron Api 를 사용하고,
- JavaScript 로 OS 와 연결된 Node.js 를 완전히 사용할 수 있고,
- Node.js 의 (Native 포함) npm 모듈을 이용할 수 있는
MASOCON 2017

25. - 데스크탑 어플리케이션을 만드는 용도
- HTML / CSS / JavaScript 로 UI 를 만들고,
- JavaScript 로 OS 와 연결된 Electron Api 를 사용하고,
- JavaScript 로 OS 와 연결된 Node.js 를 완전히 사용할 수 있고,
- Node.js 의 (Native 포함) npm 모듈을 이용할 수 있는
MASOCON 2017

26. - 데스크탑 어플리케이션을 만드는 용도
- HTML / CSS / JavaScript 로 UI 를 만들고,
- JavaScript 로 OS 와 연결된 Electron Api 를 사용하고,
- JavaScript 로 OS 와 연결된 Node.js 를 완전히 사용할 수 있고,
- Node.js 의 (Native 포함) npm 모듈을 이용할 수 있는
- 그러한 프레임워크
MASOCON 2017

27. - 데스크탑 어플리케이션을 만드는 용도
- HTML / CSS / JavaScript 로 UI 를 만들고,
- JavaScript 로 OS 와 연결된 Electron Api 를 사용하고,
- JavaScript 로 OS 와 연결된 Node.js 를 완전히 사용할 수 있고,
- Node.js 의 (Native 포함) npm 모듈을 이용할 수 있는
- 그러한 프레임워크
MASOCON 2017

28. MASOCON 2017

29. Electron 으로 어떤걸 만들 수 있나요 ??
= Electron 으로 만든건 무엇이 있는가 ??
W3C 2017

30. MASOCON 2017

31. MASOCON 2017

32. MASOCON 2017

33. MASOCON 2017

34. MASOCON 2017

35. MASOCON 2017

36. MASOCON 2017

37. MASOCON 2017

38. MASOCON 2017

39. 하고 싶은거 다 하세요 !!
MASOCON 2017

40. History
어디가서 아는척하기 좋아요
W3C 2017

41. - node-webkit 을 아시나요 ??
W3C 2017

42. - node-webkit 을 아시나요 ?? node-webkit 은 후에 NW.js 가 됩니다.
W3C 2017

43. - node-webkit 을 아시나요 ?? node-webkit 은 후에 NW.js 가 됩니다.
- node-webkit 은 Intel 에서 근무하는 ‘Roger Wang’ 의 주도하에 진행하
고 있던 오픈소스 프로젝트로
W3C 2017

44. - node-webkit 을 아시나요 ?? node-webkit 은 후에 NW.js 가 됩니다.
- node-webkit 은 Intel 에서 근무하는 ‘Roger Wang’ 의 주도하에 진행하
고 있던 오픈소스 프로젝트로
- Node.js 와 Browser Engine 을 이용해 데스크탑 앱을 만들고자 하는 노력
W3C 2017

45. - node-webkit 을 아시나요 ?? node-webkit 은 후에 NW.js 가 됩니다.
- node-webkit 은 Intel 에서 근무하는 ‘Roger Wang’ 의 주도하에 진행하
고 있던 오픈소스 프로젝트로
- Node.js 와 Browser Engine 을 이용해 데스크탑 앱을 만들고자 하는 노력
- ‘Cheng Zhao’ 가 인텔에서 인턴(?ㅋ)하면서 이 프로젝트에 참여
W3C 2017

46. - node-webkit 을 아시나요 ?? node-webkit 은 후에 NW.js 가 됩니다.
- node-webkit 은 Intel 에서 근무하는 ‘Roger Wang’ 의 주도하에 진행하
고 있던 오픈소스 프로젝트로
- Node.js 와 Browser Engine 을 이용해 데스크탑 앱을 만들고자 하는 노력
- ‘Cheng Zhao’ 가 인텔에서 인턴(?ㅋ)하면서 이 프로젝트에 참여
- ‘Cheng Zhao’ 가 깃헙으로 가서 Atom Editor 를 만들기 위해 엔진을 개발
- 그 엔진의 이름은 atom-shell
W3C 2017

47. - node-webkit 을 아시나요 ?? node-webkit 은 후에 NW.js 가 됩니다.
- node-webkit 은 Intel 에서 근무하는 ‘Roger Wang’ 의 주도하에 진행하
고 있던 오픈소스 프로젝트로
- Node.js 와 Browser Engine 을 이용해 데스크탑 앱을 만들고자 하는 노력
- ‘Cheng Zhao’ 가 인텔에서 인턴(?ㅋ)하면서 이 프로젝트에 참여
- ‘Cheng Zhao’ 가 깃헙으로 가서 Atom Editor 를 만들기 위해 엔진을 개발
- 그 엔진의 이름은 atom-shell
- atom-shell 의 이름을 electron 으로 변경하고 본격적으로 오픈소스로 널
리 퍼지기 시작
W3C 2017

48. - node-webkit 을 아시나요 ?? node-webkit 은 후에 NW.js 가 됩니다.
- node-webkit 은 Intel 에서 근무하는 ‘Roger Wang’ 의 주도하에 진행하
고 있던 오픈소스 프로젝트로
- Node.js 와 Browser Engine 을 이용해 데스크탑 앱을 만들고자 하는 노력
- ‘Cheng Zhao’ 가 인텔에서 인턴(?ㅋ)하면서 이 프로젝트에 참여
- ‘Cheng Zhao’ 가 깃헙으로 가서 Atom Editor 를 만들기 위해 엔진을 개발
- 그 엔진의 이름은 atom-shell
- atom-shell 의 이름을 electron 으로 변경하고 본격적으로 오픈소스로 널
리 퍼지기 시작
- MS 에서 electron 을 이용해서 VSCode 를 만들면서 인기를 얻음
W3C 2017

49. - node-webkit 을 아시나요 ?? node-webkit 은 후에 NW.js 가 됩니다.
- node-webkit 은 Intel 에서 근무하는 ‘Roger Wang’ 의 주도하에 진행하
고 있던 오픈소스 프로젝트로
- Node.js 와 Browser Engine 을 이용해 데스크탑 앱을 만들고자 하는 노력
- ‘Cheng Zhao’ 가 인텔에서 인턴(?ㅋ)하면서 이 프로젝트에 참여
- ‘Cheng Zhao’ 가 깃헙으로 가서 Atom Editor 를 만들기 위해 엔진을 개발
- 그 엔진의 이름은 atom-shell
- atom-shell 의 이름을 electron 으로 변경하고 본격적으로 오픈소스로 널
리 퍼지기 시작
- MS 에서 electron 을 이용해서 VSCode 를 만들면서 인기를 얻음
- Slack Desktop 도 일렉트론으로 변경
W3C 2017

50. - node-webkit 을 아시나요 ?? node-webkit 은 후에 NW.js 가 됩니다.
- node-webkit 은 Intel 에서 근무하는 ‘Roger Wang’ 의 주도하에 진행하
고 있던 오픈소스 프로젝트로
- Node.js 와 Browser Engine 을 이용해 데스크탑 앱을 만들고자 하는 노력
- ‘Cheng Zhao’ 가 인텔에서 인턴(?ㅋ)하면서 이 프로젝트에 참여
- ‘Cheng Zhao’ 가 깃헙으로 가서 Atom Editor 를 만들기 위해 엔진을 개발
- 그 엔진의 이름은 atom-shell
- atom-shell 의 이름을 electron 으로 변경하고 본격적으로 오픈소스로 널
리 퍼지기 시작
- MS 에서 electron 을 이용해서 VSCode 를 만들면서 인기를 얻음
- Slack Desktop 도 일렉트론으로 변경
- Electron Meetup 을 하면 GitHub / MS / Slack 의 엔지니어들이 모여
쑥덕쑥덕 가고싶다ㅠ
W3C 2017

51. 장점을 더 소개하자면…
본격 약팔기
W3C 2017

52. - 빠르게 프로젝트가 성장하고 있다.
W3C 2017

53. - 빠르게 프로젝트가 성장하고 있다.
- 개발 속도가 빠르다.
W3C 2017

54. - 빠르게 프로젝트가 성장하고 있다.
- 개발 속도가 빠르다.
- 버그 수정도 빠른 편!! 이다.
W3C 2017

55. - 빠르게 프로젝트가 성장하고 있다.
- 개발 속도가 빠르다.
- 버그 수정도 빠른 편!! 이다.
- 크로미움과 노드의 업데이트에 맞춰 빠르게 수정된다.
W3C 2017

56. - 빠르게 프로젝트가 성장하고 있다.
- 개발 속도가 빠르다.
- 버그 수정도 빠른 편!! 이다.
- 크로미움과 노드의 업데이트에 맞춰 빠르게 수정된다.
- 잘 관리되고 있는 써드 파티 커뮤니티가 함께 성장하고 있다.
W3C 2017

57. - 빠르게 프로젝트가 성장하고 있다.
- 개발 속도가 빠르다.
- 버그 수정도 빠른 편!! 이다.
- 크로미움과 노드의 업데이트에 맞춰 빠르게 수정된다.
- 잘 관리되고 있는 써드 파티 커뮤니티가 함께 성장하고 있다.
- Electron Userland
W3C 2017

58. - 빠르게 프로젝트가 성장하고 있다.
- 개발 속도가 빠르다.
- 버그 수정도 빠른 편!! 이다.
- 크로미움과 노드의 업데이트에 맞춰 빠르게 수정된다.
- 잘 관리되고 있는 써드 파티 커뮤니티가 함께 성장하고 있다.
- Electron Userland
- 현재 일렉트론을 사용하고 있는 다수의 유명 프로젝트로 인해, 실제 상용 레
벨로 서비스하기 위한 준비가 잘되어 있다.
W3C 2017

59. - 빠르게 프로젝트가 성장하고 있다.
- 개발 속도가 빠르다.
- 버그 수정도 빠른 편이다.
- 크로미움과 노드의 업데이트에 맞춰 빠르게 수정된다.
- 잘 관리되고 있는 써드 파티 커뮤니티가 함께 성장하고 있다.
- Electron Userland
- 현재 일렉트론을 사용하고 있는 다수의 유명 프로젝트로 인해, 실제 상용 레
벨로 서비스하기 위한 준비가 잘되어 있다.
- 자동업데이트, 설치, 배포 관련
W3C 2017

60. - 빠르게 프로젝트가 성장하고 있다.
- 개발 속도가 빠르다.
- 버그 수정도 빠른 편이다.
- 크로미움과 노드의 업데이트에 맞춰 빠르게 수정된다.
- 잘 관리되고 있는 써드 파티 커뮤니티가 함께 성장하고 있다.
- Electron Userland
- 현재 일렉트론을 사용하고 있는 다수의 유명 프로젝트로 인해, 실제 상용 레
벨로 서비스하기 위한 준비가 잘되어 있다.
- 자동업데이트, 설치, 배포 관련
- VS Code 는 우리의 표준전과, 심지어 오픈소스
W3C 2017

61. 여기까지만 하면 가면 그냥 약장수 같겠죠 ??
W3C 2017

62. 단점도 많습니다.
W3C 2017

63. - 앱을 만들지도 않았는데 100 MB 가 넘었어요 ㅠ
W3C 2017

64. - 앱을 만들지도 않았는데 100 MB 가 넘었어요 ㅠ
- 물론 요즘은 영화 한편도 수 기가 입니다. 라는 말로 자기 합리화 중
W3C 2017

65. - 앱을 만들지도 않았는데 100 MB 가 넘었어요 ㅠ
- 물론 요즘은 영화 한편도 수 기가 입니다. 라는 말로 자기 합리화 중
- 리소스를 많이 먹어요 ㅠ
W3C 2017

66. - 앱을 만들지도 않았는데 100 MB 가 넘었어요 ㅠ
- 물론 요즘은 영화 한편도 수 기가 입니다. 라는 말로 자기 합리화 중
- 리소스를 많이 먹어요 ㅠ
- 에너지를 많이 쓰는 앱 보시면 대개 일렉트론 앱 입니다.
W3C 2017

67. - 앱을 만들지도 않았는데 100 MB 가 넘었어요 ㅠ
- 물론 요즘은 영화 한편도 수 기가 입니다. 라는 말로 자기 합리화 중
- 리소스를 많이 먹어요 ㅠ
- 에너지를 많이 쓰는 앱 보시면 대개 일렉트론 앱 입니다.
- 이건 뭐 변명의 여지가 없네요.
W3C 2017

68. - 앱을 만들지도 않았는데 100 MB 가 넘었어요 ㅠ
- 물론 요즘은 영화 한편도 수 기가 입니다. 라는 말로 자기 합리화 중
- 리소스를 많이 먹어요 ㅠ
- 에너지를 많이 쓰는 앱 보시면 대개 일렉트론 앱 입니다.
- 이건 뭐 변명의 여지가 없네요.
- 윈도우에서의 사용이 상대적으로 불안정합니다.
W3C 2017

69. - 앱을 만들지도 않았는데 100 MB 가 넘었어요 ㅠ
- 물론 요즘은 영화 한편도 수 기가 입니다. 라는 말로 자기 합리화 중
- 리소스를 많이 먹어요 ㅠ
- 에너지를 많이 쓰는 앱 보시면 대개 일렉트론 앱 입니다.
- 이건 뭐 변명의 여지가 없네요.
- 윈도우에서의 사용이 상대적으로 불안정합니다.
- WPF 나 UWP 같은거랑은 차원이 다릅니다. (당연하겠지만)
W3C 2017

70. - 앱을 만들지도 않았는데 100 MB 가 넘었어요 ㅠ
- 물론 요즘은 영화 한편도 수 기가 입니다. 라는 말로 자기 합리화 중
- 리소스를 많이 먹어요 ㅠ
- 에너지를 많이 쓰는 앱 보시면 대개 일렉트론 앱 입니다.
- 이건 뭐 변명의 여지가 없네요.
- 윈도우에서의 사용이 상대적으로 불안정합니다.
- WPF 나 UWP 같은거랑은 차원이 다릅니다. (당연하겠지만)
- 태생적 한계를 극복하긴 어렵지만, 그래도 계속 나아지고는 있습니다.
W3C 2017

71. - 앱을 만들지도 않았는데 100 MB 가 넘었어요 ㅠ
- 물론 요즘은 영화 한편도 수 기가 입니다. 라는 말로 자기 합리화 중
- 리소스를 많이 먹어요 ㅠ
- 에너지를 많이 쓰는 앱 보시면 대개 일렉트론 앱 입니다.
- 이건 뭐 변명의 여지가 없네요.
- 윈도우에서의 사용이 상대적으로 불안정합니다.
- WPF 나 UWP 같은거랑은 차원이 다릅니다. (당연하겠지만)
- 태생적 한계를 극복하긴 어렵지만, 그래도 계속 나아지고는 있습니다.
- 소스보호를 공식적으로 제공하지 않습니다.
W3C 2017

72. - 앱을 만들지도 않았는데 100 MB 가 넘었어요 ㅠ
- 물론 요즘은 영화 한편도 수 기가 입니다. 라는 말로 자기 합리화 중
- 리소스를 많이 먹어요 ㅠ
- 에너지를 많이 쓰는 앱 보시면 대개 일렉트론 앱 입니다.
- 이건 뭐 변명의 여지가 없네요.
- 윈도우에서의 사용이 상대적으로 불안정합니다.
- WPF 나 UWP 같은거랑은 차원이 다릅니다. (당연하겠지만)
- 태생적 한계를 극복하긴 어렵지만, 그래도 계속 나아지고는 있습니다.
- 소스보호를 공식적으로 제공하지 않습니다.
- 저한테 일렉트론 앱 소스 깔수 있냐고 물으신다면 거의 그렇다고 할수 있습
니다.
W3C 2017

73. - 앱을 만들지도 않았는데 100 MB 가 넘었어요 ㅠ
- 물론 요즘은 영화 한편도 수 기가 입니다. 라는 말로 자기 합리화 중
- 리소스를 많이 먹어요 ㅠ
- 에너지를 많이 쓰는 앱 보시면 대개 일렉트론 앱 입니다.
- 이건 뭐 변명의 여지가 없네요.
- 윈도우에서의 사용이 상대적으로 불안정합니다.
- WPF 나 UWP 같은거랑은 차원이 다릅니다. (당연하겠지만)
- 태생적 한계를 극복하긴 어렵지만, 그래도 계속 나아지고는 있습니다.
- 소스보호를 공식적으로 제공하지 않습니다.
- 저한테 일렉트론 앱 소스 깔수 있냐고 물으신다면 거의 그렇다고 할수 있습
니다.
- Seoul.js 밋업에서 발표한 소스 보호 방법 자료
- https://slides.com/woongjae/protecting-javascript-source-
code-in-electron
- 얻는게 있으면, 버리는게 생기기 마련, 성능을 포기해야할 수 있습니다.
W3C 2017

74. Visual Studio Code 는
완성도가 높다고 알려져 있습니다.
W3C 2017

75. Visual Studio Code 는
완성도가 높다고 알려져 있습니다.
반대하시는 분 ??
W3C 2017

76. Visual Studio Code 는
완성도가 높다고 알려져 있습니다.
반대하시는 분 ??
그럼 할수 없구요 ㅠ
W3C 2017

77. 그럼 우리만 잘하면…
W3C 2017

78. 그럼 우리만 잘하면…
완성도 쩌는 슈퍼 울트라 멋진
데스크탑 어플리케이션을 만들 수 있습니다.
W3C 2017

79. W3C 2017

80. W3C 2017

81. W3C 2017

82. - Electron 을 개발할때는 자연스럽게 es6 를 사용하면 됩니다.
W3C 2017

83. - Electron 을 개발할때는 자연스럽게 es6 를 사용하면 됩니다.
- 최근 버전에서는 es7 인 async-await 도 포함되어 있습니다.
W3C 2017

84. - Electron 을 개발할때는 자연스럽게 es6 를 사용하면 됩니다.
- 최근 버전에서는 es7 인 async-await 도 포함되어 있습니다.
- 바벨 같은걸 쓸 필요가 별로 없습니다.
W3C 2017

85. - Electron 을 개발할때는 자연스럽게 es6 를 사용하면 됩니다.
- 최근 버전에서는 es7 인 async-await 도 포함되어 있습니다.
- 바벨 같은걸 쓸 필요가 별로 없습니다.
- 예외 사항은 많이 있지만… 일단 패스
W3C 2017

86. - Electron 을 개발할때는 자연스럽게 es6 를 사용하면 됩니다.
- 최근 버전에서는 es7 인 async-await 도 포함되어 있습니다.
- 바벨 같은걸 쓸 필요가 별로 없습니다.
- 예외 사항은 많이 있지만… 일단 패스
- 데스크탑 앱은 일반적으로 랜더러 프로세스를 SPA 처럼 만들고,
W3C 2017

87. - Electron 을 개발할때는 자연스럽게 es6 를 사용하면 됩니다.
- 최근 버전에서는 es7 인 async-await 도 포함되어 있습니다.
- 바벨 같은걸 쓸 필요가 별로 없습니다.
- 예외 사항은 많이 있지만… 일단 패스
- 데스크탑 앱은 일반적으로 랜더러 프로세스를 SPA 처럼 만들고,
- 메인 프로세스는 노드 서버처럼 만듭니다.
W3C 2017

88. - Electron 을 개발할때는 자연스럽게 es6 를 사용하면 됩니다.
- 최근 버전에서는 es7 인 async-await 도 포함되어 있습니다.
- 바벨 같은걸 쓸 필요가 별로 없습니다.
- 예외 사항은 많이 있지만… 일단 패스
- 데스크탑 앱은 일반적으로 랜더러 프로세스를 SPA 처럼 만들고,
- 메인 프로세스는 노드 서버처럼 만듭니다.
- 데스크탑 앱을 만들기 위해서 사용하는 소스파일의 수가 어마어마하게 많아
져서, 관리하기가 너무나도 어렵고, 복잡해질 수 있습니다.
W3C 2017

89. - Electron 을 개발할때는 자연스럽게 es6 를 사용하면 됩니다.
- 최근 버전에서는 es7 인 async-await 도 포함되어 있습니다.
- 바벨 같은걸 쓸 필요가 별로 없습니다.
- 예외 사항은 많이 있지만… 일단 패스
- 데스크탑 앱은 일반적으로 랜더러 프로세스를 SPA 처럼 만들고,
- 메인 프로세스는 노드 서버처럼 만듭니다.
- 데스크탑 앱을 만들기 위해서 사용하는 소스파일의 수가 어마어마하게 많아
져서, 관리하기가 너무나도 어렵고, 복잡해질 수 있습니다.
- 그래서 타입스크립트 도입 !!!
W3C 2017

90. W3C 2017

91. W3C 2017

92. - 메인 프로세스와 랜더러 프로세스는 실제로 프로세스가 다릅니다.
W3C 2017

93. - 메인 프로세스와 랜더러 프로세스는 실제로 프로세스가 다릅니다.
- 두 프로세스 사이를 연결하기 위해 ipc 와 remote 라는 개념을 씁니다.
W3C 2017

94. - 메인 프로세스와 랜더러 프로세스는 실제로 프로세스가 다릅니다.
- 두 프로세스 사이를 연결하기 위해 ipc 와 remote 라는 개념을 씁니다.
- ipc 는 실제 프로세스가 다르기 때문에 다른 프로세스에서 사용하는 같은 형
태의 타입들을 제대로 표현하고 사용할 필요가 있습니다.
W3C 2017

95. - 메인 프로세스와 랜더러 프로세스는 실제로 프로세스가 다릅니다.
- 두 프로세스 사이를 연결하기 위해 ipc 와 remote 라는 개념을 씁니다.
- ipc 는 실제 프로세스가 다르기 때문에 다른 프로세스에서 사용하는 같은 형
태의 타입들을 제대로 표현하고 사용할 필요가 있습니다.
- 메인에서 보낸 오브젝트에 있는 줄 알았는데 없는 프로퍼티를 랜더러에서 접
근해서 사용하려면 런타임 에러!
W3C 2017

96. - 메인 프로세스와 랜더러 프로세스는 실제로 프로세스가 다릅니다.
- 두 프로세스 사이를 연결하기 위해 ipc 와 remote 라는 개념을 씁니다.
- ipc 는 실제 프로세스가 다르기 때문에 다른 프로세스에서 사용하는 같은 형
태의 타입들을 제대로 표현하고 사용할 필요가 있습니다.
- 메인에서 보낸 오브젝트에 있는 줄 알았는데 없는 프로퍼티를 랜더러에서 접
근해서 사용하려면 런타임 에러!
- 런타임 에러를 미리 방어하기 위해 타입시스템을 이용하는게 핵심입니다.
W3C 2017

97. TypeScript = Language
W3C 2017

98. W3C 2017

99. 컴파일러
= TypeScript Compiler
= tsc
= 타입스크립트를 자바스크립트로 바꿔주는 프로그램
W3C 2017

100. W3C 2017

101. - TypeScript 를 컴파일하면 JavaScript 소스가 나옵니다.
W3C 2017

102. - TypeScript 를 컴파일하면 JavaScript 소스가 나옵니다.
- JavaScript 를 해석할수 있는 곳에서는 전부 사용이 가능합니다.
W3C 2017

103. - TypeScript 를 컴파일하면 JavaScript 소스가 나옵니다.
- JavaScript 를 해석할수 있는 곳에서는 전부 사용이 가능합니다.
- TypeScript 는 2가지가 핵심입니다.
W3C 2017

104. - TypeScript 를 컴파일하면 JavaScript 소스가 나옵니다.
- JavaScript 를 해석할수 있는 곳에서는 전부 사용이 가능합니다.
- TypeScript 는 2가지가 핵심입니다.
- JavaScript 에 없는? 스펙을 사용할 수 있습니다.
W3C 2017

105. - TypeScript 를 컴파일하면 JavaScript 소스가 나옵니다.
- JavaScript 를 해석할수 있는 곳에서는 전부 사용이 가능합니다.
- TypeScript 는 2가지가 핵심입니다.
- JavaScript 에 없는? 스펙을 사용할 수 있습니다.
- 어떤 스펙을 사용할지 말지는 TypeScript 에서 관리합니다.
W3C 2017

106. - TypeScript 를 컴파일하면 JavaScript 소스가 나옵니다.
- JavaScript 를 해석할수 있는 곳에서는 전부 사용이 가능합니다.
- TypeScript 는 2가지가 핵심입니다.
- JavaScript 에 없는? 스펙을 사용할 수 있습니다.
- 어떤 스펙을 사용할지 말지는 TypeScript 에서 관리합니다.
- 확정되지 않은 스펙을 미리 넣고 표준해달라고 조르기도 하고, (영향력이
높아져서)
W3C 2017

107. - TypeScript 를 컴파일하면 JavaScript 소스가 나옵니다.
- JavaScript 를 해석할수 있는 곳에서는 전부 사용이 가능합니다.
- TypeScript 는 2가지가 핵심입니다.
- JavaScript 에 없는? 스펙을 사용할 수 있습니다.
- 어떤 스펙을 사용할지 말지는 TypeScript 에서 관리합니다.
- 확정되지 않은 스펙을 미리 넣고 표준해달라고 조르기도 하고, (영향력이
높아져서)
- 확정된 스펙을 빨리 넣기도 합니다.
W3C 2017

108. - TypeScript 를 컴파일하면 JavaScript 소스가 나옵니다.
- JavaScript 를 해석할수 있는 곳에서는 전부 사용이 가능합니다.
- TypeScript 는 2가지가 핵심입니다.
- JavaScript 에 없는? 스펙을 사용할 수 있습니다.
- 어떤 스펙을 사용할지 말지는 TypeScript 에서 관리합니다.
- 확정되지 않은 스펙을 미리 넣고 표준해달라고 조르기도 하고, (영향력이
높아져서)
- 확정된 스펙을 빨리 넣기도 합니다.
- 혹은 프로그래밍에 도움이 되는 스펙을 자체적으로 결정하여 넣기도 합니
다.
W3C 2017

109. - TypeScript 를 컴파일하면 JavaScript 소스가 나옵니다.
- JavaScript 를 해석할수 있는 곳에서는 전부 사용이 가능합니다.
- TypeScript 는 2가지가 핵심입니다.
- JavaScript 에 없는? 스펙을 사용할 수 있습니다.
- 어떤 스펙을 사용할지 말지는 TypeScript 에서 관리합니다.
- 확정되지 않은 스펙을 미리 넣고 표준해달라고 조르기도 하고, (영향력이
높아져서)
- 확정된 스펙을 빨리 넣기도 합니다.
- 혹은 프로그래밍에 도움이 되는 스펙을 자체적으로 결정하여 넣기도 합니
다.
- 타입 시스템이 핵심입니다.
W3C 2017

110. - TypeScript 를 컴파일하면 JavaScript 소스가 나옵니다.
- JavaScript 를 해석할수 있는 곳에서는 전부 사용이 가능합니다.
- TypeScript 는 2가지가 핵심입니다.
- JavaScript 에 없는? 스펙을 사용할 수 있습니다.
- 어떤 스펙을 사용할지 말지는 TypeScript 에서 관리합니다.
- 확정되지 않은 스펙을 미리 넣고 표준해달라고 조르기도 하고, (영향력이
높아져서)
- 확정된 스펙을 빨리 넣기도 합니다.
- 혹은 프로그래밍에 도움이 되는 스펙을 자체적으로 결정하여 넣기도 합니
다.
- 타입 시스템이 핵심입니다.
- 그래서 타입스크립트의 언어 스펙은 딱 3가지로 갈립니다.
W3C 2017

111. - TypeScript 를 컴파일하면 JavaScript 소스가 나옵니다.
- JavaScript 를 해석할수 있는 곳에서는 전부 사용이 가능합니다.
- TypeScript 는 2가지가 핵심입니다.
- JavaScript 에 없는? 스펙을 사용할 수 있습니다.
- 어떤 스펙을 사용할지 말지는 TypeScript 에서 관리합니다.
- 확정되지 않은 스펙을 미리 넣고 표준해달라고 조르기도 하고, (영향력이
높아져서)
- 확정된 스펙을 빨리 넣기도 합니다.
- 혹은 프로그래밍에 도움이 되는 스펙을 자체적으로 결정하여 넣기도 합니
다.
- 타입 시스템이 핵심입니다.
- 그래서 타입스크립트의 언어 스펙은 딱 3가지로 갈립니다.
- 자바스크립트 표준 스펙이거나 (높은 것 포함)
- 타입에 관련된 스펙이거나
- 프로그래밍에 도움이 될만한 스펙이거나
W3C 2017

112. - Babel 은 자바스크립트 사용에 있어서 거의 표준에 가까운 기술이 되었습니
다.
W3C 2017

113. - Babel 은 자바스크립트 사용에 있어서 거의 표준에 가까운 기술이 되었습니
다.
- 그런데 TypeScript 는 못믿겠어라는 분들은 잉??
W3C 2017

114. - Babel 은 자바스크립트 사용에 있어서 거의 표준에 가까운 기술이 되었습니
다.
- 그런데 TypeScript 는 못믿겠어라는 분들은 잉??
- 게다가 이 오픈소스는 MS 에서 관리되고 있습니다.
W3C 2017

115. 어우 귀찮아 !!
W3C 2017

116. - 매번 타입스크립트 파일을 수정하고, 컴파일 프로그램 돌리고, 컴파일 에러있
나 보고
MASOCON 2017

117. - 매번 타입스크립트 파일을 수정하고, 컴파일 프로그램 돌리고, 컴파일 에러있
나 보고
- 인간은 도구를 사용하는 동물입니다.
MASOCON 2017

118. - 매번 타입스크립트 파일을 수정하고, 컴파일 프로그램 돌리고, 컴파일 에러있
나 보고
- 인간은 도구를 사용하는 동물입니다.
- VS Code
- IntelliJ
- Atom
MASOCON 2017

119. - 매번 타입스크립트 파일을 수정하고, 컴파일 프로그램 돌리고, 컴파일 에러있
나 보고
- 인간은 도구를 사용하는 동물입니다.
- VS Code
- IntelliJ
- Atom
- 이런것들을 이용하면 엄청나게 쉽고 편하게 사용이 가능합니다.
MASOCON 2017

120. W3C 2017

121. 메인
프로세스
랜더러
프로세스
common/type.ts
interface A 에서
타입 정의
ipc 를 통해 이동하는 객체
a: A
{…}
W3C 2017

122. - 당연히 같은 프로세스 내에서의 타입 체크도 도움이 되지만,
W3C 2017

123. - 당연히 같은 프로세스 내에서의 타입 체크도 도움이 되지만,
- 다른 프로세스 간에 큰 도움이 된다.
W3C 2017

124. - 당연히 같은 프로세스 내에서의 타입 체크도 도움이 되지만,
- 다른 프로세스 간에 큰 도움이 된다.
- 런타임 오류를 컴파일 타임에 100% 막는다는 것은 개뻥
W3C 2017

125. - 당연히 같은 프로세스 내에서의 타입 체크도 도움이 되지만,
- 다른 프로세스 간에 큰 도움이 된다.
- 런타임 오류를 컴파일 타임에 100% 막는다는 것은 개뻥
- 타입이 있으니깐 테스트를 하지 않아도 된다는 것도 개뻥
W3C 2017

126. - 당연히 같은 프로세스 내에서의 타입 체크도 도움이 되지만,
- 다른 프로세스 간에 큰 도움이 된다.
- 런타임 오류를 컴파일 타임에 100% 막는다는 것은 개뻥
- 타입이 있으니깐 테스트를 하지 않아도 된다는 것도 개뻥
- 타입 체크는 컴파일 타임에 타입 오류를 체크해 준다
W3C 2017

127. - 당연히 같은 프로세스 내에서의 타입 체크도 도움이 되지만,
- 다른 프로세스 간에 큰 도움이 된다.
- 런타임 오류를 컴파일 타임에 100% 막는다는 것은 개뻥
- 타입이 있으니깐 테스트를 하지 않아도 된다는 것도 개뻥
- 타입 체크는 컴파일 타임에 타입 오류를 체크해 준다
- 테스트는 런타임에 오류를 체크할 수 있다.
W3C 2017

128. - 당연히 같은 프로세스 내에서의 타입 체크도 도움이 되지만,
- 다른 프로세스 간에 큰 도움이 된다.
- 런타임 오류를 컴파일 타임에 100% 막는다는 것은 개뻥
- 타입이 있으니깐 테스트를 하지 않아도 된다는 것도 개뻥
- 타입 체크는 컴파일 타임에 타입 오류를 체크해 준다
- 테스트는 런타임에 오류를 체크할 수 있다.
- 결정적으로 테스트 코드를 짤때 첫번째로 하는 일은 컴파일 오류를 없애는
일이다.
W3C 2017

129. - 당연히 같은 프로세스 내에서의 타입 체크도 도움이 되지만,
- 다른 프로세스 간에 큰 도움이 된다.
- 런타임 오류를 컴파일 타임에 100% 막는다는 것은 개뻥
- 타입이 있으니깐 테스트를 하지 않아도 된다는 것도 개뻥
- 타입 체크는 컴파일 타임에 타입 오류를 체크해 준다
- 테스트는 런타임에 오류를 체크할 수 있다.
- 결정적으로 테스트 코드를 짤때 첫번째로 하는 일은 컴파일 오류를 없애는
일이다.
- 컴파일 오류를 없앤다고, 테스트가 통과하는 것이 아니다.
W3C 2017

130. ProtoPie 를 Electron 으로 만들게 된 이유
W3C 2017

131. - 웹개발자가 많았어요.
W3C 2017

132. - 웹개발자가 많았어요.
- DOM 을 극한까지 다뤄본 엔지니어들이 많이 있었어요.
W3C 2017

133. - 웹개발자가 많았어요.
- DOM 을 극한까지 다뤄본 엔지니어들이 많이 있었어요.
- 어마어마하게 많은 UI 레퍼런스가 있습니다. 정작 필요한건 없을때도 많음
W3C 2017

134. - 웹개발자가 많았어요.
- DOM 을 극한까지 다뤄본 엔지니어들이 많이 있었어요.
- 어마어마하게 많은 UI 레퍼런스가 있습니다. 정작 필요한건 없을때도 많음
- 미리 만들던 웹서비스 용 코드들이 있었음.
W3C 2017

135. - 웹개발자가 많았어요.
- DOM 을 극한까지 다뤄본 엔지니어들이 많이 있었어요.
- 어마어마하게 많은 UI 레퍼런스가 있습니다. 정작 필요한건 없을때도 많음
- 미리 만들던 웹서비스 용 코드들이 있었음.
- 크로스플랫폼의 장점
W3C 2017

136. - 웹개발자가 많았어요.
- DOM 을 극한까지 다뤄본 엔지니어들이 많이 있었어요.
- 어마어마하게 많은 UI 레퍼런스가 있습니다. 정작 필요한건 없을때도 많음
- 미리 만들던 웹서비스 용 코드들이 있었음.
- 크로스플랫폼의 장점
- 리소스 문제나 용량 문제, 불안정한 상황에도 불구하고 대부분의 유저들이 만
족할만한 결과물을 굉장히 빠르게 만들수 있습니다.
W3C 2017

137. - Electron 101
- http://slides.com/woongjae/electron-basic#/
- Electron 으로 채팅앱 만들기
- https://github.com/ts-korea/electron-with-typescript
- Electron 자동 업데이트 구축기
- http://slides.com/woongjae/electron-server#/
- Electron 소스보호
- http://slides.com/woongjae/protecting-javascript-source-
code-in-electron#/
- Electron 패키징 머신 구축기
- http://slides.com/woongjae/playnode2017#/
W3C 2017

138. - TypeScript 101
- https://www.youtube.com/playlist?list=PLV6pYUAZ-
ZoEBNDzOxzToMqv-V1QGlU0T
- TypeScript 로 React 사용하기
- https://www.youtube.com/playlist?list=PLV6pYUAZ-
ZoHx0OjUduzaFSZ4_cUqXLm0
- TypeScript 로 Electron 사용하기
- http://slides.com/woongjae/electron-with-typescript-1#/
- http://slides.com/woongjae/electron-with-typescript-2#/
- http://slides.com/woongjae/electron-with-typescript-3#/
- http://slides.com/woongjae/electron-with-typescript-4#/
W3C 2017

139. 감사합니다.
W3C 2017