首页 文章 精选 留言 我的

精选列表

搜索[前端设计],共10000篇文章
优秀的个人博客,低调大师

大前端领域哪些开源项目最受欢迎?

评选活动设置「最受欢迎项目」,以及特别策划的「优秀中国开源原生创企」和「神秘奖项」,本页面用于投票选出「最受欢迎项目」; 参与投票的候选项目被划分到「组织」或「个人」通道,最终选出 TOP 30 项目(组织:21 个,个人:9 个) 详细规则点此查看; 候选开源项目均由国人发起,评审委员会筛选出本页面的候选项目; 提名、修改项目信息等相关问题请私信 @OSCHINA编辑部。

优秀的个人博客,低调大师

foundation-sites 6.7.4 发布,响应式前端框架

foundation-sites 6.7.4发布了,Foundation 是一个易用、强大而且灵活的框架,用于构建基于任何设备上的 Web 应用,提供多种 Web 上的 UI 组件,如表单、按钮、Tabs 等等。 6.7.4 版本主要更新如下: 增强功能 当what-intent检测到正在使用触摸鼠标时,焦点上的轮廓将被删除。 当一个元素被设置为draggable=false 时,iOS上的标注和强制触摸也会被抑制。 新的可见类(黑夜模式、IE10+、sticky): show-for-dark-mode hide-for-dark-mode show-for-ie hide-for-ie show-for-sticky hide-for-sticky 现在 Slider 使用抓取的光标作为句柄。 bug 修复 运行构建时不再有 ESLint 和 SassLint 错误! 更新一些依赖项,以跟上 DEP 训练 修复了定制器构建问题 修复了文档站点上的错误链接。 标签上的匹配高度现在使用min-height 修复了Accordion菜单插入符号,有几率不通过 sass 变量定义大小的问题 删除了 console.log 的几个实例 changed.zf.mediaquery事件又回来了!当浏览器调整大小并越过定义的断点时,将触发此事件。始终可以通过以下方式访问当前命名的断点:Foundation.MediaQuery.current 为 Reveal、Off Canvas 和 Overflow 原型类添加了动态滚动支持 Slider不再在 init 上发出moved.zf.slider和changed.zf.slider事件 更新公告:https://github.com/foundation/foundation-sites/releases

优秀的个人博客,低调大师

前端通讯协议大比拼:WebSockets和HTTP

在实时应用程序中,毋庸置疑,需要在信息可用时立即从服务器获取信息。而且,从根本上说,经典的 HTTP 请求/响应模式无法胜任这项工作。因为服务器将保持沉默,无论是否有新数据,除非或直到消费者请求更新。 随着开发人员试图使请求/响应模型适应更动态的实时Web的需求,这种限制导致了各种黑客和变通方法的出现(其中一些变得正式并被广泛采用)。 所有这些技术和方法,从 Comet 到 HTTP 长轮询,都有一个共同点:本质上,它们开始创造真正实时(事件驱动)数据交换/通信的错觉,所以当服务器有一些新数据时,它发送一个响应。 尽管 HTTP 不是事件驱动的协议,因此也不是真正的实时,但这些方法实际上在特定用例中非常有效,例如 Gmail 聊天。然而,在低延迟应用程序或大规模应用程序中会出现问题,主要是因为与 HTTP 相关的处理需求。 也就是说,对于 HTTP,必须不断请求更新(并获得响应),这是非常耗费资源的:客户端建立连接->请求更新->从服务器获得响应,然后关闭连接。想象一下,这个过程被成千上万的并发用户无休止地重复,这对服务器来说是非常繁重的压力。 正是这些问题最终促使开发人员 Michael Carter 和 Ian Hickson 开发 WebSockets ,本质上是一个构建在设备 TCP/IP 堆栈之上的薄传输层。其目的是为 Web 应用程序提供本质上是 TCP 通信层的东西,它尽可能接近原生,禁止一些抽象,以消除某些基于安全的复杂性和其他问题。 本文将着眼于一些用于绕过实时应用程序中 HTTP 请求/响应 模式的限制的技术,每个技术的一些相关问题,以及 WebSockets 如何帮助克服这些问题。 HTTP HTTP 本质上是客户端-服务器计算模型中的请求/响应协议,是万维网的主要通信方式。最初的版本由 Tim Berners-Lee 在 1989 年作为应用程序协议提出,非常有限,并迅速修改以支持更广泛的浏览器和服务器功能。 尽管 HTTP/1.0 不被视为正式规范或互联网标准,但这些修改最终在 1996 年被 HTTP 工作组记录为 HTTP/1.0(RFC 1945)。 HTTP/1.1 HTTP/1.1 是 Web 浏览器和服务器中最广泛支持的版本,它的到来是向前迈出的一大步,因为它实现了一些非常重要的优化和增强,从持久和管道连接到新的请求/响应头字段。其中最主要的是两个标头,它们是许多改进的基础,这些改进有助于实现更动态的实时WEB: Keep-Alive 标头:用于设置主机之间的持久通信。意味着连接可以被重复用于多个请求,这显着减少了请求延迟,这样客户端就不需要在发送第一个请求后重新协商 TCP握手(3次握手)连接。另一个积极的副作用是,由于 TCP 的慢启动机制,连接会随着时间的推移而变得更快。在 HTTP/1.1 之前,必须为每个请求/响应对打开一个新连接。 Upgrade 头:用于将连接升级到增强协议模式(如 WebSockets)。 HTTP 轮询 HTTP 轮询代表了经典请求/响应机制的进步,尽管轮询有多种版本,但只有长轮询在任何情况下都适用于实时 WEB 程序。 例如,HTTP 短轮询使用基于 AJAX 的计时器来确保客户端设备以固定时间间隔发送服务器请求。但是,服务器仍会立即响应每个请求,在关闭连接之前,要么提供新数据,要么在没有新数据的情况下发送“空”响应。因此,当客户端需要在新数据可用时立即响应时,这在实时应用程序中真的没有多大用处。 正是这种限制导致了 HTTP 长轮询的发展,它本质上是一种旨在模拟服务器推送功能的技术。 本质上长轮询是一种技术,其中服务器选择将客户端的连接保持尽可能长的时间(通常为 20 秒),仅在任一数据之后传递响应变为可用或达到超时阈值。 长轮询的主要优点是,理论上,只要新信息可用,就会立即将其发送给客户端。然而,不足之处是处理 HTTP 请求带来的额外开销。 HTTP 流媒体 HTTP 流是一种推送式数据传输技术,它允许 Web 服务器通过无限期保持打开的单个 HTTP 连接向客户端连续发送数据。本质上,客户端发出一个 HTTP 请求,服务器推出一个不确定长度的响应。 然而,虽然 HTTP 流传输性能良好、易于使用并且可以替代 WebSockets,但它存在有局限性。从实时角度来看,主要问题是中介可以中断连接(无论是通过超时还是仅仅因为它以“循环方式”服务多个请求),因此并不总是能够保证实时性。 HTTP/2.0 HTTP/2.0 由 Google 于 2009 年最初宣布的实验性协议 SPDY 演变而来。到 2015 年,HTTP 工作组发布了 HTTP/2.0 作为建议标准,并以 SPDY 规范为起点。 它本质上是一个旨在提高 Web 通信速度的性能更新,主要有以下两个实用功能: 多路复用:不是以明文格式传输数据,而是将数据编码为二进制并封装在帧内,这些帧可以沿着称为流的双向通道进行多路复用,全部通过单个 TCP 连接。这就允许同时发生许多并行的请求/响应 服务器推送:服务器推送是一种性能特性,它允许服务器在客户端请求响应之前向符合 HTTP/2 的客户端发送响应。当服务器知道客户端需要“推送”响应来完全处理原始请求时,此功能很有用。 尽管有这些进步,如今由于移动设备的大量使用,互联网流量的爆炸式增长使得 HTTP/2.0 难以提供流畅、透明的网页浏览体验,特别是在实时应用程序及其用户需求日益增长的情况下。 优点 通过安装 SSL 证书,所有浏览器都支持基于 HTTPS 的 HTTP/2 协议。 HTTP/2 允许客户端通过单个 TCP 连接并发发送所有请求,理论上,客户端可以更快地加载资源。 TCP 是一种可靠、稳定的连接协议。 缺点 并发请求会增加服务器的负载。HTTP/2 服务器可以大批量接收请求,这可能会导致请求超时。服务器负载峰值的问题可以通过使用负载均衡器或代理服务器来解决,限制转发请求。 服务器对 HTTP/2 优先级的支持还不成熟。软件支持仍在不断发展,某些 CDN 或负载均衡器可能无法正确支持优先级。 HTTP/2 推送功能可能很难正确实现。 HTTP/2 解决了 HTTP 首尾阻塞问题,但 TCP 级别的阻塞仍然会导致问题。 HTTP/3.0 HTTP/3.0 是 HTTP 的新迭代,自 2018 年以来一直在开发中,尽管它仍然是标准草案,但一些浏览器已经支持它了,如 Chrome。 HTTP/3 的目标是通过解决 HTTP/2 与传输相关的问题,在所有形式的设备上提供快速、可靠和安全的 Web 连接。为此,它使用称为 QUIC 的不同传输层网络协议,该协议运行在用户数据报协议 (UDP) 上,而不像其他早期版本那样使用 TCP。 不过 HTTP/3 已经开始出现一些潜在的问题,例如: 传输层的影响:过渡到 HTTP/3 不仅涉及应用层的变化,还涉及底层传输层的变化。因此,与其前身相比,采用 HTTP/3 更具挑战性。 可靠性和数据完整性问题:UDP 一般适用于可以接受丢包的应用,那是因为 UDP 不保证数据包会按顺序到达。事实上,它并不能保证数据包一定会到达,因此,如果数据完整性对应用实例很重要并且使用的是 HTTP/3,则将必须构建相应的机制来确保消息排序和完整的到达。 优点 引入运行在 UDP 上的新(不同)传输协议 QUIC 意味着理论上和目前实验上的延迟减少。 由于 UDP 不在协议栈中执行错误检查和纠正,因此它适用于不需要这些或在应用程序中执行这些的应用场景。UDP 通常用于时间敏感的应用程序,例如实时系统,它不能等待数据包重新传输,因此可以容忍一些丢弃的数据包。 缺点 传输层的影响:过渡到 HTTP/3 不仅涉及应用层的变化,还涉及底层传输层的变化。因此,与其前身相比,采用 HTTP/3 更具挑战性。 可靠性问题:UDP 应用程序往往缺乏可靠性,必须承认会有一定程度的数据包丢失、重新排序、错误或重复。由最终用户应用程序提供任何必要的握手,例如已收到消息的实时确认。 HTTP/3 还没有完全标准化。 WebSockets 关于WebSockets 的详细介绍,可以参阅《深入学习WebSockets概念和实践》。 WebSockets 允许服务器和客户端随时推送消息,而与之前的请求没有任何关系。使用 WebSockets 的一个显着优势是,几乎每个浏览器都支持 WebSockets。 WebSocket 解决了一些 HTTP 问题: 双向协议:客户端/服务器可以向对方发送消息(在 HTTP 中,请求总是由客户端发起,响应由服务器处理) 全双工通信:客户端和服务器可以同时独立地相互通信。 单个 TCP 连接: 一开始升级 HTTP 连接后,客户端和服务器在 WebSocket 连接的整个生命周期都通过相同的 TCP 连接(持久连接)进行通信,很好的节省服务器资源和带宽。 优点 WebSocket 是一种事件驱动的协议,这意味着可以将其用于真正的实时通信。与 HTTP 不同(必须不断地请求更新),而使用 websockets,更新在可用时就会立即发送。 WebSockets 保持单个持久连接打开,同时消除基于 HTTP 请求/响应的方法出现的延迟问题。 WebSockets 通常不使用 XMLHttpRequest,因此,每次需要从服务器获取更多信息时,都不会发送标头。这反过来又减少了发送到服务器的数据负载。 缺点 当连接终止时,WebSockets 不会自动恢复,这是应用开发中需要自己实现的机制,也是存在许多客户端开源库的原因之一。 早于 2011 年的浏览器无法支持 WebSocket 连接,这个现在可以忽略不计。 总结 通常,在实时、持续通信的上下文中,WebSockets 将是更好的选择。 基于 HTTP 的技术往往在服务器上占用更多资源,而 WebSockets 在服务器上的占用空间非常小。同时,像长轮询这样的方法也需要在服务器和设备之间进行多次跳转,并且这些网关通常对允许连接保持打开状态的时间有不同的限制。 如果项目中有长连接、不断更新、实时数据交互的需求,应该首选 WebSockets 来构建。

资源下载

更多资源
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长,特征是大鼻子、头戴帽子、身穿背带裤,还留着胡子。与他的双胞胎兄弟路易基一起,长年担任任天堂的招牌角色。

腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题,腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构,目前腾讯云软件源站支持公网访问和内网访问。

Rocky Linux

Rocky Linux

Rocky Linux(中文名:洛基)是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版,作为CentOS稳定版停止维护后与RHEL(Red Hat Enterprise Linux)完全兼容的开源替代方案,由社区拥有并管理,支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性,采用模块化包装和SELinux安全架构,默认包含GNOME桌面环境及XFS文件系统,支持十年生命周期更新。

WebStorm

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源,继承了IntelliJ IDEA强大的JS部分的功能。

用户登录
用户注册