webtransport
turbo
webtransport | turbo | |
---|---|---|
11 | 145 | |
802 | 6,424 | |
0.9% | 0.8% | |
9.0 | 8.7 | |
9 days ago | 9 days ago | |
Bikeshed | JavaScript | |
GNU General Public License v3.0 or later | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
webtransport
- WebGPU – All of the cores, none of the canvas
-
Firefox 114 released
WebTransport is now enabled by default and will be going to release with 114. As the original Explainer notes, it enables multiple use-cases that are hard or impossible to handle without it, especially for Gaming and live streaming. It covers cases that are problematic for alternative mechanisms, such as WebSockets. Built on top of HTTP3 (HTTP2 support will be coming later). The current implementation in Firefox is passing 505 out of 565 Web-Platform Tests.
-
Alternatives to WebSockets for realtime features
WebTransport is still an emerging technology. As of November 2022, WebTransport is a draft specification with W3C, and there’s always a chance that aspects related to how it works may change.
-
Librespeed - a Foss speedtest
Sort of. The browser will re-use the connection if you have a bunch of resources in the HTML. When rendering it sees that it needs 2 images and 3 javascript files from the same server, so it pipelines all of those. But for requests initiated from javascript, you're going to get a new connection for each one unless you're using a library that implements the long-polling hack. SocketIO can use the long-polling hack as a fallback if websockets is not supported. HTTP/2 (formerly SPDY) gets part of the way to replacing websockets, but it's not a synchronous link. Only the client can send messages to the server and the server can only respond to those message (with websockets, either side can send messages once the connection is open). FWIW, less than 50% of websites use HTTP/2. HTTP/3's webtransport looks like it could replace websockets, but it also looks like it'll live along side websockets.
-
The WebSocket Handbook
If it's streaming data like dashboard statistics the new WebTransport API might be a much better base: https://github.com/w3c/webtransport/blob/main/explainer.md
-
We Got to LiveView
Are you guys looking into the Web Transport protocol for the future? Right now you have to tunnel the websocket connections over http2 and it will probably be the same for http3 afaik.
I know there is this work in progress (https://w3c.github.io/webtransport/) and websockets are probably fine for a long time but sooner or later (unless there is an update to websockets) it will probably be faster to just do normal http requests and listen on server sent events.
What are your thoughts for Liveview for the future? Will it forever stay on websockets or would you be open to change the underlying technology if / when new stuff becomes available?
-
WebTransport is a proposed API to expose QUIC's datagrams and streams to JavaScript clients
The W3C draft is here: https://github.com/w3c/webtransport
-
The History and Future of Socket-level Multiplexing
It's taken nearly 10 years for QUIC to be refined and adopted in the wild and we're basically there. There's even a new browser API in the works called WebTransport.
-
Show HN: PSX Party – Online Multiplayer Playstation 1 Emulator Using WebRTC
tl;dr using WebRTC just for realtime client<->server data sucks, but WebTransport[1] is coming soon to serve that exact usecase with an easy API
WebRTC has data channels, which are currently the only way to achieve unreliable and unordered real-time communication (UDP-style) between the browser and other browsers or a server. This is pretty essential for any networked application where latency is critical, like voice and video and fast-paced multiplayer games.
As other commenters have noted, it's a royal pain in the ass to set up WebRTC if all you want is UDP-style communication between a server and browser, since you need to wrangle half a dozen other protocols in the process.
However! A new API, WebTransport[1], is actively being developed that will offer a WebSockets-like (read: super simple to set up) API for UDP-style communication. I am extremely excited about it and its potential for real-time browser-based multiplayer games (which I'm working on).
https://github.com/w3c/webtransport
turbo
-
Turbo Streaming Modals in Ruby on Rails
I also recommend checking out the docs for Stimulus and Turbo to familiarise yourself with all their features and the APIs used in this series.
-
Htmx vs. React: A Complete Comparison – Semaphore
https://github.com/hotwired/turbo
- Turbo 8 has been released
-
What is JSDoc and why you may not need typescript for your next project?
Turbo 8 remove typescript without using JSDOC
-
Coming to grips with JS: a Rubyist's deep dive
Experiment using Turbo to drive front-end behavior: "Turbo 7.2.0 (currently in beta) allows you to define your own Stream actions which can be any JS code you want. By combining a custom Stream action or two with web components, you can essentially drive reactive frontend behavior from the backend stupidly easily. Loooove it! 😍 […] For a turnkey example, you could check out https://github.com/hopsoft/turbo_ready " —Jared White on The Spicy Web Discord
-
Improving a web component, one step at a time
This handles disconnection (as could be done by any destructive change to the DOM, like navigating with Turbo or htmx, I'm not even talking about using the element in a JavaScript-heavy web app) but not reconnection though, and we've exited early from the connectedCallback to avoid initializing the element twice, so this change actually broke our component in these situations where it's moved around, or stashed and then reinserted. To fix that, we need to always call addSparkles in connectedCallback, so move all the rest into an if, that's actually as simple as that… except that when the user prefers reduced motion, sparkles are never removed, so they keep piling in each time the element is connected again. One way to handle that, without introducing our housekeeping of individual timers, is to just remove all sparkles on disconnection. Either that or conditionally add them in connectedCallback if either we're initializing the element (including attaching the shadow DOM) or the user doesn't prefer reduced motion. The difference between both approaches is in whether we want the small animation when the sparkles appear (and appearing at new random locations). I went with the latter.
-
Mastering Rails Web Navigation with link_to and button_to Helpers - Part 2
If you think you have seen enough Rails magic, you are mistaken my friend. Rails have a new trick up its sleeve: Hotwire. And with the magical Turbo tool that comes with it, you can create modern, interactive web applications with minimal, or sometimes no JavaScript at all, providing users with an incredibly smooth experience.
-
Why you should choose HTMX for your next project
There is also Turbo and the frameworks who adopt them, Ruby on Rails, PHP Symphony and possibly others that solves the same issue in the same manner as HTMX. And the choice for HTMX is only a personal taste in this, but you should definitely learn about this, this is as cool as HTMX!
-
JavaScript First, Then TypeScript
Most controversially, the Turbo framework dropped TypeScript support altogether after assessing that strong typing was the culprit behind poor developer experience.
-
Rack Attack – Rails Tricks
Turbo[0] has been solving this for years. Quite the contrary, front-end frameworks have started to think "sending JSON is good, but actually sending HTML could be great!".
DHH's presentation[1] during Rails World 2023 is quite interesting in that regard, I recommend you give it a go (start around minute 16). I am actually very excited with his vision of the web.
[0] https://turbo.hotwired.dev/
What are some alternatives?
fastapi - FastAPI framework, high performance, easy to learn, fast to code, ready for production
htmx - </> htmx - high power tools for HTML
phoenix-liveview-counter-tutorial - 🤯 beginners tutorial building a real time counter in Phoenix 1.7.7 + LiveView 0.19 ⚡️ Learn the fundamentals from first principals so you can make something amazing! 🚀
Turbolinks - Turbolinks makes navigating your web application faster
Mercure - 🪽 An open, easy, fast, reliable and battery-efficient solution for real-time communications
hotwire-rails - Use Hotwire in your Ruby on Rails app
datagram - In-progress version of draft-ietf-quic-datagram
inertia - Inertia.js lets you quickly build modern single-page React, Vue and Svelte apps using classic server-side routing and controllers.
stimulus_reflex - Build reactive applications with the Rails tooling you already know and love.
morphdom - Fast and lightweight DOM diffing/patching (no virtual DOM needed)
geckos.io - 🦎 Real-time client/server communication over UDP using WebRTC and Node.js http://geckos.io
importmap-rails - Use ESM with importmap to manage modern JavaScript in Rails without transpiling or bundling.