[OT] D hidden features topic for StackOverflow

Bent Rasmussen IncredibleShrinkingSphere at Gmail.com
Thu Sep 25 12:28:52 PDT 2008


It may be that it "involves" using Javascript in the same sense that using D 
involves using assembler code, but Javascript implementations are becomming 
increasingly fast, as latest witnessed by the Squirrelfish Extreme 
Javascript VM (and V8 and TraceMonkey). There are also languages like haXe, 
Java and C# that can be compiled to Javascript. It's becomming increasinly 
nice to work with, with type inference, intellisense etc.

That said, the platform is aging and ad-hoc. But there is some new life 
being breathed into it.

Bent


"Nick Sabalausky" <a at a.a> skrev i meddelelsen 
news:gbgo8e$2m2i$1 at digitalmars.com...
> "JMNorris" <nospam at nospam.com> wrote in message 
> news:gbg3e2$1230$1 at digitalmars.com...
>> "Nick Sabalausky" <a at a.a> wrote in news:gb9gjc$3od$1 at digitalmars.com:
>>
>>> Meh, stack overflow needs to die a swift death. OpenID-only login, modal
>>> dhtml "dialog boxes" (WTF were people thinking when they first created
>>> these?!?!), and complety Ajax (I *HATE* Ajax).
>>
>> Just curious, why do you hate Ajax?  (This question comes from someone 
>> who
>> doesn't know enough about Ajax or web sites that use it to have his own
>> opinion about it.)
>>
>> --
>> JMNorris
>
> Well, from a developer's standpoint, I don't like it because it involves 
> using ECMAScript/JavaScript, and I consider that to be a terrible language 
> (though I admit the newer versions really are are improvements. Of course, 
> it's still basically a case of polishing a turd - they can polish it all 
> they want, it's still a turd.)
>
> Also, it involves DHTML, which involves using the browser DOMs and those 
> things are terribly inconsistent across browsers, and even the "official" 
> standard is poorly designed in places (for instance, the value that gets 
> returned to indicate which mouse button(s) is/are down is *FAR* better in 
> IE, but the official standard's way of doing it is both completely 
> incompatible with that and is practically useless by comparison anyway). 
> It's possible to get things working reliably and consistently across 
> browsers, but it involves an enormous amount of the absolute most 
> ridiculous and obscure trickery I've ever seen on any platform (And I've 
> coded for the Atari VCS). There's a site somewhere that explains a lot of 
> it, but it's (thankfully) been awhile since I've had to do much DHTML so 
> unfortunately I don't have the link handy.
>
> From a user's standpoint, I have a whole other set of reasons, which I 
> mentioned in different branch of this thread. I use an actual newsgroup 
> reader so I can't link to it, so I'll just quote it here:
>
>> I guess I overstated my point a little bit. Ajax (as well as
>> non-Ajaxy JS/DHTML) is great for simple things like voting on posts
>> (Provided that Ajax/JS isn't required for the feature, because there's
>> really no reason for these things not to have graceful non-JS fallbacks. 
>> Or
>> at least there wouldn't be any reason if it weren't for the fact that
>> (X)HTML/CSS has certain appallingly-ridiculous limitations that will 
>> never
>> get fixed just because everyone's fearful of changing HTML anymore and 
>> has
>> gotten used to using JS-based workarounds - and that *is* what they are -
>> workarounds).
>>
>> But these days, web or not, you can pretty much guarantee: if there's a 
>> way
>> to screw up the design of something, it will get screwed up *and* 
>> millions
>> of developers will then run around all copying the same screwup after 
>> either
>> not noticing it, or mistaking it for a good idea.
>>
>> Examples:
>> - Breaking the "Back" button
>> - Breaking the bookmarking ability
>> - Flash intro pages / Intro pages, period / Flash intros on the homepage
>> (Ie, the animating GIFs/blink tags of the 21st century) / Flash sites
>> - Loads of invisible text on any system that uses a non-default color
>> scheme.
>> - Crapping all over established design standards (in general).
>> - Menus that expand upon mouseover instead of click.
>> - "Close" buttons that minimize instead of close (typically a non-web
>> issue).
>> - Adding the "feature" of modal dialog boxes to something (ie, a web 
>> page)
>> that has no technical or design justification for such modality.
>> - Forcing a custom skin upon users of an app instead of at least 
>> *allowing*
>> the user to use *their own system settings* (another typically non-web
>> issue).
>> - Screwing up the ability to work with two instances at the same time
>> (*cough* Adobe LiveDocs *cough*).
>> - Inadvertently preventing full archival for offline reference (*cough*
>> Adobe LiveDocs *cough*).
>> - Insanely slow page loading and navigation (*cough* Adobe LiveDocs and
>> Joystiq/Engadget *cough*).
>> - Using PDF instead of HTML for anything except printing.
>> - Eliminating the user's ability to make their own decisions of when to 
>> open
>> something in a new tab/window or the same tab/window.
>>
>> Ajax/JS/DHTML is what enables many of those problems to occur (not all of
>> them, though, I kinda got carried away). Disable JS and many of those
>> problems go away. Or at least they *would* go away if everyone wasn't so
>> keen on throwing away the whole idea of non-JS-fallbacks.
>>
>> I mean really, there is absolutely no useful functionality that
>> JS/Ajax/DHTML provide that can't be accomplished in a non-JS/Ajax/DHTML 
>> way,
>> either right now or with a few minor improvements to XHTML/CSS (such as
>> allowing the "action" and "method" attributes to be associated with an
>> "input/submit" tag instead of the "form" tag, or allowing link tags to
>> perform a form submission - actually these things are the exact examples 
>> I
>> had in mind when I said above that JS is sometimes used as a workaround 
>> for
>> (X)HTML's limitations).
>>
>> The only *real* use of JS/Ajax/DHTML is that they allow for fewer
>> full-page-loads. That's really all it comes down to. And that's not a bad
>> thing, but for some people, like myself, the benefit of having fewer
>> full-page-loads just isn't worth the cost of having to deal with all that
>> crap design that JS/Ajax/DHTML end up allowing. But unfortunately, I 
>> don't
>> have the option of actually *making* that choice thanks to all of those
>> yahoos that have jumped onto the "JS is now a standard feature that we 
>> can
>> safely require" bandwagon.
>
> 



More information about the Digitalmars-d mailing list