Redesign of dlang.org
w0rp via Digitalmars-d
digitalmars-d at puremagic.com
Sat May 31 12:49:20 PDT 2014
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.
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 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'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?
More information about the Digitalmars-d
mailing list