articles/rails-is-better-low-code-than-low-code

[giscus[bot]]

articles/rails-is-better-low-code-than-low-code

“We need a very simple CRUD app for managing the reservations.” They1 said. “Don’t spend too much time on it.” They added. They are the stakeholders or the boss or maybe yourself. Whoever is asking for this application. ↩

https://radanskoric.com/articles/rails-is-better-low-code-than-low-code

[danielabar]

My experience with low-code tools has been similar. They're good at getting something out initially, but then you quickly realize there's no way to do automated testing, can't have multiple environments (well you can make a copy but no way to automatically deploy changes), can't run it locally for development. So you basically only have a single production environment, and making changes is like doing maintenance on a plane while it's in the air.

[radanskoric]

100% agree.

[cmittal790]

Radan, very nice writeup. The story is usually what happens almost all the time.

[radanskoric]

Thank you! Unfortunately, yes, that is a very common case.

[panSarin]

Oh man, that is nice summary of what i have in my mind whenever I setup some no-code prototype ;]

[radanskoric]

Ha, thank you. :D

[OzzyTheGiant]

Ruby and/or Rails are not my cup of tea but this is so on point. I would think that if there are going to be low-code tools, there supposed to be tools for the developer, with the option to expand as requirements increase. Unfortunately, business owners and CEOs are out there trying to take shortcuts rather than getting a job done right. That's not to say these tools, and site builders for that matter, don't fit a need; they certainly do, as maybe a small business is just starting out on a low budget and needs something small to get up and running, but good business owners should be aware of the limitations of that and understand when it's time to expand to a full scale application

[radanskoric]

You're totally right. Bottom line: it has to be an informed decision. And this is is often hard to do since usually proprietary platforms have higher marketing budgets than open source projects.

[itsterry]

Hey Radan. This mirrors the line I've been using for years, in that using a "low-code" system (usually WordPress) gets you up and running quickly, but as soon as you want something bespoke, the cost of "fighting the system" is greater than the cost of "doing it from scratch and knowing exactly what you're doing"

Great write-up, sir. Thank you!

[radanskoric]

Thank you! :)

[optevo]

It would help if you gave the name of the "Low Code" platform. Imagine if I wrote "Power Apps" (just as an example) is better than tradtiional code and didn't name the language?

There is a huge difference between low code platforms ; much larger than between languages - mainly because there is a lot of variation on how much they extend into other parts of the SDLC and their ability to handle various (or general) use cases.

[panSarin]

Not sure about that. I mean the whole point of the article is more about the idea of low-code, and its pros and cons - not abut the one tool in particular.
If I am right ;]

[radanskoric]

I didn't want to name a specific platform on purpose since that would then probably become the focus of discussion. And that wasn't my point. I've actually had multiple different platforms in mind when writing. I've touched several of them over the years. At times I've even implement or worked on subsystems that you could characterise as "low code". I even have memories of happily building a small MSAccess 97 application as a teenager after I already knew how to program (this now probably dates me :) ). Low code tools can be a wonderful solution to specific problems.

The angle from which I approached this writing was actually less about how bad low code tools are and more about how close Rails has come to it in terms of early development speed while still having virtually no upper bound for most cases.

I could have probably made this clearer in the post. It's intended to be more about the good things that Rails brings to the table. Focus on simplicity, readability, convention over configuration and sensible defaults that can be overriden. I think Rails is currently unmatched among general web frameworks for speed of initial development and yet it doesn't restrict you if your application goes huge. This is actually the main takeaway I wanted to convey in the article. Being cautious about low code platforms is the secondary intended takeaway.

If I was a better writer that would have been clearer. :)