I feel like this article doesn’t explain why Rails is better “low code” than low code. What makes Rails better than any other programming language? It mentions scaffolds and turbo and authgen; I would have liked more details on how these work and speed up the process.
I’m not a Rails developer, so feel free to take this with a grain of salt, but I can try and elaborate a bit on those questions.
Scaffolds will generate the basic code necessary for a new component. Rails follows the Model/View/Controller architecture, so the model defines the shape of the data, views handle rendering that data, and controllers handle interacting with and updating that data. More info
Turbo is part of a broader framework that allows for partial page updates via HTML rather than using a full client-side framework + JS, breaks parts of individual pages into smaller components, among other things. I haven’t used it myself, so I can’t really properly praise or criticize it.
Authgen is essentially a scaffolding tool for authentication specifically. This article provides some more detail on what exactly it does behind the scenes, but it gives you a full authentication system with user management, password resets, and sessions.
In general, I’d say Rails speeds up the process by providing robust tooling to automatically generate the necessary code for things to just work.
I’d also say this article is probably also more focused on a criticism of how restrictive low-code tools are when you start to run up against the walls of what they allow you to do, and that by starting with a framework that handles a lot of the drudgery for you, it can be a better “low-code” tool than a low-code tool. Django, Rails, Laravel, etc, it doesn’t matter a whole lot, though Rails in general probably has some of the most robust tools for automatically generating dang near anything you’d need in a basic app, while still allowing you to have complete control with code where needed.
I feel like any MVC framework with sensible defaults, scaffolding, well-known libraries, and code-first database models has the same benefits the author is talking about, Rails is just the one he uses. I feel like everything in the article also applies to Django (Python) or ASP.NET MVC + Entity Framework (C#).
this discounts just how productive rails is for a solo developer. it’s called the solo founder framework for a very good reason. it’s insanely productive.
Last time I was doing real web work for money was about a decade ago and I haven’t kept up with that world much. Most of my projects were in Django but I had come across a Ruby library that looked like a very good fit for a client project and decided to take a stab at it with Rails. I explained to my client that I was going to try some different tech for the project, was going to time box the experiment to 40h and if at the end of the week I didn’t like how it was shaping up I would eat the 40h and do it in Django instead. Overall estimate for the project was around 120-150h.
By the end of the week I had a fully functional prototype with just a couple of loose ends to clean up. Overall it came out to about 60h. I was shocked at how productive it was.
I feel like this is comparing apples to oranges, at least from the point of view of the sales pitch of low code tools. The whole reason they exist is so they (in the lingo of the article) can get an intern or junior developer to do the work quick, easy, and cheap. An experienced developer who knows how to use Rails may be quick, but they’re not cheap.
Whether or not any low code tool delivers on its sales pitch in the long run is a different discussion. Like Matheus points out, requirements change, and change can be painful. Having that experienced developer around may be a better use of time and money than throwing junior bodies at low code.
It sounds like the low code solution is still nice as a “rewrite” of your “low code prototype with 2d invested” is still fine, because you validated your idea in just 2d of work and now you have better requirements.
Saying this as more of an opponent of low code tools, but this seems fine? I mean, if your team/company has N Rails apps already, one more won’t hurt from the start, if you keep updating it just like the others. But if you’re usually doing something else and this is the one Rails app.. well, good luck.
But yeah, I’d decide based on the chance of that scope creep happening. You can still be wrong but sometimes low code is ok. My usual use case is more like: if the customer has to configure stuff and you don’t want to let them insert code that will be eval()d.
It all comes down to escape hatches. Low-code tools have to have their escape hatches welded on, and hope they don’t interfere with anything else in how the tool expects things to work, whereas Rails is just an escape hatch ready to be used, because it’s part of the foundation.
I feel like this article doesn’t explain why Rails is better “low code” than low code. What makes Rails better than any other programming language? It mentions scaffolds and turbo and authgen; I would have liked more details on how these work and speed up the process.
I’m not a Rails developer, so feel free to take this with a grain of salt, but I can try and elaborate a bit on those questions.
In general, I’d say Rails speeds up the process by providing robust tooling to automatically generate the necessary code for things to just work.
I’d also say this article is probably also more focused on a criticism of how restrictive low-code tools are when you start to run up against the walls of what they allow you to do, and that by starting with a framework that handles a lot of the drudgery for you, it can be a better “low-code” tool than a low-code tool. Django, Rails, Laravel, etc, it doesn’t matter a whole lot, though Rails in general probably has some of the most robust tools for automatically generating dang near anything you’d need in a basic app, while still allowing you to have complete control with code where needed.
I feel like any MVC framework with sensible defaults, scaffolding, well-known libraries, and code-first database models has the same benefits the author is talking about, Rails is just the one he uses. I feel like everything in the article also applies to Django (Python) or ASP.NET MVC + Entity Framework (C#).
this discounts just how productive rails is for a solo developer. it’s called the solo founder framework for a very good reason. it’s insanely productive.
Last time I was doing real web work for money was about a decade ago and I haven’t kept up with that world much. Most of my projects were in Django but I had come across a Ruby library that looked like a very good fit for a client project and decided to take a stab at it with Rails. I explained to my client that I was going to try some different tech for the project, was going to time box the experiment to 40h and if at the end of the week I didn’t like how it was shaping up I would eat the 40h and do it in Django instead. Overall estimate for the project was around 120-150h.
By the end of the week I had a fully functional prototype with just a couple of loose ends to clean up. Overall it came out to about 60h. I was shocked at how productive it was.
I feel like this is comparing apples to oranges, at least from the point of view of the sales pitch of low code tools. The whole reason they exist is so they (in the lingo of the article) can get an intern or junior developer to do the work quick, easy, and cheap. An experienced developer who knows how to use Rails may be quick, but they’re not cheap.
Whether or not any low code tool delivers on its sales pitch in the long run is a different discussion. Like Matheus points out, requirements change, and change can be painful. Having that experienced developer around may be a better use of time and money than throwing junior bodies at low code.
It sounds like the low code solution is still nice as a “rewrite” of your “low code prototype with 2d invested” is still fine, because you validated your idea in just 2d of work and now you have better requirements.
Saying this as more of an opponent of low code tools, but this seems fine? I mean, if your team/company has N Rails apps already, one more won’t hurt from the start, if you keep updating it just like the others. But if you’re usually doing something else and this is the one Rails app.. well, good luck.
But yeah, I’d decide based on the chance of that scope creep happening. You can still be wrong but sometimes low code is ok. My usual use case is more like: if the customer has to configure stuff and you don’t want to let them insert code that will be eval()d.
It all comes down to escape hatches. Low-code tools have to have their escape hatches welded on, and hope they don’t interfere with anything else in how the tool expects things to work, whereas Rails is just an escape hatch ready to be used, because it’s part of the foundation.
The low code aspect of rails is why I can’t stand using it. Everything is configuration and takes all the fun out of building a service
I’m not sure you’re joking or not.