쉐도잉 연습: We've got separation of concerns wrong - 영상으로 영어 말하기 배우기

연습 모드 선택

각 모드는 전체 화면 연습실로 열립니다.

151 문장

문장이 너무 짧거나 길면 Edit를 눌러 조정하세요.

People like to talk about the separation of concerns, especially when it comes to web development, in a really rigid way.

HTML is for the content, CSS is for making things look pretty, and JavaScript is for handling the behavior and everything else that we can't do with those other things, I guess.

But the fun thing, at least in my experience being a CSS guy, is most of the time when I hear people saying, Oh, separation of concerns, you shouldn't be doing it that way, comes up when somebody is going,

Oh, you shouldn't be using CSS for that, that's the job of JavaScript.

but then they often ignore all the things they're doing with JavaScript that probably should be done by CSS.

And this happens, or has at least happened for a long time now, because we just didn't have a choice.

There was a lot of things that you couldn't do with CSS, so you had to do it with JavaScript, and that sort of just stuck around a lot.

And there's some things that slowly shifts and moves around a little bit, and we get new things in CSS that nobody's complaining about, like, I don't know, anchor positioning, scroll driven animations.

I think we realize that's just styling related.

So that's completely fine.

But as CSS is getting all of these new features and becoming more powerful, especially in my comments section and just through conversations I've had with developers,

I keep hearing that CSS is starting to overstep its bounds.

And so much so that it actually inspired my talk that I just got back from at CSS Day, which was an absolute blast.

So much fun.

So amazing seeing so many people.

But yeah, it was I got inspired at least partially for what I was talking about in

that one where I was actually saying, well, things are going to change.

We're going to push more towards CSS and why that's actually a good idea in my talk.

But one thing that actually came up was Jeremy Keith came to see me and he was like, oh, Kevin, a really good talk, awesome stuff.

But I wanted to let you know that this conversation has been going on forever, which I sort of I'm aware of, but not to the extent that he let me know about because he actually put a blog post out in 2004.

So it's 22 years ago, which is crazy, where this whole separation of concerns thing was coming up

because hover was part of css and whether

or not it should only be for links or

if you could use hover anywhere

and people were like oh wait hover hover should be the

world of javascript that's behavior you're you're what the user's doing on the page

that shouldn't be on css i'll put a link to his article in the description

because it is kind of cool to like look back on on these types of conversations i think

and it's just it's funny how i guess it just never goes away

but i think the main thing is with all of this

is like clearly I think most people these days see hover as a styling related thing.

Yes, it's behavior, but it's also style.

And I think that's the whole problem with separation of concerns in the first place.

The idea of HTML, CSS, and JavaScript being these three things where we're separating into content styling and logic and behavior and all of that,

I think is just flawed.

And I don't think it really even encapsulates the idea of what separation of concerns is

when it comes to programming in general, where it's mostly about simplifying things.

Now, you see this in JavaScript.

If you're doing good, you're writing good JavaScript, you're separating things as much as possible, right?

You want one function to do one thing and not handle seven different things.

That's separation of concerns.

And that's something we should be doing when you're writing JavaScript or any language whatsoever.

But somehow we got this idea of HTML being content, CSS being styles, and JavaScript being the rest, right?

But the problem was JavaScript just filled in all the blanks

of the things we haven't been able to do with the other languages.

And now that things are changing, people are like, oh, a separation of concerns.

That's not how we should be doing things.

And it's like, no, it's not how we should be doing things.

It's, well, we haven't been doing it that way before because we had no other choice.

And it's just, there's this evolution that's going to continue to happen.

And I really think that we shouldn't be worried about it in that way because there is so much overlap.

A scroll driven animation, for example, is behavior.

It's the user scrolling on the page, going up and down, just like a hover would be.

So should that be in JavaScript or should that be in CSS only?

Well, I think it makes a lot of sense to be in CSS only.

I think anyone who's written the JavaScript to create scroll driven animations is probably happy it's only in CSS now

because it simplifies our life so much going from a lot of code to a few lines of CSS.

But it also increases performance

because we're not relying on JavaScript to be constantly figuring things out

and tracking our scroll position everywhere we're going and relaying

that over to our styles and updating inline styles and all of that.

It's a lot of work and now we can just let the browser pass that information directly through.

And to me, that is separation of concerns.

In a big way, we're simplifying things.

We're getting the information directly from the browser.

Invoker commands are very similar, right?

An invoker command allows us to open a modal or a dialog without any JavaScript.

You make a button, you make a dialog, you link them with a couple of attributes, which makes sense.

That's the realm of content.

Let's connect them through an attribute.

I don't see anything wrong with that.

We used to have to do the exact same thing in JavaScript, but you'd make your two elements, go and find them and then link them.

Why not just do that?

So we're simplifying the problem.

We're separating the concerns.

We're saying this button and this dialog or this modal are connected to one another.

We've simplified the matter.

And then when it opens, we style what it looks like with CSS.

Why do we need JavaScript?

We don't.

And it's not because it's behavior related, it's because we're trying to simplify the situation.

And we're making this button and thing that's being opened into this self-contained thing.

That's separation of concerns.

And sometimes with an invoker command, you might need some JavaScript.

And that's completely fine.

That API is available to do some extra things with, including creating custom commands.

Because I believe we can only do modals and popovers with the built-in invoker commands, but we can create custom ones for other types of things you might want to do.

Maybe a button to play a video or go full screen or other things like that, that for whatever reason you need your own button for, where you can make an invoker command for that now.

And that just simplifies everybody's life.

And a little bit of JavaScript is there just to actually add that extra functionality into there, but it's all part of that same system.

And I think looking at things in that way makes a lot more sense.

But instead of getting all excited about how we're starting to simplify things in many ways, in other ways, the web is getting more complicated

because of all of these things that are coming in and these new capabilities that we do have.

But there is a simplification in another way.

I don't know.

Maybe that's a topic for another day.

But instead of getting excited about, yeah, that's really cool.

People are like, oh, you shouldn't be opening a button with HTML.

You know, separation of concerns.

100

This is a problem.

101

And well, is it really, though, making life easier?

102

Is it a problem?

103

or is it just that they're not happy

104

that we're doing it in a different way than they've been told this is how we do things

105

and then they get frustrated and they say this is the wrong direction that things shouldn't be going that way.

106

I think just because we've been so trained on thinking of HTML, CSS and JavaScript in the buckets we have been.

107

And even if you think of it in more of a component-based system, you have your component file and all of the stuff for that component lives in that one file.

108

That's a separation of concerns in many ways

109

And that's why I think component based architectures become so popular because we're keeping everything self-contained, which makes a lot of sense.

110

But then what each one of the languages is doing there, it's handling its job.

111

But again, there's this gray zone, the overlap between what's behavior, what's styling, when should it be styling related, when should it be the behavior as much as possible.

112

I'm a strong believer being a CSS person that if this logic

113

or anything related to what's happening changes how the user sees it, it's updating the visual of it, well then as much of that should be done in CSS.

114

Because to me that makes sense, that's its domain.

115

But again, maybe I'm getting stuck there, I don't know.

116

Maybe it's just because I like CSS a lot.

117

But yeah, if we look at things more in that context, I think that's more of what separation of concerns should be, where we're looking at the element,

118

we're doing it as simply as possible within those languages that we have and in the way those work, instead of being so focused on, well, this is for this one purpose, this is for this other purpose.

119

And this all does raise another question, though, that I'm not too sure about.

120

And this is the one part in these videos I've started asking for what you guys think

121

and the comment sections have been fantastic.

122

So we're going to continue that on this

123

because I don't know what the answer is in terms of how AI is going to impact everything.

124

I wanted to make sure this video wasn't AI focused, but I do have a question on how you think this will be impacted

125

because AI has been trained on like millions of lines of code the way things have traditionally been done.

126

And the web's changed a lot in the last like two years.

127

There's a lot of features that are coming, invoker commands, popovers, dialogues all these things, the modals that we have now,

128

scroll-driven animations, anchor positioning, the list goes on and on and on and on, that aren't really part of those code bases.

129

And I know there's, you know, Google has their modern web thing

130

that can sort of help steer the direction a little bit

131

that I'm not 100% sure is as good as they want us to think.

132

But at least there are these things to say, oh, use these modern features and here's what they do.

133

But if people aren't writing as much of the code themselves, there's less concern about the architecture of that code and who cares

134

if we're doing it in a more complex way

135

that works i mean some people do because there's performance impacts

136

and we should probably be focused primarily on performance uh

137

which often goes by the wayside with ai but uh

138

if people are writing less code themselves is does this potentially

139

lead to a stagnation of all of our languages right

140

because it we have ways of doing things you ask it

141

to do it it can create some stuff you go in you tweak you massage it, you get it to go where you want it to be.

142

But if there's people like me, we continue writing code on our own.

143

And I know a lot of people listening to this are probably in the same boat.

144

But if there's less people doing that, does it put less pressure for the languages to continue to evolve or not?

145

This is a question that a few people asked me at CSS Day that I didn't really have an answer for.

146

It could be one of those unforeseen things that ends up happening, or maybe we continue to evolve or evolves in different ways.

147

Whatever it is, I'd love to to know what you think about

148

that and I'll probably talk about it in a future video.

149

And I think for today that is it.

150

So thank you very much for listening.

151

And of course until next time don't forget to make your corner of the internet just a little bit more awesome.

앱 다운로드

유창하게 말하는 데 필요한 모든 것

AI 발음 평가문장마다 점수 확인

IPA 발음 연습모든 소리 마스터

단어 학습나만의 단어장 만들기

단어 게임놀면서 외우기

QR 스캔

Download on theApp Store Get it onGoogle Play

같은 채널

Are we heading to an era of stagnation or innovation?

Daily ConversationUniversity StudentsWorking Adults

AI Coding Is a Dead End

Daily ConversationWorking Adults

FOR YOU

왜 이 비디오로 말하기 연습을 해야 할까요?

이 비디오는 웹 개발에서의 '관심사의 분리'라는 주제를 다루고 있습니다. 이런 주제는 기술적인 내용이지만, 실제로는 명확하게 자신의 생각을 표현할 수 있는 기회를 제공합니다. 비디오를 시청하면서 영어 회화 연습을 하면, 새로운 용어와 개념을 배우는 동시에 자신의 의견을 영어로 정리하고 발표하는 연습이 됩니다. 이런 방식으로 영어 쉐도잉을 활용하면 말의 흐름과 발음 개선에 큰 도움이 됩니다. 또한, 기술 관련 논의는 현대 사회에서 중요한 주제이므로, 이러한 대화를 통해 더 깊이 있는 영어 표현을 익힐 수 있습니다.

문맥 속 문법과 표현

비디오에서 사용된 몇 가지 주요 구조를 살펴보면, 영어 회화에서 효과적으로 사용할 수 있는 표현을 배울 수 있습니다:

"separation of concerns": '관심사의 분리'라는 개념을 설명하며 주제를 규명하는 데 유용합니다.
"at least in my experience": 자신의 경험을 언급하며 주장을 강화하는 표현입니다. 이는 대화에서 주관적인 의견을 표명할 때 자주 사용됩니다.
"it's flawed": '결함이 있다'는 강한 의견을 전달할 때 유용한 표현으로, 비판적인 사고를 영어로 표현할 때 도움이 됩니다.

이러한 구조들을 비디오를 보며 반복 연습하면, shadowspeak의 효과를 극대화할 수 있습니다.

일반적인 발음 함정

비디오에서 특히 주의해야 할 단어와 억양을 살펴보면 다음과 같습니다:

"JavaScript": 빠르게 발음하면 흐름이 끊길 수 있으니 느리게 연습하는 것이 좋습니다.
"hover": 이 단어는 발음할 때 '호버'로 강조해주어야 자연스럽습니다.
"concerns": '컨선즈'라고 발음하는 것을 주의하고, 끝 부분에서 '조금 더 끌어주는 발음'을 연습하세요.

이러한 단어들을 올바르게 발음하면, 영어 쉐도잉 실력을 더욱 향상시킬 수 있습니다. 비디오를 보며 반복해서 따라 하는 것이 중요합니다!

이 영상의 문법

화자가 가장 많이 쓰는 문형을 영상 속 실제 표현과 함께 정리했습니다.

문형	영상 속 표현
현재완료진행 have/has been + -ing — 전에 시작해 지금도 계속되는 동작	has been going · haven't been doing
현재완료 have/has + 과거분사 — 과거의 일이 지금도 관련이 있을 때	I've had · haven't been · We've simplified
수동태 be + 과거분사 — 누가 하는지보다 무슨 일이 일어나는지에 초점	should be done · is just flawed · are connected
관계절 who / which + 절 — 사람이나 사물에 대한 추가 정보	Day, which was · ago, which is · attributes, which makes

쉐도잉이란? 영어 실력을 빠르게 키우는 과학적 방법

쉐도잉(Shadowing)은 원래 전문 통역사 훈련을 위해 개발된 언어 학습 기법으로, 다언어 학자인 Dr. Alexander Arguelles에 의해 대중화된 방법입니다. 핵심 원리는 간단하지만 매우 강력합니다: 원어민의 영어를 들으면서 1~2초의 짧은 지연으로 즉시 소리 내어 따라 말하는 것——마치 '그림자(shadow)'처럼 화자를 따라가는 것입니다. 문법 공부나 수동적인 청취와 달리, 쉐도잉은 뇌와 입 근육이 동시에 실시간으로 영어를 처리하고 재현하도록 훈련합니다. 연구에 따르면 이 방법은 발음 정확도, 억양, 리듬, 연음, 청취력, 말하기 유창성을 크게 향상시킵니다. IELTS 스피킹 준비와 자연스러운 영어 소통을 원하는 분들에게 특히 효과적입니다.

섀도잉 방법: 단계별 전체 가이드 읽기 →

쉐도잉 연습: We've got separation of concerns wrong - 영상으로 영어 말하기 배우기

연습 모드 선택

앱 다운로드

같은 채널

Are we heading to an era of stagnation or innovation?

AI Coding Is a Dead End

추천 영상

Use these CSS features instead of JavaScript

Armchair Architects: Resiliency in the Cloud – Core Patterns

what happened to critical thinking?

How to Speak so That People Want to Listen - Julian Treasure

It’s not just you

How I Learned Procedural Generation

"Focusing is about saying no" - Steve Jobs (WWDC'97)

My 4.9-Star iOS App Is Actually a Website: Here’s How I Built It

The Only SaaS Moats Left in 2026

Go’s Big Mistake

DRY Often Makes Your Code Worse

왜 이 비디오로 말하기 연습을 해야 할까요?

문맥 속 문법과 표현

일반적인 발음 함정

이 영상의 문법

쉐도잉이란? 영어 실력을 빠르게 키우는 과학적 방법