Your opinion about complex Javascript applications and performance

[Charles]

I tested Yahoo Mail (Ajax version), and Windows Live Mail (also Ajax
version). They are very sluggish, for instance I have a DSL connection
with a Pentium D 3.2Ghz computer and 2GBRAM, but when I open a few
"virtual" tabs of the Yahoo Mail application (Compose, Message,
Search), with only Yahoo Mail tab open, Internet Explorer uses 65MB of
RAM. When I resize the column of the left menu, it takes half a second
to follow the mouse, LOL. When I toggle from the Inbox to the Sent
items to the Draft folder, one after the other, my browser uses 100%
CPU, and then drops to 0. When I click "Compose", it takes 3 seconds
for the new "virtual" tab to show up...

This is just an example. This afternoon, I tried also Yahoo Mail in
Opera and Firefox, it's as slow. I also tried Windows Live Mail's Ajax
version, it's almost as slow, when you resize the separation between
the list of messages and the message itself, it uses 100% CPU and
there's a delay. Alright, I guess you know what I'm talking about,
many of you have tried these Javascript applications. I find the
concept very nice but it works well only for simple applications such
as Gmail (which is not as bloated as its competitors). But when you
add as many features as you want (all the bells and whistles as
desktop applications), it gets really slow.

What do you think about the current state of Javascript and the need
for performance and flexibility? I mean, shouldn't Javascript be
compiled at one point instead of interpreted at runtime? Personally I
would love to use these new generation applications such as the new
Yahoo Mail, but I would end up using the HTML-only GUI because of
speed. Flex applications are not better, they are slow too (ie: Yahoo
Webmessenger). One might complain about the Yahoo and Microsoft
developers writing bloated code, and this is for sure, but when you
need so much stuff in one GUI, there's no other way, even with
optimized code. This bloated code would be considered normal if it
were C++, after all, an application like Thunderbird or Opera M2
implements the same thing as Yahoo Mail's GUI but are not considered
"bloated" and they are very fast (because compiled). Don't you think
at this point, interpreted Javascript is problematic for development
of complex web applications? What do you suggest to solve this
problem?

 

[Darko]

I tested Yahoo Mail (Ajax version), and Windows Live Mail (also Ajax
version). They are very sluggish, for instance I have a DSL connection
with a Pentium D 3.2Ghz computer and 2GBRAM, but when I open a few
"virtual" tabs of the Yahoo Mail application (Compose, Message,
Search), with only Yahoo Mail tab open, Internet Explorer uses 65MB of
RAM. When I resize the column of the left menu, it takes half a second
to follow the mouse, LOL. When I toggle from the Inbox to the Sent
items to the Draft folder, one after the other, my browser uses 100%
CPU, and then drops to 0. When I click "Compose", it takes 3 seconds
for the new "virtual" tab to show up...

This is just an example. This afternoon, I tried also Yahoo Mail in
Opera and Firefox, it's as slow. I also tried Windows Live Mail's Ajax
version, it's almost as slow, when you resize the separation between
the list of messages and the message itself, it uses 100% CPU and
there's a delay. Alright, I guess you know what I'm talking about,
many of you have tried these Javascript applications. I find the
concept very nice but it works well only for simple applications such
as Gmail (which is not as bloated as its competitors). But when you
add as many features as you want (all the bells and whistles as
desktop applications), it gets really slow.

What do you think about the current state of Javascript and the need
for performance and flexibility? I mean, shouldn't Javascript be
compiled at one point instead of interpreted at runtime? Personally I
would love to use these new generation applications such as the new
Yahoo Mail, but I would end up using the HTML-only GUI because of
speed. Flex applications are not better, they are slow too (ie: Yahoo
Webmessenger). One might complain about the Yahoo and Microsoft
developers writing bloated code, and this is for sure, but when you
need so much stuff in one GUI, there's no other way, even with
optimized code. This bloated code would be considered normal if it
were C++, after all, an application like Thunderbird or Opera M2
implements the same thing as Yahoo Mail's GUI but are not considered
"bloated" and they are very fast (because compiled). Don't you think
at this point, interpreted Javascript is problematic for development
of complex web applications? What do you suggest to solve this
problem?

The figures you wrote about (speed results) I don't see so
catastrophic as
you're trying to display. Clicking on something and having to wait 3
seconds
I consider normal in a web page, cause your Internet connection speed
isn't the
only thing that matters - web server load is also very important, so
you can't
expect things to be instant.

Compilation could improve speed, but take some time to think about
portability -
compilation would require different versions of executable code for
different platforms,
which would greatly complicate things.

Byte code could be a solution, but would require a virtual machine
installed on the client
side, which some people maybe wouldn't like to do. Worth thinking
about, though.

Regards

 

[Richard Maher]

Hi Charles,

I tested Yahoo Mail (Ajax version), and Windows Live Mail (also Ajax
version). They are very sluggish, for instance I have a DSL connection
with a Pentium D 3.2Ghz computer and 2GBRAM, but when I open a few
"virtual" tabs of the Yahoo Mail application (Compose, Message,
Search), with only Yahoo Mail tab open, Internet Explorer uses 65MB of
RAM. When I resize the column of the left menu, it takes half a second
to follow the mouse, LOL. When I toggle from the Inbox to the Sent
items to the Draft folder, one after the other, my browser uses 100%
CPU, and then drops to 0. When I click "Compose", it takes 3 seconds
for the new "virtual" tab to show up...

This is just an example. This afternoon, I tried also Yahoo Mail in
Opera and Firefox, it's as slow. I also tried Windows Live Mail's Ajax
version, it's almost as slow, when you resize the separation between
the list of messages and the message itself, it uses 100% CPU and
there's a delay. Alright, I guess you know what I'm talking about,
many of you have tried these Javascript applications. I find the
concept very nice but it works well only for simple applications such
as Gmail (which is not as bloated as its competitors). But when you
add as many features as you want (all the bells and whistles as
desktop applications), it gets really slow.

What do you think about the current state of Javascript and the need
for performance and flexibility? I mean, shouldn't Javascript be
compiled at one point instead of interpreted at runtime? Personally I
would love to use these new generation applications such as the new
Yahoo Mail, but I would end up using the HTML-only GUI because of
speed. Flex applications are not better, they are slow too (ie: Yahoo
Webmessenger). One might complain about the Yahoo and Microsoft
developers writing bloated code, and this is for sure, but when you
need so much stuff in one GUI, there's no other way, even with
optimized code. This bloated code would be considered normal if it
were C++, after all, an application like Thunderbird or Opera M2
implements the same thing as Yahoo Mail's GUI but are not considered
"bloated" and they are very fast (because compiled). Don't you think
at this point, interpreted Javascript is problematic for development
of complex web applications? What do you suggest to solve this
problem?

Why do you lay all this performance blame at JavaScript's or the GUI's feet?
Is there no room in your condemnation for the poorly performing, insecure,
context-devoid, pile of crap that is HTTP and all who sail in her?
(Inclusing Ajax et al)

Cheers Richard Maher

 

[Charles]

Why do you lay all this performance blame at JavaScript's or the GUI's feet?
Is there no room in your condemnation for the poorly performing, insecure,
context-devoid, pile of crap that is HTTP and all who sail in her?
(Inclusing Ajax et al)

Hi Richard,

Because the "HTML-only" versions of these webmails are much faster.
Cheers,

Charles.

 

[The Natural Philosopher]

Hi Richard,

Because the "HTML-only" versions of these webmails are much faster.
Cheers,

Charles.

Absolutely. The whole active HTML arena is a bloody minefield.

Frankly we need a fresh start on it all.

 

[Erwin Moller]

I tested Yahoo Mail (Ajax version), and Windows Live Mail (also Ajax
version). They are very sluggish, for instance I have a DSL connection
with a Pentium D 3.2Ghz computer and 2GBRAM, but when I open a few
"virtual" tabs of the Yahoo Mail application (Compose, Message,
Search), with only Yahoo Mail tab open, Internet Explorer uses 65MB of
RAM. When I resize the column of the left menu, it takes half a second
to follow the mouse, LOL. When I toggle from the Inbox to the Sent
items to the Draft folder, one after the other, my browser uses 100%
CPU, and then drops to 0. When I click "Compose", it takes 3 seconds
for the new "virtual" tab to show up...

This is just an example. This afternoon, I tried also Yahoo Mail in
Opera and Firefox, it's as slow. I also tried Windows Live Mail's Ajax
version, it's almost as slow, when you resize the separation between
the list of messages and the message itself, it uses 100% CPU and
there's a delay. Alright, I guess you know what I'm talking about,
many of you have tried these Javascript applications. I find the
concept very nice but it works well only for simple applications such
as Gmail (which is not as bloated as its competitors). But when you
add as many features as you want (all the bells and whistles as
desktop applications), it gets really slow.

What do you think about the current state of Javascript and the need
for performance and flexibility? I mean, shouldn't Javascript be
compiled at one point instead of interpreted at runtime? Personally I
would love to use these new generation applications such as the new
Yahoo Mail, but I would end up using the HTML-only GUI because of
speed. Flex applications are not better, they are slow too (ie: Yahoo
Webmessenger). One might complain about the Yahoo and Microsoft
developers writing bloated code, and this is for sure, but when you
need so much stuff in one GUI, there's no other way, even with
optimized code. This bloated code would be considered normal if it
were C++, after all, an application like Thunderbird or Opera M2
implements the same thing as Yahoo Mail's GUI but are not considered
"bloated" and they are very fast (because compiled). Don't you think
at this point, interpreted Javascript is problematic for development
of complex web applications? What do you suggest to solve this
problem?

Hi Charles,

You just described why I avoid (bloated) JavaScript libs from anywhere
except my own homebrew.
I always roll my own mean-and-lean (AJAXoid) routines and never had any
performancetroubles.

But you'll find a lot of people claiming that mastering some external
libs is the way to go with JavaScript.

In my humble opinion AJAXoid solutions are simple, and easily
implemented by any programmer without the need of external packages/libs.

What is more, I hear a lot of complaints in here about the quality of
code in some of these libs. But I cannot judge if these complaints make
sense, because I never use them. ;-)

just my 2 cents...

Regards,
Erwin Moller

 

[Charles]

You just described why I avoid (bloated) JavaScript libs from anywhere
except my own homebrew.

Hi Erwin,

Yes, but even with your own homebrew JS libraries, and optimized code,
you hardly can develop a complex application such as Yahoo Mail
without it being slow. It has so much stuff. The same application in C+
+ would be very fast (ie: Thunderbird, Outlook Express, Opera M2). You
shouldn't have to limit yourself that much just because otherwise the
application would be slow. This is why there's something wrong.

 

[The Natural Philosopher]

Hi Erwin,

Yes, but even with your own homebrew JS libraries, and optimized code,
you hardly can develop a complex application such as Yahoo Mail
without it being slow. It has so much stuff. The same application in C+
+ would be very fast (ie: Thunderbird, Outlook Express, Opera M2). You
shouldn't have to limit yourself that much just because otherwise the
application would be slow. This is why there's something wrong.

There is. Javascript.

 

[Charles]

There is. Javascript.

Absolutely... The needs in 2007 are different from the needs in 1997
back when I was using Netscape and found it absolutely great to read
the news on the old Yahoo page

 

[John G Harris]

On Sun, 11 Nov 2007 at 23:58:09, in comp.lang.javascript, Charles wrote:

I mean, shouldn't Javascript be
compiled at one point instead of interpreted at runtime?

<snip>

Don't you remember why Java Applets failed ?

John

 

[Bart Van der Donck]

I tested Yahoo Mail (Ajax version), and Windows Live Mail (also Ajax
version). They are very sluggish, for instance I have a DSL connection
with a Pentium D 3.2Ghz computer and 2GBRAM, but when I open a few
"virtual" tabs of the Yahoo Mail application (Compose, Message,
Search), with only Yahoo Mail tab open, Internet Explorer uses 65MB of
RAM. When I resize the column of the left menu, it takes half a second
to follow the mouse, LOL. When I toggle from the Inbox to the Sent
items to the Draft folder, one after the other, my browser uses 100%
CPU, and then drops to 0. When I click "Compose", it takes 3 seconds
for the new "virtual" tab to show up...

This is just an example. This afternoon, I tried also Yahoo Mail in
Opera and Firefox, it's as slow. I also tried Windows Live Mail's Ajax
version, it's almost as slow, when you resize the separation between
the list of messages and the message itself, it uses 100% CPU and
there's a delay. Alright, I guess you know what I'm talking about,
many of you have tried these Javascript applications. I find the
concept very nice but it works well only for simple applications such
as Gmail (which is not as bloated as its competitors). But when you
add as many features as you want (all the bells and whistles as
desktop applications), it gets really slow.

What do you think about the current state of Javascript and the need
for performance and flexibility? I mean, shouldn't Javascript be
compiled at one point instead of interpreted at runtime? Personally I
would love to use these new generation applications such as the new
Yahoo Mail, but I would end up using the HTML-only GUI because of
speed. Flex applications are not better, they are slow too (ie: Yahoo
Webmessenger). One might complain about the Yahoo and Microsoft
developers writing bloated code, and this is for sure, but when you
need so much stuff in one GUI, there's no other way, even with
optimized code. This bloated code would be considered normal if it
were C++, after all, an application like Thunderbird or Opera M2
implements the same thing as Yahoo Mail's GUI but are not considered
"bloated" and they are very fast (because compiled). Don't you think
at this point, interpreted Javascript is problematic for development
of complex web applications? What do you suggest to solve this
problem?

I've read your article with much interest and I must say I have always
experienced a same feeling of suspicion towards client scripting in
general. The core reasons for this are IMHO as follows.

You can only 'hope' that the visiting client executes a script
correctly; of course you can try to maximize your 'chances', but at
the end you don't have any control about that computer, how crappy it
might be, which extensions are running on it, which spyware has
affected javascript behaviour, which frameset he's in, if he has
enabled javascript, if the web page and script were fully loaded,
which browser he is running, if its javascript engine isn't buggy,
browser extensions, popups, settings, etcetera. This creates a sort of
uncomfortable insolid mud under the feet of the programmer. It's a
fundamental weakness, but a necessary one for all client scripting -
the control factor in other languages is mostly much higher. I think
your experiences with Yahoo Mail and Windows Live Mail are a good
example of this. For me they work just fine, but that doesn't mean
that it works okay for everyone.

Javascript is a technically difficult language to master; perhaps one
of the most difficult I've ever dealt with. Not only can the the
syntax be overwhelming long (eg. who on earth invented stuff like
document . forms['myform'] . elements . ['myElement'] .
options[document . forms['myform'] . elements . ['myElement'] .
selectedIndex] . style . color to access the color of one select
option). Plus, there is often much code needed for stuff that can be
done much simpler and shorter in other languages. For instance, Ajax
is not a very easy technology to work with, it needs much code for a
relatively simple task. The "code overhead" is often too big.

Third, though the Object Orientedness of javascript is a good thing,
it has its problems too. The ancient top-down Credo has fewer
structural possibilities, but has the advantage that the logic and
programming flow are easier to follow, and can be picked up by others
with relatively little effort. This is not the case with complex
structures, a thick syntax encyclopedia and a spaghetti OO model
requiring more expertise and experience.

I don't advocate complex projects in general, and would certainly try
to avoid it at the client whenever possible. Javascript is (still!) at
its best for relatively simple tasks where not much can go wrong.
Limited and well-scoped modules to make life easier for the surfer, so
to say. Projects like Google Maps are IMHO a good example that it
*can* be done, of course, but it needs extreme care and much
expertise; not the lower level of expertise that is usually satisfying
for most other languages.

Further, I miss fundamental solid logic in javascript, such as UNIX or
SQL. Those technologies are so well designed that they will keep
existing for a very long time to come IMO. The strength of UNIX/SQL
lies in the fact that the basic elements are dead simple, but one can
build mega structures with it. Javascript doesn't have this strong
robustness. Under UNIX/SQL, every separate instruction is a very
simple thought, and every program or SQL-part is very good in its very
limited job. This creates a robust base for building further on rocks
that you can trust, because you quickly understand them, their
mechanisms are simple to grasp, and they limit their functionality
explicitely. Every big project must be divided into as many small
parts as needed, and there must be drawn clear lines between them, so
that it's possible to investigate and troubleshoot every (small)
element that contributes to it. It's like LEGO; those building blocks
are very simple and keep all options open towards the sky. In
Playmobil, you have pre-fabricated tools that do the job too, but in a
total different manner.

But probably the biggest problem of javascript is the way errors are
forgiven by the browser. There is no *need* to write good javascript
code; as bad code will not have immediate dramatic results. A
programmer might live under the impression that his program works
perfectly, without knowing that his neighbour is having problems with
it.

 

[stannyc]

I tested Yahoo Mail (Ajax version), and Windows Live Mail (also Ajax
version). They are very sluggish, for instance I have a DSL connection
with a Pentium D 3.2Ghz computer and 2GBRAM, but when I open a few
"virtual" tabs of the Yahoo Mail application (Compose, Message,
Search), with only Yahoo Mail tab open, Internet Explorer uses 65MB of
RAM. When I resize the column of the left menu, it takes half a second
to follow the mouse, LOL. When I toggle from the Inbox to the Sent
items to the Draft folder, one after the other, my browser uses 100%
CPU, and then drops to 0. When I click "Compose", it takes 3 seconds
for the new "virtual" tab to show up...

This is just an example. This afternoon, I tried also Yahoo Mail in
Opera and Firefox, it's as slow. I also tried Windows Live Mail's Ajax
version, it's almost as slow, when you resize the separation between
the list of messages and the message itself, it uses 100% CPU and
there's a delay. Alright, I guess you know what I'm talking about,
many of you have tried these Javascript applications. I find the
concept very nice but it works well only for simple applications such
as Gmail (which is not as bloated as its competitors). But when you
add as many features as you want (all the bells and whistles as
desktop applications), it gets really slow.

What do you think about the current state of Javascript and the need
for performance and flexibility? I mean, shouldn't Javascript be
compiled at one point instead of interpreted at runtime? Personally I
would love to use these new generation applications such as the new
Yahoo Mail, but I would end up using the HTML-only GUI because of
speed. Flex applications are not better, they are slow too (ie: Yahoo
Webmessenger). One might complain about the Yahoo and Microsoft
developers writing bloated code, and this is for sure, but when you
need so much stuff in one GUI, there's no other way, even with
optimized code. This bloated code would be considered normal if it
were C++, after all, an application like Thunderbird or Opera M2
implements the same thing as Yahoo Mail's GUI but are not considered
"bloated" and they are very fast (because compiled). Don't you think
at this point, interpreted Javascript is problematic for development
of complex web applications? What do you suggest to solve this
problem?

As others have said, the whole system needs improvement, but my
experience with Google Gmail is completely different. It's very fast
and a pleasure to use. This is a GOOD implementation, using the
current tools available. You should check it out.

Stan

 

[The Natural Philosopher]

I've read your article with much interest and I must say I have always
experienced a same feeling of suspicion towards client scripting in
general. The core reasons for this are IMHO as follows.

You can only 'hope' that the visiting client executes a script
correctly; of course you can try to maximize your 'chances', but at
the end you don't have any control about that computer, how crappy it
might be, which extensions are running on it, which spyware has
affected javascript behaviour, which frameset he's in, if he has
enabled javascript, if the web page and script were fully loaded,
which browser he is running, if its javascript engine isn't buggy,
browser extensions, popups, settings, etcetera. This creates a sort of
uncomfortable insolid mud under the feet of the programmer. It's a
fundamental weakness, but a necessary one for all client scripting -
the control factor in other languages is mostly much higher. I think
your experiences with Yahoo Mail and Windows Live Mail are a good
example of this. For me they work just fine, but that doesn't mean
that it works okay for everyone.

Javascript is a technically difficult language to master; perhaps one
of the most difficult I've ever dealt with. Not only can the the
syntax be overwhelming long (eg. who on earth invented stuff like
document . forms['myform'] . elements . ['myElement'] .
options[document . forms['myform'] . elements . ['myElement'] .
selectedIndex] . style . color to access the color of one select
option). Plus, there is often much code needed for stuff that can be
done much simpler and shorter in other languages. For instance, Ajax
is not a very easy technology to work with, it needs much code for a
relatively simple task. The "code overhead" is often too big.

Third, though the Object Orientedness of javascript is a good thing,
it has its problems too. The ancient top-down Credo has fewer
structural possibilities, but has the advantage that the logic and
programming flow are easier to follow, and can be picked up by others
with relatively little effort. This is not the case with complex
structures, a thick syntax encyclopedia and a spaghetti OO model
requiring more expertise and experience.

I don't advocate complex projects in general, and would certainly try
to avoid it at the client whenever possible. Javascript is (still!) at
its best for relatively simple tasks where not much can go wrong.
Limited and well-scoped modules to make life easier for the surfer, so
to say. Projects like Google Maps are IMHO a good example that it
*can* be done, of course, but it needs extreme care and much
expertise; not the lower level of expertise that is usually satisfying
for most other languages.

Further, I miss fundamental solid logic in javascript, such as UNIX or
SQL. Those technologies are so well designed that they will keep
existing for a very long time to come IMO. The strength of UNIX/SQL
lies in the fact that the basic elements are dead simple, but one can
build mega structures with it. Javascript doesn't have this strong
robustness. Under UNIX/SQL, every separate instruction is a very
simple thought, and every program or SQL-part is very good in its very
limited job. This creates a robust base for building further on rocks
that you can trust, because you quickly understand them, their
mechanisms are simple to grasp, and they limit their functionality
explicitely. Every big project must be divided into as many small
parts as needed, and there must be drawn clear lines between them, so
that it's possible to investigate and troubleshoot every (small)
element that contributes to it. It's like LEGO; those building blocks
are very simple and keep all options open towards the sky. In
Playmobil, you have pre-fabricated tools that do the job too, but in a
total different manner.

But probably the biggest problem of javascript is the way errors are
forgiven by the browser. There is no *need* to write good javascript
code; as bad code will not have immediate dramatic results. A
programmer might live under the impression that his program works
perfectly, without knowing that his neighbour is having problems with
it.

BEST post this month as far as I am concerned.

 

[Charles]

As others have said, the whole system needs improvement, but my
experience with Google Gmail is completely different. It's very fast
and a pleasure to use. This is a GOOD implementation, using the
current tools available. You should check it out.

Hi Stan,

This is what I said in my original message, Gmail is fast. I'm a Gmail
user myself BTW
Thanks to Bart for his feedback also.
Cheers,

 

[beegee]

Charles wrote:

Javascript is a technically difficult language to master; perhaps one
of the most difficult I've ever dealt with.

I thought so too until I found Ruby.

Third, though the Object Orientedness of javascript is a good thing,
it has its problems too. The ancient top-down Credo has fewer
structural possibilities, but has the advantage that the logic and
programming flow are easier to follow, and can be picked up by others
with relatively little effort. This is not the case with complex
structures, a thick syntax encyclopedia and a spaghetti OO model
requiring more expertise and experience.

This is an age-old argument that has many sides to it. The language is
only the lowest level of OO design. I can tell you personally that it
is much easier to write an MVC framework in javascript than in C++.
And it is much easier to have that framework understood by developers
than say .... MFC. Top-down is easily understood but for many
developers, it is a prison.

Projects like Google Maps are IMHO a good example that it
*can* be done, of course, but it needs extreme care and much
expertise; not the lower level of expertise that is usually satisfying
for most other languages.

I doubt that Google Maps could have been developed by a "lower level
of expertise" in any language.

Further, I miss fundamental solid logic in javascript, such as UNIX or
SQL. Those technologies are so well designed that they will keep
existing for a very long time to come IMO. The strength of UNIX/SQL
lies in the fact that the basic elements are dead simple, but one can
build mega structures with it. Javascript doesn't have this strong
robustness. Under UNIX/SQL, every separate instruction is a very
simple thought,

And that simple thought is set theory. Set theory is a concept that
is barely adequate for database development and not even relevant to
more abstract tasks. Sorry, I have to laugh. I know they give people
Phd's and pay them scads of money to become proficent in SQL but the
language seems archaic. Talk about a language where a lower level of
expertise is unsuitable for all but basic retrieval of table rows...

But probably the biggest problem of javascript is the way errors are
forgiven by the browser. There is no *need* to write good javascript
code; as bad code will not have immediate dramatic results. A
programmer might live under the impression that his program works
perfectly, without knowing that his neighbour is having problems with
it.

This is a problem but not for the reasons you state. It is extremely
obvious to the programmer that the code is not working, objects are
not displayed correctly, if at all. But it is much harder to fix than
in other languages, even with great tools like Firebug. Built-in
browser debugging would be incredibly helpful, something where you
could see not just the execution of javascript code but the step by
step rendering of html.


I disagree with the "it's not javascript that's slowing things down"
opinion. All you have to do is follow this link:

http://www.jamesward.org/census/

and you'll see that it is. Flex uses http just like javascript. I'm
not sure just compiling javascript would speed things up greatly and
you'd probably lose some of the reflection that makes javascript so
powerful but it might be worth the trade off.

Bob

 

[seani]

There is. Javascript.

The "thing" that's wrong is rarely one thing, it is usually a
combination of:

1) Poor architecture/design/seperation of concerns

2) Treating JS as if it's just a subset of, or "a bit like" other
languages, rather than understanding it's features. This leads to
developers incorrectly applying inappropriate idioms from other
langauges and making a right pigs ear of it.

3) Poorly optimised string building/handling. Some JS implementations
*do* have appalling performance when it comes to string concatenation,
which is a typical activity in DHTML/JS/Ajax apps. In these cases the
penalty for concatenation in these implementations is exponential
rather than linear, resulting in a severe drop-off in performance.

Fortunately there are several very lightweight and well documented
techniques for avoiding this, leading to order of magnitude increases
in performance in some cases.

4) Confusing JS performance with DHTML rendering speed when deciding
where to apportion "blame". There is a lot of JS generating a lot of
appalling DHTML. This is not a flaw in JS, this is POBCAK.

 

[Sean Inglis]

I've read your article with much interest and I must say I have always
experienced a same feeling of suspicion towards client scripting in
general. The core reasons for this are IMHO as follows.

You can only 'hope' that the visiting client executes a script
correctly; of course you can try to maximize your 'chances', but at
the end you don't have any control about that computer, how crappy it
might be, which extensions are running on it, which spyware has
affected javascript behaviour, which frameset he's in, if he has
enabled javascript, if the web page and script were fully loaded,
which browser he is running, if its javascript engine isn't buggy,
browser extensions, popups, settings, etcetera. This creates a sort of
uncomfortable insolid mud under the feet of the programmer. It's a
fundamental weakness, but a necessary one for all client scripting -
the control factor in other languages is mostly much higher. I think
your experiences with Yahoo Mail and Windows Live Mail are a good
example of this. For me they work just fine, but that doesn't mean
that it works okay for everyone.

Javascript is a technically difficult language to master; perhaps one
of the most difficult I've ever dealt with. Not only can the the
syntax be overwhelming long (eg. who on earth invented stuff like
document . forms['myform'] . elements . ['myElement'] .
options[document . forms['myform'] . elements . ['myElement'] .
selectedIndex] . style . color to access the color of one select
option). Plus, there is often much code needed for stuff that can be
done much simpler and shorter in other languages. For instance, Ajax
is not a very easy technology to work with, it needs much code for a
relatively simple task. The "code overhead" is often too big.

Third, though the Object Orientedness of javascript is a good thing,
it has its problems too. The ancient top-down Credo has fewer
structural possibilities, but has the advantage that the logic and
programming flow are easier to follow, and can be picked up by others
with relatively little effort. This is not the case with complex
structures, a thick syntax encyclopedia and a spaghetti OO model
requiring more expertise and experience.

I don't advocate complex projects in general, and would certainly try
to avoid it at the client whenever possible. Javascript is (still!) at
its best for relatively simple tasks where not much can go wrong.
Limited and well-scoped modules to make life easier for the surfer, so
to say. Projects like Google Maps are IMHO a good example that it
*can* be done, of course, but it needs extreme care and much
expertise; not the lower level of expertise that is usually satisfying
for most other languages.

Further, I miss fundamental solid logic in javascript, such as UNIX or
SQL. Those technologies are so well designed that they will keep
existing for a very long time to come IMO. The strength of UNIX/SQL
lies in the fact that the basic elements are dead simple, but one can
build mega structures with it. Javascript doesn't have this strong
robustness. Under UNIX/SQL, every separate instruction is a very
simple thought, and every program or SQL-part is very good in its very
limited job. This creates a robust base for building further on rocks
that you can trust, because you quickly understand them, their
mechanisms are simple to grasp, and they limit their functionality
explicitely. Every big project must be divided into as many small
parts as needed, and there must be drawn clear lines between them, so
that it's possible to investigate and troubleshoot every (small)
element that contributes to it. It's like LEGO; those building blocks
are very simple and keep all options open towards the sky. In
Playmobil, you have pre-fabricated tools that do the job too, but in a
total different manner.

But probably the biggest problem of javascript is the way errors are
forgiven by the browser. There is no *need* to write good javascript
code; as bad code will not have immediate dramatic results. A
programmer might live under the impression that his program works
perfectly, without knowing that his neighbour is having problems with
it.

BEST post this month as far as I am concerned.

Still having trouble adding numbers, then?

It certainly demands knowledge and a degree of discipline, and that takes
a bit of time. Daft to judge until you acquire a but more of both in this
area.

 

[Erwin Moller]

On Sun, 11 Nov 2007 at 23:58:09, in comp.lang.javascript, Charles wrote:


<snip>

Don't you remember why Java Applets failed ?

Yes, I do.
They didn't fail at all, only in the intentionally crippled Java
implementation brought to you by M$ corp in the form of IE.

Their unofficial, broken java implementation failed, was insecure,
unreliable, etc etc, effectively giving Java a bad name.
Of course, this made Sun angry, and so they asked M$ to replace that
peice of crab immediately with their official (working, secure) version
of the JVM.

Of course it took M$ many years to 'replace the implementation'.

That is why Java Applets failed.

Are you claiming they failed because of the compilation of the bytecode?

What do you mean?

Regards,
Erwin Moller

 

[Richard Maher]

Hi Erwin,

Yes, I do.
They didn't fail at all,

Hear! HEAR!

Cheers Richard Maher

PS. Like what Flash is starting to do (especially with Sockets) but Java
Applets are still there and still cookin'!

"Erwin Moller"

 

[John G Harris]

Yes, I do.
They didn't fail at all, only in the intentionally crippled Java
implementation brought to you by M$ corp in the form of IE.

Their unofficial, broken java implementation failed, was insecure,
unreliable, etc etc, effectively giving Java a bad name.
Of course, this made Sun angry, and so they asked M$ to replace that
peice of crab immediately with their official (working, secure) version
of the JVM.

Of course it took M$ many years to 'replace the implementation'.

That is why Java Applets failed.

Are you claiming they failed because of the compilation of the bytecode?

What do you mean?

You've said it : security worries and compatibility problems.

Do you really think that .NET on Linux won't suffer from both ? I'm not
saying it's certain, but history suggests it's unwise to be optimistic.

John