I think I saw this early on, but then forgot about it. Stumbled upon it today, and it actually looks like a cool project. Have anyone any experience of using it for a real or just a toy project?

you are viewing a single comment's thread
view the rest of the comments

[–] nous@programming.dev 28 points 7 months ago (11 children)

Have not used it myself, but having a quick look at it I don't think I likely ever will. Mostly for personal preferences with the projects goals and design than anything else.

I don't like large do everything frameworks. They are ok when you want to do what they were designed for. But as soon as you step outside that they become a nightmare to deal with. They also tend to grow more complex over time as more of what everyone wants gets added to them. A framework author's case against frameworks is a great talk on the matter. Instead I prefer simpler smaller focused libraries that I can pick and choose from that best suit the application I want to build.

Also it seems like the MVC pattern, which I dislike. Personally I like to group code that changes together next to each other. Where as MVC groups code that has the same function together and splits up code that tends to change together. This means for any change or feature you are editing many files across many folders which gets tedious rather than just co-locating all the related code in one directory or file.

Because they include all dependencies for everything you might want they often lag behind upstream projects. This was a huge issue for me years ago when I tried out the Rocket framework. I wanted to use a hosted postgres DB that only supported https connections but the version of the library it was using did not yet include that feature - basically killing the project there.

They can be great if they do everything you want in the way you want and loco looks to be well built and maintained overall. But I find far too often that they don't, if not at the start of a project then eventually as my projects evolve (which is far worst). I would also question its staying power though (we have seen popular and promising frameworks before that suddenly stop development) but only time will answer that.

[–] snaggen@programming.dev 3 points 7 months ago (1 children)

What I feel looks interesting with "on rails" is that you get things like database management built in, like setup, upgrades aso. Of course, this also means that it might be difficult to jump off the rails if you need that. And even if I feel like I'm not the target audience, since I prefer to pick and choose smaller libraries, I'm watching this with interest since Ruby on Rails seems to be quite popular.

[–] natecox@programming.dev 5 points 7 months ago (1 children)

Rails is great for starting an app, you can get something to a functional MVP state in a ridiculously small amount of time. We used to do rapid prototyping where we could be shipping it to the client in like 2-4 weeks. I haven’t found anything that comes close to this elsewhere.

But you’re right that the big trade off is jumping off is effectively impossible, because Rails is your app. Most criticism that I see (and feel is valid) is that unless you’re willing to do a whole rewrite you will be on Rails forever. I think this is a more reasonable trade off than I see represented online; “long terms Rails is a nightmare” comes up a lot and I don’t think it’s that bad.

I personally like that we’re seeing options for both strategies here popping up. More options is good for us as devs.

[–] taladar@sh.itjust.works 1 points 7 months ago

As a non-Rails-developer running some apps based on it long-term the most annoying thing about Rails when trying to debug an issue in a code-base that isn't yours is all the auto-magic stuff where the usual way to find the function called doesn't work because it is magically auto-generated in the background somewhere out of strings concatenated together.

load more comments (9 replies)