On Tuesday, 16 July 2013 at 20:10:15 UTC, Val Markovic wrote:
> Having hyphenator.js on the site slows down the browsing experience
> immensely, especially on mobile. I know I personally avoid the
> dlang.orgsite on my Galaxy Nexus and on my Nexus 7 because of this
> reason.
>
> Since the whole web is right-aligned and users would much rather have a
> site that loads fast and without content flashes than a site with
> hyphenation, I believe the library should be removed.
>
> I say this as someone who is a typography nut and loves hyphenation. A
> printed book without it is not worth buying. But the cost of implementing
> it in JS for web pages is too high. There's a reason why no major website
> uses this approach.
>

Hyphenation is ok, but it's way over-eager on dlang.org

I have my thesis in front of me (LaTeXe) and there's roughly one hyphenation (is that even the right word?) per page, clever spacing manages the rest to get fully justified text. dlang.org/index.html has 26 full-width lines and 10 are hypenated! Even if you like hyphenation, that's just bad typesetting.

hyphenate.js needs to go. It's far too slow and the results aren't very good.

On Monday, 15 July 2013 at 13:12:38 UTC, Ary Borenszweig wrote:
>
> You can also try GitHub pages. And since D already has its code in github it's very simple.
>
> http://pages.github.com/
>

I would advise against, since this creates a strong dependency on github.  Currently the community would be able to move to another git hosting setup without code changes (at least not significant ones, AFAIK).  Moving the website to a web-service-provider-specific language would create vendor lock-in.

On Monday, 15 July 2013 at 06:53:37 UTC, Jacob Carlborg wrote:
> On 2013-07-14 23:18, Val Markovic wrote:
>
>> 3. Ruby on Rails (or Django or any other web framework that dynamically
>> builds a server response) would be a terrible choice for a static
>> website. It would be nothing but overhead for no benefit. Nothing on
>> dlang.org <http://dlang.org> is dynamically generated, nothing talks to
>> a database (nor should it). The site can and should be generated from
>> some simple markup language. The end result should be HTML, CSS, JS and
>> image files that are then just served by the simplest of servers.
>
> Why not? We're limiting our self here. Someone talked about adding comments to the documentation, like PHP has. Or do you want to use a database that JavaScript can talk to directly, to avoid server side scripts?

Please no RoR/PHP/JavaScript/etc.  It's already hard enough to contribute to this thing as it is.  These would add a bunch of dependencies for little gain, and possibly a bunch of alienation.

As a user, I really don't want my browsing experience slowed down by that stuff either.

I could maybe see using D+vibe.d, but only because it wouldn't introduce a new ecosystem of languages/tools.  It's also based on D and should be reasonably fast (and if it isn't: something failed; start over).

<rambling>
I think what really needs to be addressed though is the build system, checkout process, and maintainer's documentation (ex: README).  I've experienced a lot of contribution difficulty too.  It makes the whole thing not-fun and strongly encourages me to do other things.  I remember watching Wyatt hack on the docs and then ran a build script that initiated some kind of pull/clone/whatever-I-forget-exactly from the main repo (yuck).  It seems like most of the meaty bits are there, but it all needs to get adjusted according to the experiences of (potential) contributors.

The github editing interface helps, but is only really effective for very small changes that I know will work.  It requires generating a pull request before I see what the published result will look like.  I really need to be able to see doc changes /easily/.

I've always been attended to quickly during the few pull requests I made, though there seem to be some important ones (from other people) that slip through the cracks.  I find out about those later when I read the newsgroup.  I just hope that Walter & Co will notice this happening and know what to do about it.

FWIW, I was able to pick up and understand ddoc very quickly.  It is awesome for docs (you know, that thing it was made for).  I also love the idea of generating webpages from my source code: as long as it's API docs.  I don't think this necessarily means it should be used for web dev.  At the same time, when web developers offer alternative tools, my gag reflexes tend to kick in.  Maybe we can solicit the web developers for tool advice and pick the things that don't make people gag?  Maybe my imagination lives in a perfect world.

I hope this is constructive enough.
(In reality I probably just pissed off a bunch of dynamically-typed-language-loving scripty web programmers.  Oh crap! *ducks*)
</rambling>

On Wednesday, 17 July 2013 at 07:46:28 UTC, Chad Joan wrote:
>
> FWIW, I was able to pick up and understand ddoc very quickly.  It is awesome for docs (you know, that thing it was made for).  I also love the idea of generating webpages from my source code: as long as it's API docs.  I don't think this necessarily means it should be used for web dev.  At the same time, when web developers offer alternative tools, my gag reflexes tend to kick in.  Maybe we can solicit the web developers for tool advice and pick the things that don't make people gag?  Maybe my imagination lives in a perfect world.
>

This is too harsh, even if I did mean it in a tongue-in-cheek way when I wrote it.  I apologize.

Up too late I guess.

On 2013-07-17 09:46, Chad Joan wrote:

> Please no RoR/PHP/JavaScript/etc.  It's already hard enough to
> contribute to this thing as it is.  These would add a bunch of
> dependencies for little gain, and possibly a bunch of alienation.

Yes, it adds dependencies but it's easy to use and is well documented.

> FWIW, I was able to pick up and understand ddoc very quickly.  It is
> awesome for docs (you know, that thing it was made for).  I also love
> the idea of generating webpages from my source code: as long as it's API
> docs.  I don't think this necessarily means it should be used for web
> dev.  At the same time, when web developers offer alternative tools, my
> gag reflexes tend to kick in.  Maybe we can solicit the web developers
> for tool advice and pick the things that don't make people gag?  Maybe
> my imagination lives in a perfect world.

Ddoc isn't hard to use, it's too limited in what it can do. What is hard is everything around it, like building and so on, as you mentioned. With a big web development framework, like Rails, it's well documented.

I certainly don't think ddoc should be use for web development. I would never create a site with ddoc. It's too limited in what it can do.

-- 
/Jacob Carlborg

On 07/17/2013 05:22 AM, Jacob Carlborg wrote:> On 2013-07-17 09:46, Chad Joan wrote:
> 
>...
> 
> Ddoc isn't hard to use, it's too limited in what it can do. What is hard is everything around it, like building and so on, as you mentioned. With a big web development framework, like Rails, it's well documented.
> 

Since ddoc is used for documentation, then I think it should be made as easy to build as possible.  This seems like a packaging issue.  I'm usually more concerned with documentation fixup myself, and documentation fixup is a pain in the butt if the build process isn't "run command X, then open your browser to Y".

> I certainly don't think ddoc should be use for web development. I would never create a site with ddoc. It's too limited in what it can do.
> 

Reasonable enough.  I easily can see how this would be the case.

I still hope that the D site will be mostly static.  I can see use cases in some exceptions (like user comments on various things, and maybe news pulling), but I feel like those should load as close to static as possible, and otherwise not block the experience if I happen to have adblock/noscript/etcetc all running at full burn.  I think our forum software is a good example of Doing It Right.

On 07/14/2013 05:19 AM, Val Markovic wrote:
>  2. Looking at the Network data in the Chrome DevTools, realize the site
>     isn't using a CDN. Make a note of mentioning this to the site
>     maintainers; using a CDN is critical to performance and ever since
>     CloudFlare came on the scene (fast & free CDN that's also trivial to
>     set up) there's no excuse not to use one.
Yes, I get 40kB/s download rate and it takes 4s to load an uncompressed HTML file.
Compressing http://dlang.org/phobos/std_algorithm.html could save 139.9KiB (82% reduction).

>  4. Record a JavaScript profile of the site with the DevTools JS
>     profiler and the new Flame view. With this information and the
>     Timeline profile, realize that hypenate.js is probably the culprit
>     of the content flash bug. Still have to verify this, it might be
>     something else.
I takes more than 1s to run and is the dominating time waster.
https://github.com/D-Programming-Language/dlang.org/pull/352

Didn't see hypenation on the web before, looks alien to me. From the typesetting point of view I find manpages with a larger font pleasure to read.
http://man7.org/linux/man-pages/man3/fclose.3.html
They are neither justified nor hyphenated.

On Mon, Jul 22, 2013 at 09:59:57PM +0200, Kagamin wrote:
> Didn't see hypenation on the web before, looks alien to me. From the
> typesetting point of view I find manpages with a larger font
> pleasure to read.
> http://man7.org/linux/man-pages/man3/fclose.3.html
> They are neither justified nor hyphenated.

Exactly. While justification/hyphenation are nice to have, they are really only peripheral benefits. We should not be paying such a big price for them. I really have a hard time understanding the rationale behind trying to make hyphenation work, when the time could be much better spent improving the D docs that newbies keep complaining about.


T

-- 
This sentence is false.

On Monday, 22 July 2013 at 20:49:09 UTC, H. S. Teoh wrote:
> On Mon, Jul 22, 2013 at 09:59:57PM +0200, Kagamin wrote:
>> Didn't see hypenation on the web before, looks alien to me. From the
>> typesetting point of view I find manpages with a larger font
>> pleasure to read.
>> http://man7.org/linux/man-pages/man3/fclose.3.html
>> They are neither justified nor hyphenated.
>
> Exactly. While justification/hyphenation are nice to have, they are
> really only peripheral benefits. We should not be paying such a big
> price for them. I really have a hard time understanding the rationale
> behind trying to make hyphenation work, when the time could be much
> better spent improving the D docs that newbies keep complaining about.
>
>
> T

My recent changes to hyphenation were because Andrei vetoed my attempt to remove hyphenation so I spent some time trying to make it as bearable as possible.  Not much time has gone into it (and I'm not a great or qualified technical writer in any case).