Arbitrary abbreviations in phobos considered ridiculous

[James Miller]

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