Matestack – Reactive UIs in pure Ruby
matestack.io
matestack.io
The other problem is that if you use this you only learn the specific DSL which isn't portable. But if you use and learn the basic technologies under it - HTML, CSS, and pure JS now that is something you can use elsewhere even if you throw Ruby away completely. And the knowledge of the basics is really really important and useful.
Anyways, what is a problem with writing good old .html.erb templates? I don't think there is any.
And for the reactivity thing - the most easiest and fastest(10 minutes at max to install and enable) is to just turn on Turbolinks[1] and include this little plugin[2][3] for persistent scroll position where you want. Now when when you click marked with `data-turbolinks-scroll = "false"` Turbolinks fetches the page, replaces the current page with it, and you are still at the same scroll position. No need for SPA or JS heavy FE or anything.
[1] https://github.com/turbolinks/turbolinks [2] https://medium.com/@kosovacsedad/how-to-turbolinks-5-scroll-... [3] https://gist.github.com/sedadkosovac/661d0fd369069cad010f164...
As i'm thinking about it only DSL i find useful is Nokogiri's XML builder. That can save me some time sometimes.
Good luck with Matestack anyways. It's just not for me i think
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."
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 :-)
But most rails resources focus exclusively on the one approach, with very little of the other.
And yeah, I also think a mix is what makes sense for most things, and there it can be anything from plain js/jquery through stimulusjs to react/vue.
Even though it sounds to me like I am trying to defend rails, this is not really what I am trying to do, just trying to show a little bit different perspective :-)
yes, I strongly agree with this, specially when talking about Web tech.
I am programming in Ruby (and Rails) for over 12 years and I think I had the same feeling up until a couple of years ago that it become a stable system where I could move quickly and create new products but did not have so much newness.
But now I see at least two things which makes me love even more this ecosystem:
1. Stimulus JS along with StimulusRelfex https://docs.stimulusreflex.com/reflexes
2. ViewComponent https://viewcomponent.org
And now I discovered this Matestack.
I am excited because Ruby on Rails is a technology I know very well and I was (and still am) a little against moving to full SPA and adopting a JS framework for frontend. Somehow the SPA felt to me a little unstable in general, when compared with SSR. This unstable I think was mostly due to being very hard to debug real production issues.
It might be from the way debugging worked in the beginning not showing proper line of code where the JS error was, or it might be because of my own resistance to change.
But now with these new tools added to the Ruby eco-system I can make the web interface more responsive and in the same time feel that I only add stable components into an app.
But I have to acknowledge that in some domains, some users expect the web app to behave in a specific way and adding some reactivity makes my life easier. This is why I prefer to use contained - and constrained - solutions (like Stimulus or Stimulus Reflex) which does not impose to change my .html.erb views to accommodate them.
It might be that my impression of SPA is also based on my resistance to dedicate time to learn the new tools. Usually I want to start doing stuff and then go back and read more.
This is why I say it felt that way and I did not say that the SPA is unstable.
Here is how my experience with SPA looked like:
- I started with jQuery, 10 years ago or so (actually with Scriptaculous :) ), replacing parts of the interface with Ajax calls. Worked a little for a while then got into very ugly code both on JS and on Ruby. This was not a full SPA, but it was moving into that direction.
- Then I moved to Backbone around 2013 I think. In the beginning it sounded very nice in the end again the code and mix with jQuery quickly become hard to organise. Also as it started to be slower to build MVPs in terms of moving fast and adding application features.
- So I tried Angular and my main problem there was debugging production issues. The errors I saw on browser console were mostly not giving any clue about what went wrong. Probably it was because of the whole compile JS pipeline to support various browsers ...
- Then I inherited a Webapp written in React (around 2014 or 2015) with backend in Rails which was a second-screen for a radio show. It provided various live interaction with listeners. There I saw the need for SPA but also is where SPA lost me as I spent a lot of time debugging simple things from someone could not be able to login to how long it took to add a new page to display some poll results. For sure a big part (or the most part) is on me and with my expectation about how things were working in Rails where if I wanted a page to display some poll results it meant to simply build a .html.erb and it was done. Of course later on came Action Cable and I started using it for any live thing.
Again I am not saying SPA is in general heavy or hard to use. I am saying that for the products I build SSR sprinkled with some small reactive things is enough and for me (when I am mostly the solo developer) it is fast to produce (from idea to deploy) and debug a feature for a web app.
That being told I am trying to learn Vue - and force myself to use so that I want to have experience with this kind of frameworks.
editing to add: https://laravel-mix.com/ is a nice wrapper around some common webpack setup gotchas, despite having laravel in the name it's just regular old webpack (other than the default output directories)...https://luckyframework.org uses it as well
Also I keep looking for an opportunity where I would use Lucky Framework with Crystal just to give it a spin.
And for the full page reloads, which you think is weird, there are Turbolinks(again preconfigured in the basic install) since like 2012. I'm not sure React or other reactivity foos already existed at this time. And now we have things like Stimulus and Stimulus Reflex and others so the development ain't stoping now either.
So the feeling that Rails are stuck or out of date is really only a feeling.
In hindsight, I can't blame Rails for the direction it took; JavaScript's path (the language itself, as well as the tools) has been extremely volatile in that time. Rails is opinionated, which is part of what makes it great, but to be more opinionated on JS in the past probably would have been detrimental to the Rails community. I've felt the pain in my own work: every 2 weeks, it feels like my webpack/react/babel/etc toolchain and codebase need to be refactored because what was recently best-practice is now considered "legacy" and unsupported. When you embrace a specific set of technologies, you take on a certain amount of risk that those technologies will be deprecated, unsupported, or unpopular tomorrow.
I believe (hope is probably the better word) the JS landscape is getting more mature and stable, and it makes sense that the recent versions of Rails have incorporated more of what has become "standard" JS tooling. I'll always love Ruby, and even if I don't use Rails at the moment, I appreciate what Rails is doing and I directly benefit from the contributions of the Rails community.
More recently, I've been trying to learn some Elixir (those Phoenix LiveView demos look amazing), but not sure I'm ready to jump in 100%. Looks like matestack is essentially doing something similar with Ruby, so I'll be interested to see where it goes.
For my own projects, I like to keep client-side code separated from the server-side code. The static site (with compiled JavaScript) gets deployed to S3/CloudFront, while the Sinatra API is packaged as a Docker image and deployed to ECS (or any container service)[1]. This means that Sinatra is only handling the API requests, and all of the markup, JavaScript, and other assets are served from a CDN.
[1] For this to work, you'll likely need to set up CORS on the server side, but that's well-supported now and fairly simple to set up.
Liveview can't be reproduced in ruby, currently. It might be a possibility once Ractor are there, but even in that case Ruby doesn't have the performance optimizations of elixir templates (and given how liveview works, those are needed). It might never be possible, or it might be possible in many years.
As for static typing, there advantages and disadvantages to that, I wouldn't consider that a minus at all. A good engineering culture brings you in the same place with a dynamic or static typed language. Same goes for a bad engineering culture.
It’s amazing that people think there’s more to this story. It was Node that couldn’t keep up with Rails. No one cares cuz they didn’t want to learn ruby.
Edit: Explicitly added Node.JS since that's what they rave about for making it possible.
It’s a similar approach to Elixir’s Liveview and provides reactive, diff’d partial updates streamed over a websocket.
This seems a very “now” approach to building webapps.
That's my problem with this approach, I wonder what the penalty is (performance and complexity wise) for going that route. What is it using for websockets btw, Action Cable?
And that is a problem because by default Action Cable isn't scalable. You cant get it work by 100 - 200 connection and response time are very slow at 50ms+ and a lot higher at 95th percentile. AnyCable helps a lot but this is another pieces of complexity added to the system.
Not a problem for Elixir and BEAM when they are sort of built for these type of workload.
Although I am waiting for all the Fibre, Async and Ractor addition to Ruby 3 and see how they add fit in.
What is the added complexity? I honestly never used all this stuff.
The idea of chattily streaming UI changes over the network doesn't work out for mobile web, where networks are frequently unreliable if not totally inaccessible.
Or you are referring to Web Apps that work offline?
Many native mobile apps have these properties, and if mobile web apps want to compete they will have to as well.
In practice, that means generally minimizing network traffic, being smart about caching data, and providing soft failure modes.
Neither Liveview nor StimulusReflex are well suited to this problem space.
But more importantly, Rails is still insanely productive to work with. And with gems like stimulus_reflex and matestack you can get reactivity easily without having the complexity of full blown SPAs.
The issue for me is more philosophical: JS is still not acknowledged as part of the view, the mindset is still stuck at the separation of concerns = separation of technology era.
I’m not doing SPAs, but I’m not doing Web 1.0 pages either. I have views where tightly coupling JS is the sound choice, because well, the JS is really a part of that view (e.g. a data visualization). But for that Rails makes me juggle between two different apps for the same view (even worse with webpacker).
And Turbolinks is Rails' answer to the madness that is JS frameworks. You get a lot of the functionality of a single page app while still keeping the much-easier-to-code-for serverside rendering
I am very happy I don't have to touch JS frameworks if I don't want to. Because I hate all of them (except Vue and jquery, they're cool)
Rails isn't for trendy hipster JS kids, and I hope it never will be. I don't want those people in this space, they fuck everything up
I don't think any of the current JS frameworks are as comprehensive as Rails but it's clear where the momentum is.
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.
Anyone use it? Thoughts?
So selection bias is very possible.
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.
>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.
Also it's not like you have to load the runtime more than once. So it's not that it's a non-starter for anything performance sensitive--it's a non-starter for anything that can't download a 2MB file up front (I believe their goal is to get it down to half that size) if you want to use the WASM version of Blazor instead of the websocket-based HTML sync layer version.
2. 2MB includes bootstrap CSS and they are working on getting that number down.
3. 2MB is only the Wasm version of Blazor. You don’t have to use that version if it doesn’t fit your use case.
Most people I've talked to using Blazor are in fact using Blazor server not Blazor WASM.
To someone who is switching from the Node ecosystem to Django REST, this seems like an understatement.
I'd be happy to use server-side JS for certain microservices that needed its performance characteristics, or for prototyping in something like Firebase functions. But the mere thought of building a standard fully-featured web app in Node depresses me.
yeah tools like django are amazing packages. node is shockingly hardly any more tamed than it was 5 years ago, still rag tag Express for the most part. with who knows what for the data layer.
but it just doesn't matter. alas! the actual application has been heavily front end biased, & all the real investment g architecture needs to revolve around that front end. it'd be great to have better out of box omakase js experiences. projects like hapi & fastify tried. but there's just not enough effort spent on the back end for that many devs to really care. and plenty of folks are using api based systems or hosted backends, appsync or some hosted graphql, where they can care even less about the backends.
why be comprehensive when you hardly matter?
Even if you have a SPA, which isn't a given (yes, trends. I know. They come and go), the API, data migrations and background workers can easily be 50% of your code and effort.
Like I said in other comments I'd only build an API in Express if I needed its particular performance characteristics.
I've checked other tools in the JS ecosystem that serve as "low-code" API layers, but upon close inspection they always seem to have some limitations on the business logic you can write, and some of them lock you in to products. No thanks.
I'm finding Django REST gives me a sweet middle ground between dev speed backed by great abstraction "magic" and freedom to customize as the app grows.
huge js lover here but I don't think this is true. I think the basic obvious progression is that the client side has shouldered more & more responsibility, that architectures have shifted away from being server side, & few folk have figured out how to make the server relevant. it does a tiny bit of business logic & mostly just crud operations on data. trying to do like we did, keep rendering & a lot of the client state on the server- it wasn't helpful, was a bad way of doing things. these choices of languages became irrelevant as the client side rose in prevalence, capabilities, & yes too, somewhat, performance, but mainly I chalk it up to a long long struggle to find suitable architectures. I don't think this is fair accompli, that it's all decided, but server side needs to radically change it's game if it wants to become relevant again.
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).
From what I can find, in most benchmarks, Node.js is much faster than PHP - orders of magnitude in many cases [1]...
This is what I've always heard anyway, that the amount of R&D that has gone into engines like V8, the C++ under the hood and the I/O model make it so.
[1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Instead PHP is faster for the things websites normally do, like string manipulation.
"Instead PHP is faster for the things websites normally do, like string manipulation."
No, this is not right for a couple of reasons. NodeJS is potentially slower in certain CPU-bound tasks due to the single-threaded nature of JavaScript.
On the other hand, thanks to its event loop and concurrency model, NodeJS is much faster than many languages/runtimes in I/O (reading/writing to stores, fetching data from other servers, etc.) - which is what many web servers do most.
Your original comment also mentioned:
"in-browser execution has seen most of the speedup (as it's where most of the optimisation is focussed on)."
Which is also not true. The V8 engine is hyperoptimized and runs not only Chrome but Node too. It is precisely one of the reasons why server-side JS has gained in popularity over the last decade. The fact that it was initially devised for a browser environment does not mean that optimisation is focused there.
If you're an engineer or web developer I really suggest that you brush up on these things, because with comments like the ones you've been dropping you'd definitely raise eyebrows - and not for the good...
https://www.techempower.com/benchmarks/#section=data-r19&hw=...
It is certainly true that NodeJS has become much faster as your synthetic benchmarks shows, however we have to measure our programs in the context of intended use, as previous poster suggested.
NodeJS wins against PHP when NodeJS does not make an external database call, like in the two test suites JSON serialization and Plaintext, but as soon as you throw in MySQL database PHP wins.
What does this tells us? That V8, the implementation of the JavaScript, is faster than the Zend engine, the implementation of PHP, but the event based NodeJS platform is not faster than the PHP(Apache/Nginx) platform.
NodeJS performance has evolved massively thanks to V8 R&D, as you already mentioned, Zend Engine has also gained a lot performance but of course not comparable to V8 for obvious reasons, the prior is a Google based project, the latter is a volunteer community based project. However the PHP stack also consist of a web server, and they has also evolved massively the past 20 years, Nginx is relatively new on the scene with an event based asynchronous architecture and Apache has evolved with a new PHP module.
I think your personal attacks against muglug, regardless if he was right or wrong, is not appropriate for this forum, especially when you yourself is not entirely up to date.
Edit: typo
I’m doing ok, thanks, and a little humility would go a long way :)
I work at a company where we run PHP as both a shared-memory server and also in a more traditional per-request model, both serving millions of requests a day. Separately I’ve created (and maintain) a 200-thousand-line multi-threaded PHP application with over 4 million downloads. I’m reasonably aware of PHP’s performance characteristics.
I’m less up-to-date on Node, admittedly, but it also intuitively makes sense that the V8 engine will be optimised more for in-browser use than serverside use.
Presuming you wanted to stay in Ruby for the API and wanted to stay in a project similar to Rails (so, preserving ActiveRecord), Roda + ActiveRecord gets you there with already much higher performance.
If you think about it, a JSON API needs very little. Rails has a lot of added complexity for just rendering JSON. Even the sheer amount of files a Rails project has by default is enormous for something that simple.
Your perception of the strong points of rails are very different from mine. The strong points include rapid data and logic modeling, json serialization (jbuilder), robust libraries for user management (devise) and many other things, built-in security, routing logic, easy testing, and meta programming. You still get rapid prototyping in api mode, with a rails generate scaffold quickly capable of creating tables and a json rest api for that resource in a single line with no additional work necessary (assuming you had no business logic, which is generally easier to write in ruby as well).
- Roda (or Sinatra) gives routing. Actually it's very advanced routing that can be composed
- JSON serialization can be achieved more easily with Hash + Array and a subset of basic types (boolean, numeric, string, nil), which are easier to generate than with jbuilder, and it's also more performant. That being said, nothing stops developers from using tilt-jbuilder (gem) to get immediate support from Tilt for jbuilder, which can be used from Sinatra and Roda seamlessly, and can also be called everywhere, not just views
- Roda has built-in security too (I don't know about Sinatra, but I presume it does), there is a section in the README: https://github.com/jeremyevans/roda#security- as well as multiple plugins http://roda.jeremyevans.net/documentation.html#external
- Rails testing is actually _harder_ than normal Ruby testing. On top of my mind, a glaring example of this is the impossibility to instantiate a Controller and do dependency injection on them, which should be normal for any object. This is not a problem if dealing with just Ruby. Rack-test gives the same "request specs" that are present in Rails (actually it's built on top of that). As usual, the option of choosing different testing frameworks is available, given that it's normal Ruby. There isn't a need for special testing framework integration, so it's possible to use the beautiful Test Bench: http://test-bench.software/
- Devise is actually a bad choice for Rails API. It's poorly documented when used in API fashion (authentication through token), providing a whole set of utilities for sign up that are unneeded for API. However these endpoints do expand the attack surface, reducing security. The performance is also reduced, when authentication can be achieved with Redis instead of an SQL database as backend. The amount code needed for secure and well defined authentication can be written in ~5 hours of production quality code, with extensive testing (I did this quite recently). Either way, `rodauth` is available for every need
- Rapid data and logic modeling, presuming I understand what it's referring to in this context, it's given by ActiveRecord, that gem can be used with anything, there is no necessity to use Rails. This brings data migrations. For logic modeling, that is a Ruby feature, not a Rails one: Rails doesn't provide any utility from the logic perspective. In addition, putting logic into ActiveRecord models is very dangerous and known to be a problem by the community
- Rails doesn't provide metaprogramming, Ruby does. That is available with any Ruby application
- Rails does provide the scaffold command, but if the amount of tables that needs to be written is so large that this command is actually providing a benefit over duplicating a file (the activerecord model. ActiveRecord already provides the command for generating migrations wherever it's used), then the cost for writing a Rake task that generates a migration and a new file with an empty ActiveRecord model is negligible (1 hour)
With Roda I see other advantages: - Highly performant webserver (13 times faster than Rails API, 10 times smaller memory footprint: https://roda.jeremyevans.net/)
- Incredibly faster application load speed. Restarting the server is not a problem, running the test suite is not a problem either
- No autoloader, while preserving the ability to reload code. Now Ruby `load` behaves like the normal Ruby load (not monkey patched). This prevents a gigantic amount of problems reached as soon as the app starts to grow, related to how Rails loads constants: https://www.honeybadger.io/blog/avoid-these-traps-when-nesti...
- Using traditional tools for handling javascript, CSS and public assets, which Frontend developers are familiar with (webpack, parcel)
- Very small project, with ~4-5 files the whole setup is ready
- A tremendously smaller API surface (API as in "application programming interface", not HTTP), this greatly helps reducing bug surface and cognitive overload
Now if the application's need is form-over-data (so, not a JSON API), then sure, use Rails. But in that case you must be using ActiveAdmin, to get real advantages. In that space, there is a large amount of competitors in other languages or no-coding tools that Rails has to face. On top of my mind: Forestadmin, Hasura, PostgREST, Django with Django Admin.
I don't think they need to go all the way to something like react. But a souped up Turbolinks where you can also easily do partial rerendering of pages would be enormously helpful.
The barrier for entry into doing anything is still Rails + Bootstrap/Tailwind + webpack/yarn/npm. Which is a lot more than just whipping some stuff up in rails.
but ultimately, expectations moved on. rails has continued finding it's way, trying to find a rails way to do things, but without that original simplicity, it's not nearly as compelling a sell.
no one's done a particularly good job keeping a more server-side biased model. thicker clients keep winning & winning. I don't think it has to be this way, but it's going to take some soul searching & big up front bold vision & architecture to muster to the challenge & create a more balanced client - server relationship. not a ton of obvious winners hereabouts! but I believe!
They don’t know their tooling, systems, how web apps works, make huge mistakes on each level. Just putting the one solutions they know in everything. Do they think about what they doing and if this approach is feasible? No, not at all. It’s like with Wordpress, everyone is using it because of popularity, but WP is a nightmare to work with, and most of the time a huge overkill for what’s intended. I will not even mention Gatsby and super simple websites made in React because of it...
> 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.
And this, this is just outrageous. Do you have anything to back this claim up? I’m not rails/ruby developer, but it always irked me when someone’s saying such thing about any language.
Don’t get me wrong, JS is awesome, React/VUE on top of it too, but the point is, to know when and how to use them.
They don’t know their tooling, systems, how web apps works, make huge mistakes on each level. Just putting the one solutions they know in everything.
Or—bear with me here—it’s possible that everyone other than you actually isn’t an idiot and there are issues that you are neatly stepping over with this patronising nonsense.
I was very excited about what voltrb can become. Quick intro https://www.youtube.com/watch?v=KbFtIt7-ge8
Seems like isomorphic web development has warts no matter what language you choose.
I'd say that Ruby still has a place building APIs for new projects, but having done both advanced REST APIs and GraphQL with Ruby, it's starting to make its way even out of my top five for getting the job done.
The point has already been made, but if you're good at Ruby and you don't need to build something responsive, both plain Ruby and Rails have fine affordances for server side rendered views. There's still a lot of need for quick-and-dirty backoffice applications that don't need to delight the user. Of course, you get a lot more for free with Django's admin.
Also, there's a lot of "I think the DSL ends up a hinderance" in this threat from people that (perhaps) haven't tried it and judge from the looks. Maybe that's just the tough HN crowd, but every single person we've actually had using it was pretty happy to with it once they were fully onboarded :)
As unfair as this seems to you, I think it's also unfair to dismiss them as not having tried it, since I've personally tried many (I can remember encountering them in 2008 on my first ruby project and many times in the interim) and never had a good experience. It feels like a novelty that doesn't really add anything except a disconnect between what I have to write and what I mean, when "what I mean" is actually really simple and not hard to write. Your mileage may vary, but the "DSL hate" is actually rooted in experience for many people.
But you're right, I definitely haven't tried it, and I don't intend to, so I could be missing out. I just really don't think so. More power to everyone who likes this sort of thing. :)
However, I was unable to find documentation about how it works underneath. I also would like to see some info about how to integrate with other javascript libraries.
As someone who's been involved with the project from the very beginning, this is immensly valuable to hear. Could you elaborate on how we could've gotten you to tell us? :)
(I get that GH issues is probably not the way to go, but wondering what other tool/channel would work? Also I think there'll be no silver bullet since it requires some energy & care to actually jump to action over a random project you find interesting and that will never be the case all the time, but then again this is basically what we need to work on to get people like you to try/use it!)
The main downside is that rendering wasn't very efficient as it has to execute thousands of ruby functions per page. One per DOM node. This makes it harder to cache fragments as both the code and HTML is now inter-mingled.
The claim is you can write ruby everywhere, but the problem is you still have understand all of the html tags you're using.
So you haven't reduced the knowledge requirement from "HTML + Ruby" to just Ruby, you've increased it to "HTML + Ruby + This DSL"
Doubly so, in this case, since it seems to also be aiming to replace a subset of JS based updates as well, with the same problems.
---
Now - That doesn't mean the framework should be dismissed outright - It might very well be that adding this complexity brings a benefit that's entirely worth it.
Typescript is an example of that tradeoff, I'd say. It adds complexity, but the value it brings with that complexity pays for itself.
So I have no idea if this framework really delivers enough value to be worth it. My gut says no, but I haven't used it, and I'm not a huge ruby fan in the first place, so I'm the first to admit I'm a biased judge.
If the tool is so great, please make it as "for beginners" as possible. We need tutorial first, not concepts first.
For anyone looking at this right now, here's the 10-step-guide: https://docs.matestack.io/docs/reactive_apps/1000-tutorial#t...
Regarding choice of FE framework: Back when Jonas started the prototyping (late 2017), Vue.js seemed to fit our needs perfectly due to its simple-and-leightweight-component architecture, I guess. It was also on a sweet spot between Angular and Ember (for which had you buy in on full SPA mode), React (which wasn't as lightweight back then as it has become by now, IIRC) and having to write everything in Vanilla JS. There were a bunch of other projects (like Mithril.js, Elm and Swelte, amongst others) where I'm not sure if they already were around / popular enough for us to know them, and (perhaps understandably) an existing, healthy ecosystem and some popularity & traction for other people to be able to use & extend what would eventually become Matestack were other contributing factors, and I think Vue.js continues to shine here.
Since we're getting a lot of requests on being able to use React (and now Stimulus) with the same DSL this is definitely on the roadmap, not sure on how it's going to get prioritized though. Perhaps best if you reach out to Jonas (https://twitter.com/JonasJabari), he's a lovely guy!
Basic procedural Ruby, with some thoughtful functional style collection operations, is very elegant and fun to use (because you can get a job done in few lines of code which aren't terribly hard to understand later).
But as soon as you start dipping into metaprogramming, you've lost your ability to see what's happening. You have to understand the system to... understand it. Defining methods on the fly, calling methods via send() and a string/symbol, and using method_missing as a dynamic dispatcher are some of the most abused and least easy to understand later without current documentation of their use in the system.
In general, there's too much magic in a lot of the Ruby ecosystem, and some of us are really pushing back against that.