Matestack: Rapidly create interactive UIs in Ruby | Hacker News Reader

Matestack: Rapidly create interactive UIs in Ruby

matestack.org

174 pointsgremlinsinc39 comments

Core 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?

Basically, you're right. In a JS-free world this would be probably overblown (or a niche thing for Ruby fanatics).

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

Technical clarification: We don't "generate" Vue.js components. Matestack generates HTML that contains component tags. Those tags reference existing Vue.js components and hand over some configuration.

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).

This looks great. Slightly disappointed that it's not generically "in Ruby" but more specifically "in Rails", but the principle is really good and maybe there are a few bits that those of us who don't use Rails can extract.

I feel you and yes, there's plans to make it more into a PORO core and Rails/Hanami/Sinatra/personal flavor adapters. But we're a small team and Rails has the biggest market share & ecosystem, so it's the focus right now.

Feel free to reach out if you want to help! :)

I for one think that this looks incredibly impressive. A solution to reduce what needs to be written while giving ruby developers a powerful way to build a modern frontend, making it possible to stick with pretty much Ruby. And the website explains the concept very well. It's pretty much contrary to the route I took for my current project (and Rails instead of Ruby :( ), but something to bookmark and consider next time. Excited to see whether that concepts works as well in practice. That's a win in my book.

One question though: In your diagram you are saying Infrastructure 1, 2, 3 for the classical/current approach going into one API vs Matestack sitting on top of one infrastructure, right? Why? If there is an API sitting between backend and the UI there should not be a need for three backend infrastructures. I feel like you mean something else there, and the text also does not fit to the diagram as I understand it. Maybe something to double check.

The comment below how Matestack maps to native apps is warranted though. You are planning alternative renderers to web/vue, targeting native apps?

This looks very cool! I noticed some typos on the home page that should be corrected:

> Beeing a small dev team

> suffer less cognetive load

I have a habit of 'perusing' github for cool oss projects.

I'm the one who submitted this and while I haven't touch rails code since 2012, makes me almost want to give it a go again on my next project. That and I was reading that demand is higher than supply because a lot of people have jumped from rails, so employment prospects are good for at least awhile.

So I was looking at ways to make ui easier on rails.

Edit: I'm normally a vue/laravel dev. So I was actually searching rails + vue on github w/ more than 5 stars and updated in the past year. Because most rails tools/projects to seem to gear towards react, but I'm not a fan react/redux. I like SFC's in vue much better.

I like this trend of moving back toward component based architecture. This has many similarities to Flutter, which for me has been a major breath of fresh air.

What still gets me: HTML/CSS/JS honestly just sucks for building complex apps. We have shoehorned tools that were meant for simple document display into doing our bidding, but at what cost? Hours and hours of developer agony. It doesn't need to be this hard. I like looking at one file written in one language to see both the look and behavior of an app. There has just been too much mental overhead. I like the way things are going and this framework is step forward.

I really wish Flutter wasn't tied to Dart. Dart feels like a yet-another language with nothing over e.g. Go. Go can compile to JS and WASM now.

Doesn't Dart have generics and a lot of other language features that Go chose to omit?

Trouble is its yet another language to learn.

Flutter should have just done the cross platform UI part and offered APIs in a number of languages.

Would Flutter be where it is today without hotreload? Hotreload was a suggestion form the Dart team, Flutter team tried it and where amazed.

Hmm... that is interesting. Guess I will have to see if it uses native controls and is handicapped accessible. Last one is a deal breaker for a "real" UI library.

> HTML/CSS/JS honestly just sucks for building complex apps.

I think it's precisely the JS/web space that's doing most of the work for exploring the exact ideas that make complex clients tractable and pleasant to develop.

For example, React and Elm are a lot closer to an ideal than any desktop/mobile client stack I've used.

You find “hours and hours of developer agony” everywhere. Between TypeScript, React, and styled components, I’ve come to find it extremely enjoyable to build interesting and complex things for the browser. A few years ago, I’d have agreed with you we’ve been using the wrong tools. More and more, I feel like we’re finally seeing tools that help the job be creative and enjoyable instead of a frustrating, uphill battle.

>I like looking at one file written in one language to see both the look and behavior of an app

Isn't this the basis for the prediction that every app that can be written in JavaScript will eventually be rewritten in JavaScript.

> A modern View Layer for Rails built on Trailblazer and Vue.js

Nice, 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.

I don’t get it. It seems to be a haml-like syntax for writing HTML, with a jquery-like set of canned js interactions? This is how we wrote apps in 2008

I 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 react codebase while most of the team prefers working in ruby. The risk with such project imo is to have insufficient abstractions and to end up debugging js code in the browser anyway. How about code splitting, hot reload, automatic assets compiling, etc .. that we've come to expect when developing front ends ?

Since we're not compiling Ruby into JS (I think Opal/Hyperstack does this) debugging can be done using the Vue Dev Tools in the browser, so you're not worse off there.

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?

In their architecture diagram they're comparing their stack to one with distinct native UIs for each device type but they don't really explain how they're replicating that functionality. Unless there's some trick there should still be 3 UI blocks in the Ruby side of their diagram.

I won't go so far as to say this makes things worse but it seems like you're just moving things around. You can still have distinct client code on the Ruby side. If your goal is to simply move all this work out of JavaScript and into Ruby because you like Ruby, it seems fine.

You no longer have the explicit rest API to force a separation of UI and business logic but you can just enforce that with coding practices. You lose the ability to decouple UI dev entirely though.

I don't really understand what are they fixing here. They point that current web development has shifted to "REST backend" and "SPA frontend", which (according to them) is not a good thing (why?). Their solution is to make you write (again) a "full" MVC-backend that also serves the UI (frontend), and additionally, extend it with another frontend layer (Vue).

IMHO that is not fixing the initial problem they are stating that exists, but making it worse, because now you have to write UI-related code in two languages (ruby and js) instead of the 1 that is currently needed (REST + SPA).

If I'm not wrong you're assuming that the REST backend is written in JavaScript. This is not always the case. I personally saw that happen only once. All the other times the backend was either Java, Ruby, Python, Elixir.

What's risky is that a few people will know this technology. Far more know React, Angular, Vue. On the other side the same person writing the backend can write the frontend, assuming knowledge of HTML and CSS. So one project, not two. Probably cheaper.

After watching the youtube video, I feel that this actually is VERY competitive with elixir's phoenix live view. It uses websockets too.

Sweet. Are there any similar projects for Python, e.g. Django?

Reminds me of the components talk at RailsConf https://railsconf.com/program/sessions#session-810

Reminds me of inertia.js!

Interesting project... What's the biggest downside you can think of by adopting this approach? all projects have to have downsides as well as benefits... what's the trade-off here

Are there similar projects for other languages?

`my_frist_page`

would be a funny name for a dating app in SV.

Can we please stop writing html inside Javascript or Ruby in this case?

An 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.

It is completely unclear to me whether you are agreeing what Matestack does or not. It could be read as: "Yes exactly, this is what we need, not this other tech." or "What you have built is nonsense, please spend your time differently"

Also, it is completely unclear to me what 'old bullshit' is in your story. Is an API backend with UI front-end old or new? It could be read as that or as "API backend with JS front-end is the best, stop trying to push server-side rendered HTML on us."

Maybe a more tactful restatement:

This looks and feels a whole lot like what the Rails community was doing a decade ago with interpolated server-side values into ERB templates that contained script tags of jQuery. It seems like an old pattern that fell out of favor for good reasons (lack of fine grained control over the final rendered page's design and performance, still needing competencies in the front end tools when things don't work ideally, update and migration path difficulties for the front end, performance and caching issues, etc). I would personally not use Matestack as it seems like it has all the same pitfalls.

> 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 this is done. People thought that when XML and Soap were the thing.

Reply on news.ycombinator.com