Frankly, while I like StimulusReflex a lot as an idea and library, I myself haven’t played with it yet (nor morphdom - just looked at it and it seems lovely) because I just was never that sure about websockets... There's something reassuring for me in pure HTTP that every request has its start and finish and message transfers are nicely guaranteed in a transparent way by TCP itself :). I can understand that websockets are great for async server-generated updates but as a main means of client-server communication channel, I don't know, perhaps I still need to grow into this...
From what I understood about Hey so far, the elements are truly agnostic about the transfer protocol and I've seen them used both in HTTP (as analyzed in this post) and in a websocket channel (try watching the channel while receiving a new email in Hey). This is the biggest difference for me between the two right now but if you say that StimulusReflex will be protocol-agnostic, too, then there's not much left as a difference, I guess! Apart from the feeling that StimReflex is much more advanced (and probably somewhat more complex, too) than these basic template page updates in Turbolinks...
We figured that getting to a proof-of-concept state with message_bus would take weeks, but our comrade @julianrubisch
knocked it out in a casual day of tinkering. It's not ready for prime time, but it's real.
I hear what you're saying about websockets as a transfer medium. We all read Sam Saffron's post a few years back; it was easy to come away with jitters, to say the least. However, in practice... I'm not sure I've heard anyone using ActionCable talk about losing packets.
I definitely don't want to "mansplain" - you clearly know your shit - but it sounds like I have worked more with ActionCable than you at this point. (And I'd worked a lot with Faye before that; then later, Pusher.) What I've come to appreciate is that the Rails team (I assume that it was mostly Sam?) really did an impressive job of borrowing TCP-esque service guarantees for the library. So, while it's a statement of fact that the ActionCable documentation is embarrassingly bad, the framework itself doesn't get nearly enough credit. For example, if the connection gets dropped, it has retry logic built in. It might not be bank/military grade but you can pretty much assume that the packets arrive in the right order. There's no ACK, but you could build a transaction concept with receipt confirmation very quickly if that was a motivation.
The other thing people tend to roast ActionCable for is scalability. What I can say is that when people outgrow ~4000 connections with AC, there's a drop-in socket server replacement written in Go called AnyCable that boasts ~10,000 connections per server, and is horizontally scalable.
As for relative complexity, it's genuinely hard to say. We have really high quality documentation and a growing number of training assets, like the now-infamous Twitter clone video: youtube.com/watch?v=F5hA79vKE_E
We'd be thrilled if you gave it a shot. You might be pleasantly surprised.
Dear @leastbad
, thank you, I really hear you. I can say that your comments alone alleviated my anxiety about making an app dependent on websockets tech tremendously and I'm definitely about to give it a try!
Yes, I read the Sam's article and in effect it materialized my vague concerns at that time. I noticed the article when I was doing some initial exploration of the technology and I can say it jumps out of Google really fast... I would definitely love to read a follow up response that would address the issues mentioned in the article (or elsewhere) from today's point of view! Just as you did here!
Thank you for that and I'm looking forward to trying the tech out.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thank you very much for your comment!
Frankly, while I like StimulusReflex a lot as an idea and library, I myself haven’t played with it yet (nor morphdom - just looked at it and it seems lovely) because I just was never that sure about websockets... There's something reassuring for me in pure HTTP that every request has its start and finish and message transfers are nicely guaranteed in a transparent way by TCP itself :). I can understand that websockets are great for async server-generated updates but as a main means of client-server communication channel, I don't know, perhaps I still need to grow into this...
From what I understood about Hey so far, the elements are truly agnostic about the transfer protocol and I've seen them used both in HTTP (as analyzed in this post) and in a websocket channel (try watching the channel while receiving a new email in Hey). This is the biggest difference for me between the two right now but if you say that StimulusReflex will be protocol-agnostic, too, then there's not much left as a difference, I guess! Apart from the feeling that StimReflex is much more advanced (and probably somewhat more complex, too) than these basic template page updates in Turbolinks...
Thanks again!
We figured that getting to a proof-of-concept state with message_bus would take weeks, but our comrade @julianrubisch knocked it out in a casual day of tinkering. It's not ready for prime time, but it's real.
I hear what you're saying about websockets as a transfer medium. We all read Sam Saffron's post a few years back; it was easy to come away with jitters, to say the least. However, in practice... I'm not sure I've heard anyone using ActionCable talk about losing packets.
I definitely don't want to "mansplain" - you clearly know your shit - but it sounds like I have worked more with ActionCable than you at this point. (And I'd worked a lot with Faye before that; then later, Pusher.) What I've come to appreciate is that the Rails team (I assume that it was mostly Sam?) really did an impressive job of borrowing TCP-esque service guarantees for the library. So, while it's a statement of fact that the ActionCable documentation is embarrassingly bad, the framework itself doesn't get nearly enough credit. For example, if the connection gets dropped, it has retry logic built in. It might not be bank/military grade but you can pretty much assume that the packets arrive in the right order. There's no ACK, but you could build a transaction concept with receipt confirmation very quickly if that was a motivation.
The other thing people tend to roast ActionCable for is scalability. What I can say is that when people outgrow ~4000 connections with AC, there's a drop-in socket server replacement written in Go called AnyCable that boasts ~10,000 connections per server, and is horizontally scalable.
As for relative complexity, it's genuinely hard to say. We have really high quality documentation and a growing number of training assets, like the now-infamous Twitter clone video: youtube.com/watch?v=F5hA79vKE_E
We'd be thrilled if you gave it a shot. You might be pleasantly surprised.
Dear @leastbad , thank you, I really hear you. I can say that your comments alone alleviated my anxiety about making an app dependent on websockets tech tremendously and I'm definitely about to give it a try!
Yes, I read the Sam's article and in effect it materialized my vague concerns at that time. I noticed the article when I was doing some initial exploration of the technology and I can say it jumps out of Google really fast... I would definitely love to read a follow up response that would address the issues mentioned in the article (or elsewhere) from today's point of view! Just as you did here!
Thank you for that and I'm looking forward to trying the tech out.