I find that usually the easiest thing to do (the least Javascript) is to have the event (in your case, the mouseover/mouseenter) add and remove a class to the element and use that to show and hide pre-written CSS styles.
However sometimes some manipulation is good too… especially if the real goal is to get comfortable with Javascript.
Make a message display when the user moves the mouse over an image. Consider good usability practice.
Thinking of this as a tooltip, this reminds me of a task in one of the Sitepoint Javascript books… I think “Simply Javascript”. The point was to make a tooltip appear when an anchor was hovered over.
The technique they used there was, the anchor had the text already, inside its title attribute. With Javascript, they first
- found the anchor element
- found its title attribute
then
- created a new element, which was what would appear (I think a span)
- copied the text from the anchor’s title attribute and appended it to the new element
- possibly also set the title attribute to “” (empty string) so that the browser’s default tooltip didn’t get in the way
- appended the new element as a child to the anchor
- used Javascript to add in the styles to everything: position: relative on the anchor so it could be a positioned ancestor, position: absolute on the span with some coordinates (to place it where you wanted), and some other styles. Actually, these might have also already been in the CSS, which is generally a smarter thing to do in practice (other than maybe changing the display state of an element from say its default to ‘none’ and back, CSS is faster and gets to use the machine’s GPU, not the CPU), in which case the styles from the CSS come into play when the new element is added to the DOM.
Everything gets ‘undone’ when the mouse leaves.
Of course, this can also simply be done with pure CSS, defeating the point of your exercise, but maybe you can look at that for inspiration. The second task is pretty similar to the first:
When the user moves the mouse over an image a larger image should appear. Other page elements shouldn’t move and when the user moves the mouse away from the large image it should disappear.
One way would be to have small and large images as two separate images and already in the DOM:
<a href=“somewhere” id=“foo”><img src=“small img url” alt=“img alt”><img src=“larger image url” alt=“”></a>
Where
#foo {
position: relative;
maybe also display: block, we don’t need anything shifting around in some weird browser
}
#foo img+img {
display: none;
position: absolute;
set left and top to taste;
}
Where then, for example in CSS you’d have
#foo:hover img+img, #foo:focus img+img {
display: block;
}
being an absolutely positioned child, its appearance won’t shift the rest of the page around. This’ll be true even if you end up creating the element with Javascript. A real-world example of the second task is product image zoom in e-commerce. Usually the performance-thinking developers will simply have the page load the larger image only (there being only a single image instead of two), and use CSS to show a shrunken-down version, while Javascript clones it and shows it without shrinky CSS. This might be a good idea if the page is dedicated to the one image and it’s very likely the user will want to zoom, so you’re avoiding a double HTTP-request penalty.
Other people request a larger image with AJAX. This can be the better idea if there are many images on the page (so you wouldn’t want to load a lot of very large images with poorly-squished-by-browsers-versions being shown, and also with many images it may be more likely users will only zoom in on some of them). At the very least, users who are bandwidth conscious are choosing if they will request the larger image themselves.
Having the larger whatever or the extra text already existing somehow will always be faster when it comes to executing your Javascript. Sometimes, it only makes sense for Javascript to create the elements though. In these cases, look into
-cloning/copying DOM elements
-document.fragments (making elements in memory and appending stuff to them is cheap; adding/removing them to/from the page DOM is the expensive part)
- not creating stuff inside the event function. Have the event function be concerned with the hiding and showing, and either let creation happen in the background on page load, or at least deal it off to another function who can be stored in memory and simply called by the event listener
- there’s a new thing called <template>, but today you can use a script as a “template”, which is just an element that browsers naturally don’t display (like <script> tags) which contain HTML… I’ve done this for appending complicated sets of fieldsets to forms onclick of an “add more” button. They kinda look like this:
<script type="text/x-template" class="product_info">
HTML in here...
</script>
Then I didn’t have to create a bazillion elements in Javascript and hold them all in memory… instead I grabbed the script by its class name and kept cloning the HTML inside over and over again and appended them in groups of 10 
I don’t know what your familiarity with DOM manipulation is in Javascript, or which browsers you need to support. If the above ideas still don’t do anything for you, then you may need to just wander around the web and look at things like creating, appending, removing elements, and using event listeners. You will need all of these to do any of your tasks.
So without writing a line of Javascript code in this whole post, I hope any of this is helpful. If not, or you have specific questions or run into some code you wrote not doing what you thought it should, let us know.