Extremely slow website?

[keriflur]

IMO something weird is afoot, as I have no trouble with the site, even on my crappy work computers and my low-memory netbook.  I don't even have trouble using the full site on my phone (I have the rezound).  Any ideas why I'm not having issues but others with likely more powerful computers are seeing problems?

[Sun_Cat]

---

keriflur wrote:

IMO something weird is afoot, as I have no trouble with the site, even on my crappy work computers and my low-memory netbook.  I don't even have trouble using the full site on my phone (I have the rezound).  Any ideas why I'm not having issues but others with likely more powerful computers are seeing problems?

---

My guess (and it's just an educated guess) is that it's something specific about the JavaScript implementation in a particular browser or browsers. The only way to pinpoint the problem area(s) would be to use developer tools to trace and time program execution on computers where the slowdown is obvious.

[frantastk]

---

keriflur wrote:

IMO something weird is afoot, as I have no trouble with the site, even on my crappy work computers and my low-memory netbook.  I don't even have trouble using the full site on my phone (I have the rezound).  Any ideas why I'm not having issues but others with likely more powerful computers are seeing problems?

---

I don't have any trouble with the B&N website. either. I don't find it particularly slow, no slower than any other site I visit. There are other aspects of the site I wish were fixed but page loading speed has never been one of my issues. I'm using a bare bones Acer netbook. I usually run Chrome, and occasionally Firefox. I have IE but don't tend to use it. The only reason I still have it is because there are some educationaly sites my son's school uses that only work properly on IE. I also don't have super fast internet. I have more trouble with Gmail loading quickly than this site.

[MacMcK1957]

---

frantastk wrote:

I don't have any trouble with the B&N website. either. I don't find it particularly slow, no slower than any other site I visit. There are other aspects of the site I wish were fixed but page loading speed has never been one of my issues. I'm using a bare bones Acer netbook. I usually run Chrome, and occasionally Firefox. I have IE but don't tend to use it. The only reason I still have it is because there are some educationaly sites my son's school uses that only work properly on IE. I also don't have super fast internet. I have more trouble with Gmail loading quickly than this site.

---

I've been wondering about this thread, too.  I use different machines at work and at home, sometimes IE and sometimes Firefox, also an iPad running Safari, and I've never had any issues with the website.  I can think of a lot of sites which load far more slowly.

[flyingtoastr Scribe]

The computers at work running really really outdated versions of IE and Firefox have a lot of trouble with the BN website, but using Chrome 18 and Firefox 12 at my home works just peachy.

[akaCat]

---

keriflur wrote:

IMO something weird is afoot, as I have no trouble with the site, even on my crappy work computers and my low-memory netbook.  I don't even have trouble using the full site on my phone (I have the rezound).  Any ideas why I'm not having issues but others with likely more powerful computers are seeing problems?

---

The basic problem is, either whoever is developing this forum software is incompetent, or the developers intend it to be used only in a closed corporate environment where every PC is set up the same -- and B&N idiotically chose to use it in a public forum.

No two browsers, and often even different versions of the same browser, are going to "read" javascript exactly the same way. The more complicated the javascript is, the more difficult it is to make sure that every browser in the wild is going to read it well. Eventually you reach a point where the only way it will run reasonably well on every browser, is to have a seperate copy of the code for each browser.... and Lithium isn't doing that.

(And unfortunately, the preceding paragraph is a little over-simplified. Two of the exact same version of the exact same browser may read javascript differently depending on what the browser options are set to, if there are any addons, and very likely a few dozen even more obscure reasons.)

Keriflur, your crappy work computers just happen to be using a browser that's the same or similar to the one Lithium developed this forum on. It's reading the javascript the way the developer intended, so you could say that it's taking the direct path from point A to point B and not getting overwhelmed.

The browser on my gaming computer at home was reading the javascript very differently; instead of going straight from point A to point B it was taking every possible detour, throwing in a few curly-cues, and randomly etch-a-sketching a few presidential portraits before getting to point B. Fast as it is, it got overwhelmed with all that nonsense going on in the background and could barely function.

[DeanGibson Distinguished Bibliophile]

---

akaCat wrote:
...

No two browsers, and often even different versions of the same browser, are going to "read" javascript exactly the same way. The more complicated the javascript is, the more difficult it is to make sure that every browser in the wild is going to read it well. Eventually you reach a point where the only way it will run reasonably well on every browser, is to have a seperate copy of the code for each browser.... and Lithium isn't doing that.

(And unfortunately, the preceding paragraph is a little over-simplified. Two of the exact same version of the exact same browser may read javascript differently depending on what the browser options are set to, if there are any addons, and very likely a few dozen even more obscure reasons.)

---

I couldn't agree more.  In the industry, it's called "Dynamic HTML", and a more bastardized language combination would be hard to find.  Regular HTML has its incompatibilities, but if the developer exercises certain cautions, it's pretty compatible across most browsers.  On the other hand, it's virtually impossible to write any Javascript (the "dynamic" portion of DHTML) that is compatible between IE and FireFox (I leave it to others more knowledgeable as to the exact "history" behind this).

The first thing most Javascript developers do, is write a bunch of Javascript code to determine the type and version of the user's browser, and even the code to do this is a hack.

Microsoft has repeatedly fought browser compatibility tooth-and-nail for more than a decade.  Java (quite different from Javascript) was supposed to bring browser-independent client-side coding to the browser, and Microsoft:

1. Signed a license with Sun Microsystems to use it in Windows.
2. Violated the license by adding extensions outside of the license-approved methods.
3. Ended up paying $600 million to Sun in a long court battle over the above.
4. Brought out .NET, a Java look-alike that only runs on Windows.

This is the same company that has invested in B&N.  Shouldn't we all feel happy and safe now?

[keriflur]

---

akaCat wrote:

Keriflur, your crappy work computers just happen to be using a browser that's the same or similar to the one Lithium developed this forum on. It's reading the javascript the way the developer intended, so you could say that it's taking the direct path from point A to point B and not getting overwhelmed.

---

Well, if it helps anyone, I'm running Firefox 6 at work (it should be noted that I run it off of a flash drive, not the actual PC), whatever the newest non-beta Firefox is at home (and I use Chrome on that machine too), the latest Chrome on my netbook, and the default webkit-based browser on my rezound, without issues.  Those all seem to work well.

I'm fairly certain that the Lithium software is a bit older than even Firefox 6, but I get where you're going with this.  And hey, it's working for me, so you won't see me complaining. 

[Sun_Cat]

---

DeanGibson wrote:

---

akaCat wrote:
...

No two browsers, and often even different versions of the same browser, are going to "read" javascript exactly the same way. The more complicated the javascript is, the more difficult it is to make sure that every browser in the wild is going to read it well. Eventually you reach a point where the only way it will run reasonably well on every browser, is to have a seperate copy of the code for each browser.... and Lithium isn't doing that.

(And unfortunately, the preceding paragraph is a little over-simplified. Two of the exact same version of the exact same browser may read javascript differently depending on what the browser options are set to, if there are any addons, and very likely a few dozen even more obscure reasons.)

---

I couldn't agree more.  In the industry, it's called "Dynamic HTML", and a more bastardized language combination would be hard to find.  Regular HTML has its incompatibilities, but if the developer exercises certain cautions, it's pretty compatible across most browsers.  On the other hand, it's virtually impossible to write any Javascript (the "dynamic" portion of DHTML) that is compatible between IE and FireFox (I leave it to others more knowledgeable as to the exact "history" behind this).

The first thing most Javascript developers do, is write a bunch of Javascript code to determine the type and version of the user's browser, and even the code to do this is a hack.

---

This is true up to a point, but it's not quite as dire as you make it sound. There are now well tested JavaScript libraries that provide reasonably good, reasonably efficient cross-browser functionality. Developers who use the libraries consistently get much better results than those who try to roll their own.

The dominant such library at the moment is jQuery, and that in fact is used by many of the scripts running on this page, which includes about 25,000 lines of JavaScript code that's loading directly from a number of different sources, including barnesandnoble.com, lithium.com, and doubleclick.net (advertising). Plus, there are many more thousands of lines of code loading indirectly.

One of the worst offenders looks to be a set of tracking scripts hosted at barnesandnoble.com but apparently originating with a company called Coremetrics, Inc. These scripts do not use jQuery; they roll their own DHTML, and they were apparently last updated in 2006, which is a long time ago in Internet years.

[DeanGibson Distinguished Bibliophile]

---

Sun_Cat wrote:

---

.. but it's not quite as dire as you make it sound. There are now well tested JavaScript libraries that provide reasonably good, reasonably efficient cross-browser functionality. Developers who use the libraries consistently get much better results than those who try to roll their own.

The dominant such library at the moment is jQuery, ...

---

In other words, there's a library API layer that allows developers to write browser-independent code that should have been possible with original API, if certain persons/companies had not made intentional changes to break compatibility (or been incompetent, as akaCat suggests).

Yes, if there is going to be a lot of JavaScript on a site, the libraries are really nice, but if you just want to do something simple, there's almost no getting around a browser test.  My complaint is that it started out incompatible, and the compatibility layer is a bandaid on the problem.  That has some performance hit, by the way;  25,000 lines of code is a lot to be interpreted on a page load.  Oh, wait;  that was the subject of this thread ...

The more insidious impact of client-side code (even if there were no incompatilities), is that many developers write code to do error checking on the client-side.  While this has the advantage of reducing network traffic (and delays) for user errors, it doesn't (or shouldn't) eliminate the same error-checking on the server-side (which means there's little savings in server performance).  I'll bet there are a LOT of sites out there that only depend on client-side validation to protect the server-side database.  Since a knowledgeable user can grab such client-side JavaScript code and modify it, all the security checks should be done on the server as well.  I'll bet there are a LOT of holes ...

It's not like there aren't several good solutions.  I use php for virtually everything on my sites, and phpBB (message board software written in php) is probably the most popular message board software, and virtually all (if not all) of it is server-side php code.  I only use JavaScript for displaying the date/time in the user's time zone on a couple web pages.