webtransport
surface
webtransport | surface | |
---|---|---|
11 | 11 | |
802 | 1,994 | |
0.9% | 0.5% | |
9.0 | 7.9 | |
9 days ago | 2 days ago | |
Bikeshed | Elixir | |
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
surface
-
htmlgui.nvim - Create html + css + lua apps with neovim as 'browser'. ( proof of concept )
I should have been more clear that my intent was to create/use a compiler for some kind of component syntax. There are lots of them, from Surface (Elixir), Blade (PHP/Laravel), and JSX (React, Vue, Etc)
- Would you still choose Elixir/Phoenix/LiveView if scaling and performance weren’t an issue to solve for?
-
Why I selected Elixir and Phoenix as my main stack
There I learned more deeply about LiveView and Surface UI.
-
Something similar to Vuetify for Phoenix LiveView?
I think Surface is the ideal candidate for this. But it doesn’t have the components you are looking for but you can build anything with it. Hopefully, in future we can have set of headless components built using Surface 🤞
-
Single source of truth with Phoenix LiveView
I have worked with Phoenix LiveView and Surface-UI for about a year; I would like to share some of the things I learned the hard way.
-
Course/Extensive tutorials for Phoenix 1.6?
This is just an idea, but what about implementing using Phoenix.View(via use MyAppWeb, :view in your module)? Then assign I think has access to @conn. Then maybe work some magic to still allow Phoenix.Component syntax - but at this point, this is something I believe is a flow that might be in development. Try investigating / asking in Surface, because that is a lot more similar to React in its approach. In fact, I think Surface is where more aggressive features are pushed out, and ironed-out features get included into Phoenix. This was the case for Phoenix.Component, and HEEX.
-
Porting files generated by phoenix to surface
This post is intended to get you started with surface provided components. I provided the original code and surface versions so you can compare the differences yourself without installing anything. After installing surface following the installation guide https://surface-ui.org/getting_started add surface_bulma in your mix.exs, this will allow you to use the table component.
-
We Got to LiveView
I totally get the "Am I doing this the right way?" feeling, especially coming from Rails where everything was so opinionated and wanting to stay idiomatic.
Phoenix, while it does have opinions, is far less opinionated in the sense that it doesn't do it darndest to force you into certain conventions (for example, if your module name doesn't match your file name, Phoenix won't complain). Its generators do try and push you toward using good DDD practices (which is my opinion is a GREAT thing), but of course the generators are completely optional.
I don't have experience writing large LiveView apps but I would say that if you are familiar with any component-based frameworks (like React), I would take a look at SurfaceUI[1]. It simplifies a few "gotchas" in LiveView (though I would say they are very minor gotchas and worth learning about at some point) and gives you a component-rendering syntax more like React. Once you get going, you'll learn that LiveView doesn't have all the headaches that come with bigger React apps (like having to memoize functions or comparing props to avoid a re-render and whatnot). The recent release candidate for Phoenix 1.6 has made strides for a cleaner component syntax, but if you're having trouble with LiveView, Surface might bring some familiarity.
[1] https://github.com/surface-ui/surface
-
Phoenix 1.6.0-RC.0 Released
Have you seen Surface UI? Pretty cool. Collection of LiveView components. https://surface-ui.org/
- Surface UI – A server-side rendering component library for Phoenix
What are some alternatives?
fastapi - FastAPI framework, high performance, easy to learn, fast to code, ready for production
react_phoenix - Make rendering React.js components in Phoenix easy
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! 🚀
torch - A rapid admin generator for Elixir & Phoenix
Mercure - 🪽 An open, easy, fast, reliable and battery-efficient solution for real-time communications
phx_component_helpers - Extensible Phoenix liveview components, without boilerplate
datagram - In-progress version of draft-ietf-quic-datagram
phoenix_live_view - Rich, real-time user experiences with server-rendered HTML
stimulus_reflex - Build reactive applications with the Rails tooling you already know and love.
Raxx - Interface for HTTP webservers, frameworks and clients
geckos.io - 🦎 Real-time client/server communication over UDP using WebRTC and Node.js http://geckos.io
plug - Compose web applications with functions