Kozo – Stop writing boilerplate and start building products | Hacker News Reader

Kozo – Stop writing boilerplate and start building products

kozo.io

51 pointsgfmio19 comments

Signed up, I think this is an interesting and long overdue idea. Let's see if this shot works.

Truth is there are a ton of CRUD apps out there, that are 80% boilerplate in reality, it's just different boilerplate. I know HN tends to focus more on startups and bleeding edge hobbyists but enterprise CRUD is what drives software development, and creates most of our checks. And we can still do much better.

Whoever can come up with an elegant, fast, stable solution to crack out CRUD apps and not make all the mistakes of the past attempts can revolutionize things.

In my opinion the LAMP stack did this great for a time. Rails does a pretty good job now. The .Net framework also does this very well, at a cost. It's not sexy, hip or cutting edge but there's a big demand for it.

You want to talk about a very unsexy way to build CRUD apps fast, go look at Salesforce. Boy, do I hate developing on their platform, but it is a pretty damn quick way to build CRUD apps, as long as you're fine paying $100 per user per month.

And if you want something open source which you can install on your own machines, Odoo[1] is a nice alternative (disclaimer: I work for a partner company). It works in a similar way; you just define the model with its fields (as a Python class), add a view where you just indicate which fields to expose and where, and then a menu entry to point to that model, and done! You can even skip the view if you don't mind it generating a basic one for you.

[1] https://www.odoo.com/

That is a remarkable suite of tools available, and all for free. I'm surprised I haven't heard of it before, but I'll certainly be looking into it. Thanks for the tip!

Absolutely. I even think this, or something like it, will catch on in enterprise development shops for those fringe projects that are done in like a week. Especially if it can be deployed on the same tech stack as that other random thing we built. We use ASP.NET MVC for a lot of this stuff, which combined with ADO.NET and SignalR and a good JS framework, gets you 75% of the way there.

I will tell you what I would like it to be. Maybe it gives you a Visual Studio-style editor for websites, which let you easily lay out a page, edit CSS, add event handlers to elements, link to other pages, and make and use data bindings (which could be configurable: persistent to DB, associated with user account, validated with this function, etc.)

Then you could use the data model created by the bindings, modify it if you want (data model specification is probably integral to everything), add and configure whatever extra stuff is supported (accounts, websockets, whatever).

A cross between Weebly and Visual Studio. It would be great for demo apps and internal utilities.

This is quite accurately describing what we're trying to do on the front-end side. :) In addition to just creating RESTful APIs and backend and persistence code, we allow you to design your UI in a GUI (or using code). Views are data-driven, so you can essentially bind data from your models using drag&drop (or in code). However, instead of just using XY positioning, we focus on relative positioning of subviews (representing lower level parts of your application) to create working, well-designed interfaces (again, based on your design settings/parameters).

Visual Studio Lightswitch is a thing, included in Visual Studio 2012 Professional onwards. It's essentially a tool for building a database (or interfacing to an external one) and putting a CRUD UI on top of it, while it allows for extending it with real code nearly everywhere. It also integrates into other enterprise-y stuff, supposedly.

The issue is... you're stuck with Lightswitch once you start using it. There's not an "export to standalone C# project" button, I believe; you'll always be dependent on the Lightswitch libraries, which Microsoft will probably decide to drop or radically change in the future, at least before .Net itself is dropped.

And that's going to be sort of the problem with all these systems. Unless it can output pure, maintainable C# code (or whatever else), not dependent on significant libraries specific to the RAD toolkit, there's a very high risk that the toolkit and libraries become unsupported well before the application stops being used.

This looks interesting. Am I correct in understanding from your diagram that Kozo generates both the clientside and backend code? In what language does the developer write? Another question: how much control does the developer have over the server once the application is deployed?

Thanks for any response and good luck with this project!

My understanding is that you "describe" your project using XML or JSON or code (which can be written against libraries in "the language of your choice"). Then, Kozo spits out a skeleton project based on that description in the tech stack of your choice.

So, you would (optionally) write code in unspecified languages to describe your project, and then you would have to actually finish the skeleton project, of course.

That's already quite accurate. However, you can also bind against external APIs and deploy Docker applications to fill the skeleton application.

The structure can be written in a JSON or XML format or alternatively be constructed using one of our libs, which are planned to be written in D, Python, Java, Ruby, PHP and possibly/almost certainly others.

We generate client & server side code and you can get the source code out in one of the supported stacks. Alternatively, we can host for you on a scalable stack, so you wouldn't need to care about setting up your own environments. If you deploy on your own stack, you obviously can have full control, if you deploy with us, we'll provide a number of configuration options, but generally it's a compiled server app running on a auto-scaling stack.

FWIW, I think this is a really cool idea. When I was trying to imagine use cases, most of them involved a project being generated on only one stack. Mobile apps are the only exception I can think of. Do you expect that most people will only generate their project once, on a single stack?

Right now, mobile seems to be the "exception". However, when you're thinking of other, "less common" stacks, like cloud-based Desktop applications or Browser extensions, new use cases become evident.

Furthermore, we're getting more and more stacks right now, such as wearables and sooner or later AR/VR devices/platforms - hence, the need for such as cross-platform tool will certainly increase. Plus, we also make developing single stack apps easier/less painful, so even then it will (hopefully ;) ) be helpful for people.

I certainly would like to get rid of boilerplate.

What kind of platforms do you plan to support? Any specific frameworks like Django or maybe Symfony/Laravel or Express.js?

Also, do you have plans to support stuff like social connect/OAuth authentication? So that you can specify that you want it, include required API IDs/Keys and any other required config and be done with it?

We abstract away platform differences, so we only need to write translators for different software stacks. Python with Flask/Django and PHP with Slim/Symfony/Laravel are definitely on our list.

We also offer bindings to external APIs, including OAuth. Storing IDs depends on your config, but could be done in data or session storage.

Cool, thanks!

I'm actually working on a similar project that'll I'll be releasing in a month or so. It's similar in that you spec out a schema and some access control, which it hands off to processors that can generate code (db definition or ORM code).

It'll be released as GPlv3 and I would welcome any additional processors for other platforms.

Here is a similar one

www.wavemaker.com/

and this

visualwebgui.com/

Trying to sign up for the beta, getting an HTTP 400.

Issue fixed ;)

Reply on news.ycombinator.com