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

Show HN: Avo – Build Ruby on Rails apps faster

avohq.io

Post reply on HN
Print view View original

151–160 of 171 posts

Re: Show HN: Avo – Build Ruby on Rails apps faster

#151

Post by adrianthedev »

boxed wrote: post #129

I found the video to be dishonest. "Watch Adrian build a booking app in less than an hour" is the title but if you actually watch any part it's clear that it's at best going at 2x the speed. Probably more like 10x honestly.

The real-time building of the app was an hour and 10 minutes. I posted a screenshot with the recording below. That recording contains also some setup on my part, it's not just actual coding on the app.

https://share.cleanshot.com/hPUskT

The 10x speed-ups were actually data-entry which definitely nobody wants to see in real-time or would benefit from.

The 2x-3x speed-ups were for the generators and slow typing speeds.

I know the tendency is to exaggerate things, but I'm not for that. I like honesty because it's not complicated. When one lies they have to keep that in memory for the next time :P

So yeah, the video is sped up, but the message is correct.

Re: Show HN: Avo – Build Ruby on Rails apps faster

#152

Post by adrianthedev »

JamesBrooks wrote: post #134

Looks like it fits a similar bill to many existing rails admin frameworks, e.g. https://trestle.io/

Yes, they intersect in features.

The barrier that I'm trying to break and push through is that the result is not a hidden away admin panel where only a small number of core team members go to update some record. The result is a beautiful consumer-ready interface that you give to your user.

Avo is your app. Not a part of your app. Avo is the UI your users see when they go and interact with it.

Thank you for the message.

Re: Show HN: Avo – Build Ruby on Rails apps faster

#153

Post by gls2ro »

boxed wrote: post #129

I found the video to be dishonest. "Watch Adrian build a booking app in less than an hour" is the title but if you actually watch any part it's clear that it's at best going at 2x the speed. Probably more like 10x honestly.

I don't understand your assertion here:

If it is about the video on the homepage of the product, I just check it as it is a video with a total length of 15 minutes.

It includes also an explanation of the problem he tries to solve. I really don't find it dishonest.

I am not sure what speed is the code writing presented (could be 2x like you say) but really for me, it feels like knowing how to use Avo one could write that code in under 1 hour.

Re: Show HN: Avo – Build Ruby on Rails apps faster

#154

Post by mattbrewsbytes »

adrianthedev wrote: post #98
mattbrewsbytes wrote: post #92

For something like this, I bet a chunk of your target market for "Pro" level is people running ActiveAdmin. The beauty (and nightmare) of ActiveAdmin is it just looks at your tables and gives you an admin UI. If you have a mostly API based app, this can be great to give internal people some power tools so they leave the engineers alone. Would love to see demos with real world complexity level of things instead of the…

I would say that the Community version (free) covers most of what Active Admin does. The search is paid with Avo (and included in AA). The Pro users are those who need to build upon Avo. They need custom content (fields, resource tools, custom pages), and they need to make it look the same as the rest of the app. Avo provides view components that help with that. This way you create a seamless UI for your users. I thi…

Multi-tenancy brings a lot of complexity and multiple integrations with various API's also brings that. One of the large barriers for an app that's UI is internal use only is convincing others that we need to spend time on moving away from Active Admin. Its hard to justify.

Down the road if you get into wanting to address internal admin panels in these situations, one idea might be to write a mapper/importer to take active admin DSL code and convert it to similar-ish Avo code. Basic index/show and filter/search pages are like 80% of the use cases and minimizing the amount of time to convert might help you win customers.

Also don't take my comments about UI customization as a critique on the UI, Avo looks awesome. Its just that some organizations (possibly larger orgs) have UI standards defined and making it look like other internal apps is a must have.

Re: Show HN: Avo – Build Ruby on Rails apps faster

#155

Post by adrianthedev »

bradgessler wrote: post #123

It's great to see folks building frameworks on top of frameworks. I've started to look into full stack starter-kit frameworks that goes beyond the admin panel and here's what's out there these days. * https://bullettrain.co - Opensource, $0/year * https://jumpstartrails.com - Opencore, $249/year * https://www.bootrails.com - Closed source, ~$83/year I've even started to piece on together for my own projects at https:…

Yes, it's nice to see the ecosystem go green again. I love Rails and I want it to flourish.

I think bullettrain.co is open core as well. They haven't announce the pricing for the subscriptions packages yet, but I can't wait to see what they come out with.

Regarding "settled libraries", I am all for that. I'd rather have conventions all over and know that devise is on every app, but the truth is that each app is different and has different requirements. That's why Avo is deisgned to work with multiple libaries.

Good luck with monolith and let me know if I can help. I think having Avo in monolith and other similar projects would contribute on that "settled libraries" convention.

Re: Show HN: Avo – Build Ruby on Rails apps faster

#157

Post by adrianthedev »

adrianthedev wrote: post #156
strzibny wrote: post #150

Earlier quoted context omitted.

And earning money with it!

I sometimes think Rails is one of the best kept dev productivity secrets out there. Let the doubters doubt...

As a disclaimer, I've done PHP (WP, Laravel, custom), Javascript (Node, JS, TS, back-end, front-end, full-stack) and Ruby, so I'm speaking from my experience.

Re: Show HN: Avo – Build Ruby on Rails apps faster

#158

Post by adrianthedev »

strzibny wrote: post #148
bradgessler wrote: post #123

It's great to see folks building frameworks on top of frameworks. I've started to look into full stack starter-kit frameworks that goes beyond the admin panel and here's what's out there these days. * https://bullettrain.co - Opensource, $0/year * https://jumpstartrails.com - Opencore, $249/year * https://www.bootrails.com - Closed source, ~$83/year I've even started to piece on together for my own projects at https:…

There is now also mine in alpha https://businessclasskit.com/ focused on Rails defaults (Active Storage, Minitest, ...) with Paddle (important for Europeans to skip on dealing with EU taxes).

The more the merrier! I haven't tried it yet but I'm stoked there's movement around it. I love the "Rails defaults" convention. I do the same with Avo.

One problem I had with Paddle is that they haven't accepted me in their program. It would be cool if you'd be able to create some kind of partnership and fasttrack that process somehow.

Good luck!

Re: Show HN: Avo – Build Ruby on Rails apps faster

#159

Post by adrianthedev »

mattbrewsbytes wrote: post #154
adrianthedev wrote: post #98

Earlier quoted context omitted.

I would say that the Community version (free) covers most of what Active Admin does. The search is paid with Avo (and included in AA). The Pro users are those who need to build upon Avo. They need custom content (fields, resource tools, custom pages), and they need to make it look the same as the rest of the app. Avo provides view components that help with that. This way you create a seamless UI for your users. I thi…

Multi-tenancy brings a lot of complexity and multiple integrations with various API's also brings that. One of the large barriers for an app that's UI is internal use only is convincing others that we need to spend time on moving away from Active Admin. Its hard to justify. Down the road if you get into wanting to address internal admin panels in these situations, one idea might be to write a mapper/importer to take…

The Active Admin to Avo converter sounds like a good idea, and I'll wait until I hear about this request from more users. I use my time where the users need me to use it.

Oh, yeah. No offense taken. Thank you for the compliment!

Re: Show HN: Avo – Build Ruby on Rails apps faster

#160

Post by adrianthedev »

pelagicAustral wrote: post #131
vladcodes wrote: post #103

Earlier quoted context omitted.

> "oh, you made an admin panel. I could build that in a few hours. we don't need it." and they never do. I was never saying making anything with any technology is easy. Developing with plain Rails and a minimum of gems is linearly difficult while developing with a set of DSL/generators like Avo can lead to a complexity spike from 1 to 11 in no time. And the worst thing — at a random stage of development. From the bus…

I wholeheartedly agree with this post. I have used/tried every admin panel creator gem under the sun. Or other 'quickstart' products out there such as Jumpstart. Other than that there has been several efforts to make admin panels for rapid app creation that come with some CSS flavor. And always end up hitting the same ceiling, that one feature that cannot be created due to DLS limitations or whatever, and then its al…

I believe that no tool is perfect. Not even Rails. We reach for other gems and sometimes do things not "the Rails way" and we get the job done.

And there's a fallacy there. We don't go saying "Rails doesn't do everything I need it to do, so I'd rather spend more time to write my framework from scratch". But we're (and I'm including myself too) very quick to say things like that about certain tools just because "it's never been done before", "Nobody uses an off-the-shelf package to build their app on", "I'll hit a ceiling with it...", and so on.

Yes, Avo isn't perfect, and yes, Avo isn't right for any kind of project. There are some that are more suited and some that aren't. Sometimes you might hit a "ceiling" with Avo, but I baked in a ton of "escape hatches" (add own content on multiple levels, override views, override controllers, multiple ways of interacting with the data, Stimulus JS). Using these "escape hatches" (I gotta stop using that term), will help you get the job done.

This message is not fingepointing towards you or anyone else, and I respect everyone's way of doing things, but we should take some time and reflect on that. We don't go and build linuxes, nginxes, pumas, railses and other pieces of tooling everytime beacause we might get stuck at one point. We make it work. Same should apply with pieces of software like Avo.

Thank you for the message!

Post reply on HN