4 ms·

I don't know why but when I read this from the article: > Because WebSockets is effectively a blank canvas, there are a lot of choices to be made when designin

by nickjj 5y ago

I don't know why but when I read this from the article: > Because WebSockets is effectively a blank canvas, there are a lot of choices to be made when designing a protocol on top of it, and no one way of doing it has yet gained momentum. It immediately reminded me of Flash. Flash was basically a blank canvas where you can do just about anything. Turns out that's not a very good model for a number of reasons -- one of which being it turns everything you do into a snowflake and you need to invent your own patterns and abstractions instead of leaning on an extremely well thought out but more limited approach that's been vetted for many years before Flash was a thing. I don't think WebSockets are really bad but it makes me internally wince whenever I see tech stacks trying to push using them for everything, even for transitioning between pages with no broadcast mechanism. Now I see part of the allure though. If you're a language or framework maker you get to make decisions at the protocol level instead of sticking to decades of standards which is the awesomeness of HTTP. I'm all for sprinkling in tiny bits of WebSockets when it makes sense, ie. doing actual pub/sub things like showing notifications or showing messages like "4 new people commented on your post, click here to show them". In the same way that it felt ok to use a little bit of Flash back in the day for specific functionality instead of throwing out everything and trying to make your entire site in Flash.

dpeck 5y ago
| Flash was basically a blank canvas where you can do just about anything. Turns out that's not a very good model for a number of reasons I don’t think of this as a bad thing. There was exactly a lot of what you say happening around that time, but the time when Flash was biggest was also a time of massive creativeness on the web. I think we’re missing some of that now, and I’m more than ok with our collective “pendulum” swinging back towards the blank canvas than the overfit tech world we have today.
PragmaticPulp 5y ago
WebSockets are actually fantastic for providing low overhead and high flexibility. It’s really not difficult to use any number of modern frameworks to do things like encode and decode from wire formats or even multiplex across the channel. WebSockets shouldn’t be approached as a “from scratch” communication method unless you have very specific needs or your application is dead simple. Everyone else should take advantage of the numberous libraries available to help with the basics. > I don't think WebSockets are really bad but it makes me internally wince whenever I see tech stacks trying to push using them for everything, even for transitioning between pages with no broadcast mechanism. I’m not up to date with the less popular web frameworks. Which frameworks do that?
- nickjj 5y ago
  > I'm not up to date with the less popular web frameworks. Which frameworks do that? One of them is https://github.com/phoenixframework/phoenix_live_view https://github.com/phoenixframework/phoenix_live_view which is a component of Phoenix / Elixir. It will render your initial page over HTTP but then when you transition pages or perform actions using various functions it provides you it will send a diff of what's changed over WebSockets. These actions could be limited to only the 1 user using the site, such as clicking different links in a nav bar to transition between page A and B. The alternative to this is doing what other frameworks like Rails has done with Hotwire Turbo where they make these types of transitions or actions over HTTP. Turbolinks started to do this back in 2015 or whenever it came out and now more recently with Hotwire Turbo there's ways to only update a tiny area of the page (again over HTTP) but it also optionally supports using WebSockets for when you want to broadcast things to all connected clients, such as updating a counter somewhere or maybe showing a new reply on a blog post, etc.. Laravel has Live Wire and there's also HTMX which is back-end agnostic which all use HTTP for a bulk of their behaviors to send server rendered HTML over the wire. I'm not a Laravel developer but based on their docs they have a drop in solution to handle broadcasting events with WebSockets on demand too[0] so it can continue using HTTP for everything except for when you want to broadcast events similar to Hotwire Turbo in that regard. [0]: https://laravel-livewire.com/docs/2.x/laravel-echo https://laravel-livewire.com/docs/2.x/laravel-echo
  - lolinder 5y ago
    What exactly bugs you about LiveView's use of websockets? I.e., is it performance, accessibility, aesthetics, or something else? I ask as someone who's very interested from a distance in what Phoenix is doing with websockets, but hasn't gotten into it enough to understand the cons.
    - rainbowlove 5y ago
      I'm not sure they understand that the copycats needed to be built with non-websockets as a primary transport because of the limitations of those other frameworks. The BEAM and Erlang/OTP introduce an entirely different set of considerations when it comes to maintaining and managing on the order of millions of concurrent stateful websockets connections. The architecture of Plug/ Phoenix also means that, should the community come to a conclusion that websockets are no longer right, the transport mechanism is extensible, but the underlying interface and semantics of your application would be essentially unchanged. The Elixir forums would be a better place to inquire about websockets vs. SSE implementations for LiveView.
jcelerier 5y ago
> Flash was basically a blank canvas where you can do just about anything. Turns out that's not a very good model for a number of reasons -- one of which being it turns everything you do into a snowflake and you need to invent your own patterns and abstractions instead of leaning on an extremely well thought out but more limited approach that's been vetted for many years before Flash was a thing. yet we're in 2022 and the only things that are remotely competitive with what Flash allowed 15 years ago, are some games put in WASM blobs (which will "work" until $BROWSER deprecates some API in two years).
- ShoveItHN 5y ago

by nickjj 5y ago

dpeck 5y ago

| Flash was basically a blank canvas where you can do just about anything. Turns out that's not a very good model for a number of reasons I don’t think of this as a bad thing. There was exactly a lot of what you say happening around that time, but the time when Flash was biggest was also a time of massive creativeness on the web. I think we’re missing some of that now, and I’m more than ok with our collective “pendulum” swinging back towards the blank canvas than the overfit tech world we have today.

PragmaticPulp 5y ago

WebSockets are actually fantastic for providing low overhead and high flexibility. It’s really not difficult to use any number of modern frameworks to do things like encode and decode from wire formats or even multiplex across the channel. WebSockets shouldn’t be approached as a “from scratch” communication method unless you have very specific needs or your application is dead simple. Everyone else should take advantage of the numberous libraries available to help with the basics. > I don't think WebSockets are really bad but it makes me internally wince whenever I see tech stacks trying to push using them for everything, even for transitioning between pages with no broadcast mechanism. I’m not up to date with the less popular web frameworks. Which frameworks do that?

nickjj 5y ago
> I'm not up to date with the less popular web frameworks. Which frameworks do that? One of them is https://github.com/phoenixframework/phoenix_live_view https://github.com/phoenixframework/phoenix_live_view which is a component of Phoenix / Elixir. It will render your initial page over HTTP but then when you transition pages or perform actions using various functions it provides you it will send a diff of what's changed over WebSockets. These actions could be limited to only the 1 user using the site, such as clicking different links in a nav bar to transition between page A and B. The alternative to this is doing what other frameworks like Rails has done with Hotwire Turbo where they make these types of transitions or actions over HTTP. Turbolinks started to do this back in 2015 or whenever it came out and now more recently with Hotwire Turbo there's ways to only update a tiny area of the page (again over HTTP) but it also optionally supports using WebSockets for when you want to broadcast things to all connected clients, such as updating a counter somewhere or maybe showing a new reply on a blog post, etc.. Laravel has Live Wire and there's also HTMX which is back-end agnostic which all use HTTP for a bulk of their behaviors to send server rendered HTML over the wire. I'm not a Laravel developer but based on their docs they have a drop in solution to handle broadcasting events with WebSockets on demand too[0] so it can continue using HTTP for everything except for when you want to broadcast events similar to Hotwire Turbo in that regard. [0]: https://laravel-livewire.com/docs/2.x/laravel-echo https://laravel-livewire.com/docs/2.x/laravel-echo
- lolinder 5y ago
  What exactly bugs you about LiveView's use of websockets? I.e., is it performance, accessibility, aesthetics, or something else? I ask as someone who's very interested from a distance in what Phoenix is doing with websockets, but hasn't gotten into it enough to understand the cons.
  - rainbowlove 5y ago
    I'm not sure they understand that the copycats needed to be built with non-websockets as a primary transport because of the limitations of those other frameworks. The BEAM and Erlang/OTP introduce an entirely different set of considerations when it comes to maintaining and managing on the order of millions of concurrent stateful websockets connections. The architecture of Plug/ Phoenix also means that, should the community come to a conclusion that websockets are no longer right, the transport mechanism is extensible, but the underlying interface and semantics of your application would be essentially unchanged. The Elixir forums would be a better place to inquire about websockets vs. SSE implementations for LiveView.

jcelerier 5y ago

> Flash was basically a blank canvas where you can do just about anything. Turns out that's not a very good model for a number of reasons -- one of which being it turns everything you do into a snowflake and you need to invent your own patterns and abstractions instead of leaning on an extremely well thought out but more limited approach that's been vetted for many years before Flash was a thing. yet we're in 2022 and the only things that are remotely competitive with what Flash allowed 15 years ago, are some games put in WASM blobs (which will "work" until $BROWSER deprecates some API in two years).

ShoveItHN 5y ago