• What is the Future of Front End Web Development?

  • 미래의 프론트 엔드 웹 개발은 어떻게 될까?

  • I was asked to do a little session on this the other day. I'd say I'm underqualified to answer the question, as is any single person. If you really needed hard answers to this question, you'd probably look to aggregate data of survey results from lots of developers.
  • 예전에 이 주제로 작은 발표를 해달라고 요청을 받은 적이 있는데, 여느 사람과 마찬가지로 나는 개인적으로 이 질문에 답할 자격이 없어. 이 질문에 대해 진지한 답을 원한다면, 여러 개발자들의 설문 결과를 모아보는게 나을 듯.
  • I am a little qualified though. Aside from running this site which requires me to think about front end development every day and exposes me to lots of conversations about front end development, I am an active developer myself. I work on CodePen, which is quite a hive of front end developers. I also talk about it every week on ShopTalk Show with a wide variety of guests, and I get to travel all around going to conferences largely focused on front end development.
  • 어쨌든 말할 껀덕지는 있는게, 매일 프론트 엔드 개발에 대해 생각하지 않고서 이 사이트를 운영하는거 자체가 어불성설이고, 그러다 보니 프론트 엔드 개발에 대해 자주 얘기할 기회가 생긴다는 점에서, 나 스스로 열렬한 개발자이기는 함. 지금은 프론트 엔드 개발자들의 성지 중 하나인 코드펜(CodePen)에서 일하고 있고, ShopTalk Show 같은 곳에서 다양한 참가자들과 함께 매주 토론을 하고 다양한 프론트 엔드 개발 관련 컨퍼런스에 참가하는 중.
  • So let me take a stab at it.
  • 그래서 한 마디 해보려고.
  • Again, disclaimers:
  • 다시 한 번 얘기하건데,
  • - This is non-comprehensive
  • - 포괄적인 얘기도 아니고
  • - These are just loose guesses
  • - 예에에에측에 불과하며
  • - I'm just one dude
  • - 그냥 개발자A의 생각이라는 거 잊지 말아주길.
  • #User expectations on the rise.

  • 기대는 점점 커져만 가고.

  • This sets the stage:
  • 결국 이거 때문이지.
  • What websites are being asked to do is rising. Developers are being asked to build very complicated things very quickly and have them work very well and very fast.
  • 웹사이트가 해야하는 일이 넘나 많아져서. 그러다보니 개발자들도 복잡한 것들을 빠르게 만들어야 할 뿐 아니라 결과물도 빠르게 잘 돌아가야하는 상황이 됨.
  • #New JavaScript is here.

  • 새로운 자바스크립트의 시대.

  • As fabulous as jQuery was for us, it's over for new development. And I don't just mean ES6+ has us covered now, but that's true. We got ourselves into trouble by working with the DOM too directly and treating it like like a state store. As I opened with, user expectations, and thus complexity, are on the rise. We need to manage that complexity.
  • jQuery가 있어서 좋긴 했지만, 새 술은 새 부대에 담아야 하니까. ES6+가 당장 현실이라는 건 아니지만 아무튼 그렇게 되겠지. 그동안 상태를 DOM 에 직접 저장하느라 온갖 문제가 생겼는데 요구사항이 많아지고 복잡해지니까 이걸 어떻게든 개선해야겠지.
  • State is the big concept, as we talked about. Websites will be built by thinking of what state needs to be managed, then building the right stores for that state.
  • 계속 얘기해왔지만, 상태(State)가 핵심 컨셉. 앞으로의 웹사이트는 어떤 상태를 관리해야 하는지 생각한 다음에 그 상태를 잘 저장하는 것으로 완성될 것임.
  • note icon
  • The new frameworks are here. Ember, React, Vue, Angular, Svelte, whatever. They accommodate the idea of working with state, components, and handling the DOM for us.
  • 새 프레임웍들이 많지. Ember, React, Vue, Angular, Svelte, 등등등. 이것들 모두가 상태와 컴포넌트, DOM 을 어떻게 다룰지에 대한 생각 끝에 나온 것들임.
  • Now they can compete on speed, features, and API niceity.
  • 이제 속도와 기능, 그리고 API가 얼마나 좋은지로 경쟁하는 중이고.
  • TypeScript also seems like a long-term winner because it can work with whatever and brings stability and a better editor experience for developers.
  • 장기적으로 봤을 때는 TypeScript가 잘 붙고, 안정적이면서 더 좋은 개발 경험을 제공해주니까 대세가 되지 않을까 싶음.
  • #We're not building pages, we're building systems.

  • 단순히 페이지를 만드는게 아니라 시스템을 만드는 것.

  • Style guides. Design systems. Pattern libraries. These things are becoming a standard part of the process for web projects. They will probably become the main deliverable. A system can build whatever is needed. The concept of "pages" is going away. Components are pieced together to build what users see. That piecing together can be done by UX folks, interaction designers, even marketing.
  • 스타일 가이드. 디자인 시스템. 패턴 라이브러리. 이것들이 앞으로의 웹 프로젝트 개발 프로세스의 표준이 될 것. 아마 가장 주요한 것들이 되겠지. 시스템은 필요한 걸 만들어내게 되고. “페이지”라는 개념이 아니라 컴포넌트들이 모여 사용자에게 보여지게 될꺼야. UX 하는 친구들이나, 인터랙션 디자이너, 마케팅하는 사람도 이것들을 조합해서 쓰겠지.
  • New JavaScript accommodates this very well.
  • 새 자바스크립트는 이런 일에 딱이야.
  • #The line between native and web is blurring.

  • 네이티브앱과 웹 구분은 계속 모호해지는 중.

  • Which is better, Sketch or Figma? We judge them by their features, not by the fact that one is a native app and one is a web app. Should I use the Slack or TweetDeck native app, or just open a tab? It's identical either way. Sometimes a web app is so good, I wish it was native just so it could be an icon in my dock and have persistent login, so I use things like Mailplane for Gmail and Paws for Trello.
  • Sketch와 Figma 중에 뭐가 나을까? 기능으로 비교하지 그게 네이티브 앱이냐 웹 앱이냐가 중요하지는 않은 것 같아. 슬랙이랑 트윗댁을 앱으로 쓸까 아니면 그냥 브라우저 탭에서 열까? 어차피 같은데. 웹앱 중에 넘나 좋은 것들은 그냥 항상 로그인 되어서 독에 들어가 있으면 좋겠어. Mailplane for Gmail 과 Paws for Trello 를 그렇게 쓰고 있지.
  • note icon
  • I regularly use apps that seem like they would need to be native apps, but turn to be just as good or better on the web. Just looking at audio/video apps, Skype has a full-featured app, Lightstream is a full-on livestreaming studio, and Zencaster can record multi-track high-quality audio. All of those are right in the browser.
  • 네이티브 앱이여야 더 좋을 것 같은 것들 중에서도 웹 앱이 더 좋은게 있어서 자주 쓰는 앱들이 있음. 오디오/비디오 앱들을 보면, Skype 웹 앱은 훌륭하고, 라이브 스트리밍하는데 쓰는 Lightstream, 고음질 멀티 트랙 오디오 레코더인 Zencaster 같은 것들이 있지. 브라우저에서 완벽하게 동작해.
  • Those are just examples of doing a good job on the web. Web technology itself is stepping up hugely here as well. Service workers give us important things like offline ability and push notifications. Web Audio API. Web Payments API. The web should become the dominant platform for building apps.
  • 이것들은 일부에 불과하고, 웹 기술 자체가 엄청나게 좋아지고 있어. 서비스 워커를 통해서 오프라인 기능과 푸시 알림도 가능하고, 웹 오디오 API, 웹 결제 API 같은 것도 있지. 웹으로 앱 만드는게 분명히 대세가 될꺼야.
  • Users will use things that are good, and not consider or care how it was built.
  • 사용자들은 그냥 좋은걸 찾지 그게 어떻게 만들어졌는지는 별로 상관 안함.
  • #URLs are still a killer feature.

  • URL은 여전히 중요한 핵심 기능이야.

  • The web really got this one right. Having a universal way to jump right to looking at a specific thing is incredible. URLs make search engines possible, potentially one of the most important human innovations ever. URLs makes sharing and bookmarking possible. URLs are a level playing field for marketing. Anybody can visit a URL, there is no gatekeeper.
  • 웹이 진짜 잘한게 하나가 있다면 바로 어떤 것이건 한 방에 점프해서 갈 수 있도록 한 URL이지. URL이 있어서 인류의 발명품 중 갓오브갓인 검색 엔진도 가능했어. 즐겨찾기도 가능하고 마케팅에서도 중요하지. 누구나 URL을 방문할 수 있기 때문인거야.
  • #Performance is a key player.

  • 성능을 신경쓰지 않을 수 없음.

  • Tolerance for poorly performing websites is going to go down. Everyone will expect everything to be near-instant. Sites that aren't will be embarrassing.
  • 웹사이트 성능이 구리면 사람들이 찾지 않아. 사람들은 인내심이 없어서 바로 팍 나오길 원해. 그렇지 않으면 구린거임.
  • #CSS will get much more modular.

  • CSS는 더 모듈화 될꺼고.

  • When we write styles, we will always make a choice. Is this a global style? Am I, on purpose, leaking this style across the entire site? Or, am I writing CSS that is specific to this component? CSS will be split in half between these two. Component-specific styles will be scoped and bundled with the component and used as needed.
  • 스타일을 작성할 때마다 고민했었던 건데, 이게 글로벌(전역) 스타일인가? 같은거. 이걸 일부러 사이트 전체에 적용하는 건가? 아니면 요 부분에만 하는게 맞나? CSS는 이렇게 둘로 쪼개지겠지. 컴포넌트별 스타일이 컴포넌트와 함께 제공되고 필요한 부분에만 사용되게 될꺼야.
  • #CSS preprocessing will slowly fade away.

  • CSS 전처리기들은 이제 빠이빠이 해야지.

  • Many of the killer features of preprocessors have already made it into CSS (variables), or can be handled better by more advanced build processes (imports). The tools that we'll ultimately use to modularize and scope our CSS are still, in a sense, CSS preprocessors, so they may take over the job of whatever is left of preprocessing necessity. Of the standard set of current preprocessors, I would think the main one we will miss is mixins. If native CSS stepped up to implement mixins (maybe @apply) and extends (maybe @extend), that would quicken the deprecation of today's crop of preprocessors.
  • 전처리기가 제공했던 변수 같은 주요 기능들은 이미 CSS에 기본 제공되고 있거나 imports 와 같은 더 좋은 빌드 프로세스로 대체되고 있어. CSS 스타일의 스코프를 지정하고 모듈화 하는 기능은 여전히 전처리기에 남겠지만. 믹스인은 앞으로 표준으로 들여와야 한다고 생각해. 네이티브 CSS가 믹스인(아마도 @apply)과 확장(@extend겠지?)을 들여오면 전처리기는 쓰이지 않게 될 것 같아.
  • #Being good at HTML and CSS remains vital.

  • 여전히 HTML/CSS 잘 하는게 중요하다는 것.

  • The way HTML is constructed and how it ends up in the DOM will continue to change. But you'll still need to know what good HTML looks like. You'll need to know how to structure HTML in such a way that is useful for you, accessible for users, and accomodating to styling.
  • HTML을 생성하고 어떤 DOM으로 구성될 지는 앞으로 계속 바뀌겠지만, 어떤 HTML이 좋은 것인지는 알아야겠지. 사용자에게 유용하고 스타일링하기 좋은 쪽으로 HTML 구조를 만드는 방법은 알아야 할꺼야.
  • The way CSS lands in the browser and how it is applied will continue to change, but you'll still need to how to use it. You'll need to know how to accomplish layouts, manage spacing, adjust typography, and be tasteful, as we always have.
  • 브라우저에서 CSS 가 작동하고 적용되는 방법은 계속 바뀔텐데, 마찬가지로 어떻게 쓰는지는 알아야함. 레이아웃을 작성하고, 간격을 관리하며, 타이포그래피를 조정하고 세련되게 표현하는 방법은 늘 그랬듯 앞으로도 함께할 꺼야.
  • #Build processes will get competitive.

  • 경쟁력이 충만한 빌드 프로세스.

  • Because performance matters so much and there is so much opportunity to get clever with performance, we'll see innovation in getting our code bases to production. Tools like webpack (tree shaking, code splitting) are already doing a lot here, but there is plenty of room to let automated tools work magic on how our code ultimately gets shipped to browsers. Optimizing first payloads. Shipping assets in order of how critical they are. Deciding what gets sent where and how. Shipping nothing whatsoever that isn't used.
  • 성능이 굉장히 중요해졌는데 아직 성능을 개선할 부분은 쎄고 쎄서, we'll see innovation in getting our code bases to production. webpack(tree shaking, code splitting) 같은 도구가 이미 잘 쓰이고 있지만, 자동화 도구를 통해 코드가 브라우저에 전달될 때까지 아직 개선해볼만한 여지는 많이 있음. 처음으로 전달할 덩어리를 최적화하고, 중요도에 따라 어떤 순서대로 보낼지, 어디서 어떻게 보낼지 결정해야 하지. 사용되지 않은건 아예 보내지 않도록 하고.
  • As the web platform evolves (e.g. Client Hints), build processes will adjust and best practices will evolve with it, like they always have.
  • 웹 플랫폼이 진화하면(Client Hints등) 빌드 프로세스도 바뀔꺼고 최선의 방법도 같이 진화하게 됨. 늘 그랬던 것처럼.
0 Comments