I think that by when you are saying refresh, this function is being called on each update. So each time you run it, it goes like this: < div id = "history_list" > < ul > < li > Item 1 </ li > </ ul > </ div > To: < div id = "history_list" > < ul > < li > Item 1 </ li > </ ul > < ul > < li > Item 1 </ li > < li > Item 2 </ li > </ ul > </ div > What may need to happen is to remove the previous list, before you append the new list to the div, like this: var ul = document.createElement( 'ul' ); var list = document.getElementById( 'history_list' ); //Cleans the list while ( list .firstChild) { list .removeChild( list .firstChild); } list .append(ul) //Rest as normal I would not recommend using innerHTML to add the text, as that may leave you open to a XSS attack. You should prefer to use the element methods and properties to construct the link. Also to validate it, as someone could put href="javascript:alert("hi")" as a link.

Exactly that. Thrown exceptions cannot be caught in asynchronous code. It is a big reason why Promises were made, which would make more sense if I didn't forget to mention it. Although, if you were to use the new async/await syntax, instead of calling the method catch() , you could actually regain use of the try...catch . So then the code would look like this: try { const cake = await baker.bake( 'bake' ) await peasant.eat(cake) } catch (e){ console .error(e) } This works because async/await are just syntactic sugar for Promises.

In order to answer the question of "What is a Promise?", we should ask the question "Why is a Promise?". What is the problem that promises are supposed to solve? Although Marco Alka 's answer is close, but that solution can easily be solved by a callback. In fact, Node.js uses a callback for its file operations (although that will be soon changing that to Promises). This how we could have a baker work using a callback and handle the errors: baker.bake( 'cake' , function ( err, cake ) { if (err) { console .error(err); return ; } peasant.eat(cake); }); I was able to handle the error. So what does a promise give us extra over a callback? Well, lets say that all of the peasants decided to revolt, because that is all the ungrateful bunch ever think about. So when I call "peasant.eat(cake)", they just throw a fit. How am I supposed to handle that? Well, with promises, these sort of errors can be handled. baker.bake( 'cake' ) .then(peasant.eat) //Let's just pretend that 'this' remains the same . catch (console.error) So now, whether this failed because the baker died or the peasants are revolting, I get notified that someone is not eating their cake. Well, let's think about this. If the baker is not doing his work, he is easily replaced. I don't care if he is sick, injured, or dead. For all I know, he could be joining those peasants. So if we want to replace him, it could be as simple as: baker.bake( 'cake' ) .then(peasant.eat, () => executioner.fireAndReplace(baker)) // I would put quotes around "fire", but JavaScript syntax doesn't allow me . catch (console.error) So now, if a error showed up, I can replace that filthy baker. Of course, more work will have to be done so that the bakers family doesn't start questioning where he is, also reimbursement of the peasant who didn't get his cake, but you can see that this is beginning to take shape. So as an overview. Promises allow for better handling of chaining operations. Errors in the chain get propagated to the nearby error handler, whether it be with ".then(success, error)" or ".catch(error)". It also standardizes error handling, as my error parameter could have been the first argument or the last.

Microsoft still supports IE, they just no longer support older versions, such as IE 10 and lower. IE 11 is still supported and will be until they drop support for Windows 7 and Windows 8.

This is interesting. I just tried this out, and replaced your last css rule with: #output span + span:before { content: '-'; } Now, between each set, there is a dash, but if you were to select it, and do a copy and paste, it would not include the dashes. So you may be able to get more stylist with this approach. Now I don't know if this is the same with all browsers and OS, but it is interesting.

Just want to add on, although Node.js is very good for some of these, because of its single threaded nature, CPU intensive tasks can make it take a hit. Number crunching is one of the weak points of Node.js. This is because since Node.js is a single threaded application, if it is stuck resizing an image, then the server will be unable to respond to other requests. The way to get around this, is to rework the algorithm so that it is more event-based. There are various ways to do this, one of which will return a bunch of Promises with each having a small bit of the calculation to be done. This will allow Node.js to shallow the calculation a bit better. Another solution is to move the CPU intensive operation into another application/service, in which Node.js will call that. Node.js works best for small requests. Now, allow me to talk to you about our Lord and Savior, Google. Google, in its infinite wisdom, has created a language called Go. Go is very much like C, except it has more modern concepts, such as concurrency and requests. Go handles concurrency by making it simple to create a goroutine, which can be created on a separate thread, or on the same thread, managed by the go scheduler. With that, you then use a channel to pass the calculated data back into the main routine. Also, it compiles down to machine language, instead of being interpreted, and also comes with its own garbage collector. Node.js is very much a web server type of language, meaning it is good with quick requests. Go is a server language, as it is designed to handle concurrency a bit better, so it can handle longstanding requests. Honestly, you should not tie yourself to one language, as they all have weak points. Do you just want to work on servers? What do you want to do on that server? I haven't even gone into application type languages, which you already have Java. There is also system languages such as C and Rust, if you need that memory control. For me, I am currently happy with Go. JavaScript is interesting, but can be a bother, because you have to split your logic into chunks that it can shallow.

I personally wouldn't. Regex has its place, but if it takes over 20 characters to describe its purpose, then there must be a better solution. Looks like you are using Java, so the Apache Commons Validator library should help out. It can validate emails and your could make it so that it doesn't use IP addresses or localhost as valid emails. If you still feel this is best, then I would wrap it at matching parentheses, because those specify groups. Also at square brackets if necessary. If there is a plus or star at the end of either of them, I would put the new line after that, because those specify whether you want it to repeat. Same thing for curly brackets. Pattern cachedEmailRFCChecker = Pattern.compile( "^\\A(?=[a-z0-9@.!#$%&'*+\\/=?^_`\\{|\\}~-]{6,254}\\z)" + "(?=[a-z0-9.!#$%&'*+\\/=?^_`\\{|\\}~-]{1,64}@)" + "[a-z0-9!#$%&'*+\\/=?^_`\\{|\\}~-]+" + "(?:\\.[a-z0-9!#$%&'*+\\/=?^_`\\{|\\}~-]+)* + " @(? : (?=[a-z 0 - 9 -]{ 1 , 63 }\\.) " + " [a-z 0 - 9 ](? : [a-z 0 - 9 -]*[a-z 0 - 9 ])?\\.)+ " + " (?=[a-z 0 - 9 -]{ 1 , 63 }\\z)[a-z 0 - 9 ] " + " (? : [a-z 0 - 9 -]*[a-z 0 - 9 ])?\\z$" );

The simplest question that has already been proven by Alan Turing that a computer can never be able to answer. "Is my program looping?" Sounds like a simple question, but it is in fact undecidable and known as the Halting Problem. You can know in certain obvious situations whether it is looping or not, but you can't apply a technique to all programs to determine whether it is or not. This question doesn't just apply to today's computers, but computing theory, meaning that no matter how much memory is applied, no matter how fast it is running, no matter if it is deterministic or not, if you were to create a program using the full capabilities as the computer answering the question, it can never fully know whether the program is looping or not. Of course, by rewording your question we can come up with another, "What is a question that you are unable to answer?". If a computer is able to answer this question, then the answer to this question is a question that they are unable to answer. But if they are unable to answer this question, that means that they are unable to answer this question. Surprisingly, they can never be unable to answer this question, simply because if they were unable to answer this question, then the answer is this question, but it can't be because this question now has an answer which is itself. Therefore there always has to be an answer other than itself.

What do you mean second option? $("div#myUnique\\$0\\$") should suffice, but you could also drop the div, so that it will become $("#myUnique\\$0\\$"). Besides that, without knowing the structure of the HTML, I couldn't suggest anything else. If you know that "myUniqueID" is definitely going to be unique, then you can use $('[id^="myUniqueID"]'). "^=" says to match just the beginning of the string, so everything after myUniqueID will be ignored. Just know that it will also match "myUniqueID$1$" and "myUniqueIDs"

It grabs elements that match the following criteria: divs with an id of "first" <div id="first"> divs with a class of "first" <div class="first"> any element that has an name attribute whose value ends in first and is immediately the child of an "ol" that has an id of items < ol id = "items" > < li name = "first" > < li name = "testfirst" > Honestly, this query is not a good one. First off, all ids should be unique on the page, so "div#first" can just be #first. Next, the last part of the query with "ol#items > [name$='first']" reeks of bad semantics. The only element allowed directly under "ol" is "li". "li" can hold whatever, but "ol" should only have "li" direct children. Also name is not a "li" attribute, so that isn't semantic either. Of course, I know that sometimes we are not allowed to touch the HTML, so you may have to just deal with it. In order to match <div id=”myUniqueID$0$”>, the query would be: $( "div#myUnique\\ $0 \\$" ) Looks silly, but the two slashes are necessary. When your selector sees "div#myUnique$0$", it will toss it out, saying it is invalid. So if you were to escape it once, "div#myUnique\$0\$", JavaScript is going to jump in, because "\" is a escape character for JavaScript as well. So when Javascript sees that, it will replace it with "div#myUnique$0$", which we already know our selector with toss out. Therefore, we need to escape the escape character. This way it will turn into this: Code Javscript Sees ID selector looks for "div#myUnique\\$0\\$" "div#myUnique\$0\$" "myUnique$0$"