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

91–100 of 120 posts

Re: Matestack – Reactive UIs in pure Ruby

#91

Post by pdoub »

joelbluminator wrote: post #87
pdoub wrote: post #82

Earlier quoted context omitted.

Technically yes, we're abstracting away complexity and as always, this comes with a price and has the potential to fall on your toes down the road ;) In my eyes the available core components get you quite far already, and then, once you hit a certain threshold, it's "just" Vue.js and a therefore - in our eyes - a managable and approachable additional effort given you have some experience in JS (it's not like we make…

Thanks for clarifying! How did you choose FE framework, what were the considerations? If you wanted to have the same DSL but with Stimulus instead of Vue - would that have worked?

You're always welcome to ask, of course!

Regarding choice of FE framework: Back when Jonas started the prototyping (late 2017), Vue.js seemed to fit our needs perfectly due to its simple-and-leightweight-component architecture, I guess. It was also on a sweet spot between Angular and Ember (for which had you buy in on full SPA mode), React (which wasn't as lightweight back then as it has become by now, IIRC) and having to write everything in Vanilla JS. There were a bunch of other projects (like Mithril.js, Elm and Swelte, amongst others) where I'm not sure if they already were around / popular enough for us to know them, and (perhaps understandably) an existing, healthy ecosystem and some popularity & traction for other people to be able to use & extend what would eventually become Matestack were other contributing factors, and I think Vue.js continues to shine here.

Since we're getting a lot of requests on being able to use React (and now Stimulus) with the same DSL this is definitely on the roadmap, not sure on how it's going to get prioritized though. Perhaps best if you reach out to Jonas (https://twitter.com/JonasJabari), he's a lovely guy!

Re: Matestack – Reactive UIs in pure Ruby

#92

Post by pdoub »

aerovistae wrote: post #74
vinceguidry wrote: post #64

Earlier quoted context omitted.

Christ. It did keep up. Every new rails release just makes it better and better. Rails isn’t popular anymore because people followed the swan song of language isomorphism overlooking JavaScript’s deficiencies. NodeJS improved by... adding Rails features. It’s amazing that people think there’s more to this story. It was Node that couldn’t keep up with Rails. No one cares cuz they didn’t want to learn ruby.

I don't really see too many companies or projects using node on the back end. It's pretty hard to buy that node replaced rails. I see a lot more Java than anything else.

A lot of companies I'm speaking to (mostly Berlin/Germany based startups) have drank the "we have to use JS on the frontend anyways, and by going fullstack JS we can reduce our payroll since we can focus on only hiring JS devs and they magically work on ReactNative, the React web app and the Node.JS backend at the sime time" koolaid. Works super well for some, less so for others...

Edit: Explicitly added Node.JS since that's what they rave about for making it possible.

Re: Matestack – Reactive UIs in pure Ruby

#93

Post by pdoub »

ritchiea wrote: post #58
jamil7 wrote: post #17

Earlier quoted context omitted.

Might just be my area then (Berlin) I hardly see job ads for JS on the backend.

Wow we must be in separate Berlins because I see tons of JS backends. My impression is Javascript & Python are competing for most popular backend.

Seconded that in another comment in this thread. Lots of "fullstack JS saves you money since you can hire the same devs for web, backend & mobile" in Berlin, with varying success

Re: Matestack – Reactive UIs in pure Ruby

#94

Post by sutterbomb »

dperfect wrote: post #12
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…

I used Rails for a lot of projects starting ~10 years ago, but slowly gravitated towards a stack based on Sinatra (for a lean REST API), Middleman (static site generator), and webpack/react/etc - for mostly the reasons you describe. In hindsight, I can't blame Rails for the direction it took; JavaScript's path (the language itself, as well as the tools) has been extremely volatile in that time. Rails is opinionated,…

This is probably a very dumb question but I'm new to all this and trying to figure out how to mix/match these frameworks like you're describing. I have primarily a static site (using Jekyll, but Middleman would apply) but now need to add some server side stuff (e.g. with Sinatra). I see how I could dump my generated site into the Sinatra /public directory, but then I'm serving everything through the sinatra server when I really only want to hit that when I need the dynamic content/calls. How would I keep them separated while still having a single environment? Have tried googling to no avail, don't know if I'm asking the right questions. Any pointers would be super helpful! Thanks

Re: Matestack – Reactive UIs in pure Ruby

#95

Post by maxthegeek1 »

Lio wrote: post #29
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…

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.

Re: Matestack – Reactive UIs in pure Ruby

#96

Post by jozzy-james »

gls2ro wrote: post #50
arcturus17 wrote: post #24

Earlier quoted context omitted.

Can't tell what your SPA experience has been, but in my experience React with a standard webpack configuration such as what you get with create-react-app provides an extremely detailed trace. Never felt like I've lost more time than I should there.

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)...https://luckyframework.org uses it as well

Re: Matestack – Reactive UIs in pure Ruby

#97

Post by jozzy-james »

aerovistae wrote: post #74
vinceguidry wrote: post #64

Earlier quoted context omitted.

Christ. It did keep up. Every new rails release just makes it better and better. Rails isn’t popular anymore because people followed the swan song of language isomorphism overlooking JavaScript’s deficiencies. NodeJS improved by... adding Rails features. It’s amazing that people think there’s more to this story. It was Node that couldn’t keep up with Rails. No one cares cuz they didn’t want to learn ruby.

I don't really see too many companies or projects using node on the back end. It's pretty hard to buy that node replaced rails. I see a lot more Java than anything else.

i think it really depends on the industry - mine for example, most of the bigger players are running express apps on the FE (not 100% sure on backend, seems a mix of go/node and other things) - but why bother to run express/node on the frontend if you're not also going to leverage it on the backend.

Re: Matestack – Reactive UIs in pure Ruby

#98

Post by dperfect »

sutterbomb wrote: post #94
dperfect wrote: post #12

Earlier quoted context omitted.

I used Rails for a lot of projects starting ~10 years ago, but slowly gravitated towards a stack based on Sinatra (for a lean REST API), Middleman (static site generator), and webpack/react/etc - for mostly the reasons you describe. In hindsight, I can't blame Rails for the direction it took; JavaScript's path (the language itself, as well as the tools) has been extremely volatile in that time. Rails is opinionated,…

This is probably a very dumb question but I'm new to all this and trying to figure out how to mix/match these frameworks like you're describing. I have primarily a static site (using Jekyll, but Middleman would apply) but now need to add some server side stuff (e.g. with Sinatra). I see how I could dump my generated site into the Sinatra /public directory, but then I'm serving everything through the sinatra server wh…

Not a dumb question! I'm sure there are a lot of different approaches that could work.

For my own projects, I like to keep client-side code separated from the server-side code. The static site (with compiled JavaScript) gets deployed to S3/CloudFront, while the Sinatra API is packaged as a Docker image and deployed to ECS (or any container service)[1]. This means that Sinatra is only handling the API requests, and all of the markup, JavaScript, and other assets are served from a CDN.

[1] For this to work, you'll likely need to set up CORS on the server side, but that's well-supported now and fairly simple to set up.

Re: Matestack – Reactive UIs in pure Ruby

#99

Post by Fire-Dragon-DoL »

cutler wrote: post #88
Fire-Dragon-DoL wrote: post #70

Earlier quoted context omitted.

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.

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.

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.

Re: Matestack – Reactive UIs in pure Ruby

#100

Post by learc83 »

cutler wrote: post #62
troughway wrote: post #10

Earlier quoted context omitted.

This is a little bit premature of me to posit however I have a good feeling about tech like Blazor. In particular Blazor offers two interesting approaches (“hosting models”): 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. 2) a wasm ba…

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 anything that can't download a 2MB file up front (I believe their goal is to get it down to half that size) if you want to use the WASM version of Blazor instead of the websocket-based HTML sync layer version.

Post reply on HN