22 Feb, 2009, Igabod wrote in the 1st comment:
Votes: 0
I had an idea I wanted to put into effect, but wasn't sure if it was possible, and if it is, how to do it.

I want to make a link on my webpage and when you click it, it sends you to website1 on my list. At that point it would change it so that website2 on my list is what that link points to. So you click the link again and it sends you to website2, rotating to the next website on my list.

I'll try to make this a little clearer. This is supposed to be a link that says "Something to do if you are bored" or something like that. It would pull an address from a list I make of all my favorite websites for when I am bored and send you there. Never sending you to the same place twice in a row.

I'm pretty sure I'll need something more advanced than HTML to do this, so if anybody knows how to do it, keep in mind that I will need to walked through it like a child. If it's possible with HTML, I should be able to follow it easier and you don't need to treat me like a child.

Thanks in advance for any advice I can get.
22 Feb, 2009, David Haley wrote in the 2nd comment:
Votes: 0
No, you cannot do this with just HTML. Think about what you're trying to do: create a session per user that tracks which links they've clicked on, so that you can avoid showing the same one twice. HTML has no state, so it's out of the game from the get-go. You'd need to do something with setting cookies, and retrieving them to see where the user's been.

But if you have a sufficiently large number of links, it should be fine to just display one at random. Sure, you might get the same thing twice (or thrice) in a row from time to time. But it's a whole lot less work, and can be done with javascript fairly easily.
24 Feb, 2009, Igabod wrote in the 3rd comment:
Votes: 0
I wasn't exactly thinking of tracking it per user, more like each time the link gets clicked, it rotates the address it points to. Whether this was done by a different person than the last wouldn't matter. Just the fact that the link gets clicked makes it switch over.

I'd rather it not be random however, to prevent getting the same link twice. I'd rather have a set list that it rotates through. This list is only going to have about 10 - 15 links on it, not many at all really.
24 Feb, 2009, elanthis wrote in the 4th comment:
Votes: 0
You CAN do it with just HTML and JavaScript, given that you can set and retrieve cookies with JavaScript. The whole of what you need to store is an index. Crappy code for making it easy to deal with cookies in JavaScript:


Code would be something like:

<script type="text/javascript">
// insert code copied from link above here

var urls = ['http://link1', 'http://link2', 'http://link3'];
function open_link() {
var index = parseInt(getCookie('link_index'), 10);
if (!index || index >= urls.length)
index = 0;
setCookie('link_index', index + 1, 7);
document.location.href = urls[index];

<p><a href="javascript:open_link();">open a silly link</a></p>
24 Feb, 2009, Igabod wrote in the 5th comment:
Votes: 0
ok, line 10 in your example says docuent.location.href = urls[index] Is there something I need to enter there or is that exactly how it should be? Cause I've seen some examples of javascript before where that was different. I understand that on line 4 I would change the links obviously, but don't know if there's any other data I need to change in there.

Thanks for the help by the way, I'd have never figured this out on my own, even with the help of tutorial pages.
24 Feb, 2009, David Haley wrote in the 6th comment:
Votes: 0
Setting document.location.href is like clicking on a link – it tells the browser to go to that page.
24 Feb, 2009, elanthis wrote in the 7th comment:
Votes: 0
Note that the code was off the top of my head and may not work perfectly. You may need to move the parseInt bit after the first if check (but leave the assignment from getCookie where it is). parseInt returns NaN when it is called with an invalid number, and I can't remember how that behaves with boolean expressions in JavaScript.
25 Feb, 2009, Igabod wrote in the 8th comment:
Votes: 0
DavidHaley said:
Setting document.location.href is like clicking on a link – it tells the browser to go to that page.

ok, so I need to make a new document of some sort, other than this bit of code? I'm kinda a little confused by this. If I do need a seperate document for this, what does it need to contain? Keep in mind that I've never attempted doing anything in javascript before.
25 Feb, 2009, David Haley wrote in the 9th comment:
Votes: 0
You would put the script in the HTML header, if memory servers, and then stick the link he gave wherever you want it to be. Or maybe the script can go right above it – haven't played with this in so long that I don't remember.

No need to create a new file, though.
25 Feb, 2009, elanthis wrote in the 10th comment:
Votes: 0
I would highly, highly recommend finding a JavaScript tutorial or three and reading them. It is a very simple and yet incredibly powerful language, and is seeing more and more use in desktop applications and server backends in addition to being the workhorse of the World Wide Web.

document is a global variable. It's an object that represents the document being viewed in the current window/tab. document.location is an object (a property of document named location) that represents the various components of the URL used to load the document. On that object is a special property named href. It is a string containing the full URL used to load the document. However, if you change that property's value by assigning a new string to it, secret voodoo magic inside the browser notices and causes the current window/tab to load up a new document with the new URL you assigned to the property.
25 Feb, 2009, Igabod wrote in the 11th comment:
Votes: 0
so document.location.href is already in existance on the web and I'm just calling on it with this script? Just a little bit confused here. And will document.location.href work on any javascript or is it just for this particular type of script?
25 Feb, 2009, David Haley wrote in the 12th comment:
Votes: 0
Not sure if you're replying to me or Elanthis – he explained what 'document' is. It's a variable, and setting its property location.href causes the browser to move to a different URL.

Setting that property in any javascript script will cause the browser to change pages.
25 Feb, 2009, Igabod wrote in the 13th comment:
Votes: 0
Sorry, was replying to you DH. Didn't even see elanthis's response till just now.

Ok so it's sort of like the javascript equivalent of <a href="? Not exactly, but it serves a similar purpose right?
25 Feb, 2009, David Haley wrote in the 14th comment:
Votes: 0
Well, it depends on what you mean – I think the answer to your question as you meant it is "yes", but the answer is "no" if you get picky about the terms… let me clarify:

The <a> … </a> tags are just data. They don't do anything other than sit there and give the browser information about what it's supposed to do when you click on them.

In contrast, the document.location.href = "foo" line is a statement, or an action if you will. It actually does something: it changes the current page. Whenever that line is executed, something actually happens.

Javascript is a programming language, and so its statements actually do things when executed. The <a> tag however is just a piece of data that doesn't "do" anything at all. Anchors (that's what the 'a' in <a> stands for) aren't even necessarily hyperlinks that change the page. They can be page bookmarks, or as in elanthis's example, links that execute a script function when clicked upon. You could change the href to alert("hi there"), and it would pop up a message box instead of doing anything like moving the page.
25 Feb, 2009, Igabod wrote in the 15th comment:
Votes: 0
yeah I wasn't being picky about the terms or anything, after reading elanthis's reply and yours I understand what is going on here now. That one line is the only one that really gave me problems.

I plan on reading a tutorial in the near future (next couple days) but I had other things on my plate first. This thread was started mostly to see if it was possible to do it. Now that my question has been answered, my interest in javascript is sparked a little. Before, I had very little interest in learning javascript, but now I can think of a bunch of ideas I've had that weren't possible with html that might just be possible with javascript.

Thanks to both DH and Elanthis for holding my hand and explaining it to me patiently. I'm so happy this forum exists. If I had asked this question on mudconnect I'm sure I'd have been called an f-ing retard at least 12 times before anybody bothered to tell me that it could be done with javascript. At least that's the way it was when I last visited that place.

[edit cause I'm stoopid and speeled sumthing cumpleetlee rong.]
25 Feb, 2009, David Haley wrote in the 16th comment:
Votes: 0
Javascript is an amazing tool for web development. Nearly any dynamic feature you see online is done with either Flash or Javascript. You can implement whole applications like Gmail, Google Docs, etc. using just Javascript (on the browser side, at least – you still need a server for the javascript to talk to).
It's also nifty for things like images changing when you hover, expanding/collapsing menus, and so forth.
I am relatively inexperienced with practical applications of Javascript to web development, although I know the language itself fairly well in theory (funny how that works, really) – my first reaction wasn't to talk to cookies using Javascript so I learned something here too. :smile:

In any case, glad that we could be of help :smile:
25 Feb, 2009, elanthis wrote in the 17th comment:
Votes: 0
Great tutorial: http://www.quirksmode.org/js/intro.html. The http://quirksmode.org site in general is one of the best resources around for Web developers. I think that site and https://developer.mozilla.org/ will probably cover 95% of your needs for HTML/CSS/JavaScript information.

DavidHaley said:
You can implement whole applications like Gmail, Google Docs, etc. using just Javascript (on the browser side, at least – you still need a server for the javascript to talk to).

Unless you want to support IE, you don't even need a server. :) Firefox (and I believe Opera and WebKit) offer SQL databases embedded in the browser for your scripts to store data in as well as other storage services. We're starting to see built-in geolocation systems and such too. There are several "offline Web" development toolkits available these days that make it possible to develop apps that can function both on and offline or even entirely offline.

The entire Firefox user interface is actually written in JavaScript and XUL (which is basically HTML for user interfaces), as is Thunderbird, Songbird, and other Firefox-related apps. Almost all Firefox plugins are entirely JavaScript and XUL. There are also more and more servers being written in JavaScript. Some of the most popular Open Source desktop applications are being written for JavaScript-based engines that use the desktop's native window toolkit libraries. This is all thanks to the fact that we now have multiple high-quality Open Source JavaScript engines that can be used in any application (Mozilla's SpiderMonkey, Apple's JavaScriptCore, and Google's V8). The performance of these engines is also incredible, with at least two of them already JIT compiling the JS bytecode into native machine instructions, sometimes even surpassing the speed of the equivalent C code (in very specific tests – C still wins… for now).

JavaScript is far more powerful and elegant than most people realize, mostly because its use on the Web can be a bit frustrating at times. For one, almost nobody uses all the power of modern JavaScript because Internet Explorer doesn't support anything newer than JavaScript 1.5, so those newer features are unusable for Web development. Second, browsers still carry a lot of legacy cruft from the cracked-out decisions of the old Netscape team, such as assigning to document.location.href to load a new document instead of making it a function like window.load(). The document.location.href magic trick wasn't even possible in the original JavaScript language itself and required special hacks inside the browser… how the Netscape engineers thought that was a good idea – and why Brendan let them get away with it – is beyond me.
25 Feb, 2009, Vassi wrote in the 18th comment:
Votes: 0

-covers his ears and chants la, la, la-

But seriously, It wasn't until I used libraries like jQuery that I managed to gain some love for the language. I'm currently committed to a back-end (I love back-end stuff, you can be picky about which browser they can use) application that uses PHP and Javascript for some dreamy UI in order to get a better handle on it and get some practice using it. Web integration, as WoW Armory and other such services have shown us, is a growing necessity for any interactive form of entertainment both from the user side and productivity side.
25 Feb, 2009, David Haley wrote in the 19th comment:
Votes: 0
elanthis said:
The performance of these engines is also incredible, with at least two of them already JIT compiling the JS bytecode into native machine instructions, sometimes even surpassing the speed of the equivalent C code

This claim is pretty hard to believe; what are the specifics here? How can it be impossible to write C code that generates basically the same machine code as the JIT compiler?

I agree though that it's a nice language in general; actually, its semantics are fairly similar to Lua's, in many ways. (Lua is more sane, though, IMO at least.)
26 Feb, 2009, elanthis wrote in the 20th comment:
Votes: 0
David Haley said:
elanthis said:
The performance of these engines is also incredible, with at least two of them already JIT compiling the JS bytecode into native machine instructions, sometimes even surpassing the speed of the equivalent C code

This claim is pretty hard to believe; what are the specifics here? How can it be impossible to write C code that generates basically the same machine code as the JIT compiler?

Tired and slightly intoxicated, so forgive the rambling, poor explanation…

It's not "impossible," but it's much the same as how technically you _could_ write code in assembler that's faster than well-optimized C code, the fact is that on modern CPU architectures it's really stupid ****ing hard and the C compiler has a lot of magic tricks up its sleeve to eck out better performance than you can really achieve by hand. Now combine that with profile-guided optimization, where the compiler can pull off even more magic tricks when you give it profiling information from a previous runs of the application.

Essentially, the JIT compiler engines being used now are essentially doing that, except better. They can optimize the exact code being actually run and don't rely as heavily on speculative optimization (which is all a C compiler or human is capable of). Tracing in particular is the "hot" technique in the JavaScript world (it's not all that new, but its application to scripting engines is).

With C or other "AOT" compiled languages, you the programmer have to try to guess which functions should be inlined, where to unroll loops, where to move code around to avoid excess branches, when to precompute values, etc. Compilers are getting good at guessing at a lot of that, but there's just a limit to what they can do because they still have to guess what code path is going to be taken. Tracing JIT engines however follow the actual path of statements taken by the program and generate machine code for that exact series of steps.

It's essentially the same thing as manually inlining a bunch of code, but manually doing that in every critical loop or oft-called function is just out of the question from a maintenance and sanity perspective. The tracing engine beats traditional compilers because tracing actually knows for a fact which loops or functions are "hot." They can know that 98% of the time you call foo() the global variable it accesses is always 10, and so it can generate machine code that optimizes away every if check or arithmetic on said variable and just add a single barrier to the function to note if that variable actually happened to vary (and if it does, drop out of the JIT-compiled code into the interpreter, which might then load up another more generic version of the function's machine code, or just run it under the interpreter if foo is so rarely run with that variable not being 10).

Now that the basics are down, there are experiments at actually inling the underlying C code straight through, so even the call points between the interpreter and the underlying C/C++ runtime (or even straight through the C library itself!) are automatically inlined away.

Basically these optimizations are only really powerful for tight math-heavy loops, like image processing or the like. More general-purpose code isn't as likely to benefit from tracing, so a JIT engine is not likely to exceed the performance of C. The nature of dynamic languages pretty much guarantees that they'll remain slower than well-optimized C code for those kinds of code paths because of all the extra checks that have to be done all over because any variable can be any type (although many dynamic engines work around -that- where possible too, like JavaScriptCore and V8's approaches). However, those very same JIT techniques are applicable to non-dynamic languages (like Java or C#) and it's quite possible that we'll start seeing those outperform all but the absolute best-optimized C code.

On top of all that, various techniques in VM engines actually make managed languages much faster. A modern, good garbage collector is actually _faster_ than manually-managed memory in many cases, because the garbage collector can perform memory management during normally-occurring program pauses (remember, free() is not free) and also because they can compact memory and negate the performance degradation caused by heap fragmentation.

C cannot take advantage of many of these new techiques because they all require on the runtime being able to pull off magic tricks, but C does not allow the runtime to have enough information to do them. Garbage collectors for C/C++ cannot compact memory, for example, because they have no way of knowing where valid pointers are because programmers can stuff points inside of other data types or use weird bit-manipulation tricks on them and so on. The C language does not express enough of your intent to the runtime for the runtime to be able to make intelligent decisions.

Likewise, dynamic languages have limitations too. Because you don't tell JavaScript/Python/Ruby/etc. the type of a variable, the JIT-compiled code has to assume that the type of a variable will eventually change (except in simpler cases where it can clearly see that the variable is not assigned to). Even simple cases can trigger a variable to change type (and hence invalidated JITed machine code), such as incrementing an integer variable by 1: in C that just rolls over, but in some dynamic languages that causes the variable to change from a fast native integer type into a "BigNum" object.

The best performance is going to be available only from statically-typed, metadata-rich, managed languages… like Java or C#.

Then the neat thing is that JavaScript 2.0 is on track to include optional static typing, meaning that performance-sensitive JavaScript code could be written to take full advantage of modern JIT compilation techniques without the disadvantages of dynamic languages.

Oh, and let's not forget that languages like JavaScript make it way easier to take advantage of modern computers' parallelism. Writing safe threaded C code that actually gets a real performance boost out of the threads is damn hard. Writing it in a language like Java is easy. Writing it in a language like JavaScript is even easier.

Keep in mind that any of these advances in JavaScript (except the static typing stuff) is just as applicable to Lua or Python or so on. JavaScript is just further ahead than those languages because right now the whole "Web 2.0" stuff is soaring and everybody thinks that the Web is going to replace the OS and there is just a ton of money being put into paying smart people to make browsers (and JavaScript) stupid-fast.

I agree though that it's a nice language in general; actually, its semantics are fairly similar to Lua's, in many ways. (Lua is more sane, though, IMO at least.)

We've had this debate before. ;)