Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rails is better low code than low code

radanskoric.com

Post reply on HN
Print view View original

81–90 of 249 posts

Re: Rails is better low code than low code

#81

Post by it_citizen »

brightball wrote: post #80
ahodgkinson wrote: post #66

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 t…

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…

I agree. But with great powers comes great responsabilities.

Re: Rails is better low code than low code

#82

Post by afuchs »

abid786 wrote: post #74
0xDEAFBEAD wrote: post #61

Earlier quoted context omitted.

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…

Could you give some examples of what the use cases are where Rails makes it hard to stray from the beaten path?

> Could you give some examples of what the use cases are where Rails makes it hard to stray from the beaten path?

Rails is amazing for greenfield projects. It will automatically do things for you which will greatly reduce the amount of boilerplate you need to write as long as you follow the framework's conventions.

However, Rails has a less than stellar reputation from those who have maintained long lived projects which use it. Rails' conventions encourage the use of fat models where business logic is implemented in the models themselves. With the default scaffolding Rails provides, every single model and all of this business logic ends up in the project's app/models/ directory without any separation between different features. Because the default doesn't cleanly separate business logic with well defined boundaries this means that Rails apps tend to evolve in a way where everything starts to become tightly coupled with everything else. When the business requirements for the application inevitably change this tendency towards tight coupling between models makes it difficult to make major changes to existing code.

I've also seen hacky workarounds used in Rails based apps which exist to make complex business logic work (e.g., saving one model doesn't implicitly trigger hooks for business logic on other related models). These hacky workarounds usually break the conventions Rails uses and ends up requiring extra boilerplate to be added elsewhere in the application.

Some developers try to avoid this by hand rolling more architectural layers (e.g., "Java/Go/Node.js/OOP like") on top of Rails to try prevent this, to varying degrees of success. Other frameworks (e.g., Django) try to encourage developers to separate different features into distinct modules to try and prevent them from being tightly coupled with each other.

Re: Rails is better low code than low code

#83

Post by throwaway42668 »

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.

Re: Rails is better low code than low code

#84

Post by Zambyte »

jitl wrote: post #6

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.

Ruby is strongly typed. Dynamic typing and inferred typing are not the same as typeless. B and Forth are examples of typeless languages.

Re: Rails is better low code than low code

#85

Post by stephen »

jitl wrote: post #6

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.

> don't want to build in a language w/o types

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.

Re: Rails is better low code than low code

#86

Post by gonzo41 »

throwaway42668 wrote: post #83

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 unde…

Everything you just said also applies to all ETL and workflow management tools as well. There's a level of complexity that's never going away.

Re: Rails is better low code than low code

#87

Post by andrewmutz »

afuchs wrote: post #82
abid786 wrote: post #74

Earlier quoted context omitted.

Could you give some examples of what the use cases are where Rails makes it hard to stray from the beaten path?

> Could you give some examples of what the use cases are where Rails makes it hard to stray from the beaten path? Rails is amazing for greenfield projects. It will automatically do things for you which will greatly reduce the amount of boilerplate you need to write as long as you follow the framework's conventions. However, Rails has a less than stellar reputation from those who have maintained long lived projects wh…

Long-lived rails apps are a nightmare to work with, in exactly the same manner as long-lived java, python or php apps

Re: Rails is better low code than low code

#88

Post by stana »

revscat wrote: post #37
stana wrote: post #32

Code is cost. Low-code is getting a vendor to generate code for you (cost again) and putting into a black box you can't access. i.e. lock in.

How is that relevant to this discussion?

Point I was trying to make was that low-code is a lock-in IMO, and I would pick Ruby, Django, or whatever any day for no other reason than being able to modify/maintain/own code.

Re: Rails is better low code than low code

#90

Post by stoat_meniscus »

gonzo41 wrote: post #86
throwaway42668 wrote: post #83

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 unde…

Everything you just said also applies to all ETL and workflow management tools as well. There's a level of complexity that's never going away.

Yes, Informatica was the one that came to mind.

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?

Post reply on HN