D For A Web Developer

[Adam D. Ruppe via Digitalmars-d]

On Wednesday, 30 April 2014 at 07:14:34 UTC, Jacob Carlborg wrote:
> I think one of the great things about Rails and Ruby is all the 
> libraries and plugins that are available. If I want to do 
> something, in RoR there's a big chance there's already a 
> library for that. In D, there's a big chance I need to 
> implement it myself.

I like implementing things myself :P

That's the question I dread most at meetings now: "is there a gem 
for this?" idk, in the time it takes to search for and evaluate 
third party code, I could have just written it myself. Especially 
since libraries almost always need some kind of customization for 
our specific case anyway!

There's a few exceptions where something is hard to write, but 
most things just aren't that hard.


> But unit tests in D suck as well.

A big difference though is the compiler helps you a lot in D. In 
Ruby, for example, the main reason we use the unit tests (so far) 
is to help ensure consistency after refactoring something. It 
catchings things like a renaming we missed, or a removed method 
still in use.

In D, you just recompile and those things are found almost 
instantly without needing to actually run any code.

> How do you mean? It just adds an object oriented layer on top 
> of it.

They deliberately avoid the most important parts of a relational 
database:

http://guides.rubyonrails.org/migrations.html

"The Active Record way claims that intelligence belongs in your 
models, not in the database. As such, features such as triggers 
or foreign key constraints, which push some of that intelligence 
back into the database, are not heavily used."

ORM is something I only like in very small quantities, but 
ActiveRecord uses it for *everything*, well, except for the 
things it doesn't even support.

The problem here is one of encapsulation and of correctness. If 
something bypasses the model - which is required for tasks the 
library doesn't even support and also likely to happen if there's 
a second app using the data - all kinds of stuff can get in there 
that is bad.

You also have problems like race conditions:

account = BankAccount.find(1)
account.balance -= 10
account.save!

What if two of those run concurrently? I searched the web quickly 
for this and haven't found a good answer yet...

Then, with referential integrity, the docs suggest DIY or getting 
some third party gem, because their godawful library doesn't 
really support it. The best it does is offer you a square wheel 
with the dependent thing. Stupid stupid stupid.


When you actually use the database as it is intended, it takes 
care of these things for you with very easy syntax that works 
across business logic languages. Nothing new to learn there.


> BTW, what should I use in D. I need a library that is database 
> independent and I don't want to write SQL for the common use 
> cases?

idk, I use my database.d which has a little bit of overlap with 
what active record does, but since I generally see ORM as being a 
nasty anti-pattern and horribly leaky abstraction, I didn't go 
far with it.

There's really nothing to fear with writing SQL, except the cases 
where the language sucks. (UPDATE and INSERT being so different, 
and the solutions being different for the various vendors, ugh. 
That's why I made my DataObject, it gathers the changes together 
then issues one of those commands. It can also be gotten from a 
query, making it a kind of simple active record:

auto obj = mysql.queryDataObject("select * from foo limit 
1").front;
obj.whatever = "something";
obj.commitChanges(); // calls UPDATE foo SET whatever='something' 
WHERE id = ?

which also works on joined queries on MySQL btw and offers easy 
support for multiple primary keys or ones not named "id" (as an 
argument to commitChanges), something active record as far as i 
can tell doesn't even try to do, but it doesn't try to fetch 
child objects or anything like that.

I have considered adding child object fetching, but I don't 
really see the need, it is easy to write a method that does that 
if you want to.)

> I prefer HAML (similar to Jade in vibe.d) but I don't think 
> it's that bad. What do you use?

The ruby thing looks like this <span class="foo"><%= @some_value 
%></span>.

For my D stuff, I have two options:

1) create the HTML right in D using dom.d. I like to use this for 
objects that know how to format themselves and output strictly 
semantic XML/HTML. The visual styling is then done with CSS. This 
works better than you might expect!

2) web.d also has a fairly simple replacement system too:

<span class="foo">{$some_value}</span>

it also supports inserting partials

<div html-from="{$dynamic_html}"></div> or <include partial="foo" 
/>, though the include thing takes a wee bit of helper code from 
the app because it needs to find the html somewhere.

And the variable replacement can be piped: {$some_count|plural 
user users} for example, which is kinda cool.

It does NOT support intertwined code. Other things are done with 
attributes, such as class="if-logged-in" or <ul from="data_thing" 
/> (infinitely extensible with the server-side DOM).

> I don't know how you do you're routing but the first thing I do 
> when generating a new Rails application is to remove the 
> default routing. The default routing opens every public method 
> in a controller to be a routing end point. It's a complete mess.

It looks like this

   root "home#index"

   get "/users/login", to: "users#login"

   namespace :admin do
     resources :users do
       resources :children
     end
   end


and so on. It isn't awful (especially now that I get what they 
mean by "resources"), but my web.d rarely uses explicit routing 
at all, it figures it out automatically by the names, protection 
level, and types of child members.


> There's a plugin [1] for Rails for generating a form based on a 
> type. I don't understand how anyone can manage without that.

thx, I'll take a gander.

> It can automatically respond in a couple of formats as well. By 
> default JSON, XML and Erb template. The most basic example will 
> look something like this:

Responding with json, xml, and html Just Work with web.d, it 
figures it out from the static type of the function return value.

> You don't think that's because you're used D for quite a while 
> and developed your own web framework. Compared to Rails where 
> you're completely new.

Yes, obviously that's some of it, but there's other things that I 
don't expect to change, especially things like runtime errors for 
what the D compiler would catch.

I had to rename a thing last night. Took two hours to do the db 
migrations and then rename the classes and update all the files. 
I'm still not completely sure I did it right too! I've done 
similar things in D in about 5 minutes, the compiler catches 
everything so I have confidence.

> The biggest problem I have with D is have to do everything 
> myself. I'm getting a bit tired of that.

i love that, different strokes i guess.