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
"Adam D. Ruppe" 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 mo
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
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 ab
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
"Jeff Nowakowski" 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
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
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. T
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 both
"Nick Sabalausky" wrote in message
news:ieivqj$2s8...@digitalmars.com...
> "Jeff Nowakowski" 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 thin
"Jeff Nowakowski" 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 iss
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 JavaScrip
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
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 si
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, yo
On Thu, Dec 16, 2010 at 2:48 PM, Nick Sabalausky wrote:
> "Michael Stover" 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
>
On Thu, Dec 16, 2010 at 2:22 PM, Nick Sabalausky wrote:
> "Michael Stover" 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
"Jeff Nowakowski" 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
"Nick Sabalausky" wrote in message
news:iedqh5$6q...@digitalmars.com...
> "Michael Stover" 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 wea
"Michael Stover" 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, fire
"Adam Chandler" 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 anywher
Thu, 16 Dec 2010 14:22:01 -0500, Nick Sabalausky wrote:
> "Michael Stover" 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
"Michael Stover" 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
"Adam Ruppe" 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 of
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
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
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 pu
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 bec
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 wrote:
> Andrew W
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
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 s
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
On Thu, 16 Dec 2010 01:31:13 -0600, Andrew Wiley wrote:
> On Wed, Dec 15, 2010 at 3:16 PM, Nick Sabalausky wrote:
>
>> "Michael Stover" wrote in message
>> news:mailman.1041.1292446362.21107.digitalmar...@puremagic.com...
>> > >With my own computer, there are things I can do to prevent that.
>>
On Wed, Dec 15, 2010 at 3:16 PM, Nick Sabalausky wrote:
> "Michael Stover" 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 d
> 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 wor
> 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
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 wrote:
>
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"
On Wed, 15 Dec 2010 23:45:49 +0200, Nick Sabalausky 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
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
"Michael Stover" 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 onl
"Michael Stover" 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 lemmin
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 sh
> 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
>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 wrote:
> "Michael Stover" wrote in message
> news
"Michael Stover" wrote in message
news:mailman.1037.1292442333.21107.digitalmar...@puremagic.com...
> On Wed, Dec 15, 2010 at 2:26 PM, retard 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
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 wrote:
> Michael Stover wrote:
> > If I provide a spreadsheet program via javascript,
> > why should
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 spreads
>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 tal
"David Nadlinger" 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
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
hor
"Michael Stover" 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.
On Wed, Dec 15, 2010 at 2:26 PM, retard 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 possib
"Adam D. Ruppe" 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 li
Wed, 15 Dec 2010 13:18:16 -0500, Nick Sabalausky wrote:
> "Andrew Wiley" wrote in message
> news:mailman.1026.1292433894.21107.digitalmar...@puremagic.com...
>> On Wed, Dec 15, 2010 at 9:37 AM, Adam D. Ruppe
>> wrote:
>>>
>>> And in those rare cases where you are doing a lot of client side work,
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
>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". Perhap
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 act
"Andrew Wiley" wrote in message
news:mailman.1030.1292438460.21107.digitalmar...@puremagic.com...
> On Wed, Dec 15, 2010 at 12:18 PM, Nick Sabalausky 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
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 dire
On Wed, Dec 15, 2010 at 12:18 PM, Nick Sabalausky 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, ol
"Michael Stover" 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
appl
"Andrew Wiley" wrote in message
news:mailman.1026.1292433894.21107.digitalmar...@puremagic.com...
> On Wed, Dec 15, 2010 at 9:37 AM, Adam D. Ruppe
> wrote:
>>
>> And in those rare cases where you are doing a lot of client side work, it
>> is so
>> brutally slow that if you start piling other run
On Wed, 15 Dec 2010 12:27:48 +0200, Andrej Mitrovic
wrote:
On 12/14/10, Vladimir Panteleev 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'v
On Wed, Dec 15, 2010 at 11:24 AM, Andrew Wiley wrote:
> On Wed, Dec 15, 2010 at 9:37 AM, Adam D. Ruppe
> wrote:
>>
>> And in those rare cases where you are doing a lot of client side work, it
>> is so
>> brutally slow that if you start piling other runtimes on top of it, you'll
>> often
>> be le
On Wed, Dec 15, 2010 at 9:37 AM, Adam D. Ruppe wrote:
>
> And in those rare cases where you are doing a lot of client side work, it
> is so
> brutally slow that if you start piling other runtimes on top of it, you'll
> often
> be left with an unusable mess anyway!
Unless you're using the beta of
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
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 tag too, and wow it blows.
Wait for its animation to start up. Wait for its animation to finish. Click an
option it
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
On 12/14/10, Vladimir Panteleev 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:
Vladimir Panteleev Wrote:
> On Tue, 14 Dec 2010 18:27:28 +0200, Alexander Pánek
> 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 dat
2010/12/15 Adam D. Ruppe :
> 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 t
"Adam D. Ruppe" 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
"Michael Stover" 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.
>
> 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
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 e
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
easi
> 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 wor
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 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
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 i
On Tue, Dec 14, 2010 at 2:03 PM, 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 usele
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 goo
> 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
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
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
> > >>
On Tue, 14 Dec 2010 18:27:28 +0200, Alexander Pánek
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'
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 get
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%
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 gett
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!
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 wel
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 doe
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
Adam Ruppe:
> Client side scripting sucks.
JavaScript is the Next Big Language :-) Better to lean it.
Bye,
bearophile
> 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
95 matches
Mail list logo
