"Adam D. Ruppe" <destructionator@gmail.com> wrote in message news:pfaikhejyfjpbpwwqrit@forum.dlang.org...
>
> Then, he asked for a partial ajax load thing. Turns out that's trivially easy too. On the client:
>

That reminds me: "Trendy" web people seem to be a bit schizophrenic (I can't believe I spelled that right!) when it comes to "thin vs thick clients". They're into "cloud" this and "cloud" that, and always web-based naturally, so obviously they're into thin clients. But then they cram it so full of JS that they're literally turning their beloved thin "cloud" client into an ad-hoc thick client.

Makes me want yell at them: Just cut the crap, admit you want a think client, and make a *real* thick client. If you want trivial installation, start backing and pushing for something like 0-install. If you want cross-platform, use a cross-platform toolkit. You want network connectivity? Use curl, or any other networking lib. Ultimately, you'll get the *same* effect, but with better system integration, much less incompatibility bullshit, never have to deal with IE, don't need to wait for HTML5/canvas penetrarion, use whatever language you damn well please, and you get all these without all that "middleman" bloat. (And you can do more to make reverse engineering harder if you're into closed-source.)

>
> Now, there *are* cases where you can't do this so easily.
> If you're stuck on poor PHP I'm sure this is harder than
> in D too... but really, do you have one of those cases?

And even if you are stuck with PHP, you really should just be using something like Haxe instead. (IMO)

"Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message news:mailman.572.1331601463.4860.digitalmars-d@puremagic.com...
> On Tuesday, March 13, 2012 01:50:29 Adam D. Ruppe wrote:
>> On Tuesday, 13 March 2012 at 00:25:15 UTC, Jonathan M Davis wrote:
>> > But that's a decision based on your needs as a website
>> > developer. If JS best suits whatever the needs of a particular
>> > website developer are, then they are completely justified in
>> > using it,
>> > because 99% of the people out there have it enabled in their
>> > browsers.
>>
>> If it takes ten seconds to support 100% of the people out there, why not?
>
> [snip]
>
>> Now, there *are* cases where you can't do this so easily.
>> If you're stuck on poor PHP I'm sure this is harder than
>> in D too... but really, do you have one of those cases?
>
> All I'm saying is that if it makes sense for the web developer to use
> javascript given what they're trying to do, it's completely reasonable to
> expect that their users will have javascript enabled (since virtually
> everyone
> does). If there's a better tool for the job which is reasonably supported,
> then all the better. And if it's easy to provide a workaround for the lack
> of
> JS at minimal effort, then great. But given the fact that only a very
> small
> percentage of your user base is going to have JS disabled, it's not
> unreasonable to require it and not worry about the people who disable it
> if
> that's what you want to do.
>

Personally, I disagree with the notion that non-JS versions are a "workaround".

"H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote in message news:mailman.575.1331603803.4860.digitalmars-d@puremagic.com...
>
> (And for the record, I don't own [a TV], and do not plan to. I know I'm in the minority.
>

I can somewhat relate: I have a TV, but I rarely watch broadcast programming anymore, just library videos.

Although even if I didn't watch videos either, I'd still want a TV just for gaming. I spend so much time at a computer desk, that when I unwind I want to do away from a desk or computer, like a living room couch. YMMV, of course.

"James Miller" <james@aatch.net> wrote in message news:mailman.576.1331604546.4860.digitalmars-d@puremagic.com...
>
>The phrase in web development is "Progressive enhancement" that used to be all the rage at one point. I miss those days...

Heh. :) So true...

I miss the days when having animations on a page was actually considered *bad* style. And when the big thing in web dev was minimizing "page load (and render) time". Then flash and advanced JS came around and that conventional wisdom silently flipped around (like a boiled frog), and has stayed that way ever since.

On 13 March 2012 15:48, Nick Sabalausky <a@a.a> wrote:
> "James Miller" <james@aatch.net> wrote in message news:mailman.576.1331604546.4860.digitalmars-d@puremagic.com...
>>
>>The phrase in web development is "Progressive enhancement" that used to be all the rage at one point. I miss those days...
>
> Heh. :) So true...
>
> I miss the days when having animations on a page was actually considered *bad* style. And when the big thing in web dev was minimizing "page load (and render) time". Then flash and advanced JS came around and that conventional wisdom silently flipped around (like a boiled frog), and has stayed that way ever since.
>
>

If its any consolation, I still think in terms of page load times and UX in terms of loading. I don't think animations in and of themselves are a bad thing, I think the problem was GIF's and tacky animations for the sake of it. Slide-up and slide-down animations for removal of items and the similar are more subtle, but make things look much nicer that sudden popping. Popping is bad UX in general, even high-graphics games know that now, going more for mosaic fade-ins on the textures instead.

--
James Miller

On 03/12/2012 08:32 PM, Nick Sabalausky wrote:
> "Adam D. Ruppe"<destructionator@gmail.com>  wrote in message
> news:npkazdoslxiuqxiingao@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.

On 03/12/2012 10:58 PM, H. S. Teoh wrote:
> On Mon, Mar 12, 2012 at 09:17:22PM -0400, Jonathan M Davis wrote:
>> On Tuesday, March 13, 2012 01:50:29 Adam D. Ruppe wrote:
>>> On Tuesday, 13 March 2012 at 00:25:15 UTC, Jonathan M Davis wrote:
>>>> But that's a decision based on your needs as a website developer.
>>>> If JS best suits whatever the needs of a particular website
>>>> developer are, then they are completely justified in using it,
>>>> because 99% of the people out there have it enabled in their
>>>> browsers.
>>>
>>> If it takes ten seconds to support 100% of the people out there, why
>>> not?
>>
>> [snip]
>>
>>> Now, there *are* cases where you can't do this so easily.
>>> If you're stuck on poor PHP I'm sure this is harder than
>>> in D too... but really, do you have one of those cases?
>>
>> All I'm saying is that if it makes sense for the web developer to use
>> javascript given what they're trying to do, it's completely reasonable
>> to expect that their users will have javascript enabled (since
>> virtually everyone does). If there's a better tool for the job which
>> is reasonably supported, then all the better. And if it's easy to
>> provide a workaround for the lack of JS at minimal effort, then great.
>> But given the fact that only a very small percentage of your user base
>> is going to have JS disabled, it's not unreasonable to require it and
>> not worry about the people who disable it if that's what you want to
>> do.
> [...]
>
> The complaint is not with using JS when it's *necessary*. It's with
> using JS *by default*. It's with using JS just because you can, even
> when it's *not needed* at all.
>
> It's like requiring you to have a TV just to make a simple phone call.
> Sure, you can do cool stuff like hooking up the remote end's webcam to
> the TV and other such fluff like that. But *requiring* all of that for a
> *phone call*?  Totally unnecessary, and a totally unreasonable
> requirement, even if 95% (or is that 99.9%?) of all households own a TV.
> (And for the record, I don't own one, and do not plan to. I know I'm in
> the minority.  That doesn't negate the fact that such a requirement is
> unreasonable.)
>
> OTOH if you want to *watch a movie*, well, then requiring a TV is
> completely reasonable.
>
> The problem today is that JS is the "next cool thing", so everyone is
> jumping on the bandwagon, and everything from a single-page personal
> website to a list of links to the latest toaster oven requires JS to
> work, even when it's not necessary at all. That's the silliness of it
> all.
>
>
> T

It's not the next cool thing. It makes thing more understandable for the user. And it makes the web transfer less content, and leverages server processing time. It's the next step. It's not a backwards step. :-P

I figure then Google people are just all a bunch of idiots who just like JS a lot...

"James Miller" <james@aatch.net> wrote in message news:mailman.581.1331607750.4860.digitalmars-d@puremagic.com...
> On 13 March 2012 15:48, Nick Sabalausky <a@a.a> wrote:
>> "James Miller" <james@aatch.net> wrote in message news:mailman.576.1331604546.4860.digitalmars-d@puremagic.com...
>>>
>>>The phrase in web development is "Progressive enhancement" that used to be all the rage at one point. I miss those days...
>>
>> Heh. :) So true...
>>
>> I miss the days when having animations on a page was actually considered *bad* style. And when the big thing in web dev was minimizing "page load (and render) time". Then flash and advanced JS came around and that conventional wisdom silently flipped around (like a boiled frog), and has stayed that way ever since.
>>
>>
>
> If its any consolation, I still think in terms of page load times and UX in terms of loading. I don't think animations in and of themselves are a bad thing, I think the problem was GIF's and tacky animations for the sake of it. Slide-up and slide-down animations for removal of items and the similar are more subtle, but make things look much nicer that sudden popping. Popping is bad UX in general, even high-graphics games know that now, going more for mosaic fade-ins on the textures instead.
>

Yea, I do mostly agree, actually. But there is still a lot of needless animation (often in the form of Flash), although that does seem to be on a [long slow] decline. Adverts are a *big* probelm with animation (and even sound), though. I never actually used to mind the old banner ads, but when they started animating I had to install an adblocker literally just so I could be *capable* of reading the main content. Maybe that's just me, but still, accessiblity is important. Or at least *should* be considered important - and not just the subset of accessibility mandated by government.

As far as the typical UI animations, I think that's a much more complicated issue: First of all, I do agree that it *can* be good design. However, there's a few problems:

1. Such animations need to be *FAST*. We're talking roughly 250ms max (probably even less, but I'd have to play around with it to refresh my memory). Most UI animations are slower than this (particularly on the web - although many DVDs are *FAR* worse), and while it's good for first-time users, for everyone else it just gets in the way of getting work done and makes the experience feel sluggish.

2. On the web, animation means JS. But not everyone is using a browser with that V8 engine or whatever it's called (the one that Chrome uses). And not everyone is using a quad-core system with 64-bit software and 16GB or whatever RAM, etc. like the well-supplied web developers are likely using. So frequently this means very choppy, sluggish animations. And that's a much worse UX than popping. This also gets in the way of being able to properly handle #1 above, *fast* animations.

3. People have also reported that such UI animations can convey a subtle (or even not-so-subtle) sense of being patronized. Especially if it's a slower animation. I can definitely relate to this.

(Of course, if people just make real applications instead of web apps, then those problems would be trivially solvable.)

On Tuesday, 13 March 2012 at 04:24:45 UTC, Nick Sabalausky wrote:
> 2. On the web, animation means JS.

css3 does animations that are pretty easy to use,
degrade well, and tend to be fast. Moreover css
is where it belongs anyway - it is pure presentation.

Far, far superior to the JS crap.

On 13 March 2012 17:07, Ary Manzana <ary@esperanto.org.ar> wrote:
> On 03/12/2012 08:32 PM, Nick Sabalausky wrote:
>>
>> "Adam D. Ruppe"<destructionator@gmail.com>  wrote in message news:npkazdoslxiuqxiingao@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