www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - emscripten

reply bearophile <bearophileHUGS lycos.com> writes:
Today being online matters for languages. I have found another way to (in
theory) run D code on the web. An interesting (unfinished still) project named
emscripten:
http://code.google.com/p/emscripten/

It translated LLVM asm (IR, I think) to JavaScript (that later may be optimized
or compressed, with the Google Clojure JS compiler too). So I think it may be
used with with D/LDC too. Given the performance of the recently created
Crankshaft of the Chrome V8 JavaScript engine, it may be interesting. It's
often 10-15 times faster than plain Python code, this means it's not fast
compared to compiled languages, but it's fast enough for some usages.

Bye,
bearophile
Dec 14 2010
next sibling parent reply Adam Ruppe <destructionator gmail.com> writes:
 Today being online matters for languages. I have found
 another way to (in theory) run D code on the web.


I've been running D code on the web, professionally, for almost a year now.

To toy around, I've also done C, C++, and even assembly.

How? It runs on the server, and the client browser is just a display for its
output and a source for its input.


Client side scripting sucks. It's garbage. Slow, incompatible, unreliable, and a
piece of junk platform in general - it does very little that's interesting.
That's
not even getting into the language itself.

Sites that rely on it suck. They ignore the facts above, wasting my time (and
anyone else who keeps the slow crappy scripts disabled).



Now, I'm not saying "don't use it". It can do some useful things. But, don't
rely
on it. If the crappiness of javascript, the language (as opposed to the browser
platform, which sucks in its own right), it seriously affecting your website, it
means you're using too much of it and/or you're using it for the wrong thing.
Some
annoyance? Yeah, guaranteed. Enough to warrant switching to a different
language... yet still be locked in the browser? blargh.


Thus, anything that compiles to javascript is a failure out of the gate in my
eyes. It is guaranteed to suck and is virtually worthless anyway, even if it
works
well.


Which brings me to emscripten... it most certainly does not work well! The
Python
example took a couple *minutes* to load for me, and actually running some python
code took seconds each time.

Maybe a magic wand will be waved and it will magically become fast, but I doubt
it. Even so however, it's pretty worthless.
Dec 14 2010
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Adam Ruppe:


 Client side scripting sucks.


JavaScript is the Next Big Language :-) Better to lean it.

Bye,
bearophile
Dec 14 2010
prev sibling next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
Adam Ruppe Wrote:

 
 Client side scripting sucks. It's garbage. Slow, incompatible, unreliable, and
a
 piece of junk platform in general - it does very little that's interesting.
That's
 not even getting into the language itself.


It totally sucks, but it does scale better than executing everything
server-side.
Dec 14 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/14/10 9:25 AM, Sean Kelly wrote:

 Adam Ruppe Wrote:

 Client side scripting sucks. It's garbage. Slow, incompatible, unreliable, and
a
 piece of junk platform in general - it does very little that's interesting.
That's
 not even getting into the language itself.


 It totally sucks, but it does scale better than executing everything
server-side.


Surprisingly, it doesn't. Facebook is reducing its client-side 
Javascript to a minimum in favor of server-side code. Reason? Speed. You 
can't control user's OS, browser, and hardware platform, but you can 
control your own.

Andrei
Dec 14 2010
next sibling parent reply Michael Stover <michael.r.stover gmail.com> writes:
Facebook is hardly a fair example - they are not a true webapp and are more
interested in numbers of users than quality of their app.  Someone who was
serious about making an application over the web would simply require Chrome
or Firefox, and then 99% of your incompatibility issues go away, as well as
your performance problems.

Something like http://muro.deviantart.com/ is great and, to me, demonstrates
the browser/javascript platform is more than capable.

-Mike



On Tue, Dec 14, 2010 at 10:49 AM, Andrei Alexandrescu <
SeeWebsiteForEmail erdani.org> wrote:


 On 12/14/10 9:25 AM, Sean Kelly wrote:


 Adam Ruppe Wrote:


 Client side scripting sucks. It's garbage. Slow, incompatible,
 unreliable, and a
 piece of junk platform in general - it does very little that's
 interesting. That's
 not even getting into the language itself.


 It totally sucks, but it does scale better than executing everything
 server-side.


 Surprisingly, it doesn't. Facebook is reducing its client-side Javascript
 to a minimum in favor of server-side code. Reason? Speed. You can't control
 user's OS, browser, and hardware platform, but you can control your own.

 Andrei
Dec 14 2010
next sibling parent Adam Ruppe <destructionator gmail.com> writes:
Michael Stover wrote:

 Someone who was serious about making an application over the
 web would simply require Chrome or Firefox, and then 99% of your
 incompatibility issues go away, as well as your performance problems.


And, let's not forget, 50% of your potential users!
Dec 14 2010
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/14/10 10:12 AM, Michael Stover wrote:

 Facebook is hardly a fair example - they are not a true webapp and are
 more interested in numbers of users than quality of their app.  Someone
 who was serious about making an application over the web would simply
 require Chrome or Firefox, and then 99% of your incompatibility issues
 go away, as well as your performance problems.


I'm not talking on behalf of my employer, but that doesn't even come 
close to describing the state of affairs.

Andrei
Dec 14 2010
prev sibling next sibling parent reply =?ISO-8859-1?Q?Alexander_P=e1nek?= <a.panek brainsware.org> writes:
Andrei Alexandrescu Wrote:

 On 12/14/10 9:25 AM, Sean Kelly wrote:

 Adam Ruppe Wrote:

 Client side scripting sucks. It's garbage. Slow, incompatible, unreliable, and
a
 piece of junk platform in general - it does very little that's interesting.
That's
 not even getting into the language itself.






It's up to you what you're doing with the language/platform. I created some
pretty decent almost-MVC apps with JS in the browser, using a lot of the
language's features. If you're just hacking some stuff together.. ay.. then you
might not get into the language itself. Anyways, your fault. :)


 It totally sucks, but it does scale better than executing everything
server-side.




Always a matter of using the right tools for the job.
 

 Surprisingly, it doesn't. Facebook is reducing its client-side 
 Javascript to a minimum in favor of server-side code. Reason? Speed. You 
 can't control user's OS, browser, and hardware platform, but you can 
 control your own.


I've never heard of that before. I can also not really imagine it, given that
Facebook is one of the providers of the most-included JS cross-site snippets?
Ever heard of FBML? The only thing they reduced was the *markup* code which was
slowing some browsers down when displaying a lot of items in the feed.
Javascript isn't a bottleneck here, they really did a good job on the
architecture of the whole site.

D as server-side was once something I tried to achieve, but it wasn't the right
time. It would have been perfect as backend for a full-blown JS browser app,
only handling & shuffling data around, sending JSON back and forth.

Cheers, Alex
Dec 14 2010
parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Tue, 14 Dec 2010 18:27:28 +0200, Alexander Pánek  
<a.panek brainsware.org> wrote:


 D as server-side was once something I tried to achieve, but it wasn't  
 the right time. It would have been perfect as backend for a full-blown  
 JS browser app, only handling & shuffling data around, sending JSON back  
 and forth.


I've done this. I wrote three web-apps (HTML/CSS, JS+jQuery and D). It's  
awesome.

Two of the three are private, but here's the simplest one I wrote in 2006  
(no jQuery):
http://snoop.worms2d.info/ (basically web IRC client)

The biggest challenge with pure JS applications is getting back/forward  
buttons and bookmarking right. It's possible, and easy with the right  
jQuery plugins. However, preserving state which you can't squeeze in the  
URL is nontrivial (for example, the user submits a form, then clicks  
"Back" - normally the form would still be filled out on non-JS apps). The  
solution is storing the information in JS vars or the DOM (you could even  
leave the form HTML filled out).

D really hits the spot here, though. The apps' backends needed to be  
persistent and fast (things like searching through growable memory-mapped  
files), so CGI-like languages (PHP/Perl) were no good. With D's inline  
struct types and a JSON serializer, returning JSON is really clean and  
easy, which isn't possible in mainstream compiled languages:

if (resource == "/getfoo")
{
	struct FooResult { int n; string s; }
	return toJSON(FooResult(42, "bar")); // {"n":42,"s":"bar"}
}

-- 
Best regards,
  Vladimir                            mailto:vladimir thecybershadow.net
Dec 14 2010
next sibling parent reply =?ISO-8859-1?Q?Alexander_P=e1nek?= <a.panek brainsware.org> writes:
Vladimir Panteleev Wrote:


 On Tue, 14 Dec 2010 18:27:28 +0200, Alexander Pánek  
 <a.panek brainsware.org> wrote:
 

 D as server-side was once something I tried to achieve, but it wasn't  
 the right time. It would have been perfect as backend for a full-blown  
 JS browser app, only handling & shuffling data around, sending JSON back  
 and forth.


 
 I've done this. I wrote three web-apps (HTML/CSS, JS+jQuery and D). It's  
 awesome.
 
 Two of the three are private, but here's the simplest one I wrote in 2006  
 (no jQuery):
 http://snoop.worms2d.info/ (basically web IRC client)


Nice nice!


 D really hits the spot here, though. The apps' backends needed to be  
 persistent and fast (things like searching through growable memory-mapped  
 files), so CGI-like languages (PHP/Perl) were no good. With D's inline  
 struct types and a JSON serializer, returning JSON is really clean and  
 easy, which isn't possible in mainstream compiled languages:
 
 if (resource == "/getfoo")
 {
 	struct FooResult { int n; string s; }
 	return toJSON(FooResult(42, "bar")); // {"n":42,"s":"bar"}
 }


That's what I'm talkin' 'bout! :D
Dec 15 2010
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
Vladimir Panteleev Wrote:

 if (resource == "/getfoo")
 {
  struct FooResult { int n; string s; }
  return toJSON(FooResult(42, "bar")); // {"n":42,"s":"bar"}
 }



What kind of code did you use there? My app does something
similar using wrappers of std.json.

JSONValue toJsonValue(T)(T a) {
        JSONValue val;
        static if(is(T == JSONValue)) {
                val = a;
        } else static if(__traits(compiles, a.makeJsonValue())) {
                val = a.makeJsonValue();
        } else static if(isIntegral!(T)) {
                val.type = JSON_TYPE.INTEGER;
                val.integer = to!long(a);
[......]

And it goes right through a variety of types, including
structs where it does __traits(allMembers), and ultimately
settles for to!string if nothing else fits.



My program also reads json, but I had some trouble with std.json,
so I had to fork it there. It has a helper function jsonValueToVariant (which
just
became fully usable in dmd 2.050,
shortening my code a lot, thanks phobos/dmd devs!) which
pulls it into a std.variant for easy using later.

The trouble I had was std.json.parseJSON claims to be able
to handle arbitrary input ranges, but when I actually instantiated
it on plain old string, it refused to compile.

I made it work by switching it to just normal strings in my private
fork.




What's really cool about these templates is it enables automatic calling of
functions from the outside. You write a function like:

struct User { ... }

User getUserInfo(int id) { .... }


And then this is accessible, through template magic, as:

/app/get-user-info?id=1

Returns a full HTML document with the info

/app/get-user-info?id=1&format=json

Returns the User struct converted to json

/app/get-user-info?id=1&format=xml

The struct as a kind of xml (I didn't spend much time on this so it still sucks)


And more. Way cool.



Anyway, I thought about committing some of my json changes back to std.json, but
removing the range capability goes against the grain there, and adding the
templates seems pointless since everyone says std.json is going to be trashed
anyway. I thought I might have actually been the only one using it!


I'm curious what you did in your code. Is it a custom module or did you build
off
the std.json too?
Dec 15 2010
next sibling parent reply "Robert Jacques" <sandford jhu.edu> writes:
On Wed, 15 Dec 2010 09:38:16 -0500, Adam D. Ruppe  
<destructionator gmail.com> wrote:

 Vladimir Panteleev Wrote:

 if (resource == "/getfoo")
 {
  struct FooResult { int n; string s; }
  return toJSON(FooResult(42, "bar")); // {"n":42,"s":"bar"}
 }



 What kind of code did you use there? My app does something
 similar using wrappers of std.json.

 JSONValue toJsonValue(T)(T a) {
         JSONValue val;
         static if(is(T == JSONValue)) {
                 val = a;
         } else static if(__traits(compiles, a.makeJsonValue())) {
                 val = a.makeJsonValue();
         } else static if(isIntegral!(T)) {
                 val.type = JSON_TYPE.INTEGER;
                 val.integer = to!long(a);
 [......]

 And it goes right through a variety of types, including
 structs where it does __traits(allMembers), and ultimately
 settles for to!string if nothing else fits.



 My program also reads json, but I had some trouble with std.json,
 so I had to fork it there. It has a helper function jsonValueToVariant  
 (which just
 became fully usable in dmd 2.050,
 shortening my code a lot, thanks phobos/dmd devs!) which
 pulls it into a std.variant for easy using later.

 The trouble I had was std.json.parseJSON claims to be able
 to handle arbitrary input ranges, but when I actually instantiated
 it on plain old string, it refused to compile.

 I made it work by switching it to just normal strings in my private
 fork.




 What's really cool about these templates is it enables automatic calling  
 of
 functions from the outside. You write a function like:

 struct User { ... }

 User getUserInfo(int id) { .... }


 And then this is accessible, through template magic, as:

 /app/get-user-info?id=1

 Returns a full HTML document with the info

 /app/get-user-info?id=1&format=json

 Returns the User struct converted to json

 /app/get-user-info?id=1&format=xml

 The struct as a kind of xml (I didn't spend much time on this so it  
 still sucks)


 And more. Way cool.



 Anyway, I thought about committing some of my json changes back to  
 std.json, but
 removing the range capability goes against the grain there, and adding  
 the
 templates seems pointless since everyone says std.json is going to be  
 trashed
 anyway. I thought I might have actually been the only one using it!


 I'm curious what you did in your code. Is it a custom module or did you  
 build off
 the std.json too?


Hi Adam,
I've been working on a replacement for std.json. I posted a preview to the  
phobos list, but I haven't gotten any feedback yet, as its not very high  
priority.

Here is my original post:
I have been working on a re-write of std.json. The purpose was to fix  
implementation bugs, better conform to the spec, provide a lightweight  
tokenizer (Sean) and to use an Algebraic type (Andrei) for JSON values. In  
the progress of doing this, I made my parser 2x faster and updated/fixed a  
bunch of issues with VariantN in order to fully support Algebraic types.  
Both of these libraries are at a solid beta level, so I'd like to get some  
feedback, and provide a patch for those being held back by the problems  
with Algebraic. The code and docs are available at:  
https://jshare.johnshopkins.edu/rjacque2/public_html/. These files were  
written against DMD 2.050 and both depend on some patches currently in  
bugzilla (see the top of each file or below)

Summary of Variant changes:
* Depends on Issue 5155's patch
* VariantN now properly supports types defined using "This".
* Additional template constraints and acceptance of implicit converters in  
opAssign and ctor. i.e. if an Algebraic type supports reals, you can now  
assign an int to it.
* Updated to using opBinary/opBinaryRight/opOpAssign. This adds right  
support to several functions and is now generated via compile time  
reflection + mixins: i.e. Algebraic types of user defined types should  
work, etc.
* Added opIn support, though it currently on works for AAs.
* Added opIndexOpAssign support.
* Added opDispatch as an alternative indexing method. This allows Variants  
of type Variant[string] to behave like prototype structs: i.e. var.x = 5;  
instead of var["x"] = 5;

Notes:
* There's an bugzilla issue requesting opCall support in Variant. While I  
can see the usefulness, syntactically this clashes with the ctor. Should  
this issue be closed or should a method be used as an opCall surrogate?
* Could someone explain to me the meaning/intension of "Future additions  
to Algebraic will allow compile-time checking that all possible types are  
handled by user code, eliminating a large class of errors." Is this  
something akin to final switch support?

Summary of JSON changes:
* Depends on the Variant improvements.
* Depends on Issue 5233's patch
* Depends on Issue 5236's patch
* Issue 5232's patch is also recommended
* The integer type was removed: JSON doesn't differentiate between  
floating and integral numbers. Internally, reals are used and on systems  
with 80-bit support, this encompasses all integral types.
* UTF escape characters are now correctly support.
* All routines/types were encapsulated in a JSON struct for name space  
reasons.
* An Algebraic type is used for JSON values, with  
serialization/de-serialization routines as free methods.
* Serialization/de-serialization centers around a set of input/output  
range to/from token range routines, with separate parser/writer routines.
* Values can be written in either a concise (default) or pretty printed  
format. (i.e. indented with line returns)
* Convenience toString and toStringHR routines exist.
* Simple Type to/from json routines exist, but are marked as to be  
re-evaluated pending std.serialization.
* I've implemented a binary format customized for JSON. Besides preserving  
numeric precision (i.e. 80-bit reals), I found it gave slightly smaller  
file size (~20%) and 2-3x parsing performance for a large numeric dataset  
of mine. I'm not sure if it's worth-while on the whole, so I'd appreciate  
feedback.

Notes:
* Does anyone have a suggestion of a good way to attach methods to an  
Algebraic type? And if we can, should we?
Dec 15 2010
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/15/10 11:49 AM, Robert Jacques wrote:
[JSON]

Apologies for not making the time to review this; I'm very interested in 
the topic but I have 121 emails waiting for attention in my inbox, and 
each requires a fair amount of work.


 Notes:
 * Does anyone have a suggestion of a good way to attach methods to an
 Algebraic type? And if we can, should we?


This is a very good challenge. Ideally Algebraic would define a method 
if and only if all of its possible types define a method with (a) same 
name, (b) covariant return types (i.e. return types have a CommonType), 
(c) contravariant parameter types (we don't have ContravariantCommonType 
in std.traits, but it should be doable). Consider:

class Widget {
     long foo(int);
}

class Gadget {
     int foo(long);
}

auto a = Algebraic!(Widget, Gadget)(new Widget);
long x = a.foo(42); // should work
x = a.foo(x); // shouldn't compile

That would be awes, and is in fact implementing an optimization called 
type casing.


Andrei
Dec 15 2010
prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
Robert Jacques wrote:

 *snip code*


I'm just quickly looking it over, with some brief comments.

Your code looks good. You covered everything, and your use of tupleof seems to
do
a better job than my own use of allMembers! Very cool.

I guess I'm actually very brief, but generally it looks nice. I'll try using it
in
a project sometime (hopefully soon) and may have some meaty comments then, but
from the source, I think I'll like it.
Dec 15 2010
parent reply "Robert Jacques" <sandford jhu.edu> writes:
On Wed, 15 Dec 2010 13:31:37 -0500, Adam D. Ruppe  
<destructionator gmail.com> wrote:


 Robert Jacques wrote:

 *snip code*


 I'm just quickly looking it over, with some brief comments.

 Your code looks good. You covered everything, and your use of tupleof  
 seems to do
 a better job than my own use of allMembers! Very cool.

 I guess I'm actually very brief, but generally it looks nice. I'll try  
 using it in
 a project sometime (hopefully soon) and may have some meaty comments  
 then, but
 from the source, I think I'll like it.


Thanks. I also used allMembers in my first iteration, but it gives what  
I'd consider false positives, so you have to filter the results.
Dec 15 2010
parent Adam D. Ruppe <destructionator gmail.com> writes:
Robert Jacques wrote:

 I also used allMembers in my first iteration, but it gives what
 I'd consider false positives, so you have to filter the results.


Aye. What I did that was good enough for me was to skip any
names that started with a _ (which hits _ctor and also a naming
convention for "private" variables) and also added a check
for a member function toJsonValue.

If that member function is available, it is called instead of
proceeding inside, letting the struct or class specialize its
own output, thus getting around the naming problems.

I never used it in practice though, since I just learned to
avoid names that cause problems. Not a perfect solution but
it worked for me.
Dec 15 2010
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/15/10 11:49 AM, Robert Jacques wrote:
[Algebraic]

Are all bugfixes that your work depends on rolled into the upcoming dmd 
release?

Andrei
Dec 15 2010
parent reply "Robert Jacques" <sandford jhu.edu> writes:
On Wed, 15 Dec 2010 13:42:39 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:


 On 12/15/10 11:49 AM, Robert Jacques wrote:
 [Algebraic]

 Are all bugfixes that your work depends on rolled into the upcoming dmd  
 release?

 Andrei


I don't think so, each bug seems to still be open and I haven't seen any  
posts to the phobos list mentioning them. The bug reports do all contain  
patches though.
Issue 5155: http://d.puremagic.com/issues/show_bug.cgi?id=5155
Issue 5233: http://d.puremagic.com/issues/show_bug.cgi?id=5233
Issue 5236: http://d.puremagic.com/issues/show_bug.cgi?id=5236
Issue 5232: http://d.puremagic.com/issues/show_bug.cgi?id=5232
Dec 15 2010
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/15/10 2:05 PM, Robert Jacques wrote:

 On Wed, 15 Dec 2010 13:42:39 -0500, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:


 On 12/15/10 11:49 AM, Robert Jacques wrote:
 [Algebraic]

 Are all bugfixes that your work depends on rolled into the upcoming
 dmd release?

 Andrei


 I don't think so, each bug seems to still be open and I haven't seen any
 posts to the phobos list mentioning them. The bug reports do all contain
 patches though.
 Issue 5155: http://d.puremagic.com/issues/show_bug.cgi?id=5155
 Issue 5233: http://d.puremagic.com/issues/show_bug.cgi?id=5233
 Issue 5236: http://d.puremagic.com/issues/show_bug.cgi?id=5236
 Issue 5232: http://d.puremagic.com/issues/show_bug.cgi?id=5232


This month's release is already in beta, so this probably won't make it 
now. Would be great to boost the priority bugs for the next release then.

Andrei
Dec 15 2010
prev sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Wed, 15 Dec 2010 16:38:16 +0200, Adam D. Ruppe  
<destructionator gmail.com> wrote:


 I'm curious what you did in your code. Is it a custom module or did you  
 build off
 the std.json too?


Umm, I just wrote my own, it's way simpler than what you described. Also  
it's in D1. See attached :P

-- 
Best regards,
  Vladimir                            mailto:vladimir thecybershadow.net
Dec 15 2010
parent Adam D. Ruppe <destructionator gmail.com> writes:
Vladimir Panteleev wrote:

 Umm, I just wrote my own, it's way simpler than what you described.


Ah indeed, that is simple! Very nice.
Dec 15 2010
prev sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 12/14/10, Vladimir Panteleev <vladimir thecybershadow.net> wrote:

 if (resource == "/getfoo")
 {
 	struct FooResult { int n; string s; }
 	return toJSON(FooResult(42, "bar")); // {"n":42,"s":"bar"}
 }


Funny thing about that commented out code. I've tried returning
something like that once from a function:

return { int n = 42; string s = "bar"; }

So basically a struct that has it's members default-initialized with
some values. Unfortunately D thought I was returning a delegate
instead, so I can't use this syntax.
Dec 15 2010
parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Wed, 15 Dec 2010 12:27:48 +0200, Andrej Mitrovic  
<andrej.mitrovich gmail.com> wrote:


 On 12/14/10, Vladimir Panteleev <vladimir thecybershadow.net> wrote:

 if (resource == "/getfoo")
 {
 	struct FooResult { int n; string s; }
 	return toJSON(FooResult(42, "bar")); // {"n":42,"s":"bar"}
 }


 Funny thing about that commented out code. I've tried returning
 something like that once from a function:

 return { int n = 42; string s = "bar"; }

 So basically a struct that has it's members default-initialized with
 some values. Unfortunately D thought I was returning a delegate
 instead, so I can't use this syntax.


The commented-out "code" is the resulting JSON :)

-- 
Best regards,
  Vladimir                            mailto:vladimir thecybershadow.net
Dec 15 2010
prev sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
Andrei Alexandrescu Wrote:


 On 12/14/10 9:25 AM, Sean Kelly wrote:

 Adam Ruppe Wrote:

 Client side scripting sucks. It's garbage. Slow, incompatible, unreliable, and
a
 piece of junk platform in general - it does very little that's interesting.
That's
 not even getting into the language itself.


 It totally sucks, but it does scale better than executing everything
server-side.


 
 Surprisingly, it doesn't. Facebook is reducing its client-side 
 Javascript to a minimum in favor of server-side code. Reason? Speed. You 
 can't control user's OS, browser, and hardware platform, but you can 
 control your own.


I don't think speed and scalability are the same thing.  Everything is far
faster server-side, but you pay for that in data center real estate.  The trick
is finding the right balance.
Dec 14 2010
parent Sean Kelly <sean invisibleduck.org> writes:
Sean Kelly Wrote:


 Andrei Alexandrescu Wrote:
 

 On 12/14/10 9:25 AM, Sean Kelly wrote:

 Adam Ruppe Wrote:

 Client side scripting sucks. It's garbage. Slow, incompatible, unreliable, and
a
 piece of junk platform in general - it does very little that's interesting.
That's
 not even getting into the language itself.


 It totally sucks, but it does scale better than executing everything
server-side.


 
 Surprisingly, it doesn't. Facebook is reducing its client-side 
 Javascript to a minimum in favor of server-side code. Reason? Speed. You 
 can't control user's OS, browser, and hardware platform, but you can 
 control your own.


 
 I don't think speed and scalability are the same thing.  Everything is far
faster server-side, but you pay for that in data center real estate.  The trick
is finding the right balance.


Oh, I forgot to mention that latency is another issue.  On a slow line, even
instantaneous server-side computation can seem slow to the user.  This is
probably the largest issue in designing a performant web app these days.  There
are solutions (like edge caching) but they can tremendously complicate the app
design.
Dec 14 2010
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2010-12-14 13:56, Adam Ruppe wrote:

 Today being online matters for languages. I have found
 another way to (in theory) run D code on the web.


 I've been running D code on the web, professionally, for almost a year now.

 To toy around, I've also done C, C++, and even assembly.

 How? It runs on the server, and the client browser is just a display for its
 output and a source for its input.


 Client side scripting sucks. It's garbage. Slow, incompatible, unreliable, and
a
 piece of junk platform in general - it does very little that's interesting.
That's
 not even getting into the language itself.

 Sites that rely on it suck. They ignore the facts above, wasting my time (and
 anyone else who keeps the slow crappy scripts disabled).



 Now, I'm not saying "don't use it". It can do some useful things. But, don't
rely
 on it. If the crappiness of javascript, the language (as opposed to the browser
 platform, which sucks in its own right), it seriously affecting your website,
it
 means you're using too much of it and/or you're using it for the wrong thing.
Some
 annoyance? Yeah, guaranteed. Enough to warrant switching to a different
 language... yet still be locked in the browser? blargh.


Have you tried, for example, CoffeeScript: 
http://jashkenas.github.com/coffee-script/ ? A language that compiles to 
JavaScript.


 Thus, anything that compiles to javascript is a failure out of the gate in my
 eyes. It is guaranteed to suck and is virtually worthless anyway, even if it
works
 well.


 Which brings me to emscripten... it most certainly does not work well! The
Python
 example took a couple *minutes* to load for me, and actually running some
python
 code took seconds each time.

 Maybe a magic wand will be waved and it will magically become fast, but I doubt
 it. Even so however, it's pretty worthless.



-- 
/Jacob Carlborg
Dec 14 2010
parent reply Adam Ruppe <destructionator gmail.com> writes:
 Have you tried, for example, CoffeeScript:


I have not - my main problem with Javascript isn't so much the
language as the browsers in which it runs, which is why I feel things
like emscripten (and google native client) are pretty useless.

Browsers are good for displaying html pages. Javascript is good
for enhancing those html pages. But they aren't very good at full
blown applications.

I do have a list of flames against javascript the language too,
but none of them are huge in context.


Anyway looking at the coffeescript website... it looks like my worst
nightmare: something inspired by a mixing of Python and Ruby! I
don't think I could handle that.
Dec 14 2010
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2010-12-14 20:03, Adam Ruppe wrote:

 Have you tried, for example, CoffeeScript:


 I have not - my main problem with Javascript isn't so much the
 language as the browsers in which it runs, which is why I feel things
 like emscripten (and google native client) are pretty useless.

 Browsers are good for displaying html pages. Javascript is good
 for enhancing those html pages. But they aren't very good at full
 blown applications.


I agree, I don't like it either, just trying to make the best of the 
situation.


 I do have a list of flames against javascript the language too,
 but none of them are huge in context.


 Anyway looking at the coffeescript website... it looks like my worst
 nightmare: something inspired by a mixing of Python and Ruby! I
 don't think I could handle that.


Since I'm quite a big fan of Ruby I like it.

-- 
/Jacob Carlborg
Dec 14 2010
prev sibling parent reply Michael Stover <michael.r.stover gmail.com> writes:
On Tue, Dec 14, 2010 at 2:03 PM, Adam Ruppe <destructionator gmail.com>wrote:


 Have you tried, for example, CoffeeScript:


 I have not - my main problem with Javascript isn't so much the
 language as the browsers in which it runs, which is why I feel things
 like emscripten (and google native client) are pretty useless.

 Browsers are good for displaying html pages. Javascript is good
 for enhancing those html pages. But they aren't very good at full
 blown applications.


 Adam Ruppe <destructionator gmail.com>
Did you use the gmail webapp to write that?



 I do have a list of flames against javascript the language too,
 but none of them are huge in context.


 Anyway looking at the coffeescript website... it looks like my worst
 nightmare: something inspired by a mixing of Python and Ruby! I
 don't think I could handle that.
Dec 14 2010
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
Michael Stover:

 Did you use the gmail webapp to write that?


No. My public email address is gmail so I get a free spam
filter and online archive, but I don't actually use their
awful, awful interface. (All incoming mail to that address is
forwarded to my real email address, and my outgoing mail is
SMTP relayed back through gmail. My real address remains spam
free by being secret.)

This does bring me to two rants though:

a) Gmail's web interface is horrible, even the basic HTML
version. Consider this: right click a message... no "open in
new window" option! WTF.

I handle, on average, about 170 emails a day. In my mail client
(mutt) and my server setup, this is no bother for me. There's no
waiting on slow servers. The controls are natural and fluid. I can
pick up on another computer right where I left off, thanks to
GNU screen. When I'm emailed a dozen attachments, it is a simple
case of hitting a button to save them all locally - no annoying
scan and downloading of them individually.

With gmail, I'd have to click through the messages one thread at a time, never
seeing the whole message (their hiding of quoted text and signatures, not 100%
accurate!). Try to reply? Have to deal
with their godawful editor (with mutt I can just use vim) and
the hidden text below it (implicit top quoting, are they on drugs?).

With new incoming mail, my computer beeps the second it arrives
and is idle while waiting. With gmail, it'd be sitting there
polling, at the notice it does give doesn't even compare in terms
of usability or speed.

Oh, and search? Surely Google could get search right? Nope


The worst part? Gmail might have the best of the web mail interfaces. Goes to
tell
you how dreadfully awful they are in general.



b) I am posting this from the digitalmars news web interface.
For some reason, my emails don't seem to reliably get through.

And this php webnews thing makes gmail look like heaven. It's
amazing the level of suck in this thing. I'm sure everyone
who has used it will agree so I'll spare you the long rant.

But there's times that I feel the greatest service someone
could do for D would be to replace this thing!
Dec 14 2010
next sibling parent reply Michael Stover <michael.r.stover gmail.com> writes:
I don't have any problems you seem to have with gmail.  I suspect attitude
is a big difference.

On Tue, Dec 14, 2010 at 6:43 PM, Adam D. Ruppe <destructionator gmail.com>wrote:


 Michael Stover:

 Did you use the gmail webapp to write that?


 No. My public email address is gmail so I get a free spam
 filter and online archive, but I don't actually use their
 awful, awful interface. (All incoming mail to that address is
 forwarded to my real email address, and my outgoing mail is
 SMTP relayed back through gmail. My real address remains spam
 free by being secret.)

 This does bring me to two rants though:

 a) Gmail's web interface is horrible, even the basic HTML
 version. Consider this: right click a message... no "open in
 new window" option! WTF.

 I handle, on average, about 170 emails a day. In my mail client
 (mutt) and my server setup, this is no bother for me. There's no
 waiting on slow servers. The controls are natural and fluid. I can
 pick up on another computer right where I left off, thanks to
 GNU screen. When I'm emailed a dozen attachments, it is a simple
 case of hitting a button to save them all locally - no annoying
 scan and downloading of them individually.

 With gmail, I'd have to click through the messages one thread at a time,
 never
 seeing the whole message (their hiding of quoted text and signatures, not
 100%
 accurate!). Try to reply? Have to deal
 with their godawful editor (with mutt I can just use vim) and
 the hidden text below it (implicit top quoting, are they on drugs?).

 With new incoming mail, my computer beeps the second it arrives
 and is idle while waiting. With gmail, it'd be sitting there
 polling, at the notice it does give doesn't even compare in terms
 of usability or speed.

 Oh, and search? Surely Google could get search right? Nope


 The worst part? Gmail might have the best of the web mail interfaces. Goes
 to tell
 you how dreadfully awful they are in general.



 b) I am posting this from the digitalmars news web interface.
 For some reason, my emails don't seem to reliably get through.

 And this php webnews thing makes gmail look like heaven. It's
 amazing the level of suck in this thing. I'm sure everyone
 who has used it will agree so I'll spare you the long rant.

 But there's times that I feel the greatest service someone
 could do for D would be to replace this thing!
Dec 14 2010
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
 I don't have any problems you seem to have with gmail.


Two questions:

a) Have you ever tried a better alternative? If you've only
used crap, a polished turd looks really really good.

b) How much email do you handle? I used the web interface
for quite a while before I went into business. It works ok
if you do a low volume of low priority email stuff. (as they
say, anything is fast with small n)

I just logged in. Here's what it greeted me with (after taking
its sweet time loading):

Inbox (31187)

Though now, even for a small volume, I can't go back. It'd be
like using C after spending so much time with D.
Dec 14 2010
parent reply Michael Stover <michael.r.stover gmail.com> writes:
I've used Pegasus, thunderbird, Exchange, Evolution, and whatever is on my
Mac by default (briefly).  I've used other web emails too, including one for
Exchange, which is terrible.  Some of your complaints are not generic to
javascript/web apps - like the right click complaint.  It can be done
easily.  They didn't do it, but this complaint is not damning against the
browser platform.

Complaining the editor isn't like vi just makes me roll my eyes.  Few would
really want it to be.  However, again, there are vi clones in javascript, if
one were really wanted it.

I didn't understand your complaint about having to read one thread at a
time.  I don't have the ability to read more than one at a time anyway, so I
do not have this complaint.

The server has never been slow for me, at all.  I set one browser tab to
gmail at the start of the day and never think about it again.  New emails
are always just there for me.

I can go anywhere and get my email, including the computers at the Y, the
library, from behind the firewall at work, and on my sister's computer when
I go visit her for Christmas.  I won't have to install anything to be able
to do so.

I probably get ~100 non-spam emails a day here.  Managing it is hardly any
work at all.

I really don't think the complaints about the browser platform and
javascript have much validity anymore.  They used to.  But I think those
days are gone, and I think it's like the whole "java is slow" phenomenon.
It takes a ridiculously long time for most people to change their perception
of things once they've had a bad experience.

Mike

On Tue, Dec 14, 2010 at 7:15 PM, Adam D. Ruppe <destructionator gmail.com>wrote:


 I don't have any problems you seem to have with gmail.


 Two questions:

 a) Have you ever tried a better alternative? If you've only
 used crap, a polished turd looks really really good.

 b) How much email do you handle? I used the web interface
 for quite a while before I went into business. It works ok
 if you do a low volume of low priority email stuff. (as they
 say, anything is fast with small n)

 I just logged in. Here's what it greeted me with (after taking
 its sweet time loading):

 Inbox (31187)

 Though now, even for a small volume, I can't go back. It'd be
 like using C after spending so much time with D.
Dec 14 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"Michael Stover" <michael.r.stover gmail.com> wrote in message 
news:mailman.1004.1292372981.21107.digitalmars-d puremagic.com...

 Complaining the editor isn't like vi just makes me roll my eyes.  Few 
 would
 really want it to be.  However, again, there are vi clones in javascript, 
 if
 one were really wanted it.


Text editors that rely on JavaScript are abominations, period.


 I can go anywhere and get my email, including the computers at the Y, the
 library, from behind the firewall at work, and on my sister's computer 
 when
 I go visit her for Christmas.  I won't have to install anything to be able
 to do so.


I use Outlook Express for my email. Anytime I'm away from one of my own 
computers, I can use the shitty web interface that my server provides. But 
then when I'm back on my computer, get to use a client that doesn't blow. 
Look, look -> There's my cake, and I'm eating it!

Besides, no-install software is entirely possible without resorting to the 
web browser abomination. The *only* reason they aren't already ubiquitous is 
because people keep irrationally clinging to all this moronic "web app" 
bullshit.


 I really don't think the complaints about the browser platform and
 javascript have much validity anymore.  They used to.  But I think those
 days are gone, and I think it's like the whole "java is slow" phenomenon.
 It takes a ridiculously long time for most people to change their 
 perception
 of things once they've had a bad experience.


I hear the "Java's fast now, really!" a lot. I don't buy it. If Java's no 
longer slow, I'd like to see some video codecs (mp4/ogm/xvid/etc...) written 
in Java that actually compare to systems-language ones that people actually 
use, and without the code being twice as convoluted as the systems-language 
ones.

Plus, JS is undeniably slow on my web browser: FF2. And I'll happily give up 
FF2 exactly when someone comes out with a web browser that does the 
following, and without fucking something else up in the process:

- No unified forward/back buttons
- No cluttered, crayola-colored address bar and dropdown.
- No skin.
- No useless always-resident processes.
- No invisi-text for light-on-dark systems.
- NoScript or an equivalent.
- AdBlock Plus or an equivalent.
- BetterPrivacy or an equivalent.
- TabMixPlus or an equivalent.
Dec 14 2010
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
Nick Sabalausky wrote:

 Text editors that rely on JavaScript are abominations, period.


Any widget that does sucks IMO. I've had to use javascript replacements of the
standard <select> tag too, and wow it blows.

Wait for its animation to start up. Wait for its animation to finish. Click an
option.... it didn't work, sorry my browser isn't good enough.

Usually I just abandon the site, but sometimes I can't. So switch to firefox 3.
Wait for the animation to start up. Wait for it to finish. Click the thing. Wait
for it to animate again. Oops, I got the wrong option, I'll just hit the down
arrow.... sorry, didn't work.

Aaaaaarrrrrgggggghhhhhh!

"but but look at the super cool animations jquery is amazing! and i can style
this
thing better than the built in so nyah"

Gah.



 Look, look -> There's my cake, and I'm eating it!


This is one thing I love about running mutt in screen. If I have access to my
home
box at all (directly or ssh) it works well. If I left a message half read, when
I
come back to it, it is still half read! No need to hunt it down again among the
read messages, no need to scroll back to my original position. The screen is
*exactly* as I left it.

Any my emails are *my* emails, stored on my local box. If I want to back it up,
just copy the file. If I want a search that actually works, I can just grep the
file, and so on. Just better in every way.
Dec 15 2010
parent reply Michael Stover <michael.r.stover gmail.com> writes:
All of your complaints are about specific choices of the developers, not the
technology.  Right now, javascript and web apps are being written (for the
most part) by young, inexperienced, often graphically-oriented individuals.
 Soon, more experience developers will join the scene and start writing
useful apps that aren't just eye-candy.


Any my emails are *my* emails, stored on my local box. If I want to back it


up,
just copy the file. If I want a search that actually works, I can just grep
the
file, and so on. Just better in every way.

The vast majority of people appreciate that they just get all that for free
and without bother in gmail, hotmail, yahoo, etc.

-Mike

On Wed, Dec 15, 2010 at 9:47 AM, Adam D. Ruppe <destructionator gmail.com>wrote:


 Nick Sabalausky wrote:

 Text editors that rely on JavaScript are abominations, period.


 Any widget that does sucks IMO. I've had to use javascript replacements of
 the
 standard <select> tag too, and wow it blows.

 Wait for its animation to start up. Wait for its animation to finish. Click
 an
 option.... it didn't work, sorry my browser isn't good enough.

 Usually I just abandon the site, but sometimes I can't. So switch to
 firefox 3.
 Wait for the animation to start up. Wait for it to finish. Click the thing.
 Wait
 for it to animate again. Oops, I got the wrong option, I'll just hit the
 down
 arrow.... sorry, didn't work.

 Aaaaaarrrrrgggggghhhhhh!

 "but but look at the super cool animations jquery is amazing! and i can
 style this
 thing better than the built in so nyah"

 Gah.



 Look, look -> There's my cake, and I'm eating it!


 This is one thing I love about running mutt in screen. If I have access to
 my home
 box at all (directly or ssh) it works well. If I left a message half read,
 when I
 come back to it, it is still half read! No need to hunt it down again among
 the
 read messages, no need to scroll back to my original position. The screen
 is
 *exactly* as I left it.

 Any my emails are *my* emails, stored on my local box. If I want to back it
 up,
 just copy the file. If I want a search that actually works, I can just grep
 the
 file, and so on. Just better in every way.
Dec 15 2010
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
 All of your complaints are about specific choices of the
 developers, not the technology.


Some killer limitations:

a) No real time networking. There is websockets aiming to correct this, but they
aren't actually working yet. Long polling gives surprisingly decent results, all
things considered, but it still sucks compared to real networking.

b) Cross domain communication requires ugly, inefficient hacks, or a proxy on
your
server.

c) No sounds (without flash anyway).

d) Graphics, even if you grant the canvas element, are a joke. The latency is
brutal. Take that deviant art thing from earlier in the thread. Flick your
mouse,
and watch the lines slowly catch up to you! Using X11 with a remote server is
faster than that.

e) Input requires a lot of magic. Some keys have the same identifiers, some of
the
time, meaning just checking for keypress requires dozens of lines of code, and
still doesn't work right! Checking for multiple keys or mouse buttons hit at
once
is very poor.

f) Very little state across loads (though html5 is adding something for this, if
it ever gets broad penetration), mentioned mainly for completeness, since
javascript variables do work for must things, but your persistent database still
has to be on the server.

g) No threading. I recently tried making a javascript -> d caller. In D, this
would be trivial: opDispatch means no code needs to be written, and if it runs
in
a different thread from the rest of the UI, it can make sync calls to the server
without freezing everything up, thus letting it be written in a linear style.

Now a set of linear calls to a network server might not be desirable anyway, but
sometimes it simplifies things a lot without a significant slowdown; it'd be
nice
to have it as an option.

But no can do in javascript. If you make a sync ajax request, the *entire
browser*
freezes up waiting on the response. Even if it is brief, this is really annoying
to the user.

Even with async calls, if you spend much time processing any one event, the
whole
thing grinds to a halt. It won't fire other events while waiting on you to
finish
the one, since the js environment is all one thread.


It's not too bad in practice most the time, but in those cases where I want to
just process in the background, it sucks hard.



I'll spare the list of Javascript mistakes, since quite a few of them could be
fixed in the library, except, ironically enough, loading that library yourself.
Wouldn't it be great to have an #include? Best you can do is check for some
global
to be defined, and if not, write a <script> element... which loads slowly so you
have to wait for it, which is a pain thanks to (g). Most libraries just seem to
require the user write the <script> tag himself in the html. So much for
encapsulating your dependencies.

But every lib that does this needs to carry those functions with it. Aargh.


Conclusion:
If the web were used as a document sharing system, most of these things would be
features rather than bugs. Who doesn't hate websites with sound anyway? But if
you
want to do applications on it, they are severe limitations.

Which brings me back to my first post in the thread: if you are doing a serious
application, 9/10 times you have to do all your real work on the server anyway,
with the client being just for simple display and input. External service
interaction is done on the server. The database interaction is done on the
server.
Any background tasks you want to run is done on the server. Sensitive data tends
to be handled on the server.


In the end, with so much work done on the server, there's very little left to do
on the client, so there's not much benefit from being able to choose a different
client side language.

And in those rare cases where you are doing a lot of client side work, it is so
brutally slow that if you start piling other runtimes on top of it, you'll often
be left with an unusable mess anyway!
Dec 15 2010
next sibling parent reply Andrew Wiley <debio264 gmail.com> writes:
On Wed, Dec 15, 2010 at 9:37 AM, Adam D. Ruppe <destructionator gmail.com>wrote:

 And in those rare cases where you are doing a lot of client side work, it
 is so
 brutally slow that if you start piling other runtimes on top of it, you'll
 often
 be left with an unusable mess anyway!



Unless you're using the beta of the next IE, the beta of the next Opera, or
the current version of Chrome, in which case you'd find that client-side
work is becoming more and more feasible. Now, it's not there yet, but when a
C-ported-to-Java-compiled-to-Javascript version of Quake 2 can get 30FPS in
Google Chrome, I start thinking that performance probably won't be nearly as
bad as browsers move forward.

You don't have to like it, but there's a huge push in web development
towards doing more work on the client, and now that browsers are catching
up, it's going to change the way the web works.

As for the rest:
a) No real time networking
HTML 5 WebSockets, as you said

b) Cross domain communication requires ugly, inefficient hacks, or a proxy
on your server.
This is the one thing you've listed that's not going to change because it
poses a security risk.

c) No sounds (without flash anyway).
Included in HTML 5.

d) Graphics, even if you grant the canvas element, are a joke. The latency
is
brutal. Take that deviant art thing from earlier in the thread. Flick your
mouse,
and watch the lines slowly catch up to you! Using X11 with a remote server
is
faster than that.
In Chrome (even the version a year or so old that is installed on the lab
computer I'm using right now), there is no latency whatsoever. That's a
simple matter of javascript performance, which is dramatically improving.

e) Input requires a lot of magic. Some keys have the same identifiers, some
of the
time, meaning just checking for keypress requires dozens of lines of code,
and
still doesn't work right! Checking for multiple keys or mouse buttons hit at
once
is very poor.
This is where frameworks can help. Now that Javascript performance is
barrelling ahead, frameworks start looking much more attractive. I've used
GWT (Java->Javascript) in the past, and input handling feels exactly like it
does in SWT or Swing (the leading Java UI frameworks).

f) Very little state across loads (though html5 is adding something for
this, if
it ever gets broad penetration), mentioned mainly for completeness, since
javascript variables do work for must things, but your persistent database
still
has to be on the server.
As you said, HTML5. My internet was down this morning, but I was still able
to read the batch of mail in GMail that I downloaded last night because
GMail is already taking advantage of Google Gears, which provides similar
functionality. I get the same thing with a few other web applications.

g) No threading. I recently tried making a javascript -> d caller. In D,
this
would be trivial: opDispatch means no code needs to be written, and if it
runs in
a different thread from the rest of the UI, it can make sync calls to the
server
without freezing everything up, thus letting it be written in a linear
style.
HTML5 adds WebWorkers, which handle exactly this use case (among others).
Dec 15 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"Andrew Wiley" <debio264 gmail.com> wrote in message 
news:mailman.1026.1292433894.21107.digitalmars-d puremagic.com...

 On Wed, Dec 15, 2010 at 9:37 AM, Adam D. Ruppe 
 <destructionator gmail.com>wrote:

 And in those rare cases where you are doing a lot of client side work, it
 is so
 brutally slow that if you start piling other runtimes on top of it, 
 you'll
 often
 be left with an unusable mess anyway!



 Unless you're using the beta of the next IE, the beta of the next Opera, 
 or
 the current version of Chrome, in which case you'd find that client-side
 work is becoming more and more feasible. Now, it's not there yet, but when 
 a
 C-ported-to-Java-compiled-to-Javascript version of Quake 2 can get 30FPS 
 in
 Google Chrome, I start thinking that performance probably won't be nearly 
 as
 bad as browsers move forward.


A game that was designed to run on a 90-133MHz 16-24MB RAM machine (in 
*software* rendering mode), and was frequently able to get framerates in the 
hundreds on sub-500MHz machines (using hardware rendering - with the old, 
old, old 3dfx cards), manages to get *only* 30FPS in JS on a multi-GHz 
multi-core machine using what is clearly hardware rendering (on a modern 
graphics card), and I'm supposed to think that means JS is fast? If 
anything, that's *proof* of how horrid JS is - it turns a multi-GHz 
multi-core into a Pentium ~100MHz. What a joke!


 [HTML5, HTML5, HTML5, Chrome, HTML5, HTML5...]


Yea, *eventually* HTML5 will *improve* a few things...That hardly counts as 
"The web's not a shitty platform!".

And what percentage of web users use Chrome? Less than 99%? Well then it 
doesn't make a damn bit of difference how great Chrome supposedly is, I'm 
not going to design my pages to require it, end of story, and I'm sure as 
hell not going to be one of those "This site best viewed with X browser" 
assholes.
Dec 15 2010
next sibling parent reply Andrew Wiley <debio264 gmail.com> writes:
On Wed, Dec 15, 2010 at 12:18 PM, Nick Sabalausky <a a.a> wrote:

 A game that was designed to run on a 90-133MHz 16-24MB RAM machine (in
 *software* rendering mode), and was frequently able to get framerates in
 the
 hundreds on sub-500MHz machines (using hardware rendering - with the old,
 old, old 3dfx cards), manages to get *only* 30FPS in JS on a multi-GHz
 multi-core machine using what is clearly hardware rendering (on a modern
 graphics card), and I'm supposed to think that means JS is fast? If
 anything, that's *proof* of how horrid JS is - it turns a multi-GHz
 multi-core into a Pentium ~100MHz. What a joke!


The point was that while Javascript is slow, it's getting fast enough to be
useful. Yes, it's not C. It will never be. But the fact that any sort of
realtime calculations are possible in it is a breakthrough that will be
reflected in actual application code.
Javascript was not designed to be fast, and honestly, it doesn't need to be
fast to fill it's niche.


 [HTML5, HTML5, HTML5, Chrome, HTML5, HTML5...]


 Yea, *eventually* HTML5 will *improve* a few things...That hardly counts as
 "The web's not a shitty platform!".


Well, there was a list of reasons why it was a shitty platform, and I showed
that it's not as shitty as it seems. Honestly, I agree that it's a shitty
platform in general, but it's also not nearly as bad as many people think it
is, and a lot of effort is going into reducing its relative shittiness.


 And what percentage of web users use Chrome? Less than 99%? Well then it
 doesn't make a damn bit of difference how great Chrome supposedly is, I'm
 not going to design my pages to require it, end of story, and I'm sure as
 hell not going to be one of those "This site best viewed with X browser"
 assholes.


Thus my explicit and repeated mentions of Opera, Firefox, and IE9 supporting
the same features. This isn't a Chrome only thing, and competition alone is
insuring that these features aren't Chrome-only. These aren't things coming
*eventually* to each browser, they're things that browser developers are
adding *now*.
Dec 15 2010
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Andrew Wiley" <debio264 gmail.com> wrote in message 
news:mailman.1030.1292438460.21107.digitalmars-d puremagic.com...

 On Wed, Dec 15, 2010 at 12:18 PM, Nick Sabalausky <a a.a> wrote:

 A game that was designed to run on a 90-133MHz 16-24MB RAM machine (in
 *software* rendering mode), and was frequently able to get framerates in
 the
 hundreds on sub-500MHz machines (using hardware rendering - with the old,
 old, old 3dfx cards), manages to get *only* 30FPS in JS on a multi-GHz
 multi-core machine using what is clearly hardware rendering (on a modern
 graphics card), and I'm supposed to think that means JS is fast? If
 anything, that's *proof* of how horrid JS is - it turns a multi-GHz
 multi-core into a Pentium ~100MHz. What a joke!


 The point was that while Javascript is slow, it's getting fast enough to 
 be
 useful. Yes, it's not C. It will never be. But the fact that any sort of
 realtime calculations are possible in it is a breakthrough that will be
 reflected in actual application code.
 Javascript was not designed to be fast, and honestly, it doesn't need to 
 be
 fast to fill it's niche.


 [HTML5, HTML5, HTML5, Chrome, HTML5, HTML5...]


 Yea, *eventually* HTML5 will *improve* a few things...That hardly counts 
 as
 "The web's not a shitty platform!".


 Well, there was a list of reasons why it was a shitty platform, and I 
 showed
 that it's not as shitty as it seems. Honestly, I agree that it's a shitty
 platform in general, but it's also not nearly as bad as many people think 
 it
 is, and a lot of effort is going into reducing its relative shittiness.


Fair enough. But I still think it would be far better for people to put 
their efforts into developing/pushing an alternate that's actually decent on 
a fundamental level than to blow all that effort on polishing a turd.


 These aren't things coming
 *eventually* to each browser, they're things that browser developers are
 adding *now*.


Are they in 99.9% of the browsers *actually being used now*? No, they're 
not. Deployment to user machines doesn't happen instantaneously, nor should 
it. You can talk about auto-update, but IMO anything that *forces* 
auto-updates is bad, bad, bad, bad, bad. (Optional auto-update is fine, of 
course.)
Dec 15 2010
parent reply David Nadlinger <see klickverbot.at> writes:
On 12/15/10 8:04 PM, Nick Sabalausky wrote:

 Are they in 99.9% of the browsers *actually being used now*?


As it was already discussed, this is not as much of an argument as it 
might seem – Windows x86 isn't used on 99.9% of all machines either…

David
Dec 15 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"David Nadlinger" <see klickverbot.at> wrote in message 
news:ieb3q0$1nc$1 digitalmars.com...

 On 12/15/10 8:04 PM, Nick Sabalausky wrote:

 Are they in 99.9% of the browsers *actually being used now*?


 As it was already discussed, this is not as much of an argument as it 
 might seem - Windows x86 isn't used on 99.9% of all machines either.


First of all, the percentage of user machines that are Windows is much much 
higher than the percentage of browsers being used that are bleeding-edge.

Secondly, If someones going to make a non-cross-platform desktop app these 
days, I'd consider that silly too. Maybe less silly, but only because it's 
notably easier to test a page with JS on/off and in multiple browsers than 
to test an app on multiple OSes, and because there is Wine.

Third, it's uncommon to need to use a *specific* non-cross-platform app. The 
vast majority of the time there are alternates available. But it's not 
uncommon at all for a website to not have an alternate equivalent. Trying to 
make an online payment to Visa or check on one of Visa's policies? Are you 
gonna be able to do that at MasterCard's website? With desktop software 
stuff like that rarely happens. Basically, websites/webapps have a greater 
need for compatibility than desktop apps do.
Dec 15 2010
parent reply Michael Stover <michael.r.stover gmail.com> writes:
Trying to


make an online payment to Visa or check on one of Visa's policies? Are you
gonna be able to do that at MasterCard's website? With desktop software
stuff like that rarely happens. Basically, websites/webapps have a greater
need for compatibility than desktop apps do.

Again, we're not talking about *websites*.  We're talking about web *apps*.
 Of course your bank site ought to provide you your account info whether you
are on a Mac or Windows and even if you use IE 5.5.  But that's not what
we're talking about.  We're talking about someone making an application
that, today or in the past you would have downloaded and installed, and
instead making it runnable in a browser.  It's not content, it's
*behavior*you're there for, and therefore, if they require Chrome and
you are a
devoted Firefox user, then you can find someone else who provides that
behavior in Firefox and use them instead.  There's no tie to some particular
content provided (like Visa), just like there isn't with desktop apps.

Mike

On Wed, Dec 15, 2010 at 3:14 PM, Nick Sabalausky <a a.a> wrote:


 "David Nadlinger" <see klickverbot.at> wrote in message
 news:ieb3q0$1nc$1 digitalmars.com...

 On 12/15/10 8:04 PM, Nick Sabalausky wrote:

 Are they in 99.9% of the browsers *actually being used now*?


 As it was already discussed, this is not as much of an argument as it
 might seem - Windows x86 isn't used on 99.9% of all machines either.


 First of all, the percentage of user machines that are Windows is much much
 higher than the percentage of browsers being used that are bleeding-edge.

 Secondly, If someones going to make a non-cross-platform desktop app these
 days, I'd consider that silly too. Maybe less silly, but only because it's
 notably easier to test a page with JS on/off and in multiple browsers than
 to test an app on multiple OSes, and because there is Wine.

 Third, it's uncommon to need to use a *specific* non-cross-platform app.
 The
 vast majority of the time there are alternates available. But it's not
 uncommon at all for a website to not have an alternate equivalent. Trying
 to
 make an online payment to Visa or check on one of Visa's policies? Are you
 gonna be able to do that at MasterCard's website? With desktop software
 stuff like that rarely happens. Basically, websites/webapps have a greater
 need for compatibility than desktop apps do.
Dec 15 2010
parent "Nick Sabalausky" <a a.a> writes:
"Michael Stover" <michael.r.stover gmail.com> wrote in message 
news:mailman.1039.1292444687.21107.digitalmars-d puremagic.com...

Trying to


 make an online payment to Visa or check on one of Visa's policies? Are you
 gonna be able to do that at MasterCard's website? With desktop software
 stuff like that rarely happens. Basically, websites/webapps have a greater
 need for compatibility than desktop apps do.

 Again, we're not talking about *websites*.  We're talking about web 
 *apps*.
 Of course your bank site ought to provide you your account info whether 
 you
 are on a Mac or Windows and even if you use IE 5.5.  But that's not what
 we're talking about.  We're talking about someone making an application
 that, today or in the past you would have downloaded and installed, and
 instead making it runnable in a browser.  It's not content, it's
 *behavior*you're there for, and therefore, if they require Chrome and
 you are a
 devoted Firefox user, then you can find someone else who provides that
 behavior in Firefox and use them instead.  There's no tie to some 
 particular
 content provided (like Visa), just like there isn't with desktop apps.


When you're arguing that web technologies aren't so bad, it must be an 
immense convenience to wave that magic wand and claim that one of the major 
counterpoints to your argument just simply doesn't count. We most certainly 
are are talking about both websites and webapps.

And frankly, even if we were just talking your overy-limited, IMO, 
definition of "webapp", it still makes no sense. They're much harder to get 
working well than real apps, take up more resources, and you have to use 
them through what's literally nothing more than a hacked-up document viewer. 
And none of that is going to change (most of it *can't*).

Fuck, we might as well be trying to find fast/effective ways to tunnel our 
code through Logo or GWBasic - you know, just for the fuck of it. Or find 
ways to get photos from a digital camera to a computer by tunneling it all 
through a printer and a scanner - just for the fuck of it. Sure, we might be 
able to get it to a "usable" level, but what would be the point? It would 
still be completely idiotic (except as just a "for shits and grins" kinda 
thing).

And yet, that's exactly what people making "webapps" (in your sense of the 
term) and webapp libraries and faster JS implementations are doing (and yet 
they're actually taking it all seriously!): they're tossing in utterly 
useless and mediocre-at-best layers that serve absolutely no damn purpose 
other than maybe to boost sales of more powerful PC hardware. There is no 
possible benefit of webapps that can't be handled perfectly fine, if not 
better, *without* trying to cram the whole damn thing through a web browser.
Dec 15 2010
prev sibling parent reply retard <re tard.com.invalid> writes:
Wed, 15 Dec 2010 12:40:50 -0600, Andrew Wiley wrote:


 The point was that while Javascript is slow, it's getting fast enough
 to be useful. Yes, it's not C. It will never be. But the fact that any
 sort of realtime calculations are possible in it is a breakthrough that
 will be reflected in actual application code. Javascript was not
 designed to be fast, and honestly, it doesn't need to be fast to fill
 it's niche.


I'm not getting this. WHY we should use Javascript/HTML5 applications 
instead. I'm perfectly happy with my existing tools. They work nicely. It 
takes years to develop these applications on top of HTML5. I simply have 
no motivation to use web applications. They have several downsides:

 - you "rent" the app, you don't "own" it anymore
   => which leads to: advertisements, monthly fees
   - this is especially bad if you're already using free as in beer/
speech software
   - this is especially bad ethically if you're writing free software

 - worse privacy (do I want some Mark SuckerBerg to spy on my personal 
life for personal gain)

 - worse security (a networkless local box IS quite safe, if CIA is 
raiding your house every week, you're probably doing something wrong, 
otherwise, buy better locks)

 - worse performance (at least now and in the next few years)

 - worse usability

 - worse reliability (network problems, server problems)

I know the good sides. No need to mention them. In my opinion the 
downsides are still more important when making the decision.
Dec 15 2010
parent reply Michael Stover <michael.r.stover gmail.com> writes:
On Wed, Dec 15, 2010 at 2:26 PM, retard <re tard.com.invalid> wrote:


 Wed, 15 Dec 2010 12:40:50 -0600, Andrew Wiley wrote:


 The point was that while Javascript is slow, it's getting fast enough
 to be useful. Yes, it's not C. It will never be. But the fact that any
 sort of realtime calculations are possible in it is a breakthrough that
 will be reflected in actual application code. Javascript was not
 designed to be fast, and honestly, it doesn't need to be fast to fill
 it's niche.


 I'm not getting this. WHY we should use Javascript/HTML5 applications
 instead. I'm perfectly happy with my existing tools. They work nicely. It
 takes years to develop these applications on top of HTML5. I simply have
 no motivation to use web applications. They have several downsides:

  - you "rent" the app, you don't "own" it anymore


Many would find that a benefit, as updates are automatic, never need to
install new versions.



   => which leads to: advertisements, monthly fees


Again, benefits galore for some folks.  Should I pay $80 to buy the software
and find out if I like it, and another $40 two years later to upgrade, or
pay $4/month and quit whenever I'm done with it?

  - this is especially bad if you're already using free as in beer/

 speech software


gmail is free as in beer and nothing prevents it being open source.



   - this is especially bad ethically if you're writing free software


There is no change here.


  - worse privacy (do I want some Mark SuckerBerg to spy on my personal
 life for personal gain)


Same issues with applications you install on your computer.  Perhaps they
are worse in that case, since so many people have so many problems with
malware, spyware, worms and viruses.



  - worse security (a networkless local box IS quite safe, if CIA is
 raiding your house every week, you're probably doing something wrong,
 otherwise, buy better locks)


Javascript+browser can be a purely client-machine application too just like
D or Java or C


  - worse performance (at least now and in the next few years)


Yes.  But if you take frame rates in games, which is a terrible example for
javascript, the more general truth is that beyond a certain point,
performance differences are undetectable to the human eye.  At which point,
the only thing driving your technology choice is developer productivity.
 Even before that point of undetectability, most people will choose the app
that provides more features over the one that performs somewhat better.  And
for good reason.  Something being a little slow vs not being able to do it
at all is an easy choice for most people.  People on this mailing list are
somewhat eccentric in their demands, which is entirely their right, but
y'all should at least recognize web apps are and will be successful by and
large.


  - worse usability


Completely disagree.  Desktop apps right now have an enormous advantage in
how much development-hours have gone into them over web app counterparts.
 This will change, quickly.



  - worse reliability (network problems, server problems)


In theory, yes, and once in a while it is a problem, but I honestly can't
remember the last time I had any issues with connectivity.



 I know the good sides. No need to mention them. In my opinion the
 downsides are still more important when making the decision.


Honestly, where do think things will stand 5-10 years from now?
Dec 15 2010
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Michael Stover" <michael.r.stover gmail.com> wrote in message 
news:mailman.1037.1292442333.21107.digitalmars-d puremagic.com...

 On Wed, Dec 15, 2010 at 2:26 PM, retard <re tard.com.invalid> wrote:


 Wed, 15 Dec 2010 12:40:50 -0600, Andrew Wiley wrote:


 The point was that while Javascript is slow, it's getting fast enough
 to be useful. Yes, it's not C. It will never be. But the fact that any
 sort of realtime calculations are possible in it is a breakthrough that
 will be reflected in actual application code. Javascript was not
 designed to be fast, and honestly, it doesn't need to be fast to fill
 it's niche.


 I'm not getting this. WHY we should use Javascript/HTML5 applications
 instead. I'm perfectly happy with my existing tools. They work nicely. It
 takes years to develop these applications on top of HTML5. I simply have
 no motivation to use web applications. They have several downsides:

  - you "rent" the app, you don't "own" it anymore


 Many would find that a benefit, as updates are automatic, never need to
 install new versions.


It's not uncommon for newer versions to be worse. Look at Acrobat Reader, 
iTunes, and Nero. A lot of people don't want to be forced into updates that 
make things worse. My Mom uses Hotmail and has a fit every time they decide 
to change everything around (which seems to be quite a lot). She'd be far 
happier with something that didn't work that way, but she sticks with it 
because she's every bit as much of a group-think lemming as everyone else.



   => which leads to: advertisements, monthly fees


 Again, benefits galore for some folks.  Should I pay $80 to buy the 
 software
 and find out if I like it, and another $40 two years later to upgrade, or
 pay $4/month and quit whenever I'm done with it?


Or get freeware/FLOSS and pay nothing and have no ads. And there's 
ad-supported desktop software too, so with desktop software you can go 
either way. Web apps can't go either way, because there's always the 
possibility the owner will pull the plug, and even if they don't, the ownser 
will still have server expenses which will have to get paid somehow.


  - worse privacy (do I want some Mark SuckerBerg to spy on my personal
 life for personal gain)


 Same issues with applications you install on your computer.  Perhaps they
 are worse in that case, since so many people have so many problems with
 malware, spyware, worms and viruses.


With my own computer, there are things I can do to prevent that. With 
webapps I'm 100% reliant on someone else: there isn't a damn thing I can do.


  - worse security (a networkless local box IS quite safe, if CIA is
 raiding your house every week, you're probably doing something wrong,
 otherwise, buy better locks)


 Javascript+browser can be a purely client-machine application too just 
 like
 D or Java or C


Yes, but what would be the point? It would be all downsides and no upsides. 
If you're going to have a local app it may as well be 
D/Java/C/Python/whatever.


  - worse performance (at least now and in the next few years)


 Yes.  But if you take frame rates in games, which is a terrible example 
 for
 javascript, the more general truth is that beyond a certain point,
 performance differences are undetectable to the human eye.


Which the vast majority of JS web apps are nowhere remotely near.


 At which point,
 the only thing driving your technology choice is developer productivity.


Which once again is a big vote *against* web-browser-as-a-platform.


  - worse usability


 Completely disagree.  Desktop apps right now have an enormous advantage in
 how much development-hours have gone into them over web app counterparts.
 This will change, quickly.


I've been hearing that for a long time. Still waiting. In the meantime, the 
only changes I've seen have been for the worse.


 I know the good sides. No need to mention them. In my opinion the
 downsides are still more important when making the decision.


 Honestly, where do think things will stand 5-10 years from now?


I shudder to even think...Nowhere good considering the directions things are 
moving.
Dec 15 2010
parent reply Michael Stover <michael.r.stover gmail.com> writes:
With my own computer, there are things I can do to prevent that. With


webapps I'm 100% reliant on someone else: there isn't a damn thing I can do.

But what about your group-think lemming mother?

On Wed, Dec 15, 2010 at 3:36 PM, Nick Sabalausky <a a.a> wrote:


 "Michael Stover" <michael.r.stover gmail.com> wrote in message
 news:mailman.1037.1292442333.21107.digitalmars-d puremagic.com...

 On Wed, Dec 15, 2010 at 2:26 PM, retard <re tard.com.invalid> wrote:


 Wed, 15 Dec 2010 12:40:50 -0600, Andrew Wiley wrote:


 The point was that while Javascript is slow, it's getting fast enough
 to be useful. Yes, it's not C. It will never be. But the fact that any
 sort of realtime calculations are possible in it is a breakthrough






 that

 will be reflected in actual application code. Javascript was not
 designed to be fast, and honestly, it doesn't need to be fast to fill
 it's niche.


 I'm not getting this. WHY we should use Javascript/HTML5 applications
 instead. I'm perfectly happy with my existing tools. They work nicely.




 It

 takes years to develop these applications on top of HTML5. I simply have
 no motivation to use web applications. They have several downsides:

  - you "rent" the app, you don't "own" it anymore


 Many would find that a benefit, as updates are automatic, never need to
 install new versions.


 It's not uncommon for newer versions to be worse. Look at Acrobat Reader,
 iTunes, and Nero. A lot of people don't want to be forced into updates that
 make things worse. My Mom uses Hotmail and has a fit every time they decide
 to change everything around (which seems to be quite a lot). She'd be far
 happier with something that didn't work that way, but she sticks with it
 because she's every bit as much of a group-think lemming as everyone else.



   => which leads to: advertisements, monthly fees


 Again, benefits galore for some folks.  Should I pay $80 to buy the
 software
 and find out if I like it, and another $40 two years later to upgrade, or
 pay $4/month and quit whenever I'm done with it?


 Or get freeware/FLOSS and pay nothing and have no ads. And there's
 ad-supported desktop software too, so with desktop software you can go
 either way. Web apps can't go either way, because there's always the
 possibility the owner will pull the plug, and even if they don't, the
 ownser
 will still have server expenses which will have to get paid somehow.


  - worse privacy (do I want some Mark SuckerBerg to spy on my personal
 life for personal gain)


 Same issues with applications you install on your computer.  Perhaps they
 are worse in that case, since so many people have so many problems with
 malware, spyware, worms and viruses.


 With my own computer, there are things I can do to prevent that. With
 webapps I'm 100% reliant on someone else: there isn't a damn thing I can
 do.


  - worse security (a networkless local box IS quite safe, if CIA is
 raiding your house every week, you're probably doing something wrong,
 otherwise, buy better locks)


 Javascript+browser can be a purely client-machine application too just
 like
 D or Java or C


 Yes, but what would be the point? It would be all downsides and no upsides.
 If you're going to have a local app it may as well be
 D/Java/C/Python/whatever.


  - worse performance (at least now and in the next few years)


 Yes.  But if you take frame rates in games, which is a terrible example
 for
 javascript, the more general truth is that beyond a certain point,
 performance differences are undetectable to the human eye.


 Which the vast majority of JS web apps are nowhere remotely near.


 At which point,
 the only thing driving your technology choice is developer productivity.


 Which once again is a big vote *against* web-browser-as-a-platform.


  - worse usability


 Completely disagree.  Desktop apps right now have an enormous advantage


 in

 how much development-hours have gone into them over web app counterparts.
 This will change, quickly.


 I've been hearing that for a long time. Still waiting. In the meantime, the
 only changes I've seen have been for the worse.


 I know the good sides. No need to mention them. In my opinion the
 downsides are still more important when making the decision.


 Honestly, where do think things will stand 5-10 years from now?


 I shudder to even think...Nowhere good considering the directions things
 are
 moving.
Dec 15 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"Michael Stover" <michael.r.stover gmail.com> wrote in message 
news:mailman.1041.1292446362.21107.digitalmars-d puremagic.com...

With my own computer, there are things I can do to prevent that. With


 webapps I'm 100% reliant on someone else: there isn't a damn thing I can 
 do.

 But what about your group-think lemming mother?


Unfortunately, she leaves the security and accessibility of her data at the 
mercy of MS's web monkeys. So tell me how exactly that's supposed to be an 
improvement over just keeping it on her local system? Yes, either way there 
are possible security risks. But there isn't a chance in hell a webapp can 
actually be considered better in that regard.
Dec 15 2010
parent reply Andrew Wiley <debio264 gmail.com> writes:
On Wed, Dec 15, 2010 at 3:16 PM, Nick Sabalausky <a a.a> wrote:


 "Michael Stover" <michael.r.stover gmail.com> wrote in message
 news:mailman.1041.1292446362.21107.digitalmars-d puremagic.com...

With my own computer, there are things I can do to prevent that. With


 webapps I'm 100% reliant on someone else: there isn't a damn thing I can
 do.

 But what about your group-think lemming mother?


 Unfortunately, she leaves the security and accessibility of her data at the
 mercy of MS's web monkeys. So tell me how exactly that's supposed to be an
 improvement over just keeping it on her local system? Yes, either way there
 are possible security risks. But there isn't a chance in hell a webapp can
 actually be considered better in that regard.


This is what you're not seeing. Web applications have zero-install,
zero-configuration, and while you've pointed out that people whine when they
change, those same people are already using them and continue to use them
anyway. Why? Ease of use.
The sad truth is that most computer users know next to nothing about how
their computer works, and when given the choice between a fully featured
email client they have to set up properly and a ready-to-go webmail system
like Gmail/Hotmail, the choice seems fairly obvious. The same average user
would probably say their data is safer with Microsoft than on their
computer, simply because Microsoft has experts working to maintain privacy
and backup, while the user might not even understand how he/she would go
about that sort of thing. Now, from the inside that we see as developers,
the picture isn't as pretty, but still. Computers and software are designed
and created by the elite for both the elite and the non-elite. When the
non-elite have a choice between doing it themselves and trusting it to the
elite, the rise of web applications shows that they will generally choose
the elite.
For power users, this choice just isn't the same.
Dec 15 2010
next sibling parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Thu, 16 Dec 2010 01:31:13 -0600, Andrew Wiley wrote:


 On Wed, Dec 15, 2010 at 3:16 PM, Nick Sabalausky <a a.a> wrote:
 

 "Michael Stover" <michael.r.stover gmail.com> wrote in message
 news:mailman.1041.1292446362.21107.digitalmars-d puremagic.com...

With my own computer, there are things I can do to prevent that.
With


 webapps I'm 100% reliant on someone else: there isn't a damn thing I
 can do.

 But what about your group-think lemming mother?


 Unfortunately, she leaves the security and accessibility of her data at
 the mercy of MS's web monkeys. So tell me how exactly that's supposed
 to be an improvement over just keeping it on her local system? Yes,
 either way there are possible security risks. But there isn't a chance
 in hell a webapp can actually be considered better in that regard.


 This is what you're not seeing. Web applications have zero-install,
 zero-configuration, and while you've pointed out that people whine when
 they change, those same people are already using them and continue to
 use them anyway. Why? Ease of use.
 The sad truth is that most computer users know next to nothing about how
 their computer works, and when given the choice between a fully featured
 email client they have to set up properly and a ready-to-go webmail
 system like Gmail/Hotmail, the choice seems fairly obvious. The same
 average user would probably say their data is safer with Microsoft than
 on their computer, simply because Microsoft has experts working to
 maintain privacy and backup, while the user might not even understand
 how he/she would go about that sort of thing. Now, from the inside that
 we see as developers, the picture isn't as pretty, but still. Computers
 and software are designed and created by the elite for both the elite
 and the non-elite. When the non-elite have a choice between doing it
 themselves and trusting it to the elite, the rise of web applications
 shows that they will generally choose the elite.
 For power users, this choice just isn't the same.


This just means that the "elite" has failed in ensuring that the obvious 
choice is the right one.

As you say, the average user will chose whatever looks simpler or more 
convenient, regardless of whether it actually *is* the best choice, 
performance- or security-wise.  (Or even with regards to user-
friendliness, once the seemingly insurmountable hurdles of installation 
and configuration have been passed.)  But that doesn't mean that 
developers should take advantage of that to push crappy applications on 
people.

Instead, developers should work to make local applications as easy to use 
as web applications, or to find a better way of serving applications over 
the internet than running them in a glorified document viewer.

-Lars
Dec 16 2010
parent reply Adam Ruppe <destructionator gmail.com> writes:
Lars T. Kyllingstad wrote:

 find a better way of serving applications over
 the internet than running them in a glorified document viewer.


This is something I've been (very) slowly working on for a while,
with my D Windowing System project.

My idea was to take a fairly high level GUI API and put it over
the network. By adding a middleman program, it can handle multiple
user sessions, and most importantly, remember state across dying
processes, without complicating the application. So if you leave
the program on your desktop and connect from your laptop, it is
just as you left it. Like what Remote Desktop does, but for
individual applications.

It doesn't just do gui either, since there's more to an application
than graphics. I included sound, files, and a little more in the
setup too. (A lot of inspiration from Remote Desktop.)

With a high level API, latency can be kept to a minimum by doing
local processing, and integration with the local system is done
simply by *not* micro-managing it - let the widgets do their default
whenever possible so the local operating system handles the details.


An interesting side effect of this is some dws applications actually can run in
the browser. I've written a partial javascript viewer
that, so far, runs my three demo applications (aim, notepad, and
calculator)! While it is not as good of an experience as using
the Windows viewer, it does work.

Though, notepad, calculator, and a buggy aim client aren't
particularly taxing to a GUI's capabilities. I still have a lot
of work to do before being able to make a confident public release.
Last time I spent a good chunk of time on it, I was doing a low
level event api. Very difficult to get that working as well as I
want given network lag, but not impossible.

(And, of course, these programs don't have to be run over a network.
 They work just as well as stand alone local apps, but I'd like the
 network still be as fast as possible.)
Dec 16 2010
parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Thu, 16 Dec 2010 13:54:24 +0000, Adam Ruppe wrote:


 Lars T. Kyllingstad wrote:

 find a better way of serving applications over the internet than
 running them in a glorified document viewer.


 
 This is something I've been (very) slowly working on for a while, with
 my D Windowing System project.


I know, and I'm very interested in that project.  I drop by your home 
page every once in a while to keep up to date, and I continually fight 
the urge to nag you about it. ;)

-Lars
Dec 16 2010
prev sibling parent reply Adam Ruppe <destructionator gmail.com> writes:
Andrew Wiley wrote:

 Web applications have zero-install


But they trade it in for registration, with those awful, awful
CAPTCHAs.

They don't just distinguish between humans and computers (sometimes).
They also distinguish between flawless humans with perfect vision
and expensive monitors and real life humans who can't see the
poorly contrasting colors or can't distinguish letters with a
font size of 8 pixels. Some have letters right on top of each
other.... what order do they want it? Gah.

It invariably takes me two or three attempts to get those stupid
things. Thankfully, the popular Re-Captcha ones are among the
easiest to read, but that doesn't help when someone still uses
the green on red with purple stripes and tiny font variety. It's
been a while since I saw the Google captcha, but I remember it
as being nearly impossible.


The worst part is they come back post-registration too! Vile.
Dec 16 2010
next sibling parent reply Michael Stover <michael.r.stover gmail.com> writes:
And CAPTCHAs prove that javascript and browsers are terrible???

You must have failed logic class.  Probably you never took it, knowing how
poorly you would do.

I should criticize your precious local apps because some require dongles.

On Thu, Dec 16, 2010 at 8:28 AM, Adam Ruppe <destructionator gmail.com>wrote:


 Andrew Wiley wrote:

 Web applications have zero-install


 But they trade it in for registration, with those awful, awful
 CAPTCHAs.

 They don't just distinguish between humans and computers (sometimes).
 They also distinguish between flawless humans with perfect vision
 and expensive monitors and real life humans who can't see the
 poorly contrasting colors or can't distinguish letters with a
 font size of 8 pixels. Some have letters right on top of each
 other.... what order do they want it? Gah.

 It invariably takes me two or three attempts to get those stupid
 things. Thankfully, the popular Re-Captcha ones are among the
 easiest to read, but that doesn't help when someone still uses
 the green on red with purple stripes and tiny font variety. It's
 been a while since I saw the Google captcha, but I remember it
 as being nearly impossible.


 The worst part is they come back post-registration too! Vile.
Dec 16 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"Michael Stover" <michael.r.stover gmail.com> wrote in message 
news:mailman.1053.1292506694.21107.digitalmars-d puremagic.com...

 And CAPTCHAs prove that javascript and browsers are terrible???


Where are you gettng that? That's not even remotely what he said. He was 
clearly saying that CAPTCHAs and registration are a counter-argument to the 
notion that most webapps are zero-config. Or at least that they're not 
really much better than having to do some basic config.
Dec 16 2010
next sibling parent retard <re tard.com.invalid> writes:
Thu, 16 Dec 2010 14:22:01 -0500, Nick Sabalausky wrote:


 "Michael Stover" <michael.r.stover gmail.com> wrote in message
 news:mailman.1053.1292506694.21107.digitalmars-d puremagic.com...

 And CAPTCHAs prove that javascript and browsers are terrible???


 Where are you gettng that? That's not even remotely what he said. He was
 clearly saying that CAPTCHAs and registration are a counter-argument to
 the notion that most webapps are zero-config. Or at least that they're
 not really much better than having to do some basic config.


This guy is trolling here. Any sane person would have already given up. 
This discussion is more or less useless.
Dec 16 2010
prev sibling parent Michael Stover <michael.r.stover gmail.com> writes:
On Thu, Dec 16, 2010 at 2:22 PM, Nick Sabalausky <a a.a> wrote:


 "Michael Stover" <michael.r.stover gmail.com> wrote in message
 news:mailman.1053.1292506694.21107.digitalmars-d puremagic.com...

 And CAPTCHAs prove that javascript and browsers are terrible???


 Where are you gettng that? That's not even remotely what he said. He was
 clearly saying that CAPTCHAs and registration are a counter-argument to the
 notion that most webapps are zero-config. Or at least that they're not
 really much better than having to do some basic config.

 The conversation was about technologies, not specific webapps. The


emotional outburst that began this aspect of the discussion was that
javascript sucks, period, end of story, without any possibility of ever
being otherwise.  CAPTCHAs are irrelevant.
Dec 16 2010
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Adam Ruppe" <destructionator gmail.com> wrote in message 
news:ied469$2qg4$1 digitalmars.com...

 Thankfully, the popular Re-Captcha ones are among the
 easiest to read, but that doesn't help when someone still uses
 the green on red with purple stripes and tiny font variety.


Re-Captcha also doen't help when JS is off. ( Actually, that's the only 
reason I use TangoCMS's default captcha instead of Re-Captcha on my 
bitch-and-whine site (I'm irrationally not calling it a "blog"): 
https://www.semitwist.com/articles )
Dec 16 2010
prev sibling parent reply retard <re tard.com.invalid> writes:
First, I have to ask, wtf are you using to post these. I can't even reply 
to you. The text area is empty, when I press 'reply'. It breaks pan, a 
standards-compliant nntp client.

Wed, 15 Dec 2010 14:45:23 -0500, Michael Stover wrote:


 at 2:26 PM, retard <re tard.com.invalid> wrote:
 

 Wed, 15 Dec 2010 12:40:50 -0600, Andrew Wiley wrote:


 The point was that while Javascript is slow, it's getting fast enough
 to be useful. Yes, it's not C. It will never be. But the fact that
 any sort of realtime calculations are possible in it is a
 breakthrough that will be reflected in actual application code.
 Javascript was not designed to be fast, and honestly, it doesn't need
 to be fast to fill it's niche.


 I'm not getting this. WHY we should use Javascript/HTML5 applications
 instead. I'm perfectly happy with my existing tools. They work nicely.
 It takes years to develop these applications on top of HTML5. I simply
 have no motivation to use web applications. They have several
 downsides:

  - you "rent" the app, you don't "own" it anymore


 Many would find that a benefit, as updates are automatic, never need to
 install new versions.


I can assure you, the automatic updates work nicely in Linux land (use a 
stable distro) and also many Windows programs now handle it nicely. And 
often I don't even need them. As a sw developer I do want to hack with my 
programs. I want to own my software to avoid VLI. I want to own it to make 
sure it contains no backdoors or ad/spyware features.


   => which leads to: advertisements, monthly fees


 Again, benefits galore for some folks.  Should I pay $80 to buy the
 software and find out if I like it, and another $40 two years later to
 upgrade, or pay $4/month and quit whenever I'm done with it?


I think at some point the software becomes good enough. There has to be a 
balance between the number of features and stability and all. Human mind 
can't handle arbitrary complexity. At that point the feature development 
should stop. At that point the price should approach zero. I don't want 
to pay just to get nothing in return. In become way too familiar with 
this in the Windows Exchange/AD/Office/Windows leash land.

For example email and instant messaging. I have probably 50..100 
different email clients and IM clients in the distro's repositories. And 
you're saying that I should suddenly start paying or watching ads to use 
that functionality I've taken for granted since I was born. Seriously 
what the fuck.


 
   - this is especially bad if you're already using free as in beer/

 speech software


 gmail is free as in beer and nothing prevents it being open source.


Oh really? Where are the sources?


   - this is especially bad ethically if you're writing free software


 There is no change here.


What? The time you spend on non-free software reduces the time you spent 
improving free software.


  - worse privacy (do I want some Mark SuckerBerg to spy on my personal
 life for personal gain)


 Same issues with applications you install on your computer.  Perhaps
 they are worse in that case, since so many people have so many problems
 with malware, spyware, worms and viruses.


They use the wrong operating system and in general are idiots. Ever heard 
of Facebook privacy issues? http://img220.imageshack.us/
img220/4271/129228102781.jpg just to name one. They get fixed, but before 
the fix is applied, some real world people get harmed.

Another downside of web apps is that less developer time is spent on 
local applications. This is bad news for us old skool folks.



  - worse security (a networkless local box IS quite safe, if CIA is
 raiding your house every week, you're probably doing something wrong,
 otherwise, buy better locks)


 Javascript+browser can be a purely client-machine application too just
 like D or Java or C


Why the F would I want to use this inferior platform? Write me a Blender 
in Javascript. The only reason I'd choose it is when it's a better tool 
for the task.


  - worse usability


 Completely disagree.  Desktop apps right now have an enormous advantage
 in how much development-hours have gone into them over web app
 counterparts.
  This will change, quickly.


I meant now. Stop talking about the potential. It's not here yet. 


  - worse reliability (network problems, server problems)


 In theory, yes, and once in a while it is a problem, but I honestly
 can't remember the last time I had any issues with connectivity.


If you travel a lot or don't live in an urban environment, you see that 
connectivity sucks in many places. And on top of that the charges per 
megabyte are enormous abroad. At home, at least my ISP fails to keep the 
DHCP/DNS servers and routers up several times each year. If I only had 
web apps, I'd be screwed. I would need to buy two independent network 
connections, preferably both wireless and wired.


 I know the good sides. No need to mention them. In my opinion the
 downsides are still more important when making the decision.


 Honestly, where do think things will stand 5-10 years from now?


Thanks to advocates like you, we're totally fucked up.
Dec 15 2010
parent reply Michael Stover <michael.r.stover gmail.com> writes:
Ugh, the reading comprehension here is abysmal.  Ciao, I'm off to fuck up
your future and enjoy every moment of it.

On Wed, Dec 15, 2010 at 3:54 PM, retard <re tard.com.invalid> wrote:


 First, I have to ask, wtf are you using to post these. I can't even reply
 to you. The text area is empty, when I press 'reply'. It breaks pan, a
 standards-compliant nntp client.

 Wed, 15 Dec 2010 14:45:23 -0500, Michael Stover wrote:


 at 2:26 PM, retard <re tard.com.invalid> wrote:


 Wed, 15 Dec 2010 12:40:50 -0600, Andrew Wiley wrote:


 The point was that while Javascript is slow, it's getting fast enough
 to be useful. Yes, it's not C. It will never be. But the fact that
 any sort of realtime calculations are possible in it is a
 breakthrough that will be reflected in actual application code.
 Javascript was not designed to be fast, and honestly, it doesn't need
 to be fast to fill it's niche.


 I'm not getting this. WHY we should use Javascript/HTML5 applications
 instead. I'm perfectly happy with my existing tools. They work nicely.
 It takes years to develop these applications on top of HTML5. I simply
 have no motivation to use web applications. They have several
 downsides:

  - you "rent" the app, you don't "own" it anymore


 Many would find that a benefit, as updates are automatic, never need to
 install new versions.


 I can assure you, the automatic updates work nicely in Linux land (use a
 stable distro) and also many Windows programs now handle it nicely. And
 often I don't even need them. As a sw developer I do want to hack with my
 programs. I want to own my software to avoid VLI. I want to own it to make
 sure it contains no backdoors or ad/spyware features.


   => which leads to: advertisements, monthly fees


 Again, benefits galore for some folks.  Should I pay $80 to buy the
 software and find out if I like it, and another $40 two years later to
 upgrade, or pay $4/month and quit whenever I'm done with it?


 I think at some point the software becomes good enough. There has to be a
 balance between the number of features and stability and all. Human mind
 can't handle arbitrary complexity. At that point the feature development
 should stop. At that point the price should approach zero. I don't want
 to pay just to get nothing in return. In become way too familiar with
 this in the Windows Exchange/AD/Office/Windows leash land.

 For example email and instant messaging. I have probably 50..100
 different email clients and IM clients in the distro's repositories. And
 you're saying that I should suddenly start paying or watching ads to use
 that functionality I've taken for granted since I was born. Seriously
 what the fuck.


   - this is especially bad if you're already using free as in beer/

 speech software


 gmail is free as in beer and nothing prevents it being open source.


 Oh really? Where are the sources?


   - this is especially bad ethically if you're writing free software


 There is no change here.


 What? The time you spend on non-free software reduces the time you spent
 improving free software.


  - worse privacy (do I want some Mark SuckerBerg to spy on my personal
 life for personal gain)


 Same issues with applications you install on your computer.  Perhaps
 they are worse in that case, since so many people have so many problems
 with malware, spyware, worms and viruses.


 They use the wrong operating system and in general are idiots. Ever heard
 of Facebook privacy issues? http://img220.imageshack.us/
 img220/4271/129228102781.jpg just to name one. They get fixed, but before
 the fix is applied, some real world people get harmed.

 Another downside of web apps is that less developer time is spent on
 local applications. This is bad news for us old skool folks.



  - worse security (a networkless local box IS quite safe, if CIA is
 raiding your house every week, you're probably doing something wrong,
 otherwise, buy better locks)


 Javascript+browser can be a purely client-machine application too just
 like D or Java or C


 Why the F would I want to use this inferior platform? Write me a Blender
 in Javascript. The only reason I'd choose it is when it's a better tool
 for the task.


  - worse usability


 Completely disagree.  Desktop apps right now have an enormous advantage
 in how much development-hours have gone into them over web app
 counterparts.
  This will change, quickly.


 I meant now. Stop talking about the potential. It's not here yet.


  - worse reliability (network problems, server problems)


 In theory, yes, and once in a while it is a problem, but I honestly
 can't remember the last time I had any issues with connectivity.


 If you travel a lot or don't live in an urban environment, you see that
 connectivity sucks in many places. And on top of that the charges per
 megabyte are enormous abroad. At home, at least my ISP fails to keep the
 DHCP/DNS servers and routers up several times each year. If I only had
 web apps, I'd be screwed. I would need to buy two independent network
 connections, preferably both wireless and wired.


 I know the good sides. No need to mention them. In my opinion the
 downsides are still more important when making the decision.


 Honestly, where do think things will stand 5-10 years from now?


 Thanks to advocates like you, we're totally fucked up.
Dec 15 2010
parent "Nick Sabalausky" <a a.a> writes:
"Michael Stover" <michael.r.stover gmail.com> wrote in message 
news:mailman.1042.1292447042.21107.digitalmars-d puremagic.com...

 Ugh, the reading comprehension here is abysmal.  Ciao, I'm off to fuck up
 your future and enjoy every moment of it.


Hooked on Phonics might help you with that reading comprehension problem of 
yours.
Dec 15 2010
prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
Nick Sabalausky wrote:

 that's *proof* of how horrid JS is


I often feel Google is re-discovering DOS' capabilities and going on about how
great it is. Got it in graphics and input, and files too.

HTML5 local storage is a bunch of key/item pairs. Wooo, it's like a filesystem
with only a root directory!

I wonder if it even works to store interesting data. When I was working on the
DWS/AJAX viewer (Which I still intend to finish if I get a decent break from
work... that I don't spend flamewarring on the newsgroup), I tried to get a
binary
string sent down, manipulated, and finally displayed as an image.

But:

var img = new Image(binaryData); // didn't work

Some browsers supported a img.src = "data://" + encodedBinaryData, but not all
of
them did, and the limit was obscenely small anyway.

I ultimately just served it from the server and referenced it via url. But I had
that option since there was a server app available... what would the local
storage do?


Blargh.



 I'm sure as hell not going to be one of
 those "This site best viewed with X browser" assholes.


I might be one of those people, though I don't come out and say it, my sites do
tend to be best viewed with X browser.

But the important difference is it still *works* in Y and Z browser. It just
won't
have rounded corners, etc.
Dec 15 2010
next sibling parent reply Michael Stover <michael.r.stover gmail.com> writes:
And no, I'm *not* playing semantics games here: "Distributed via the


web" means exactly what it means

Of course you're playing semantic games.  Not being very helpful in the
discussion.  You seem to be arguing that if the content arrived via "http"
it must work in lynx or else it "sucks".  Perhaps I will just rename it to
"ws" and then you can have some new expectations that don't cloud your
judgement so.

On Wed, Dec 15, 2010 at 1:51 PM, Adam D. Ruppe <destructionator gmail.com>wrote:


 Nick Sabalausky wrote:

 that's *proof* of how horrid JS is


 I often feel Google is re-discovering DOS' capabilities and going on about
 how
 great it is. Got it in graphics and input, and files too.

 HTML5 local storage is a bunch of key/item pairs. Wooo, it's like a
 filesystem
 with only a root directory!

 I wonder if it even works to store interesting data. When I was working on
 the
 DWS/AJAX viewer (Which I still intend to finish if I get a decent break
 from
 work... that I don't spend flamewarring on the newsgroup), I tried to get a
 binary
 string sent down, manipulated, and finally displayed as an image.

 But:

 var img = new Image(binaryData); // didn't work

 Some browsers supported a img.src = "data://" + encodedBinaryData, but not
 all of
 them did, and the limit was obscenely small anyway.

 I ultimately just served it from the server and referenced it via url. But
 I had
 that option since there was a server app available... what would the local
 storage do?


 Blargh.



 I'm sure as hell not going to be one of
 those "This site best viewed with X browser" assholes.


 I might be one of those people, though I don't come out and say it, my
 sites do
 tend to be best viewed with X browser.

 But the important difference is it still *works* in Y and Z browser. It
 just won't
 have rounded corners, etc.
Dec 15 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"Michael Stover" <michael.r.stover gmail.com> wrote in message 
news:mailman.1034.1292441124.21107.digitalmars-d puremagic.com...

And no, I'm *not* playing semantics games here: "Distributed via the


 web" means exactly what it means

 Of course you're playing semantic games.  Not being very helpful in the
 discussion.  You seem to be arguing that if the content arrived via "http"
 it must work in lynx or else it "sucks".


Not at all. In fact that blatantly contradicts what I just pointed out. 
Things like DMD, certain OSes, etc, all arrive via http (or ftp, whatever, 
like that matters) and yet, like I said, they're obviously not what we're 
talking about when we're talking about web apps.

Secondly, I'm not the one that brought up Lynx. Although if there's 
something that clearly doesn't need graphics and such to be useful, then 
yes, it absolutely should work on Lynx. Apps obviously shouldn't require 
things they don't need: My DB shouldn't require I have a webcam installed. 
Grep shouldn't require an email client. Making a backup shouldn't require 
OpenGL or a printer. Submitting a form or downloading a PDF shouldn't 
require JS or HTML images. Viewing information on an official county probate 
court website shouldn't require Flash (I've actually seen that, and I'd be 
very surprised if it doesn't violate multiple government-mandated 
accessibility requirements). Etc.
Dec 15 2010
parent reply Michael Stover <michael.r.stover gmail.com> writes:
If I provide a spreadsheet program via javascript, why should it have to
work in Lynx? It's not a web page.  I'm providing absolutely ZERO content.
 It is only behavior, just like Excel is only behavior.  If I provide the
same functionality, but only if you use Chrome or Firefox, why is that so
horrible?

On Wed, Dec 15, 2010 at 2:50 PM, Nick Sabalausky <a a.a> wrote:


 "Michael Stover" <michael.r.stover gmail.com> wrote in message
 news:mailman.1034.1292441124.21107.digitalmars-d puremagic.com...

And no, I'm *not* playing semantics games here: "Distributed via the


 web" means exactly what it means

 Of course you're playing semantic games.  Not being very helpful in the
 discussion.  You seem to be arguing that if the content arrived via


 "http"

 it must work in lynx or else it "sucks".


 Not at all. In fact that blatantly contradicts what I just pointed out.
 Things like DMD, certain OSes, etc, all arrive via http (or ftp, whatever,
 like that matters) and yet, like I said, they're obviously not what we're
 talking about when we're talking about web apps.

 Secondly, I'm not the one that brought up Lynx. Although if there's
 something that clearly doesn't need graphics and such to be useful, then
 yes, it absolutely should work on Lynx. Apps obviously shouldn't require
 things they don't need: My DB shouldn't require I have a webcam installed.
 Grep shouldn't require an email client. Making a backup shouldn't require
 OpenGL or a printer. Submitting a form or downloading a PDF shouldn't
 require JS or HTML images. Viewing information on an official county
 probate
 court website shouldn't require Flash (I've actually seen that, and I'd be
 very surprised if it doesn't violate multiple government-mandated
 accessibility requirements). Etc.
Dec 15 2010
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
Michael Stover wrote:

 If I provide a spreadsheet program via javascript,
 why should it have to work in Lynx?


It doesn't necessarily have to work, but it should degrade gracefully. If it
goes
all the way down the Lynx gracefully, that means it is most likely usable by
everyone.

For a spreadsheet, I'd output the data in an html table. Now all users can at
least view the saved document, with no extra effort from you.
Dec 15 2010
next sibling parent reply Michael Stover <michael.r.stover gmail.com> writes:
Do you complain that Excel doesn't not "degrade gracefully"?  Why would
someone even think to load the app in lynx?  Do you load excel files in
lynx?

On Wed, Dec 15, 2010 at 3:32 PM, Adam D. Ruppe <destructionator gmail.com>wrote:


 Michael Stover wrote:

 If I provide a spreadsheet program via javascript,
 why should it have to work in Lynx?


 It doesn't necessarily have to work, but it should degrade gracefully. If
 it goes
 all the way down the Lynx gracefully, that means it is most likely usable
 by everyone.

 For a spreadsheet, I'd output the data in an html table. Now all users can
 at
 least view the saved document, with no extra effort from you.
Dec 15 2010
parent Adam D. Ruppe <destructionator gmail.com> writes:
 Do you complain that Excel doesn't not "degrade gracefully"?


No, because it does the right thing! It works in Win7, Win Vista, Win XP. It's
files (if you pick the right format when saving as) can be loaded up in Office
2010, Office 2007, and Office 2003, as well as a million other program. Save as
csv and it gracefully degrades all the way down to opening in Notepad!

Some desktop apps don't do the right thing though, and those ones suck. So I
don't
have a mp3 lib installed. I should still be able to save as a .wav! Some apps
work
like that. Some don't. The ones that don't suck.

I used Windows 98 for a long time. A *well written* Windows XP program would
work
perfectly on XP (including themeing support, etc), and also work almost as well
on
Win 98, just dropping the new XP features, while doing its best everywhere else.
Dec 15 2010
prev sibling parent reply David Nadlinger <see klickverbot.at> writes:
On 12/15/10 9:32 PM, Adam D. Ruppe wrote:

 For a spreadsheet, I'd output the data in an html table. Now all users can at
 least view the saved document, with no extra effort from you.


You are confusing the web application and the data it operates on here – 
of course, a spreadsheet application should provide some means to export 
the tables you created with it in an easily accessible format, e.g. HTML 
or PDF. But this piece of data created by the exporting routines of the 
web application is not linked to the application itself per se…

Although e.g. whether you want to rely on storing and processing your 
data (at least partly) on some server cluster you have no control over 
is an entirely different question worth to be discussed in detail, I 
don't quite see how lack of graceful degradation can be a valid argument 
against web applications – or have you ever tried running the latest 
Microsoft Office suite on Windows 3.11?

David
Dec 15 2010
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
David Nadlinger:

 You are confusing the web application and the data it operates on here


The thing is a web application is built on top of its data, almost
literally. Javascript manipulates an HTML document, and you need
to give it one to get started, even if it is an empty document.

If you give the javascript a usable HTML document as its starting
point, you can have your app with scripts available, and still have
the document when the scripts aren't available.

Let me do an example app, hopefully it won't be butchered too
much in transport.

Output this from your server side program:
<table>
<caption>Thread Participants</caption>
<tr>
   <td>Adam</td><td>Ruppe</td>
</tr>
<tr>
   <td>David</td><td>Nadlinger</td>
</tr>
</table>


If you go to that page in any browser, from Lynx up, you have a usable table of
data to look at.

Now add editing.js to it:

=====
function makeEditable() {
    var input = document.createElement("input");
    input.value = this.innerHTML;
    this.onclick = null;
    input.onblur = function() {
         post("/update-cell", { "row" : getRow(this), "column" :
getColumn(this),
"value" : input.value }, function(response) {

              this.onclick = makeEditable;
              this.innerHTML = response;
         });
    }

    this.innerHTML = "";
    this.appendChild(input);
}

window.onload = function() {
  var items = document.getElementsByTagName("td");
  for(var a = 0; a < items.length; a++) {
     var item = items[a];
     item.onclick = makeEditable;
  }
}

=======

Now, if you do have a browser with scripting capabilities, this runs through the
already usable document and makes it more usable, by adding the inline editing
capability. It's now a primitive web app, while still being a usable web page to
browsers without all the fancy capabilities.

(Note that I wrote this on the fly here, without testing. I don't know if it
would
actually run correctly or not. Another thing that sucks about the browser
platform... it's not complex code, but I have no confidence in it without
testing
across them all.)



This is all I'm asking for with the "works in Lynx" thing. Start with a regular
webpage and build up. You are still on the web, still accessible from all these
browsers. You should at least follow the basic html standards well enough so
they
aren't completely screwed and left behind.

How much do you build up? I say not too much, since before long you'll hit a
wall
where the browser just sucks too much. But that's a separate concern from
graceful
degradation.

Remember, the practical benefit to this isn't working for Lynx users, but for
the
~20% of today's market with noscript installed, or stuck on IE6, or on
underpowered mobile phones, etc.

Or if you take a step up, depending on HTML5 stuff even locks out IE7 and some
IE8, Firefox, and Opera users. But if your site is still built on a solid
foundation, they won't be left behind either.
Dec 15 2010
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
Tangentially related to this thread. I just went back to my work to-do list,
which
the rest of the team puts up on a Google Doc.

I *loathe* Google Docs, for a lot of reasons. But one more: my X11 selection
doesn't work. This is with Firefox 3.6.

In Linux, with most programs, you can select text, then middle click in a text
input box to instantly paste it. This includes standard html text in the web
browsers.

... but not Google Docs text. It highlights in a weird looking color, not
matching
the rest of my system. It lags as I drag or scroll. And it doesn't update the X
selection, so when I middle click out of habit... the wrong thing happens.
AAAAarrrrrrggggghhhh!


Those javascript things never pay attention to details, and even those that do
don't know the quirks of platforms or individual user setup, and even if they do
know, there's nothing they can do about it!


Now, if they just output a standard html document, these details would be
handled
properly. Firefox itself knows it is a Linux program, has access to the Linux
APIs, and manages them somewhat well.

Or if it was a standard doc, I could open it in my other browser and maybe it'd
do
a better job.

But nope, open it in my no-script Konqueror 3.5, and it just says

===
Google Docs is not supported in your browser.   Learn more   Dismiss
===

And a blank screen under it. I can't even view the text, despite it being just
text. Fucking garbage.
Dec 15 2010
parent reply Michael Stover <michael.r.stover gmail.com> writes:
So much hate because you can't middle-click paste.  Swearing and
AAArrrrggghhing, "loathing", etc.  It's childish and hard to take such
attitudes seriously.  The world moves on and doesn't care that you can't
adapt to the simplest of things.

On Wed, Dec 15, 2010 at 5:20 PM, Adam D. Ruppe <destructionator gmail.com>wrote:


 Tangentially related to this thread. I just went back to my work to-do
 list, which
 the rest of the team puts up on a Google Doc.

 I *loathe* Google Docs, for a lot of reasons. But one more: my X11
 selection
 doesn't work. This is with Firefox 3.6.

 In Linux, with most programs, you can select text, then middle click in a
 text
 input box to instantly paste it. This includes standard html text in the
 web browsers.

 ... but not Google Docs text. It highlights in a weird looking color, not
 matching
 the rest of my system. It lags as I drag or scroll. And it doesn't update
 the X
 selection, so when I middle click out of habit... the wrong thing happens.
 AAAAarrrrrrggggghhhh!


 Those javascript things never pay attention to details, and even those that
 do
 don't know the quirks of platforms or individual user setup, and even if
 they do
 know, there's nothing they can do about it!


 Now, if they just output a standard html document, these details would be
 handled
 properly. Firefox itself knows it is a Linux program, has access to the
 Linux
 APIs, and manages them somewhat well.

 Or if it was a standard doc, I could open it in my other browser and maybe
 it'd do
 a better job.

 But nope, open it in my no-script Konqueror 3.5, and it just says

 ===
 Google Docs is not supported in your browser.   Learn more   Dismiss
 ===

 And a blank screen under it. I can't even view the text, despite it being
 just
 text. Fucking garbage.
Dec 15 2010
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
 So much hate because you can't middle-click paste.


It's illustrative of a bigger overall problem: there's no integration with the
external environment; no use of native capabilities, ignoring user system
setups,
and not even integration with other web apps. With a Windows program, you can
set
up a user theme. Well behaved programs will honor your colors, layouts, etc.

One of the reasons I stick to my old Konqueror is it uses the website icon and
title in my system taskbar and tries to honor my user settings. Most browsers
don't even try that, but even with konq, the integration is quite poor.

While web apps could, in theory, get some consistency with user defined
stylesheets, in practice, this would just break sites, since they are all so
accustomed to being independent.

It's just like DOS. Except DOS apps could actually /use/ the hardware available
to
them...
Dec 15 2010
parent reply Michael Stover <michael.r.stover gmail.com> writes:
 there's no integration with the


external environment

But it is an advantage at the same time as it's a weakness.  The advantage
is, I can read and use gmail or google docs anywhere, firewall or not.

I could sit here at home, open an openoffice doc, write in it, save it.
 Then tomorrow go to work, open open office and bitch and scream about why
the doc I made last night at home isn't in my recent docs list!! ZOMG!!! I
*LOATHE* Open Office!  I can't do the simplest thing!  But, no, I recognize
the limitations of the different mediums, and rather than look at what is
not exactly the same as what I'm used to, I can see what it does that I've
not been able to do before.  If you'd asked me 1 year ago about javascript,
I would have laughed and said no way I would want to use that crap.  I've
learned to think otherwise since.

If you go looking for problems, you're going to find them.  To me, it simply
indicates inflexibility on your part.  Which is fine, like I said, the world
doesn't care about your inability to adapt and see new possibilities.

It's just, the strength of the emotional response in this thread has been
kind of revealing.

Mike

On Wed, Dec 15, 2010 at 9:20 PM, Adam D. Ruppe <destructionator gmail.com>wrote:


 So much hate because you can't middle-click paste.


 It's illustrative of a bigger overall problem: there's no integration with
 the
 external environment; no use of native capabilities, ignoring user system
 setups,
 and not even integration with other web apps. With a Windows program, you
 can set
 up a user theme. Well behaved programs will honor your colors, layouts,
 etc.

 One of the reasons I stick to my old Konqueror is it uses the website icon
 and
 title in my system taskbar and tries to honor my user settings. Most
 browsers
 don't even try that, but even with konq, the integration is quite poor.

 While web apps could, in theory, get some consistency with user defined
 stylesheets, in practice, this would just break sites, since they are all
 so
 accustomed to being independent.

 It's just like DOS. Except DOS apps could actually /use/ the hardware
 available to
 them...
Dec 15 2010
next sibling parent reply Adam Chandler <adam paradise.com> writes:
Michael Stover Wrote:


 there's no integration with the


 external environment
 
 But it is an advantage at the same time as it's a weakness.  The advantage
 is, I can read and use gmail or google docs anywhere, firewall or not.
 
 I could sit here at home, open an openoffice doc, write in it, save it.
  Then tomorrow go to work, open open office and bitch and scream about why
 the doc I made last night at home isn't in my recent docs list!! ZOMG!!! I
 *LOATHE* Open Office!  I can't do the simplest thing!  But, no, I recognize
 the limitations of the different mediums, and rather than look at what is
 not exactly the same as what I'm used to, I can see what it does that I've
 not been able to do before.  If you'd asked me 1 year ago about javascript,
 I would have laughed and said no way I would want to use that crap.  I've
 learned to think otherwise since.
 
 If you go looking for problems, you're going to find them.  To me, it simply
 indicates inflexibility on your part.  Which is fine, like I said, the world
 doesn't care about your inability to adapt and see new possibilities.
 
 It's just, the strength of the emotional response in this thread has been
 kind of revealing.


Dear Mike, you're one of the most annoying wankers I've seen. Go f** yourself
or even better, go kill yourself. TYVM let us have a nice day.
Dec 16 2010
parent "Nick Sabalausky" <a a.a> writes:
"Adam Chandler" <adam paradise.com> wrote in message 
news:iecv7f$1n1o$1 digitalmars.com...

 Michael Stover Wrote:


 there's no integration with the


 external environment

 But it is an advantage at the same time as it's a weakness.  The 
 advantage
 is, I can read and use gmail or google docs anywhere, firewall or not.

 I could sit here at home, open an openoffice doc, write in it, save it.
  Then tomorrow go to work, open open office and bitch and scream about 
 why
 the doc I made last night at home isn't in my recent docs list!! ZOMG!!! 
 I
 *LOATHE* Open Office!  I can't do the simplest thing!  But, no, I 
 recognize
 the limitations of the different mediums, and rather than look at what is
 not exactly the same as what I'm used to, I can see what it does that 
 I've
 not been able to do before.  If you'd asked me 1 year ago about 
 javascript,
 I would have laughed and said no way I would want to use that crap.  I've
 learned to think otherwise since.

 If you go looking for problems, you're going to find them.  To me, it 
 simply
 indicates inflexibility on your part.  Which is fine, like I said, the 
 world
 doesn't care about your inability to adapt and see new possibilities.

 It's just, the strength of the emotional response in this thread has been
 kind of revealing.


 Dear Mike, you're one of the most annoying wankers I've seen. Go f** 
 yourself or even better, go kill yourself. TYVM let us have a nice day.


Dear Adam, even though your post is technically trolling and I'm normally a 
"don't feed the trolls" kinda guy, I gotta say: HAVE THIS FRESH-BAKED BATCH 
OF COOKIES! Chocolate-chip! Macaroons! Whatever you want!

I'm amazed at how much Michael's been taking things the wrong way in this 
thread. Almost sounds like my mother: You say just about anything and they 
zero-in on one insignificant detail and blow it entirely out of proportion 
while completely misinterpreting it anyway.
Dec 16 2010
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Michael Stover" <michael.r.stover gmail.com> wrote in message 
news:mailman.1046.1292468790.21107.digitalmars-d puremagic.com...

 there's no integration with the


 external environment

 But it is an advantage at the same time as it's a weakness.  The advantage
 is, I can read and use gmail or google docs anywhere, firewall or not.


That's entirely possible without cramming the whole thing through a webpage. 
I can thank of at least a couple ways just off the top of my head. The 
*only* reason you don't see outside of the web browser it is because 
everyone making "use-anywhere" apps is insisting doing it through the web 
browser. It's *not* a technical limitation of not using a web browser. If 
anything, it's just a widespread misconception amoung people who grew up 
writing web code and therefore don't know any better about what is and isn't 
possible.
Dec 16 2010
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:iedqh5$6qn$1 digitalmars.com...

 "Michael Stover" <michael.r.stover gmail.com> wrote in message 
 news:mailman.1046.1292468790.21107.digitalmars-d puremagic.com...

 there's no integration with the


 external environment

 But it is an advantage at the same time as it's a weakness.  The 
 advantage
 is, I can read and use gmail or google docs anywhere, firewall or not.




Slight wording correction added in-line:


 That's entirely possible without cramming the whole thing through a 
 webpage. I can thank of at least a couple ways just off the top of my 
 head. The *only* reason you don't see
 [the access-your-data-from-anywhere ability]
 outside of the web browser it is because everyone making "use-anywhere" 
 apps is insisting doing it through the web browser. It's *not* a technical 
 limitation of not using a web browser. If anything, it's just a widespread 
 misconception amoung people who grew up writing web code and therefore 
 don't know any better about what is and isn't possible.
Dec 16 2010
prev sibling parent Michael Stover <michael.r.stover gmail.com> writes:
On Thu, Dec 16, 2010 at 2:48 PM, Nick Sabalausky <a a.a> wrote:


 "Michael Stover" <michael.r.stover gmail.com> wrote in message
 news:mailman.1046.1292468790.21107.digitalmars-d puremagic.com...

 there's no integration with the


 external environment

 But it is an advantage at the same time as it's a weakness.  The


 advantage

 is, I can read and use gmail or google docs anywhere, firewall or not.


 That's entirely possible without cramming the whole thing through a
 webpage.
 I can thank of at least a couple ways just off the top of my head. The
 *only* reason you don't see outside of the web browser it is because
 everyone making "use-anywhere" apps is insisting doing it through the web
 browser. It's *not* a technical limitation of not using a web browser. If
 anything, it's just a widespread misconception amoung people who grew up
 writing web code and therefore don't know any better about what is and
 isn't
 possible.


What's possible and what's reasonable to two are different things.  Clearly,
implementors and users are converging on the idea that browsers are the
easiest way to do this.  You can do it other ways, go ahead.  You think
you'll get widespread adoption?

 You can argue against javascript and browsers, sure, but I'm not sure why
you feel it's productive to be so insulting about it.
Dec 16 2010
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Michael Stover" <michael.r.stover gmail.com> wrote in message 
news:mailman.1038.1292443910.21107.digitalmars-d puremagic.com...

 If I provide a spreadsheet program via javascript, why should it have to
 work in Lynx? It's not a web page.  I'm providing absolutely ZERO content.
 It is only behavior, just like Excel is only behavior.  If I provide the
 same functionality, but only if you use Chrome or Firefox, why is that so
 horrible?


First of all, I see no good reason to choose JS to make a spreadsheet app in 
the first place. The browser (not to mention the JS language itself) is 
providing absolutely ZERO benefit, and the only thing it can do is get in 
the way.

Secondly, I've never said that I saw any problem with requiring something 
that actually *is* necessary. Wanna make a web-based photo-editing app? Is 
think it's a stupid and utterly pointless thing to bother doing, but if 
you're going to do it, then sure, by all means exclude Lynx and require JS 
or Flash or something. But if you're going to make, say, a mortgage rate 
calculator, excluding Lynx or requiring JS makes absolutely no sense 
whatsoever.
Dec 15 2010
parent reply Jeff Nowakowski <jeff dilacero.org> writes:
On 12/15/2010 04:31 PM, Nick Sabalausky wrote:

 But if you're going to make, say, a mortgage rate calculator,
 excluding Lynx or requiring JS makes absolutely no sense whatsoever.


This is actually a good example of why you might require JavaScript. 
Here, JavaScript is useful to the end user because it doesn't require a 
request and response to the server, so everything is faster and smoother.

Supporting both JavaScript and plain HTML takes extra work for little 
benefit, since the vast majority of users have it enabled.

It's not 1995 anymore.
Dec 16 2010
next sibling parent Justin Johansson <noreply jj.com> writes:
On 17/12/10 00:35, Jeff Nowakowski wrote:

 On 12/15/2010 04:31 PM, Nick Sabalausky wrote:

 But if you're going to make, say, a mortgage rate calculator,
 excluding Lynx or requiring JS makes absolutely no sense whatsoever.


 This is actually a good example of why you might require JavaScript.
 Here, JavaScript is useful to the end user because it doesn't require a
 request and response to the server, so everything is faster and smoother.

 Supporting both JavaScript and plain HTML takes extra work for little
 benefit, since the vast majority of users have it enabled.

 It's not 1995 anymore.


True its not 1995 anymore but in 2010 JavaScript has not made any 
significant headway in language maturity since its lame-day incarnation 
a decade ago.  The paradox, of course, is that this lame language has 
attained ubiquity (at least in the web client arena) and that there 
seems little else in the way of competition as to a truly web-standard 
offering (aside from plugins that the big end of town want you to 
install, or try to install on your Open Source Browser without your 
permission).
Dec 16 2010
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Jeff Nowakowski" <jeff dilacero.org> wrote in message 
news:ied4mg$2u7f$1 digitalmars.com...

 On 12/15/2010 04:31 PM, Nick Sabalausky wrote:

 But if you're going to make, say, a mortgage rate calculator,
 excluding Lynx or requiring JS makes absolutely no sense whatsoever.


 This is actually a good example of why you might require JavaScript. Here, 
 JavaScript is useful to the end user because it doesn't require a request 
 and response to the server, so everything is faster and smoother.


That makes no sense, given that it's entirely possible to for the JS to be 
optional. A mortgage rate calculator would be a good example of why you 
might toss in *optional* JS to streamline things, but to require it? 
Ridiculous.


 Supporting both JavaScript and plain HTML takes extra work for little 
 benefit, since the vast majority of users have it enabled.


I do make my pages usable both ways and I've found the extra effort to be 
downright minimal. Unless you're doing things very, very, very wrong, the 
vast majority of the work in a site is independent of JS vs non-JS.


 It's not 1995 anymore.


What's that line about those who refuse to learn from history?

And besides, no one's ever going to get me to agree with something simply by 
trying to shame me into it with some idiotic "newer-is-inherently-better", 
"Oh no! I don't want to be un-trendy!!" line of dumbass sheep-think.
Dec 16 2010
parent reply Jeff Nowakowski <jeff dilacero.org> writes:
On 12/16/2010 03:04 PM, Nick Sabalausky wrote:

 I do make my pages usable both ways and I've found the extra effort to be
 downright minimal. Unless you're doing things very, very, very wrong, the
 vast majority of the work in a site is independent of JS vs non-JS.


For the mortgage calculator, you have to implement the same 
functionality twice, once in JavaScript, and once as a backend 
calculation using request/response server navigation. The technologies 
are very different and it's nearly a complete duplication of work.


 And besides, no one's ever going to get me to agree with something simply by
 trying to shame me into it with some idiotic "newer-is-inherently-better",
 "Oh no! I don't want to be un-trendy!!" line of dumbass sheep-think.


You're missing the point. 1995 is when JavaScript came out, and you 
couldn't depend on the browser having it. Now it's nearly ubiquitous, so 
there's very little benefit to spend the time making something like a 
mortgage calculator work without JavaScript.

Your argument is to do extra work for a worse interface to benefit a 
minority of users. By the way, I browse by default with NoScript. I 
resisted JavaScript just as much as you, but it does have it's uses, and 
I'll enable it when I have to.
Dec 17 2010
parent reply retard <re tard.com.invalid> writes:
Fri, 17 Dec 2010 20:45:46 -0500, Jeff Nowakowski wrote:


 On 12/16/2010 03:04 PM, Nick Sabalausky wrote:

 I do make my pages usable both ways and I've found the extra effort to
 be downright minimal. Unless you're doing things very, very, very
 wrong, the vast majority of the work in a site is independent of JS vs
 non-JS.


 
 For the mortgage calculator, you have to implement the same
 functionality twice, once in JavaScript, and once as a backend
 calculation using request/response server navigation. The technologies
 are very different and it's nearly a complete duplication of work.
 

 And besides, no one's ever going to get me to agree with something
 simply by trying to shame me into it with some idiotic
 "newer-is-inherently-better", "Oh no! I don't want to be un-trendy!!"
 line of dumbass sheep-think.


 
 You're missing the point. 1995 is when JavaScript came out, and you
 couldn't depend on the browser having it. Now it's nearly ubiquitous, so
 there's very little benefit to spend the time making something like a
 mortgage calculator work without JavaScript.


FWIW, JavaScript still isn't very efficiently supported on many 
platforms. Latest IE beta (9), Opera, Chrome/Chromium daily builds, and 
Firefox betas might have a reasonable performance level, but the others 
often don't. We not only have windows and macosx. Many users have Linux 
or BSD or some portable device with integrated web browsers. Not every 
mobile phone is an Android phone or iPhone. At work places the corporate 
policy might prevent upgrades. E.g. I've worked in a company where they 
still use WinXP & IE 6 because new browsers would break expensive 
intranet apps.
Dec 17 2010
parent reply Jeff Nowakowski <jeff dilacero.org> writes:
On 12/17/2010 09:18 PM, retard wrote:

 FWIW, JavaScript still isn't very efficiently supported on many
 platforms.


Do you think performance is a problem for a mortgage calculator?

I think the performance issues of JavaScript are way overblown for the 
majority of use cases. I think the biggest problem is people keeping 
open lots of tabs with crappy JavaScript running from ad farms.
Dec 17 2010
next sibling parent retard <re tard.com.invalid> writes:
Fri, 17 Dec 2010 21:58:06 -0500, Jeff Nowakowski wrote:


 On 12/17/2010 09:18 PM, retard wrote:

 FWIW, JavaScript still isn't very efficiently supported on many
 platforms.


 
 Do you think performance is a problem for a mortgage calculator?
 
 I think the performance issues of JavaScript are way overblown for the
 majority of use cases. I think the biggest problem is people keeping
 open lots of tabs with crappy JavaScript running from ad farms.


You can test this by running popular google web applications with a 
vanilla installation of Gnome / KDE desktop. Those are the most used 
desktop environments in the Linux land. Both have problems with the 
khtml / webkit browsers provided by the environments. The neverending 
feed page in google reader makes Gnome's browser soon choke. Some events 
in gmail make KDE's browser confused (not responding to further events). 
This is the typical behavior you get with Linux distributions not using 
latest Firefox / Opera / Chromium. I'd consider the fact that you're not 
being able to read your mail quite critical. It's just that the html 5 
developers don't care. Webmails have worked with html 3/4 browsers for 
over 15 years now.
Dec 17 2010
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Jeff Nowakowski" <jeff dilacero.org> wrote in message 
news:ieh83c$26gk$1 digitalmars.com...

 On 12/17/2010 09:18 PM, retard wrote:

 FWIW, JavaScript still isn't very efficiently supported on many
 platforms.


 Do you think performance is a problem for a mortgage calculator?

 I think the performance issues of JavaScript are way overblown for the 
 majority of use cases. I think the biggest problem is people keeping open 
 lots of tabs with crappy JavaScript running from ad farms.


Ok, so why would I want to turn JS on and put up with those shitty 
browser-killing, user-experience-killing JS Ads just for a calculator that 
obviously doesn't need it?

As for the "nearly a complete duplication of work", it's a duplication of *a 
simple mathematical formula*. It's a near complete duplication *of something 
that is utterly trivial to implement either way*. And if you don't already 
have a system set up for the request/response stuff then you've got a 
*really* dinky site. And if you *do* have such a dinky site, then tossing in 
a basic client-server form is trivial.
Dec 18 2010
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:ieivqj$2s8u$1 digitalmars.com...

 "Jeff Nowakowski" <jeff dilacero.org> wrote in message 
 news:ieh83c$26gk$1 digitalmars.com...

 On 12/17/2010 09:18 PM, retard wrote:

 FWIW, JavaScript still isn't very efficiently supported on many
 platforms.


 Do you think performance is a problem for a mortgage calculator?

 I think the performance issues of JavaScript are way overblown for the 
 majority of use cases. I think the biggest problem is people keeping open 
 lots of tabs with crappy JavaScript running from ad farms.


 Ok, so why would I want to turn JS on and put up with those shitty 
 browser-killing, user-experience-killing JS Ads just for a calculator that 
 obviously doesn't need it?

 As for the "nearly a complete duplication of work", it's a duplication of 
 *a simple mathematical formula*. It's a near complete duplication *of 
 something that is utterly trivial to implement either way*. And if you 
 don't already have a system set up for the request/response stuff then 
 you've got a *really* dinky site. And if you *do* have such a dinky site, 
 then tossing in a basic client-server form is trivial.


Also, I'm not convinced that that duplication can't be abstracted away. 
Actualy, it definitely can be if you use Haxe. And maybe we would already 
have plenty other good ways to do that if developers weren't wasting their 
time making awful browser-skinning engines and implementing excel in a 
webpage.
Dec 18 2010
parent Adam D. Ruppe <destructionator gmail.com> writes:
Nick Sabalausky wrote:

 Also, I'm not convinced that that duplication can't be abstracted away.


I find some functions are easily copy/pasted from a server side
language out to the javascript. Though as it gets complex, it
needs more and more library support on both ends.

That's why I rarely bother trying with it in practice: writing
sharable code is easy, but just doing it on the server using the
full capabilities it has is /easier/, and its almost the same speed
as doing it in pure script anyway! The http submit and response
really doesn't take a very long time.

http://arsdnet.net/cgi-bin/noscript

Submit some stuff... not really slow. Doesn't even refresh the
whole page if your browser has iframe support, but no script.

And if your browser doesn't support iframes, it still works,
since it's just a standard form anyway.


Here's the source:

=====
import arsd.cgi;
import arsd.sha;

void main() {
	auto cgi = new Cgi;
	scope(exit) cgi.close();

	if("text" in cgi.get) {
		cgi.write(hashToString(SHA256!string(cgi.get["text"])));
		return;
	}

	cgi.write(`
		<iframe width="100%" height="30" style="border: none;" border="0" name="hash"
id="hash"></iframe>
		<form target="hash">
			Enter some text to hash: <input type="text" name="text" />
			<input type="submit" />
		</form>
	`);
}
========

Trivial.

How much effort would it have been to do this in Javascript?
JS doesn't have the same library ecosystem available to it, nor
does it have the facilities to make things as simple as languages
like D. I've seen implementations of SHA256 in javascript. Pretty
ugly. Of course, my implementation is pretty ugly too, so maybe
that's a push!

Still, the main point is just that the server can do it really
easily anyway, and then it works for everyone, script or not. Might
as well just do it the easy way on the server.

(If you want to compile it yourself, grab the referenced modules
from here: http://arsdnet.net/dcode/ and use a command line
like so:

 dmd noscript.d cgi.d sha.d -Idmd2/src/druntime/src/
dmd2/src/druntime/src/object_.d  -d

Most that spam is to convince the associative array in cgi.d to
actually link. I think there's a bug somewhere in dmd or druntime, but this
works
around it.)
Dec 18 2010
prev sibling parent reply Jeff Nowakowski <jeff dilacero.org> writes:
On 12/18/2010 01:49 PM, Nick Sabalausky wrote:

 Ok, so why would I want to turn JS on and put up with those shitty
 browser-killing, user-experience-killing JS Ads just for a calculator that
 obviously doesn't need it?


Do as you please. I find it trivial to enable specific pages with 
NoScript. The question is why should the web author spend extra time for 
a tiny minority of users that get up in arms?

You talk about dinosaurs and being pretentious in another thread, but 
you're the biggest curmudgeon on the newsgroup. Even I have learned to 
live with JavaScript, and I used to hate it just as much as you.
Dec 18 2010
next sibling parent so <so so.do> writes:
 Do as you please. I find it trivial to enable specific pages with  
 NoScript. The question is why should the web author spend extra time for  
 a tiny minority of users that get up in arms?

 You talk about dinosaurs and being pretentious in another thread, but  
 you're the biggest curmudgeon on the newsgroup. Even I have learned to  
 live with JavaScript, and I used to hate it just as much as you.


Funny, i think the word "dinosaur" is a compliment. Because mostly  
"lamer"s call someone dinosaur (Didn't see how Nick used it though).

Oh still using that phone?


Dinosaur!

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
Dec 18 2010
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Jeff Nowakowski" <jeff dilacero.org> wrote in message 
news:iejblg$jl1$1 digitalmars.com...

 On 12/18/2010 01:49 PM, Nick Sabalausky wrote:

 Ok, so why would I want to turn JS on and put up with those shitty
 browser-killing, user-experience-killing JS Ads just for a calculator 
 that
 obviously doesn't need it?


 Do as you please. I find it trivial to enable specific pages with 
 NoScript.


I never said turning it was too difficult. Sure it's easy to turn on JS with 
NoScript. And sometimes I do. Problem is, that frequently turns on a bunch 
of other crap on the page leaving the page nearly unusable, or at least far 
less usable. Therefore, it would be far better not to have to.


 The question is why should the web author spend extra time for a tiny 
 minority of users that get up in arms?


The situation does not boil down to that. Like Adam pointed out, it's easy 
to just do it on the server, and then it works just fine for everyone. And 
if you *really* want some JS niceties for the tiny minority that actually 
give a crap about not needing a page or iframe reload, then nothing's 
stopping you from doing so (and yes, that *is* a tiny minority - they're 
just very very vocal).

So, you could do it the, I'm not going to claim it's a good way, it really 
is a shitty way (response/request/server scripting) that only excludes the 
tiny minority of users that get up in arms over a page reload, or you can 
exclude the non-sheep people just for the sake of being able to use 
something that's even shittier (JS/AJAX/etc.)


 You talk about dinosaurs and being pretentious in another thread, but 
 you're the biggest curmudgeon on the newsgroup. Even I have learned to 
 live with JavaScript, and I used to hate it just as much as you.


Saying that videogames are dishonorable and provide no benefit to society is 
idiocy (and in a fairly pompous way; and it is a fallacy that's primarily 
exhibited by older generations). Saying that it's good to require JS for 
things that don't need JS is also idiocy (but in a more technical way; and 
it seems to be more prevailent among newer developers). To claim that's a 
hypocritical inconsistency inherently implies that dumb notions can't exist 
in both new and old varieties - that there can only be bad things about the 
new or that there can only be bad things about the old. Of course there can 
be both, why wouldn't that be possible?

I definitely don't deny being the biggest curmudgeon on the newsgroup. But I 
don't see that as bad: People generally swallow far too much crap (unless 
I'm the one dishing stuff out, in which case everyone pounces on me if I get 
even the slightest thing less-than-perfect...or perhaps more accurately: if 
it's anything less-than-popular).
Dec 18 2010
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:ieb2ng$2u34$1 digitalmars.com...

 Nick Sabalausky wrote:

 that's *proof* of how horrid JS is


 I often feel Google is re-discovering DOS' capabilities and going on about 
 how
 great it is. Got it in graphics and input, and files too.


Yea, I feel like I'm one of the few people in the software world that was 
actually into software throughout the whole 90's, and actually used things 
like the Apple II (Apple's only good product line ever, IMNSHO). Things go 
in circles, and it's so frustrating to see things veer off into a brink wall 
while people like us are left screaming "WTF are you thinking?!" to a deaf 
audience, only to *eventually* see some of those same drunkards finally 
begin to get a tiny glint of clarity, at which point we're just shaking our 
heads going "See, I fucking *told* you so", which, again is ignored by the 
idiots who think they've invented exactly what we've been fruitlessly 
preaching all along.


 HTML5 local storage is a bunch of key/item pairs. Wooo, it's like a 
 filesystem
 with only a root directory!


I don't know how I feel about that: I'd hate to see HTML5 end up repeating 
Flash's SuperCookies.


 I'm sure as hell not going to be one of
 those "This site best viewed with X browser" assholes.


 I might be one of those people, though I don't come out and say it, my 
 sites do
 tend to be best viewed with X browser.

 But the important difference is it still *works* in Y and Z browser. It 
 just won't
 have rounded corners, etc.


Well, yea, that's just cosmetic irrelevancies. But if something's built for 
chrome, and then runs on other browsers like a GameBoy-powered 
streaming-HD-video server, and breaks entirely with JS off (there's a lot of 
good reasons to have JS off), then that's rather a different story.
Dec 15 2010
prev sibling parent retard <re tard.com.invalid> writes:
Wed, 15 Dec 2010 13:18:16 -0500, Nick Sabalausky wrote:


 "Andrew Wiley" <debio264 gmail.com> wrote in message
 news:mailman.1026.1292433894.21107.digitalmars-d puremagic.com...

 On Wed, Dec 15, 2010 at 9:37 AM, Adam D. Ruppe
 <destructionator gmail.com>wrote:

 And in those rare cases where you are doing a lot of client side work,
 it is so
 brutally slow that if you start piling other runtimes on top of it,
 you'll
 often
 be left with an unusable mess anyway!



 Unless you're using the beta of the next IE, the beta of the next
 Opera, or
 the current version of Chrome, in which case you'd find that
 client-side work is becoming more and more feasible. Now, it's not
 there yet, but when a
 C-ported-to-Java-compiled-to-Javascript version of Quake 2 can get
 30FPS in
 Google Chrome, I start thinking that performance probably won't be
 nearly as
 bad as browsers move forward.


 A game that was designed to run on a 90-133MHz 16-24MB RAM machine (in
 *software* rendering mode), and was frequently able to get framerates in
 the hundreds on sub-500MHz machines (using hardware rendering - with the
 old, old, old 3dfx cards), manages to get *only* 30FPS in JS on a
 multi-GHz multi-core machine using what is clearly hardware rendering
 (on a modern graphics card), and I'm supposed to think that means JS is
 fast? If anything, that's *proof* of how horrid JS is - it turns a
 multi-GHz multi-core into a Pentium ~100MHz. What a joke!


Some points:

 - IIRC the game was further optimized since the first release. The 
requirements went down a bit. Especially the SIMD optimizations allowed 
much lower MHz requirements with software rendering. Nowadays the SIMD 
instructions give even better throughput.

 - Compilers have improved a lot. E.g. auto-vectorization. Requirements 
went down a bit again.

 - the Jake2 version also runs faster because of faster JVMs and better 
OpenGL libraries

 - OTOH resolutions have gone up... but if the game uses hardware 
accelerated opengl canvas, using Javascript instead of C doesn't have 
much effect

 - overall I think the CPU requirements have gone down even though higher 
resolution and expensive graphical effects are more common these days.

Indeed Quake II used to work very fast on Pentium II class hardware with 
Nvidia TNT cards. I think I got over 100 fps   1280x1024 over 10 years 
ago. Getting 30 FPS on average now IS a bad joke. The (graphics) hardware 
gets 100% faster every 12-18 months. Even if you make the game twice as 
fast as now, hardcore fps gamers wouldn't find the rate acceptable for 
modern network gaming. Hardcore fps gamers won't also play 13 yo games 
anymore.

I admit that JavaScript is getting faster and faster. However, at some 
point the language will hit the performance wall. Luajit is one of the 
fastest dynamic languages out there. It's still drastically slower than 
statically typed languages. It probably shows has fast JavaScript can 
possibly get in raw computational tasks.

This is all ok for "casual gaming", but if you only get 30 FPS when 
running a 13 yo game, it means you're 15-16 years behind the state of the 
art. OTOH slow software rendered flash applets were already used as a 
platform for casual gaming, HTML5 doesn't change the situation that much. 
Maybe the greatest difference is that HTML5 also runs quite fast on 
Linux. This HTML5 hype also helps them in marketing. After all, it's the 
same old shit in new package.


 [HTML5, HTML5, HTML5, Chrome, HTML5, HTML5...]


 
 Yea, *eventually* HTML5 will *improve* a few things...That hardly counts
 as "The web's not a shitty platform!".


It's just 15-16 years behind the state of the art. Not much!
Dec 15 2010
prev sibling parent Andrew Wiley <debio264 gmail.com> writes:
On Wed, Dec 15, 2010 at 11:24 AM, Andrew Wiley <debio264 gmail.com> wrote:


 On Wed, Dec 15, 2010 at 9:37 AM, Adam D. Ruppe
<destructionator gmail.com>wrote:

 And in those rare cases where you are doing a lot of client side work, it
 is so
 brutally slow that if you start piling other runtimes on top of it, you'll
 often
 be left with an unusable mess anyway!



 Unless you're using the beta of the next IE, the beta of the next Opera, or
 the current version of Chrome, in which case you'd find that client-side
 work is becoming more and more feasible. Now, it's not there yet, but when a
 C-ported-to-Java-compiled-to-Javascript version of Quake 2 can get 30FPS in
 Google Chrome, I start thinking that performance probably won't be nearly as
 bad as browsers move forward.

 You don't have to like it, but there's a huge push in web development
 towards doing more work on the client, and now that browsers are catching
 up, it's going to change the way the web works.

 As for the rest:
 a) No real time networking
 HTML 5 WebSockets, as you said

 b) Cross domain communication requires ugly, inefficient hacks, or a proxy
 on your server.
 This is the one thing you've listed that's not going to change because it
 poses a security risk.


 c) No sounds (without flash anyway).
 Included in HTML 5.

 d) Graphics, even if you grant the canvas element, are a joke. The latency
 is
 brutal. Take that deviant art thing from earlier in the thread. Flick your
 mouse,
 and watch the lines slowly catch up to you! Using X11 with a remote server
 is
 faster than that.
 In Chrome (even the version a year or so old that is installed on the lab
 computer I'm using right now), there is no latency whatsoever. That's a
 simple matter of javascript performance, which is dramatically improving.


 e) Input requires a lot of magic. Some keys have the same identifiers, some
 of the
 time, meaning just checking for keypress requires dozens of lines of code,
 and
 still doesn't work right! Checking for multiple keys or mouse buttons hit
 at once
 is very poor.
 This is where frameworks can help. Now that Javascript performance is
 barrelling ahead, frameworks start looking much more attractive. I've used
 GWT (Java->Javascript) in the past, and input handling feels exactly like it
 does in SWT or Swing (the leading Java UI frameworks).


 f) Very little state across loads (though html5 is adding something for
 this, if
 it ever gets broad penetration), mentioned mainly for completeness, since
 javascript variables do work for must things, but your persistent database
 still
 has to be on the server.
 As you said, HTML5. My internet was down this morning, but I was still able
 to read the batch of mail in GMail that I downloaded last night because
 GMail is already taking advantage of Google Gears, which provides similar
 functionality. I get the same thing with a few other web applications.


 g) No threading. I recently tried making a javascript -> d caller. In D,
 this
 would be trivial: opDispatch means no code needs to be written, and if it
 runs in
 a different thread from the rest of the UI, it can make sync calls to the
 server
 without freezing everything up, thus letting it be written in a linear
 style.
 HTML5 adds WebWorkers, which handle exactly this use case (among others).


I should also note that every HTML5 feature I mentioned here except
WebSockets is also supported in Firefox 3.5. IE9 supports everything but
WebSockets and WebWorkers. (Apparently there's some trouble with the
WebSockets specification at the moment)
Dec 15 2010
prev sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Wed, 15 Dec 2010 09:18:51 +0200, Nick Sabalausky <a a.a> wrote:


 Plus, JS is undeniably slow on my web browser: FF2. And I'll happily  
 give up
 FF2 exactly when someone comes out with a web browser that does the
 following, and without fucking something else up in the process:
 - No unified forward/back buttons
 - No cluttered, crayola-colored address bar and dropdown.
 - No skin.
 - No useless always-resident processes.
 - No invisi-text for light-on-dark systems.
 - NoScript or an equivalent.
 - AdBlock Plus or an equivalent.
 - BetterPrivacy or an equivalent.
 - TabMixPlus or an equivalent.


Hey Nick, don't mean to start a browser war or anything, but have you  
tried Opera? Admittedly it fails at point 2 and perhaps others, but:
1) allows choosing between its own skin and the "OS native" skin
2) built-in NoScript (per-domain JavaScript toggle)
3) built-in FlashBlock, as of Opera 11 (solves the EverCookie problem)
4) built-in content blocker (wildcard-based), though doesn't auto-update  
like AdBlock Plus
5) several TabMixPlus features built-in

I like Opera because its functionality is comparable with Firefox + a good  
deal of extensions, but it's much more responsive.

-- 
Best regards,
  Vladimir                            mailto:vladimir thecybershadow.net
Dec 15 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"Vladimir Panteleev" <vladimir thecybershadow.net> wrote in message 
news:op.vnrxxtcrtuzx1w cybershadow.mshome.net...

 On Wed, 15 Dec 2010 09:18:51 +0200, Nick Sabalausky <a a.a> wrote:


 Plus, JS is undeniably slow on my web browser: FF2. And I'll happily 
 give up
 FF2 exactly when someone comes out with a web browser that does the
 following, and without fucking something else up in the process:
 - No unified forward/back buttons
 - No cluttered, crayola-colored address bar and dropdown.
 - No skin.
 - No useless always-resident processes.
 - No invisi-text for light-on-dark systems.
 - NoScript or an equivalent.
 - AdBlock Plus or an equivalent.
 - BetterPrivacy or an equivalent.
 - TabMixPlus or an equivalent.


 Hey Nick, don't mean to start a browser war or anything,


Fair enough :)


 but have you  tried Opera? Admittedly it fails at point 2 and perhaps 
 others, but:
 1) allows choosing between its own skin and the "OS native" skin
 2) built-in NoScript (per-domain JavaScript toggle)
 3) built-in FlashBlock, as of Opera 11 (solves the EverCookie problem)
 4) built-in content blocker (wildcard-based), though doesn't auto-update 
 like AdBlock Plus
 5) several TabMixPlus features built-in

 I like Opera because its functionality is comparable with Firefox + a good 
 deal of extensions, but it's much more responsive.


Yes, I gave it another try fairly recently, in fact. The "OS native" skin 
isn't remotely native (in fact, I didn't even know it was the "OS native" 
setting until I went into the skin options to turn on "OS native" and found 

there's been a very big change very recently, Opera's "extentions" aren't 
extensions at all but widgets that have little-to-no connection with the 
web-browsing function. I think I had some other problems as well though I 
don't remember exactly what. I posted my impressions of it on this NG, you 
can probably just search the NG for posts from "Sabalausky" with "opera" in 
the text. It was better than I expected, but not enough to tear me away from 
FF2 (not that I'm happy with FF2).
Dec 15 2010
parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Wed, 15 Dec 2010 23:45:49 +0200, Nick Sabalausky <a a.a> wrote:


 Opera's "extentions" aren't
 extensions at all but widgets that have little-to-no connection with the
 web-browsing function.


Opera 11 supposedly introduces support for real extensions, though after  
browsing the extension gallery[1] I haven't noticed anything I'd want to  
use. They seem to be pimped-up UserScripts, nothing which allows actually  
modifying the UI (possibly a good thing - a customized Firefox looks like  
a Frankenbrowser with all the toolbars and buttons). Opera has also  
supported UserScripts for some time.


 I think I had some other problems as well though I
 don't remember exactly what. I posted my impressions of it on this NG,  
 you
 can probably just search the NG for posts from "Sabalausky" with "opera"  
 in
 the text.


Hmm, can't find anything (neither in my archives, nor on Google)... well,  
considering that a few years ago someone from Opera Software said that  
"The best browser in the world doesn't need extensions", I'd say that  
quite a few things changed ;)

  [1]: https://addons.opera.com/addons/extensions/

-- 
Best regards,
  Vladimir                            mailto:vladimir thecybershadow.net
Dec 15 2010
parent Justin C Calvarese <technocrat7+d gmail.com> writes:
On Wed, Dec 15, 2010 at 3:58 PM, Vladimir Panteleev <
vladimir thecybershadow.net> wrote:


  I think I had some other problems as well though I

 don't remember exactly what. I posted my impressions of it on this NG, you
 can probably just search the NG for posts from "Sabalausky" with "opera"
 in
 the text.


 Hmm, can't find anything (neither in my archives, nor on Google)...



This looks like the relevant post by Nick:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.announce&article_id=19476

jcc7
Dec 15 2010
prev sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
Adam D. Ruppe Wrote:


 Michael Stover:

 Did you use the gmail webapp to write that?


 
 No. My public email address is gmail so I get a free spam
 filter and online archive, but I don't actually use their
 awful, awful interface. (All incoming mail to that address is
 forwarded to my real email address, and my outgoing mail is
 SMTP relayed back through gmail. My real address remains spam
 free by being secret.)
 
 This does bring me to two rants though:
 
 a) Gmail's web interface is horrible, even the basic HTML
 version. Consider this: right click a message... no "open in
 new window" option! WTF.


What about Hotmail, Yahoo, MobileMe, etc?  I agree with your opinion of GMail
but am curious about your opinion of others.
Dec 14 2010
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
 What about Hotmail, Yahoo, MobileMe, etc?


I haven't used most of them for a long time. Gmail gets most
my ranting because its the one I've used most recently. (And
I remember my password to it so I could sign in and re-check
my statements before posting too.)

If I were writing a webmail program, here's how I'd do it though:

1) Start with a regular HTML view. A simple table of from/date/
subject, and a compose button. The messages are standard links, so opening in a
new window works as expected.

The compose screen is a very basic form. The website should be
perfectly usable in the Lynx browser.

2) Beef up the html. Ensure things like accesskeys and tabindexes are set, so
keyboard control works at least somewhat well.

3) Go back and start adding stuff on to it with scripts. The gmail polling for
new
message notification is pretty useful, so add that. Having auto-completion of
your
friends' email addresses is a nice thing gmail does too. I might add a document
keypress handler to add hotkeys, since I'm not really happy with browser
implementations of accesskeys (alt+shift+letter in firefox - did they not
realize
the whole point was to be /accessible/? I can't get my fingers to contort that
way
without hunt+pecking with both hands! But my old konqueror is much better - hit
control to toggle them on and off - and that's what I use, so meh.)

4) The scripts might fetch the message after the one you click on as well, just
ajax getting the next document in line then doing nothing with the result. My
server code would be configured to send the proper cache headers, meaning when
you
click the link to actually view it, it is pre-loaded in the cache, and thus
loads
instantly. A lot of websites do it for images, why not documents too? This would
keep the user visible latency to a minimum while browsing messages.


That's about it. It wouldn't be as good as a real application, but it'd be good
enough as webmail with or without scripting.
Dec 14 2010
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:ie9hjv$r1n$1 digitalmars.com...

 What about Hotmail, Yahoo, MobileMe, etc?


 I haven't used most of them for a long time. Gmail gets most
 my ranting because its the one I've used most recently. (And
 I remember my password to it so I could sign in and re-check
 my statements before posting too.)

 If I were writing a webmail program, here's how I'd do it though:

 1) Start with a regular HTML view. A simple table of from/date/
 subject, and a compose button. The messages are standard links, so opening 
 in a
 new window works as expected.

 The compose screen is a very basic form. The website should be
 perfectly usable in the Lynx browser.

 2) Beef up the html. Ensure things like accesskeys and tabindexes are set, 
 so
 keyboard control works at least somewhat well.

 3) Go back and start adding stuff on to it with scripts. The gmail polling 
 for new
 message notification is pretty useful, so add that. Having auto-completion 
 of your
 friends' email addresses is a nice thing gmail does too. I might add a 
 document
 keypress handler to add hotkeys, since I'm not really happy with browser
 implementations of accesskeys (alt+shift+letter in firefox - did they not 
 realize
 the whole point was to be /accessible/? I can't get my fingers to contort 
 that way
 without hunt+pecking with both hands! But my old konqueror is much 
 better - hit
 control to toggle them on and off - and that's what I use, so meh.)

 4) The scripts might fetch the message after the one you click on as well, 
 just
 ajax getting the next document in line then doing nothing with the result. 
 My
 server code would be configured to send the proper cache headers, meaning 
 when you
 click the link to actually view it, it is pre-loaded in the cache, and 
 thus loads
 instantly. A lot of websites do it for images, why not documents too? This 
 would
 keep the user visible latency to a minimum while browsing messages.


 That's about it. It wouldn't be as good as a real application, but it'd be 
 good
 enough as webmail with or without scripting.


You've just described what I call "The *right* way to make a website".
Dec 14 2010
parent reply Michael Stover <michael.r.stover gmail.com> writes:
And that's the problem - we're talking about applications that happen to be
distributed via the web, not a "website".  Everyone's demands that it work
in lynx, FF2, with javascript turned off, etc are ludicrous.  You don't get
to make such demands of applications. Some applications are Windows only.
 Some don't follow platform standards.  Some require 1GB to work
effectively.  None let you require it work without running code, etc.

These expectations are invalid.

On Wed, Dec 15, 2010 at 2:24 AM, Nick Sabalausky <a a.a> wrote:


 "Adam D. Ruppe" <destructionator gmail.com> wrote in message
 news:ie9hjv$r1n$1 digitalmars.com...

 What about Hotmail, Yahoo, MobileMe, etc?


 I haven't used most of them for a long time. Gmail gets most
 my ranting because its the one I've used most recently. (And
 I remember my password to it so I could sign in and re-check
 my statements before posting too.)

 If I were writing a webmail program, here's how I'd do it though:

 1) Start with a regular HTML view. A simple table of from/date/
 subject, and a compose button. The messages are standard links, so


 opening

 in a
 new window works as expected.

 The compose screen is a very basic form. The website should be
 perfectly usable in the Lynx browser.

 2) Beef up the html. Ensure things like accesskeys and tabindexes are


 set,

 so
 keyboard control works at least somewhat well.

 3) Go back and start adding stuff on to it with scripts. The gmail


 polling

 for new
 message notification is pretty useful, so add that. Having


 auto-completion

 of your
 friends' email addresses is a nice thing gmail does too. I might add a
 document
 keypress handler to add hotkeys, since I'm not really happy with browser
 implementations of accesskeys (alt+shift+letter in firefox - did they not
 realize
 the whole point was to be /accessible/? I can't get my fingers to contort
 that way
 without hunt+pecking with both hands! But my old konqueror is much
 better - hit
 control to toggle them on and off - and that's what I use, so meh.)

 4) The scripts might fetch the message after the one you click on as


 well,

 just
 ajax getting the next document in line then doing nothing with the


 result.

 My
 server code would be configured to send the proper cache headers, meaning
 when you
 click the link to actually view it, it is pre-loaded in the cache, and
 thus loads
 instantly. A lot of websites do it for images, why not documents too?


 This

 would
 keep the user visible latency to a minimum while browsing messages.


 That's about it. It wouldn't be as good as a real application, but it'd


 be

 good
 enough as webmail with or without scripting.


 You've just described what I call "The *right* way to make a website".
Dec 15 2010
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Michael Stover" <michael.r.stover gmail.com> wrote in message 
news:mailman.1018.1292422650.21107.digitalmars-d puremagic.com...

 And that's the problem - we're talking about applications that happen to 
 be
 distributed via the web, not a "website".


Ahh, I see, so it's just "distributed via the web". Here are some 
applications that *are*, in fact, distrubuted via the web:

- DMD
- Eclipse
- GIMP
- Avisynth / VirtualDub
- Linux / BSD

Those are distributed via the web and using them doesn't require one damn 
bit of in-browser code execution. Hell, they doesn't even require a browser 
at all. And no, I'm *not* playing semantics games here: "Distributed via the 
web" means exactly what it means. So obviously we *are* talking about 
websites that act as apps, *not* merely apps distributed via the web.


 Everyone's demands that it work
 in lynx, FF2, with javascript turned off, etc are ludicrous.  You don't 
 get
 to make such demands of applications.


Of course I get to. See, here I am demanding it. What can you possibly mean 
by I "don't get to make such demands of applications"? Of course I get to.


 Some applications are Windows only.


And Unix users *don't* use those apps (wine notwithstanding). Are you goint 
to complain about Unix users who refuse to use Windows apps or desire apps 
to be cross-platform?


 Some don't follow platform standards.


And I avoid using those programs. See, here I am making demands that you 
didn't think I could make.


 Some require 1GB to work effectively.


Even *I* have 1GB RAM.

And some things *shouldn't* require 1GB RAM: Like a text-entry box.


 None let you require it work without running code, etc.


Strawman: Nobody ever said anything about not running any code at all. Web 
apps can work perfectly fine running code on the server.
Dec 15 2010
prev sibling parent =?ISO-8859-1?Q?Pelle_M=E5nsson?= <pelle.mansson gmail.com> writes:
On 12/15/2010 03:17 PM, Michael Stover wrote:

 And that's the problem - we're talking about applications that happen to
 be distributed via the web, not a "website".  Everyone's demands that it
 work in lynx, FF2, with javascript turned off, etc are ludicrous.


I disagree.


 You don't get to make such demands of applications.


Yes I do!


 Some applications areWindows only.


Not running them.


 Some don't follow platform standards.


They suck!


 Some require 1GB to work effectively.


Probably not running them.


 These expectations are invalid.


They are not.

The idea that you shouldn't expect things to be good is backwards. 
Web-as-a-platform isn't good. Maybe it can be in the future. It's not now.
Dec 16 2010
prev sibling parent Torarin <torarind gmail.com> writes:
2010/12/15 Adam D. Ruppe <destructionator gmail.com>:


 4) The scripts might fetch the message after the one you click on as well, just
 ajax getting the next document in line then doing nothing with the result. My
 server code would be configured to send the proper cache headers, meaning when
you
 click the link to actually view it, it is pre-loaded in the cache, and thus
loads
 instantly. A lot of websites do it for images, why not documents too? This
would
 keep the user visible latency to a minimum while browsing messages.


Gmail does preload all unread messages plus the last message in each
thread. It also preloads the first few words of every message as a
preview. I'll give you that it could have fetched everything, though.

Torarin
Dec 15 2010
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Adam Ruppe:


 Which brings me to emscripten... it most certainly does not work well! The
Python
 example took a couple *minutes* to load for me, and actually running some
python
 code took seconds each time.


On a more modern browser it works "well enough" (Firefox 4). Do you realize
that the source code of CPython is a LOT of code, we are talking about a
JavaScript source file of 2.6 MB, after compression! So just seeing it compile
and be able to run it and run some Python scripts is a marvel for me :-) So I
think emscripten is a very nice toy. I have not yet tried to use LDC &
emscripten to convert some D1 code to JS.

Regarding the JavaScript language, they are going to fix some of its biggest
mistakes (but not semicolons yet, hopefully later), so JS is gaining speed,
fixing its mistakes, and gaining power (canvas, WebGL, audio, video, other
widgets, frameworks, etc):
http://www.yuiblog.com/blog/2010/12/14/strict-mode-is-coming-to-town/

An interesting part from that blog post, that reminds us that D2 has sadly
failed to fix this problem (and the octal!x syntax is not a significant
improvement of the situation):


In C, an extremely unfortunate representation of octalness was selected:
Leading zero. So in C, 0100 means 64, not 100, and 08 is an error, not 8. Even
more unfortunately, this anachronism has been copied into nearly all modern
languages, including JavaScript, where it is only used to create errors. It has
no other purpose. So in strict mode, octal forms are no longer allowed.<


Bye,
bearophile
Dec 19 2010
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
bearophile:

 On a more modern browser it works "well enough" (Firefox 4).


This is a bit of a rant, but I hate how the web community
always uses "modern browser" like this.

I ran this site on Firefox 3.6.3. The most recent one it offers
on getfirefox.com is 3.6.13 - I'm not very far behind! My about
firefox box says Gecko from April 2010.

That should be modern by any sane definition!

(Now, my every day browser, Konqueror 3.5.7, is (c) 2005. So
I can understand it not being a "modern browser". But it works
for me so I won't change it. Something I find hilarious though:
it's CSS2 compliance was better than firefox up until about
last year!

I just wrote a site going wild with css for a web demo for the
company, and it worked almost as well in my old Konq as it did
in my newer Firefox. The kde folks did a really impressive job
there.)


Anyway, it just irks me that so many web evangelists say "modern"
when they really mean "bleeding edge". And in Google's case, it
is even worse: when they say "all modern browsers", they actually
mean "/our/ bleeding edge beta". It really annoys me.



Back on topic:


 So I think emscripten is a very nice toy.


I agree completely, it's a cool toy and pretty impressive that they
got it to work as well as they did. I just don't think it is
usable or really desirable for real work. Maybe it will improve,
but it still has to compete with straight up javascript, which
is already good enough for most places where you really need it.



 Regarding the JavaScript language, they are going to fix some of
 its biggest mistakes (but not semicolons yet, hopefully later),


Interesting. Some comments from the article, then back to you
to comment on octal! at the end:

"Strict mode requires that all variable binding be done statically."

I wonder how that will change the javascript "this" keyword. I
originally found it confusing, but now that I know its rules it
isn't so bad and is sometimes extra useful.


"You should explicitly declare all of your variables."

"Should"?? If this is actually a strict mode, shouldn't it be
"must"? Maybe the author is just being sloppy, but this wording
makes me think it moved from implicit global to implicit local.
Definitely better, but still requiring "var" in all cases is
better yet.


"Noisy Failure"

Something important about failure is it isn't just the language.
The environment needs to tell you too.

Browsers often either hide errors or annoy you so much about them
you want them hidden. Some support an onerror event so you can
hook it yourself, but not all browsers do.

It would be nice if the browser behavior on error in strict mode
was improved too.


...or better yet, give us a compiler ahead of time! JSLint is
OK I guess though, but I rarely use it.


"There are still problems in JavaScript that strict mode does not address."

Yes, and those things still suck. But if you use js sparingly,
you don't have to deal with them too much. :)


Back to bearophile:


 (and the octal!x syntax is not a significant improvement of the situation):


Sure it is! The problem is that the old syntax is still accepted
instead of either breaking C or giving a compiler error. This is
one place where Walter and I disagree, but to move to a new
way, we eventually need to remove the old way.
Dec 19 2010
next sibling parent Lutger Blijdestijn <lutger.blijdestijn gmail.com> writes:
Adam D.  Ruppe wrote:


 bearophile:

 On a more modern browser it works "well enough" (Firefox 4).


 
 This is a bit of a rant, but I hate how the web community
 always uses "modern browser" like this.
 
 I ran this site on Firefox 3.6.3. The most recent one it offers
 on getfirefox.com is 3.6.13 - I'm not very far behind! My about
 firefox box says Gecko from April 2010.
 
 That should be modern by any sane definition!
 
 (Now, my every day browser, Konqueror 3.5.7, is (c) 2005. So
 I can understand it not being a "modern browser". But it works
 for me so I won't change it. Something I find hilarious though:
 it's CSS2 compliance was better than firefox up until about
 last year!
 
 I just wrote a site going wild with css for a web demo for the
 company, and it worked almost as well in my old Konq as it did
 in my newer Firefox. The kde folks did a really impressive job
 there.)
 
 
 Anyway, it just irks me that so many web evangelists say "modern"
 when they really mean "bleeding edge". And in Google's case, it
 is even worse: when they say "all modern browsers", they actually
 mean "/our/ bleeding edge beta". It really annoys me.
 


I'm more used to the term in "every modern browser, except IE", in which 
case it is usually correct and modern means something from this or last year 
(except IE). Good old Konq from 2005 for example has better CSS2 support 
than IE8.
Dec 19 2010
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:ieleht$1qc8$1 digitalmars.com...

 bearophile:

 On a more modern browser it works "well enough" (Firefox 4).


 This is a bit of a rant, but I hate how the web community
 always uses "modern browser" like this.

 I ran this site on Firefox 3.6.3. The most recent one it offers
 on getfirefox.com is 3.6.13 - I'm not very far behind! My about
 firefox box says Gecko from April 2010.

 That should be modern by any sane definition!

 (Now, my every day browser, Konqueror 3.5.7, is (c) 2005. So
 I can understand it not being a "modern browser". But it works
 for me so I won't change it. Something I find hilarious though:
 it's CSS2 compliance was better than firefox up until about
 last year!

 I just wrote a site going wild with css for a web demo for the
 company, and it worked almost as well in my old Konq as it did
 in my newer Firefox. The kde folks did a really impressive job
 there.)


 Anyway, it just irks me that so many web evangelists say "modern"
 when they really mean "bleeding edge". And in Google's case, it
 is even worse: when they say "all modern browsers", they actually
 mean "/our/ bleeding edge beta". It really annoys me.


Hear, hear!
Dec 19 2010
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Adam D. Ruppe:


 Anyway, it just irks me that so many web evangelists say "modern"
 when they really mean "bleeding edge".


You are right, saying "modern" I have used the wrong words. If you use
emscripten to compile large amounts of C or C++ code you probably need a very
fast JavaScript engine. And we are still in the middle of the JS speed race, so
it matters if you use FF 3.6 or FF4 or the latest canary build of Chrome that
has Crankshaft. In few years this speed race will end and using the very latest
JS engine will not matter.

Bye,
bearophile
Dec 19 2010