D For A Web Developer

Jacob Carlborg via Digitalmars-d digitalmars-d at puremagic.com
Wed Apr 30 00:14:33 PDT 2014


On 30/04/14 00:09, Adam D. Ruppe wrote:

> A lot of things, mostly focusing around having the compiler to help
> refactor with confidence (the importance of this really can't be
> understated) and having libraries that fit better.

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.

> The speed is a nice
> bonus too, having to spend half a minute just waiting for the tests to
> run really grates me.

Yeah, it's sucks that Rails is so slow to boot. But unit tests in D suck 
as well. I mean, how do I run a single unit test in D? Also, my text 
editor (TextMate) already has support for the unit tests frameworks used 
in Ruby.

> But wrt libraries, ActiveRecord is unbelievably awful, for example. It
> is a bad idea from the ground up: why, oh why are we reinventing the
> database?

How do you mean? It just adds an object oriented layer on top of it. 
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?

> erb templates are painful to use too

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

> , and so is the routing. I
> don't understand why routing isn't done automatically for the common case.

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.

> The scaffolding is a pain too. Contrast to what web.d does: given a
> function signature, it automatically generates a form for it (using type
> information to select correct widgets) and can format the response in
> several forms automatically including plain text, html list, html table,
> json, xml, csv, and a custom template.

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

class FoosController < ApplicationController
   respond_to :json, :xml

   def index
     respond_with Foo.all
   end
end

> Maybe Rails can do this stuff and I'm too much of a n00b, but the other
> experienced team members say the way we're doing it is pretty standard
> and I'm just not impressed.

Sure, it depends on what's "standard". Only using what's installed by 
default. Then yes, perhaps that's standard. But it's not always the best 
idea. At my previous work I did quite a lot different compared to the 
"experienced" team members.

> I can just get stuff done in D in a fraction of a time it takes to do
> even less in RoR.

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.

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

[1] https://github.com/plataformatec/simple_form

-- 
/Jacob Carlborg


More information about the Digitalmars-d mailing list