Matestack – Reactive UIs in pure Ruby
matestack.io
Matestack – Reactive UIs in pure Ruby
1–10 of 120 posts
Re: Matestack – Reactive UIs in pure Ruby
#2Love 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 stuck with "the Asset Pipeline," purely MVC-style full-page-reload apps, and things like Coffeescript/jQuery by default.
It's really unfortunate because Rails is such a brilliant framework, and Ruby such a lovely language, and they're falling out of the mainstream and losing popularity because of this. I wish the community would re-align.
Michael Hartl's book, the go-to "learn Rails" resource, is a classic example. I think it's costing the community more than helping it nowadays. Although it's a great guide, it just feels weirdly out of date to be building a purely MVC full-page-reload app. And I think for every person it helps, five people look at it and think "seem like this isn't what I need for my project."
Re: Matestack – Reactive UIs in pure Ruby
#3Love 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 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. And since you're stuck with JS on the frontend there are some significant advantages to using it on the backend as well.
I don't think any of the current JS frameworks are as comprehensive as Rails but it's clear where the momentum is.
Re: Matestack – Reactive UIs in pure Ruby
#4Love 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…
Hmmm,
At least in rails 6 it moved away from the asset pipeline to a webpacker thing. It always was opinionated, and imho for many applications the classic full-page-reload cycle is still good enough, or a js client-side app doesn't bring any benefits besides being the cool thing to do. The docs were a problem from the beginning, but that improved a little with the official guides. As someone who used it on and off since version 1.x, it is obviously familiar and I am biased. Though it still feels like not really getting in my way when doing things and I can just write a feature and be done with it, when following the rails way.
In the past I spent a lot of time in the freenode #rubyonrails channel, and a lot of beginners would have benefited greatly from understanding how a MVC app works, and along with it stuff like request-/response cycle. Especially since this also translates well into API/client-side apps.
Sorry if this is a little incoherent, I am a little sleep deprived and back to the baby now :-)
Re: Matestack – Reactive UIs in pure Ruby
#5Love 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 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. And since you're stuck with JS on the frontend there are some significant advantages to using it on the backend as well. I don't think any of the current JS frameworks are as comprehensive as Rails but it's clear where the momentum is.
Actually I'm not seeing many projects with a JavaScript backend. In my experience the number is one, and it was 2015. I mean, backends of projects I worked on or somebody offered to hire me to work on. It could be selection bias and yet they're asking me about Java, which I basically abandoned about 15 years ago, PHP, which I know since the beginning of it but only kind of toyed with, even C# which I can read as a foreign language close to one I know but never used. I wonder if anybody asked me about Rust or Go, probably not. What they ask me about and I accept to work on are Ruby, Elixir and Python, in order of my preference. Python is a distant third (as preference.)
About frontend: JavaScript all the times if there is a frontend separate from the backend. React with some rare Angular project.
I'd like to make a poll and see how many of the people here are working on a JavaScript backend vs any other language.
Re: Matestack – Reactive UIs in pure Ruby
#6Earlier 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. And since you're stuck with JS on the frontend there are some significant advantages to using it on the backend as well. I don't think any of the current JS frameworks are as comprehensive as Rails but it's clear where the momentum is.
Actually I'm not seeing many projects with a JavaScript backend. In my experience the number is one, and it was 2015. I mean, backends of projects I worked on or somebody offered to hire me to work on. It could be selection bias and yet they're asking me about Java, which I basically abandoned about 15 years ago, PHP, which I know since the beginning of it but only kind of toyed with, even C# which I can read as a fo…
Same. I never understand these things I read about JavaScript momentum on the back end. I have yet to encounter a company using Express on the back end.
Re: Matestack – Reactive UIs in pure Ruby
#7Love 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…
Hmmm, At least in rails 6 it moved away from the asset pipeline to a webpacker thing. It always was opinionated, and imho for many applications the classic full-page-reload cycle is still good enough, or a js client-side app doesn't bring any benefits besides being the cool thing to do. The docs were a problem from the beginning, but that improved a little with the official guides. As someone who used it on and off s…
I certainly agree the classic full page reload approach is still completely relevant. It's more that most websites nowadays will employ a hybrid approach. They need a bit of both. Anything that isn't a static website is going to be using react or some other front end frameworks, and a lot of react involves asynchronous requests with REST APIs.
But most rails resources focus exclusively on the one approach, with very little of the other.
Re: Matestack – Reactive UIs in pure Ruby
#8Earlier quoted context omitted.
Actually I'm not seeing many projects with a JavaScript backend. In my experience the number is one, and it was 2015. I mean, backends of projects I worked on or somebody offered to hire me to work on. It could be selection bias and yet they're asking me about Java, which I basically abandoned about 15 years ago, PHP, which I know since the beginning of it but only kind of toyed with, even C# which I can read as a fo…
Same. I never understand these things I read about JavaScript momentum on the back end. I have yet to encounter a company using Express on the back end.
I've been curious about this lately: https://reimagined.github.io/resolve/.
Anyone use it? Thoughts?
Re: Matestack – Reactive UIs in pure Ruby
#9Love 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 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. And since you're stuck with JS on the frontend there are some significant advantages to using it on the backend as well. I don't think any of the current JS frameworks are as comprehensive as Rails but it's clear where the momentum is.
> 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).
Re: Matestack – Reactive UIs in pure Ruby
#10Love 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 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. And since you're stuck with JS on the frontend there are some significant advantages to using it on the backend as well. I don't think any of the current JS frameworks are as comprehensive as Rails but it's clear where the momentum is.
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 based approach where the whole application is delivered to the browser and you make the API calls.
Both have you writing majority of the code in C# and Razor templating syntax. Yes, you make an argument that well it’s technically still JS running it. But this becomes an implementation detail that will be ironed out, because technically the browser is written in C++, but we look beyond all that. And so on and so forth.
Now, I’m not saying I expect the world to move to .NET. Far from it. I have been preaching for a language agnostic browser execution engine so that I can write not only my logic, but my layout and styling in whatever language I want to, whether it’s Ruby or F# or Lisp, and have the browser execute it via its own internal “assembly code”. Except I’ve been parroting this idea since mid-2000s and we have at last finally started down that road.
I think this is where we are headed, and I don’t think it’s far fetched.