Redesign of dlang.org

[Rikki Cattermole via Digitalmars-d]

On 1/06/2014 7:49 a.m., w0rp wrote:
> After watching Andrei's keynote where he was asking for help, and
> noticing that there wasn't any proof of someone working on this, I took
> charge.
>
> http://w0rp.com:8010/
>
> That's the design in the form of a single page website running on my
> Linode. The source is available here.
>
> https://github.com/w0rp/new-dlang.org
>
> I would like to keep going with this and just redesign the whole
> website. A few points worth noting.
>
> * This is entirely a vibe.d website. (See the source.)
> * For pages, DDoc is replaced with diet templates.
> * I would still use ddox for generating library documentation.
> * The page is mostly held together with Bootstrap, which is very good.
> * The page is most of the way to being responsive (design sense), as it
> should be.
> * The module in the middle is missing, I'd use some future version of
> Nowak's drepl and put a REPL right there on the front page.
> * The logo is something I quickly put together with InkScape. Look at it
> as "please insert better logo here."
>
> I encourage the use of diet over DDoc because it is simpler to insert
> dynamic content in the page, especially so for vibe.d. The support for
> doing conditional things or loops based on any dynamic content we can
> think of is right there in vibe.d.

+1

> Now unfortunately, I have two major complaints, for vibe.d and D itself.
>
> For vibe.d, I can't think of a way to make changes to diet templates
> without recompiling the whole site. This doesn't seem so bad, given that
> compilation speed is very fast, but it builds up. This is because the
> process of experimenting with HTML becomes.
>
> 1. Make a change.
> 2. Recompile the whole program in a matter of seconds.
> 3. Refresh the browser window.
>
> Those seconds in between making a change and seeing the results really
> build up over time. It's probably hard to describe without trying it
> yourself, but trust me, it matters. This is the kind of thing I have
> recently fought against at work, and it was well worth it. I replaced a
> Compass filesystem monitor with an even slightly broken libsass CPython
> compiler which compiled SCSS based on modification times. The couple
> seconds of difference has definitely improved the day-to-day life of
> myself and the web designer I work with.
>
> This could be avoided if there was perhaps a way to rebuild diet
> templates at runtime. This could be enabled only for debug builds. So
> you could quickly make changes during development, and then compile
> everything statically for maximum speed for production.

The problem with diet is it compiles directly to D code, hence forth its 
not really possible at the moment.
However as I believe Sonke has said previous it is out of scope of Vibe. 
Its actually in the scope of Cmsed instead.

I have looked into doing just this, reloading of templates. And from 
what I can ascertain reliably we need shared library support. While this 
is doable upon Linux, it isn't on Windows. Until its available on 
Windows I will not use it.

My thread on the dub forum is here[0].
Basically I am also blocked by dub, to be able to grab all the previous 
templates ext. From libraries and push them into a findable place at 
runtime.

> The complaint I have for D is that too much memory is consumed for
> building D programs. The memory usage made it impossible for me to build
> the vibe.d site on my Linode, which the site above linked is running off
> of. The only way I was able to get the site to run on my Debian Wheezy
> server was to install a bunch of libraries from Debian testing, compile
> the program on my Arch Linux desktop, and then upload and run it on my
> server.

I personally allow for atleast 1.5 to 2gb of ram to build anything with 
D. Cmsed base package alone takes around 700mb. And thats with a LOT of 
CTFE work going on. I can only see that increasing.
So I'd like a way for dmd to utilize memory better even if it means 
slowing down for larger builds. For small builds the current way is 
great, just for larger we need alternative means.

> I'm not sure how to fix the issue myself, but something should be done
> to address this kind of issue. My Linode box has about 1GB of RAM with
> about 800MB free typically. Maybe I could have gotten things to build by
> increasing my swap space a little, I'm not sure.
>
> So, what does everyone else think?

Definitely looks nicer. But I must say it does feel a little clunky in 
some places (although don't ask how to fix, I don't know how to myself).

[0] 
http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/1404/