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!
Feel free to reach out if you want to help! :)
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?
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.
This enables us/you to define interactive UI behavior by just configuring predefined Vue.js components in pure Ruby.
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
> Beeing a small dev team
> suffer less cognetive load
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 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.
Flutter should have just done the cross platform UI part and offered APIs in a number of languages.
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.
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?
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.
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).
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.
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.
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."
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.