Events

Events in JavaScript are still very shady to me.  I see the way they work, and I only slightly understand the way browsers execute them.  A great deal of this chapter on events covered cross-browser problems (especially involving Internet Explorer) and was confusing in explaining the core details of event listeners.  I can't firmly say I understand them. In order to troubleshoot those I have been able to implement, I have taken the code archive and stepped through each action to see where the next part of the script would be executed.  It's been quite a rollercoaster ride through spelling mistakes and logical errors on my part, but it's helped me see how some parts work.  It takes a lot of work to get the functionality as intended when working with an already-existing page, but the efforts seem to play out in the end.  I can see the importance of being able to use events now, and I hope I can implement the idea in further projects throughout my expanding web development hobby or career.

Events are important to the extent of user interaction on a web page.  It is important to let users be able to interact with a page for a better user experience while visiting.  At the same time, however, just as with design and form, the function or behavior of the page must be separated from the content of the page.  In this way we keep accessibility alive and our code can be reused in other cases for the same processes in the future that we need on particular pages we create now.

Document Object Model (DOM)

The Document Object Model (DOM) is used to define the parts of a document, be it HTML or other type.  In the scope of JavaScript, the DOM is used to define what elements can be accessed using the scripting language and changed.  The role of the DOM in web development is to define a standard so languages such as JavaScript can search through elements in a document and change them according to user input and other factors.  Development of websites has become more dynamic due to the ability for change using scripting languages.  This dynamic interface with the end user has created a more live approach to web surfing and presentation of content on the web.  Users can get feedback based on input directly from these client-side scripted pages.  Web browser vendors have developed browsers that can interact to provide the platform- and language-neutral interface features of the DOM to allow other languages to manipulate the contents displayed.  Developing the DOM has enabled the expansion of multiple browsers because it sets a standard on which others can build and comply.

Following the specifications recommended by the W3C is in best practice just as obeying defined courtesy laws in traffic.  If everyone developed a different solution to the object model, the referencing would be very browser-specific, and generally non-conformity leads to more confusion and lack of support.  Drivers and developers alike rely on a system of conformity on which they comply to get the optimal results from the task at hand.  The tested standard in place by the W3C, as defined, will result in the best compatibility between sites and browsers in the coming future.  That is why standards are in place, and that is why we look to them as a foundation on which to build.

The DOM is something I've referenced and used without first knowing it existed.  In the playground of development, getElementById was a necessary property on which I relied for changing a predefined web page to meet my personal taste.  I didn't know as much then as I do now, but it was an adventure which helps me appreciate the DOM now.  I can see its value in the development of browsers and in a world where no one can tell who will use what to access what is available.  Just as I have previously stated, some choose to conform to and others to dictate to the masses of the development sector.  W3C standards are generally dictations of what others should conform to when considering future development in the fields concerned, but as such, the dictations are generally derived from a collection of conformities collected over time and defined as best practice.

JavaScript

Developing with JavaScript for me is much like my previous semester where thoughts often fall into the categories of if and then decision-making for everyday life.  I've had some previous experience decoding JavaScript for purposes of just playing around with possible code features on a website where users log in to view a page.  I scripted the site so that if the user is in fact logged in then display the page, otherwise they will be redirected to the login page and will not be able to view the page requested.  It was this that consisted of the first points of my interest in JavaScript, and I found myself browsing the W3C school website quite often to better understand the code for which I had no previous editing experience.  I've begun again to think of different implementations for JavaScript, including authentication of users and form-filling features for users.  I look toward the future a little more, where I see ASP and PHP web programming languages taking over the features we see in JavaScript, but not entirely replacing the use for it on the web.

JavaScript and Java are often confused.  The basic difference is that a script is used to send instructions through a program to perform a task.  Scripts are interpreted whereas Java, as a program language, must be compiled and decompiled using a program that must be installed on the computer.  Scripting languages, like JavaScript and VBScript, are lighter in the sense of memory usage on the computer.  Once a programmed language like Java loads it must run the decompiler for the entire duration of the program.  In the case of JavaScript, the browser renders the script and interprets it as it comes across the code, and when the process is complete, the rendering of the script is over.  JavaScript is used to accept and apply user input and can be changed by the user.  Java is more of a static program when used online which cannot be changed, but instead has been packaged to meet a specified need before being distributed to be run by its own decompiler.

JavaScript, most formally although less widely known as ECMAScript or ECMA-262, was turned over to an international standards body in 1996, which then became responsible for subsequent development in the scripting language.  The ability today for JavaScript to be separated from the content and presentation of the website has broadened its use and enabled developers to implement the features of JavaScript more thoroughly on the Web without limiting users from accessing the content intended.  However, as of now, I cannot say I see the future in JavaScript.  I have seen its uses for programming simple sites where no database is used, but the future lies in the database-driven website and JavaScript might be an afterthought.