On Sat, 2014-05-31 at 19:49 +0000, w0rp via Digitalmars-d 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/
I have to admit my initial reaction on seeing this was: oh no not another bland "me too" Angular/Ember/Drupal style three-column, client-side, flat menu system more or less like every other new site created because that is the fashionable style of the moment. On the other hand others like it so, go with it. For me the issue is branding. Whatever it's faults, the current dlang.org does have a unique style to it. I think having humour on the site is a good thing, cf. the D figure on dlang.org. It would be good to do more with the D figure, or some other mascot. Java has Duke, Go has the gopher, there is a lot of mileage in having such a character, not only for the website, but also for presentations. Having a mascot that can be used for humour helps massively. When Sun controlled Duke it was all a bit tedious, once the mascot was released, many people created many variants leading to an extremely useful tool for enlivening presentations. > 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.) Seems entirely reasonable in the context :-) In fact it would be worth ensuring this fact is front and centre so that anyone alighting on the site knows it is vibe.d, i.e. D, powered. > * 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. Go has the Go playground rather than trying to create a REPL per se (cf. http://golang.org/). Despite the fashion for REPLs, I find them irritating. I am much more in favour of a tiny lightweight edit and a fast compile/execution of the editor content. Another example of this is IPython notebooks. Python and IPython have REPLs, which have their uses, but the IPython notebooks are modern literate programming. Well actually their main use is for writing documents (especially scientific papers to be shipped) that include executable code. It is an idea that has totally won over many in bioinformatics, HPC, and data sciences in general. It wouldn't surprise me if Go could do something similar in the near future. > * The logo is something I quickly put together with InkScape. > Look at it as "please insert better logo here." Just use the logo from dlang.org? It is effectively, and possibly actually, the official logo. > 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. Not so bad for releases, but terrible for development. Grails and Django go to great lengths to ensure that the development environment is entirely local to the development machine and has dynamic, and fast, update of all content. So as soon as you write back a file to the filestore the development server gets notified and reloads the site as needed. This makes for very fast evolution of things — but I am probably "teaching grandmother to such eggs" here. > 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. I can attest to the pain of a system that takes 5s or 6s to refresh, it becomes horribly painful. To the extent of giving up and switching infrastructure. > 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. Isn't the problem here that you are having to deploy in order to develop? Maybe I am just missing something, but it sounds as though there isn't actually a development workflow, just a create and release one. > 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? The Go website has it's faults, but it has a lot of good stuff, analogues of which would be well worth considering for a revised dlang.org. dlang.org may be a bit static and not of the currently fashionable style, but it has a brand image. -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
