
Matestack: Rapidly create interactive UIs in Ruby - gremlinsinc
https://www.matestack.org/
======
pdoub
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!

~~~
mosselman
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?

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

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

~~~
api
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.

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

~~~
api
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.

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

------
jes5199
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

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

~~~
pdoub
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?

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

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

~~~
pmontra
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.

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

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

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

------
sansnomme
Reminds me of inertia.js!

------
weaksauce
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

------
haolez
Are there similar projects for other languages?

------
m712
`my_frist_page`

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

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

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

~~~
ericb
> 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.

