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 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 next sibling parent =?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
prev sibling next 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 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 next sibling parent Michael Stover <michael.r.stover gmail.com> writes:
--000e0cd328a07bdbdb0497611563
Content-Type: text/plain; charset=ISO-8859-1

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

--000e0cd328a07bdbdb0497611563 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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. =A0Someone who w= as serious about making an application over the web would simply require Ch= rome or Firefox, and then 99% of your incompatibility issues go away, as we= ll as your performance problems. =A0<div> <br></div><div>Something like=A0<a href=3D"http://muro.deviantart.com/">htt= p://muro.deviantart.com/</a> is great and, to me, demonstrates the browser/= javascript platform is more than capable.</div><div><br></div><div>-Mike<br=

s=3D"Apple-style-span" style=3D"border-collapse: collapse;"><br></span></fo= nt></div><div><font class=3D"Apple-style-span" face=3D"arial, sans-serif"><= span class=3D"Apple-style-span" style=3D"border-collapse: collapse;"><br> </span></font><br><div class=3D"gmail_quote">On Tue, Dec 14, 2010 at 10:49 = AM, Andrei Alexandrescu <span dir=3D"ltr">&lt;<a href=3D"mailto:SeeWebsiteF= orEmail erdani.org">SeeWebsiteForEmail erdani.org</a>&gt;</span> wrote:<br>= <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;"> <div><div></div><div class=3D"h5">On 12/14/10 9:25 AM, Sean Kelly wrote:<br=

x #ccc solid;padding-left:1ex"> Adam Ruppe Wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> <br> Client side scripting sucks. It&#39;s garbage. Slow, incompatible, unreliab= le, and a<br> piece of junk platform in general - it does very little that&#39;s interest= ing. That&#39;s<br> not even getting into the language itself.<br> </blockquote> <br> It totally sucks, but it does scale better than executing everything server= -side.<br> </blockquote> <br></div></div> Surprisingly, it doesn&#39;t. Facebook is reducing its client-side Javascri= pt to a minimum in favor of server-side code. Reason? Speed. You can&#39;t = control user&#39;s OS, browser, and hardware platform, but you can control = your own.<br> <font color=3D"#888888"> <br> Andrei<br> </font></blockquote></div><br></div></div> --000e0cd328a07bdbdb0497611563--
Dec 14 2010
prev sibling next sibling 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
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 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*

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 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 next sibling 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 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 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 next 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
next sibling 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 next sibling 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 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
next sibling 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 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 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 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
prev sibling next 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
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 next sibling parent 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
prev sibling 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
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
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:
"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 it was already on), and it doesn't fit point #2 like you said. Unless 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
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
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
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 Michael Stover <michael.r.stover gmail.com> writes:
--000e0cd14b8a8f5d8404978d0813
Content-Type: text/plain; charset=ISO-8859-1

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

javascript sucks, period, end of story, without any possibility of ever being otherwise. CAPTCHAs are irrelevant. --000e0cd14b8a8f5d8404978d0813 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <br><br><div class=3D"gmail_quote">On Thu, Dec 16, 2010 at 2:22 PM, Nick Sa= balausky <span dir=3D"ltr">&lt;a a.a&gt;</span> wrote:<br><blockquote class= =3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd= ing-left:1ex;"> <div class=3D"im">&quot;Michael Stover&quot; &lt;<a href=3D"mailto:michael.= r.stover gmail.com">michael.r.stover gmail.com</a>&gt; wrote in message<br> </div>news:mailman.1053.1292506694.21107.digitalmars-d puremagic.com...<br> <div class=3D"im">&gt;<br> &gt; And CAPTCHAs prove that javascript and browsers are terrible???<br> &gt;<br> <br> </div>Where are you gettng that? That&#39;s not even remotely what he said.= He was<br> clearly saying that CAPTCHAs and registration are a counter-argument to the= <br> notion that most webapps are zero-config. Or at least that they&#39;re not<= br> really much better than having to do some basic config.<br><br></blockquote=
<div>The conversation was about technologies, not specific webapps. The em=

pt sucks, period, end of story, without any possibility of ever being other= wise. =A0CAPTCHAs are irrelevant.</div> </div> --000e0cd14b8a8f5d8404978d0813--
Dec 16 2010
prev sibling next sibling 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 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 next sibling parent Michael Stover <michael.r.stover gmail.com> writes:
--000e0cd32b78f061140497664ec6
Content-Type: text/plain; charset=ISO-8859-1

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.

--000e0cd32b78f061140497664ec6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <br><br><div class=3D"gmail_quote">On Tue, Dec 14, 2010 at 2:03 PM, Adam Ru= ppe <span dir=3D"ltr">&lt;<a href=3D"mailto:destructionator gmail.com">dest= ructionator gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_q= uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e= x;"> <div class=3D"im">&gt; Have you tried, for example, CoffeeScript:<br> <br> </div>I have not - my main problem with Javascript isn&#39;t so much the<br=

like emscripten (and google native client) are pretty useless.<br> <br> Browsers are good for displaying html pages. Javascript is good<br> for enhancing those html pages. But they aren&#39;t very good at full<br> blown applications.<br></blockquote><div><br></div><div>=A0Adam Ruppe=A0<sp= an dir=3D"ltr">&lt;<a href=3D"mailto:destructionator gmail.com">destruction= ator gmail.com</a>&gt;</span></div><div><span dir=3D"ltr">Did you use the g= mail webapp to write that?</span></div> <div><span dir=3D"ltr"><br></span></div><meta charset=3D"utf-8"><blockquote= class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli= d;padding-left:1ex;"> <br> I do have a list of flames against javascript the language too,<br> but none of them are huge in context.<br> <br> <br> Anyway looking at the coffeescript website... it looks like my worst<br> nightmare: something inspired by a mixing of Python and Ruby! I<br> don&#39;t think I could handle that.<br> </blockquote></div><br> --000e0cd32b78f061140497664ec6--
Dec 14 2010
prev sibling next sibling parent Michael Stover <michael.r.stover gmail.com> writes:
--001636e0b5997ba116049767b97d
Content-Type: text/plain; charset=ISO-8859-1

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!

--001636e0b5997ba116049767b97d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I don&#39;t have any problems you seem to have with gmail. =A0I suspect att= itude is a big difference.<br><br><div class=3D"gmail_quote">On Tue, Dec 14= , 2010 at 6:43 PM, Adam D. Ruppe <span dir=3D"ltr">&lt;<a href=3D"mailto:de= structionator gmail.com">destructionator gmail.com</a>&gt;</span> wrote:<br=

x #ccc solid;padding-left:1ex;">Michael Stover:<br> <div class=3D"im">&gt; Did you use the gmail webapp to write that?<br> <br> </div>No. My public email address is gmail so I get a free spam<br> filter and online archive, but I don&#39;t actually use their<br> awful, awful interface. (All incoming mail to that address is<br> forwarded to my real email address, and my outgoing mail is<br> SMTP relayed back through gmail. My real address remains spam<br> free by being secret.)<br> <br> This does bring me to two rants though:<br> <br> a) Gmail&#39;s web interface is horrible, even the basic HTML<br> version. Consider this: right click a message... no &quot;open in<br> new window&quot; option! WTF.<br> <br> I handle, on average, about 170 emails a day. In my mail client<br> (mutt) and my server setup, this is no bother for me. There&#39;s no<br> waiting on slow servers. The controls are natural and fluid. I can<br> pick up on another computer right where I left off, thanks to<br> GNU screen. When I&#39;m emailed a dozen attachments, it is a simple<br> case of hitting a button to save them all locally - no annoying<br> scan and downloading of them individually.<br> <br> With gmail, I&#39;d have to click through the messages one thread at a time= , never<br> seeing the whole message (their hiding of quoted text and signatures, not 1= 00%<br> accurate!). Try to reply? Have to deal<br> with their godawful editor (with mutt I can just use vim) and<br> the hidden text below it (implicit top quoting, are they on drugs?).<br> <br> With new incoming mail, my computer beeps the second it arrives<br> and is idle while waiting. With gmail, it&#39;d be sitting there<br> polling, at the notice it does give doesn&#39;t even compare in terms<br> of usability or speed.<br> <br> Oh, and search? Surely Google could get search right? Nope<br> <br> <br> The worst part? Gmail might have the best of the web mail interfaces. Goes = to tell<br> you how dreadfully awful they are in general.<br> <br> <br> <br> b) I am posting this from the digitalmars news web interface.<br> For some reason, my emails don&#39;t seem to reliably get through.<br> <br> And this php webnews thing makes gmail look like heaven. It&#39;s<br> amazing the level of suck in this thing. I&#39;m sure everyone<br> who has used it will agree so I&#39;ll spare you the long rant.<br> <br> But there&#39;s times that I feel the greatest service someone<br> could do for D would be to replace this thing!<br> </blockquote></div><br> --001636e0b5997ba116049767b97d--
Dec 14 2010
prev sibling next sibling parent reply Michael Stover <michael.r.stover gmail.com> writes:
--000e0cd15826f50d1504976807e7
Content-Type: text/plain; charset=ISO-8859-1

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.

--000e0cd15826f50d1504976807e7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I&#39;ve used Pegasus, thunderbird, Exchange, Evolution, and whatever is on= my Mac by default (briefly). =A0I&#39;ve used other web emails too, includ= ing one for Exchange, which is terrible. =A0Some of your complaints are not= generic to javascript/web apps - like the right click complaint. =A0It can= be done easily. =A0They didn&#39;t do it, but this complaint is not damnin= g against the browser platform.<div> <br></div><div>Complaining the editor isn&#39;t like vi just makes me roll = my eyes. =A0Few would really want it to be. =A0However, again, there are vi= clones in javascript, if one were really wanted it.</div><div><br></div><d= iv> I didn&#39;t understand your complaint about having to read one thread at a= time. =A0I don&#39;t have the ability to read more than one at a time anyw= ay, so I do not have this complaint.=A0</div><div><br></div><div>The server= has never been slow for me, at all. =A0I set one browser tab to gmail at t= he start of the day and never think about it again. =A0New emails are alway= s just there for me.</div> <div><br></div><div>I can go anywhere and get my email, including the compu= ters at the Y, the library, from behind the firewall at work, and on my sis= ter&#39;s computer when I go visit her for Christmas. =A0I won&#39;t have t= o install anything to be able to do so.</div> <div><br></div><div>I probably get ~100 non-spam emails a day here. =A0Mana= ging it is hardly any work at all.</div><div><br></div><div>I really don&#3= 9;t think the complaints about the browser platform and javascript have muc= h validity anymore. =A0They used to. =A0But I think those days are gone, an= d I think it&#39;s like the whole &quot;java is slow&quot; phenomenon. =A0 = It takes a ridiculously long time for most people to change their perceptio= n of things once they&#39;ve had a bad experience.</div> <div><br></div><div>Mike=A0<br><br><div class=3D"gmail_quote">On Tue, Dec 1= 4, 2010 at 7:15 PM, Adam D. Ruppe <span dir=3D"ltr">&lt;<a href=3D"mailto:d= estructionator gmail.com">destructionator gmail.com</a>&gt;</span> wrote:<b= r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:= 1px #ccc solid;padding-left:1ex;"> <div class=3D"im">&gt; I don&#39;t have any problems you seem to have with = gmail.<br> <br> </div>Two questions:<br> <br> a) Have you ever tried a better alternative? If you&#39;ve only<br> used crap, a polished turd looks really really good.<br> <br> b) How much email do you handle? I used the web interface<br> for quite a while before I went into business. It works ok<br> if you do a low volume of low priority email stuff. (as they<br> say, anything is fast with small n)<br> <br> I just logged in. Here&#39;s what it greeted me with (after taking<br> its sweet time loading):<br> <br> Inbox (31187)<br> <br> Though now, even for a small volume, I can&#39;t go back. It&#39;d be<br> like using C after spending so much time with D.<br> </blockquote></div><br></div> --000e0cd15826f50d1504976807e7--
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
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 Michael Stover <michael.r.stover gmail.com> writes:
--000e0cd30bb83b605d04978d14fa
Content-Type: text/plain; charset=ISO-8859-1

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

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

 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. --000e0cd30bb83b605d04978d14fa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <br><br><div class=3D"gmail_quote">On Thu, Dec 16, 2010 at 2:48 PM, Nick Sa= balausky <span dir=3D"ltr">&lt;a a.a&gt;</span> wrote:<br><blockquote class= =3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd= ing-left:1ex;"> <div class=3D"im">&quot;Michael Stover&quot; &lt;<a href=3D"mailto:michael.= r.stover gmail.com">michael.r.stover gmail.com</a>&gt; wrote in message<br> </div>news:mailman.1046.1292468790.21107.digitalmars-d puremagic.com...<br> <div class=3D"im">&gt;&gt; there&#39;s no integration with the<br> &gt; external environment<br> &gt;<br> </div><div class=3D"im">&gt; But it is an advantage at the same time as it&= #39;s a weakness. =A0The advantage<br> &gt; is, I can read and use gmail or google docs anywhere, firewall or not.= <br> &gt;<br> <br> </div>That&#39;s entirely possible without cramming the whole thing through= a webpage.<br> I can thank of at least a couple ways just off the top of my head. The<br> *only* reason you don&#39;t see outside of the web browser it is because<br=

the web<br> browser. It&#39;s *not* a technical limitation of not using a web browser. = If<br> anything, it&#39;s just a widespread misconception amoung people who grew u= p<br> writing web code and therefore don&#39;t know any better about what is and = isn&#39;t<br> possible.<br></blockquote><div><br></div><div>What&#39;s possible and what&= #39;s reasonable to two are different things. =A0Clearly, implementors and = users are converging on the idea that browsers are the easiest way to do th= is. =A0You can do it other ways, go ahead. =A0You think you&#39;ll get wide= spread adoption?</div> <div><br></div><div>=A0You can argue against javascript and browsers, sure,= but I&#39;m not sure why you feel it&#39;s productive to be so insulting a= bout it.=A0</div></div><br> --000e0cd30bb83b605d04978d14fa--
Dec 16 2010
prev sibling next 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 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
prev sibling next sibling parent Michael Stover <michael.r.stover gmail.com> writes:
--000e0cd17e4c6e9d8e049773982d
Content-Type: text/plain; charset=ISO-8859-1

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

 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

 so
 keyboard control works at least somewhat well.

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

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

 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

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

 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?

 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

 good
 enough as webmail with or without scripting.

You've just described what I call "The *right* way to make a website".

--000e0cd17e4c6e9d8e049773982d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable And that&#39;s the problem - we&#39;re talking about applications that happ= en to be distributed via the web, not a &quot;website&quot;. =A0Everyone&#3= 9;s demands that it work in lynx, FF2, with javascript turned off, etc are = ludicrous. =A0You don&#39;t get to make such demands of applications. Some = applications are Windows only. =A0Some don&#39;t follow platform standards.= =A0Some require 1GB to work effectively. =A0None let you require it work w= ithout running code, etc. =A0<div> <br></div><div>These expectations are invalid.<br><br><div class=3D"gmail_q= uote">On Wed, Dec 15, 2010 at 2:24 AM, Nick Sabalausky <span dir=3D"ltr">&l= t;a a.a&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"mar= gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> &quot;Adam D. Ruppe&quot; &lt;<a href=3D"mailto:destructionator gmail.com">= destructionator gmail.com</a>&gt; wrote in message<br> news:ie9hjv$r1n$1 digitalmars.com...<br> <div><div></div><div class=3D"h5">&gt;&gt; What about Hotmail, Yahoo, Mobil= eMe, etc?<br> &gt;<br> &gt; I haven&#39;t used most of them for a long time. Gmail gets most<br> &gt; my ranting because its the one I&#39;ve used most recently. (And<br> &gt; I remember my password to it so I could sign in and re-check<br> &gt; my statements before posting too.)<br> &gt;<br> &gt; If I were writing a webmail program, here&#39;s how I&#39;d do it thou= gh:<br> &gt;<br> &gt; 1) Start with a regular HTML view. A simple table of from/date/<br> &gt; subject, and a compose button. The messages are standard links, so ope= ning<br> &gt; in a<br> &gt; new window works as expected.<br> &gt;<br> &gt; The compose screen is a very basic form. The website should be<br> &gt; perfectly usable in the Lynx browser.<br> &gt;<br> &gt; 2) Beef up the html. Ensure things like accesskeys and tabindexes are = set,<br> &gt; so<br> &gt; keyboard control works at least somewhat well.<br> &gt;<br> &gt; 3) Go back and start adding stuff on to it with scripts. The gmail pol= ling<br> &gt; for new<br> &gt; message notification is pretty useful, so add that. Having auto-comple= tion<br> &gt; of your<br> &gt; friends&#39; email addresses is a nice thing gmail does too. I might a= dd a<br> &gt; document<br> &gt; keypress handler to add hotkeys, since I&#39;m not really happy with b= rowser<br> &gt; implementations of accesskeys (alt+shift+letter in firefox - did they = not<br> &gt; realize<br> &gt; the whole point was to be /accessible/? I can&#39;t get my fingers to = contort<br> &gt; that way<br> &gt; without hunt+pecking with both hands! But my old konqueror is much<br> &gt; better - hit<br> &gt; control to toggle them on and off - and that&#39;s what I use, so meh.= )<br> &gt;<br> &gt; 4) The scripts might fetch the message after the one you click on as w= ell,<br> &gt; just<br> &gt; ajax getting the next document in line then doing nothing with the res= ult.<br> &gt; My<br> &gt; server code would be configured to send the proper cache headers, mean= ing<br> &gt; when you<br> &gt; click the link to actually view it, it is pre-loaded in the cache, and= <br> &gt; thus loads<br> &gt; instantly. A lot of websites do it for images, why not documents too? = This<br> &gt; would<br> &gt; keep the user visible latency to a minimum while browsing messages.<br=

&gt;<br> &gt; That&#39;s about it. It wouldn&#39;t be as good as a real application,= but it&#39;d be<br> &gt; good<br> &gt; enough as webmail with or without scripting.<br> <br> </div></div>You&#39;ve just described what I call &quot;The *right* way to = make a website&quot;.<br> <br> <br> </blockquote></div><br></div> --000e0cd17e4c6e9d8e049773982d--
Dec 15 2010
prev sibling next sibling parent Michael Stover <michael.r.stover gmail.com> writes:
--000e0cd17e4c61769e0497741f50
Content-Type: text/plain; charset=ISO-8859-1

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

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.

--000e0cd17e4c61769e0497741f50 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable All of your complaints are about specific choices of the developers, not th= e technology. =A0Right now, javascript and web apps are being written (for = the most part) by young, inexperienced, often graphically-oriented individu= als. =A0Soon, more experience developers will join the scene and start writ= ing useful apps that aren&#39;t just eye-candy.<div> <br></div><div>&gt;<meta charset=3D"utf-8"><span class=3D"Apple-style-span"= style=3D"font-family: arial, sans-serif; font-size: 13px; border-collapse:= collapse; ">Any my emails are *my* emails, stored on my local box. If I wa= nt to back it up,<br> just copy the file. If I want a search that actually works, I can just grep= the<br>file, and so on. Just better in every way.</span></div><div><font c= lass=3D"Apple-style-span" face=3D"arial, sans-serif"><span class=3D"Apple-s= tyle-span" style=3D"border-collapse: collapse;"><br> </span></font></div><div><font class=3D"Apple-style-span" face=3D"arial, sa= ns-serif"><span class=3D"Apple-style-span" style=3D"border-collapse: collap= se;">The vast majority of people appreciate that they just get all that for= free and without bother in gmail, hotmail, yahoo, etc.</span></font></div> <div><font class=3D"Apple-style-span" face=3D"arial, sans-serif"><span clas= s=3D"Apple-style-span" style=3D"border-collapse: collapse;"><br></span></fo= nt></div><div><font class=3D"Apple-style-span" face=3D"arial, sans-serif"><= span class=3D"Apple-style-span" style=3D"border-collapse: collapse;">-Mike<= br> </span></font><br><div class=3D"gmail_quote">On Wed, Dec 15, 2010 at 9:47 A= M, Adam D. Ruppe <span dir=3D"ltr">&lt;<a href=3D"mailto:destructionator gm= ail.com">destructionator gmail.com</a>&gt;</span> wrote:<br><blockquote cla= ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa= dding-left:1ex;"> <div class=3D"im">Nick Sabalausky wrote:<br> &gt; Text editors that rely on JavaScript are abominations, period.<br> <br> </div>Any widget that does sucks IMO. I&#39;ve had to use javascript replac= ements of the<br> standard &lt;select&gt; tag too, and wow it blows.<br> <br> Wait for its animation to start up. Wait for its animation to finish. Click= an<br> option.... it didn&#39;t work, sorry my browser isn&#39;t good enough.<br> <br> Usually I just abandon the site, but sometimes I can&#39;t. So switch to fi= refox 3.<br> Wait for the animation to start up. Wait for it to finish. Click the thing.= Wait<br> for it to animate again. Oops, I got the wrong option, I&#39;ll just hit th= e down<br> arrow.... sorry, didn&#39;t work.<br> <br> Aaaaaarrrrrgggggghhhhhh!<br> <br> &quot;but but look at the super cool animations jquery is amazing! and i ca= n style this<br> thing better than the built in so nyah&quot;<br> <br> Gah.<br> <div class=3D"im"><br> <br> &gt; Look, look -&gt; There&#39;s my cake, and I&#39;m eating it!<br> <br> </div>This is one thing I love about running mutt in screen. If I have acce= ss to my home<br> box at all (directly or ssh) it works well. If I left a message half read, = when I<br> come back to it, it is still half read! No need to hunt it down again among= the<br> read messages, no need to scroll back to my original position. The screen i= s<br> *exactly* as I left it.<br> <br> Any my emails are *my* emails, stored on my local box. If I want to back it= up,<br> just copy the file. If I want a search that actually works, I can just grep= the<br> file, and so on. Just better in every way.<br> </blockquote></div><br></div> --000e0cd17e4c61769e0497741f50--
Dec 15 2010
prev sibling next sibling parent reply Andrew Wiley <debio264 gmail.com> writes:
--001517479648985111049776361e
Content-Type: text/plain; charset=ISO-8859-1

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). --001517479648985111049776361e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On Wed, Dec 15, 2010 at 9:37 AM, Adam D. Ruppe <= span dir=3D"ltr">&lt;<a href=3D"mailto:destructionator gmail.com">destructi= onator gmail.com</a>&gt;</span> wrote:<blockquote class=3D"gmail_quote" sty= le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> And in those rare cases where you are doing a lot of client side work, it i= s so<br> brutally slow that if you start piling other runtimes on top of it, you&#39= ;ll often<br> be left with an unusable mess anyway!</blockquote></div><div><br></div><div=
Unless you&#39;re using the beta of the next IE, the beta of the next Oper=

nt-side work is becoming more and more feasible. Now, it&#39;s not there ye= t, but when a C-ported-to-Java-compiled-to-Javascript version of Quake 2 ca= n get 30FPS in Google Chrome, I start thinking that performance probably wo= n&#39;t be nearly as bad as browsers move forward.</div> <div><br></div><div>You don&#39;t have to like it, but there&#39;s a huge p= ush in web development towards doing more work on the client, and now that = browsers are catching up, it&#39;s going to change the way the web works.</= div> <div><br></div><div>As for the rest:</div><div><span class=3D"Apple-style-s= pan" style=3D"font-family: arial, sans-serif; font-size: 13px; border-colla= pse: collapse; ">a) No real time networking</span></div><div><span class=3D= "Apple-style-span" style=3D"font-family: arial, sans-serif; font-size: 13px= ; border-collapse: collapse; ">HTML 5 WebSockets, as you said</span></div> <div><span class=3D"Apple-style-span" style=3D"font-family: arial, sans-ser= if; font-size: 13px; border-collapse: collapse; "><br>b) Cross domain commu= nication requires ugly, inefficient hacks, or a proxy on your=A0server.</sp= an></div> <div><span class=3D"Apple-style-span" style=3D"font-family: arial, sans-ser= if; font-size: 13px; border-collapse: collapse; ">This is the one thing you= &#39;ve listed that&#39;s not going to change because it poses a security r= isk.<br> <br>c) No sounds (without flash anyway).</span></div><div><font class=3D"Ap= ple-style-span" face=3D"arial, sans-serif"><span class=3D"Apple-style-span"= style=3D"border-collapse: collapse;">Included in HTML 5.</span></font></di= v><div> <span class=3D"Apple-style-span" style=3D"font-family: arial, sans-serif; f= ont-size: 13px; border-collapse: collapse; "><br>d) Graphics, even if you g= rant the canvas element, are a joke. The latency is<br>brutal. Take that de= viant art thing from earlier in the thread. Flick your mouse,<br> and watch the lines slowly catch up to you! Using X11 with a remote server = is<br>faster than that.</span></div><div><span class=3D"Apple-style-span" s= tyle=3D"font-family: arial, sans-serif; font-size: 13px; border-collapse: c= ollapse; ">In Chrome (even the version a year or so old that is installed o= n the lab computer I&#39;m using right now), there is no latency whatsoever= . That&#39;s a simple matter of javascript performance, which is dramatical= ly improving.<br> <br>e) Input requires a lot of magic. Some keys have the same identifiers, = some of the<br>time, meaning just checking for keypress requires dozens of = lines of code, and<br>still doesn&#39;t work right! Checking for multiple k= eys or mouse buttons hit at once<br> is very poor.</span></div><div><span class=3D"Apple-style-span" style=3D"fo= nt-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; "=
This is where frameworks can help. Now that Javascript performance is barr=

GWT (Java-&gt;Javascript) in the past, and input handling feels exactly lik= e it does in SWT or Swing (the leading Java UI frameworks).<br> <br>f) Very little state across loads (though html5 is adding something for= this, if<br>it ever gets broad penetration), mentioned mainly for complete= ness, since<br>javascript variables do work for must things, but your persi= stent database still<br> has to be on the server.</span></div><div><span class=3D"Apple-style-span" = style=3D"font-family: arial, sans-serif; font-size: 13px; border-collapse: = collapse; ">As you said, HTML5. My internet was down this morning, but I wa= s still able to read the batch of mail in GMail that I downloaded last nigh= t because GMail is already taking advantage of Google Gears, which provides= similar functionality. I get the same thing with a few other web applicati= ons.<br> <br>g) No threading. I recently tried making a javascript -&gt; d caller. I= n D, this<br>would be trivial: opDispatch means no code needs to be written= , and if it runs in<br>a different thread from the rest of the UI, it can m= ake sync calls to the server<br> without freezing everything up, thus letting it be written in a linear styl= e.</span></div><div><span class=3D"Apple-style-span" style=3D"font-family: = arial, sans-serif; font-size: 13px; border-collapse: collapse; ">HTML5 adds= WebWorkers, which handle exactly this use case (among others).</span></div=

--001517479648985111049776361e--
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
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 "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 "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

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
prev sibling next sibling parent Andrew Wiley <debio264 gmail.com> writes:
--20cf3054a475616bb1049776834d
Content-Type: text/plain; charset=ISO-8859-1

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) --20cf3054a475616bb1049776834d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On Wed, Dec 15, 2010 at 11:24 AM, Andrew Wiley <= span dir=3D"ltr">&lt;<a href=3D"mailto:debio264 gmail.com">debio264 gmail.c= om</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg= in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div class=3D"im"><div class=3D"gmail_quote">On Wed, Dec 15, 2010 at 9:37 A= M, Adam D. Ruppe <span dir=3D"ltr">&lt;<a href=3D"mailto:destructionator gm= ail.com" target=3D"_blank">destructionator gmail.com</a>&gt;</span> wrote:<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> And in those rare cases where you are doing a lot of client side work, it i= s so<br> brutally slow that if you start piling other runtimes on top of it, you&#39= ;ll often<br> be left with an unusable mess anyway!</blockquote></div><div><br></div></di= v><div>Unless you&#39;re using the beta of the next IE, the beta of the nex= t Opera, or the current version of Chrome, in which case you&#39;d find tha= t client-side work is becoming more and more feasible. Now, it&#39;s not th= ere yet, but when a C-ported-to-Java-compiled-to-Javascript version of Quak= e 2 can get 30FPS in Google Chrome, I start thinking that performance proba= bly won&#39;t be nearly as bad as browsers move forward.</div> <div><br></div><div>You don&#39;t have to like it, but there&#39;s a huge p= ush in web development towards doing more work on the client, and now that = browsers are catching up, it&#39;s going to change the way the web works.</= div> <div><br></div><div>As for the rest:</div><div class=3D"im"><div><span styl= e=3D"font-family:arial, sans-serif;font-size:13px;border-collapse:collapse"=
a) No real time networking</span></div></div><div><span style=3D"font-fami=

kets, as you said</span></div> <div class=3D"im"> <div><span style=3D"font-family:arial, sans-serif;font-size:13px;border-col= lapse:collapse"><br>b) Cross domain communication requires ugly, inefficien= t hacks, or a proxy on your=A0server.</span></div> </div><div><span style=3D"font-family:arial, sans-serif;font-size:13px;bord= er-collapse:collapse">This is the one thing you&#39;ve listed that&#39;s no= t going to change because it poses a security risk.<div class=3D"im"><br> <br>c) No sounds (without flash anyway).</div></span></div><div><font face= =3D"arial, sans-serif"><span style=3D"border-collapse:collapse">Included in= HTML 5.</span></font></div><div class=3D"im"><div> <span style=3D"font-family:arial, sans-serif;font-size:13px;border-collapse= :collapse"><br>d) Graphics, even if you grant the canvas element, are a jok= e. The latency is<br>brutal. Take that deviant art thing from earlier in th= e thread. Flick your mouse,<br> and watch the lines slowly catch up to you! Using X11 with a remote server = is<br>faster than that.</span></div></div><div><span style=3D"font-family:a= rial, sans-serif;font-size:13px;border-collapse:collapse">In Chrome (even t= he version a year or so old that is installed on the lab computer I&#39;m u= sing right now), there is no latency whatsoever. That&#39;s a simple matter= of javascript performance, which is dramatically improving.<div class=3D"i= m"> <br> <br>e) Input requires a lot of magic. Some keys have the same identifiers, = some of the<br>time, meaning just checking for keypress requires dozens of = lines of code, and<br>still doesn&#39;t work right! Checking for multiple k= eys or mouse buttons hit at once<br> is very poor.</div></span></div><div><span style=3D"font-family:arial, sans= -serif;font-size:13px;border-collapse:collapse">This is where frameworks ca= n help. Now that Javascript performance is barrelling ahead, frameworks sta= rt looking much more attractive. I&#39;ve used GWT (Java-&gt;Javascript) in= the past, and input handling feels exactly like it does in SWT or Swing (t= he leading Java UI frameworks).<div class=3D"im"> <br> <br>f) Very little state across loads (though html5 is adding something for= this, if<br>it ever gets broad penetration), mentioned mainly for complete= ness, since<br>javascript variables do work for must things, but your persi= stent database still<br> has to be on the server.</div></span></div><div><span style=3D"font-family:= arial, sans-serif;font-size:13px;border-collapse:collapse">As you said, HTM= L5. My internet was down this morning, but I was still able to read the bat= ch of mail in GMail that I downloaded last night because GMail is already t= aking advantage of Google Gears, which provides similar functionality. I ge= t the same thing with a few other web applications.<div class=3D"im"> <br> <br>g) No threading. I recently tried making a javascript -&gt; d caller. I= n D, this<br>would be trivial: opDispatch means no code needs to be written= , and if it runs in<br>a different thread from the rest of the UI, it can m= ake sync calls to the server<br> without freezing everything up, thus letting it be written in a linear styl= e.</div></span></div><div><span style=3D"font-family:arial, sans-serif;font= -size:13px;border-collapse:collapse">HTML5 adds WebWorkers, which handle ex= actly this use case (among others).</span></div> </blockquote><div><br></div><div>I should also note that every HTML5 featur= e I mentioned here except WebSockets is also supported in Firefox 3.5. IE9 = supports everything but WebSockets and WebWorkers. (Apparently there&#39;s = some trouble with the WebSockets specification at the moment)</div> </div><br> --20cf3054a475616bb1049776834d--
Dec 15 2010
prev sibling next sibling parent "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
prev sibling next sibling 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 next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
------------be6thmems7fJ77SCmfMZpY
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
Content-Transfer-Encoding: 8bit

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 ------------be6thmems7fJ77SCmfMZpY Content-Disposition: attachment; filename=Json.d Content-Type: application/octet-stream; name="Json.d" Content-Transfer-Encoding: Base64 LyoqDQogKiBKU09OIGVuY29kaW5nLg0KICoNCiAqIENvcHlyaWdodCAyMDEwICBW bGFkaW1pciBQYW50ZWxlZXYgPHRoZWN5YmVyc2hhZG93QGdtYWlsLmNvbT4NCiAq Lw0KDQptb2R1bGUgSHR0cC5Kc29uOw0KDQppbXBvcnQgc3RkLnN0cmluZzsNCg0K c3RyaW5nIGpzb25Fc2NhcGUoc3RyaW5nIHN0cikNCnsNCglzdHJpbmcgcmVzdWx0 Ow0KCWZvcmVhY2goYztzdHIpDQoJCWlmIChjPT0nXFwnIHx8IGM9PSciJykNCgkJ CXJlc3VsdCB+PSAiXFwiIH4gW2NdOw0KCQllbHNlDQoJCWlmIChjPT0nXDAnKQ0K CQkJe30NCgkJZWxzZQ0KCQlpZiAoYz09J1xiJykNCgkJCXJlc3VsdCB+PSBgXGJg Ow0KCQllbHNlDQoJCWlmIChjPT0nXGYnKQ0KCQkJcmVzdWx0IH49IGBcZmA7DQoJ CWVsc2UNCgkJaWYgKGM9PSdcbicpDQoJCQlyZXN1bHQgfj0gYFxuYDsNCgkJZWxz ZQ0KCQlpZiAoYz09J1xyJykNCgkJCXJlc3VsdCB+PSBgXHJgOw0KCQllbHNlDQoJ CWlmIChjPT0nXHQnKQ0KCQkJcmVzdWx0IH49IGBcdGA7DQoJCWVsc2UNCgkJCXJl c3VsdCB+PSBbY107DQoJcmV0dXJuIHJlc3VsdDsNCn0NCg0Kc3RyaW5nIHRvSnNv bihUKShUIHYpDQp7DQoJc3RhdGljIGlmIChpcyhUPT1zdHJpbmcpKQ0KCQlyZXR1 cm4gIlwiIiB+IGpzb25Fc2NhcGUodikgfiAiXCIiOw0KCWVsc2UNCglzdGF0aWMg aWYgKGlzKFQgOiBsb25nKSkNCgkJcmV0dXJuIC50b1N0cmluZyh2KTsNCgllbHNl DQoJc3RhdGljIGlmIChpcyhUIFUgOiBVW10pKQ0KCXsNCgkJc3RyaW5nW10gaXRl bXM7DQoJCWZvcmVhY2ggKGl0ZW07IHYpDQoJCQlpdGVtcyB+PSB0b0pzb24oaXRl bSk7DQoJCXJldHVybiAiWyIgfiBqb2luKGl0ZW1zLCAiLCIpIH4gIl0iOw0KCX0N CgllbHNlDQoJc3RhdGljIGlmIChpcyhUPT1zdHJ1Y3QpKQ0KCXsNCgkJc3RyaW5n IGpzb247DQoJCWZvcmVhY2ggKGksIGZpZWxkOyB2LnR1cGxlb2YpDQoJCQlqc29u IH49IHRvSnNvbih2LnR1cGxlb2ZbaV0uc3RyaW5nb2ZbMi4uJF0pIH4gIjoiIH4g dG9Kc29uKGZpZWxkKSB+ICIsIjsNCgkJaWYoanNvbi5sZW5ndGg+MCkNCgkJCWpz b249anNvblswLi4kLTFdOw0KCQlyZXR1cm4gInsiIH4ganNvbiB+ICJ9IjsNCgl9 DQoJZWxzZQ0KCXN0YXRpYyBpZiAoaXModHlwZW9mKFQua2V5cykpICYmIGlzKHR5 cGVvZihULnZhbHVlcykpKQ0KCXsNCgkJc3RyaW5nIGpzb247DQoJCWZvcmVhY2go a2V5LHZhbHVlO3YpDQoJCQlqc29uIH49IHRvSnNvbihrZXkpIH4gIjoiIH4gdG9K c29uKHZhbHVlKSB+ICIsIjsNCgkJaWYoanNvbi5sZW5ndGg+MCkNCgkJCWpzb249 anNvblswLi4kLTFdOw0KCQlyZXR1cm4gInsiIH4ganNvbiB+ICJ9IjsNCgl9DQoJ ZWxzZQ0KCXN0YXRpYyBpZiAoaXModHlwZW9mKCp2KSkpDQoJCXJldHVybiB0b0pz b24oKnYpOw0KCWVsc2UNCgkJc3RhdGljIGFzc2VydCgwLCAiQ2FuJ3QgZW5jb2Rl ICIgfiBULnN0cmluZ29mIH4gIiB0byBKU09OIik7DQp9DQoNCnVuaXR0ZXN0DQp7 DQoJc3RydWN0IFggeyBpbnQgYTsgc3RyaW5nIGI7IH0NCglYIHggPSB7MTcsICJh b2V1In07DQoJYXNzZXJ0KHRvSnNvbih4KSA9PSBgeyJhIjoxNywiYiI6ImFvZXUi fWApOw0KCWludFtdIGFyciA9IFsxLDUsN107DQoJYXNzZXJ0KHRvSnNvbihhcnIp ID09IGBbMSw1LDddYCk7DQp9DQo= ------------be6thmems7fJ77SCmfMZpY--
Dec 15 2010
prev sibling next sibling parent reply Andrew Wiley <debio264 gmail.com> writes:
--20cf3054a475bfdfb20497774681
Content-Type: text/plain; charset=ISO-8859-1

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*. --20cf3054a475bfdfb20497774681 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On Wed, Dec 15, 2010 at 12:18 PM, Nick Sabalausk= y <span dir=3D"ltr">&lt;a a.a&gt;</span> wrote:<blockquote class=3D"gmail_q= uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e= x;">A game that was designed to run on a 90-133MHz 16-24MB RAM machine (in<= br> *software* rendering mode), and was frequently able to get framerates in th= e<br> hundreds on sub-500MHz machines (using hardware rendering - with the old,<b= r> old, old 3dfx cards), manages to get *only* 30FPS in JS on a multi-GHz<br> multi-core machine using what is clearly hardware rendering (on a modern<br=

anything, that&#39;s *proof* of how horrid JS is - it turns a multi-GHz<br> multi-core into a Pentium ~100MHz. What a joke!<br>=A0</blockquote><div>The= point was that while Javascript is slow, it&#39;s getting fast enough to b= e useful. Yes, it&#39;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.</div> <div>Javascript was not designed to be fast, and honestly, it doesn&#39;t n= eed to be fast to fill it&#39;s niche.</div><blockquote class=3D"gmail_quot= e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"=

&gt; [HTML5, HTML5, HTML5, Chrome, HTML5, HTML5...]<br> <br> Yea, *eventually* HTML5 will *improve* a few things...That hardly counts as= <br> &quot;The web&#39;s not a shitty platform!&quot;.<br></blockquote><div><br>= </div><div>Well, there was a list of reasons why it was a shitty platform, = and I showed that it&#39;s not as shitty as it seems. Honestly, I agree tha= t it&#39;s a shitty platform in general, but it&#39;s also not nearly as ba= d as many people think it is, and a lot of effort is going into reducing it= s relative shittiness.=A0</div> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;"> <br> And what percentage of web users use Chrome? Less than 99%? Well then it<br=

&#39;m<br> not going to design my pages to require it, end of story, and I&#39;m sure = as<br> hell not going to be one of those &quot;This site best viewed with X browse= r&quot;<br> assholes.<br>=A0</blockquote><div>Thus my explicit and repeated mentions of= Opera, Firefox, and IE9 supporting the same features. This isn&#39;t a Chr= ome only thing, and competition alone is insuring that these features aren&= #39;t Chrome-only. These aren&#39;t things coming *eventually* to each brow= ser, they&#39;re things that browser developers are adding *now*.</div> </div> --20cf3054a475bfdfb20497774681--
Dec 15 2010
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 "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
prev sibling next 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.

*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 next sibling parent 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
prev sibling next sibling parent Michael Stover <michael.r.stover gmail.com> writes:
--000e0cd17e4c90f364049777e556
Content-Type: text/plain; charset=ISO-8859-1

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

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.

--000e0cd17e4c90f364049777e556 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable &gt;<meta charset=3D"utf-8"><span class=3D"Apple-style-span" style=3D"font-= family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">An= d no, I&#39;m *not* playing semantics games here: &quot;Distributed via the= <br> web&quot; means exactly what it means</span><div><font class=3D"Apple-style= -span" face=3D"arial, sans-serif"><span class=3D"Apple-style-span" style=3D= "border-collapse: collapse;"><br></span></font></div><div><font class=3D"Ap= ple-style-span" face=3D"arial, sans-serif"><span class=3D"Apple-style-span"= style=3D"border-collapse: collapse;">Of course you&#39;re playing semantic= games. =A0Not being very helpful in the discussion. =A0You seem to be argu= ing that if the content arrived via &quot;http&quot; it must work in lynx o= r else it &quot;sucks&quot;. =A0Perhaps I will just rename it to &quot;ws&q= uot; and then you can have some new expectations that don&#39;t cloud your = judgement so.<br> </span></font><br><div class=3D"gmail_quote">On Wed, Dec 15, 2010 at 1:51 P= M, Adam D. Ruppe <span dir=3D"ltr">&lt;<a href=3D"mailto:destructionator gm= ail.com">destructionator gmail.com</a>&gt;</span> wrote:<br><blockquote cla= ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa= dding-left:1ex;"> <div class=3D"im">Nick Sabalausky wrote:<br> &gt; that&#39;s *proof* of how horrid JS is<br> <br> </div>I often feel Google is re-discovering DOS&#39; capabilities and going= on about how<br> great it is. Got it in graphics and input, and files too.<br> <br> HTML5 local storage is a bunch of key/item pairs. Wooo, it&#39;s like a fil= esystem<br> with only a root directory!<br> <br> I wonder if it even works to store interesting data. When I was working on = the<br> DWS/AJAX viewer (Which I still intend to finish if I get a decent break fro= m<br> work... that I don&#39;t spend flamewarring on the newsgroup), I tried to g= et a binary<br> string sent down, manipulated, and finally displayed as an image.<br> <br> But:<br> <br> var img =3D new Image(binaryData); // didn&#39;t work<br> <br> Some browsers supported a img.src =3D &quot;data://&quot; + encodedBinaryDa= ta, but not all of<br> them did, and the limit was obscenely small anyway.<br> <br> I ultimately just served it from the server and referenced it via url. But = I had<br> that option since there was a server app available... what would the local = storage do?<br> <br> <br> Blargh.<br> <div class=3D"im"><br> <br> &gt; I&#39;m sure as hell not going to be one of<br> &gt; those &quot;This site best viewed with X browser&quot; assholes.<br> <br> </div>I might be one of those people, though I don&#39;t come out and say i= t, my sites do<br> tend to be best viewed with X browser.<br> <br> But the important difference is it still *works* in Y and Z browser. It jus= t won&#39;t<br> have rounded corners, etc.<br> </blockquote></div><br></div> --000e0cd17e4c90f364049777e556--
Dec 15 2010
prev sibling next sibling parent reply Michael Stover <michael.r.stover gmail.com> writes:
--000e0cd328a09237530497782dbe
Content-Type: text/plain; charset=ISO-8859-1

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? --000e0cd328a09237530497782dbe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <br><br><div class=3D"gmail_quote">On Wed, Dec 15, 2010 at 2:26 PM, retard = <span dir=3D"ltr">&lt;re tard.com.invalid&gt;</span> wrote:<br><blockquote = class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid= ;padding-left:1ex;"> <div class=3D"im">Wed, 15 Dec 2010 12:40:50 -0600, Andrew Wiley wrote:<br> <br> &gt; The point was that while Javascript is slow, it&#39;s getting fast eno= ugh<br> &gt; to be useful. Yes, it&#39;s not C. It will never be. But the fact that= any<br> &gt; sort of realtime calculations are possible in it is a breakthrough tha= t<br> &gt; will be reflected in actual application code. Javascript was not<br> &gt; designed to be fast, and honestly, it doesn&#39;t need to be fast to f= ill<br> &gt; it&#39;s niche.<br> <br> </div>I&#39;m not getting this. WHY we should use Javascript/HTML5 applicat= ions<br> instead. I&#39;m perfectly happy with my existing tools. They work nicely. = It<br> takes years to develop these applications on top of HTML5. I simply have<br=

<br> =A0- you &quot;rent&quot; the app, you don&#39;t &quot;own&quot; it anymore= <br></blockquote><div><br></div><div>Many would find that a benefit, as upd= ates are automatic, never need to install new versions.</div><div>=A0</div> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;"> =A0 =3D&gt; which leads to: advertisements, monthly fees<br></blockquote><= div><br></div><div>Again, benefits galore for some folks. =A0Should 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&#39;m done with it?<= /div> <div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex= ;border-left:1px #ccc solid;padding-left:1ex;"> =A0 - this is especially bad if you&#39;re already using free as in beer/<= br> speech software<br></blockquote><div><br></div><div>gmail is free as in bee= r and nothing prevents it being open source.</div><div>=A0</div><blockquote= class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli= d;padding-left:1ex;"> =A0 - this is especially bad ethically if you&#39;re writing free software= <br></blockquote><div><br></div><div>There is no change here.=A0</div><bloc= kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc= c solid;padding-left:1ex;"> <br> =A0- worse privacy (do I want some Mark SuckerBerg to spy on my personal<br=

h applications you install on your computer. =A0Perhaps they are worse in t= hat case, since so many people have so many problems with malware, spyware,= worms and viruses.</div> <div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;= border-left:1px #ccc solid;padding-left:1ex;"> <br> =A0- worse security (a networkless local box IS quite safe, if CIA is<br> raiding your house every week, you&#39;re probably doing something wrong,<b= r> otherwise, buy better locks)<br></blockquote><div><br></div><div>Javascript= +browser can be a purely client-machine application too just like D or Java= or C</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor= der-left:1px #ccc solid;padding-left:1ex;"> <br> =A0- worse performance (at least now and in the next few years)<br></blockq= uote><div><br></div><div>Yes. =A0But if you take frame rates in games, whic= h is a terrible example for javascript, the more general truth is that beyo= nd a certain point, performance differences are undetectable to the human e= ye. =A0At which point, the only thing driving your technology choice is dev= eloper productivity. =A0Even before that point of undetectability, most peo= ple will choose the app that provides more features over the one that perfo= rms somewhat better. =A0And for good reason. =A0Something being a little sl= ow vs not being able to do it at all is an easy choice for most people. =A0= People on this mailing list are somewhat eccentric in their demands, which = is entirely their right, but y&#39;all should at least recognize web apps a= re and will be successful by and large.</div> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;"> <br> =A0- worse usability<br></blockquote><div><br></div><div>Completely disagre= e. =A0Desktop apps right now have an enormous advantage in how much develop= ment-hours have gone into them over web app counterparts. =A0This will chan= ge, quickly.</div> <div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;= border-left:1px #ccc solid;padding-left:1ex;"> <br> =A0- worse reliability (network problems, server problems)<br></blockquote>= <div><br></div><div>In theory, yes, and once in a while it is a problem, bu= t I honestly can&#39;t remember the last time I had any issues with connect= ivity.</div> <div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;= border-left:1px #ccc solid;padding-left:1ex;"> <br> I know the good sides. No need to mention them. In my opinion the<br> downsides are still more important when making the decision.<br></blockquot= e><div><br></div><div>Honestly, where do think things will stand 5-10 years= from now? =A0=A0</div></div><br> --000e0cd328a09237530497782dbe--
Dec 15 2010
parent "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
prev sibling next sibling parent "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*

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
prev sibling next sibling parent "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
prev sibling next sibling parent reply Michael Stover <michael.r.stover gmail.com> writes:
--000e0cd17e4c9ab9650497788b79
Content-Type: text/plain; charset=ISO-8859-1

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

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

 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.

--000e0cd17e4c9ab9650497788b79 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If I provide a spreadsheet program via javascript, why should it have to wo= rk in Lynx? It&#39;s not a web page. =A0I&#39;m providing absolutely ZERO c= ontent. =A0It is only behavior, just like Excel is only behavior. =A0If I p= rovide the same functionality, but only if you use Chrome or Firefox, why i= s that so horrible?<br> <br><div class=3D"gmail_quote">On Wed, Dec 15, 2010 at 2:50 PM, Nick Sabala= usky <span dir=3D"ltr">&lt;a a.a&gt;</span> wrote:<br><blockquote class=3D"= gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-= left:1ex;"> &quot;Michael Stover&quot; &lt;<a href=3D"mailto:michael.r.stover gmail.com= ">michael.r.stover gmail.com</a>&gt; wrote in message<br> news:mailman.1034.1292441124.21107.digitalmars-d puremagic.com...<br> <div class=3D"im">&gt; &gt;And no, I&#39;m *not* playing semantics games he= re: &quot;Distributed via the<br> &gt; web&quot; means exactly what it means<br> &gt;<br> &gt; Of course you&#39;re playing semantic games. =A0Not being very helpful= in the<br> &gt; discussion. =A0You seem to be arguing that if the content arrived via = &quot;http&quot;<br> &gt; it must work in lynx or else it &quot;sucks&quot;.<br> &gt;<br> <br> </div>Not at all. In fact that blatantly contradicts what I just pointed ou= t.<br> Things like DMD, certain OSes, etc, all arrive via http (or ftp, whatever,<= br> like that matters) and yet, like I said, they&#39;re obviously not what we&= #39;re<br> talking about when we&#39;re talking about web apps.<br> <br> Secondly, I&#39;m not the one that brought up Lynx. Although if there&#39;s= <br> something that clearly doesn&#39;t need graphics and such to be useful, the= n<br> yes, it absolutely should work on Lynx. Apps obviously shouldn&#39;t requir= e<br> things they don&#39;t need: My DB shouldn&#39;t require I have a webcam ins= talled.<br> Grep shouldn&#39;t require an email client. Making a backup shouldn&#39;t r= equire<br> OpenGL or a printer. Submitting a form or downloading a PDF shouldn&#39;t<b= r> require JS or HTML images. Viewing information on an official county probat= e<br> court website shouldn&#39;t require Flash (I&#39;ve actually seen that, and= I&#39;d be<br> very surprised if it doesn&#39;t violate multiple government-mandated<br> accessibility requirements). Etc.<br> <br> <br> </blockquote></div><br> --000e0cd17e4c9ab9650497788b79--
Dec 15 2010
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 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
prev sibling next sibling parent reply Michael Stover <michael.r.stover gmail.com> writes:
--000e0cd14b8adbb15a049778b935
Content-Type: text/plain; charset=ISO-8859-1

Trying to

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.

--000e0cd14b8adbb15a049778b935 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable &gt;<meta charset=3D"utf-8"><span class=3D"Apple-style-span" style=3D"font-= family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">Tr= ying to<br>make an online payment to Visa or check on one of Visa&#39;s pol= icies? Are you<br> gonna be able to do that at MasterCard&#39;s website? With desktop software= <br>stuff like that rarely happens. Basically, websites/webapps have a grea= ter<br>need for compatibility than desktop apps do.</span><div><font class= =3D"Apple-style-span" face=3D"arial, sans-serif"><span class=3D"Apple-style= -span" style=3D"border-collapse: collapse;"><br> </span></font></div><div><font class=3D"Apple-style-span" face=3D"arial, sa= ns-serif"><span class=3D"Apple-style-span" style=3D"border-collapse: collap= se;">Again, we&#39;re not talking about <i>websites</i>. =A0We&#39;re talki= ng about web <i>apps</i>. =A0Of course your bank site ought to provide you = your account info whether you are on a Mac or Windows and even if you use I= E 5.5. =A0But that&#39;s not what we&#39;re talking about. =A0We&#39;re tal= king about someone making an application that, today or in the past you wou= ld have downloaded and installed, and instead making it runnable in a brows= er. =A0It&#39;s not content, it&#39;s <i>behavior</i> you&#39;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 us= e them instead. =A0There&#39;s no tie to some particular content provided (= like Visa), just like there isn&#39;t with desktop apps.</span></font></div=

s=3D"Apple-style-span" style=3D"border-collapse: collapse;"><br></span></fo= nt></div><div><font class=3D"Apple-style-span" face=3D"arial, sans-serif"><= span class=3D"Apple-style-span" style=3D"border-collapse: collapse;">Mike<b= r> </span></font><br><div class=3D"gmail_quote">On Wed, Dec 15, 2010 at 3:14 P= M, Nick Sabalausky <span dir=3D"ltr">&lt;a a.a&gt;</span> wrote:<br><blockq= uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc = solid;padding-left:1ex;"> &quot;David Nadlinger&quot; &lt;<a href=3D"mailto:see klickverbot.at">see k= lickverbot.at</a>&gt; wrote in message<br> news:ieb3q0$1nc$1 digitalmars.com...<br> <div class=3D"im">&gt; On 12/15/10 8:04 PM, Nick Sabalausky wrote:<br> &gt;&gt; Are they in 99.9% of the browsers *actually being used now*?<br> &gt;<br> &gt; As it was already discussed, this is not as much of an argument as it<= br> </div>&gt; might seem - Windows x86 isn&#39;t used on 99.9% of all machines= either.<br> &gt;<br> <br> First of all, the percentage of user machines that are Windows is much much= <br> higher than the percentage of browsers being used that are bleeding-edge.<b= r> <br> Secondly, If someones going to make a non-cross-platform desktop app these<= br> days, I&#39;d consider that silly too. Maybe less silly, but only because i= t&#39;s<br> notably easier to test a page with JS on/off and in multiple browsers than<= br> to test an app on multiple OSes, and because there is Wine.<br> <br> Third, it&#39;s uncommon to need to use a *specific* non-cross-platform app= . The<br> vast majority of the time there are alternates available. But it&#39;s not<= br> uncommon at all for a website to not have an alternate equivalent. Trying t= o<br> make an online payment to Visa or check on one of Visa&#39;s policies? Are = you<br> gonna be able to do that at MasterCard&#39;s website? With desktop software= <br> stuff like that rarely happens. Basically, websites/webapps have a greater<= br> need for compatibility than desktop apps do.<br> <br> <br> <br> </blockquote></div><br></div> --000e0cd14b8adbb15a049778b935--
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

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 next sibling parent Michael Stover <michael.r.stover gmail.com> writes:
--000e0cd15826f8de19049778e954
Content-Type: text/plain; charset=ISO-8859-1

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.

--000e0cd15826f8de19049778e954 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Do you complain that Excel doesn&#39;t not &quot;degrade gracefully&quot;? = =A0Why would someone even think to load the app in lynx? =A0Do you load exc= el files in lynx?<br><br><div class=3D"gmail_quote">On Wed, Dec 15, 2010 at= 3:32 PM, Adam D. Ruppe <span dir=3D"ltr">&lt;<a href=3D"mailto:destruction= ator gmail.com">destructionator gmail.com</a>&gt;</span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;"><div class=3D"im">Michael Stover wrote:<br> &gt; If I provide a spreadsheet program via javascript,<br> &gt; why should it have to work in Lynx?<br> <br> </div>It doesn&#39;t necessarily have to work, but it should degrade gracef= ully. If it goes<br> all the way down the Lynx gracefully, that means it is most likely usable b= y everyone.<br> <br> For a spreadsheet, I&#39;d output the data in an html table. Now all users = can at<br> least view the saved document, with no extra effort from you.<br> </blockquote></div><br> --000e0cd15826f8de19049778e954--
Dec 15 2010
prev sibling next sibling parent reply Michael Stover <michael.r.stover gmail.com> writes:
--000e0cd14b8abf84770497791d1e
Content-Type: text/plain; charset=ISO-8859-1

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

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



 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.


 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

 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.

--000e0cd14b8abf84770497791d1e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable &gt;<meta charset=3D"utf-8"><span class=3D"Apple-style-span" style=3D"font-= family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">Wi= th my own computer, there are things I can do to prevent that. With<br>weba= pps I&#39;m 100% reliant on someone else: there isn&#39;t a damn thing I ca= n do.</span><div> <font class=3D"Apple-style-span" face=3D"arial, sans-serif"><span class=3D"= Apple-style-span" style=3D"border-collapse: collapse;"><br></span></font></= div><div><font class=3D"Apple-style-span" face=3D"arial, sans-serif"><span = class=3D"Apple-style-span" style=3D"border-collapse: collapse;">But what ab= out your group-think lemming mother?<br> </span></font><br><div class=3D"gmail_quote">On Wed, Dec 15, 2010 at 3:36 P= M, Nick Sabalausky <span dir=3D"ltr">&lt;a a.a&gt;</span> wrote:<br><blockq= uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc = solid;padding-left:1ex;"> &quot;Michael Stover&quot; &lt;<a href=3D"mailto:michael.r.stover gmail.com= ">michael.r.stover gmail.com</a>&gt; wrote in message<br> news:mailman.1037.1292442333.21107.digitalmars-d puremagic.com...<br> <div class=3D"im">&gt; On Wed, Dec 15, 2010 at 2:26 PM, retard &lt;re tard.= com.invalid&gt; wrote:<br> &gt;<br> </div><div class=3D"im">&gt;&gt; Wed, 15 Dec 2010 12:40:50 -0600, Andrew Wi= ley wrote:<br> &gt;&gt;<br> &gt;&gt; &gt; The point was that while Javascript is slow, it&#39;s getting= fast enough<br> &gt;&gt; &gt; to be useful. Yes, it&#39;s not C. It will never be. But the = fact that any<br> &gt;&gt; &gt; sort of realtime calculations are possible in it is a breakth= rough that<br> &gt;&gt; &gt; will be reflected in actual application code. Javascript was = not<br> &gt;&gt; &gt; designed to be fast, and honestly, it doesn&#39;t need to be = fast to fill<br> &gt;&gt; &gt; it&#39;s niche.<br> &gt;&gt;<br> &gt;&gt; I&#39;m not getting this. WHY we should use Javascript/HTML5 appli= cations<br> &gt;&gt; instead. I&#39;m perfectly happy with my existing tools. They work= nicely. It<br> &gt;&gt; takes years to develop these applications on top of HTML5. I simpl= y have<br> &gt;&gt; no motivation to use web applications. They have several downsides= :<br> &gt;&gt;<br> &gt;&gt; =A0- you &quot;rent&quot; the app, you don&#39;t &quot;own&quot; i= t anymore<br> &gt;&gt;<br> &gt;<br> </div><div class=3D"im">&gt; Many would find that a benefit, as updates are= automatic, never need to<br> &gt; install new versions.<br> &gt;<br> <br> </div>It&#39;s not uncommon for newer versions to be worse. Look at Acrobat= Reader,<br> iTunes, and Nero. A lot of people don&#39;t want to be forced into updates = that<br> make things worse. My Mom uses Hotmail and has a fit every time they decide= <br> to change everything around (which seems to be quite a lot). She&#39;d be f= ar<br> happier with something that didn&#39;t work that way, but she sticks with i= t<br> because she&#39;s every bit as much of a group-think lemming as everyone el= se.<br> <div class=3D"im"><br> <br> &gt;<br> &gt;&gt; =A0 =3D&gt; which leads to: advertisements, monthly fees<br> &gt;&gt;<br> &gt;<br> </div><div class=3D"im">&gt; Again, benefits galore for some folks. =A0Shou= ld I pay $80 to buy the<br> &gt; software<br> &gt; and find out if I like it, and another $40 two years later to upgrade,= or<br> &gt; pay $4/month and quit whenever I&#39;m done with it?<br> &gt;<br> <br> </div>Or get freeware/FLOSS and pay nothing and have no ads. And there&#39;= s<br> ad-supported desktop software too, so with desktop software you can go<br> either way. Web apps can&#39;t go either way, because there&#39;s always th= e<br> possibility the owner will pull the plug, and even if they don&#39;t, the o= wnser<br> will still have server expenses which will have to get paid somehow.<br> <div class=3D"im"><br> &gt;&gt;<br> &gt;&gt; =A0- worse privacy (do I want some Mark SuckerBerg to spy on my pe= rsonal<br> &gt;&gt; life for personal gain)<br> &gt;&gt;<br> &gt;<br> </div><div class=3D"im">&gt; Same issues with applications you install on y= our computer. =A0Perhaps they<br> &gt; are worse in that case, since so many people have so many problems wit= h<br> &gt; malware, spyware, worms and viruses.<br> &gt;<br> <br> </div>With my own computer, there are things I can do to prevent that. With= <br> webapps I&#39;m 100% reliant on someone else: there isn&#39;t a damn thing = I can do.<br> <div class=3D"im"><br> &gt;&gt;<br> &gt;&gt; =A0- worse security (a networkless local box IS quite safe, if CIA= is<br> &gt;&gt; raiding your house every week, you&#39;re probably doing something= wrong,<br> &gt;&gt; otherwise, buy better locks)<br> &gt;&gt;<br> &gt;<br> </div><div class=3D"im">&gt; Javascript+browser can be a purely client-mach= ine application too just<br> &gt; like<br> &gt; D or Java or C<br> &gt;<br> <br> </div>Yes, but what would be the point? It would be all downsides and no up= sides.<br> If you&#39;re going to have a local app it may as well be<br> D/Java/C/Python/whatever.<br> <div class=3D"im"><br> &gt;&gt;<br> &gt;&gt; =A0- worse performance (at least now and in the next few years)<br=

&gt;<br> </div><div class=3D"im">&gt; Yes. =A0But if you take frame rates in games, = which is a terrible example<br> &gt; for<br> &gt; javascript, the more general truth is that beyond a certain point,<br> &gt; performance differences are undetectable to the human eye.<br> <br> </div>Which the vast majority of JS web apps are nowhere remotely near.<br> <div class=3D"im"><br> &gt; At which point,<br> &gt; the only thing driving your technology choice is developer productivit= y.<br> <br> </div>Which once again is a big vote *against* web-browser-as-a-platform.<b= r> <div class=3D"im"><br> &gt;&gt;<br> &gt;&gt; =A0- worse usability<br> &gt;&gt;<br> &gt;<br> &gt; Completely disagree. =A0Desktop apps right now have an enormous advant= age in<br> &gt; how much development-hours have gone into them over web app counterpar= ts.<br> &gt; This will change, quickly.<br> &gt;<br> <br> </div>I&#39;ve been hearing that for a long time. Still waiting. In the mea= ntime, the<br> only changes I&#39;ve seen have been for the worse.<br> <div class=3D"im"><br> &gt;&gt;<br> &gt;&gt; I know the good sides. No need to mention them. In my opinion the<= br> &gt;&gt; downsides are still more important when making the decision.<br> &gt;&gt;<br> &gt;<br> </div><div class=3D"im">&gt; Honestly, where do think things will stand 5-1= 0 years from now?<br> &gt;<br> <br> </div>I shudder to even think...Nowhere good considering the directions thi= ngs are<br> moving.<br> <br> <br> <br> </blockquote></div><br></div> --000e0cd14b8abf84770497791d1e--
Dec 15 2010
parent "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

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
prev sibling next sibling parent 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

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

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


Oh really? Where are the sources?
   - this is especially bad ethically if you're writing free software


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)

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)

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

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)

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.


Thanks to advocates like you, we're totally fucked up.
Dec 15 2010
prev sibling next sibling parent reply Michael Stover <michael.r.stover gmail.com> writes:
--000e0cd14b8a4408590497794642
Content-Type: text/plain; charset=ISO-8859-1

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

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

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


Oh really? Where are the sources?
   - this is especially bad ethically if you're writing free software


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)

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)

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

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)

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.


Thanks to advocates like you, we're totally fucked up.

--000e0cd14b8a4408590497794642 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ugh, the reading comprehension here is abysmal. =A0Ciao, I&#39;m off to fuc= k up your future and enjoy every moment of it.<br><br><div class=3D"gmail_q= uote">On Wed, Dec 15, 2010 at 3:54 PM, retard <span dir=3D"ltr">&lt;re tard= .com.invalid&gt;</span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;">First, I have to ask, wtf are you using to = post these. I can&#39;t even reply<br> to you. The text area is empty, when I press &#39;reply&#39;. It breaks pan= , a<br> standards-compliant nntp client.<br> <div class=3D"im"><br> Wed, 15 Dec 2010 14:45:23 -0500, Michael Stover wrote:<br> <br> &gt; at 2:26 PM, retard &lt;re tard.com.invalid&gt; wrote:<br> &gt;<br> </div><div class=3D"im">&gt;&gt; Wed, 15 Dec 2010 12:40:50 -0600, Andrew Wi= ley wrote:<br> &gt;&gt;<br> &gt;&gt; &gt; The point was that while Javascript is slow, it&#39;s getting= fast enough<br> &gt;&gt; &gt; to be useful. Yes, it&#39;s not C. It will never be. But the = fact that<br> &gt;&gt; &gt; any sort of realtime calculations are possible in it is a<br> &gt;&gt; &gt; breakthrough that will be reflected in actual application cod= e.<br> &gt;&gt; &gt; Javascript was not designed to be fast, and honestly, it does= n&#39;t need<br> &gt;&gt; &gt; to be fast to fill it&#39;s niche.<br> &gt;&gt;<br> &gt;&gt; I&#39;m not getting this. WHY we should use Javascript/HTML5 appli= cations<br> &gt;&gt; instead. I&#39;m perfectly happy with my existing tools. They work= nicely.<br> &gt;&gt; It takes years to develop these applications on top of HTML5. I si= mply<br> &gt;&gt; have no motivation to use web applications. They have several<br> &gt;&gt; downsides:<br> &gt;&gt;<br> &gt;&gt; =A0- you &quot;rent&quot; the app, you don&#39;t &quot;own&quot; i= t anymore<br> &gt;&gt;<br> &gt;&gt;<br> </div><div class=3D"im">&gt; Many would find that a benefit, as updates are= automatic, never need to<br> &gt; install new versions.<br> <br> </div>I can assure you, the automatic updates work nicely in Linux land (us= e a<br> stable distro) and also many Windows programs now handle it nicely. And<br> often I don&#39;t even need them. As a sw developer I do want to hack with = my<br> programs. I want to own my software to avoid VLI. I want to own it to make<= br> sure it contains no backdoors or ad/spyware features.<br> <div class=3D"im"><br> &gt;&gt; =A0 =3D&gt; which leads to: advertisements, monthly fees<br> &gt;&gt;<br> &gt;&gt;<br> </div><div class=3D"im">&gt; Again, benefits galore for some folks. =A0Shou= ld I pay $80 to buy the<br> &gt; software and find out if I like it, and another $40 two years later to= <br> &gt; upgrade, or pay $4/month and quit whenever I&#39;m done with it?<br> <br> </div>I think at some point the software becomes good enough. There has to = be a<br> balance between the number of features and stability and all. Human mind<br=

t<br> should stop. At that point the price should approach zero. I don&#39;t want= <br> to pay just to get nothing in return. In become way too familiar with<br> this in the Windows Exchange/AD/Office/Windows leash land.<br> <br> For example email and instant messaging. I have probably 50..100<br> different email clients and IM clients in the distro&#39;s repositories. An= d<br> you&#39;re saying that I should suddenly start paying or watching ads to us= e<br> that functionality I&#39;ve taken for granted since I was born. Seriously<b= r> what the fuck.<br> <div class=3D"im"><br> &gt;<br> &gt; =A0 - this is especially bad if you&#39;re already using free as in be= er/<br> &gt;&gt; speech software<br> &gt;&gt;<br> &gt;&gt;<br> </div><div class=3D"im">&gt; gmail is free as in beer and nothing prevents = it being open source.<br> <br> </div>Oh really? Where are the sources?<br> <div class=3D"im"><br> &gt;&gt; =A0 - this is especially bad ethically if you&#39;re writing free = software<br> &gt;&gt;<br> &gt;&gt;<br> </div><div class=3D"im">&gt; There is no change here.<br> <br> </div>What? The time you spend on non-free software reduces the time you sp= ent<br> improving free software.<br> <div class=3D"im"><br> &gt;&gt; =A0- worse privacy (do I want some Mark SuckerBerg to spy on my pe= rsonal<br> &gt;&gt; life for personal gain)<br> &gt;&gt;<br> &gt;&gt;<br> </div><div class=3D"im">&gt; Same issues with applications you install on y= our computer. =A0Perhaps<br> &gt; they are worse in that case, since so many people have so many problem= s<br> &gt; with malware, spyware, worms and viruses.<br> <br> </div>They use the wrong operating system and in general are idiots. Ever h= eard<br> of Facebook privacy issues? <a href=3D"http://img220.imageshack.us/" target= =3D"_blank">http://img220.imageshack.us/</a><br> img220/4271/129228102781.jpg just to name one. They get fixed, but before<b= r> the fix is applied, some real world people get harmed.<br> <br> Another downside of web apps is that less developer time is spent on<br> local applications. This is bad news for us old skool folks.<br> <div class=3D"im"><br> <br> &gt;&gt; =A0- worse security (a networkless local box IS quite safe, if CIA= is<br> &gt;&gt; raiding your house every week, you&#39;re probably doing something= wrong,<br> &gt;&gt; otherwise, buy better locks)<br> &gt;&gt;<br> &gt;&gt;<br> </div><div class=3D"im">&gt; Javascript+browser can be a purely client-mach= ine application too just<br> &gt; like D or Java or C<br> <br> </div>Why the F would I want to use this inferior platform? Write me a Blen= der<br> in Javascript. The only reason I&#39;d choose it is when it&#39;s a better = tool<br> for the task.<br> <div class=3D"im"><br> &gt;&gt; =A0- worse usability<br> &gt;&gt;<br> &gt;&gt;<br> &gt; Completely disagree. =A0Desktop apps right now have an enormous advant= age<br> &gt; in how much development-hours have gone into them over web app<br> &gt; counterparts.<br> &gt; =A0This will change, quickly.<br> <br> </div>I meant now. Stop talking about the potential. It&#39;s not here yet.= <br> <div class=3D"im"><br> &gt;&gt; =A0- worse reliability (network problems, server problems)<br> &gt;&gt;<br> &gt;&gt;<br> </div><div class=3D"im">&gt; In theory, yes, and once in a while it is a pr= oblem, but I honestly<br> &gt; can&#39;t remember the last time I had any issues with connectivity.<b= r> <br> </div>If you travel a lot or don&#39;t live in an urban environment, you se= e that<br> connectivity sucks in many places. And on top of that the charges per<br> megabyte are enormous abroad. At home, at least my ISP fails to keep the<br=

web apps, I&#39;d be screwed. I would need to buy two independent network<b= r> connections, preferably both wireless and wired.<br> <div class=3D"im"><br> &gt;&gt; I know the good sides. No need to mention them. In my opinion the<= br> &gt;&gt; downsides are still more important when making the decision.<br> &gt;&gt;<br> &gt;&gt;<br> </div><div class=3D"im">&gt; Honestly, where do think things will stand 5-1= 0 years from now?<br> <br> </div>Thanks to advocates like you, we&#39;re totally fucked up.<br> </blockquote></div><br> --000e0cd14b8a4408590497794642--
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 "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
prev sibling next sibling parent "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
prev sibling next sibling parent Justin C Calvarese <technocrat7+d gmail.com> writes:
--001485eba1e864268004977a3862
Content-Type: text/plain; charset=ISO-8859-1

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 --001485eba1e864268004977a3862 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Dec 15, 2010 at 3:58 PM, Vladimir Panteleev <span dir=3D"ltr">&lt;<= a href=3D"mailto:vladimir thecybershadow.net">vladimir thecybershadow.net</= a>&gt;</span> wrote:<div class=3D"gmail_quote"><blockquote class=3D"gmail_q= uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e= x;"> <div class=3D"im"> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> I think I had some other problems as well though I<br> don&#39;t remember exactly what. I posted my impressions of it on this NG, = you<br> can probably just search the NG for posts from &quot;Sabalausky&quot; with = &quot;opera&quot; in<br> the text.<br> </blockquote> <br></div> Hmm, can&#39;t find anything (neither in my archives, nor on Google)... </b= lockquote><div><br></div><div><div>This looks like the relevant post by Nic= k:</div><div><a href=3D"http://www.digitalmars.com/webnews/newsgroups.php?a= rt_group=3Ddigitalmars.D.announce&amp;article_id=3D19476">http://www.digita= lmars.com/webnews/newsgroups.php?art_group=3Ddigitalmars.D.announce&amp;art= icle_id=3D19476</a></div> </div><div><br></div><div>jcc7</div></div> --001485eba1e864268004977a3862--
Dec 15 2010
prev sibling next sibling parent Michael Stover <michael.r.stover gmail.com> writes:
--001636e0b599cdec1104977d7ab2
Content-Type: text/plain; charset=ISO-8859-1

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.

--001636e0b599cdec1104977d7ab2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable So much hate because you can&#39;t middle-click paste. =A0Swearing and AAAr= rrrggghhing, &quot;loathing&quot;, etc. =A0It&#39;s childish and hard to ta= ke such attitudes seriously. =A0The world moves on and doesn&#39;t care tha= t you can&#39;t adapt to the simplest of things.<br> <br><div class=3D"gmail_quote">On Wed, Dec 15, 2010 at 5:20 PM, Adam D. Rup= pe <span dir=3D"ltr">&lt;<a href=3D"mailto:destructionator gmail.com">destr= uctionator gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_qu= ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex= ;"> Tangentially related to this thread. I just went back to my work to-do list= , which<br> the rest of the team puts up on a Google Doc.<br> <br> I *loathe* Google Docs, for a lot of reasons. But one more: my X11 selectio= n<br> doesn&#39;t work. This is with Firefox 3.6.<br> <br> In Linux, with most programs, you can select text, then middle click in a t= ext<br> input box to instantly paste it. This includes standard html text in the we= b browsers.<br> <br> ... but not Google Docs text. It highlights in a weird looking color, not m= atching<br> the rest of my system. It lags as I drag or scroll. And it doesn&#39;t upda= te the X<br> selection, so when I middle click out of habit... the wrong thing happens.<= br> AAAAarrrrrrggggghhhh!<br> <br> <br> Those javascript things never pay attention to details, and even those that= do<br> don&#39;t know the quirks of platforms or individual user setup, and even i= f they do<br> know, there&#39;s nothing they can do about it!<br> <br> <br> Now, if they just output a standard html document, these details would be h= andled<br> properly. Firefox itself knows it is a Linux program, has access to the Lin= ux<br> APIs, and manages them somewhat well.<br> <br> Or if it was a standard doc, I could open it in my other browser and maybe = it&#39;d do<br> a better job.<br> <br> But nope, open it in my no-script Konqueror 3.5, and it just says<br> <br> =3D=3D=3D<br> Google Docs is not supported in your browser. =A0 Learn more =A0 Dismiss<br=

<br> And a blank screen under it. I can&#39;t even view the text, despite it bei= ng just<br> text. Fucking garbage.<br> </blockquote></div><br> --001636e0b599cdec1104977d7ab2--
Dec 15 2010
prev sibling next sibling parent reply Michael Stover <michael.r.stover gmail.com> writes:
--001636e0b59983017204977e569e
Content-Type: text/plain; charset=ISO-8859-1

 there's no integration with the

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...

--001636e0b59983017204977e569e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable &gt;<meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf-8= "><span class=3D"Apple-style-span" style=3D"font-family: arial, sans-serif;= font-size: 13px; border-collapse: collapse; ">=A0there&#39;s no integratio= n with the<br> external environment</span><div><font class=3D"Apple-style-span" face=3D"ar= ial, sans-serif"><span class=3D"Apple-style-span" style=3D"border-collapse:= collapse;"><br></span></font></div><div><font class=3D"Apple-style-span" f= ace=3D"arial, sans-serif"><span class=3D"Apple-style-span" style=3D"border-= collapse: collapse;">But it is an advantage at the same time as it&#39;s a = weakness. =A0The advantage is, I can read and use gmail or google docs anyw= here, firewall or not.</span></font></div> <div><font class=3D"Apple-style-span" face=3D"arial, sans-serif"><span clas= s=3D"Apple-style-span" style=3D"border-collapse: collapse;"><br></span></fo= nt></div><div><font class=3D"Apple-style-span" face=3D"arial, sans-serif"><= span class=3D"Apple-style-span" style=3D"border-collapse: collapse;">I coul= d sit here at home, open an openoffice doc, write in it, save it. =A0Then t= omorrow go to work, open open office and bitch and scream about why the doc= I made last night at home isn&#39;t in my recent docs list!! ZOMG!!! I *LO= ATHE* Open Office! =A0I can&#39;t do the simplest thing! =A0But, no, I reco= gnize the limitations of the different mediums, and rather than look at wha= t is not exactly the same as what I&#39;m used to, I can see what it does t= hat I&#39;ve not been able to do before. =A0If you&#39;d asked me 1 year ag= o about javascript, I would have laughed and said no way I would want to us= e that crap. =A0I&#39;ve learned to think otherwise since.</span></font></d= iv> <div><font class=3D"Apple-style-span" face=3D"arial, sans-serif"><span clas= s=3D"Apple-style-span" style=3D"border-collapse: collapse;"><br></span></fo= nt></div><div><font class=3D"Apple-style-span" face=3D"arial, sans-serif"><= span class=3D"Apple-style-span" style=3D"border-collapse: collapse;">If you= go looking for problems, you&#39;re going to find them. =A0To me, it simpl= y indicates inflexibility on your part. =A0Which is fine, like I said, the = world doesn&#39;t care about your inability to adapt and see new possibilit= ies. =A0</span></font></div> <div><font class=3D"Apple-style-span" face=3D"arial, sans-serif"><span clas= s=3D"Apple-style-span" style=3D"border-collapse: collapse;"><br></span></fo= nt></div><div><font class=3D"Apple-style-span" face=3D"arial, sans-serif"><= span class=3D"Apple-style-span" style=3D"border-collapse: collapse;">It&#39= ;s just, the strength of the emotional response in this thread has been kin= d of revealing.</span></font></div> <div><font class=3D"Apple-style-span" face=3D"arial, sans-serif"><span clas= s=3D"Apple-style-span" style=3D"border-collapse: collapse;"><br></span></fo= nt></div><div><font class=3D"Apple-style-span" face=3D"arial, sans-serif"><= span class=3D"Apple-style-span" style=3D"border-collapse: collapse;">Mike<b= r> </span></font><br><div class=3D"gmail_quote">On Wed, Dec 15, 2010 at 9:20 P= M, Adam D. Ruppe <span dir=3D"ltr">&lt;<a href=3D"mailto:destructionator gm= ail.com">destructionator gmail.com</a>&gt;</span> wrote:<br><blockquote cla= ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa= dding-left:1ex;"> <div class=3D"im">&gt; So much hate because you can&#39;t middle-click past= e.<br> <br> </div>It&#39;s illustrative of a bigger overall problem: there&#39;s no int= egration with the<br> external environment; no use of native capabilities, ignoring user system s= etups,<br> and not even integration with other web apps. With a Windows program, you c= an set<br> up a user theme. Well behaved programs will honor your colors, layouts, etc= .<br> <br> One of the reasons I stick to my old Konqueror is it uses the website icon = and<br> title in my system taskbar and tries to honor my user settings. Most browse= rs<br> don&#39;t even try that, but even with konq, the integration is quite poor.= <br> <br> While web apps could, in theory, get some consistency with user defined<br> stylesheets, in practice, this would just break sites, since they are all s= o<br> accustomed to being independent.<br> <br> It&#39;s just like DOS. Except DOS apps could actually /use/ the hardware a= vailable to<br> them...<br> </blockquote></div><br></div> --001636e0b59983017204977e569e--
Dec 15 2010
next sibling parent reply Adam Chandler <adam paradise.com> writes:
Michael Stover Wrote:

 there's no integration with the

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

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

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
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

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 next sibling parent Andrew Wiley <debio264 gmail.com> writes:
--485b393aafa5d8c99f0497820940
Content-Type: text/plain; charset=ISO-8859-1

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

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.

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. --485b393aafa5d8c99f0497820940 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On Wed, Dec 15, 2010 at 3:16 PM, Nick Sabalausky= <span dir=3D"ltr">&lt;a a.a&gt;</span> wrote:<br><blockquote class=3D"gmai= l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left= :1ex;"> <div class=3D"im">&quot;Michael Stover&quot; &lt;<a href=3D"mailto:michael.= r.stover gmail.com">michael.r.stover gmail.com</a>&gt; wrote in message<br> </div>news:mailman.1041.1292446362.21107.digitalmars-d puremagic.com...<br> <div class=3D"im">&gt; &gt;With my own computer, there are things I can do = to prevent that. With<br> &gt; webapps I&#39;m 100% reliant on someone else: there isn&#39;t a damn t= hing I can<br> &gt; do.<br> &gt;<br> </div><div class=3D"im">&gt; But what about your group-think lemming mother= ?<br> &gt;<br> <br> </div>Unfortunately, she leaves the security and accessibility of her data = at the<br> mercy of MS&#39;s web monkeys. So tell me how exactly that&#39;s supposed t= o be an<br> improvement over just keeping it on her local system? Yes, either way there= <br> are possible security risks. But there isn&#39;t a chance in hell a webapp = can<br> actually be considered better in that regard.<br> <br><br></blockquote><div>=A0</div><div>This is what you&#39;re not seeing.= Web applications have zero-install, zero-configuration, and while you&#39;= ve pointed out that people whine when they change, those same people are al= ready using them and continue to use them anyway. Why? Ease of use.</div> <div>The sad truth is that most computer users know next to nothing about h= ow 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 comput= er, simply because Microsoft has experts working to maintain privacy and ba= ckup, while the user might not even understand how he/she would go about th= at sort of thing. Now, from the inside that we see as developers, the pictu= re isn&#39;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-eli= te 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 elit= e.</div> <div>For power users, this choice just isn&#39;t the same.</div></div> --485b393aafa5d8c99f0497820940--
Dec 15 2010
prev sibling next sibling parent "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

can do. But what about your group-think lemming mother?

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.

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
prev sibling next sibling parent reply Michael Stover <michael.r.stover gmail.com> writes:
--000e0cd15826bdc9ac04978729fb
Content-Type: text/plain; charset=ISO-8859-1

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.

--000e0cd15826bdc9ac04978729fb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable And CAPTCHAs prove that javascript and browsers are terrible???<div><br></d= iv><div>You must have failed logic class. =A0Probably you never took it, kn= owing how poorly you would do.</div><div><br></div><div>I should criticize = your precious local apps because some require dongles.<br> <br><div class=3D"gmail_quote">On Thu, Dec 16, 2010 at 8:28 AM, Adam Ruppe = <span dir=3D"ltr">&lt;<a href=3D"mailto:destructionator gmail.com">destruct= ionator gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote= " style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div class=3D"im">Andrew Wiley wrote:<br> &gt; Web applications have zero-install<br> <br> </div>But they trade it in for registration, with those awful, awful<br> CAPTCHAs.<br> <br> They don&#39;t just distinguish between humans and computers (sometimes).<b= r> They also distinguish between flawless humans with perfect vision<br> and expensive monitors and real life humans who can&#39;t see the<br> poorly contrasting colors or can&#39;t distinguish letters with a<br> font size of 8 pixels. Some have letters right on top of each<br> other.... what order do they want it? Gah.<br> <br> It invariably takes me two or three attempts to get those stupid<br> things. Thankfully, the popular Re-Captcha ones are among the<br> easiest to read, but that doesn&#39;t help when someone still uses<br> the green on red with purple stripes and tiny font variety. It&#39;s<br> been a while since I saw the Google captcha, but I remember it<br> as being nearly impossible.<br> <br> <br> The worst part is they come back post-registration too! Vile.<br> </blockquote></div><br></div> --000e0cd15826bdc9ac04978729fb--
Dec 16 2010
parent "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
prev sibling parent 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
prev sibling 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???

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 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? Oh my, you don't have a ### account? Dinosaur! -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Dec 18 2010