SitePoint Sponsor

User Tag List

Results 1 to 16 of 16
  1. #1
    SitePoint Enthusiast
    Join Date
    Dec 2010
    Posts
    47
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    pros / cons of dom vs html

    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

  2. #2
    I meant that to happen silver trophybronze trophy Raffles's Avatar
    Join Date
    Sep 2005
    Location
    Tanzania
    Posts
    4,662
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Yes, you could load a blank page that just looks like this:

    HTML Code:
    <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.

  3. #3
    SitePoint Enthusiast
    Join Date
    Dec 2010
    Posts
    47
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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?

  4. #4
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,861
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    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.
    Stephen J Chapman

    javascriptexample.net, Book Reviews, follow me on Twitter
    HTML Help, CSS Help, JavaScript Help, PHP/mySQL Help, blog
    <input name="html5" type="text" required pattern="^$">

  5. #5
    SitePoint Enthusiast
    Join Date
    Dec 2010
    Posts
    47
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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?

  6. #6
    I meant that to happen silver trophybronze trophy Raffles's Avatar
    Join Date
    Sep 2005
    Location
    Tanzania
    Posts
    4,662
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    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.

  7. #7
    SitePoint Enthusiast
    Join Date
    Dec 2010
    Posts
    47
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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...)

  8. #8
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2006
    Location
    Augusta, Georgia, United States
    Posts
    4,182
    Mentioned
    16 Post(s)
    Tagged
    4 Thread(s)
    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.
    The only code I hate more than my own is everyone else's.

  9. #9
    SitePoint Enthusiast
    Join Date
    Dec 2010
    Posts
    47
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.

  10. #10
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,861
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by Raffles View Post
    Regarding having JS disabled, just search. Felgall's opinion is top of the list.
    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.
    Stephen J Chapman

    javascriptexample.net, Book Reviews, follow me on Twitter
    HTML Help, CSS Help, JavaScript Help, PHP/mySQL Help, blog
    <input name="html5" type="text" required pattern="^$">

  11. #11
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,861
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by jefals View Post
    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.

    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.
    Stephen J Chapman

    javascriptexample.net, Book Reviews, follow me on Twitter
    HTML Help, CSS Help, JavaScript Help, PHP/mySQL Help, blog
    <input name="html5" type="text" required pattern="^$">

  12. #12
    SitePoint Enthusiast
    Join Date
    Dec 2010
    Posts
    47
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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!

  13. #13
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2006
    Location
    Augusta, Georgia, United States
    Posts
    4,182
    Mentioned
    16 Post(s)
    Tagged
    4 Thread(s)
    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.
    The only code I hate more than my own is everyone else's.

  14. #14
    SitePoint Enthusiast
    Join Date
    Dec 2010
    Posts
    47
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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...
    1. Quicker response to the user
    2. Reduce the load on the server

    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.

  15. #15
    SitePoint Zealot
    Join Date
    Dec 2010
    Posts
    187
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.

  16. #16
    SitePoint Enthusiast
    Join Date
    Dec 2010
    Posts
    47
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks Furicane,

    I agree, and I think we have probably beat this poor horse to death!


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •