critique of vibe.d

[Jacob Carlborg via Digitalmars-d]

On 2014-07-10 15:53, Adam D. Ruppe wrote:

> 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.

And they are database independent, mostly.

> 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.

Capybara is more for user acceptances tests. Rails has other kinds of 
tests that are a bit lower for integration tests. But the line is thin.

> 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.

It depends. Capybara is only a high level API. It supports multiple 
drivers: Rack Test (the default one), Selenium, PhantomJS and others. 
Rack Test is the most simple one but also the fastest. PhantomJS is a 
completely headless driver which uses WebKit. Selenium is the most 
flexible one. By default it's not headless and uses Firefox. But it can 
be configured, using some kind of hub, to support multiple browsers and 
headless as well. The major advantage of PhantomJS and  Selenium is that 
they're release browsers and supports JavaScript.

> 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.

That's heavily dependent on how large project you have, how much Sass 
you've got. Preprocessing with Ruby as well will be slower.

Just a side note, the assets pipeline is extremely slow in a VirtualBox 
compared to a native machine. We had some problems with that at my 
previous work. Apparently the assets pipeline needs to access a lot of 
files on disk, and each access took around a second.

-- 
/Jacob Carlborg