Dana Lawson 分享了她的技术背景、讲解了 JavaScript，深入探讨了 Netlify 如何处理自己的网络资产。
译自 Netlify’s Approach to the Frontend According to Its New CTO，作者 Loraine Lawson 是一位资深的技术记者，涵盖了从数据集成到安全等技术问题长达 25 年。在加入 The New Stack 之前，她担任银行技术网站 Bank Automation News 的编辑。
Netlify 的新任首席技术官 Dana Lawson 坦言：她觉得 JavaScript “令人头痛”。这个承认有点羞怯，因为这家基于云的 Web 开发平台的目标受众是前端开发人员。
“我曾经对 JavaScript 进行了一次‘牛仔表演’。我是一个糟糕的 JavaScript 开发者，而且我在一家前端公司工作，” Lawson 笑着说。“我总是告诉 [Netlify CEO] Matt Billmann，也许我正处于正确的位置，因为我知道 JavaScript 是多么令人痛苦。”
尽管如此，上个月晋升的 Lawson 对 JavaScript 框架领域的所有发展感到兴奋。
“你看看 Remix —— Remix 以一种方式处理它，你来到这里，你看看 Astro、Solid，再次，Next，他们真的在推动[…] JavaScript 和无服务器在做 ISR [增量静态再生] 和流式处理方面的能力时，它是不可思议的，”她说。
然而，她确实在想这一切是否都是有代价的。
“在另一方面，我想[…] 等等，我们为什么要让网页变得更难呢？”她说。“网页应该是快速的，应该是易于接近的。”
正是这个原因使她从 GitHub 的工程副总裁职位上来到了公司，她说。在 Netlify 简化努力的其中一项是其最近推出的面向企业的可组合 Web 平台，Lawson 将其列为一种帮助开发人员解决安全性和合规性等挑战的工具。
“当我在 GitHub 时，它是关于赋权开发者，让他们能够做更多、创新，并推动人类进步，”她说。“现在在 Netlify，我们能够做到这一点，但与更多不必是全栈工程师的参与者一起，他们可以是前端工程师，在自己擅长的领域成为专家，并仍然拥有创新的自主权和代理权。”
在晋升之前，Lawson 担任 Netlify 的高级副总裁工程师，但她的职业生涯始于军队。
“我从未想过我会在科技行业，因为在 90 年代末我在新墨西哥东南部长大 —— 不以其科技场景而闻名，更以橄榄球和石油而闻名，”她说。“我想要摆脱沙漠中的贫困，找到自己的出路。我加入了军队，我一直对科学和数学有一种天赋，并且有一个新的领域正在兴起。我知道我可以呆在里面，因为计算机需要空调 —— 这是我的逻辑。这就是我进入这个领域的方式。”
军队让她经历了一年的密集学习，从网络到编程，她说。她学习了 Java，但主要在系统方面工作，担任 Unix 管理员，并使用 IBM WebSphere。在语言方面，她自称是“Go 迷”。她也喜欢 Python。
“我很高兴 AI 和 ML 回来了，因为 Python 太棒了，”她说。“它非常直观。这真的很令人兴奋。我没料到 Python 会像现在这样回来。”
我们询问了 Lawson 关于 Netlify 自己管理前端的方法。作为一个以推动 Jamstack 为人所知的公司，Lawson 表示，Netlify 自己的 Web 资产是 Jamstack 和无头的。她补充说，它有用 Eleventy、Astro 和 Next 构建的网站。
“随着世界继续思考计算、速度和首字节时间，以及老实说，这些生成式 AI 工具的快速演变。当这些模型在手机上运行时 —— 因为它们会 —— [...] 这将是一个全新的局面，”她说。“浏览器和无服务器仍然将统治至上，因为你将希望为繁重的工作保存计算、能量和带宽。”
由于 The New Stack 最近关注了前端的单一仓库问题，我们询问了 Lawson Netlify 是如何处理仓库的。她承认这对技术领导者来说是一个重要的讨论，并相当谨慎地回答了这个问题。
“你必须为合适的工作找到合适的工具，”她说。“作为新晋的 CTO 类型，我们只是希望拥有同质化的系统，以便我们可以减少复杂性，提高生产力。我觉得我在过去做出了错误的决定，比如，嘿，让我们完全转向微服务，远离单一仓库和单体架构，这样我们就可以更好地分离服务。”
但是，这种方法可能会带来更多问题，公司可能会比仅仅坚持使用单一仓库时面临更多问题，她补充说。考虑单一仓库与多仓库时，代码只是旅程的开始，她警告道。
“我现在的看法是你必须全面考虑，并真正了解你正在解决什么问题，你正在解决技术上的什么问题，我认为没有一套系统可以统治一切，” Lawson 表示。
她说，人们经常放弃单体架构是因为他们达到了扩展能力的限制。相反，她建议更好地考虑开发团队愿意接受的权衡和风险，以及团队的规模与业务结果之间的关系。
“是否有任何一套系统可以统治一切？我认为这是一个陷阱。”