Angular与Jessica Janiuk

现代Web开发面临诸多挑战，尤其是在构建可扩展、可维护和高性能应用时。随着应用规模增长，管理复杂的用户界面、确保高效数据处理和模块化代码结构变得越来越困难。Angular是由谷歌开发的基于TypeScript的Web框架，采用组件驱动设计，专为构建单页应用而打造，特别强调模块化架构和性能优化。Angular的可扩展性、可维护性以及内置特性（如模块化架构、TypeScript支持和强大的工具链）使其在企业级应用中广受欢迎。

Modern web development faces several challenges, particularly when building scalable, maintainable, and high performance applications. As applications grow, managing complex user interfaces and ensuring efficient data handling and modular code structures becomes increasingly difficult. Angular is a TypeScript based web framework developed by Google. It's component driven and designed for building single page applications with a strong emphasis on modular architecture and performance optimization. Angular scalability, maintainability, and built in features like modular architecture, TypeScript support, and robust tooling have made it popular for enterprise applications.

Jessica Janiuk是谷歌的高级软件工程师，她从事Angular开发工作——该框架刚在去年底发布了第19版。在本期节目中，Jessica与Josh Goldberg共同探讨Angular项目。本期主持人是Josh Goldberg，一位全职独立开源开发者。他专注于TypeScript生态项目，最著名的是TypeScript ESLint（该工具使ESLint和Prettier能够运行在TypeScript代码上）。Josh还是O'Reilly《Learning TypeScript》的作者，微软开发者技术MVP，并在Twitch上进行实时编码直播。

Jessica Janiuk is a staff software engineer at Google, where she works on Angular, which just hit version 19 late last year. In this episode, Jessica joins the show with Josh Goldberg to talk about the Angular project. This episode is hosted by Josh Goldberg, an independent full time open source developer. Josh works on projects in the TypeScript ecosystem, most notably TypeScript ESLint, the tooling that enables ESLint and Prettier to run on TypeScript code. Josh is also the author of the O'Reilly Learning TypeScript book, a Microsoft MVP for developer technologies, and a live code streamer on Twitch.

您可以在Blue Sky、Mastodon、Twitter、Twitch、YouTube和.com上通过Joshua k Goldberg找到Josh。

Find Josh on Blue Sky, Mastodon, Twitter, Twitch, YouTube, and .com as Joshua k Goldberg.

Jessica Janek，欢迎来到软件工程日报。

Jessica Janek, welcome to software engineering daily.

哦，谢谢邀请。

Oh, thank you for having me.

感谢您的到来。很高兴能与您交流。您在Angular内外做了很多很棒的工作。不过先回溯一下，您是如何进入编程领域的？

Thanks for coming on. I'm excited to talk to you. You do a lot of cool stuff in and out of Angular. But just to wind things back a bit, how did you get into coding?

哦，天哪，这个问题真好。我大概是在九十年代开始编程的——这暴露了我的年龄。当时用家里的第一台PC，我开始摆弄随Windows自带的QBasic（不知道现在还有没有）。学了批处理命令，把电脑搞坏了好几次，但那时就发现自己在这方面有点天赋。

Oh, gosh, that's a really good question. So I got into coding probably back in the nineties, which is showing my age. But with my first family's PC, I started playing with QBasic, which came with Windows back then. I don't know if it still does. And learned batch commands and kind of messed up our computer quite a few times, but discovered I had a knack for it back then.

这算是第一次尝试。高中时还上过Pascal编程课，但现在全忘光了。从那以后，我一直对技术很有感觉。只要接触电脑，编程就是我一直感兴趣的事。之后我就各种折腾技术和编程语言。

So that was probably the first foray. I took programming classes in high school for Pascal, but I don't remember any of it. And then, yeah, from then on, I've just always had a knack for tech. So coding was something I was always interested in as soon as I had access to computers. And I've just kind of played around with all sorts of tech and programming languages since then.

不过我并没有获得软件工程的正规学位，算是绕了些弯路才最终进入工程领域作为职业。

But I didn't actually end up with a formal degree in software engineering. So I kind of roundabout made my way into being in engineering for a career.

在进入工程行业之前您从事什么工作？

What did you do before you went into engineering as a career?

所以我最初从事的是视频制作行业。我担任制片人，整个职业目标就是最终能够进入好莱坞那样的领域，但不是站在镜头前。我想在幕后工作，做剪辑和特效之类的事情。这些让我非常感兴趣。因此我在大学获得了传播学学位，希望朝这个方向发展，并找到了第一份制片人的工作。

So I started my career in video production. I worked as a producer working my whole goal was to, like, eventually make my way out into, like, kind of the Hollywood space, but not in front of the camera. I wanted to be behind the camera and doing editing and special effects, that kind of stuff. That interested me significantly. So I got a communication degree in college with the goal of hopefully getting out in that direction, got my first job as a producer.

那是我做过的最无聊的工作。至少在我所负责的领域是这样。我做的是那些远没有那么光鲜的工作。我为我们的房地产支持服务公司撰写文案。那时候他们会制作长达三十分钟的电视房屋广告节目。

And it was the most boring job ever. At least in the areas that I was working in. I was doing like the jobs that are far less glamorous. I was writing for our real estate support services companies. So back then they would do television home advertisement programs that were like thirty minutes long.

如果你在周日早上醒来打开本地电视台，可能会看到一个三十分钟的节目，有人在朗读你所在地区的待售房屋信息。那些就是我写的。多年来日复一日，我查看MLS房源列表，将一页纸的信息转换成定时脚本。我实在觉得这份工作太无聊了，于是开始编写软件来自动完成这项工作。我工作的公司既有软件部门也有视频部门。

And if you woke up on a Sunday morning and you turned on your local television, you might see a thirty minute program of someone reading about homes for sale in your area. I wrote those. For several years, day in, day out, I looked at MLS listings and translated a sheet of paper into a script to time. And I essentially was so bored in that job that I started writing software to do it for me. And the company I worked for like had both the software side and a video side.

他们给了我时间去做这件事，还在他们的服务器上提供了空间。到我离职时，我已经编写出了能够自动处理MLS房源列表、生成定时脚本并以所需格式输出的软件。就在那时我意识到，我或许应该从事这个工作而不是继续做制片。于是我在那个时间点转变了职业方向。这就是我迂回进入工程和技术领域的经历。

And they offered me like time to do that and space on their server to do that. And by the time I left that job, I had written software that would automate like taking in MLS listings and generating a script to time and spitting it out into a format needed. So it was at that point, I was like, I should probably do this job instead of doing the producing job. So I pivoted my career at that point. So that's essentially my roundabout way of getting into actually engineering and tech.

这是进入编程领域非常常见的途径。你有一个无聊的任务，需要反复做同样的事情。要是能有什么方法让它自动化就好了。

That's such a common way to get into programming. You have a boring task. That's the same thing over and over again. If only there were a way to automate it.

没错。我听过一种说法：每个优秀的工程师都是懒惰的工程师。

Exactly. I've heard it said that every good engineer is a lazy engineer.

是的。

Yes.

因为他们正是会这样做。他们会完全自动化那些因为重复性太强而懒得亲自做的任务。然后你就有更多时间去编码

Because they will do exactly that. They will fully automate a task that they're too lazy to do because it's repetitive. And then you have more time to code

处理其他事情。是的。这就像那些点击饼干类游戏，你不断做某件事以便能更好地做这件事。

on other things. Yeah. It's like one of those, you know, cookie clicker style games where you keep doing the things so that you can do the thing more.

是的。完全正确。

Yes. Exactly.

在MLS数据自动化之后你去了哪里？

Where did you go after MLS data automation?

我的第一份真正的工程工作是在美国威斯康星州西部的一家小型代理公司。这家公司现在已经不存在了，但那是在Squarespace等平台出现之前的时代，那时人们还不能轻易使用平台来建网站。当时，小公司会付费给本地代理机构来做这项工作。我就在其中一家工作。所以我帮助一个团队为小公司搭建商业网站，这些网站包含标准的联系表单，可能还有一个产品目录之类的东西。

My first real engineering job was for a small agency that was located in Western Wisconsin in The United States. And the company no longer exists, but this was back in the time before the Squarespaces and whatnot of the world where people could just use a platform that would build a website pretty easily. Back then, smaller companies would pay local agencies to do that work. And I worked for one of those. So I would help a team of people build out small company business websites that had your standard contact forms and maybe a catalog or something like that.

我不得不向他们证明自己的能力，因为我既没有学位也没有相关背景经验。所以是的，我在这家公司开始时是在证明自己，然后很快就成为了他们的首席工程师。所以我显然在这方面有天赋。我记得他们交给我的第一个任务，他们可能以为会花我一些时间，但我大约三十分钟就完成了。而且我觉得那是一个相当简单的任务。

And I kind of had to demonstrate to them that I was capable because of course I didn't have the degree and I didn't have the background experience. So yeah, I started at this company kind of proving myself and then very quickly ended up as their lead engineer. So I clearly have a talent for it. I remember they gave me my first task, which they probably thought would take me a while and I did it in like thirty minutes. And it was like what I thought to be a fairly trivial task.

所以他们当时显然对我表现得如此出色感到惊讶。但那也是回到IE6、IE7、IE8的时代，不得不处理所有那些问题。我当时在写Cold Fusion代码。

So they were clearly surprised with how well I was doing at the time. But this was also back in the IE6, IE7, IE8 days and having to deal with all of that. I was writing cold fusion code.

哦，那可是老古董了。

Oh, that's a throwback.

是的。我想它现在还存在，但自从那份工作后我就再没碰过它了。

Yeah. I think it still exists, but I haven't touched it since that job.

很多在IE6那个时代进入网页开发的人，因为IE6等等原因并没有留在网页开发领域。你为什么觉得自己从那以后一直坚持在这个领域？

A lot of people who went into web development in the I e six so on days did not stay in web development because of I e six and so on. Why do you think you've stuck in that area since then?

我其实很清楚我为什么坚持下来了。那是因为，尤其是在前端方面，尽管处理IE令人沮丧，但编写代码并立即在屏幕上看到结果，这种满足感过去有，现在依然有。完全构建出某个东西并能在浏览器中直接与之交互，这给了我一种多巴胺的冲击。而且我觉得还有一种‘我打败了你，Internet Explorer’的感觉。

I actually know quite well why I did. And it was because, especially on the front end side, as frustrating as dealing with IE was, there was and still is such a satisfaction to me of writing code and seeing it immediately reflected on a screen. And the satisfaction of fully building something out and being able to directly interact with it in a browser gave me a dopamine hit. And I think there was also that sense of like, I beat you Internet Explorer.

是啊。

Yeah.

所以我觉得这就是原因。因为我现在仍然有那种感觉。现在的满足感略有不同，我认为它来自于所有测试运行通过时的绿色勾选标记，以及我的一些其他爱好。就像是让某个东西物理上运作起来并完成一件事。我想我可能永远都会从中获得多巴胺的冲击。

So I think that's where it comes from. Because I still feel that now. There's a slightly different satisfaction now, which I think comes from the green check mark of all your tests running and some of the other hobbies of mine. It's like getting something physically working and doing a thing. I think I'll probably always get a dopamine hit from that.

所以我认为这就是它的来源，也是我坚持下来的原因。

So I think that's where it comes from and why I've stayed with it.

真棒。问完这个问题后我突然想到，如今并不是每个从事网络开发的人都知道IE代表什么。所以谢谢你明确说出Internet Explorer。已经过去这么久了。不过好吧。

Lovely. It occurred to me after asking the question that not everyone in web development today might even know what IE stands for. So thank you for explicitly saying Internet Explorer. It's been so long. But okay.

让我们稍微快进一下。你在Internet Explorer的有趣时代进入了网络开发领域。现在你在谷歌的Angular团队。这是怎么发生的？

Let's fast forward a little bit. So you got into web development in the fun days of Internet Explorer. Now you're at Google on the Angular team. How did that come to be?

这是个意想不到的故事。我从没想过自己会进入谷歌，更不用说加入Angular团队了。大约在我做第一份工程工作的时候，或者实际上是之后不久的工作时，Google IO刚开始兴起。我记得当时对Google IO整体感到非常兴奋，我会关注所有相关的更新。

That's a unexpected story. So I never expected I would be at Google, let alone on the Angular team. Like around the time that I was doing that first engineering job or actually the job shortly thereafter was when Google IO was first becoming a thing. And I remember being excited about Google IO in general. I would watch all of the updates on it.

然后我有机会去参加了一年，我被那里的每个人深深震撼，简直就像眼睛里闪着星星一样四处走动，脸上仿佛有小星星。不，开个玩笑。我脸上其实没有星星，但我超级兴奋，为能成为那次经历的一部分而激动不已。尤其是我有一群技术宅朋友，他们总是关注着，哦，谷歌有什么新闻？天啊，你能去IO？

And then I had the opportunity to go one year and I was super starstruck by just everybody there and just kind of like literally starry eyed walking around, like had little stars on my face. No, I'm just kidding. I didn't actually have stars on my face, but I was just like super excited and like thrilled to be a part of that experience. Especially since I had a bunch of techie friends who are always looking at like, Oh, what's the news coming out of Google? Oh my god, you get to go to IO?

太疯狂了。所以我对此超级兴奋。我当时觉得，谷歌是那种遥不可及的工作。因为对我来说，谷歌一直是聪明人工作的地方。而我从不认为自己属于那里，因为我没有斯坦福的学位。

That's so crazy. So I was super excited about it. And I was like, I thought of Google as the unattainable kind of job. Because to me, Google was always one of those places where smart people worked. And I never thought of myself as that because I didn't have that Stanford degree.

我不是从什么名牌科技大学毕业然后进入那种工作的。我是自学成才的，所以那对我来说就是不可企及的。所以在参加了IO之后——实际上我去过几次——有一年我看到了Angular团队的演讲。我记得看着那两个人演讲，当时就想，天啊，能和那些人一起工作，从事Angular这样的项目该多酷啊，我当时正在做一个AngularJS项目。

Didn't come out of some fancy tech university and get to go into a job like that. I'm self taught, so that was just unattainable to me. So after going to IO, I actually got to go a few times. And one year was a year where I actually saw the Angular team present. And I remembered watching the two people present and it was just like, man, it would be so cool to work with those people, to work on something like Angular, which is I was doing an AngularJS project at the time.

那是在Angular 2发布后不久。所以有很多关于这个框架新版本的信息。我当时就觉得，这是最酷的东西。我无法想象和那些人一起工作是什么感觉。快进一下，我得到了我的第一份，我称之为真正的科技工作。

And this was shortly after Angular two came out. So there was all this information about the new version of the framework. And I was just kind of like, this is the coolest thing. I can't imagine what it's like working with those people. So kind of flash forward, I got my first, what I would call real tech job.

我的意思是在一家科技初创公司工作，一家自称是科技公司的公司。在那之前，我为其他公司工作，那些公司碰巧有技术支持他们主要业务运营的部门。所以现在我在一家科技初创公司工作，然后我收到谷歌的邮件说，嘿，我们对你感兴趣，你愿意面试吗？我当时就想，当然，我肯定会搞砸，但当然愿意。于是我做了电话筛选，并以优异成绩通过了，我当时就懵了，什么？

And by that I mean like working at a tech startup, like a company that called itself a tech company. Prior to that, I worked for other companies that happened to have tech areas where they were supporting their major business operation. So now I'm working for a tech startup and I get an email from Google saying like, hey, we're interested, would you like to do an interview? And I'm just like, sure, I'm gonna bomb it, but sure. So I do the phone screen and I pass it with flying colors and I'm just like, what?

这不应该发生啊。但结果当时我已经收到了另一家较小初创公司的offer，所以我接受了那个职位，拒绝了现场面试。但谷歌仍然对我有兴趣，我会定期收到他们的跟进消息。最终，我到了那种我称之为‘放下防备’的时刻，就是你对自己的工作感到满意，但有点筋疲力尽，愿意考虑去别处面试。而时机最终正好合适。

This isn't supposed to happen. But it turned out that at the time, I had already had an offer from another smaller startup, so I accepted that role and declined the on-site. But there was still interest from Google and I get, you know, periodic check ins and stuff. And eventually I was kind of at one of those, I call it like a shields down moment where you're like happy with your job, but you're kind of a little burned out and you're open to maybe interviewing somewhere. And the timing ended up being right.

我参加了面试，不知怎么的，我记得在面试时感觉一切都很顺利，这本来不该发生的。结果我得到了这份工作。后来我加入了谷歌内部的一个导师计划，走进房间时，我见到的人恰好是我在Google IO大会上看到过的一位演讲者，我们最终建立了联系。通过那个机会，我最终得以加入Angular团队。至今我仍然觉得不可思议，哇，这些人现在是我的同事了。

And I interviewed and somehow, like I remember being in the interview being like, this is going well, that's not supposed to happen. And I ended up getting the job. And then I joined a mentorship program within Google and I walk into the room and the person that I see happened to be one of the people that I saw on stage at Google IO and we ended up connecting. And through that opportunity, eventually I was able to join the Angular team. And it's still like one of these things that I'm just like, wow, these people are my colleagues now.

这对我来说仍然难以置信，我从不认为这是理所当然的，因为我知道他们会不同意这一点，但我总觉得自己是团队里最笨的那个人，因为我对自己要求很严格。但我始终想向他们学习，总是对他们的能力和知识感到敬畏。我觉得这是一个很棒的位置，因为团队里的每个人都如此出色。所以我以非常谦逊的态度接受自己在Angular团队的角色。我知道现在很多人特别将我与Angular团队联系在一起，因为他们在YouTube上看到我，看到我做演讲等等。

That doesn't make any sense to me still, and I don't take it for granted because I know they would disagree with this, but I feel like I'm always the dumbest person on the team because I'm very hard on myself. But I always want to learn from them and I'm always in awe of their ability and their knowledge. And I think it's a wonderful place to be because everybody on the team is so wonderful. So I think I accept my position on the Angular team with a lot of humility. I know a lot of people now associate me specifically with the Angular team because they see me on YouTube and they see me give talks and stuff.

但对我来说，我做所有这些事情是因为我知道外面也有像我一样的人，他们不认为自己有能力，但实际上他们是有能力的。也许他们会看到我，看到一个像他们一样的人，最终也能找到自己的道路，并可能因此受到鼓舞。所以，是的，这就是我如何来到这里的背景故事的长话短说版。

But for me, I do all of those things because I know there's a person like me out there too that doesn't think that they're capable, but is. And maybe they'll see me and see someone like them and eventually find their way here too and might be inspired by that. So, yeah, that's the long and the short of kind of the background of how I got here.

你有没有在现实中看到过例子，有人提到看到你拥有传播学背景等等对他们有所帮助？

Have you seen examples in the wild of people mentioning that seeing you with, you know, communications background and so on has helped them?

我不确定有没有。我见过有人说受到我的鼓舞，也见过有人（比如Jessica）将我作为职业发展的目标。听到这些总是让我感到非常暖心。是的，我不记得有人直接告诉过我，比如'哦，我受到你非技术背景的鼓舞，想进入科技行业'之类的话。所以也许有一天会吧，我们拭目以待。

I don't know that I have. I have seen people say, like, they are inspired by me and I've seen Jessica's, my goals, like as far as where I'd like to see my career go. And that's always like very heartwarming for me to hear. Yeah, I don't think I've ever had anybody tell me directly like, oh, I'm inspired by your non technical background and want to get into tech and whatnot. So maybe someday, we'll see.

也许这个播客的听众会听到这段话。也许会写信告诉你。

Maybe a listener of this very podcast will hear this Maybe. And write it.

也许吧。正是如此。

Maybe. Exactly.

不过好吧。让我们深入一点。你现在在Angular团队。很多人可能知道Angular是什么，但也有很多人不知道。

But okay. Let's dive in a little bit. So you're on the Angular team. A lot of folks may know what Angular is. A lot of folks don't.

首先，你能给我们一个内部视角，告诉我们Angular到底是什么吗？

Just to start off, could you give us the insider look on what actually is Angular?

Angular是一个用于大规模构建复杂企业级应用程序的框架。我们相信它是目前最优秀的框架之一。到现在为止，我们是最老牌的大型框架。我们特别专注于Web，而不是像某些框架那样试图瞄准多平台方法。我们的专长是Web，我们认为专注于这一点才能做到最好。

So Angular is a framework for building complex enterprise applications at scale. And we believe it is one of the best out there. We're the oldest big framework out there at this point. And we specifically focus on the web over the whole multi platform approach that there are some frameworks out there that are trying to target. Our expertise is the web, and we think we can do best by focusing on that.

我们之所以说企业级，是因为通常Angular更多地被用于企业端。但是，是的，我想这大概就是我会描述它的方式。

We say enterprise because typically Angular is used more on the enterprise side. But, yeah, I would say that is probably the way I would describe it.

当然。我能看出你在措辞上深思熟虑，有两点我想强调一下。一是你用了‘我们认为’而不是‘它就是’；然后你说了‘最好的之一’而不是‘最好的’。你能告诉我们，为什么从你的角度来看，用‘最好的之一’这样的措辞如此重要，而不是说‘我们是最好的’？

Sure. I can tell you've thought deeply and carefully on your language there, and there are two parts I wanna highlight. One is that you said we think rather than it is. And then you said one of the best rather than the best. Can you tell us why is that phrasing so important of phrasing it as one of the best from your opinion rather than we are the best?

是的。我知道有很多人还在想着那些框架之争，但我们——我指的是整个Angular团队——觉得那已经是过去式了。我们实际上与其他框架的作者保持着相当定期的交流。比如我们和Solid、Vue、Svelte，几乎所有你能想到的其他框架都进行过对话。而且这些交流都是积极的。

Yeah. Well, I know there's a lot of people who think about the frameworkwars out there, but we, and I say we as in the Angular team in general, feels that that's a thing of the past. We actually communicate pretty regularly with other framework authors. Like we've had conversations with Solid and Vue and Svelte, just every other framework you can think of. And we have those in a positive way.

这些更像是协作会议，我们讨论各自的优缺点，能从对方那里学到什么，以及每个框架所采用的方法。我们喜欢这样，因为历史上你会发现每个框架都或多或少地从其他框架借鉴了一些东西。我们认为这没什么不对。灵感来自其他框架，不同的做事方式也源于那些框架和其他经验。所以我们知道我们不会是做事情的唯一权威来源。

Those are kind of collaborative sessions where we talk about the pros and cons and what we can gain from each other and how the approaches that each framework is taking. We liked it because historically you'll see that every framework has kind of taken bits from each of them. And we don't think that there's anything wrong with that. Like, inspiration comes from other frameworks, other modalities of doing things come from those and other experiences. So we know we're not going to be the only source of the definitive way to do things.

如果我们固步自封，说‘哦，Angular就是一切，Angular的做事方式是唯一的方式’，那我们就会错过很多东西。所以我们喜欢与其他框架交流，并且我们不认为我们是在为了争夺市场主导地位而互相敌对。显然，有些框架更受欢迎，有些则不那么受欢迎，有些框架适用于特定的用例。但很多公司里的人并不能选择他们使用哪个框架，因为他们正在已有的技术栈上工作，而当初可能只是有人碰巧选择了‘哦，我们用React’或‘我们用Vue’、‘用Svelte’、‘用Angular’。这些选择可能是在那些框架优势突出的时候做出的，或者只是某个人喜欢那个框架。所以我们觉得在这个领域，我们应该努力让整个领域对每个人都变得更好，而不是试图去证明我们比X、Y或Z更好。

And if we just keep our head in the sand and say like, Oh, Angular is it, Angular is like our way of doing things is the only way, we're going to miss out on a lot. So we like to talk to other frameworks and we don't think that we're at each other's throats for marketplace dominance. Clearly there are popular frameworks and less popular frameworks, and there are frameworks that have certain use cases, But a lot of people at companies don't get to make the choice over which framework they use because they're working on an existing piece of technology and somebody just happened to choose, oh, we're using React or we're using Vue or we're using Svelte or we're using Angular. And those choices were made at a time that maybe the strengths were in those frameworks or maybe a person just liked that framework. So we feel that in this space, we should endeavor to make the space better for everyone rather than trying to be like, well, we're better than X, Y or Z.

所以我想，也许答案就是我们希望人们使用他们觉得舒服的东西。我们希望人们能看看Angular并喜欢他们所看到的。但最终，我们希望通过跨框架的对话，我们都能推动网络朝着一个更好、性能更高、对工程师和用户都更易用的方向发展。所以我认为这就是那种说法的来源。

So I guess maybe that's the answer is we want people to use what's comfortable for them. We hope that people will take a look at Angular and like what they see. But ultimately, we hope that with our conversations across frameworks that we are all moving the web in a better, more performant, easy to use for engineers and users alike direction. So I think that's where that comes from.

这很有道理。这是一种非常好且具有前瞻性的看待事物的方式。

That makes a lot of sense. That's a very good and forward thinking way of looking at things.

我们希望如此。

We hope so.

API是可靠AI的基础，而可靠的API始于Postman。作为财富500强中98家公司的选择，Postman是一个帮助超过4000万开发者构建和扩展其最关键业务工作流背后的API的平台。通过Postman，团队可以集中访问最新的LLM和API，获得MCP支持，并在一个平台上实现无代码工作流。无需编写一行代码，即可快速集成关键工具并构建多步智能体。立即开始构建更智能、更可靠的智能体。

APIs are the foundation of reliable AI and reliable APIs start with Postman. Trusted by 98 of the Fortune 500, Postman is the platform that helps over 40,000,000 developers build and scale the APIs behind their most critical business workflows. With Postman, teams get centralized access to the latest LLMs and APIs, MCP support, and no code workflows all in one platform. Quickly integrate critical tools and build multistep agents without writing a single line of code. Start building smarter, more reliable agents today.

访问 postman.com/sed 了解更多信息。

Visit postman.com/sed to learn more.

Angular有哪些特别出色的方面是你想特别指出的，无论这些特性在其他框架中是否也有？

Do you have particular aspects of Angular that you would call out as being particularly great, whether or not they are duplicated in other frameworks?

是的，我认为有几个方面。但最重要的一点是，我们在向前发展时始终秉持着让用户同步升级的理念。很多其他框架没有迁移系统。当我们发布主要版本或次要版本并进行破坏性变更时，我们不会简单地说'嘿，你的代码坏了'。

Yes. I think there's a few of them. The biggest one though, I think, is our mentality about bringing users along with us as we move forward. A lot of other frameworks don't have a migration system. So when we release a major version or minor version and we do a breaking change, we don't just want to say, Hey, your change is broken.

我们希望带着您一起升级。因此大多数变更（如果不是全部的话）都会提供自动化迁移工具，这些工具可以自动运行或由您选择运行，将您的代码从已弃用的旧版本升级到新版本。我认为我们从AngularJS到Angular 2的转换过程中吸取了惨痛教训——那是一次重大的破坏性变更，迁移并不容易。显然，对于当时在这个领域的开发者来说，这是一个非常有争议的举措，让我们失去了很多好感。从那时起，我们投入了大量精力来确保不会破坏用户的代码。

We want to bring you along with us. So a lot of those changes, if not all of them, will have an automated migration that will either run automatically or you can opt in to run that will take your code from the previous deprecated version to the new version. I think we learned the hard way that that is a very important thing through the whole, you know, AngularJS, Angular two kind of switch where we it was a big major breaking change that wasn't an easy thing to migrate. And obviously, for those that were around at that time in this space, that was a very controversial move and cost a lot of goodwill. And so since then, we've put a ton of effort into making sure we don't break people.

所以我认为这是我们的一大优势。我们现在做的很多事情在用户体验方面可以说是行业领先的，特别是在经历了很长一段时间被认为是一个笨重、模板代码多、较难使用的框架之后。现在我们推出了可延迟视图（deferrable views）或延迟块（defer blocks），通过声明式设计了一个系统，让您无需手动管理依赖关系、编写动态导入或处理解析时机。我们提供了非常用户友好的API，让人们可以说'我希望这段代码延迟加载'，并根据用户交互或浏览器空闲状态来触发延迟加载。

So I think that's a big factor working in our favor. I think a lot of the things that we're doing now are somewhat industry leading in the user experience space, especially after for a long while we were considered one of the heavy boilerplate y, more difficult to use frameworks. Now we're doing things like our deferrable views or defer blocks where we have declaratively designed a system so that you don't have to manage your dependencies and write dynamic imports yourself and manage when they're going to resolve. You get a very user friendly API for people to say like, hey, I want this section of code to be lazy loaded. And, trigger that lazy loading based on a user interaction or once your browser becomes idle.

除此之外，我们还将此扩展为水合（hydration）边界，我们的增量水合功能让很多人感到惊讶，因为这是一个难以解决的问题。我们在信号（signals）和响应式系统方面的工作也是行业领先的努力，与Solid等其他框架进行了合作。我们实际上与Solid密切合作设计了一个运行良好的API。所以我认为这些是我们当前做得特别出色的方面，被广泛认为是积极的，并在整个前端行业具有趋势引领作用。

And then on top of that, we've extended that to be a boundary for hydration and our incremental hydration is kind of I think a lot of people were surprised when we shipped that because it is a hard problem to solve. So I think a lot of the things that we're doing around signals and reactivity is also an industry leading effort in partnership with some of the other frameworks like Solid, for example. We've actually worked closely with Solid to design an API that works well. So I think those are standouts to me of the things that we're doing right now that are really seen as positive and having a really overall across the entire front end industry kind of trend setting.

好的。我想按顺序深入了解这些特性。我们先谈谈可延迟加载、defer和水合功能。为什么这是个难题？首先，这到底是个什么问题？

Sure. I'd like to go through those in order. Let's talk about deferrables, defer and hydration. Why is that such a difficult problem? And in fact, what is that problem in the first place?

好的，关于可延迟加载或懒加载代码，复杂应用面临的一个问题是初始页面加载（或者任何可能被首次访问的页面）。如果不使用懒加载，可能会包含一些非常重的组件，这些组件会延长初始渲染时间，延迟首次绘制，对核心网页指标产生负面影响，从而影响用户体验。通常目标是减小初始包大小。在其他框架中，虽然有Suspense边界这样的机制，但您仍然需要处理动态导入的识别和懒加载等相关事宜。

Okay, so when it comes to deferrable stuff or lazy loaded code, one of the problems that people have in complex apps is that their initial page load or yeah, we'll just go with initial page load. It can be any page in your app that could be landed on initially. When you don't lazy load stuff, you can have some really heavy components in there that will take a while and delay your initial render and delay your time to first paint when user interaction have a negative impact on your Core Web Vitals. And typically the goal is to reduce that initial bundle size. So in other frameworks, there's things like the suspense boundaries, but you still have to deal with identifying your dynamic imports that you're going have to lazy load and all that sort of stuff.

您需要找到一种代码拆分方式，既不会对用户体验产生负面影响（比如避免长时间显示加载动画或布局偏移），同时尽可能保持包体积最小。我想这大概就是问题的描述。在Angular中，我们通过让您可以直接在组件模板中用defer语句包裹模板的某个部分来解决这个问题。这基本上就是说：模板中该代码块内的每个组件和每个依赖项都要懒加载。无需手动编写那些动态导入。

So you need to kind of figure out how you can break up your code in a way that won't negatively impact the user experience because they're seeing a loading spinner for a really, wouldn't say long time, but where you might have a layout shift that comes with that, while also keeping that bundle size as small as possible. I think that is probably the way I would describe it. So we have solved this in Angular by being able to essentially go into your template for your component and just wrap a section of that template in a statement that's defer. And that basically just says every component, every dependency inside that block of code in your template, lazy load that. No having to write out those dynamic imports.

框架会为您处理这一切。这基本上解决了'作为开发者，我想要懒加载应用的某些部分，我该怎么做'的问题。我们还提供了相关API，比如加载模板、加载失败时的错误模板、预先显示的占位符等，这些几乎是所有类Suspense边界都必需的功能。在此之前，在任何框架中，您都必须手动编写所有这些内容，这需要大量模板代码和额外工作。

It just the framework handles it for you. So that essentially solves the like, hey, I'm a developer, I want to be able to lazy load sections of my application, here's how I'm going to do that. And we've provided APIs there that are like, here's your loading template, here's your error template if something fails when you load, Here's a placeholder that shows beforehand and which are just kind of essentials for just about every kind of suspense like boundary. You need to have that kind of thing. And prior to this in any framework, you would have to manually write out all of that stuff, which is a lot of boilerplate, it's a lot of extra work.

然后您还得自己处理性能优化。所以延迟加载代码本质上要解决的问题就是：将大量重型依赖从应用的主 chunk 中移出，让用户能更快地看到您的网站。

And then you got to handle making that perform it yourself. So that is the problem essentially that deferring your code is solving, is trying to get a bunch of heavy dependencies out of your main chunk for your application so users can see your website faster.

我认为这很好地说明了至少两点。一是所有框架都在致力于对性能和整洁代码、服务性能的共同投入。二是，我认为这是一个非常有趣的例子，展示了Angular模板语言如何被核心团队使用和扩展，它非常简洁，并且与你已有的Angular模板指令（比如添加defer、添加loading、添加error等）非常一致。它看起来就像是现有功能的自然延伸。

I think this speaks really well to at least two things. One is this shared investment in performance and clean code and service performance that all the frameworks are working towards. And two, I think this is a really interesting example of how the Angular templating language can be worked with and extended by core, that it's very clean and very in line with existing Angular template directives that you have, you know, add defer, add loading, add error and so on. And it just seems like a natural extension of what's already been there.

是的，谢谢。我想我们看法一致。Angular团队实际上非常喜欢Svelte的语法，我们最初为defer功能计划的就是直接采用Svelte使用的相同语法。这实际上是我们最初RFC的一部分，但正是由于用户反馈，我们最终切换到了现在的语法。

Yeah. Thank you. I think we agree. The Angular team actually really likes Svelte's syntax, and we actually initially for our defer, we're planning on just using the same syntax that Svelte uses. That was actually part of our initial RFC that we put out when it was actually due to user feedback that we ended up switching to the syntax.

但没错，我认为最初Angular模板的理念是它只是HTML。但事实是它并不完全是。我想这一点很早就被意识到了，因为如果你查看工作组，你会看到他们在抱怨我们处理属性的方式不同，他们说需要与Angular团队沟通，看看能否让我们在某些属性和标签上遵循标准，因为我们原生使用了非HTML标准的自有属性。但我认为这艘船已经启航了。所以现在我们只是试图创造一种自然、易用且非常接近HTML的语法。

But yeah, like I think originally the concept behind Angular templates was that it was just HTML. And the truth is it's kind of not. And I think that was realized fairly early on because if you look in the working groups, you'll see them complaining about how we were doing attributes differently and that they were like, we need to talk to the Angular team to figure out if we can get them on the standards for certain attributes and tags because we natively have used our own attributes that are not HTML standard. But I think that trip has sailed at this point. So now we're just trying to make a natural, easy to use syntax that is very close to HTML for people.

顺着这个话题继续，你之前也提到了signals。Jessica，什么是signals？

Continuing forward on that, you also mentioned signals earlier. Jessica, what are signals?

你可以通过在房子顶上放一盏大灯并射向天空来做这件事，这会向人们发出信号，表明你的房子在那里。谢谢。很棒。不客气。

These are things that you can do by putting a big light on the top of your house and shooting that into the sky, and that will signal to people that your house is there. Thank you. Great. Yeah. You're welcome.

是的。有些人还会在那些灯上放些东西，比如蝙蝠形状之类的。

Yeah. Some people actually put things on those lights too, like bat shapes and stuff like that.

哦，为什么那样做？

Oh, why is that?

是啊，就是为了让人们知道他们是蝙蝠侠，这挺奇怪的。你会以为他们不想吸引别人注意这个。但不管怎样，不是的。所以signals是一种新的响应式形式，我认为它大概是在Preact领域首创的。

Yeah. Just to let people know that they're Batman, which is odd. You would think that they would not want to draw people attention to that. But anyway, no. So signals is a new form of reactivity that I think was kind of pioneered in the pre act world.

我觉得Jason是最早提出的人之一，或者至少，我不确定是不是JSON创建的——顺便说一下，JSON是Preact的创作者。我认为他们首创了signals，然后Solid也加入并创建了自己的库。之后我们开始关注这个，因为很多人一提到Angular就会想到RxJS，因为它深度嵌入在我们的框架中，是学习路径的一部分，但它有点重，并且很容易让人在使用时感到困惑。我们早就知道这一点。Angular的目标之一就是简化学习路径，尽量减少初始故事中的依赖，这样人们在学Angular时就不必考虑像RxJS这样复杂的东西。

I feel like Jason was one of the first people to put, or at least, I don't know if it was JSON that created it, the creator of Preact, by the way. I think they pioneered signals and then Solid kind of jumped in and made their own library. And then we started taking a look at, because Angular has, a lot of people think of Angular, they think of RxJS, because we had it very embedded in our framework and it's part of the learning journey, but it's a little heavy and can be very confusing for people to do properly. And we've known this. Part of our goal for Angular is to simplify the learning journey for Angular to keep as many dependencies out of that initial story so that when people are learning Angular, they don't have to think about complex things like RxJS.

我知道他们可以在真正需要时才引入它。所以我们一直在尝试为这方面的响应式找到一个好的解决方案。团队中的Alex、Rikabaugh、Pavel一直在研究我们在这个领域能做什么，并且我们与Solid团队也进行了大量交流，提出了使用signals的想法。Signals本质上是一种响应式原语，你可以创建一个signal，把你的值放进去，任何时候这个signal发生变化，订阅（用‘订阅’这个词可能不太准确，因为人们一听到订阅就会想到observables）这个signal的消费者就会得到通知或更新。

I know it can only bring that in when they actually need it. So we've been trying to figure out a good solution for reactivity in that regards. And Alex, Rikabaugh, Pavel on the team, they were looking at what we we could do in this space, And we're also talking a lot with Solid team and proposed this idea of us using signals. Signals are essentially a reactivity primitive where you can create a signal and you put your value in that signal and other Anytime that signal changes, you get kind of an Subscribe is the wrong word because that people think of observables when they think of subscribe. But your consumers of that signal will get notified or updated.

所以它非常轻量。同时还有计算信号，本质上是一种记忆化信号，它会缓存值并根据你设置的其他信号更新计算。这形成了一个完整的响应式图。但关键因素是它小巧且快速。这个方案被提给团队后，我们都觉得，没错。

So it's very lightweight. And along with that, there's like computed signals, which are essentially a memoized signal that caches values and updates compute computations that you've set based on other signals. So it's kind of a whole graph of reactivity. But the key factor is that it is small and fast. So this was proposed to the team and we were just like, yeah.

是的。这对我们来说是正确方向。我们就走这条路。所以这就是信号的本质。你可以声明新信号，在括号里放入值，当你想使用信号时，像调用函数一样调用它，它就会返回该信号的值。

Yeah. That's the right direction for us. Let's go that route. And so that's essentially what signals is. You you can say new signal, put your value in the parentheses, and then you when you wanna use a signal, you call it like a function and it returns the value of that signal.

你可以在TypeScript代码中通过获取该信号并调用set方法来设置值（如果是可写信号）。可以有只读信号。现在还出现了其他类型的信号，比如链接信号——这是一种高级的计算信号。希望这解答了你的问题。这是一个轻量、快速且响应灵敏的响应式系统。

You can set the value in your TypeScript code by grabbing that signal and calling set on it. If it's a writable signal, can have read only signals. And there are now new other types of signals like linked signal that is a fancy type of computed. So hopefully that answers your question. It's a reactivity system that is lightweight, fast, and responsive.

确实解答了。谢谢。我关注信号和可观察对象这类技术已经很久了。Vue早就有了ref之类的。我记得在我用React的时候还是MobX的忠实粉丝。

That does. Thank you. I've seen signals and observables and things like one or both of those for quite a while. I mean, Vue had had refs and such. I remember being a big fan of mob x back in my react days.

是的。我也是。

Yeah. Me too.

那是个很棒的库。

That was a great library.

确实很棒。

Yes. It was.

向MobX致敬。你觉得为什么信号是现在被加入Angular，而不是三年前或十年前呢？

Shout out. Shout out mob x. Is there a particular reason you think that signals are being added to Angular now as opposed to, you know, three years ago, ten years ago?

这部分源于我们改进响应式系统和优化学习路径的努力。多年来我们看到大量反馈认为Angular难学，其中RxJS是原因之一。查看Angular中的RxJS代码时，很容易让人困惑，且难以正确使用，尤其对新工程师而言。我们认为在合适场景使用RxJS或可观察对象是理想的（它们即将成为标准），因为可观察对象特别适合异步工作和需要持续更新的场景。

Part of that story of trying to improve our reactivity system and to improve the learning journey as part of it. We have seen over the years feedback from a lot of people that Angular is hard to learn. And part of that is RxJS. And if you look at a lot of RxJS code in Angular, it can get really confusing and it is hard to do right, especially for a new engineer. And we think that it is ideal to use RxJS or observables in general because now they're gonna be a standard at the right time because that is observables for those that don't know are really great for asynchronous work and anything that needs to continuously update.

比如从服务器流式接收数据并实时更新，这就是可观察对象的完美用例。但很多场景并不理想，如同步工作就绝非最佳用途——RxJS对此过于重型，新用户看到这类代码时会完全困惑。我们一直关注这些反馈，并尽力以最佳方式回应。

So let's say you've got data streaming from a server and you need to update that as it comes in, that's a great use case for observables. There are a lot of use cases that are not ideal, like synchronous work is is definitely not the best use. Like RxJS is very heavy for that and users coming in and looking at that code are like, what am I looking at here? What are we actually doing? So we've been seeing that feedback of Angular, and we're trying to respond to it in the best way that we can.

所以这主要就是当前的出发点。我们思考的是，如何让Angular更易于使用和学习？我们发现，目前使用信号的用户反馈非常积极。他们认为组件变得更加轻量级，更容易直观理解其功能。这给了我们一个强烈的信号，表明我们正走在正确的道路上。

So that is where this has come from primarily now. Like, what can we do to make Angular easier to work with and easier to learn? And we have found that the feedback from people who are now using signals is overwhelmingly positive. They find that components are way more lightweight, easier to just look at and understand what it's doing. So we take that as a huge sign or signal that we're doing the right thing.

我很喜欢这个方向。

I love it.

您的团队代码产出量创新高，却仍受困于僵化的传统工具。不灵活的工作流程、手动更新和割裂的沟通方式正在拖慢进度，而工程师们还要处理比以往更多的拉取请求和上下文切换。这就是monday.com开发平台的价值所在——提供完全可定制的工作流程，加速交付。没有管理瓶颈，没有笨重的插件。让开发者直接在Monday dev或IDE中工作，通过AI驱动的集成保持每个任务的上下文关联。

Your team is generating more code than ever, but you're still stuck with rigid legacy tools. Inflexible workflows, manual updates, and siloed communication are slowing you down just as your engineers juggle more pull requests and context switches than ever. That's why there's monday.com's dev platform with fully customizable workflows you can ship faster. No admin bottlenecks, no clunky add ons. Let your developers work in Monday dev or right from their IDE with AI powered integrations that keep every task in context.

实时全面掌握进度、性能和风险，与GitHub及整个生态系统完全同步。内置业务连接功能，Monday dev确保工程优先级与最关键的影响力目标保持一致。彻底告别管理瓶颈。访问monday.com/dev了解更多。

Get full visibility into progress, performance, and risk all in real time, fully synced with GitHub and your entire ecosystem. And with business connectivity built in, Monday dev keeps engineering priorities aligned with the impact that matters most. No more admin bottlenecks. Visit monday.com/dev to learn more.

您认为团队还会在哪些其他方面投入精力来简化或优化Angular？

Are there any other parts of Angular that you think the team's gonna invest in simplifying or streamlining in that line?

是的。我们在过去的视频和演讲中也多次提到过。作为一个框架团队，我们持续寻找改进的方法——这也是大家所期望的。我们重点关注的领域之一是如何进一步消除组件中的样板代码。不知道您最近是否使用过Angular，过去编写组件时必须先添加@Component装饰器。

Yes. And we've signaled again as such in past videos and talks and stuff. We're we're constantly trying to look at ways that we can improve, as you might hope a framework team is doing. But one of the key ones we're looking at is how we can eliminate even more boiler plate that we have in our components. So I don't know if you've used Angular recently, but in the past, anytime you wanted to write a component, you have to do add component.

然后在里面需要设置大量标志参数，这些都是重复的样板代码。您必须指定是否使用独立模式、模板位置、样式表URL，所有依赖项的导入都要放在里面。还有一些其他可能需要配置的选项，比如处理特定类型变更检测时需要在组件装饰器中指定参数。这些都需要大量思考，也增加了许多冗余代码。

And then inside there, you've got a whole bunch of flags you have to set that it's a lot of boilerplate. It's a lot you have to add. We had to specify whether you're in standalone and you to specify where your template's located and your style URL and your imports for all of your dependencies has to go in there. And a few other things that you might need, like if you're trying to deal with a certain type of change detection, you might specify something in the component decorator. And that's a lot to have to think about, it's a lot of extra code to look at.

因此我们正在研究如何减少这些负担。比如目前需要双重导入依赖项：既要在文件顶部通过标准JavaScript import导入，又要在组件装饰器中再次声明导入。这很烦人，我们希望能消除这种重复。

So we are looking at how we can reduce that. So one being like, you have to import all of your dependencies twice. You have to import it at the top of your file through your standard JavaScript import, and then you have to go into your component decorator and say you're importing it again. That's annoying. We wanna be able to remove that.

我们正在探索避免双重导入的方案。同时注意到还需要在装饰器中指定选择器——当在HTML模板中引用组件时，必须先在组件装饰器里定义选择器名称。比如想使用example-cmp，就需要先在装饰器中声明，再到模板中使用。我们希望也能消除这个步骤。

So we're looking at ways that we can avoid having to do the dual import. We're also looking at the fact that you also have to specify what your selector will look like in that decorator. So if you are in your HTML template and you wanna reference that component, you have to specify what the selector will be in your component decorator. So if you want it to be like example CMP, you have to go into the component decorator, specify that, and then you use it in the template. So we're hoping that we can eliminate the need to specify that too.

不过这些还处于早期阶段，核心目标始终是降低复杂度。我们还在持续改进服务端渲染功能。可能有些人不知道，过去社区开发的Angular Universal现已正式纳入框架体系，不再需要第三方库就能实现服务端渲染。

But we're really only in the early phase for that, essentially, again, trying to remove complexity for people. We're continuing down server side rendering improvements. For those that don't know, in the past, there used to be something called Angular Universal that was developed by our community. We actually officialized that as part of the framework now. So you don't have to have a third party library to do server side rendering.

我们正努力将框架与服务器端渲染能力更紧密地结合，并尽可能提升性能。这方面也有很多改进。现在开始使用Vite等现代构建工具。虽然很多框架都在做这些事，但我们也必须不断演进。我们还在研究诸如水合作用改进之类的事情，这一直是我重点关注的领域。

And we're trying to more closely tie the framework to the ability to server side render and make it as performance as we can. There's a lot of improvements there too. Things are using Vite now and trying to use modern build tools. I think a lot of frameworks are doing all of this, but we have to constantly evolve ours too. So we're also looking at things like improvements to hydration, which has been a thing that I've been focused heavily on.

除此之外，其他框架正在做的所有事情，比如缓存和验证策略以及部署相关的工作，这类事情也正在大量推进中。

But also on top of that, all of the things that a lot of the other frameworks are doing, like the cache and validation strategies and whatnot for deployment, That kind of thing is being worked on, gosh, so much.

你们团队规模不小，做了很多事情啊。

You've got a big team doing a lot of stuff.

我们确实做了很多，但其实团队规模并不大。我们很大程度上依赖社区帮助。所以如果你想贡献代码，欢迎提交PR。不过说实话，以我们现有的人力和工程时间来看，我们的目标确实很有野心。但我宁愿保持雄心，而不是安于现状。

We've got a lot, and we don't even have that big a team. We rely a lot on our community to help with us. So, you know, if you wanna contribute, you're welcome to put up a PR. But, yeah, we're very ambitious for the amount of people we have and the amount of, like, engineering hours we have available to us. So but I would rather us be ambitious than not.

确实。你们框架开发者所处的世界变化太快了。总是有新的竞争者提出一些疯狂的新概念，大家都喜欢，然后你们就不得不跟进。

Sure. Yeah. It's a very rapidly evolving world that you framework folks are are living in. I mean, there's constantly some new up and comer introducing some wacky new concept that everyone loves and you are expected to align with.

没错，我们这行业非常追逐潮流。

Sure. Very trendy, our industry.

说到这个，你应该能看出我是React开发者，因为我的很多问题都从这个角度出发。React领域长期存在关于是否应该服务器端渲染以及水合作用重要性的争论。有些人认为SSR很好，因为如你所说有利于SEO和性能；有些人讨厌它，因为会让单页应用更难开发。还有关于单页应用、多页应用、PESBA等各种概念的划分。嗯。

Speaking of which, there is you can tell I'm a React developer because many of my questions come from perspective. There's a big back and forth that's been going on for a while in React land of whether you should server side render and whether hydration is important. Some folks think that SSR is very good because, you know, as you mentioned, SEO performance, other folks hate it because it makes single page apps harder to build. And then there's the whole delineation of what's a single page app versus a multi page app versus a PESBA versus and so on. Mhmm.

作为专注水合作用开发的专家，你如何看待Angular在这个争论中的立场？或者你认为这些强制观点存在什么缺陷？

As someone who's now working in hydration, where do you see Angular or or do you see as the flaws of the the forced perspectives in that whole hullabaloo?

强制观点——我很喜欢这个术语，这是电影术语。关于SSR能提升SEO和初始加载速度的说法都是真的，但它确实会增加应用的复杂性。

Forced perspectives. I love that term. It's a film term. All of the things about like SSR improving your SEO and initial load, perceived initial load speed are true. SSR does that, but it sure does add complexity to your application.

我觉得很多人没意识到服务器不了解浏览器原生对象。服务器端渲染时，window这样的对象根本不存在。这在编写既支持SSR又能在客户端运行的代码时会带来很多问题，很多工程师尤其是初学者甚至没意识到这点。我认为并不是所有人都需要采用服务器端渲染。

I think a lot of people don't think about the fact that the server doesn't know about the browser's primitives. So when you're server side rendering, things like window don't exist. And that certainly adds a lot of issues when dealing with, you know, how do I write code that can be server side rendered and works in the client? And I think a lot of, especially early on engineers don't even realize that. I do think not everyone needs to reach for server side rendering.

我认为SSR（服务器端渲染）在你真正需要它的时候非常重要。我说的'需要它'是指，随着你的应用规模扩大、用户基数增长，你会逐渐意识到CSR（客户端渲染）应用的局限性。这时服务器端渲染就成了下一个选择，因为你确实需要SSR在初始加载时带来的那一点性能优势。我觉得目前行业内正在进行大量关于最佳实现方式的实验。比如，React服务器组件既被认为非常酷，也被认为处理起来和编码时非常困难。

I think that SSR really matters when you need it. And when I say when you need it, I mean like there will come a point where you realize that as your app gets bigger and as you have a user base that gets bigger, you will start to see the edges of where a CSR client side rendered app are. And server side rendering becomes the next go to because you just need that little edge of performance that SSR is going to give you on that initial load. I think what we're seeing in the industry right now is a lot of experimentation on the best ways to do it. Like, I think React server components are seen as both really cool and really difficult to deal with and code around.

你会看到各种不同的声音，比如：Angular什么时候会有类似React服务器组件的功能？或者：求别了，我们不想要React服务器组件那种复杂度。所以我认为所有的批评和赞扬都同样有道理，原因正是大家讨论的那些。我觉得人们真的应该思考：我是否需要它？如果确实需要，要知道一刀切的做法并不适用所有情况。

And you see a mixture of like, hey, when is Angular gonna get something like React server components? Or please no, we don't want the complexity of of React server component style work. So I think all of the criticisms and praise are equally valid for all of the exact reasons that are being discussed. I think people should really think about do they need it? And if they do need it, you know, one size does not fit all.

所以要思考：我为什么需要服务器端渲染？是因为觉得它很酷？是因为我真的需要SEO好处？是为了节省成本而想做预渲染或SSR？这些因素的最佳平衡点在哪里？这样我既能让开发团队开心（因为我们使用了更少的处理能力），也能让终端用户开心（因为网站加载更快，因为我们存在初始加载问题，用户因性能问题而离开）。

So think about why am I asking for server side rendering? Is it because I think it's cool? Is it because I genuinely need the SEO benefit? Is it for cost saving reasons that I wanna do prerendering or SSR? Where is the ideal mix of all of these so that I make my dev info team happy because we're using less processing power or I make our end users happy because the site loads faster, because we have a problem with our initial load and people are navigating away because performance is a problem.

我们是否试图通过某些做法为客户省钱？因为当人们想到SSR时，它实际上包含很多方面。不仅仅是'我在服务器上渲染'。它包括服务器端渲染、预渲染，以及随之而来的所有缓存系统。可能是这些方式的组合：你确定某些特定页面需要服务器端渲染因为它们需要性能，但网站上其他大量页面并不需要。

Are we trying to save our clients money by doing certain things? Because like when people think of SSR, it's actually quite a number of things. It's not just I'm rendering on the server. It's like server side rendering, pre rendering, all of the cache systems that come with that. It can be a mixture of all of those things where you've identified individual pages you wanna server side render because they need the performance, but a bunch of other pages on your site don't.

所以确实需要仔细思考，才能准确弄清楚你到底需要什么。

So it really takes careful thought to figure out exactly what is the thing that you need.

听起来你正在做这种仔细的思考。你提到正在研究水合作用（hydration）。有没有一个你兴奋地致力于实现的愿景或长期目标，可以分享一下吗？

Sounds like you're doing that careful thought. You mentioned you're working on hydration. Is there a vision or a long term goal that you're excited about working towards that you're able to share?

确实有一个愿景，但我不能谈论这个，因为那属于漫威电影宇宙的范畴。

There is a vision, but I am not allowed to talk about that because that's in the Marvel Cinematic Universe.

我以为他死了。这是剧透吗？他回来了。

I thought he died. Is that a spoiler? He came back.

我我是说，我也不想给任何人剧透，但是

I I mean, don't wanna spoil it for anybody either, but

我后悔说了任何话。

I regret saying anything.

就像我说的，我不能谈论这个，因为实际上不行。我认为对我们来说，水合作用多年来主要被视为一种不利因素，因为我们实际上并没有真正的水合。我们拥有的是所谓的破坏性水合，这是一个花哨的术语，意思是我们销毁并重新创建一切。但我们团队中的几个人被委以重任，去实现真正的水合。自那以后，我们的一个重点就是不断将其发展成一种易于人们使用、问题极少甚至没有、并且越来越先进的方式。

Like I said, I'm not allowed to talk about it because no, actually. So I think hydration for us was largely seen as a detriment for years because we didn't actually have it. We had what we call destructive hydration, which is a fancy term for we destroy and recreate everything. But a couple of us on the team were tasked with actually doing real hydration. And since then, it's been a big focus for us to continually evolve it in into a way that one is easy for people to use and has little to no issues is more and more advanced.

因此才有了增量水合这部分。对于那些不知道这是什么，或者部分水合是什么的人来说，它指的是能够将应用程序中服务器端渲染和水合的部分保留在页面上。其中一些部分可能是脱水的。这样你既可以获得所有这些延迟加载的好处，同时也可以让页面的某些部分保持脱水状态，直到有人真正需要那段代码。所以对我们来说，我们正在研究如何继续改善这种体验。

So hence the incremental hydration part of it. And for those that don't know what that is, or partial hydration, that is being able to leave portions of your application on your pages that are server side rendered and hydrated. Some of those sections might be dehydrated. So you can get the same benefits of all that defer loading while also leaving some of the page not hydrated until someone actually needs that code. So for us, we're looking at ways we can continue to improve that experience.

也许是资源的并行获取，也许是别的什么。我们研究过像 ASTRO 这样的东西，并且我们知道有人想用 Angular 和 ASTRO 一起工作。目前这是一个繁重的任务。也许我们将来会考虑这个。我不确定我们那里的超长期计划是什么，但本质上我们将继续发展和推进我们已有的东西。

Maybe it's parallel fetching of resources, maybe it's something else. We've looked at things like ASTRO and we know there are people who want to work with Angular and ASTRO. Right now that's a heavy undertaking. Maybe we'll look at that in the future. I'm not sure what our super long term plan is there, but essentially we will continue to evolve and advance what we have.

也许我们会研究一些我们称之为“岛屿”的东西，给那些不熟悉更高级形式水合的人。一个岛屿可能有点像嵌套的 React 服务器组件，或者像 Astra 所做的那样，但可能仍然略有不同，即你可以让应用程序的更大块内容保持脱水状态，但在这些脱水内容内部，有一个水合内容的“岛屿”位于其中。所以正是脱水块内的这种水合，使其成为你整个应用程序中的一个交互性小岛。这非常具有挑战性，因为 Angular 有层次化的依赖注入。所以我们的水合系统要求，当我们水合一个子组件时，其父级必须被水合，因为我们需要知道依赖关系。

Maybe we'll look at something like what we call islands for those that are unfamiliar with more advanced forms of hydration. An island would be kind of like maybe a nested React server component or something like what Astra does, but maybe still slightly different where if you can leave bigger chunks of your application dehydrated, but inside that dehydrated content you have an island of hydrated content that is in the middle of it. So it's that hydration within the dehydrated block that would make it a little island of interactivity within your whole application. It's very challenging because Angular has hierarchical dependency injection. So our hydration system requires that parents be hydrated when we hydrate a child component because we need to know the dependencies.

所以每当我们有一个最终被水合的脱水块时，如果它目前是其他脱水内容的子级，我们基本上必须一直向上遍历树并进行水合，然后再向下，以确保一切就位。但我们希望有朝一日能够支持定义一个应用程序部分的选项，你可以将其从该层次系统中分离出来，并创建一个交互性小岛。我们还在考虑的其他事情是，如何让我们的信号图影响水合？

So whenever we have a dehydrated block that you end up hydrating, if it's a child of other dehydrated content right now, we kind of have to go all the way up the tree and hydrate back down so that everything is present. But we hope to at someday be able to support the option of defining a section of your app that you want to detach from that hierarchical system and be able to make a little island of interactivity. Other things we're thinking about are how could we make our signal graph affect hydration?

你知道，这太不可思议了，我们讨论的所有事情——水合、服务器端渲染、导入、延迟——这些都交织在一起并相互影响。这不是一个可以单独投资的直接领域。你必须通盘考虑。

You know, it's incredible that all the things we've talked about, hydration, server rendering, imports, defer, these all spin together and impact each other. It's not one direct line of area to invest in. You have to think about the whole thing.

是的，完全正确。如果你看，一切都是垫脚石，对吧？当你致力于改进一个系统时，你无法从 A 直接跳到 G，除非你是企业号航空母舰（USS Enterprise），但你可以从 A 到 B，然后从 B 到 C。我们的水合历程就是如此。我们必须先构建我们真正的水合系统，才能实现增量水合。

Yes, exactly. And if you look at everything's a stepping stone, right? When you're working on improvements to a system, you can't go from, A to G unless you're the USS Enterprise, but you can go from A to B and then B to C. And our hydration story has been that. We had to build our real hydration system in order to get to incremental hydration.

我们必须构建，我们从水合开始，然后我们研究了我们的可延迟系统。为了实现增量水合，我们需要这两者。所以这些中的每一个都是我们未来改进这些功能如何工作的垫脚石。

We had to build, we started with hydration, then we looked at our deferrable system. In order to get to incremental hydration, we needed both of those. So each of these are a stepping stone in our future of improving how these things work.

我迫不及待想看看未来几年会出现什么。但我们只剩下几分钟了。我还有最后两个问题要问你。你提到了企业号（USS Enterprise）。首先，见到勒瓦尔·伯顿（LeVar Burton）是什么感觉？你是怎么见到他的？

I can't wait to see what comes up in the next few years. But we only have a few minutes left. I have just one or two last questions for you. You mentioned the USS Enterprise. First of all, what was it like meeting LeVar Burton and how did you meet LeVar Burton?

哦，天哪。我是一个巨大的《星际迷航》粉丝。我形容《星际迷航》是我的初恋。我从很小的时候就是粉丝了。是看着《下一代》长大的，里面有勒瓦尔·伯顿饰演的乔迪·拉弗吉中校，总工程师。

Oh gosh. So I'm a huge Star Trek fan. I described Star Trek as my first love. I have been a fan since early childhood. Grew up with the next generation, which has LeVar Burton in it as lieutenant commander Geordie LaForge, the chief engineer.

去年，我有机会参加了一个大会，星际迷航大会。是的，我就是那种书呆子。在纽约州北部的提康德罗加，有人在那里建造了一个完整的USS企业号复制品，就是原初系列里的那艘，你可以去参观，然后他们会在那里举办大会。所以我去了Trekondoroga（这是大会的名字），几位星际迷航的演员也在场，包括乔纳森·弗雷克斯和拉瓦尔·伯顿。

And this past year, I got to go to a convention, Star Trek convention. Yes. I am that kind of nerd. In Upstate New York at Ticonderoga's, there's somebody there who's built a full replica of the USS Enterprise, the original one from the original series that you can go and tour, and then they they have conventions there. And so I got to go to, Trekondoroga, which is the name of the con, and several Trek actors were present, including Jonathan Frakes and LaVar Burton.

所以我见到了他们两位。拉瓦尔正是你希望他成为的那种人。我知道人们常说永远不要见你的偶像，但拉瓦尔真的是我们这个时代的弗雷德·罗杰斯。他是一个很棒的人，体贴、有同理心、关心他人。听到观众席中有人说他是国宝，房间里大多数人，包括拉瓦尔自己，都眼眶湿润了。

So I got to meet both of them. And LaVar is exactly the person you want him to be. Like, I know they say never meet your heroes, but Lavar truly is the Fred Rogers of our age. He is a wonderful human being and thoughtful and empathetic and caring. And just listening to someone in the audience say that he is a national treasure and kind of most of us in the room, including Lavar, kind of tearing up.

那真是太棒了。非常棒。我强烈推荐，如果你有机会见到他和乔纳森·弗雷克斯——他也很棒——我强烈推荐你去。

It was just wonderful. It's wonderful. I highly recommend the if you have the opportunity to meet him and Jonathan Frakes, he was wonderful too. I would highly recommend that.

我对这两位演员都感到很兴奋。他们都是非常有趣的人。尤其是拉瓦尔·伯顿。我最近开始听他的‘拉瓦尔·伯顿朗读’播客。每一集都是一个不同的短篇故事，非常出色。

I'm excited about both actors. They're both fascinating people. LaVar Burton in particular. I recently started listening to his LaVar Burton reads podcast. Every episode is a different short story, and it's phenomenal.

他是一位不可思议的朗读者，有一系列非常棒的书可以读。

He's an incredible narrator with a great great set of books to read.

他绝对是。绝对是。

He absolutely is. Absolutely.

我最后一个问题是，你能为我们解释一下Angular麦片是什么以及为什么会有它吗？

The last question I have for you is could you explain the what and why of Angular cereal for us, please?

Angular麦片。好的。对于那些不知道的人，一年前的4月1日，我们发布了一个Angular麦片的广告。你可以去我们的YouTube频道观看。那是我搞的一个傻傻的创作。

Angular cereal. Okay. So for those that are unaware, a year ago, April 1, we released a commercial for Angular cereal. You can go on our YouTube channel and watch it. And that was my silly creation.

它的由来是一年前为NG Conf（一个较大的以Angular为重点的活动）准备的，我们开发关系团队的几个成员要在台上做一个演讲，作为准备，他们问我是否能为它制作一个广告，因为他们要做的是一个新闻播报主题的演讲。所以他们想在台上时切入广告，然后播放一些搞笑的内容。他们就说，随你做什么。于是我的脑子就想到了Angular麦片这个概念。所以我设计了麦片片，并用3D打印出来，还为它设计了一个盒子。

Where it came from is a year ago for NG Conf, which is one of the bigger angular focused events, couple of our DevRel team members were doing a talk on stage and as a prep for that, they asked if I would produce a commercial for it because they were doing a talk that wasn't like a newscast theme. So they wanted to be like on stage and then cut to commercial and then show something silly. So they're just like, do whatever you want. And out of that, my brain went to angular serial as a concept. So I designed serial pieces and three d printed them, and we had a box design made for it.

然后我自己在我整个房子里拍摄了这个广告，在屏幕上扮演了多个角色，非常荒谬。我记得在拍这个广告的时候我在想，我现在在干什么？我是怎么走到这一步的？自那以后，没错，Angular就成了这份完整早餐的一部分。所以实际上，在我背景里——我知道这是个播客，没人能看到——但这个麦片盒子就作为道具放在我身后，还有拍摄时也用到的Boring O's麦片盒。

And I shot this commercial by myself in my whole house and played multiple characters on screen and was ridiculous. I remember thinking while I was shooting this commercial, what am I doing right now? How did my how did I get here? Since then, yeah, Angular has been a part of this complete breakfast. So I have actually in the background of I know this is a podcast, so nobody can actually see it, but the the cereal box sits behind me as a prop, as well as the boring o's cereal box that was also part of the shoot.

所以这些东西会一直跟着我到处走。这就是它的由来。之后我们决定，为什么不把它作为一个愚人节视频发布，让大家一起乐一乐。我不知道现在有多少人看过，但上面的评论很棒。在那次NG Conf上，我还分发了3D打印的序列号碎片，让大家当作小纪念品带走。

So those will will travel with me wherever. That's where it came from. And we decided after that that why not release it as an April fools video for everyone to enjoy. I don't know how many people have watched it now, but the comments on it are great. And at that NG Conf, I actually handed out pieces of the three d printed serial for people to take as a little souvenir.

所以那是一段美好时光。

So it was a good time.

真的把你之前的通讯视频制作功底都发挥出来了。

Really pulling in your communications video production back.

哦，是的。没错。没错。我很喜欢在这个团队里能真正运用那些技能。

Oh, yes. Yes. Yes. I love the fact that I actually get to use those skills when I'm on this team.

就像早餐一样，你是个多面手。顺便说一句，里面有句超棒的台词。就想提一下这句妙语：‘我不是你妈妈’，这让我想起了《废柴联盟》第六季片尾彩蛋的场景。做得真的很棒。

Much like the breakfast, you are well rounded. There's this great line, by the way. Just wanna pick on this great line in it. I'm not your mom, and it reminded me of the community post season six after credit scene. It was really well done.

不错。

Nice.

谢谢。谢谢。

Thank you. Thank you.

太好了。嗯，我们已经超时了。Jessica，非常感谢你参加节目。如果大家想了解更多关于你和/或Angular的信息，你有什么特别推荐他们去互联网上的什么地方吗？

Great. Well, we're already over time. So Jessica, thank you so much for hopping on the show. If people want to learn more about you and or Angular, is there anywhere in particular you direct them on the internet?

嗯，如果他们想了解Angular，可以去angular.dev，也可以去我们的YouTube频道，就是Angular的YouTube频道，你经常会看到我在发布视频里做些傻乎乎的小片段。如果你想具体了解我，我所有的社交媒体……好吧，是部分社交媒体。如今，我在Blue Sky上，也在Mastodon上。

Well, if they want to learn about Angular, you can head over to angular.dev, you can head over to our YouTube channel, which is you know, the Angular YouTube channel, where you will see me often doing silly bits in the release videos. And then if you wanna learn more about me specifically, I'm on all of the socials. Well, I am on some of the socials. These days, I'm I'm on Blue Sky. I'm on Mastodon.

我希望Flashes推出安卓版时也能加入，因为我是安卓用户。我还有一个Linktree，你可以在jessicajanick.com找到，那应该能带你找到我目前所有的平台。

I am hoping to be on Flashes when that comes out for Android as I'm an Android user. And I do have a link tree. You can find that at jessicajanick.com. And that should get you to all of the things that I am currently on.

太好了。非常期待能实现这一点。这里是《软件工程日报》的杰西卡·贾尼克和乔什·戈德堡。大家干杯。

That's great. Looking forward to doing that. For Software Engineering Daily, this has been Jessica Janick and Josh Goldberg. Cheers all.

是的，生生不息，繁荣昌盛。

Yeah, live long and prosper.