Hello guys 
, I’m learning Javascript programming language…
I’ve learned some basics and don’t know if it’s enough.
I know JS variables,functions,events,loops,popup boxes… I’m gonna start learning php after JS , so how do you think is it enough to start php or continue learning ?
Hi Georga, welcome to the forums!
Will it be enough? That really depends on why you’re learning. If you want to be a front-end developer, for example, then having an in-depth knowledge of JS is going to be important.
Looking at the list you’ve given, I’d say the most obvious omission is objects. If you want to be able to do more than just wire-up jQuery plugins, you’ll want to understand how to create objects, how the prototype system works, and some basic patterns for writing apps in JS.
There are a lot of good resources available online where you can learn this kind of thing. One I’d recommend is Eloquent JavaScript.
The most obvious omission from the list is the Document Object Model. How JavaScript can interact with the web page makes up more than half of JavaScript.
If by popup boxes you mean alert, confirm and prompt then forget what you learnt - they were repurposed for debugging use only when Netscape 4 died and have more recently been completely replaced by the built in debugger and console.log calls.
Good catch, sometimes things can be so obvious that they’re easy to overlook!
While I’d agree that better tools (debuggers, and console.log) exist for debugging, the built-in dialogs do have their uses and I think it’s a bit unnecessary to suggest forgetting about them. I haven’t been able to find any source online to suggest they’ve been deprecated, or relegated to ‘debugging use only’ as you often suggest - perhaps you could provide a reference for this claim?
Certainly the Mozilla Developer Network (MDN) makes no mention of this in the entries for those functions. I’ve got a copy of Professional JavasScript for Web Developers (3rd Ed) by Nicholas C. Zakas handy, so I thought I’d see what he has to say about them:
These system dialogs can be helpful for displaying information to the user and asking for confirmation of decisions. Since they require no HTML, CSS, or JavaScript to be loaded, they are fast and easy ways to enhance a web application.
Obviously they have their disadvantages (you can’t style them), but they do have their uses within simple web apps for example. They’re even in use here on the SitePoint Forums, to give a notification of privates messages and to add URLs to posts, among other things.
What I see here are what I would call “modals” not dialog boxes in the classic sense.
To me using alert() and confirm() are “quick and dirty” and I often use them when I just want a quick look at what a variable value is at a given point in the code.
Then I quickly remove them.
And I know there is some code used here by Moderators that uses them. But that is because we “don’t mind”.
It would be a lot different if the scripts were being used by others outside of the forum staff.
And I would be hard pressed to recommend their use in a live site where the “less polished” look could leave a negative impression on visitors.
We’ll all be super happy when modal dialogs can be given the same default window focus as default Javascript dialogs… right now, to get the correct tabbing and focus behaviour of a model, you have to do all that by hand. It’s like building your own custom form control-- a pain in the ass.
The documentation doesn’t state that they were repurposed for debugging but the way they display in some browsers makes them useless for any other purpose.
As you can see both of these alerts show an extra checkbox to assist in debugging.
The confirm and prompt also have them.
They don’t display the same in all browsers but enough browsers have these extra debugging checkboxes to make it impossible to use the dialogs in a live page.
I used to always tick the “turn off JavaScript” box when web pages asked me to but now have turned off these three calls completely in my browser as I no longer use them.
It also seems strange to me, then, why the W3 HTML5 spec lists them as ‘User Prompts’ as part of the Web Application APIs section, with no mention of a debugging purpose? This is a very up-to-date document, so it would seem that the W3 intends them to be used in building applications.
Browser makers implement the checkbox feature as a protection against malicious pages that might otherwise put your browser into a continuous loop of dialogs. This also explains why both Chrome and Firefox do not show the checkbox on the first dialog displayed by a page, but only on subsequent ones.
Turning off dialogs without even reading them doesn’t sound like very reasonable behavior. I’ll go out on a limb and say that you’re probably in the minority of users.
But why would you want to use such limited dialogs when JavaScript makes it easy to create your own custom ones that display exactly what you want them to display without the “turn off JavaScript” option in every single one.
Anyway I find the use of these dialogs annoying which is why I turned them off completely in my browser (trivial to do in almost any browser - another reason for not using them in your page if you want people to see them). Now my browser simply ignores any alerts and automatically responds ok to any confirm dialogs without displaying anything - makes for a much better browsing experience particularly since confirm appears to be mostly used to try to stop you leaving a web page.
The HTML 5 spec contains a lot of obsolete commands simply because there are so many antiquated web pages out there that are still using that code instead of the more modern replacements. HTML such as <embed> and <iframe> were identified as obsolete in HTML 4 and were supposed to have been dropped from HTML 5 completely but because most pages have not yet replaced those tags with the more modern <object> tag those tags have been retained in HTML 5 even though it was advised back in 1997 that they would not be in HTML 5. Similarly since many people still write their JavaScript in a way that is appropriate for Netscape 4 rather than for modern browsers, that antiquated version of JavaScript continues to be supported (although the introduction of the “use strict” command a few years ago has allowed some of the antiquated commands to be dropped and will probably include dropping more commands in the future).
Come on, you know that’s not how it works. It’s not necessary to keep obsolete tags in HTML5 for compatibility. Older sites will continue to be served as previous versions of HTML (eg. HTML4) and won’t break for as long as browser makers continue to support those versions. The features that are obsolete in HTML5 are actually listed here, and are not part of the main spec. While the iframe tag may have be deprecated in XHTML1 strict mode, HTML5 actually adds new attributes to the tag, which indicates to me that the W3 still sees a use for it and so it’s still part of a current spec.
If you’d said this right off the bat, I’d have agreed with you wholeheartedly. Most of the time you probably don’t want to be using the built-in dialogs because, as you say, there are better alternatives. In my opinion, a good developer should know the tools available to him/her, even if most of the time there is not much use for certain ones.
That’s might be true for alert dialogs, but I wanted to mention what is pretty common behaviour in users is closing popups/modals/whatever without reading them, especially if they appear on page load rather than after a user action. No matter how useful to the user the popup content may be, users seem to assume it’s some kind of ad.
Close. It’s not that web pages are using them, but that browsers are still supporting them, and the specs need to describe what a user agent should do with them.
It was wrong to leave so much stuff working in browsers without anyone outside of that browser vendor knowing a One True Way to implement it. Leading to someone else reverse-engineering it (possibly badly) and the wild west is back. At the point of HTML5 specs, the idea was that implementations, whether recommended for vendors and authors or not, would be described in a specification.
True.
Most people overlook that the HTML 5 specification is aimed at browser creators to tell them how they should implement the commands.
What commands people should be using in their web pages is a subset of those commands. Unfortunately there is no official guide for how to write web pages - which is one of the reasons so many people still use antiquated tags such as <iframe> or <embed> instead of the more modern and more powerful <object> tag and other similar far more restrictive tags than the ones that they could be using. JavaScript comes a bit closer to achieving that by implementing the “use strict”; command that all new scripts should use and which has started disabling some of the commands that shouldn’t be used.
Unfortunately most people failed to understand when HTML 4 was released in 1997 that deprecated means obsolete now and about to be removed. They didn’t stop using those tags they were told to stop using and so removing them as was pre warned in 1997 would break too much of the web.
Well, as I tell my colleagues when we worry about something not working for a client, or we discover something crappy like <strike> tags in our code, I’ve taken to mentioning that since we’re not programming in Ada, the fact that our code is sh*tty and doesn’t adhere to standards won’t actually be killing any astronauts or doing (air) traffic control or anything…
or at least, that’s my attempt to deal with it.