Matestack: Rapidly create interactive UIs in Ruby
11–20 of 42 posts
Re: Matestack: Rapidly create interactive UIs in Ruby
#12Core contributor here: Happy we made it to HN, maybe a notch too early :) Right now there's only two not very supporting comments here. Glad the authors have solutions that work for them, but Rest + SPA is overly complicated for most small/mid sized projects in our opion. Everyone else: Feel free to join our Gitter if you like what you see!
Do I understand correctly in that you are generating Vue.js components from Ruby? If so, how is that less complicated and not like an SPA than simply rendering HTML with erb or slim?
Where Matestack shines is when it comes to very generic JS behaviour that you don't want to recreate for the 100st time in a project - just wrap it into Matestack component and tell it what to do. I suggest watching my co-founder and Matestack creater Jonas introduce the concepts behind it: https://www.youtube.com/watch?v=OY5AeGhgK7I
Re: Matestack: Rapidly create interactive UIs in Ruby
#13I understand there's already some ruby feature to avoid full page refresh? I'm a js Dev currently working with a ruby backend. Honestly for what we're doing we could have just made a plain old html page and that would have been best, with some partial reload sprinkled here and there. I'm not sure if there's a market for this, but it's nice to see that you try new things. Right now I feel the pain of having a large re…
Most basic use cases (show/hide/rerender on event, deferred loading, onclick...) are part of the Matestack core and have good test coverage. For special use cases there's a guide on creating custom dynamic components, but yeah we could add some more info on debugging I guess. Not sure if my comment helped?
Re: Matestack: Rapidly create interactive UIs in Ruby
#14Core contributor here: Happy we made it to HN, maybe a notch too early :) Right now there's only two not very supporting comments here. Glad the authors have solutions that work for them, but Rest + SPA is overly complicated for most small/mid sized projects in our opion. Everyone else: Feel free to join our Gitter if you like what you see!
Do I understand correctly in that you are generating Vue.js components from Ruby? If so, how is that less complicated and not like an SPA than simply rendering HTML with erb or slim?
This enables us/you to define interactive UI behavior by just configuring predefined Vue.js components in pure Ruby.
If one needs custom UI behavior here and there, just add your own Vue.js components (write some lines of JavaScript) and then add and controll them like you do with the predefined dynamic (=Vue.js) core components. this approach is much easier than creating a standalone JS frontend app. You might end up writing 90-99% Ruby and just some lines of JS while getting an interactive, dynamic UI (or even a PWA if you add some meta information).
Re: Matestack: Rapidly create interactive UIs in Ruby
#15Re: Matestack: Rapidly create interactive UIs in Ruby
#16Re: Matestack: Rapidly create interactive UIs in Ruby
#17Hate to see efforts go to waste.
Re: Matestack: Rapidly create interactive UIs in Ruby
#18Re: Matestack: Rapidly create interactive UIs in Ruby
#19Nice, vue.js is super popular with the rails and laravel crowd. Trailblazer is also a great way to keep business logic out of the standard Rails MVC, and make testing trivial.
It also appears that it has similar features that Phoenix Live View does.
Re: Matestack: Rapidly create interactive UIs in Ruby
#20An API backend + UI front-end consuming it is the perfect solution, it is the only sane thing I ever came across. Stop trying so hard to shoehorn old bullshit over it. It took us decades to settle on this, please leave it be and focus on more pressing issues. World hunger or something.
> An API backend + UI front-end consuming it is the perfect solution I call shenanigans. It is perfect only if you hand-wave away the math and consequences. You've doubled your surface area, number of apps, stacks, dependency issues, deployment targets, bugs, uptime dependencies, hiring language/framework requirements and attack vectors. It is the right tool for some jobs. I'd encourage you to stop assuming any of th…