我编写了JavaScript以避免使用JavaScript

Web技术已经取得了长足的进步，您会意识到：如今并不是所有的事情都需要用JavaScript来完成。

但这已经是一张大嘴巴了，而且还会透露太多信息，你可能就不会点击我那略显诱人的标题了，对吧？

首先，我根本不反对JavaScript(JS)。如果你正在构建一个Web应用程序，那么这不仅完全可以，而且很可能是一个核心需求。

但我确实对JS的普通网站和博客感到恼火。目前在静态站点生成器领域仍然有如此强烈的风潮，告诉我们我们所有的站点都应该是某种类型的Reaction或其他基于前端框架的项目(看看你，盖茨比，NeXT，Nuxt，VuePress，…)。。你需要在访问者的浏览器中运行大量的代码，才能获得流畅的、感觉像原生应用程序用户体验的体验。网站应该是单页面应用程序(SPA)。我可以告诉你，一个普通的HTML+CSS网站也能很好地做到这一点。惊喜！

一方面，浏览器供应商增加了越来越多的WebAPI，我们在HTML和CSS方面也得到了很大的改进。通常情况下，他们周围不会有大肆宣传的列车，除非你非常热情，并生活在那个利基市场。

看看caniuse.com，看看今天可能发生什么，明天可能会发生什么。你知道HTML5还在迭代，我们正在向5.3版本迈进吗？另一方面，“HTML5”也被用作各种标准的总称。另外，对于CSS来说，故事变得非常有趣：尽管CSS 2.1之前是一个单一的规范，但从CSS3开始就有了一大堆建议和草案。CSS工作组的wiki可能是进一步发现的一个很好的起点。

关键因素是css的位置：粘性🛈。尽管它们中的大多数被标记为部分支持，但此属性值可以在大多数情况下使用，但在某些与表相关的情况下除外。如果你想在滚动后看到一个粘滞的菜单，并且只使用div这样的元素，那么一切都很好。当我意识到所有常见的和现代的浏览器都没有任何阻塞问题后，我可以扔掉所有的代码。所以我就这么做了。唯一真正的后来者是网页视图组件，这对我来说没什么大不了的。

Const navbar=Document.querySelector('；.navbar'；)；let Sticky=navbar.offsetTop；const navbarScroll=()=>；{if(Window.pageYOffset>；=Sticky){navbar.classList.add('；Sticky&39；))}Else{navbar.classList.Remove('；Sticky&39；)；}；窗口。

.navbar{position：Sticky；top：0；/*它不会立即重新定位，但会确定它粘在哪个点上*/}。

还注意到现在实际需要的代码有多少吗？两个CSS属性，工作就完成了。

同样在2018年，我玩了进步网络应用(PWA)。整个博客都是一个。几天前，我把它都拆了。在PWAS的核心是SIT服务工作者(SW)，不过您也可以使用SW而无需构建应用程序。这就是我的目标，但最终，我自己开发的动态缓存解决方案对我来说更令人讨厌，而不是对其他任何人有帮助。每次我在这里更新任何东西时，我都必须等待和/或强制刷新才能看到结果。我相信有些人可能会因为浏览器中仍在运行的服务人员而看到视觉上的不一致。如果这样做，请尝试强制清除此网站的所有数据。

长话短说：如果你不开发网络应用，你很可能不需要服务人员。因此，还有一件事是从JS名单上掉下来的。

这里没有之前/之后的比较，但是通过删除它们，减少了宝贵的几千字节的JavaScript。

如果您有文件大小不是很小的图像，则可能需要提供分辨率和质量非常低的临时占位符。这对于低速的互联网连接非常有用；我生活在德国，我知道这种情况有多困难。那个叫互联网的东西对我们来说仍然是纽兰(Neuland)式的东西。🤦。

SVG是可伸缩向量图形，这是一种我非常喜欢的图像格式，我的徽标已经用它做好了(我不久前写过这篇文章)。

LQIP最终代表»低质量图像占位符(Low Quality Image Placeders)，它基于一种算法来寻找基元形状来描述源图像。基本上只能找到几个三角形、矩形、圆形、椭圆形和其他低多边形。它本身也是一种艺术形式，你可以在那里欣赏到一些很好的例子。SVG的优点在于，它是用极少的人类可读文本字符对这些数字进行编码的，因此占位符的不太复杂的图像可以用1千字节或更少的字节来编写。

与原始的高分辨率图像相比，这是很棒的，因为高分辨率图像可以轻松地重达0.5兆字节甚至更多。您可以在页面中预留空间，并在加载过程的早期显示一些视觉提示，表明很快就会有合适的图片。特别是对于不支持渐进式加载的类型(如JPEG)，使用SQIP/LQIP占位符非常有意义。

在这个场景中，一开始并不是真的要保存前端JS，而是更多地将其保存在后端站点上，并用其他东西替换它。不幸的是，在这中间，一些代码不管怎样悄悄地进入了前台。

因此，使用小的低质量占位符的一个原因是，在这类标签成为一种东西之前，我们完全依赖于单一的<；img>；和一些使用CSS的技巧(有时还辅之以少量的JavaScript)。我试图完全避免JS，但当然最终我不得不使用一些样式技巧。

<；img src="；高大。png"；样式="；背景-大小：封面；背景-图像：url('；数据：图像/svg+xml；base 64，phn2…。'；)；"；>；<；！--通常在某些后处理中，所有样式属性都被收集到<；style>；标记或CSS文件中。-->；

在我使用透明图像之后，JavaScript一度进入了这个场景。遗憾的是，用这个背景图像解决办法，你会看到低质量的占位符透过透明的部分，说实话，这是非常丑陋的。我无法忍受，在实际图片加载后，我部署了一些代码片段来触发背景移除：

//删除背景图像样式，以便透明图像不会//出现//奇怪的SQIP伪像通过文档.querySelectorAll("；img[loading=lazy][class]：not(.thumbnail)：not(.loaded)"；).forEach((Img)=>；{img.。OnLoad=(_Event)=>；img.className="；已加载"；；})；文档.querySelectorAll("；img[loading=lazy].thumbnail:not(.loaded)"；).forEach((Img)=>；{img.。OnLoad=(_Event)=>；img.className="；加载的缩略图"；；})；

理论上这是可以忍受的，但当我开始将图片包装成图片标签时，我注意到了一些奇怪的行为。

得了吧，更多的缩略语？我很抱歉，网络上有很多这样的东西。

目前你需要知道的是，这两种图像格式都是相当现代的图像格式，在保持良好质量的同时具有相当好的(有损)压缩比。WebP出现已经有一段时间了，大多数浏览器都支持它。AVIF非常新，目前只有Chrome版本85和Opera 71可以显示它们。Firefox有一个配置标志，也许他们很快就会默认启用它。

因此，目前的情况是，我有我的原始图像(大多数情况下是PNG或JPEG)、WebP版本、AVIF版本和SQIP占位符。我该怎么处理呢？返回到我们的<；图片&>标签：

<；图片&>源资源="；./over.avif"；type="；Image/avif"；>；<；源资源="；./cover.webp"；type="；Image/WebP"；>；<；img src="；./over.png"；style=&。<；/Picture>；

您也可以根据媒体查询使用不同视图大小的源集，但在我的例子中，我主要关心的是支持不同的图像格式。我的想法是首先对文件大小最小的格式进行优先排序，给出压缩比通常的顺序是：AVIF、WebP、PNG/JPG。并非在所有情况下都是如此；例如，WebP并不总是比经过适当压缩的JPEG节省得更多。到目前为止，AVIF还没有令人失望，但遗憾的是，我的部分访问者还没有看到效果。

真正不再发生的是在加载最终图像之前显示占位符。我做了相当长一段时间的实验，直到我意识到我不想再花更多的精力。

我在风险和回报之间进行了权衡，完全放弃了SQIP。对于越来越多的AVIF支持，图像有时要小得多，这使得允许一些显示延迟是可以接受的。

在下面的屏幕截图中，JPEG是源照片。PNG是为一些透明的东西而创建的；当然，对于照片来说，这种格式通常没有多大意义。遗憾的是，WebP在这种情况下也无法竞争。这就是为什么我必须让这个图片组生成更智能一点，以便根据实际文件大小进行重新排序。目前，它只是基于固定的格式首选项选择。

嗯，AVIF在这方面绝对打败了它。是的，这个17.6KB的版本在视觉上可以与原始版本相媲美。当然，仔细观察你可以发现不同之处，但对于支持性的符号图片来说，不需要100%的准确率。如果你不注意它(或者只是不知道它的来源)，它可以很容易地与之竞争。

顺便说一句：在部署过程中，进行了另一次压缩尝试，PNG压缩到159KB，而WebP则完全没有。

唯一令人恼火的部分仍然是图像尺寸没有被适当地保留，即使使用目前的宽度和高度属性也是如此。因此，如果您滚动到尚未加载的图像，布局可以跳转。如果你有办法在图片组中解决这个问题，我很乐意听听。

更多不同格式的图片，更多的后端处理(目前主要是JS)，没有占位符图片，没有前端脚本。

您可以在此站点的GitHub存储库中找到我当前尝试将»<；img>；转换为<；Picture>；。

»有时我会在这里和那里添加一些东西。再过一会儿，我想我应该再去掉一些东西。

基本上，我删除了访问、查看和阅读不必要的所有脚本。视觉上令人愉悦的提示，如阅读位置的细微进度条，是一个很好的玩具，尽管根本不是必要的。

我在一开始就提到，没有JavaScript的站点也有例外。你会找到页面分辨率和主题的脚本。

当我需要在调整主题的同时检查屏幕和窗口大小时，第一页实际上是为我自己准备的。在调整大小和缩放时，它需要动态(重新)计算这些值，所以这里没有真正绕过JS的方法。正如我所说的，我一点也不介意。

如果我诚实的话，第二个页面可以没有客户端脚本，但当时我有点懒得在部署之前或部署期间以完全静态的方式自动生成数据。现在，它提醒您可以通过编程获得计算样式。有时这可能非常有用。

顺便说一句，在构建、前后处理和部署期间，该站点由153 MB的node_module提供支持。我对此并不十分满意，但目前这还可以。不过，我可能会在未来努力用其他东西来取代它。

🙅🏻‍♀️🕵🏻‍♀️，🙅🏻‍♀️🍪。

另一个侧面的事实是：由于我不跟踪我的访问者，甚至没有任何第三方脚本在任何地方徘徊。这也意味着你不仅要带咖啡或茶来下午阅读，还要带上你自己的饼干。因为我吃的时候不需要它们。

我希望更多的人--特别是在Web开发领域工作或感兴趣的人--会考虑减少或避免在他们的项目中使用JavaScript。当你建立一个静态网站时，也要问问自己，静态对你来说意味着什么？(我还记得动态超文本标记语言、Java applet和Flash时代略显阴暗的一面，brrrrr…)。

可以说我很老派，但如果你创建了一个以文字和图片为主的网站，为什么你要试图把我的设备变成加热器或炉子呢？事物的简单还在于什么不做什么不做，什么不做什么省略。

我希望我通过上面的例子给了你一些想法。了解HTML和CSS规格，并寻找用更小、更智能的解决方案替换部件的机会。如果有些东西还很粗糙，不要担心，大多数东西都是生活水平，而且会随着时间的推移不断演变和改进(如果你愿意的话，你可以提供帮助)。浏览器供应商通常在提案和规范最终确定之前实施一些草案。一切都在快速发展。睁大你的眼睛！

尽情享受小事吧，因为有一天你回首往事，可能会意识到它们才是大事。“--罗伯特·布劳特