iyuki22 / weekly Goto Github PK

本文是来自 Red Hat 的工程师 Bryant Son，原文在 2020 年发布（比较早，有些工具其实已经更新，不影响），主要对 DevOps、pipeline、CI/CD 相关术语做了介绍。如果一般只使用基建而不是做这块的话，对 DevOps 中涉及的一些概念不一定很了解。阅读本文，能够让我们对 DevOps 有一个全局的认知。Enjoy :)

原文划重点

DevOps automation tooling is often discussed as a pipeline. Here's what that means to your system architecture.

DevOps 自动化工具常被称为 pipeline 流水线。

Constructing a DevOps pipeline is an essential part of a software architect's process when working in a software engineering team. In the past, as I participated as a technical interviewer at Red Hat, I was quite surprised to find very few people could clearly describe a DevOps pipeline and a continuous integration and continuous deployment (CI/CD) pipeline. You will understand what these pipelines are by reading this article.

如果你在软件工程团队工作，那么构建 DevOps pipeline 是实现软件架构的重要一环。面试时很少有能把 DevOps pipeline、持续集成和持续部署 CI/CD 说清楚的，本文来给做一个科普。

In this article, you learned about the heart of DevOps and DevOps pipelines. You also learned how to create DevOps pipelines from two different perspectives: One with infrastructure engineers in mind and one for the application developers. You also saw the difference between continuous integration (CI) and continuous delivery (CD) processes and how the industry trend is to separate the two.

阅读本文，了解 DevOps、DevOps 流水线以及从两种不同的视角创建 DevOps 流水线：基础设施工程师；应用开发工程师。了解 CI 和 CD 之间的区别以及业务逐渐将两者分开。

一图解读

人工智能简史

基于 22 年的预热，今年 AI 彻底爆发，2023 已经被定义为 AI 元年。近期关于 GPT-4、stable diffusion 以及 OpenAI、Midjourney、Notion AI、New Bing 等的文章满天飞，有兴奋、有焦虑，这波浪潮，将会给各行业带来怎样的巨变？

从了解历史开始。

图一、两条时间线：一是 computer - microprocessor - internet - iPhone - now；另一是 notable AI systems
图二、手写识别、语音识别、图片识别、阅读理解、语言理解能力打到人类水平
图三、AI 生成图片能力
图四、解释笑话 - 阅读和语言理解能力
图五、AI 在过去 80 年的崛起

图片来自文章《The brief history of artificial intelligence: The world has changed fast – what might be next?》
地址：https://ourworldindata.org/brief-history-of-ai

一图读懂《10 Web Development Trends in 2023》

原文地址：https://www.robinwieruch.de/web-development-trends/
另附 State of JS 2022 地址：https://2022.stateofjs.com/en-US/

一句话总结

作者 Robin Wieruch ，来自德国的自由职业者，全文基于 State of JS 2022 来介绍他所看到的 10 个 Web 开发趋势。通过阅读这篇文章，结合 State of JS 的问卷结果以及大家各自的开发经历，相信对 Web 相关技术和生态的了解会更加全面和深刻。

原文划重点

While, in my personal opinion, the web development landscape slowed down for a few years (2016 - 2021), it started to gain lots of traction just last year (also see State of JS where the images for this article are taken from). In this article, I want to point out new web development trends that I have seen, which are certainly trends which I expect to continue sparking interest among web developers, and which I am excited about for the next year. Let's get right into them ...

首先表达了个人对 Web 开发的一个看法：之前 2016 - 2021 这 5 年 Web 开发生态整体放缓，去年 2022 情况出现好转。本文中作者讲他看到的 Web 开发新趋势。

Anyway, hopefully I was able to provide you with a great overview of the status quo in the web development ecosystem.

本文为大家带来 Web 开发生态现状概览。

一图读懂

一图读懂《Introduction to Defensive CSS》

原文地址：https://defensivecss.dev/articles/intro-defensive-css/

一句话总结

本文作者是前端兼设计师 Ahmad（之前有解读过他的《The Guide To Responsive Design In 2023 and Beyond》），主要介绍 CSS 防御性编程（Defensive Programming）—— 防御性设计 Defensive design 在 CSS 上的体现。文章内容不多，通过几个示例，让前端以及设计师了解看似完美设计和实现，可能会在边界情况下出现各种问题，从而引起重视。

原文划重点

Back in December 2021, I wrote an article titled Defensive CSS. I used that term because that's really what is it about. I wanted a term that communicates the concept of writing CSS that prevents unexpected layout behaviors, or at least, reduces them.

作者在 2021 年底的时候已经写过一篇介绍防御性 CSS 编程的文章，提出了 “防御性 CSS” 这一概念。

It turned out that defensive CSS doesn't only apply to CSS, but UI design as well. As a designer, you need to either work on visual variations of a component with all the possible use-cases or at least communicate them clearly with the development team.

防御性设计的实现不仅需要 CSS，还需要设计师。设计师需要将组件各种情况下的视觉都设计好，最起码让开发者了解。

In this introduction article, I will shed the light on why it's important to design and write CSS defensively, and how we can take it from there.

在这篇文章中，主要介绍防御性设计、防御性 CSS 编程以及开发者应该从何开始。

一图读懂

一图读懂《2023 年大淘宝 Web 端技术概览》

原文地址：https://mp.weixin.qq.com/s/9JCqhRh2cIkyXEAOLI6N5Q

一句话总结

原文是对大淘宝 Web 前端总结性的文章，主要介绍了大淘宝团队新的组织协作形态及其当下的技术方向和技术产品。阅读文章对了解大淘宝前端技术非常有帮助，也对了解前端前沿技术以及前端实践重点有所指导，推荐。

原文划重点

2022 年，大淘宝前端团队进行了调整：重新组织生产关系，按业务线拆分整合进对应的业务技术团队，同时保留了大前端虚线组织，确保研发基建的一致性、技术的持续投入以及推进人员的成长。

2022 年大淘宝前端团队进行了调整，设大前端虚线组织，技术团队进业务线。

整个变化涉及超过三百人的前端团队，经过了半年多的运转，整个团队在技术上也进行了对应的聚焦和收敛。

团队人数超过三百人，新的组织形态已经运行了半年多，技术聚焦和收敛。

新的组织协作形态下，大淘宝 Web 领域的工程师们正在做哪些技术工作、有什么技术产品，特在 2023 年开年之际向行业前端同学进行分享。

说明原文整体会介绍大淘宝 Web 领域的划分，包括技术产品和技术方向。

我们按工程、研发、应用三个领域进行分层梳理了淘宝的技术地图。

工程：包括前端工程和研发质量保障，提供前端开发需要的研发平台、研发工具、调试、监控告警等。

研发：包括运行容器、开发框架、搭建体系。

运行容器有 Web 容器、自研 Hybird 容器以及云原生 JavaScript 容器。

开发框架有前端框架和 Node.js 框架。

搭建是自研的低/零代码系统（内部代号天马）。

应用：基于工程和研发，面向不同场域、不同用户提供相应的应用，包括面向 C 端消费者的前台应用，面向 B 端商家、达人、运营的中后台应用。

主要划分三个方向：工程、研发和应用。详细方向看下文大图。

同样是在 2022 年，阿里巴巴集团启动了终端人才升级项目 - 将前端开发、移动 App 研发等端技术融合成终端技术，对应的技术人才也统一到终端域，为工程师个体拉宽了技术通道，也为未来提供了更多的可能性。

介绍前端和移动端融合的现象，边界更加模糊。人才模型上也是如此，也对技术人才的要求上，更加宽阔。

一图读懂

重塑低代码开发：人工智能的智慧赋能

科技是解放生产力的第一要素，人工智能是推动科技发展的最大驱动力。 -- 马化腾

科技是推动人类进步的重要动力之一，而作为当今"互联网+"时代重要技术变革之一的人工智能技术，正引领着世界各国技术革新的新大潮。与此同时，人工智能技术的应用也在逐渐改变和重塑着当前的各个领域。在低代码开发领域中，人工智能技术的智慧赋能，对于程序开发效率和质量的提高具有重要意义。本文将从视觉编程、用户界面设计、程序预测和程序质量监测等四个方面，深入探讨人工智能技术如何助力并重塑低代码开发。

人工智能与低代码开发的新篇章

人工智能作为当前极具潜力的技术之一，已经得到了广泛的应用探索。在低代码开发领域，人工智能与机器学习等技术融合后，将为低代码开发带来新的机遇。视觉编程是低代码开发的主要技术之一，在视觉编程中，人工智能技术可以智能化地扫描底层数据，对数据进行模式识别、分类和分析，使得视觉编程系统可以自动生成代码组件，让开发人员通过拖拽组件进行开发。并在通过自然语言处理技术的自然语言编程后，程序代码更可以实现自动转化。此外，在程序开发中，人工智能技术也可以通过算法自动完成代码生成，在低代码开发领域中实现大幅提高开发效率。

用户界面设计和程序预测中的人工智能应用

在用户界面设计领域中，人工智能技术可以对用户的喜好进行预测，并生成更加适合用户的界面，从而提高用户体验。在程序预测和分析方面，人工智能技术可以基于历史数据分析未来的程序变化，结合自动化测试技术，实现开发预测，对程序进行有效控制。这将使得程序的设计、开发和上线更加自动化和效率化，在当前开发环境下大大提高代码的稳定性和可靠性。

自动化监测与程序质量控制

在低代码开发中，人工智能技术还可以通过自动化监测对程序质量进行评估，自动生成测试用例等等。对于视觉编程所涉及到的程序，在生成代码组件后，人工智能技术可以检测组件的使用情况以及现有组件的质量，并运用算法来进行代码多重检测，提高程序的质量与可靠性。此外，程序异常监测也为人工智能技术在低代码开发中发挥作用提供了新的突破口，结合过程重构技术，人工智能技术可以对程序错误和异常进行实时监测，从而优化代码的运行质量和稳定性。总之，人工智能技术在低代码开发中的自动化监测与程序质量控制，不仅提高程序的可靠性，还为程序开发提供了更加智能化的支持。

人工智能推动低代码开发升级与优化

通过当前技术发展与实际生产的需求不断推进，人工智能技术在低代码开发中正逐渐发挥更为重要的作用，与此同时，也将会引领低代码开发整体的变革。借助人工智能技术的智慧赋能，许多低代码开发服务商都在提供更加高效与可靠的视觉编程服务，这将有助于低代码开发模式快速推广并得到更多的应用。并且，随着人工智能技术的不断发展，相信其在低代码开发中的作用还将继续扩大，为人们创造出更智能、更高效、更具可靠性的新应用。

结语

总体而言，在低代码开发中，人工智能技术的应用可以极大地提高开发效率、优化开发质量，并还有助于创新出更具创造性的代码设计方案。但同时，人工智能技术的实际应用仍需要加强算法模型、模拟人类行为能力和规避数据偏差等方面的研究，以期实现更为优秀的效果。我们相信，在不断的探索和发展中，人工智能技术将继续发挥着其更多的智慧与能力，为低代码开发带来更愉悦和值得期待的新篇章。
以上。

通过阅读本文，相信大家已经了解了关于人工智能如何赋能低代码开发。不过需要说明的是，这些并不是我写的，而是我给了 ChatGPT 几个问题

写一篇引言引用名人名句、有四个段落的文章，主题是关于人工智能如何助力、重塑低代码开发
为这篇文章起一个尽可能有吸引力的标题
每一段展开讲讲并为每一段增加一个小标题
将以上内容整合成一篇可以投稿的文章，字数 3000 字左右

当然，最开始引言中的话应该也并不是马化腾亲口说的，我问了一下 ChatGPT，他说是根据他的一些话 “理解总结” 后给出的。感叹一下，稀缺的永远是我们的注意力。

最后，引用一句原话，来自比尔·盖茨 -- The Age of AI has begun.

一图读懂《The Web’s Next Transition》

原文地址：https://www.epicweb.dev/the-webs-next-transition

一句话总结

作者是从事前端教育的 Kent C. Dodds，在 Web 社区影响力排名也比较靠前。本文是他加入 Remix 之后介绍该框架如何引领 Web 开发的下一次演进。

原文划重点

The web is made up of technologies that got their start over 25 years ago. HTTP, HTML, CSS, and JS were all first standardized in the mid-nineties (when I was 8 years old). Since then, the web evolved into a ubiquitous application platform. As the web has evolved, so too has the architecture for the development of these applications. There are many core architectures for building applications for the web these days. The most popular architecture employed by web developers today is the Single Page App (SPA), but we are transitioning to a new and improved architecture for building web applications.

核心引出本文作者要讲的 Next Transition - PESPA。Web 有着悠久的历史，从 90 年代中期的 HTTP、HTML、CSS、JS 演进到现在成为无处不在的应用平台，过程中有很多开发 Web 应用的核心架构，前几年最流行的就是 SPA，然而现在正朝着下一架构演进。

Each architecture of web development has benefits and pain points. Eventually, the pain points became enough of a problem to motivate the move to the next architecture which came with its own trade-offs.

每个框架都有其优缺点，而缺点是推动框架演进的动力。

Personally, I’m super here for this transition. Getting a better UX and DX at the same time is a solid win. I think it’s an important one and I’m excited about what the future holds for us.

SPA 最大的优点是其带来的 DX 体验，而其 UX 体验很糟糕（如 Fetch Loading)，所以作者这里说 UX 和 DX 都变好才是真的好。

一图读懂

一图读懂《Our top Core Web Vitals recommendations for 2023》

原文地址：https://web.dev/top-cwv-2023/

为了较全面的学习和掌握，下文还有原文中引用的几篇文章的内容，更易于理解，感兴趣可以阅读原文逐一查看。

一句话总结

Chrome DevRel 团队 2023 推荐的提升 Core Web Vitals 性能的一系列最佳实践。从 Core Web Vitals 中的 Largest Contentful Paint (LCP)、Cumulative Layout Shift (CLS)、First Input Delay (FID) 三个指标来展开，文中引用了许多在平时总结的文章，推荐阅读。

一图读懂

原文划重点

Over the years, we at Google have made a lot of recommendations to web developers on how to improve performance.
While each of these recommendations, individually, may improve performance for many sites, the full set of recommendations is admittedly overwhelming and, realistically, there's no way any one person or site could follow all of them.
Unless web performance is your day job, it's probably not obvious which recommendations are going to have the largest positive impact on your site. For example, you might have read that implementing critical CSS can improve load performance, and you may have also heard that it's important to optimize your images. But, if you don't have time to work on both things, how would you decide which one to pick?

核心表达之前已经做过很多次的性能优化推荐了，但是之前推荐就有点大而全，比较难执行。

On the Chrome team, we've spent the last year trying to answer this question: what are the most important recommendations we can give to developers to help them improve performance for their users?
To adequately answer this question we have to consider not just the technical merits of any given recommendation, but also human and organizational factors that influence the likelihood that developers will actually be able to adopt these recommendations. In other words, some recommendations may be hugely impactful in theory, but in reality very few sites will have the time or resources to implement them. Similarly, some recommendations are critical, but most websites are already following these practices.
In short, we wanted our list of top web performance recommendations to focus on:
● Recommendations we believe will have the largest real-world impact
● Recommendations that are relevant and applicable to most sites
● Recommendations that are realistic for most developers to implement

灵魂发问：哪些是提升性能最最推荐的方式。有些推荐理论上可行，但是现实可能由于各种情况无法执行；有些推荐很好，但是大多数站点已经都有实践。所以，这次基于几个原则来写这篇文章。

Over the past year we've spent a lot of time auditing the full set of performance recommendations we make, and assessing each of them (both qualitatively and quantitatively) against the above three criteria.
This post outlines our top recommendations to improve performance for each of the Core Web Vitals metrics. If you're new to web performance, or if you're trying to decide what will give you the biggest bang for your buck, we think these recommendations are the best place to start.

介绍文章会从 Core Web Vitals 的三个指标来推荐最佳实践。

一图读懂《Understanding typography》

原文地址：https://m2.material.io/design/typography/understanding-typography.html

一句话总结

本文来自 Material UI 官方文档，从 Type properties、Type classification、Readability 三个方面介绍字体。阅读本文，相信对 “字体” 应该会有一个全面的认识。

原文划重点

A typeface is a collection of letters. While each letter is unique, certain shapes are shared across letters. A typeface represents shared patterns across a collection of letters.
Typefaces that are selected for their style, legibility, and readability are most effective when following the fundamental principles of typographic design.

字体是字母的集合，虽然每个字母不一样，但是特定的字形是想通的，字体代表了字母相似的模式。每种字体的 style、legibility、readability 是字体设计的基础原则。

Names of letterform parts: aperture, ascender, baseline, cap height, descender, leading, letter-spacing, sans serif, serif, stem, stroke, x-height

字体中字母相关的术语。

While legibility is determined by the characters in a typeface, readability refers to how easy it is to read words or blocks of text, which is affected by the style of a typeface.

legibility 和 readability 强调的重点不一样，前者由字体的特点决定，后者是指阅读体验，受字体样式的影响。

Android - Roboto system font; iOS - San Francisco system font. Roboto is the default system font for Android. For platforms outside of Android and web products, use a system typeface that is preferred on that platform. For example, iOS applications should use Apple’s San Francisco font.

Android 和 iOS 中系统默认字体不同。

一图解读

𝟸𝟶𝟸𝟹 前端最受欢迎的 𝟷𝟶 款构建工具

上周 ByteDance Web Infra 团队宣布开源了已经做了 11 个月的基于 Rust 实现的 Rspack，前端领域又多了一名基于 Rust 实现的构建工具。其实在开源社区已经有不少，上图 2 中列出了截止 2023 年 3 月最受欢迎的 10 款。

至于 Rspack 最终在社区中接受和参与度如何，还得看其完善度和优势，毕竟业务场景中切换后的回归成本一定不会小。不过近两年 Evan You 主导的 Vite 是非常受欢迎的，2022 年 The State of JS 报告 7 项 Awards 中 Vite 独占 3 席，可在图 3 中了解。

回到构建工具。伴随着前端开发步入基于组件的开发方式（component-based development, CBD），各种框架层出不穷，构建工具也随之不断地迭代，上图 4 是从 2011 年至今，那些被广泛应用过的构建工具。桃花依旧笑春风，或许未来，它们都将不再流行。

一图解读《How To Eliminate Render Blocking Resources》

原文地址：https://www.debugbear.com/blog/render-blocking-resources

一句话总结

本文来自 DebugBear 官方博客，关于影响网页性能的 render blocking resources 的介绍以及如何解决带来的问题。虽然文章目的之一是为了宣传其性能检测工具，不过我们确实可以从中了解到 JS、CSS 以及其它各种资源如何在不经意间阻塞页面渲染影响页面性能的。

原文划重点

Render blocking websites can slow down your website and increase Core Web Vitals metrics like the Largest Contentful Paint.
This article explains the performance impact of render blocking resources and what you can do to solve these issues.

渲染阻塞会让网站变慢，增加 Core Web Vitals 的指标。本文介绍了渲染阻塞资源对性能的影响以及如何解决。

JavaScript and CSS files can be render blocking.

JS 和 CSS 文件能够阻塞渲染

Web fonts don't block rendering of the page, but they can block rendering of the text itself. Waiting for web fonts can slow down your First Contentful Paint if no other content is rendered on the page.

字体不会阻塞渲染，但可能会影响文本渲染本身。在没有其它资源的情况下，可能会影响 FCP

Images are not render blocking. They can delay metrics like the Largest Contentful Paint, but the rest of the page will still render fine even if the browser is still downloading an image file.

图片不会阻塞渲染，但可能会影响 LCP

一图解读

一图读懂《The new wave of Javascript web frameworks》

原文地址：https://frontendmastery.com/posts/the-new-wave-of-javascript-web-frameworks/

一句话总结

文章比较全面地介绍了 JavaScript Web Frameworks 的演进，通过回顾构建大型 Web 应用时的痛点，了解每种框架基于对不同问题 trade-offs 给出不同解法，从而深刻理解现代元框架 meta frameworks 是如何演变而来。博古通今，十分推荐。

原文划重点

Staying current in the Javascript ecosystem is not for the faint of heart. It’s challenging for those entering the industry to follow what’s happening amongst the new libraries, frameworks, concepts, and strong opinions.
We’ll make sense of the current landscape by looking at the past pain points when building large-scale web applications.
Rather than focus on the proliferation of solutions, we’ll dive into the underlying problems. Where each framework gives different answers and makes different trade-offs.
By the end, we’ll have a high-level model of popular frameworks like React, Svelte, Vue, Solid, Astro, Marko, Fresh, Next, Remix, Qwik, and the “meta frameworks” fit into today’s landscape.
It’s helpful to understand the past to make sense of the present. We’ll start with a trip down memory lane to see the path behind us.
This story’s been told before. This time we’ll focus on the problems on larger projects that sparked alternative approaches and ways of thinking.

JS 生态繁荣，更新非常快，想要跟踪了解各种概念、类库、框架有一定难度。本文较全面地回顾过去，让读者了解现代构建大型 Web 应用的框架全景。

There’s no one universal answer to what is the best framework, architecture or pattern mentioned in this post and the countless others we didn’t mention.
It’s always a tradeoff against specific metrics. And knowing what to tradeoffs to make will depend on what you are building. Who your users are, and their usage patterns. And whatever other requirements around key user experiences (like performance budgets) are set.
For most of us, the truth will be somewhere in the middle. The great thing about the new wave of frameworks and innovation is that they provide levers to scale up and down as needed.
For those coming into the industry and those experienced alike it’s always a good bet to invest in the fundamentals.

很难回答哪个框架是最优解，它们都是面向不同问题的结果。对于开发者而言，如何选择适合自己的技术方案才是更重要的。

The evolution of frameworks slowly push the native web further, removing the previous needs of frameworks to smooth its rough edges, and mitigating previous tradeoffs - allowing us to adopt its features natively more and more.

框架的演变也在不断推动原生 Web 的发展，使其不断完善，在开发中能够直接使用上这些新的特性。

一图读懂

一图解读《The Guide To Responsive Design In 2023 and Beyond》

原文地址：https://ishadeed.com/article/responsive-design/

一句话总结

设计类文章，涉及图片相对较多

本文作者是前端兼设计师 Ahmad，围绕响应式设计 responsive design 这一话题，表达了之前 Web 页面只围绕桌面端 desktop、平板 tablet 以及手机 mobile 的设计已经过时，响应式布局不再是媒体查询的专属。阅读本文，可以了解现代基于组件式开发方式下的响应式布局，为响应式适配提供更多思路。

原文划重点

When you think about building fluid layouts these days isn’t about having fixed-width breakpoints anymore. Instead, the layouts we build today need to work on nearly any device size. To my surprise, I still see websites follow the adaptive design pattern, where it has a container that gets a new max-width value as per the viewport width.

现代布局几乎需要适配任何尺寸的设备，作者发现仍然有很多网站使用传统的根据视口 viewport 宽度设置 max-width 方式的自适应布局。

The term “responsive” means a lot of things now. We have media queries that check for user preferences, and modern CSS features that help us make a fluid layout without even using a media query. Responsive is different nowadays. It’s an exciting time, indeed!

responsive 这一术语与之前的含义大不相同，现在这个词意味着很多。可以通过 media queries 去检查用户偏好设置，通过现代 CSS 新特性来实现更流畅的布局。

It’s time to share more awareness that responsive design isn’t just about fixed-width breakpoints and making a website work on mobile, tablet, and desktop.

现在我们需要意识到响应式设计不再是根据特定尺寸设定固定的宽度，也不再只有手机、平板和电脑。

The current CSS features we’ve been powerful to the point that makes anything possible on all screen sizes.

现代 CSS 已经可以满足适配任何尺寸的屏幕。

CSS is getting so powerful nowadays. That means the future of responsive design will change. It won’t be about treating the whole page as responsive. Instead, we’ll write the responsive CSS for components and let the browser do its own work to decide when a component should have a specific style.

随着 CSS 变得强大，响应式设计的定义也在改变 -- 不再只是整个页面响应式。相反，可以组件级别写响应式样式。

Responsive design isn’t about media queries. It’s about time we change our mindset and take the full potential of modern CSS. I look at a future where we might need media queries for general things like a website header, and the rest can be responsive with size container queries, fluid sizing, and who knows whatever new features will land.

响应式布局不再只有媒体查询，现在我们应该改变原有心智去挖掘现代 CSS 的更多可能。

一图读懂

四种常见图片格式的对比

不压缩：WebP 是未压缩照片的最佳格式；PNG 是未压缩文本图像的最佳格式，适用于线条和文本。
有损压缩：AVIF 和 WebP 在有损压缩照片质量方面最佳；PNG 则是最佳的文本图像压缩格式；渐进式 JPEG 提供更高质量，但文件比标准 JPEG 稍大。
WebP is the best format for uncompressed photos (1.42x smaller than JPEG, 1.70x smaller than PNG, and 1.75x smaller than AVIF).
PNG is the best format for uncompressed text images (6.25x smaller than JPEG, 3.06x smaller than WebP, and 3.88x smaller than AVIF).
AVIF and WebP offer the best quality when lossy compression of photos, while PNG offers the best lossy compression for text images.
Progressive JPEG files are 5% larger than standard JPEG files.

声明：本文结论和图片来自 Photutorial 文章《Image Format Comparison (JPEG, PNG, WEBP, & AVIF) – 2023 Statistics》，地址：https://photutorial.com/image-format-comparison-statistics/

Web Push 拯救 Web 凉凉 Native App？

本周四 02/16 Webkit Blog 发文《Web Push for Web Apps on iOS and iPadOS》称今天标志着 iOS、iPadOS 和 Safari 16.4-beta.1 的发布（02/13 发布 iOS 和 iPadOS 16.3.1、Safari 16.3），本次发布是 Safari 16 版本发布以来 features 最多的一次（135 个）。原文中重点介绍了该版本中支持了 Web Push 以及其它围绕系统主屏幕添加 Web App 的特性。

本文简单介绍下这次发布，聊聊 A2HS 和 Web Push，并结合历史和趋势谈谈 Web 和 Native App.

发布简述

Safari 本次发布内容较多，下面简单列一下发布概览并借机学习下其产品迭代 Release Notes，然后挑几个 Web 开发同学相对可能更感兴趣的特性稍微展开一讲，可留意备用。

发布内容整体涉及 28 项，其中每项内主要是 New Features（Added xxx）、Resolved Issues（Fixed xxx），另外在 Apple 产品 Release Notes 中还会有 New Restrictions（Disabled xxx）、Known Issues、Deprecations 等等，每次迭代内容比较清晰。

这里根据发布说明，挑几个技术话题来聊。

HTML: Added support for lazy loading iframes.

这个很有趣，浏览器级别支持 iframe 懒加载，关于 iframe lazy-loading 可以参考《It's time to lazy-load offscreen iframes!》这篇文章，下图来源于这篇文章。

顺便联想到涉及微前端时，iframe 还是很不受待见的，比如 qiankun 的技术决策《why not iframe》。不过现在基于 iframe 的微前端方案，也在不断出新，改期可以聊下。

Custom Elements: Added support for Declarative Shadow DOM.

这个不得不说。Shadow DOM 大家都比较熟悉，Web Components 中实现封装的核心 API，最初由 Google 为 Web 上可复用组件而提出，且早已是 HTML DOM 标准。

以前实现方式是必须通过 JS 使用 Element.attachShadow() 方法将 Shadow Root 改在到元素上。

// Create a shadow root
const shadowClosed = elementRef.attachShadow({ mode: "closed" });

声明式 shadow DOM 则引入了一种新的定义 Shadow Tree 方式，直接将元素声明式写在 HTML 中。

<some-component>
  <template shadowrootmode="closed">hello, world.</template>
</some-component>

到这里可能会问 “为什么要这样做？”，这主要是因为现在的网站或者 Web 应用又重新启用 SSR server-side rendering，Webkit 上博文最近对《Declarative Shadow Dom》进行了详细介绍，Epic Web Dev 的《The Web’s Next Transition》对 SSR 趋势做了说明，可以一并阅读了解。

CSS: Added support for the unprefixed :fullscreen pseudo-class.

本次发布中 CSS 的 bugfix 仍然很多，这里单拎一个 feature 伪类 :fullscreen 介绍，显而易见它是允许开发者在浏览器全屏模式时生效的 CSS 样式，体现着 Web 对用户体验的追求。这些年 CSS 已经有了长足的进展，布局角度，从当年 float 满天飞，到现在基本 flex、grid 的全线支持，也因此推动更加流畅的响应式布局。关于响应式布局和设计，有兴趣可以看下《The Guide To Responsive Design In 2023 and Beyond》。

JS: Added support for Array.fromAsync.

当前在 Stage-2 的 Array.fromAsync，有兴趣可以去了解更多 ES Next（新特性列表），从此再也不用担心 “讲下 ES100 新特性吧” 的场景。

Images: Added support for AVIF on macOS Monterey and macOS Big Sur.

对 AVIF 图片格式的支持。关于被称为现代图片格式的 AVIF 和 Webp，技术周刊（现已 114 期）中多次有推荐文章介绍，感兴趣可以了解，改期也可以聊聊几种主流图片格式的优缺点及其支持程度。

其它还有很多，不再一一列举。

添加到主屏幕

自第一代 iPhone 发布的过去十几年，“添加到主屏幕”（Add to Home screen or A2HS for short）一直是 Safari 点击分享按钮、分享菜单中的的功能，找了张图示意（像是给人打了广告，侵删）。

关于 Web Application 和 A2HS，在 Apple 开发者文档中有介绍：

A web application is designed to look and behave in a way similar to a native application—for example, it is scaled to fit the entire screen on iOS. You can tailor your web application for Safari on iOS even further, by making it appear like a native application when the user adds it to the Home screen.

也就是说，通过 A2HS 能够实现让网站从 Web 应用 “变成” Native 应用，这时候上滑切换应用时，也能看到该应用，表现上不再是以 Safari 为载体（这里叫 Home Screen web apps，有没有感觉熟悉的词来了 -- PWA Progressive Web App）。

此外，简单尝试了下 safari 中页面添加到屏幕，发现了几个问题。

因为该功能的目标是将 Web 应用搞成 Native 应用，而如果添加的是一个单独的页面，则无法再跳出当前页面，相当于这个页面就代表着这个应用。
如果添加的页面是一个网站入口，比如搜狗首页，那可以实现上述效果。但现在网站本身自身并不一定都做好适配。比如将百度和搜狗的页面分别添加到主屏幕，便看到了 bug 可优化点（又不是不能用）-- 百度仍在 Safari 打开，像极了跳转链接（没写 manifest 吧）；搜狗二级图片搜索页面，暴露返回按钮但无效果（这里不上图了🙄）

最后，关于 PWA 的支持程度。在 Mobile 上基本上是全系列支持，MacOS 上 Microsoft Edge 和 Google Chrome 支持，Safari 目前仍不支持，Apple 论坛上有对于此的问答。

Web Push

终于到 Web Push 了。Web Push 是一个 W3C 的标准，是指允许通过 Push API、Notifications API 和 Service Workers 技术实现 Web 开发者给用户推送消息，即便浏览器是在后台或者关闭的情况下。在 iOS 和 iPadOS 上（MacOS 上是在 Ventura Safari 16.1 时已经支持）大致逻辑就是添加到主屏幕的 Web 应用会请求接收推送消息的权限，系统则向用户询问说是否允许该行为，一旦允许，用户就能像其它应用一样管理 Web 应用的通知权限。

下图是 iOS 中通知的权限控制示意图。

其实对于 iOS 和 iPadOS 上 Web Push 的支持，Apple 在去年的 WWDC 上《Meet Web Push for Safari》介绍 MacOS Safari 支持 Web Push 时有提到会在 2023 年实现，视频中也有对 Web Push UX、flow 以及详细实现的介绍，文字版在《Meet Web Push》，感兴趣可了解。

下图是 MacOS 中 webpushd 进程示意图。

本次发布中，配合 Web Push 来增强 Web Apps 的还有几个新特性：

Added support for the "id" member in Web App Manifest files.
Added support for the Badging API.
Added support for third-party browsers to offer Add to Home Screen from the Share menu.

围绕 Web App 的开发，还有 Screen Wake Lock API、Screen Orientation API、User Activation API、Web Codecs API video support 等，这里就不再对此进行拓展介绍了。

Web or Native

这些年（自 iPhone 2007 年诞生以来）关于移动端上为什么是 Native App 而不是 Web App 的讨论基本没停过，确实是一个比较难聊的话题。这里借着本次 Apple 对 Web App 的支持，通过概述移动端应用发展、各自优缺点以及 Web 技术发展，简单聊聊个人看法。如有偏误，欢迎交流指正。

先来看下历史。其实在 iPhone 发布之初，Steve Jobs 对 iPhone 的预期之一是不需要第三方的原生应用，可在当年 WWDC07 Jobs 演示 Safari: iPhone Development Platform 中看到，当时列出不少优点，如 No SDK required。但当 2008 年发布了 App Store 并看到开发者发布了如此之多专为 iOS 以及 iPadOS 系统的应用、如此大的下载量以及如此可观的收入之后，“We Didn't Expect It to Be This Big” 震惊了。关于 Web 和 Native 的竞争可以看 CodePen 联合创始人 Chris Coyier 的这篇《What does it look like for the web to lose?》文章。

由于历史和各自定位不同等原因，移动端上 Native 比 Web 系统能力更强、性能更优、发版机制更易于管控等优势。而 Web 则具备动态性、跨系统、技术栈通用等方面优势。回到 App 开发，其实我们现在的应用基本上都是各种技术栈的混合体，只是通常应用壳子是 Native 的，应用功能实现会有 Native、RN、Flutter、Web(View) 等等。所以从这个角度来说，技术方案的选择并不是非此即彼的，根据不同场景发挥各自优势。关于 App 技术选择，ionic 有篇文章《Hybrid vs Native…What About a Third Option?》对此也有介绍。

从目前现状看，移动类设备上（包括 IoT、游戏主机等）一定会有自己的 App Store，而 Web 以及 PWA 可能短时间内依旧不会获得足够的投入。但依托于 SuperApp（如微信）的 PWA 的变种 Miniapp 小程序确是获得了巨大的成功。这个也可以理解，国内拥有 SuperApp 这类应用级厂商与 iOS 和 Android 为代表的 Apple 和 Google 这类系统级厂商 scope 不同，应用级别角度建护城河、保留存等，小程序当之无愧。

将视角转向桌面端。这些年 Web 的长足发展以及广泛应用在桌面端上是有足够体现的，桌面端以其更佳的硬件设备，将 Web 缺点放小，跨平台优势放大，国外 Figma、Notion 等应用则是典型代表。同理，伴随移动端硬件的提升以及 Web App 功能的完善，相信 Web App 会大放光彩。

结语

本文主要结合 iOS 和 iPadOS 14.1-beta.1 的发布，介绍了其中涉及的新特性、Web Push、A2HS 以及简单聊了聊 Web App 和 Native App 开发。相信通过以上内容，对标题中的 “拯救 Web、凉凉 Native” 会有更全面的评判。

回到 Web。从前几年 SPA 独占鳌头，到近两年 SSR 重回江湖，各种 Meta Framework 层出不穷。还有响应式设计重新定义、基于区块链和去中心化技术的 Web3，相信 Web 未来会更加光明。

最后，本文中有些技术话题未聊到或有些聊到了但没有深入拓展，后续根据需要再一起交流。内容会一并在微信同名公众号 OSInsight 推送，其中每周固定一篇周刊、两篇一图解读，还有不定时技术分享、源码解读以及项目分析等。欢迎关注，一起见证，共同成长，Enjoy :)

iyuki22 / weekly Goto Github PK

weekly's Introduction

Web 技术周刊

目录

2023

2022

weekly's People

Contributors

Stargazers

Watchers

weekly's Issues

一句话总结

原文划重点

一图解读

一句话总结

原文划重点

一图读懂

一句话总结

原文划重点

一图读懂

一句话总结

原文划重点

一图读懂

人工智能与低代码开发的新篇章

用户界面设计和程序预测中的人工智能应用

自动化监测与程序质量控制

人工智能推动低代码开发升级与优化

结语

一句话总结

原文划重点

一图读懂

一句话总结

一图读懂

原文划重点

一句话总结

原文划重点

一图解读

一句话总结

原文划重点

一图解读

一句话总结

原文划重点

一图读懂

一句话总结

原文划重点

一图读懂

发布简述

添加到主屏幕

Web Push

Web or Native

结语

Recommend Projects

Recommend Topics

Recommend Org

Jobs