Re: emscripten
Adam Ruppe: Which brings me to emscripten... it most certainly does not work well! The Python example took a couple *minutes* to load for me, and actually running some python code took seconds each time. On a more modern browser it works well enough (Firefox 4). Do you realize that the source code of CPython is a LOT of code, we are talking about a JavaScript source file of 2.6 MB, after compression! So just seeing it compile and be able to run it and run some Python scripts is a marvel for me :-) So I think emscripten is a very nice toy. I have not yet tried to use LDC emscripten to convert some D1 code to JS. Regarding the JavaScript language, they are going to fix some of its biggest mistakes (but not semicolons yet, hopefully later), so JS is gaining speed, fixing its mistakes, and gaining power (canvas, WebGL, audio, video, other widgets, frameworks, etc): http://www.yuiblog.com/blog/2010/12/14/strict-mode-is-coming-to-town/ An interesting part from that blog post, that reminds us that D2 has sadly failed to fix this problem (and the octal!x syntax is not a significant improvement of the situation): In C, an extremely unfortunate representation of octalness was selected: Leading zero. So in C, 0100 means 64, not 100, and 08 is an error, not 8. Even more unfortunately, this anachronism has been copied into nearly all modern languages, including JavaScript, where it is only used to create errors. It has no other purpose. So in strict mode, octal forms are no longer allowed. Bye, bearophile
Re: emscripten
bearophile: On a more modern browser it works well enough (Firefox 4). This is a bit of a rant, but I hate how the web community always uses modern browser like this. I ran this site on Firefox 3.6.3. The most recent one it offers on getfirefox.com is 3.6.13 - I'm not very far behind! My about firefox box says Gecko from April 2010. That should be modern by any sane definition! (Now, my every day browser, Konqueror 3.5.7, is (c) 2005. So I can understand it not being a modern browser. But it works for me so I won't change it. Something I find hilarious though: it's CSS2 compliance was better than firefox up until about last year! I just wrote a site going wild with css for a web demo for the company, and it worked almost as well in my old Konq as it did in my newer Firefox. The kde folks did a really impressive job there.) Anyway, it just irks me that so many web evangelists say modern when they really mean bleeding edge. And in Google's case, it is even worse: when they say all modern browsers, they actually mean /our/ bleeding edge beta. It really annoys me. Back on topic: So I think emscripten is a very nice toy. I agree completely, it's a cool toy and pretty impressive that they got it to work as well as they did. I just don't think it is usable or really desirable for real work. Maybe it will improve, but it still has to compete with straight up javascript, which is already good enough for most places where you really need it. Regarding the JavaScript language, they are going to fix some of its biggest mistakes (but not semicolons yet, hopefully later), Interesting. Some comments from the article, then back to you to comment on octal! at the end: Strict mode requires that all variable binding be done statically. I wonder how that will change the javascript this keyword. I originally found it confusing, but now that I know its rules it isn't so bad and is sometimes extra useful. You should explicitly declare all of your variables. Should?? If this is actually a strict mode, shouldn't it be must? Maybe the author is just being sloppy, but this wording makes me think it moved from implicit global to implicit local. Definitely better, but still requiring var in all cases is better yet. Noisy Failure Something important about failure is it isn't just the language. The environment needs to tell you too. Browsers often either hide errors or annoy you so much about them you want them hidden. Some support an onerror event so you can hook it yourself, but not all browsers do. It would be nice if the browser behavior on error in strict mode was improved too. ...or better yet, give us a compiler ahead of time! JSLint is OK I guess though, but I rarely use it. There are still problems in JavaScript that strict mode does not address. Yes, and those things still suck. But if you use js sparingly, you don't have to deal with them too much. :) Back to bearophile: (and the octal!x syntax is not a significant improvement of the situation): Sure it is! The problem is that the old syntax is still accepted instead of either breaking C or giving a compiler error. This is one place where Walter and I disagree, but to move to a new way, we eventually need to remove the old way.
Re: emscripten
Adam D. Ruppe wrote: bearophile: On a more modern browser it works well enough (Firefox 4). This is a bit of a rant, but I hate how the web community always uses modern browser like this. I ran this site on Firefox 3.6.3. The most recent one it offers on getfirefox.com is 3.6.13 - I'm not very far behind! My about firefox box says Gecko from April 2010. That should be modern by any sane definition! (Now, my every day browser, Konqueror 3.5.7, is (c) 2005. So I can understand it not being a modern browser. But it works for me so I won't change it. Something I find hilarious though: it's CSS2 compliance was better than firefox up until about last year! I just wrote a site going wild with css for a web demo for the company, and it worked almost as well in my old Konq as it did in my newer Firefox. The kde folks did a really impressive job there.) Anyway, it just irks me that so many web evangelists say modern when they really mean bleeding edge. And in Google's case, it is even worse: when they say all modern browsers, they actually mean /our/ bleeding edge beta. It really annoys me. I'm more used to the term in every modern browser, except IE, in which case it is usually correct and modern means something from this or last year (except IE). Good old Konq from 2005 for example has better CSS2 support than IE8.
Re: emscripten
Adam D. Ruppe destructiona...@gmail.com wrote in message news:ieleht$1qc...@digitalmars.com... bearophile: On a more modern browser it works well enough (Firefox 4). This is a bit of a rant, but I hate how the web community always uses modern browser like this. I ran this site on Firefox 3.6.3. The most recent one it offers on getfirefox.com is 3.6.13 - I'm not very far behind! My about firefox box says Gecko from April 2010. That should be modern by any sane definition! (Now, my every day browser, Konqueror 3.5.7, is (c) 2005. So I can understand it not being a modern browser. But it works for me so I won't change it. Something I find hilarious though: it's CSS2 compliance was better than firefox up until about last year! I just wrote a site going wild with css for a web demo for the company, and it worked almost as well in my old Konq as it did in my newer Firefox. The kde folks did a really impressive job there.) Anyway, it just irks me that so many web evangelists say modern when they really mean bleeding edge. And in Google's case, it is even worse: when they say all modern browsers, they actually mean /our/ bleeding edge beta. It really annoys me. Hear, hear!
Re: emscripten
Adam D. Ruppe: Anyway, it just irks me that so many web evangelists say modern when they really mean bleeding edge. You are right, saying modern I have used the wrong words. If you use emscripten to compile large amounts of C or C++ code you probably need a very fast JavaScript engine. And we are still in the middle of the JS speed race, so it matters if you use FF 3.6 or FF4 or the latest canary build of Chrome that has Crankshaft. In few years this speed race will end and using the very latest JS engine will not matter. Bye, bearophile
Re: emscripten
Jeff Nowakowski j...@dilacero.org wrote in message news:ieh83c$26g...@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.
Re: emscripten
Nick Sabalausky a...@a.a wrote in message news:ieivqj$2s8...@digitalmars.com... Jeff Nowakowski j...@dilacero.org wrote in message news:ieh83c$26g...@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.
Re: emscripten
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.)
Re: emscripten
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.
Re: emscripten
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 lamers 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/
Re: emscripten
Jeff Nowakowski j...@dilacero.org wrote in message news:iejblg$jl...@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).
Re: emscripten
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.
Re: emscripten
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.
Re: emscripten
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.
Re: emscripten
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.
Re: emscripten
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.sto...@gmail.com wrote in message news:mailman.1041.1292446362.21107.digitalmar...@puremagic.com... With my own computer, there are things I can do to prevent that. With webapps I'm 100% reliant on someone else: there isn't a damn thing I can do. But what about your group-think lemming mother? Unfortunately, she leaves the security and accessibility of her data at the mercy of MS's web monkeys. So tell me how exactly that's supposed to be an improvement over just keeping it on her local system? Yes, either way there are possible security risks. But there isn't a chance in hell a webapp can actually be considered better in that regard. This is what you're not seeing. Web applications have zero-install, zero-configuration, and while you've pointed out that people whine when they change, those same people are already using them and continue to use them anyway. Why? Ease of use. The sad truth is that most computer users know next to nothing about how their computer works, and when given the choice between a fully featured email client they have to set up properly and a ready-to-go webmail system like Gmail/Hotmail, the choice seems fairly obvious. The same average user would probably say their data is safer with Microsoft than on their computer, simply because Microsoft has experts working to maintain privacy and backup, while the user might not even understand how he/she would go about that sort of thing. Now, from the inside that we see as developers, the picture isn't as pretty, but still. Computers and software are designed and created by the elite for both the elite and the non-elite. When the non-elite have a choice between doing it themselves and trusting it to the elite, the rise of web applications shows that they will generally choose the elite. For power users, this choice just isn't the same. This just means that the elite has failed in ensuring that the obvious choice is the right one. As you say, the average user will chose whatever looks simpler or more convenient, regardless of whether it actually *is* the best choice, performance- or security-wise. (Or even with regards to user- friendliness, once the seemingly insurmountable hurdles of installation and configuration have been passed.) But that doesn't mean that developers should take advantage of that to push crappy applications on people. Instead, developers should work to make local applications as easy to use as web applications, or to find a better way of serving applications over the internet than running them in a glorified document viewer. -Lars
Re: emscripten
Michael Stover Wrote: there's no integration with the external environment But it is an advantage at the same time as it's a weakness. The advantage is, I can read and use gmail or google docs anywhere, firewall or not. I could sit here at home, open an openoffice doc, write in it, save it. Then tomorrow go to work, open open office and bitch and scream about why the doc I made last night at home isn't in my recent docs list!! ZOMG!!! I *LOATHE* Open Office! I can't do the simplest thing! But, no, I recognize the limitations of the different mediums, and rather than look at what is not exactly the same as what I'm used to, I can see what it does that I've not been able to do before. If you'd asked me 1 year ago about javascript, I would have laughed and said no way I would want to use that crap. I've learned to think otherwise since. If you go looking for problems, you're going to find them. To me, it simply indicates inflexibility on your part. Which is fine, like I said, the world doesn't care about your inability to adapt and see new possibilities. It's just, the strength of the emotional response in this thread has been kind of revealing. Dear Mike, you're one of the most annoying wankers I've seen. Go f** yourself or even better, go kill yourself. TYVM let us have a nice day.
Re: emscripten
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.
Re: emscripten
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.
Re: emscripten
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 destructiona...@gmail.comwrote: 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.
Re: emscripten
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.
Re: emscripten
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.)
Re: emscripten
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).
Re: emscripten
On Thu, 16 Dec 2010 13:54:24 +, 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
Re: emscripten
Adam Ruppe destructiona...@gmail.com wrote in message news:ied469$2qg...@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 )
Re: emscripten
Michael Stover michael.r.sto...@gmail.com wrote in message news:mailman.1053.1292506694.21107.digitalmar...@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.
Re: emscripten
Thu, 16 Dec 2010 14:22:01 -0500, Nick Sabalausky wrote: Michael Stover michael.r.sto...@gmail.com wrote in message news:mailman.1053.1292506694.21107.digitalmar...@puremagic.com... And CAPTCHAs prove that javascript and browsers are terrible??? Where are you gettng that? That's not even remotely what he said. He was clearly saying that CAPTCHAs and registration are a counter-argument to the notion that most webapps are zero-config. Or at least that they're not really much better than having to do some basic config. This guy is trolling here. Any sane person would have already given up. This discussion is more or less useless.
Re: emscripten
Adam Chandler a...@paradise.com wrote in message news:iecv7f$1n1...@digitalmars.com... Michael Stover Wrote: there's no integration with the external environment But it is an advantage at the same time as it's a weakness. The advantage is, I can read and use gmail or google docs anywhere, firewall or not. I could sit here at home, open an openoffice doc, write in it, save it. Then tomorrow go to work, open open office and bitch and scream about why the doc I made last night at home isn't in my recent docs list!! ZOMG!!! I *LOATHE* Open Office! I can't do the simplest thing! But, no, I recognize the limitations of the different mediums, and rather than look at what is not exactly the same as what I'm used to, I can see what it does that I've not been able to do before. If you'd asked me 1 year ago about javascript, I would have laughed and said no way I would want to use that crap. I've learned to think otherwise since. If you go looking for problems, you're going to find them. To me, it simply indicates inflexibility on your part. Which is fine, like I said, the world doesn't care about your inability to adapt and see new possibilities. It's just, the strength of the emotional response in this thread has been kind of revealing. Dear Mike, you're one of the most annoying wankers I've seen. Go f** yourself or even better, go kill yourself. TYVM let us have a nice day. Dear Adam, even though your post is technically trolling and I'm normally a don't feed the trolls kinda guy, I gotta say: HAVE THIS FRESH-BAKED BATCH OF COOKIES! Chocolate-chip! Macaroons! Whatever you want! I'm amazed at how much Michael's been taking things the wrong way in this thread. Almost sounds like my mother: You say just about anything and they zero-in on one insignificant detail and blow it entirely out of proportion while completely misinterpreting it anyway.
Re: emscripten
Michael Stover michael.r.sto...@gmail.com wrote in message news:mailman.1046.1292468790.21107.digitalmar...@puremagic.com... there's no integration with the external environment But it is an advantage at the same time as it's a weakness. The advantage is, I can read and use gmail or google docs anywhere, firewall or not. That's entirely possible without cramming the whole thing through a webpage. I can thank of at least a couple ways just off the top of my head. The *only* reason you don't see outside of the web browser it is because everyone making use-anywhere apps is insisting doing it through the web browser. It's *not* a technical limitation of not using a web browser. If anything, it's just a widespread misconception amoung people who grew up writing web code and therefore don't know any better about what is and isn't possible.
Re: emscripten
Nick Sabalausky a...@a.a wrote in message news:iedqh5$6q...@digitalmars.com... Michael Stover michael.r.sto...@gmail.com wrote in message news:mailman.1046.1292468790.21107.digitalmar...@puremagic.com... there's no integration with the external environment But it is an advantage at the same time as it's a weakness. The advantage is, I can read and use gmail or google docs anywhere, firewall or not. Slight wording correction added in-line: That's entirely possible without cramming the whole thing through a webpage. I can thank of at least a couple ways just off the top of my head. The *only* reason you don't see [the access-your-data-from-anywhere ability] outside of the web browser it is because everyone making use-anywhere apps is insisting doing it through the web browser. It's *not* a technical limitation of not using a web browser. If anything, it's just a widespread misconception amoung people who grew up writing web code and therefore don't know any better about what is and isn't possible.
Re: emscripten
Jeff Nowakowski j...@dilacero.org wrote in message news:ied4mg$2u7...@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.
Re: emscripten
On Thu, Dec 16, 2010 at 2:22 PM, Nick Sabalausky a...@a.a wrote: Michael Stover michael.r.sto...@gmail.com wrote in message news:mailman.1053.1292506694.21107.digitalmar...@puremagic.com... And CAPTCHAs prove that javascript and browsers are terrible??? Where are you gettng that? That's not even remotely what he said. He was clearly saying that CAPTCHAs and registration are a counter-argument to the notion that most webapps are zero-config. Or at least that they're not really much better than having to do some basic config. The conversation was about technologies, not specific webapps. The emotional outburst that began this aspect of the discussion was that javascript sucks, period, end of story, without any possibility of ever being otherwise. CAPTCHAs are irrelevant.
Re: emscripten
On Thu, Dec 16, 2010 at 2:48 PM, Nick Sabalausky a...@a.a wrote: Michael Stover michael.r.sto...@gmail.com wrote in message news:mailman.1046.1292468790.21107.digitalmar...@puremagic.com... there's no integration with the external environment But it is an advantage at the same time as it's a weakness. The advantage is, I can read and use gmail or google docs anywhere, firewall or not. That's entirely possible without cramming the whole thing through a webpage. I can thank of at least a couple ways just off the top of my head. The *only* reason you don't see outside of the web browser it is because everyone making use-anywhere apps is insisting doing it through the web browser. It's *not* a technical limitation of not using a web browser. If anything, it's just a widespread misconception amoung people who grew up writing web code and therefore don't know any better about what is and isn't possible. What's possible and what's reasonable to two are different things. Clearly, implementors and users are converging on the idea that browsers are the easiest way to do this. You can do it other ways, go ahead. You think you'll get widespread adoption? You can argue against javascript and browsers, sure, but I'm not sure why you feel it's productive to be so insulting about it.
Re: emscripten
2010/12/15 Adam D. Ruppe destructiona...@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
Re: emscripten
Vladimir Panteleev Wrote:
On Tue, 14 Dec 2010 18:27:28 +0200, Alexander Pánek
a.pa...@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
Re: emscripten
On 12/14/10, Vladimir Panteleev vladi...@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.
Re: emscripten
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 destructiona...@gmail.com wrote in message news:ie9hjv$r1...@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.
Re: emscripten
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. Aargghh! 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.
Re: emscripten
All of your complaints are about specific choices of the developers, not the technology. Right now, javascript and web apps are being written (for the most part) by young, inexperienced, often graphically-oriented individuals. Soon, more experience developers will join the scene and start writing useful apps that aren't just eye-candy. Any my emails are *my* emails, stored on my local box. If I want to back it up, just copy the file. If I want a search that actually works, I can just grep the file, and so on. Just better in every way. The vast majority of people appreciate that they just get all that for free and without bother in gmail, hotmail, yahoo, etc. -Mike On Wed, Dec 15, 2010 at 9:47 AM, Adam D. Ruppe destructiona...@gmail.comwrote: 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. Aargghh! 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.
Re: emscripten
On Wed, Dec 15, 2010 at 9:37 AM, Adam D. Ruppe destructiona...@gmail.comwrote: 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).
Re: emscripten
On Wed, Dec 15, 2010 at 11:24 AM, Andrew Wiley debio...@gmail.com wrote: On Wed, Dec 15, 2010 at 9:37 AM, Adam D. Ruppe destructiona...@gmail.comwrote: 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)
Re: emscripten
On Wed, 15 Dec 2010 12:27:48 +0200, Andrej Mitrovic
andrej.mitrov...@gmail.com wrote:
On 12/14/10, Vladimir Panteleev vladi...@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,
Vladimirmailto:vladi...@thecybershadow.net
Re: emscripten
Andrew Wiley debio...@gmail.com wrote in message news:mailman.1026.1292433894.21107.digitalmar...@puremagic.com... On Wed, Dec 15, 2010 at 9:37 AM, Adam D. Ruppe destructiona...@gmail.comwrote: 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.
Re: emscripten
Michael Stover michael.r.sto...@gmail.com wrote in message news:mailman.1018.1292422650.21107.digitalmar...@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.
Re: emscripten
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*.
Re: emscripten
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.
Re: emscripten
Andrew Wiley debio...@gmail.com wrote in message news:mailman.1030.1292438460.21107.digitalmar...@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.)
Re: emscripten
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.
Re: emscripten
And no, I'm *not* playing semantics games here: Distributed via the web means exactly what it means Of course you're playing semantic games. Not being very helpful in the discussion. You seem to be arguing that if the content arrived via http it must work in lynx or else it sucks. Perhaps I will just rename it to ws and then you can have some new expectations that don't cloud your judgement so. On Wed, Dec 15, 2010 at 1:51 PM, Adam D. Ruppe destructiona...@gmail.comwrote: 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.
Re: emscripten
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
Re: emscripten
Wed, 15 Dec 2010 13:18:16 -0500, Nick Sabalausky wrote: Andrew Wiley debio...@gmail.com wrote in message news:mailman.1026.1292433894.21107.digitalmar...@puremagic.com... On Wed, Dec 15, 2010 at 9:37 AM, Adam D. Ruppe destructiona...@gmail.comwrote: And in those rare cases where you are doing a lot of client side work, it is so brutally slow that if you start piling other runtimes on top of it, you'll often be left with an unusable mess anyway! Unless you're using the beta of the next IE, the beta of the next Opera, or the current version of Chrome, in which case you'd find that client-side work is becoming more and more feasible. Now, it's not there yet, but when a C-ported-to-Java-compiled-to-Javascript version of Quake 2 can get 30FPS in Google Chrome, I start thinking that performance probably won't be nearly as bad as browsers move forward. A game that was designed to run on a 90-133MHz 16-24MB RAM machine (in *software* rendering mode), and was frequently able to get framerates in the hundreds on sub-500MHz machines (using hardware rendering - with the old, old, old 3dfx cards), manages to get *only* 30FPS in JS on a multi-GHz multi-core machine using what is clearly hardware rendering (on a modern graphics card), and I'm supposed to think that means JS is fast? If anything, that's *proof* of how horrid JS is - it turns a multi-GHz multi-core into a Pentium ~100MHz. What a joke! Some points: - IIRC the game was further optimized since the first release. The requirements went down a bit. Especially the SIMD optimizations allowed much lower MHz requirements with software rendering. Nowadays the SIMD instructions give even better throughput. - Compilers have improved a lot. E.g. auto-vectorization. Requirements went down a bit again. - the Jake2 version also runs faster because of faster JVMs and better OpenGL libraries - OTOH resolutions have gone up... but if the game uses hardware accelerated opengl canvas, using Javascript instead of C doesn't have much effect - overall I think the CPU requirements have gone down even though higher resolution and expensive graphical effects are more common these days. Indeed Quake II used to work very fast on Pentium II class hardware with Nvidia TNT cards. I think I got over 100 fps @ 1280x1024 over 10 years ago. Getting 30 FPS on average now IS a bad joke. The (graphics) hardware gets 100% faster every 12-18 months. Even if you make the game twice as fast as now, hardcore fps gamers wouldn't find the rate acceptable for modern network gaming. Hardcore fps gamers won't also play 13 yo games anymore. I admit that JavaScript is getting faster and faster. However, at some point the language will hit the performance wall. Luajit is one of the fastest dynamic languages out there. It's still drastically slower than statically typed languages. It probably shows has fast JavaScript can possibly get in raw computational tasks. This is all ok for casual gaming, but if you only get 30 FPS when running a 13 yo game, it means you're 15-16 years behind the state of the art. OTOH slow software rendered flash applets were already used as a platform for casual gaming, HTML5 doesn't change the situation that much. Maybe the greatest difference is that HTML5 also runs quite fast on Linux. This HTML5 hype also helps them in marketing. After all, it's the same old shit in new package. [HTML5, HTML5, HTML5, Chrome, HTML5, HTML5...] Yea, *eventually* HTML5 will *improve* a few things...That hardly counts as The web's not a shitty platform!. It's just 15-16 years behind the state of the art. Not much!
Re: emscripten
Adam D. Ruppe destructiona...@gmail.com wrote in message news:ieb2ng$2u3...@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.
Re: emscripten
On Wed, Dec 15, 2010 at 2:26 PM, retard r...@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?
Re: emscripten
Michael Stover michael.r.sto...@gmail.com wrote in message news:mailman.1034.1292441124.21107.digitalmar...@puremagic.com... And no, I'm *not* playing semantics games here: Distributed via the web means exactly what it means Of course you're playing semantic games. Not being very helpful in the discussion. You seem to be arguing that if the content arrived via http it must work in lynx or else it sucks. Not at all. In fact that blatantly contradicts what I just pointed out. Things like DMD, certain OSes, etc, all arrive via http (or ftp, whatever, like that matters) and yet, like I said, they're obviously not what we're talking about when we're talking about web apps. Secondly, I'm not the one that brought up Lynx. Although if there's something that clearly doesn't need graphics and such to be useful, then yes, it absolutely should work on Lynx. Apps obviously shouldn't require things they don't need: My DB shouldn't require I have a webcam installed. Grep shouldn't require an email client. Making a backup shouldn't require OpenGL or a printer. Submitting a form or downloading a PDF shouldn't require JS or HTML images. Viewing information on an official county probate court website shouldn't require Flash (I've actually seen that, and I'd be very surprised if it doesn't violate multiple government-mandated accessibility requirements). Etc.
Re: emscripten
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.sto...@gmail.com wrote in message news:mailman.1034.1292441124.21107.digitalmar...@puremagic.com... And no, I'm *not* playing semantics games here: Distributed via the web means exactly what it means Of course you're playing semantic games. Not being very helpful in the discussion. You seem to be arguing that if the content arrived via http it must work in lynx or else it sucks. Not at all. In fact that blatantly contradicts what I just pointed out. Things like DMD, certain OSes, etc, all arrive via http (or ftp, whatever, like that matters) and yet, like I said, they're obviously not what we're talking about when we're talking about web apps. Secondly, I'm not the one that brought up Lynx. Although if there's something that clearly doesn't need graphics and such to be useful, then yes, it absolutely should work on Lynx. Apps obviously shouldn't require things they don't need: My DB shouldn't require I have a webcam installed. Grep shouldn't require an email client. Making a backup shouldn't require OpenGL or a printer. Submitting a form or downloading a PDF shouldn't require JS or HTML images. Viewing information on an official county probate court website shouldn't require Flash (I've actually seen that, and I'd be very surprised if it doesn't violate multiple government-mandated accessibility requirements). Etc.
Re: emscripten
David Nadlinger s...@klickverbot.at wrote in message news:ieb3q0$1n...@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.
Re: emscripten
Trying to make an online payment to Visa or check on one of Visa's policies? Are you gonna be able to do that at MasterCard's website? With desktop software stuff like that rarely happens. Basically, websites/webapps have a greater need for compatibility than desktop apps do. Again, we're not talking about *websites*. We're talking about web *apps*. Of course your bank site ought to provide you your account info whether you are on a Mac or Windows and even if you use IE 5.5. But that's not what we're talking about. We're talking about someone making an application that, today or in the past you would have downloaded and installed, and instead making it runnable in a browser. It's not content, it's *behavior*you're there for, and therefore, if they require Chrome and you are a devoted Firefox user, then you can find someone else who provides that behavior in Firefox and use them instead. There's no tie to some particular content provided (like Visa), just like there isn't with desktop apps. Mike On Wed, Dec 15, 2010 at 3:14 PM, Nick Sabalausky a...@a.a wrote: David Nadlinger s...@klickverbot.at wrote in message news:ieb3q0$1n...@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.
Re: emscripten
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.
Re: emscripten
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 destructiona...@gmail.comwrote: 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.
Re: emscripten
Michael Stover michael.r.sto...@gmail.com wrote in message news:mailman.1037.1292442333.21107.digitalmar...@puremagic.com... On Wed, Dec 15, 2010 at 2:26 PM, retard r...@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.
Re: emscripten
With my own computer, there are things I can do to prevent that. With webapps I'm 100% reliant on someone else: there isn't a damn thing I can do. But what about your group-think lemming mother? On Wed, Dec 15, 2010 at 3:36 PM, Nick Sabalausky a...@a.a wrote: Michael Stover michael.r.sto...@gmail.com wrote in message news:mailman.1037.1292442333.21107.digitalmar...@puremagic.com... On Wed, Dec 15, 2010 at 2:26 PM, retard r...@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.
Re: emscripten
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.
Re: emscripten
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
Re: emscripten
Michael Stover michael.r.sto...@gmail.com wrote in message news:mailman.1041.1292446362.21107.digitalmar...@puremagic.com... With my own computer, there are things I can do to prevent that. With webapps I'm 100% reliant on someone else: there isn't a damn thing I can do. But what about your group-think lemming mother? Unfortunately, she leaves the security and accessibility of her data at the mercy of MS's web monkeys. So tell me how exactly that's supposed to be an improvement over just keeping it on her local system? Yes, either way there are possible security risks. But there isn't a chance in hell a webapp can actually be considered better in that regard.
Re: emscripten
Michael Stover michael.r.sto...@gmail.com wrote in message news:mailman.1038.1292443910.21107.digitalmar...@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.
Re: emscripten
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
captionThread Participants/caption
tr
tdAdam/tdtdRuppe/td
/tr
tr
tdDavid/tdtdNadlinger/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.
Re: [OT] Browsers (was: Re: emscripten)
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, Vladimirmailto:vladi...@thecybershadow.net
Re: [OT] Browsers (was: Re: emscripten)
On Wed, Dec 15, 2010 at 3:58 PM, Vladimir Panteleev vladi...@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.announcearticle_id=19476 jcc7
Re: emscripten
So much hate because you can't middle-click paste. Swearing and AAAggghhing, 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 destructiona...@gmail.comwrote: 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. arrg! 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.
Re: emscripten
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...
Re: emscripten
there's no integration with the external environment But it is an advantage at the same time as it's a weakness. The advantage is, I can read and use gmail or google docs anywhere, firewall or not. I could sit here at home, open an openoffice doc, write in it, save it. Then tomorrow go to work, open open office and bitch and scream about why the doc I made last night at home isn't in my recent docs list!! ZOMG!!! I *LOATHE* Open Office! I can't do the simplest thing! But, no, I recognize the limitations of the different mediums, and rather than look at what is not exactly the same as what I'm used to, I can see what it does that I've not been able to do before. If you'd asked me 1 year ago about javascript, I would have laughed and said no way I would want to use that crap. I've learned to think otherwise since. If you go looking for problems, you're going to find them. To me, it simply indicates inflexibility on your part. Which is fine, like I said, the world doesn't care about your inability to adapt and see new possibilities. It's just, the strength of the emotional response in this thread has been kind of revealing. Mike On Wed, Dec 15, 2010 at 9:20 PM, Adam D. Ruppe destructiona...@gmail.comwrote: 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...
Re: emscripten
On Wed, Dec 15, 2010 at 3:16 PM, Nick Sabalausky a...@a.a wrote: Michael Stover michael.r.sto...@gmail.com wrote in message news:mailman.1041.1292446362.21107.digitalmar...@puremagic.com... With my own computer, there are things I can do to prevent that. With webapps I'm 100% reliant on someone else: there isn't a damn thing I can do. But what about your group-think lemming mother? Unfortunately, she leaves the security and accessibility of her data at the mercy of MS's web monkeys. So tell me how exactly that's supposed to be an improvement over just keeping it on her local system? Yes, either way there are possible security risks. But there isn't a chance in hell a webapp can actually be considered better in that regard. This is what you're not seeing. Web applications have zero-install, zero-configuration, and while you've pointed out that people whine when they change, those same people are already using them and continue to use them anyway. Why? Ease of use. The sad truth is that most computer users know next to nothing about how their computer works, and when given the choice between a fully featured email client they have to set up properly and a ready-to-go webmail system like Gmail/Hotmail, the choice seems fairly obvious. The same average user would probably say their data is safer with Microsoft than on their computer, simply because Microsoft has experts working to maintain privacy and backup, while the user might not even understand how he/she would go about that sort of thing. Now, from the inside that we see as developers, the picture isn't as pretty, but still. Computers and software are designed and created by the elite for both the elite and the non-elite. When the non-elite have a choice between doing it themselves and trusting it to the elite, the rise of web applications shows that they will generally choose the elite. For power users, this choice just isn't the same.
Re: emscripten
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.
Re: emscripten
Adam Ruppe: Client side scripting sucks. JavaScript is the Next Big Language :-) Better to lean it. Bye, bearophile
Re: emscripten
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.
Re: emscripten
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
Re: emscripten
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 seewebsiteforem...@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
Re: emscripten
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!
Re: emscripten
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
Re: emscripten
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
Re: emscripten
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.
Re: emscripten
On Tue, 14 Dec 2010 18:27:28 +0200, Alexander Pánek
a.pa...@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,
Vladimirmailto:vladi...@thecybershadow.net
Re: emscripten
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.
Re: emscripten
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
Re: emscripten
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.
Re: emscripten
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
Re: emscripten
On Tue, Dec 14, 2010 at 2:03 PM, Adam Ruppe destructiona...@gmail.comwrote: 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 destructiona...@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.
Re: emscripten
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!
Re: emscripten
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 destructiona...@gmail.comwrote: 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!
Re: emscripten
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.
Re: emscripten
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 destructiona...@gmail.comwrote: 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.
Re: emscripten
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.
Re: emscripten
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.
Re: emscripten
Michael Stover michael.r.sto...@gmail.com wrote in message news:mailman.1004.1292372981.21107.digitalmar...@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.
Re: emscripten
Adam D. Ruppe destructiona...@gmail.com wrote in message news:ie9hjv$r1...@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.
