7 ms·

You can try out Turbolinks, the Rails equivalent for LiveView.

by d3nj4l 6y ago

latortuga 6y ago
This is not exactly a great characterization of turbolinks. TL definitely is great and useful for blurring the lines between server rendered and SPA, but it isn't anything like liveview. For that you're looking for something more like Motion (https://github.com/Unabridged/motion https://github.com/Unabridged/motion). Disclaimer, maintainer, but the comparison is much closer.
- ksec 6y ago
  And StimulusReflex, although Motion is slightly closer to LiveView, but both are in the same Category as LiveView. Turbolink is definitely not though.
Fire-Dragon-DoL 6y ago
No, liveview does everything on the server, including holding the frontend state, which is why it's so powerful. Liveview can't be reproduced in ruby, currently. It might be a possibility once Ractor are there, but even in that case Ruby doesn't have the performance optimizations of elixir templates (and given how liveview works, those are needed). It might never be possible, or it might be possible in many years.
- cutler 6y ago
  Yes this is where I see Ruby 3 being irrelevant, unfortunately. Ruby and Python are single-threaded, dynamically typed languages designed for the 1990s. You can try to retrofit anything you like and pretend you have real concurrency or static typing but it will never be the real thing and you'll just end-up with thousands of legacy libraries.
  - Fire-Dragon-DoL 6y ago
    I think Erlang is older than Ruby? (Not sure, but it's pretty old!) As for single threaded, they are not, even with green threads, IO is usually the problem (otherwise you chose the wrong language). As for static typing, there advantages and disadvantages to that, I wouldn't consider that a minus at all. A good engineering culture brings you in the same place with a dynamic or static typed language. Same goes for a bad engineering culture.

7 ms·

You can try out Turbolinks, the Rails equivalent for LiveView.

by d3nj4l 6y ago

You can try out Turbolinks, the Rails equivalent for LiveView.

latortuga 6y ago
This is not exactly a great characterization of turbolinks. TL definitely is great and useful for blurring the lines between server rendered and SPA, but it isn't anything like liveview. For that you're looking for something more like Motion (https://github.com/Unabridged/motion https://github.com/Unabridged/motion). Disclaimer, maintainer, but the comparison is much closer.
- ksec 6y ago
  And StimulusReflex, although Motion is slightly closer to LiveView, but both are in the same Category as LiveView. Turbolink is definitely not though.
Fire-Dragon-DoL 6y ago
No, liveview does everything on the server, including holding the frontend state, which is why it's so powerful. Liveview can't be reproduced in ruby, currently. It might be a possibility once Ractor are there, but even in that case Ruby doesn't have the performance optimizations of elixir templates (and given how liveview works, those are needed). It might never be possible, or it might be possible in many years.
- cutler 6y ago
  Yes this is where I see Ruby 3 being irrelevant, unfortunately. Ruby and Python are single-threaded, dynamically typed languages designed for the 1990s. You can try to retrofit anything you like and pretend you have real concurrency or static typing but it will never be the real thing and you'll just end-up with thousands of legacy libraries.
  - Fire-Dragon-DoL 6y ago
    I think Erlang is older than Ruby? (Not sure, but it's pretty old!) As for single threaded, they are not, even with green threads, IO is usually the problem (otherwise you chose the wrong language). As for static typing, there advantages and disadvantages to that, I wouldn't consider that a minus at all. A good engineering culture brings you in the same place with a dynamic or static typed language. Same goes for a bad engineering culture.