critique of vibe.d

[Adam D. Ruppe via Digitalmars-d]

On Wednesday, 9 July 2014 at 19:05:54 UTC, w0rp wrote:
> * An ORM, which absolutely must have a way to build queries a 
> piece at a time without writing any SQL, like Django.

I'm skeptical of the benefit of full ORM, but my database.d goes 
to the point I believe is useful with two classes (and a few 
helper functions): DataObject, which allows easy inspection and 
setting of individual items and SelectBuilder which just builds a 
query.

> * A framework for generating all of the SQL required for 
> database migrations like South or the built in migrations in 
> Django 1.7, so you can quickly change any model.

I never did this automatically, I just wrote change files in sql 
myself before taking the RoR job... and personally I think Rails 
migrations aren't all that great, but it is nice that they are 
standardized; I can do the rails g migration here and the boss 
can shoot it up to heroku and it all usually just works.

> * An API for creating form handlers, especially for creating 
> instances of models in the ORM through forms. (Django Form and 
> ModelForm)

see my other email

> * An HTML template system which doesn't eat memory at compile 
> time and where changes can be made while the development server 
> is running.

I've thought about using dom.d at compile time, it now works 
there and could potentially do static checks on html 
well-formedness, broken links, correct field names, etc. But I 
never actually bothered, instead it just loads the file - 
convenient for tweaks by the rest of the team without recompiling 
anyway!

> * Django's automated testing framework lets you test pages with 
> session data and email output, so I have tests for complex 
> things like checkouts which are very easy to write.

I've done nothing like that. I kinda like this thing one of my 
rails coworkers pointed me toward there though called capybara. 
You fetch pages and tell it to click on buttons to do integration 
tests on html. It'd be almost trivial to do that with my cgi.d 
and dom.d - cgi.d already includes simulated requests (for 
command line testing, you run the binary like ./my_server GET 
/foo bar=baz and it runs the program with the given arguments) 
and dom.d can easily click/inspect the output.

But I haven't actually done it.

> * The Django pipeline module provides mechanisms for generating 
> JS and CSS. I now have SCSS which regenerates CSS automatically 
> during development

I've been using scss for the Rails job and I like that it has 
similar functionality to my own css expander (in html.d on my 
misc github, also now as a separate dub package called 
cssexpand), but I can't stand how BRUTALLY slow it is.

Some of the features it offers over cssexpand are kinda cool, but 
if the price is that high, it just isn't worth it. I'll stick to 
my simple nesting expansion and text macro replacement.