Low code initially works quite well until you hit the limits of the low-code framework. If you just need a throw-away proof of concept, or a personal utility, or the like, low-code solutions can be quite efficient.
However, implementing anything significant that's expected to be extended and improved, particularly when there are users that request changes, improvements and new features, low-code "is like climbing a tree in order to reach the moon". You'll will very quickly run out of tree and further progress becomes almost impossible.
To a lesser extent the same thing also occurs with web development frameworks, but the limits are less constraining and there are often mechanisms that allow you integrate your own code, that implements whatever it is that the framework doesn't provide.
Low code, frameworks, and "build it totally from scratch", can all be a valid solutions, but the right choice often depends on a bunch of specific considerations (technology, user & quality expectations, organizational capabilities & constraints, etc.)
My recommendation is to keep an open mind about alternative technologies and approaches, and to pick solutions that are appropriate for the environment in which they will be developed, extended and operated. And that requires experience, which you normally don't have in the early phase of your career (e.g. good judgement comes from experience, and experience comes from bad judgement)
I’ve spend a few decades in non-tech enterprise including 7 years in the public sector, and I’ve never seen a low-code solution work at all. Even extremely simple automation flows require at least some degree of software engineering. Looping isn’t intuitive at all, he’ll even conditions aren’t.
What has completely changed the field is LLMs. We now have employees of every sort building small Python scripts which actually work. Even installing Python and getting it up and running is something the LLMs help with. Obviously almost all of it is terrible, and none of scale, but for 90% it, it never has to run outside the personal computers of the employees who write it. Now the challenge becomes keeping the knowledge (and scripts) when employees change jobs. Though to be fair, the knowledge bit was always a challenge.
I've worked quite a bit in civil engineering and GIS, and most places I've worked at have made very good use of a 'low-code' tool called FME for automation and ETL tasks. I even reach for it myself for many tasks, even when I am fully capable of doing exactly the same task using for example Python. For the right tasks it is simply the most productive solution.
That being said even with these tools you still need to know how to 'program', at least conceptually, and it's not like just anybody can pick up a tool like this and be productive. The basic concepts of control flow and algorithms still apply and work the same way.
Those scripts work, until they don't and the people who generated them cannot even ask the right questions to an LLM, and people who can actually maintain them get overwhelmed by the side-quests of keeping them in order, because everything that gets some use become a dependency for the business.
The best low code solutions I’ve seen from the end user perspective are ones that create sane looking skeleton code for you and have an eject button for when you hit the boundaries of what the tool is capable of. The eject button is a one off operation that switches the low code solution to a traditional code based solution, and is irreversible. Bootstrapping and prototyping quickly is a great use case for low code tools in the phase where long term code maintenance is not really important.
Such a model is not easily monetized which is why you don’t often see this model in the wild. Draftbit is one company I’ve seen that uses this model: https://draftbit.com/pricing. Note I am not affiliated and have not used the software just find it interesting to see this model actually out in the wild.
I currently work in the public sector in the UK and my experience is different. I see quite a lot of PowerAutomate going on to automate tasks and to create simple SharePoint apps.
One of the perks of Rails is that Ruby itself makes it more compelling.
When you need to get to something that the framework doesn’t expose, Ruby makes it easy to get to it without having to rewrite the framework, extend a class and replace it in multiple places or fork it just to use your modification.
This applies to the entire gem ecosystem too.
Over the years this ability has saved me numerous headaches with only a few lines of code. IMO it’s the real super power of Ruby.
Ruby is my least favorite part of Rails by far. The lack of type checking makes every single gem and rails update extremely dangerous in ways that are incredibly difficult to predict.
For example the redis gem updated to return an int from exists() instead of a bool like it did before. This doesn’t raise any exceptions because all ints work in if statements. They just always return true. Silently breaking all of the code using it. You can read all of the change logs and search your own code base, but will constantly run in to situations where another gems code is using the method that just changed.
As well as the fact that almost every method has one param “options” where the available options are never listed in the documentation and are impossible to find without reading the source code.
Rails itself I quite like for being an all inclusive framework that just works out of the box, but untyped languages should be avoided at all costs these days when we have much better options like typescript.
>Low code initially works quite well until you hit the limits of the low-code framework.
I wrote this a while ago. May be the future is a No Code tool with AI that generate enough of an App to allow Low Code edit with the help of AI while the whole App itself is still a full Ruby Rails App that allow Real Code modification in the future by professionals.
> Low code initially works quite well until you hit the limits of the low-code framework. If you just need a throw-away proof of concept, or a personal utility, or the like, low-code solutions can be quite efficient.
The same I'd say for dynamically typed languages (and their frameworks like Rails): initially works quite well until you hit the limits.
Once your app is big and there is a team, the efficiency dwindles. Refactoring becomes really hard. Unit test for the rescue, but they also take time to write.
at some point we need to take a step back and acknowledge that programming is not solved, no kind of language works particularly well at scale. Companies have been buying their way out by growing revenue/cash more quickly than tech debt, and those that fail to do that, stagnate and die.
Low code tools are fantastic for people with unambitious software goals (not to be confused with unambitious company goals). A lot of burden is lifted off of the tool builder, simply, because there is so much stuff that has been decided for you and therefore a lot of things you can not do.
But you have to really accept this limitation as a feature, just like you need to accept that inventing pieces or moves is not an option when you get frustrated during a match of chess. As soon as you fall into the coder mindset of "If only I could go one level down", you immediately switch into having 0 upside while having all of the downside. You fight the tool and then there's a ton of things that would in fact be simpler if you just wrote it starting from the correct level.
I would argue, just as with coding, this is mostly a matter of discipline. Having boundaries is part of the real world problem solving. Being able to work within them is a skill.
I never understood the "low code" microbubble that was being inflated.
We went through that era already. We called them RAD tools, and they targeted the same sort of strange, mythical end user profile. Someone so technically capable and apt that they could navigate a dizzying domain of deeply buried checkboxes, property fields, and sprawling relationships & side-effects, but who was also simultaneously unable to understand source code or program structure.
When using them you would quickly hit a point where making changes to relatively simple things would take mounting an archeological dig of GUI controls that would have otherwise been a few simple find & replace operations on code in a regular environment.
RAD is a broadly used term, but tools like Delphi were good at it and not restricted. You could build anything, but the dream of dragging and dropping little boxes and filling properties to build applications with the client and having, possibly another team, building other little boxes to satisfy the features you couldn't deliver, was a successful way of doing things.
I would say especially in modern day guy in some cases: I have not seen anyone happy changing modern code (nextjs or so) that has not been touched for 5 years. The 'just drop in a new component' won't work because 9 billion dependencies had updates and break everything (seems modern devs in the npm ecosystem have serious issues keeping things compatible even across minor versions); that issue was never there with delphi; you just make the change; either in code or gui. Many components I used for 2 decades to create and fix applications without the pain I feel these days. Unlike others apparently, I have no interest in actually maintaining applications: I want to make them and if no changes are needed, I don't want to update them; security fixes are meant to be compatible with what there already is, so that's just a recompile. It's not anymore though so it causes work and work costs money. It's not very nice unless you get paid by the hours then it's brilliant.
Commenting on your general use of rad tools, the rest you say i agree with. I see (i googled a bit) that things like Outsystems are RAD tools now, and yes, those are hell on earth to work with (we did a massive project with it and everyone basically thought it was terrible).
Then again, I wouldn't say Delphi was (is?) "low code". Certainly easier to use than some of the alternatives available for building GUI applications at the time (looking at you "Visual" C++!), but that just took care of the boilerplate, you still had to code the application's business logic.
Oh man, I totally forgot about the delphi IDE and the drag and drop editor for making GUIs. I only ever did encounter it in college (early 2000s) and for group projects it was really nice. Simply because it allowed you to prototype GUIs in the IDE and then instead of having to re-implement them in your markup language simply use those prototypes to build the functionality behind it.
It's a bit of a different perspective as you describe.
> I have not seen anyone happy changing modern code (nextjs or so) that has not been touched for 5 years.
Yeah... even if you do faithfully update dependencies it isn't straightforward. The sort of stuff I work on is mostly used internally and overall is fairly simple as far as the UI goes. So, for a while now, I have done away with most dependencies where I can and switched to vanilla JS, HTML and CSS for this sort of tooling. Not only does this help me with future maintaining of these tools, it also makes the whole development process a lot smoother as there is no building involved.
I very much realize that I am in a somewhat luxury position here as I don't do client facing applications and most of them are fairly simple. But that's also my point, all too often I see very simple single purpose applications that make use of a complete ecosystem of modern frameworks where the same can easily be achieved without them.
I think you're taking the intent of "low-code" too literal, or have not worked in an organization of sufficient size for its value proposition to be evident. It's not to solve a solutioning problem; it's to solve an organizational one.
While any "low-code" is marketed as a WYSWG, business friendly solution platform, what it actually is is a way for the business to get access to capabilities IT otherwise gatekeeps as "domain expertise", but fails to actually produce with.
Case-and-point: IT quotes an organization $75 million for 30 projects in fiscal year 20nn. By 20nn+1 IT has completed 5 projects for $75 million. Sick. Org gets "low-code" on their own dime for $1 million, hires a couple "business systems analyst" for a little less, and in 20nn+1.5 has completed 25 projects. In 20nn+3 IT looks incompetent, gets pissed, cries foul, the "business systems analyst" are ingested into IT and taught Java and CRUD circa 1998, and the life-cycle continues.
My experience of apps built by "the business" is 13 years in UBS and Bank of America. "The business" cannot be trusted to understand regulatory and privacy concerns, they cannot test their apps, they do not concern themselves with vulnerabilites in their dependencies or the licence terms therof. For those reasons, and more, the ability for the business to deliver apps more cheaply than IT is illusory.
That doesn't stop a cyclical swing towards RAD/no-code/AI when people forget this and then a swing back when we remember.
I have heard this before. But before we assume incompetence, first we need to understand what the IT is producing. Anyone in IT can also build the application in a very short time. What the business do not fully understand is the effort required to implement all the other non-functional requirements they need but they don't know yet. Once the quick and dirty solution is done, and they are happy that the feature are done, they realize it is not compliant. Now they spent some effort for compliance and after that they realize that there is no backup. If the data is corrupted, all is lost. So then they call up their business analyst to implement that. And after a few such iterations they give up and hand it over to IT. Now IT has a shitty application that is not secure, partially compliant and terrible disaster recovery. So it has to be rebuilt. Now it costs much more than if IT had implemented it in the beginning.
The costs of the IT department exists because we have experience on the real costs of implementing production grade software.
For minor throwaway apps, there is always excel and MS access.
100% this! In some companies the 'simple app' that is described in this post will get some ridiculous quote from central IT/tech ('it will take our team 4 sprints') and then never get signed off. IT will also ban anyone spinning up their own servers due to support issues.
No code platforms manage to get around this.
Another use case - I work for a 'non-tech' consultancy. Clients typically won't like paying us to spin up some flask/django/rails app, but are happy to pay us to spin up some sort of no-code thing for them (perception is that it will be easier to self-support, which is also probably the reality compared to me developing some sort of rails app and then leaving the company).
Writing the code is NOT the problem with these enterprise project failures.
Usually decades of problem-solving have led to an absolute mess of blurry ownership and accountability.
This in turn leads to corner cutting and a road completely covered in Chesterton fences…
Tearing arbitrary fence down leads to consequences out of project scope, no one can answer questions, and no one can prioritize - this is a business problem, and no amount of fancy code (lo/hi/full/lo/left or right) will help.
If you run a bigger company and rely on IT and ERP flows, well, it’s a part of your core and you’d better treat it as such!
From your first sentence it is implied you have some working experience with this. What are your thoughts on end user computing and the longer term effect in the business?
Low code tooling is alive and well in the entertainment industry. Node graphs are becoming very popular in game engines, shaders, procedural modeling software etc.
The king of low-code, spreadsheets, are still quite popular as well.
Well said. You are exactly right. Low Code stuff is usually invented by people with a specific set of criteria that they realize can be generalized, and defined by a GUI, but who lack enough experience to realize the entire world of possibilities can't be crammed into their model. Languages (like Python, etc) are already the most compact way to represent most things, and trying to avoid that fact just makes things even harder.
You're letting perfect be the enemy of good. The low code solutions can simply have a full-code escape hatch with interop. Much like how Python can interop with C.
I don’t think they were strange or mythical users. Excels and Access gave business analysts enough power to make real tools tailored to specific needs. VB would have been the next step. One thing that made this possible was the ubiquity of Windows though.
I still haven’t used anything as easy and powerful as those tools were even if they were Windows only and lacked easy distribution.
I see it quite often as SaaS platform I work for the configuration grew into small time low code because business wanted to do all kinds of changes skipping dev cycle to deliver faster.
„low code” appeals to people - who are not technically capable, whose numbers are big - who think if they can get rid of this complex writing stuff they will be able to do stuff. Those people are on all levels of seniority so if CEO mandates stuff, company will do that.
Unfortunately essential complexity of an application does not go away and I have seen those people struggling, cursing and shooting themselves in the foot.
proper software dev tooling has all the right solutions for handling complexity like version control, CI/CD, unit/integration testing - no low code tools implement that.
But if people hear my solution „let’s teach you proper dev tools” they are pretty much uninterested.
It's particularly baffling because there's currently a _competitive_ "do programming without doing programming" bubble; LLMs. Whatever about one at a time, it's odd to have two approaches to the same false promise going at once.
RAD tools had nothing to do with low-code. I think you're confusing something. You still needed seasoned software developers and you weren't restricted by anything.
We inherited some Informatica ETL workflows once at work. Nice at first glance with good logging, but peel back the surface a little bit and it was a dizzying level of hidden complexity. Some of this was business logic which was inherently complex, but it was so deeply buried in menus and abstractions with no easy diffing or version control...
Like the comment starter mentioned - who are these tools designed for?
Low code efforts go back decades. In the eighties there was this whole movement around 4GL languages. Basically relatively simple languages around databases that enabled relatively quick development of business applications. Before that, Cobol of course was an attempt to come up with a business programming language that was nominally human readable. In the nineties we got things like Visual Basic, Delphi and a bunch of other things which again were targeting relatively inexperienced programmers. And then of course there's a long history of creating domain specific languages for all sorts of things - typically with the goal to let domain experts be able to define things. Tcl/TK is a good example for UI applications on X-windows.
Rails built on all of that. Ruby brought two useful thing to the table (well, borrowed from Lisp) which was meta programming and the ability to use its syntax to build so-called internal DSLs: domain specific languages which were just building on top of Ruby's own syntax instead of needing a new one. Rails is basically a DSL for building web based database applications with server side model view controller style UIs.
Once MVC moved mostly client side with single page javascript applications and rich mobile applications, the MVC bits and bobs became somewhat redundant. And of course the rest of it is basically a nice but otherwise unremarkable ORM framework that you can find for other languages as well. I was never that impressed with it to be honest and I'm not a big fan or ORM frameworks in general. Server side MVC is still somewhat relevant if you are into server side rendering (which reinvents what world + dog was doing twenty years ago) but otherwise not that relevant for most REST APIs.
IMHO the last two decades have been a bit unremarkable for UI development. It seems a lot of things plateaued in the nineties. The average UI projects are still fairly labor intensive for what they do; which is mostly just building a lot of form based crap to input data in some database. We had perfectly usable and relatively idiot proof visual UI builders that did that sort of thing thirty years ago. From a functional point of view, the resulting UIs more or less did the same thing. Was that great code, not necessarily. But it did the job. And most "modern" react/rails/django/whatever code isn't a whole lot better. If you discard the lipstick on a pig that is CSS, you are left with essentially the same UI components and primitives (buttons, checkboxes, text fields, etc.). We had all of those decades ago. You don't need a mustache twirling hipster web ninja to reinvent those wheels.
This post boils down to "it's easier to use something you know in and out that some new tool you're using for the first time.", so not a good argument. I think I've seen ruby code a handful of times in my life and it looks like an obfuscated form of perl to me. If you'd give me a low code tool and ruby and the same task I don't think I'll succeed with either in a reasonable amount of time.
You can use an LLM and get quite far with Rails imo if you've been programming in a web framework of any kind. You don't have to know Ruby.
Probably same goes for the low code tool, only there once you're stuck its probably because you've hit the limits of the tool.
I don’t want to build in a language without types, but low code is even less types than Rails. I’ve just never worked on a public app that was simple enough for Rails to feel good - Airbnb was rails but by the time I got there it was very much not simple. Internal tools in rails though, that is okay.
Allow internal tools to be built with regular frameworks, while making it easy to add gitops, SSO, secrets management etc which are required for internal tools.
I expect low code that can be translated into typed clean code. The low code side of it is just with more assumptions baked in. And with llms you can perhaps have a lot of leeway to in fact customize and allow low or no coders to specify somethinf exportable to readable typed code
Whenever I google to see if people are enjoying Sorbet or RBS I find articles like this that basically say “no, no one seems to be enjoying this and it’s going nowhere” https://brandur.org/fragments/ruby-typing-2024
In my opinion RBS files are a horrible design decision and split the Ruby community between a typing system that people actually want to use (Sorbet) and a typing system we’ll tolerate because it’s official but a pain in the ass (RBS), leaving both ecosystems to whither. Sad :-(
"Strongly typed" is not a well defined term—it basically means "I'm personally comfortable with the level of guarantees offered by the language", which is a purely subjective measurement.
In context it's obvious that what OP meant is that they wouldn't want to build in a language without statically-checked types. That there are languages that provide even fewer statically-analyzable guarantees than Ruby does not make Ruby a suitable candidate.
I'm building "ActiveRecord but with type(script)" at https://joist-orm.io/ and have our own internal "kinda Rails w/GraphQL" going internally--so far we're at ~450 tables and still "feeling good" (no n+1s ever!), but definitely a long way to go before AirBNB-sized problems.
Even though it is Oracle, Oracle APEX is exceptional at creating CRUD applications.
The main benefit to other low code tools is that it doesn't want eliminate code but just the repetitive UI code. It still expects you to have skills in database development so you can achieve everything but generating a Report, Grid or Form from a SQL query takes as long as you need to write the query. And everything is customizable and maintainable in the end.
A former employer of mine banned Microsoft Access, because they didn't want critical business functions running from random desktop machines. I imagine they'd take the same view today to home made LLM-generated Rails apps.
They instead said "if you need to write your own little CRUD apps, use our APEX instance that we support and have backups for."
> imagine they'd take the same view today to home made LLM-generated Rails apps.
Sounds like an effective solution. Even though some people might build a great application, but someday they might leave, and nobody knows how to administer this.
You can still write bad PL/SQL code, but at least everything is centralized and stored in a single database where you have an admin making sure that everything is fine. For other developers, it is straightforward to make small changes because 95% of the complexity just lies in the data model and the database code. You don't need to adapt to a specific infrastructure, frameworks and other dependencies, etc.
> It still expects you to have skills in database development so you can achieve everything but generating a Report, Grid or Form from a SQL query takes as long as you need to write the query. And everything is customizable and maintainable in the end.
Isn't this what people thought about Oracle Forms before it going the way it did?
Yes, it similarly just builds around developers storing the code in the database layer. Forms is still around, with some giant companies relying on it, but of course, it is slowly dying. APEX is also 20 years old already, but based on the web stack. This choice aged perfectly, so it went from a niche inside Oracle to now the default application framework inside Oracle around 2020. Oracle Forums[0] is build on APEX for example.
> It also makes it so easy to create opportunities for SQL injection if you don't have careful coders.
This is not the case. If you bind values with :ITEM_NAME and use compiled statements (never dynamic string concatenated ones with "execute immediate') there is no chance of SQL injection.
I don't know. I recently am drawn more and more in pure Go code, which is conceptually as simple as it gets, yet I can achieve basically everything imaginable in it without hitting walls/limitations. Add some (embedded) SQLite for small/quick/cheap things or postgres for when it gets more involved or critical (horizontal scaling, backups, ...), and everything is quickly possible. Now with LLMs, its outright trivial to make them generate functionality at will immediately, and (pure) Go is exceptionally friendly with LLM codegen, due to the language being stupid simple and the stdlib being "complete" for years.
Essentially I prefer staying at the "you need to be a coder" abstraction level, but the general tooling nowadays makes becoming one very easy. Once you mentally lift the requirement that something needs to be configurable by some non-technical end user or even needs an UI at all, 90%+ of all dev effort can be saved directly. Plus there are no showstoppers in capabilities or usual barriers like too bad performance/config hell of "no code"/"low code" I encountered quite often. And if you don't use the latest webdev fads, things can be maintainable for decades (looking at Go compared to NodeJS).
Rawdogging basic programming (yes, also no framework if possible) made more "business" projects first succeed (and then stay alive easily) much more than either a web framework or any kind of lo-/no-tool, at least the things I encountered in the wild. Even bad spaghetticode monstrosities can now uploaded to an LLM and refactored into sanity quite efficiently.
The worst kind of projects (with lots of pain and regret) have been either JS-based, mis-used framework projects (including rails!) or Salesforce setups. Often you're stuck in a dead-end here.
For simple frontends I just use the built in go templates.
If I need complex frontends for larger apps I use sveltekit/svelte5 for frontend data I just export a single instance of a class that has state/derived fields for data and an isInitialized field that returns a promise for loading the data. Then methods for reloading data, changing data or any actions I need.
So all i have to do is await classInstance then use the class data in whatever way I need. Everything is reactive and simple due to states. you can use and update the fields directly like regular js but with global reactivity built in.
The data automatically loads the first time the module is imported. due to how esmodule files work. I just have a classInstance.LoadData() after the export.
Svelte5 isn't as good with LLM's but with some small instructions about how states, derived, and effects work it works pretty well.
Most existing front-end frameworks are already low-code by any standards, I'd say.
Most backend, integrations, automations require some degree of business logic, which requires algorithmic thinking, and this in turns requires engineers - there aren't many people who 'think algorithmically' and can't code. Engineers, in turn, hate low code frameworks, as they are useless on the CV and annoying to work with for reasons mentioned by others here. Proprietary s*ht tech that always, inevitably, leads to custom code.
And, it's expensive. We had mulesoft, outsystems, boomi and replaced it all with general purpose stuff shaving approx. 9M/yr in license costs. We have lost no velocity, and the great thing about the alternative (in our case: simply standardizing the toolset and going with GCP 'serverless' stack) is that its super easy to find devs who will willingly work on that. That hasn't been our experience with the low code frameworks.
I am not a rails dev but have looked into it for some side projects that I am considering.
IMO, I think it hits an excellent balance between rolling-your-own framework and no-framework-low-code. Rails itself handles so much configuration and wiring up so you that most of the code you do have to write is business logic.
Lambda functions and firebase are convenient and compelling but come with their own tradeoffs that are not as well-tested in the real world compared to rails.
I think Rails is good for a consultant who wants to pump out a lot of relatively generic apps. You pay a constant upfront cost to learn the Rails magic and the conventions, and once you know that stuff, it makes greenfield development faster.
If you're doing a single big project, Rails is less attractive. The upfront cost is amortized over just one project, and the magic makes it a bit harder to stray from the beaten path when you need that.
My experience has been different. Rails is good for everything from small internal projects to larger, enterprise level projects. Like all languages and frameworks, it requires discipline and good practices for the code to remain robust and maintainable, but functionally I’m not aware of anything that fits what you describe in your second paragraph.
Readit News
However, implementing anything significant that's expected to be extended and improved, particularly when there are users that request changes, improvements and new features, low-code "is like climbing a tree in order to reach the moon". You'll will very quickly run out of tree and further progress becomes almost impossible.
To a lesser extent the same thing also occurs with web development frameworks, but the limits are less constraining and there are often mechanisms that allow you integrate your own code, that implements whatever it is that the framework doesn't provide.
Low code, frameworks, and "build it totally from scratch", can all be a valid solutions, but the right choice often depends on a bunch of specific considerations (technology, user & quality expectations, organizational capabilities & constraints, etc.)
My recommendation is to keep an open mind about alternative technologies and approaches, and to pick solutions that are appropriate for the environment in which they will be developed, extended and operated. And that requires experience, which you normally don't have in the early phase of your career (e.g. good judgement comes from experience, and experience comes from bad judgement)
What has completely changed the field is LLMs. We now have employees of every sort building small Python scripts which actually work. Even installing Python and getting it up and running is something the LLMs help with. Obviously almost all of it is terrible, and none of scale, but for 90% it, it never has to run outside the personal computers of the employees who write it. Now the challenge becomes keeping the knowledge (and scripts) when employees change jobs. Though to be fair, the knowledge bit was always a challenge.
I've worked quite a bit in civil engineering and GIS, and most places I've worked at have made very good use of a 'low-code' tool called FME for automation and ETL tasks. I even reach for it myself for many tasks, even when I am fully capable of doing exactly the same task using for example Python. For the right tasks it is simply the most productive solution.
That being said even with these tools you still need to know how to 'program', at least conceptually, and it's not like just anybody can pick up a tool like this and be productive. The basic concepts of control flow and algorithms still apply and work the same way.
Such a model is not easily monetized which is why you don’t often see this model in the wild. Draftbit is one company I’ve seen that uses this model: https://draftbit.com/pricing. Note I am not affiliated and have not used the software just find it interesting to see this model actually out in the wild.
When you need to get to something that the framework doesn’t expose, Ruby makes it easy to get to it without having to rewrite the framework, extend a class and replace it in multiple places or fork it just to use your modification.
This applies to the entire gem ecosystem too.
Over the years this ability has saved me numerous headaches with only a few lines of code. IMO it’s the real super power of Ruby.
For example the redis gem updated to return an int from exists() instead of a bool like it did before. This doesn’t raise any exceptions because all ints work in if statements. They just always return true. Silently breaking all of the code using it. You can read all of the change logs and search your own code base, but will constantly run in to situations where another gems code is using the method that just changed.
As well as the fact that almost every method has one param “options” where the available options are never listed in the documentation and are impossible to find without reading the source code.
Rails itself I quite like for being an all inclusive framework that just works out of the box, but untyped languages should be avoided at all costs these days when we have much better options like typescript.
I wrote this a while ago. May be the future is a No Code tool with AI that generate enough of an App to allow Low Code edit with the help of AI while the whole App itself is still a full Ruby Rails App that allow Real Code modification in the future by professionals.
The same I'd say for dynamically typed languages (and their frameworks like Rails): initially works quite well until you hit the limits.
Once your app is big and there is a team, the efficiency dwindles. Refactoring becomes really hard. Unit test for the rescue, but they also take time to write.
But you have to really accept this limitation as a feature, just like you need to accept that inventing pieces or moves is not an option when you get frustrated during a match of chess. As soon as you fall into the coder mindset of "If only I could go one level down", you immediately switch into having 0 upside while having all of the downside. You fight the tool and then there's a ton of things that would in fact be simpler if you just wrote it starting from the correct level.
I would argue, just as with coding, this is mostly a matter of discipline. Having boundaries is part of the real world problem solving. Being able to work within them is a skill.
We went through that era already. We called them RAD tools, and they targeted the same sort of strange, mythical end user profile. Someone so technically capable and apt that they could navigate a dizzying domain of deeply buried checkboxes, property fields, and sprawling relationships & side-effects, but who was also simultaneously unable to understand source code or program structure.
When using them you would quickly hit a point where making changes to relatively simple things would take mounting an archeological dig of GUI controls that would have otherwise been a few simple find & replace operations on code in a regular environment.
I would say especially in modern day guy in some cases: I have not seen anyone happy changing modern code (nextjs or so) that has not been touched for 5 years. The 'just drop in a new component' won't work because 9 billion dependencies had updates and break everything (seems modern devs in the npm ecosystem have serious issues keeping things compatible even across minor versions); that issue was never there with delphi; you just make the change; either in code or gui. Many components I used for 2 decades to create and fix applications without the pain I feel these days. Unlike others apparently, I have no interest in actually maintaining applications: I want to make them and if no changes are needed, I don't want to update them; security fixes are meant to be compatible with what there already is, so that's just a recompile. It's not anymore though so it causes work and work costs money. It's not very nice unless you get paid by the hours then it's brilliant.
Commenting on your general use of rad tools, the rest you say i agree with. I see (i googled a bit) that things like Outsystems are RAD tools now, and yes, those are hell on earth to work with (we did a massive project with it and everyone basically thought it was terrible).
https://i0.wp.com/blogs.embarcadero.com/wp-content/uploads/2...
It's a bit of a different perspective as you describe.
> I have not seen anyone happy changing modern code (nextjs or so) that has not been touched for 5 years.
Yeah... even if you do faithfully update dependencies it isn't straightforward. The sort of stuff I work on is mostly used internally and overall is fairly simple as far as the UI goes. So, for a while now, I have done away with most dependencies where I can and switched to vanilla JS, HTML and CSS for this sort of tooling. Not only does this help me with future maintaining of these tools, it also makes the whole development process a lot smoother as there is no building involved.
I very much realize that I am in a somewhat luxury position here as I don't do client facing applications and most of them are fairly simple. But that's also my point, all too often I see very simple single purpose applications that make use of a complete ecosystem of modern frameworks where the same can easily be achieved without them.
While any "low-code" is marketed as a WYSWG, business friendly solution platform, what it actually is is a way for the business to get access to capabilities IT otherwise gatekeeps as "domain expertise", but fails to actually produce with.
Case-and-point: IT quotes an organization $75 million for 30 projects in fiscal year 20nn. By 20nn+1 IT has completed 5 projects for $75 million. Sick. Org gets "low-code" on their own dime for $1 million, hires a couple "business systems analyst" for a little less, and in 20nn+1.5 has completed 25 projects. In 20nn+3 IT looks incompetent, gets pissed, cries foul, the "business systems analyst" are ingested into IT and taught Java and CRUD circa 1998, and the life-cycle continues.
That doesn't stop a cyclical swing towards RAD/no-code/AI when people forget this and then a swing back when we remember.
The costs of the IT department exists because we have experience on the real costs of implementing production grade software.
For minor throwaway apps, there is always excel and MS access.
No code platforms manage to get around this.
Another use case - I work for a 'non-tech' consultancy. Clients typically won't like paying us to spin up some flask/django/rails app, but are happy to pay us to spin up some sort of no-code thing for them (perception is that it will be easier to self-support, which is also probably the reality compared to me developing some sort of rails app and then leaving the company).
Usually decades of problem-solving have led to an absolute mess of blurry ownership and accountability.
This in turn leads to corner cutting and a road completely covered in Chesterton fences…
Tearing arbitrary fence down leads to consequences out of project scope, no one can answer questions, and no one can prioritize - this is a business problem, and no amount of fancy code (lo/hi/full/lo/left or right) will help.
If you run a bigger company and rely on IT and ERP flows, well, it’s a part of your core and you’d better treat it as such!
The king of low-code, spreadsheets, are still quite popular as well.
I still haven’t used anything as easy and powerful as those tools were even if they were Windows only and lacked easy distribution.
„low code” appeals to people - who are not technically capable, whose numbers are big - who think if they can get rid of this complex writing stuff they will be able to do stuff. Those people are on all levels of seniority so if CEO mandates stuff, company will do that.
Unfortunately essential complexity of an application does not go away and I have seen those people struggling, cursing and shooting themselves in the foot.
proper software dev tooling has all the right solutions for handling complexity like version control, CI/CD, unit/integration testing - no low code tools implement that.
But if people hear my solution „let’s teach you proper dev tools” they are pretty much uninterested.
We inherited some Informatica ETL workflows once at work. Nice at first glance with good logging, but peel back the surface a little bit and it was a dizzying level of hidden complexity. Some of this was business logic which was inherently complex, but it was so deeply buried in menus and abstractions with no easy diffing or version control...
Like the comment starter mentioned - who are these tools designed for?
Rails built on all of that. Ruby brought two useful thing to the table (well, borrowed from Lisp) which was meta programming and the ability to use its syntax to build so-called internal DSLs: domain specific languages which were just building on top of Ruby's own syntax instead of needing a new one. Rails is basically a DSL for building web based database applications with server side model view controller style UIs.
Once MVC moved mostly client side with single page javascript applications and rich mobile applications, the MVC bits and bobs became somewhat redundant. And of course the rest of it is basically a nice but otherwise unremarkable ORM framework that you can find for other languages as well. I was never that impressed with it to be honest and I'm not a big fan or ORM frameworks in general. Server side MVC is still somewhat relevant if you are into server side rendering (which reinvents what world + dog was doing twenty years ago) but otherwise not that relevant for most REST APIs.
IMHO the last two decades have been a bit unremarkable for UI development. It seems a lot of things plateaued in the nineties. The average UI projects are still fairly labor intensive for what they do; which is mostly just building a lot of form based crap to input data in some database. We had perfectly usable and relatively idiot proof visual UI builders that did that sort of thing thirty years ago. From a functional point of view, the resulting UIs more or less did the same thing. Was that great code, not necessarily. But it did the job. And most "modern" react/rails/django/whatever code isn't a whole lot better. If you discard the lipstick on a pig that is CSS, you are left with essentially the same UI components and primitives (buttons, checkboxes, text fields, etc.). We had all of those decades ago. You don't need a mustache twirling hipster web ninja to reinvent those wheels.
(Not that I'm a fan of low code or anything.)
Allow internal tools to be built with regular frameworks, while making it easy to add gitops, SSO, secrets management etc which are required for internal tools.
In my opinion RBS files are a horrible design decision and split the Ruby community between a typing system that people actually want to use (Sorbet) and a typing system we’ll tolerate because it’s official but a pain in the ass (RBS), leaving both ecosystems to whither. Sad :-(
Dead Comment
In context it's obvious that what OP meant is that they wouldn't want to build in a language without statically-checked types. That there are languages that provide even fewer statically-analyzable guarantees than Ruby does not make Ruby a suitable candidate.
Yep; that's the only reason I don't use Rails.
I'm building "ActiveRecord but with type(script)" at https://joist-orm.io/ and have our own internal "kinda Rails w/GraphQL" going internally--so far we're at ~450 tables and still "feeling good" (no n+1s ever!), but definitely a long way to go before AirBNB-sized problems.
I'd go with Kotlin/SqlDelight or Rust/sqlx (or even jOOQ) these days to avoid having to deal with the overhead of an ORM.
They instead said "if you need to write your own little CRUD apps, use our APEX instance that we support and have backups for."
Sounds like an effective solution. Even though some people might build a great application, but someday they might leave, and nobody knows how to administer this.
You can still write bad PL/SQL code, but at least everything is centralized and stored in a single database where you have an admin making sure that everything is fine. For other developers, it is straightforward to make small changes because 95% of the complexity just lies in the data model and the database code. You don't need to adapt to a specific infrastructure, frameworks and other dependencies, etc.
Isn't this what people thought about Oracle Forms before it going the way it did?
[0]https://forums.oracle.com/ords/r/apexds/community/home
It also makes it so easy to create opportunities for SQL injection if you don't have careful coders. And it is also a great target for DoS attacks.
Having said all this, it really is the only low code platform I would ever consider using, in spite of it being Oracle's.
This is not the case. If you bind values with :ITEM_NAME and use compiled statements (never dynamic string concatenated ones with "execute immediate') there is no chance of SQL injection.
Essentially I prefer staying at the "you need to be a coder" abstraction level, but the general tooling nowadays makes becoming one very easy. Once you mentally lift the requirement that something needs to be configurable by some non-technical end user or even needs an UI at all, 90%+ of all dev effort can be saved directly. Plus there are no showstoppers in capabilities or usual barriers like too bad performance/config hell of "no code"/"low code" I encountered quite often. And if you don't use the latest webdev fads, things can be maintainable for decades (looking at Go compared to NodeJS).
Rawdogging basic programming (yes, also no framework if possible) made more "business" projects first succeed (and then stay alive easily) much more than either a web framework or any kind of lo-/no-tool, at least the things I encountered in the wild. Even bad spaghetticode monstrosities can now uploaded to an LLM and refactored into sanity quite efficiently.
The worst kind of projects (with lots of pain and regret) have been either JS-based, mis-used framework projects (including rails!) or Salesforce setups. Often you're stuck in a dead-end here.
Sqlite for quick and easy postgres for scaling.
For simple frontends I just use the built in go templates.
If I need complex frontends for larger apps I use sveltekit/svelte5 for frontend data I just export a single instance of a class that has state/derived fields for data and an isInitialized field that returns a promise for loading the data. Then methods for reloading data, changing data or any actions I need.
So all i have to do is await classInstance then use the class data in whatever way I need. Everything is reactive and simple due to states. you can use and update the fields directly like regular js but with global reactivity built in.
The data automatically loads the first time the module is imported. due to how esmodule files work. I just have a classInstance.LoadData() after the export.
Svelte5 isn't as good with LLM's but with some small instructions about how states, derived, and effects work it works pretty well.
Most backend, integrations, automations require some degree of business logic, which requires algorithmic thinking, and this in turns requires engineers - there aren't many people who 'think algorithmically' and can't code. Engineers, in turn, hate low code frameworks, as they are useless on the CV and annoying to work with for reasons mentioned by others here. Proprietary s*ht tech that always, inevitably, leads to custom code.
And, it's expensive. We had mulesoft, outsystems, boomi and replaced it all with general purpose stuff shaving approx. 9M/yr in license costs. We have lost no velocity, and the great thing about the alternative (in our case: simply standardizing the toolset and going with GCP 'serverless' stack) is that its super easy to find devs who will willingly work on that. That hasn't been our experience with the low code frameworks.
IMO, I think it hits an excellent balance between rolling-your-own framework and no-framework-low-code. Rails itself handles so much configuration and wiring up so you that most of the code you do have to write is business logic.
Lambda functions and firebase are convenient and compelling but come with their own tradeoffs that are not as well-tested in the real world compared to rails.
If you're doing a single big project, Rails is less attractive. The upfront cost is amortized over just one project, and the magic makes it a bit harder to stray from the beaten path when you need that.