Arbitrary abbreviations in phobos considered ridiculous

[Ary Manzana]

On 03/13/2012 01:29 AM, James Miller wrote:
> On 13 March 2012 17:07, Ary Manzana<ary at esperanto.org.ar>  wrote:
>> On 03/12/2012 08:32 PM, Nick Sabalausky wrote:
>>>
>>> "Adam D. Ruppe"<destructionator at gmail.com>    wrote in message
>>> news:npkazdoslxiuqxiingao at forum.dlang.org...
>>>>
>>>> On Monday, 12 March 2012 at 23:23:13 UTC, Nick Sabalausky wrote:
>>>>>
>>>>> at the end of the day, you're still saying "fuck you" to millions of
>>>>> people.
>>>>
>>>>
>>>> ...for little to no reason. It's not like making 99% of
>>>> sites work without javascript takes *any* effort.
>>>>
>>>
>>> *Exactly*. And nobody can tell me otherwise because *I DO* exactly that
>>> sort
>>> of web development. Plus, it often makes for a *worse* user experience
>>> even
>>> when JS is on - look at Vladimir's D forums vs reddit. Vladimir put reddit
>>> to shame *on reddit*, for god's sake! And how many man-hours of effort do
>>> you think went into those D forums vs reddit?
>>>
>>>> Indeed, going without javascript is often desirable
>>>> anyway, since no JS sites are /much/ faster than script
>>>> heavy sites.
>>>
>>>
>>> Yup. Guess I already responded to this in the paragraph above :)
>>
>>
>> It's not about the speed. It's about behaviour.
>>
>> Imagine I do I blog site and want people to leave comments. I decide the
>> best thing for the user is to just enter the comment in a text area, press a
>> button, and have the comment turn into a text block, and say something like
>> "Comment saved!". From a UI perspective, it's the most reasonable thing to
>> do: you leave a comment, it becomes a definitive comment on the blog, that's
>> it.
>>
>> The implementation is straightforward (much more if I use something like
>> knockoutjs): I post the comment to the server via javascript and on the
>> callback, turn that "editing comment" into a definitive comment. Note that
>> only the comment contents were transfered between the client and the server.
>>
>> Now, I have to support people who don't like javascript (and that people
>> ONLY includes developers, as most people don't even know the difference
>> between google and a web browser).
>>
>> To implement that I have to check for disabled javascript, and post the
>> comment to a different url that will save the comment and redirect to the
>> same page. First, it's a strange experience for the user: navigating to
>> another page while it's really going to the same page, just with one more
>> comment (and how can I make it scroll without javascript to let the user see
>> the comment just created? Or should I implement an intermediate page saying
>> "here's your newly created comment, now go back to the post"). Second, the
>> whole page is transferred again! I can't see how in the world that is faster
>> than not transferring anything at all.
>>
>> I know, I had to transfer some javascript. But just once, since it'll be
>> cached by the server. In fact, if the page has a static html which invokes
>> javascript that makes callbacks, that's the most efficient thing to do.
>> Because even if your comments change, the whole page remains the same:
>> elements will be rendered after *just* the comment's content (in JSON) are
>> transferred.
>>
>> Again, I don't understand how that is slower than transferring whole pages
>> the whole time.
>
> Ary, the idea is to start with the static HTML version, then
> progressively add javascript to improve the functionality. If you have
> javascript at your disposal, you can change the behavior of the
> existing page.
>
> Your example would be:
>
> 1. Start with normal POST-request comment form, make sure it works.
> (HTTP redirect back to original page)
> 2. Add javascript that listens to the submit on the comment form.
> 2a. Stop the default submit, submit the form to the same endpoint as 1
> 3. On success, do your in-page comment action.
>
> And thats about it. I'm sure you could break it down more. There's
> also more you can do, most of it server-side (check for ajax post,
> return JSON, etc.), but the idea is that the extra effort to support
> HTML-only isn't really extra effort. Since you have to submit the form
> anyway, then why not allow it to submit by regular HTTP first.
>
> Ideally, you don't have to detect for javascript, you just have to
> *shock horror* code to web standards.
>
> --
> James Miller

But the non-javascript version is a worse user experience, and it's less 
efficient. Why not make it well from scratch?