georga — 2014-04-03T08:49:10-04:00 — #1
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 ?
fretburner — 2014-04-03T11:26:08-04:00 — #2
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.
felgall — 2014-04-03T14:40:36-04:00 — #3
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.
fretburner — 2014-04-04T08:17:31-04:00 — #4
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:
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.
mittineague — 2014-04-04T12:25:36-04:00 — #5
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.
stomme_poes — 2014-04-04T12:57:05-04:00 — #6
felgall — 2014-04-04T17:15:14-04:00 — #7
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.
fretburner — 2014-04-04T18:11:47-04:00 — #8
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.
felgall — 2014-04-04T20:37:26-04:00 — #9
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.
fretburner — 2014-04-06T08:23:25-04:00 — #10
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.
stomme_poes — 2014-04-07T14:39:16-04:00 — #11
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.
felgall — 2014-04-07T15:10:30-04:00 — #12
Most people overlook that the HTML 5 specification is aimed at browser creators to tell them how they should implement the commands.
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.
stomme_poes — 2014-04-07T15:17:56-04:00 — #13
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.