Ask HN: Why not build CRUD app generators and be done with it? | Hacker News Reader

Ask HN: Why not build CRUD app generators and be done with it?

16 pointsaviraldg14 comments

Before I start, you should probably know that I'm still a student, and hence I have fairly limited real world experience, so interpret my opinions in that context. :)

----

Ever since I was a kid, I loved making things - origami, board games, "robots", and so on. Naturally, when I first got my hands on a computer, I fell in love with it, just because I could create so many things with it. My personal interest back then, was videogames, so I started with creating simple text based games in BASIC. It wasn't the actual programming that interested me, but just the power, and the excitement of creating something new.

Now, I've picked up most of the major programming languages and I regularly hack on web dev projects. I've noticed that a large majority of websites/apps are simply CRUD apps with minor modifications here and there. Yet, we continue to create such apps manually, thus wasting hours of dev time on something that trivial. I do recognise that this is an obvious oversimplification, but why can't we just build one solid, well-engineered and well tested multiplatform solution for CRUD apps, and get done and over with it?

If I'm correct in my assumption that most developers are motivated not by the code they write, or the architectures they engineer, but the actual effect that those things have (as I mentioned earlier), then wouldn't it be much better for us to create higher level tools for working with CRUD business logic and focus our attention on the actual "hard" problems in CS, like AI, which could have a much greater impact on the world?

Compared to what we used to have to do to write CRUD apps, Rails et al ARE app generators!

Seriously though, my knee jerk reaction was to write all the reasons this couldn't work. But instead, I think you should go ahead and start trying to build it. In the end even if you fail you'll have learned a great deal, and at least have created some code worth turning into libraries.

I was about to respond the same thing - any advanced enough framework (Rails and Grails are the only two I'm familiar with) that supports scaffolding is, in some way, a CRUD generator. In the sense that once you have modelled your domain properly (including what constraints apply to your data) it generates web forms to manipulate your data.

Every app is different. Some apps need the flow to be different. Some apps need different logic and processing for things. Most apps are not just basic CRUD apps.

There are plenty of CRUD generators, but they are basic and just create bare bone CRUD. A lot of programmers don't even use the existing CRUD generators because they do things that aren't wanted.

I spent a lot of time thinking about this too at some point. It can be done but the problem is you don't solve the problem.

Now you have this elaborate tool that's going to get insanely complex if you want to really cover everything. You will be spending your time tweaking the generator's config files and adhering to its restrictions. I only made mine generate code for 1 language too, I couldn't even imagine trying to support multiple languages.

Eventually you're going to monkey patch in so many stupid rules because you run into sites that need something you didn't think of, and then it's going to get into this jumbled mess of insanity that makes you want to kill people whenever you use it.

The solution is to leverage your code editor and create snippets that get you 90% of the way. Now you have the annoying boiler plate out of the way but you have end points and their respective http handlers separate for each resource.

Now if you need something specific it's as simple as editing the resource that needs something specific and you don't have to worry about anything.

You trade in some code duplication for modularity and simplicity. I'm going to make this trade all day, especially when you can eliminate most of the grunt work with snippets in your editor.

You want to maximize productivity?

1. Make some snippets for whatever tech you use.

2. Create an extremely basic project skeleton and put this on github. Then clone it for new projects.

3. ??

4. Profit.

As mentioned by other posters, Rails, Grails and Django all do the job to a certain extend, the hardest part being to gen the UI that is generic enough, yet flexible. Man, hard is not the right word, it is insanely difficult to achieve this goal.

That said, this is what our team set out to do. We just released on github the full client for a new type of CRUD app generator http://github.com/urbien/urbini focused on mobile web apps. Cloud backend is not open source, but is free to use.

Developer creates a Model in Web UI on the phone, tablet or a modern desktop browser, and the app prototype is done. Backbone.js models are generated and are sent to the browser when you point it to your app. Model definitions, templates, views, css, images are saved to appcache and LocalStorage and the data for models are saved to IndexedDB/WebSQL and are automatically synced with the server in background via CRUD. Is that what you had in mind?

Because every app could be different even if they are CRUD. Some factors to consider:

- Business logic

- Workflow

- User interaction

You cannot have a "one size fits all" solution for the above. Hope this answers your question.

Start learning Ruby on Rails. Check out and use the scaffold generators for a bit.

Eventually you'll see for yourself that you can't make the scaffold generators do X, Y, or Z custom requirements yourself and you'll probably drop this notion.

Libraries and frameworks can make repetitive tasks easier, but there's nothing out there yet that's going to write the majority of a non-trivial App for you.

It's a trade-off to some extent. You can have more automation and less customization, less automation and more customization, or somewhere in between. A lot of existing tools for dealing with CRUD apps address a particular set of needs somewhere along that line.

A lot of CRUD apps (especially enterprise ones) are icebergs. From the user's perspective, the application is fairly simple, but there is a ton of business logic behind the scenes. Something like Rails provides an easy way to serve the "real" program on the web.

Contrary to what everyone here seems to think, I've actually used (something like) RoR (Django, to be specific.) Although frameworks simplify the process quite a bit, there's still a lot of stuff that doesn't really need a "proper developer" to do, imho. Again, oversimplifying here, but tbh, aren't a lot of these applications basically "glorified spreadsheets"?

Anyway, I guess I got the title for the post wrong. The main point here is that:

1. CRUD is repetitive.

2. CRUD is boring.

3. Why don't we solve better, harder problems and leave CRUD to the non-programmers?

What stuff are you thinking of specifically? The biggest web time waster to me is the culture of "every site must look unique". Tools like bootstrap mitigate that to an extent, but using them heavily makes your product look amateurish. On the other hand, your application looks and feels amateurish if you don't use Cocoa, or WPF, or Qt/Gtk natively.

Django has generic views for doing CRUD. My experience with them has been that I always, always end up having to replace them with real views due to some not-quite-generic requirement. Every time this happens I think "I'm never going to do that again", but I never seem to learn.

Your assumption is completely wrong in my experience. Most engineers become emotionally attached to their code and architectures. Even if it's probably not useful deleting code can be emotionally trying.

there are frameworks. bootstrap + express + node.js is basically crud app ready to go. any tweaking necessary is done in a day by a good programmer, and that day's reflection is actually important in the long end. the truth of the matter is, creativity matters a lot in code and is often what drives application development in its earliest phases.

Reply on news.ycombinator.com