和这样，我的意思是一个工作和感觉完全像本机应用程序的网络应用程序。
为什么，本机应用程序怎么了？
让您想出一个很好的应用程序或服务的概念，例如就我而言，是minimalistic micro journaling app。您自然希望它能适用于尽可能多的用户，无论他们居住在哪里以及他们选择在桌子，手腕和/或口袋里都有的设备。
对于一家不错的体面公司，只需让您的产品团队提出设计并聘请一堆Android-，iOS和Web Devs来实现每个平台的版本（总计3个版本）。但是，对于一个小组织或一个不选择的indie hacker，您只有资源来构建和维护三个应用程序。
好吧，那里有跨平台的解决方案。通常的嫌疑人是反应的本地，离子和颤动。它们都很好，可让您访问本机设备API。 React Native和Ionic甚至允许您使用Web堆栈（HTML，JS/JSX，CSS）和诸如React或Vue之类的框架快速构建应用程序。
（感谢Daniel Roe，使用NUXT很快也将是nuxt/ionic的选择）
的图像
很好，但是它们都共享一个问题：该应用程序仍需要打包（几次），部署到网络，并提交给Apple，Google和Microsoft的各自商店。
这很烦人，因为您的应用程序的更新将被每个商店的审核过程以及仅决定不使用年龄更新其应用程序的用户延迟。因此，从理论上讲，您的后端/API必须能够与存在的每个版本的应用程序一起工作。 meeeâ
此外，您被迫根据商店策略实施多个付款解决方案（包括会计！）（在这种情况下为3，加上1个用于网络）。如果您想接受Lightning付款，该怎么办？
进步的Web应用程序（PWA）呢？
渐进式网络应用程序（PWAS）很棒，您甚至可以通过bubblewrap或PWA Builder等工具将其限制出现在大多数应用程序商店中。另请参见可信赖的网络活动（TWA）和我以前的Publishing a Progressive Web App (PWA) on the PlayStore — What works and what doesn’t (in 2021)。
的图像
但是，当我们谈论一个类似于本机的应用时，渐进的加载和缓存并不是我们想要的。
下载后，一个本机应用程序脱机工作。这也是PWA的前提，但是渐进式网络应用程序（如名称所建议的ph）只会缓存页面并在访问时进行更新。因此，该应用程序并不是真正完全离线的，而是在网上带有后备。
这种行为对于增强Web服务的体验很有用，并且有stats to prove it，但是对于很多用例，I.A.。我的日记应用程序，这将不起作用。
所以让我们进行一些调整â
本机Web应用程序（NWAS）
我们真正想要的是带有即兴缓存和立即填充支持的PWA。
它会是什么样子？
让我们看一个理想化的概念，该概念将（几乎）（几乎）我们目前在本机应用以及PWAS面临的所有问题。
您没有咨询应用商店，而是打开要购买的应用程序的主页，例如www.journalisticapp.com。这里有两个选项，要么要使用安装横幅pwa提示您，要么有一个安装按钮手动触发安装。理想情况下，两个选项之间的选择应留给开发人员。
触发安装后，将下载应用程序（又称完全缓存）到用户设备，因此可以立即脱机。
目前没有任何技术障碍可以阻止我们实施此类应用程序，即使没有开箱即用的解决方案，我们将不得不使用Workbox和/或Service Worker脚本修补。
但是，它将受到限制。
我的意思是，很明显，在依靠在浏览器中执行单个线程的JS代码库时，我们将不得不进行性能命中，而不是针对芯片架构优化的本机Java或Swift Code。但是，并非所有应用程序都至关重要。我猜那些不会很快就不会在本地实施中实现。
那么缺少什么？
尽管正在取得进度以启用通过Web APIs访问越来越多的设备API，但仍有很多关键的丢失，例如控制导航栏颜色，访问设备的安全芯片或生物识别验证。
对于NWA而言，拥有未与浏览器共享的专用存储，并且可以加密和/或阻止，例如当用户未经身份验证或已锁定应用程序时。截至撰写本文时，使用浏览器发货的网络唯一可行的存储选项是IndexedDB。
概括
拥有与本机应用程序无法区分的Web应用程序结合了两全其美的应用程序，并且可以直接从Web下载。当考虑应用程序的分散未来和web3时，后者尤其重要。
。很有可能，我会继续与Journalistic一起沿着NWA兔子的洞走下去，并继续报告我将在构建与本地同类产品无法区分的Web应用程序中所走多远。
感谢您的阅读，并度过美好的一天。