Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Matestack – Reactive UIs in pure Ruby

matestack.io

Post reply on HN
Print view View original

101–110 of 120 posts

Re: Matestack – Reactive UIs in pure Ruby

#101

Post by tomc1985 »

aerovistae wrote: post #2

Love the idea of it, even if it's not for me. Ruby needs new blood infused into it. I realized recently that Rails started losing its popularity because it just didn't quite keep up as the web evolved. Where the framework and its community resources (guides/tutorials) should have started promoting REST APIs and out-of-the-box no-friction compatibility with modern tooling like npm/webpack/react/whatever, instead it st…

We come from dramatically different perspectives because building page-reloading MVC still feels fine, as fine as it ever did.

And Turbolinks is Rails' answer to the madness that is JS frameworks. You get a lot of the functionality of a single page app while still keeping the much-easier-to-code-for serverside rendering

I am very happy I don't have to touch JS frameworks if I don't want to. Because I hate all of them (except Vue and jquery, they're cool)

Rails isn't for trendy hipster JS kids, and I hope it never will be. I don't want those people in this space, they fuck everything up

Re: Matestack – Reactive UIs in pure Ruby

#102

Post by cutler »

learc83 wrote: post #100
cutler wrote: post #62

Earlier quoted context omitted.

Blazor currently has to haul its runtime over the wire before it can do anything so a non-starter for anything performance-sensitive.

Did you miss this part: >1) a websocket-based HTML sync layer, basically shipping over the smallest amounts of render state from the back-end. This is as close as you get to having, essentially, a server-side rendered page that is then updated in real time. Also it's not like you have to load the runtime more than once. So it's not that it's a non-starter for anything performance sensitive--it's a non-starter for any…

Compared to React + React DOM at 109k unzipped Blazor's runtime at 2MB is a significant hike in download size so unsuitable for older devices and constrained bandwidth networks.

Re: Matestack – Reactive UIs in pure Ruby

#103

Post by muglug »

arcturus17 wrote: post #19
muglug wrote: post #9

Earlier quoted context omitted.

> I think it's more that the massive engineering effort that's gone into improving JS has leapfrogged it over languages like Python, Ruby & PHP in terms of performance and tooling This is not true – PHP is still much faster when running on the server than NodeJS. JS has got much faster in the last 20 years, but in-browser execution has seen most of the speedup (as it's where most of the optimisation is focussed on).

What benchmarks are you basing this on? From what I can find, in most benchmarks, Node.js is much faster than PHP - orders of magnitude in many cases [1]... This is what I've always heard anyway, that the amount of R&D that has gone into engines like V8, the C++ under the hood and the I/O model make it so. [1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

PHP isn't faster for arbitrary mathematical workloads (though the JIT in PHP 8 will help with those).

Instead PHP is faster for the things websites normally do, like string manipulation.

Re: Matestack – Reactive UIs in pure Ruby

#104

Post by arcturus17 »

muglug wrote: post #103
arcturus17 wrote: post #19

Earlier quoted context omitted.

What benchmarks are you basing this on? From what I can find, in most benchmarks, Node.js is much faster than PHP - orders of magnitude in many cases [1]... This is what I've always heard anyway, that the amount of R&D that has gone into engines like V8, the C++ under the hood and the I/O model make it so. [1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

PHP isn't faster for arbitrary mathematical workloads (though the JIT in PHP 8 will help with those). Instead PHP is faster for the things websites normally do, like string manipulation.

I see this is the hill you want to die on...

"Instead PHP is faster for the things websites normally do, like string manipulation."

No, this is not right for a couple of reasons. NodeJS is potentially slower in certain CPU-bound tasks due to the single-threaded nature of JavaScript.

On the other hand, thanks to its event loop and concurrency model, NodeJS is much faster than many languages/runtimes in I/O (reading/writing to stores, fetching data from other servers, etc.) - which is what many web servers do most.

Your original comment also mentioned:

"in-browser execution has seen most of the speedup (as it's where most of the optimisation is focussed on)."

Which is also not true. The V8 engine is hyperoptimized and runs not only Chrome but Node too. It is precisely one of the reasons why server-side JS has gained in popularity over the last decade. The fact that it was initially devised for a browser environment does not mean that optimisation is focused there.

If you're an engineer or web developer I really suggest that you brush up on these things, because with comments like the ones you've been dropping you'd definitely raise eyebrows - and not for the good...

Re: Matestack – Reactive UIs in pure Ruby

#105

Post by ksec »

latortuga wrote: post #55
d3nj4l wrote: post #43

Earlier quoted context omitted.

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

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 ). Disclaimer, maintainer, but the comparison is much closer.

And StimulusReflex, although Motion is slightly closer to LiveView, but both are in the same Category as LiveView. Turbolink is definitely not though.

Re: Matestack – Reactive UIs in pure Ruby

#106

Post by ksec »

maxthegeek1 wrote: post #95
Lio wrote: post #29

Earlier quoted context omitted.

I’m actually quite bullish about Rails for the fitst time in a while due to StimulusRelex[1]. It’s a similar approach to Elixir’s Liveview and provides reactive, diff’d partial updates streamed over a websocket. This seems a very “now” approach to building webapps. 1. https://docs.stimulusreflex.com/

Neither Elixir Liveview nor StimulusReflex are really viable longterm, especially for mobile web. The idea of chattily streaming UI changes over the network doesn't work out for mobile web, where networks are frequently unreliable if not totally inaccessible.

If the Network is unreliable how is that any different to failing to updating / reloading a page?

Or you are referring to Web Apps that work offline?

Re: Matestack – Reactive UIs in pure Ruby

#107

Post by ksec »

joelbluminator wrote: post #41
Lio wrote: post #29

Earlier quoted context omitted.

I’m actually quite bullish about Rails for the fitst time in a while due to StimulusRelex[1]. It’s a similar approach to Elixir’s Liveview and provides reactive, diff’d partial updates streamed over a websocket. This seems a very “now” approach to building webapps. 1. https://docs.stimulusreflex.com/

> streamed over a websocket That's my problem with this approach, I wonder what the penalty is (performance and complexity wise) for going that route. What is it using for websockets btw, Action Cable?

>What is it using for websockets btw, Action Cable?

And that is a problem because by default Action Cable isn't scalable. You cant get it work by 100 - 200 connection and response time are very slow at 50ms+ and a lot higher at 95th percentile. AnyCable helps a lot but this is another pieces of complexity added to the system.

Not a problem for Elixir and BEAM when they are sort of built for these type of workload.

Although I am waiting for all the Fibre, Async and Ractor addition to Ruby 3 and see how they add fit in.

Re: Matestack – Reactive UIs in pure Ruby

#108

Post by gls2ro »

jozzy-james wrote: post #96
gls2ro wrote: post #50

Earlier quoted context omitted.

Probably nowadays React with webpack provides a stable experience. It might be that my impression of SPA is also based on my resistance to dedicate time to learn the new tools. Usually I want to start doing stuff and then go back and read more. This is why I say it felt that way and I did not say that the SPA is unstable. Here is how my experience with SPA looked like: - I started with jQuery, 10 years ago or so (act…

you might be interested in https://inertiajs.com/ if you're using rails (or laravel) - doesn't solve SSR if needed, but in my limited use does provide a nice middle ground for not needing to go full SPA editing to add: https://laravel-mix.com/ is a nice wrapper around some common webpack setup gotchas, despite having laravel in the name it's just regular old webpack (other than the default output directories)... http…

Wow thank you. InertiaJS might be exactly what I was looking for to integrate some small Vue into a Rails app.

Also I keep looking for an opportunity where I would use Lucky Framework with Crystal just to give it a spin.

Re: Matestack – Reactive UIs in pure Ruby

#109

Post by joelbluminator »

ksec wrote: post #107
joelbluminator wrote: post #41

Earlier quoted context omitted.

> streamed over a websocket That's my problem with this approach, I wonder what the penalty is (performance and complexity wise) for going that route. What is it using for websockets btw, Action Cable?

>What is it using for websockets btw, Action Cable? And that is a problem because by default Action Cable isn't scalable. You cant get it work by 100 - 200 connection and response time are very slow at 50ms+ and a lot higher at 95th percentile. AnyCable helps a lot but this is another pieces of complexity added to the system. Not a problem for Elixir and BEAM when they are sort of built for these type of workload. Al…

> AnyCable helps a lot but this is another pieces of complexity added to the system.

What is the added complexity? I honestly never used all this stuff.

Re: Matestack – Reactive UIs in pure Ruby

#110

Post by tored »

arcturus17 wrote: post #104
muglug wrote: post #103

Earlier quoted context omitted.

PHP isn't faster for arbitrary mathematical workloads (though the JIT in PHP 8 will help with those). Instead PHP is faster for the things websites normally do, like string manipulation.

I see this is the hill you want to die on... "Instead PHP is faster for the things websites normally do, like string manipulation." No, this is not right for a couple of reasons. NodeJS is potentially slower in certain CPU-bound tasks due to the single-threaded nature of JavaScript. On the other hand, thanks to its event loop and concurrency model, NodeJS is much faster than many languages/runtimes in I/O (reading/wr…

Benchmarks that try to replicate reality actually shows the opposite, PHP web stack beats NodeJS web stack.

https://www.techempower.com/benchmarks/#section=data-r19&hw=...

It is certainly true that NodeJS has become much faster as your synthetic benchmarks shows, however we have to measure our programs in the context of intended use, as previous poster suggested.

NodeJS wins against PHP when NodeJS does not make an external database call, like in the two test suites JSON serialization and Plaintext, but as soon as you throw in MySQL database PHP wins.

What does this tells us? That V8, the implementation of the JavaScript, is faster than the Zend engine, the implementation of PHP, but the event based NodeJS platform is not faster than the PHP(Apache/Nginx) platform.

NodeJS performance has evolved massively thanks to V8 R&D, as you already mentioned, Zend Engine has also gained a lot performance but of course not comparable to V8 for obvious reasons, the prior is a Google based project, the latter is a volunteer community based project. However the PHP stack also consist of a web server, and they has also evolved massively the past 20 years, Nginx is relatively new on the scene with an event based asynchronous architecture and Apache has evolved with a new PHP module.

I think your personal attacks against muglug, regardless if he was right or wrong, is not appropriate for this forum, especially when you yourself is not entirely up to date.

Edit: typo

Post reply on HN