Hi folks,
Just learning a little about DOM now, and coming to the realization that, apparantly, if you wanted, you could create the entire web site with dom, and don’t really need any straight html…
My first question: Am I right about that?
Then, if that’s true, What’s the best way? What, if anything, are the advantages and/or disadvantages of doing it one way vs. the other?
Thanks,
Jeff S
Yes, you could load a blank page that just looks like this:
<script src="script.js"></script>
and create all the elements on the page. But what’s the point? You might as well put the HTML elements in there to start with.
Also, it would mean that users with JS disabled, and search engines, would not be able to view your content. Also, it would make the page load slower and make maintenance a nightmare.
The only reason you would want to do this is as a proof of concept, but nobody would be impressed nowadays.
ok, thanks Raffles. I understand each of your points except “it would make maintenance a nightmare”…why is that? You’d be doing the maintenance to the javascript code rather than an html page, but why would one be harder than the other?
Somewhere between 5 and 10% of people have JavaScript turned off or use a web reader that doesn’t support JavaScript. What do you expect those people to see/hear? To be accessible to all web pages need to work without JavaScript.
Yes, I agree. I guess if someone built their site entirely with javascript, then those folks that have it disabled would get a message telling them that they need to enable it in order to view the site…
but, now you’ve peaked my curiosity again; If you have the option of having javascript enabled, why would you disable it?
You’d be doing the maintenance to the javascript code rather than an html page, but why would one be harder than the other?
Simply because it’s harder to find things than in an HTML document tree, especially nowadays with things like Firebug, you need to do a lot more typing and the potential for bugs is much larger.
I think if you think about it you’ll realise it would be a lot more time-consuming.
Regarding having JS disabled, just search. Felgall’s opinion is top of the list.
Thanks again, Raffles,
So far, I don’t have enough experience yet with either html or javascript to really know on my own which one is more difficult to maintain. So I’ll just take your word for the time being on that. But you did confuse me a little; I’m using Firebug in my javascript exercises, and it seems to point right to where my problems are – but are you saying it’s more difficult with firebug?
And thanks for the link re. why people disable js. It appears that folks disable js due to misconceptions re. security issues, or to prevent popups or things happening after the page loads…( I notice sometimes, when I’m composing or replying to google e-mails, that the browser hangs – now I’m wondering if it’s due to something js is doing behind the scenes…)
The only time it is suitable to make function completely dependent on JavaScript is when its a an absolute that the user(s) will have JavaScript turned on or its a requirement outlined in the spec that has been approved by the client. In most cases it will only ever be appropriate to use the approach for regulated areas, where a known number of people will be able to access such as an admin section. However, the front-end of a web site should never be developed in a away that makes core functionality dependent on JavaScript for the reasons mentioned. That said, I’m generally not a proponent on anything being dependent on JavaScript regardless of admin regulated areas. However, I can definitely understand the need to make core functionality dependent on JavaScript for admin areas and what not that are isolated from the general public.
Yes, I think I’ve got that point now, Oddz. Thanks!
Re. why people might disable JS, I’ve just gone a little further in my studies, and come across an example where js is controlling the number of items you are allowed to order, and by disabling js, the client is attempting to get around that restriction. Of course I know this should be caught by the server. But this is opens my eyes to another explanation why people might want to disable JS.
Note that my article at the top of that list is about the situations where people mistakenly disable JavaScript where doing so doesn’t really achieve what they intended by doing so.
There are also a lot of legitimate reasons for some people to have JavaScript disabled.
That comes down to the purpose of validation in JavaScript vs validation on the server. JavaScript validation is there for the convenience of the visitor. It allows them to correct their errors before the form gets submitted to the server. Those without JavaScript have to submit the form and then find out if they filled it out correctly.
All the actual validations on what is or isn’t allowed in given fields must be done on the server as that is where the site owner’s validation takes place.
The only time turning off JavaScript to bypass validation will work is where the validation has not been implemented correctly on the server.
The only time turning off JavaScript to bypass validation will work is where the validation has not been implemented correctly on the server.
Yes, I’ve got that, Stephen. Thanks!
If anything JavaScript validation is more so aesthetic, to achieve a design/usability goal than it is functional. All validation should be handled at the server level, not client.
Well, Oddz, wouldn’t you say that you should do it at both client and server where practical?
For instance, isn’t is true that a couple of reasons for client side programming are…
And, with those things in mind, then, isn’t it true that when you do whatever validation you can on the client, ( like checking required fields have something in them, or checking boundaries for numeric entries), doesn’t this contribute towards both of those things? Suppose a dollar value should be greater than 4.99 and less than 44.99. I do realize now the need for validating – or RE-validating this on the server; but, if you initially check it on the client, isn’t that going to serve the first goal I mentioned?
I have to admit, I don’t see, now, where JS is going to reduce the load on the server – at least in the area of validation – since you’re going to be validating everything on the server anyway. I guess, if part of the benefit of JS is that it does reduce the load on the server, then it must do this in other ways besides validation.
I think you two are talking about same thing, but are having problems wording it
All validation should be handled server side, once the form is actually submitted for some sort of database-insertion.
If available, JS should / could be used to notify users of common errors so they don’t have to wait for the page to reload and notify them about errors and what not (re-enter captcha, that’s the most annoying thing if you ask me).
So things such as “agree to terms of use” and so on can be implemented on client side (and many more) but before the whole thing goes to the DB it MUST be revalidated to ensure the data integrity, which is server side.
Thanks Furicane,
I agree, and I think we have probably beat this poor horse to death! 