Matestack – Reactive UIs in pure Ruby(matestack.io)
matestack.io
Matestack – Reactive UIs in pure Ruby
https://matestack.io
119 comments
Core contributor here: I think you're right when talking about DSLs ONLY introdrucing a high level of abstraction. But Matestack's first layer only maps HTML tag rendering to Ruby method calls, which actually doesn't add any abstraction and thus gives you the same level of flexibility when implementing things. The advantage of doing things in pure Ruby (even without any abstraction layer) is simply that it's now possible to utilize Ruby's languange features to create clean and readable UI code within a proper Ruby class - which means you can use class inheritance and modules for UI code structuring. That could be a big thing if you're into writing Ruby code ;)
On top of that Matestack offers components (used via a DSL) with a higher level of abstraction in order to hide implementation complexity of - for example - rerendering a specific part of the UI. The idea behind these components is to drastically reduce the amount of code and effort you have to invest in order to implement typical UI requirements. And yes it's true: When using these components you loose some flexibility on how exactly things will work but you gain development speed and productivity. If the components don't perform as desired, you simply create your own component in pure Ruby or pure Vue.js and do whatever you want - e.g. consuming a JSON API and perform client side rendering. Without this customization path I would totally agree with what you said here: "the problem of DSLs is that they can quickly turn into giant pain in the ass once you need to do something they aren't prepared for" Matestack tries to enable you to use components with high level of abstraction next to components with low level of abstraction next to your very own components... and they are all meant to live happily side by side :D
Well i don't find plain HTML unreadable or messy. Same with JS. And i never experienced any productivity issues writing it.
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
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
Love the idea of it, even if it's not for me. Ruby needs new blood infused into it.
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."
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."
Hmmm,
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 :-)
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 :-)
I certainly agree the classic full page reload approach is still completely relevant. It's more that most websites nowadays will employ a hybrid approach. They need a bit of both. Anything that isn't a static website is going to be using react or some other front end frameworks, and a lot of react involves asynchronous requests with REST APIs.
But most rails resources focus exclusively on the one approach, with very little of the other.
But most rails resources focus exclusively on the one approach, with very little of the other.
I don't know the resources anymore, but Rails really embraced the REST (in it's opinionated way) approach with rails 3+. So any more or less up-to-date doc should indoctrinate the REST-style, especially for CRUD. You might need to make the transfer from the data is not coming from a form anymore, but some JS that sends JSON, but that is something a developer should be able to do...
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 :-)
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 :-)
> Ruby needs new blood infused into it.
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.
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.
Can't tell what your SPA experience has been, but in my experience React with a standard webpack configuration such as what you get with create-react-app provides an extremely detailed trace. Never felt like I've lost more time than I should there.
Probably nowadays React with webpack provides a stable experience.
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.
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.
you might be interested in https://inertiajs.com/ if you're using rails (or laravel) - doesn't solve SSR if needed, but in my limited use does provide a nice middle ground for not needing to go full SPA
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
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
Wow thank you. InertiaJS might be exactly what I was looking for to integrate some small Vue into a Rails app.
Also I keep looking for an opportunity where I would use Lucky Framework with Crystal just to give it a spin.
Also I keep looking for an opportunity where I would use Lucky Framework with Crystal just to give it a spin.
What's wrong with old and boring? I don't think all the "newness" coming out of Node/Deno is actually improving anyone's productivity.
Nothing is wrong with old and boring. I like it. This is why I am using Ruby on Rails for most of my projects and it is the default framework to prototype any new idea I have.
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.
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.
I think it's quite the contrary. Rails integrated Webpack a long time ago in it's basic installation so if you do `rails new my_cool_app` you have Webpack ready(and preconfigured with React/Vue/Elm etc.) right out of the box. Also it moved away from Coffeescript and jQuery.
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.
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.
I used Rails for a lot of projects starting ~10 years ago, but slowly gravitated towards a stack based on Sinatra (for a lean REST API), Middleman (static site generator), and webpack/react/etc - for mostly the reasons you describe.
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.
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.
This is probably a very dumb question but I'm new to all this and trying to figure out how to mix/match these frameworks like you're describing. I have primarily a static site (using Jekyll, but Middleman would apply) but now need to add some server side stuff (e.g. with Sinatra). I see how I could dump my generated site into the Sinatra /public directory, but then I'm serving everything through the sinatra server when I really only want to hit that when I need the dynamic content/calls. How would I keep them separated while still having a single environment? Have tried googling to no avail, don't know if I'm asking the right questions. Any pointers would be super helpful! Thanks
Not a dumb question! I'm sure there are a lot of different approaches that could work.
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.
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.
If you want a sinatra equivalent for elixir, you can use plug.
You can try out Turbolinks, the Rails equivalent for LiveView.
This is not exactly a great characterization of turbolinks. TL definitely is great and useful for blurring the lines between server rendered and SPA, but it isn't anything like liveview. For that you're looking for something more like Motion (https://github.com/Unabridged/motion). Disclaimer, maintainer, but the comparison is much closer.
And StimulusReflex, although Motion is slightly closer to LiveView, but both are in the same Category as LiveView. Turbolink is definitely not though.
No, liveview does everything on the server, including holding the frontend state, which is why it's so powerful.
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.
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.
Yes this is where I see Ruby 3 being irrelevant, unfortunately. Ruby and Python are single-threaded, dynamically typed languages designed for the 1990s. You can try to retrofit anything you like and pretend you have real concurrency or static typing but it will never be the real thing and you'll just end-up with thousands of legacy libraries.
I think Erlang is older than Ruby? (Not sure, but it's pretty old!)
As for single threaded, they are not, even with green threads, IO is usually the problem (otherwise you chose the wrong language).
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.
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.
Christ. It did keep up. Every new rails release just makes it better and better. Rails isn’t popular anymore because people followed the swan song of language isomorphism overlooking JavaScript’s deficiencies. NodeJS improved by... adding Rails features.
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.
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.
I don't really see too many companies or projects using node on the back end. It's pretty hard to buy that node replaced rails. I see a lot more Java than anything else.
A lot of companies I'm speaking to (mostly Berlin/Germany based startups) have drank the "we have to use JS on the frontend anyways, and by going fullstack JS we can reduce our payroll since we can focus on only hiring JS devs and they magically work on ReactNative, the React web app and the Node.JS backend at the sime time" koolaid. Works super well for some, less so for others...
Edit: Explicitly added Node.JS since that's what they rave about for making it possible.
Edit: Explicitly added Node.JS since that's what they rave about for making it possible.
That's because Java is one of the top 3 adopted languages and is general purpose. A more relevant comparison would be between Node.js and Django, Rails or Laravel and as far as job stats go, eg. https://indeed.com, Node.js is everywhere.
i think it really depends on the industry - mine for example, most of the bigger players are running express apps on the FE (not 100% sure on backend, seems a mix of go/node and other things) - but why bother to run express/node on the frontend if you're not also going to leverage it on the backend.
The web becomes very narrow not only there are mostly Chromium based browsers, but also Node based backend technology for rendering HTML (in javascript). Very coupling tech.
I’m actually quite bullish about Rails for the fitst time in a while due to StimulusRelex[1].
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.
1. https://docs.stimulusreflex.com/
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.
1. https://docs.stimulusreflex.com/
> streamed over a websocket
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?
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?
>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.
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.
> AnyCable helps a lot but this is another pieces of complexity added to the system.
What is the added complexity? I honestly never used all this stuff.
What is the added complexity? I honestly never used all this stuff.
Neither Elixir Liveview nor StimulusReflex are really viable longterm, especially for mobile web.
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.
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.
If the Network is unreliable how is that any different to failing to updating / reloading a page?
Or you are referring to Web Apps that work offline?
Or you are referring to Web Apps that work offline?
Yes I'm referring to mobile web apps that either work offline, or don't severely impact their UX in the presence of a slow or unreliable network.
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.
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.
Cool that people are doing a live view type thing in Rails, but it introduces a lot more complexity without the BEAM
Rails has very much embraced webpack and different ways to build SPA on it, with providing an API only mode and easy install webpacker install commands.
Maybe for an oppinionated framework it now offers too many ways to do the frontend.
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.
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.
MVC full page reload are fine with turbolinks and can deliver a better user experience (at least that’s what I get from my clients).
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).
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).
We come from dramatically different perspectives because building page-reloading MVC still feels fine, as fine as it ever did.
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
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 think it's more that the massive engineering effort that's gone into improving JS has leapfrogged it over languages like Python, Ruby & PHP in terms of performance and tooling. And since you're stuck with JS on the frontend there are some significant advantages to using it on the backend as well.
I don't think any of the current JS frameworks are as comprehensive as Rails but it's clear where the momentum is.
I don't think any of the current JS frameworks are as comprehensive as Rails but it's clear where the momentum is.
Actually I'm not seeing many projects with a JavaScript backend. In my experience the number is one, and it was 2015. I mean, backends of projects I worked on or somebody offered to hire me to work on. It could be selection bias and yet they're asking me about Java, which I basically abandoned about 15 years ago, PHP, which I know since the beginning of it but only kind of toyed with, even C# which I can read as a foreign language close to one I know but never used. I wonder if anybody asked me about Rust or Go, probably not. What they ask me about and I accept to work on are Ruby, Elixir and Python, in order of my preference. Python is a distant third (as preference.)
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.
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.
That hardly sounds representative of the Node.js adoption curve. Could you elaborate on your typical client profile? Are you a solo freelancer, maybe attracting clients with legacy codebases? Location?
Freelancer, Milano, Italy. They reach to me either for taking over existing projects or to start new ones. Of course it can be selection bias but it extends to the other developers I'm in contact with.
Just searched Milan on https://it.indeed.com - Node.js 123, Django 26, Rails 11, ASP.Net 133, Laravel 67. As Node is a web technology comparing it with general purpose languages such as Java and C# is apples to oranges.
What's your typical way of sourcing clients?
Almost always word of mouth. They start looking for somebody experienced in what they want to do (development and/or software architecture) and some eventually find me.
So selection bias is very possible.
So selection bias is very possible.
How do they find you?
He said word of mouth, obviously through a business network. It's a good thing to keep in touch with people and maintain business links for both parties. I do it all the time.
Same. I never understand these things I read about JavaScript momentum on the back end. I have yet to encounter a company using Express on the back end.
I've been curious about this lately: https://reimagined.github.io/resolve/.
Anyone use it? Thoughts?
Anyone use it? Thoughts?
Survey results of back-end JS: https://2019.stateofjs.com/back-end/ Only those who know about the annual State of JS survey.
I read an article from Thoughtworks where they said they use NestJS in some production apps that benefitted from Node's performance characteristics. In the same article however they were critical of the trend of shoe-horning server-side JS into projects where more classical languages/frameworks would be a better fit.
> I think it's more that the massive engineering effort that's gone into improving JS has leapfrogged it over languages like Python, Ruby & PHP in terms of performance and tooling
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).
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).
What benchmarks are you basing this 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/...
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/...
PHP isn't faster for arbitrary mathematical workloads (though the JIT in PHP 8 will help with those).
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.
I see this is the hill you want to die on...
"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...
"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...
Benchmarks that try to replicate reality actually shows the opposite, PHP web stack beats NodeJS web stack.
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
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
> If you're an engineer or web developer I really suggest that you brush up on these things
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.
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.
PHP is fast but not as fast as Node. However, once you introduce something like Laravel into the mix performance tanks leaving it slower than Django and Rails according to Techempower benchmarks.
Pretty sure nodejs is almost always faster in a multi connection setup.
This is a little bit premature of me to posit however I have a good feeling about tech like Blazor.
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.
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.
Blazor currently has to haul its runtime over the wire before it can do anything so a non-starter for anything performance-sensitive.
Did you miss this part:
>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.
>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.
Compared to React + React DOM at 109k unzipped Blazor's runtime at 2MB is a significant hike in download size so unsuitable for older devices and constrained bandwidth networks.
1. Being too large for constrained bandwidth networks hardly makes it a non starter for anything performance sensitive unless you have a very narrow definition of performance.
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.
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.
I don't have to use it but Wasm Blazor is the version everyone is shouting about. Well, everybody at the Microsoft hype machine that is.
Go to the Blazor homepage. Right there on the front page--the 2nd bullet point is "Run on WebAssembly or the server".
Most people I've talked to using Blazor are in fact using Blazor server not Blazor WASM.
Most people I've talked to using Blazor are in fact using Blazor server not Blazor WASM.
In my experience I’ve seen JS on the backend really only used for lambda functions, to run socketio for some chat-like feature or for pre-rendering React components.
I work for a Fortune 50 and my team’s product is JS frontend and backend. JS all the way down :)
Might just be my area then (Berlin) I hardly see job ads for JS on the backend.
Wow we must be in separate Berlins because I see tons of JS backends. My impression is Javascript & Python are competing for most popular backend.
Seconded that in another comment in this thread. Lots of "fullstack JS saves you money since you can hire the same devs for web, backend & mobile" in Berlin, with varying success
Quite possible that I live in my bubble! I see a lot of React & React Native but hadn't seen so much on the backend.
Node is massive in London so, yes, your experience has an element of local bias.
> I don't think any of the current JS frameworks are as comprehensive as Rails
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.
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.
the whole trend though is that the server side is mostly a very tiny crud layer & a little bit of business operations.
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?
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?
> mostly a very tiny crud layer & a little bit of business operations.
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.
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.
Yea, I have switched to Django with the intent of continuing to develop primarily SPAs.
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.
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.
> i think it's more that the massive engineering effort that's gone into improving JS has leapfrogged it over languages like Python, Ruby & PHP in terms of performance and tooling.
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.
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.
The concept of performance is interesting, to me it should be more applied to the user's experience of performance. And personally, when I come across a slow, janky SPA where a server-rendered site would have made a lot more sense, I feel immediately annoyed by the lower performance.
Well, realistically, rails is a bad choice for a json rest api. As for everything else you said, it is doing that as far as i'm aware. Webpacker it's a thing.
Is it? It has an api mode and I’ve used it extensively for that at multiple workplaces and projects.
Yes but at that point you are getting all the disadvantages of Rails, without the strong points (fast prototyping and everything related to rendering HTML pages, file uploading etc.).
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.
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.
> Yes but at that point you are getting all the disadvantages of Rails, without the strong points (fast prototyping and everything related to rendering HTML pages, file uploading etc.).
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).
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).
Yes, I was highlighting my view.
To respond to the advantages mentioned:
- 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.
- 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'll check it out, I'm a fan of Jeremy Evans sequel gem.
Cool, glad this was helpful. If nothing, it gives a different perspective on the Ruby world!
The problem I have with Rails is that it's not a complete solution. You can use the generators to scaffold a bunch of stuff but those pages have no CSS and lack basic javascript like dynamically adding a row to a form.
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.
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.
alas for rails, a very very large percent of it's simplicity & adoptability were derived from it being so so so so server side based. useful for making an easy to use opinionated framework.
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!
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!
I still prefer the good old “build stuff in rails” (which change a lot, something you don’t really know) over build everything in JS. Which is mostly popularized by new kind of programmers breed who learned everything purely from YouTube.
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. 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.
Which is mostly popularized by new kind of programmers breed who learned everything purely from YouTube.
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.
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.
Oh, wow a personal attack! I didn’t want to offend anyone, but you somehow feel attacked. Either way, have a good day. :)
I believe this has been around for a while, and it reminds me:
- https://opalrb.com/
- http://voltframework.com/
I was very excited about what voltrb can become. Quick intro https://www.youtube.com/watch?v=KbFtIt7-ge8
- https://opalrb.com/
- http://voltframework.com/
I was very excited about what voltrb can become. Quick intro https://www.youtube.com/watch?v=KbFtIt7-ge8
Came here for the DSL hate, and was not disappointed.
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.
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.
Even if this was a good idea, the push on commercialisation puts me off. And as other commenters have said, the DSL feels like it would end up being a hinderance. Stimulus (and perhaps StimulusReflex) feel like the safer bets for the dynamic rails future.
As someone who's been involved with the project from day one, I'm genuinely interested in what other suggestion you have for making a living while wrinting OS software. There's a lot of discussions around sustainable open source, and I wonder what's so wrong about asking people that find the project supportable enough to become a GH sponsor (I myself am one, since leaving the company around Matestack as a co-founder due to mental health issues), asking companies that profit from it for a tiny compensation and offering premium add-ons & consulting (like, e.g., the people behind Sidekick, Trailblazer or Laravel do). Tough ask when tons of OSS is free & high quality, but then again not everybody has the luxury of either already being famous and/or being employed at $bigcorp to write OSS for a living (and we as a community perhaps should embrace different paths?!).
Looking forward to a constructive discussion if you find the time :)
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 :)
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 :)
> there's a lot of "I think the DSL ends up a hinderance" in this [thread] from people that (perhaps) haven't tried it and judge from the looks
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. :)
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. :)
Looked into it before. Love the concept, and looks very neat to use.
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.
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.
Thank you for the feedback!
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!)
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 first to implement a pure-ruby HTML renderer was Markaby[1]. This was without the reactive bits. I remember it being quite enjoyable to use. The barrier between ruby logic and HTML rendering is much lowered.
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.
[1]: https://rubygems.org/gems/markaby
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.
[1]: https://rubygems.org/gems/markaby
Seems like a similar concept to Livewire: https://laravel-livewire.com/
This is cool, but I feel like this design has come up a few times before and hasn’t really caught on (Volt, Hyperstack). Why is that?
At least in my opinion, it's because this style of coding doesn't reduce the things you need to know at all.
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.
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.
> There's a good group who've been working on making essentially a Ruby to JavaScript transpiler and I've heard a lot of the pitches for it and they're like, "But it's Ruby and like isn't that better?" And I'm like, "No, like JavaScript is great for what JavaScript does." I don't have this idea of just, like, there's the one approach to everything. The same thing, and that goes all the way back to thinking like SQL is not a bad language. Active Record has never taken the approach that like SQL is this sort of demon that needs to be exorcized. We've reduced the amount of SQL you need to write, on a regular basis, I don't write a lot of SQL, we used to write more because Active Record didn't do as much, but it's not from this perspective of like we have to eradicate it. We do the conceptual compression but, when I look at something like, Ruby to JavaScript transpiling, there's limited amounts of conceptual compression, 'cause you still have to understand the model of what it outputs into and like, it's just, it's not for me - David Heinemeier hansson
It feels really contrived. To be fair, I have not tried it, but it just looks like an incremental improvement at a first glance. I am going to stick with JavaScript and continue to use Ruby as backend code.
Too much introduction, lack of real beginner's tutorial.
If the tool is so great, please make it as "for beginners" as possible. We need tutorial first, not concepts first.
If the tool is so great, please make it as "for beginners" as possible. We need tutorial first, not concepts first.
Fair point I guess, we seem to have made the tutorial less discoverable over time...thanks for the feedback, we'll improve this!
For anyone looking at this right now, here's the 10-step-guide: https://docs.matestack.io/docs/reactive_apps/1000-tutorial#t...
For anyone looking at this right now, here's the 10-step-guide: https://docs.matestack.io/docs/reactive_apps/1000-tutorial#t...
Is the Ruby code compiled into JS?
No, there are three layers on how to use matestack. Without reactivity, it just creates pure HTML. If you use reactive functions like :onclick, :toggle, :async, you basically configure/fill VueJS components provided by matestack. On the third layer you can write your own VueJS components in Javascript, but still use the matestack DSL to then use/configure it.
Ah. I see. I wonder if they're not just hiding a lot of complexity like that; I mean once a component becomes decently complex, that there's no way for you to implement it right without learning Vue.
Technically yes, we're abstracting away complexity and as always, this comes with a price and has the potential to fall on your toes down the road ;)
In my eyes the available core components get you quite far already, and then, once you hit a certain threshold, it's "just" Vue.js and a therefore - in our eyes - a managable and approachable additional effort given you have some experience in JS (it's not like we make you buy into a whole new paradigm/programming language/an outdated framework)
Thanks for clarifying! How did you choose FE framework, what were the considerations? If you wanted to have the same DSL but with Stimulus instead of Vue - would that have worked?
You're always welcome to ask, of course!
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!
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!
Is the implementation of this like Elixir's Phoenix LiveView?
The crazy idea that Ruby "DSLs" are neat is one of the worst things to come out of Ruby. This code is Ruby, and yet you're encouraged to think of it as a different language that's "intuitive" and "expressive" when you can't even tell what is executing and when. It's a nightmare for anything except the samples.
I second this. In fact, it's the #1 reason I don't enjoy "Ruby" anymore. Ruby as a language is great if you stick to a small subset of its capabilities (meaning, largely skip the metaprogramming, and definitely skip the make-a-dsl route).
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.
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.
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...