Live data from Hacker News

Rails is better low code than low code

radanskoric.com

71–80 of 249 posts

Re: Rails is better low code than low code

#71
post #29

Earlier quoted context omitted.

I don't particularly want to be involved with a long lived and non trivial collection of Ruby code either, if my experience of the Gitlab codebase is anything to go by. I agree with the author's point, if you replace Ruby with something less awful (Deno, Go, etc.)

This feels like the exception that proves the rule. Gitlab has one of the largest Rails codebases on earth. It's also been built by a decentralized remote engineering org from the start. I think that explains a lot. Compare that to my personal experiences and that of my colleagues who work heavily with Rails: We show up to a new job at any level of seniority, spend a week or two learning the codebase, and immediately…

Same here. I’ve basically made my career as a rails developer and it’s never taken me very long to figure out the many applications I’ve worked with. Some of them are quite complicated.

Some of the older stuff built around rails overdid the meta-programming. Makes unraveling things a little more difficult, but you generally know where to look.

And every time I see a nontrivial state machine using a state machine gem, I know I’m in for a world of hurt. But I know exactly what mistakes I will be fixing. :)

Re: Rails is better low code than low code

#73

Earlier quoted context omitted.

Sufficiently advanced "low code" is indistinguishable from a framework or a library. The main difference in practice is that most software that markets itself as "low code" obscures how it works and tries to lock you in to charge rent. Though to be fair, there is generally not much of a market for proprietary/non-OSS libraries and frameworks anymore, so if you want to monetize your library/framework low-code (or an A…

This makes me think about Microsoft Access and why it never took off. It helps people create databases, forms, and reports. One might call it a no code solution as opposed to merely a low code solution. There are a lot of businesses that's ostensibly in the right place for Microsoft Access. In my view there are certain aspects of app building that's hard. Some of it is in code, some of it is in design, some of it is…

Access was so good. I've been trying to find something half as good for years since it died.

Re: Rails is better low code than low code

#74

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…

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?

Re: Rails is better low code than low code

#76

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…

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…

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.

Re: Rails is better low code than low code

#77

Earlier quoted context omitted.

Sufficiently advanced "low code" is indistinguishable from a framework or a library. The main difference in practice is that most software that markets itself as "low code" obscures how it works and tries to lock you in to charge rent. Though to be fair, there is generally not much of a market for proprietary/non-OSS libraries and frameworks anymore, so if you want to monetize your library/framework low-code (or an A…

This makes me think about Microsoft Access and why it never took off. It helps people create databases, forms, and reports. One might call it a no code solution as opposed to merely a low code solution. There are a lot of businesses that's ostensibly in the right place for Microsoft Access. In my view there are certain aspects of app building that's hard. Some of it is in code, some of it is in design, some of it is…

Microsoft Access definitely took off. It was certainly more popular than the new crop of no-code/low-code platforms we have today. In the late-90s and early 2000s almost every large company seems to have had Access applications running in several different corners of the business.

The reason Access eventually died off is that it wasn't designed as a multi-user database. You could run Access on a network file share but performance would suffer (especially with concurrent access by multiple users), and you'll be running the risk of database file corruption. Microsoft Access did support a client-only mode, where Access is used for the forms, queries and application code, but the actual data is stored in Microsoft SQL Server — but setting up and maintaining a database server was probably too complicated for the type of contexts in which Access became popular.

The key point is that most of the usage of low-code products in the past was basically an instance of Shadow IT. In order for a Shadow IT product to be successful it generally needs to be easy to use, easy to distribute (or access) and have a capable free (or effectively free) version. Access and Excel had it all. They were easy to use for beginners (although complex applications required skill). Distribution was extremely simple in the corporate intranet age: you just had to place your Excel or Access file on a network share. They were part of Microsoft Office, so everybody had them on their computer "for free". If a product fulfills the conditions above, entrepreneurial employees will start using this product to address viable needs that your IT department lacks the resources to solve with a more robust solution.

Often these Access apps became popular enough that it had to be officially taken by the IT department, where IT programmers invariably cursed the buggy hack of an application they had to maintain. I don't know the statistics, but I assume a great number of these would just be rewritten as a traditional client/server or web application.

Re: Rails is better low code than low code

#78
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.

[flagged]

Re: Rails is better low code than low code

#79
post #74

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?

If you work on an older and large rails code base, you can easily find the programmers who came from more "formal" languages like java.

They build layers and layers of code to "isolate" rails and end up with big ball of mud. Once you do that you have to keep wrapping and adapting, and commanding, and querying and it takes a gang of more than 4 developers to maintain a feature set that could be done with 1 good rails dev.

Code is liability. Features are the asset. Well written rails has one of the best bang for the buck for lines of code per feature.

Re: Rails is better low code than low code

#80

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 a few lines of code. IMO it’s the real super power of Ruby.

Post reply on HN