Yet more VBScript Fun: Subroutines and By Reference



  • Actually, I'm not 100% certain this is a WTF, but it sure seems like one to me

    In a lot of places in the current codebase, I see things like this:

    Call SomeSub(pSomeVar, pAnotherVar, pYetAnotherVar)

    If pSomeVar = Something Then

      ' Stuff

    Else

      ' Do other stuff

    End If

    pAnotherVar = SomethingElse

    And then SomeSub is declared thusly:

    Sub SomeSub(pSomeVar, pAnotherVar, pYetAnotherVar)

      If Stuff Then

         pSomeVar = SomeResult

         pAnotherVar = AnotherResult

      Else

        pSomeVar = DifferentResult

        pAnotherVar = DifferentResult

      End If

    End Sub 

     

    I have never, in several years of programming, seen anything remotely like this, where you give a routine what amounts to all ref/out parameters; I've seen some cases where out params are used, but never for the entire routine.  Ironically, I actually see the use of writing something like this, because several of the methods return multiple results (which is probably a WTF in and of itself), so if you used a function you would need several instead of only one. However, the main reason I think it's WTFy is because there's no indication about it - the calling code passes the exact same variables to it that it uses in the following line, leaving you to wonder "W[here]TF is this value coming from?"  And, of course, since there's no Option Explicit the variables are just globally set in God knows where, so they're visible to everyone and everything.



  • That certainly looks like the "Well, I'm not sure how or why this works, but fuck it, it's working!" style of coding. 



  • @ObiWayneKenobi said:

    I have never, in several years of programming, seen anything remotely like this, where you give a routine what amounts to all ref/out parameters; I've seen some cases where out params are used, but never for the entire routine.  Ironically, I actually see the use of writing something like this, because several of the methods return multiple results (which is probably a WTF in and of itself), so if you used a function you would need several instead of only one. However, the main reason I think it's WTFy is because there's no indication about it - the calling code passes the exact same variables to it that it uses in the following line, leaving you to wonder "W[here]TF is this value coming from?"  And, of course, since there's no Option Explicit the variables are just globally set in God knows where, so they're visible to everyone and everything.

     

    There's nothing wrong in principle with a function that returns results consisting of multiple elementary typed data items; such collections are commonly known as "records".  But the proper way to do it would have been to bundle all those parameters up as properties/members of some class of object, and pass in to or return from the function one of those objects.



  • @DaveK said:

    There's nothing wrong in principle with a function that returns results consisting of multiple elementary typed data items; such collections are commonly known as "records".  But the proper way to do it would have been to bundle all those parameters up as properties/members of some class of object, and pass in to or return from the function one of those objects.

    True, but this is VBScript, where the class implementation is sketchy at best, and nonexistant at worst. This code doesn't use classes at all - everything is global functions. 

    Another thing I noticed is the old programmer used Dreamweaver for a lot of the HTML layouts, so a lot of them use divs within divs within divs within divs (which isn't that bad) and absolute positioning for most everything (which is that bad).  And, of course, no indentation really.  Ironically the page I'm working on now has an XHTML doctype, but uses CAPS for some tags, and uses deprecated things like <font>.  I really am starting to think this guy had no fucking clue what he was doing.

    Geez.. I know a lot of people think rewrites are bad and should be avoided, but I'm beginning to wonder... 



  • @ObiWayneKenobi said:

    Ironically the page I'm working on now has an XHTML doctype, but uses CAPS for some tags, and uses deprecated things like <font>.

    Switch it to HTML 4.01 strict.  XHTML isn't usable anyway. 



  • Depending on how old the original software was could explain things.  I knew a big handful of vb programmers who had no idea that you could even use classes in vb, and when you told them about them, they discouraged the idea (mainly because its different than what they know and think they know all there is because they were in the field x years...).   They need a T-Rex mask to wear to work. 

     As far as the html, it wouldn't be too bad if the html is generated. If they were using a WYSIWYG editor, most of them produce unindented source anyway.



  • @morbiuswilters said:

    Switch it to HTML 4.01 strict.  XHTML isn't usable anyway. 

     

    I actually did that.  I'm not really rewriting the page, but am refactoring it a lot to use decent variable names, indentation, etc.  

    Also, I think this code was from 2005 or so, maybe 2004. Young enough that, if this guy was a real programmer, he would know what he's talking about instead of hacking together shit.  Although a lot of it is based off of an open-source product called Comersus Sophistocated Cart, which I think has been around for many years and claim to be one of the best e-commerce apps out there, used by companies like Disney and Volvo, so that might be why the code is so terrible.  From what I have seen, the old programmer evidently picked up a lot of his habits from the Comersus code, since he tried to emulate it in custom-written modules (more proof he didn't know wtf he was doing - cargo cult programming at it's best)



  • Slightly OT. I went looking around at Comersus to see what you're talking about. Google search for "Comersus code", this thread is hit #5.

    Google works fast! 



  • @JamesKilton said:

    Google works fast! 
     

    Nah, it only appears that way because Google hangs around waiting for Spectate posts.... it is as fascinated with the flaming failure of a retard just as much as we are....

     


  • Considered Harmful

    @morbiuswilters said:

    @ObiWayneKenobi said:

    Ironically the page I'm working on now has an XHTML doctype, but uses CAPS for some tags, and uses deprecated things like <font>.

    Switch it to HTML 4.01 strict.  XHTML isn't usable anyway. 

    XHTML is not usable? Uh oh, looks like I have to go port the past 50 websites or so I developed to HTML!

    XHTML is wonderful, if you know how to keep styles out of your markup and in your CSS.



  • Interestingly enough, I downloaded the free version of the shopping cart program, "Comersus" to see if it was just this lame-ass developer.  Nope, the entire Comersus code itself is written in this style, with barely any indentation and lots of "rsTemp, rtemp2, rtmp3, rstmp4" variables for getting things to the database.  

    Which really leads me to believe the developer had absolutely zero idea of how to write ASP, and was just copying/pasting what he saw Comersus do already.  And yet the company kept this guy around for several years.   Maybe I should submit the story to the main page.



  • @morbiuswilters said:

    XHTML is not usable? Uh oh, looks like I have to go port the past 50 websites or so I developed to HTML!

    XHTML is wonderful, if you know how to keep styles out of your markup and in your CSS.

     

    (Hope I'm quoting the right person) 

    XHTML is not usable as a general purpose markup language for web design, mostly due to IE's broken handling.

    Short story: IE requires XHTML to be served with an html mime-type.  This puts IE into "quirks-mode" and turns on the tag-soup browser, which manages to mostly extract usable HTML, but cancels out most of the positive benefits of using XHTML.

    In addition, in-line Javascript requires being wrapped in a CDATA construct, as well as the unary -- operator causing its own set of grief.

    See Sending XHTML as text/html Considered Harmful for a much more detailed explanation.   I really don't understand WHY people insist upon trying to use XHTML before the world (and User Agents) are truly ready for it.



  • @r3jjs said:

    Short story: IE requires XHTML to be served with an html mime-type.  This
    puts IE into "quirks-mode" and turns on the tag-soup browser, which manages to
    mostly extract usable HTML, but cancels out most of the positive benefits of
    using XHTML.

    You still can serve it as text/html to IE and as application/xhtml+xml to everyone else.

    @r3jjs said:

    I really don't understand WHY people insist upon trying to use XHTML before the
    world (and User Agents) are truly ready for it.

    Because if we don't use it, then UA developers won't be bothered to support it. Someone has to do the first step.


  • Garbage Person

    @Spectre said:

    You still can serve it as text/html to IE and as application/xhtml+xml to everyone else.

    Thoughts on how to do that? My Apache.conf-foo is weak, but I don't seem to recall anything that might possibly let you serve different MIME types to different user agents.

    Which leaves us with either some oddball plugin, or writing our own HTTPD.



  • Personally, I only use XHTML when I know I'm on a project where we need, say, an XSL transform or funky XPath navigation of the resulting document to work correctly. But, off the top of my head, we've got:

    ASP/VBScript:

    Response.ContentType = "application/xhtml+xml"

     PHP:

    header("Content-Type: application/xhtml+xml");

    Java:

    response.setContentType("application/xhtml+xml");

    If you were intent on doing this without a scripting engine, Apache negotiates content type in [url="http://httpd.apache.org/docs/2.0/mod/mod_negotiation.html"]mod_negotiation[/url].

    You might also be interested in Alan Flavell's [url="http://web.archive.org/web/20040611103722/http://ppewww.ph.gla.ac.uk/~flavell/www/lang-neg.html"]Language Negotiation Notes[/url], a subset of which applies to you. In general, it looks like you may want to have a landing page that detects the browser type, and subdivide the site using MultiViews for pages that might be going to unsupported browsers.



  • @Weng said:

    @Spectre said:
    You still can serve it as text/html to IE and as application/xhtml+xml to everyone else.

    Thoughts on how to do that? My Apache.conf-foo is weak, but I don't seem to recall anything that might possibly let you serve different MIME types to different user agents.

    Which leaves us with either some oddball plugin, or writing our own HTTPD.

    I was attempting to do that a while ago, not by user agent, but by the contents of the HTTP-ACCEPT header. I never quite got it working (I think the only problem was that the implied index pages didn't work. site.com/index.html was fine, but site.com/ failed.), but here it is if you want the general idea:

    # serve up the appropriate type
    # (look for the type, followed by possibly other types, then a semicolon, then make sure the priority is greater than 0)
    RewriteCond %{HTTP_ACCEPT} application/xhtml\+xml[^;]*;\s*(q=[^0])? [NC]
    RewriteRule ^(.+/|.+\.html|.{0})$ - "[T=application/xhtml+xml; charset=UTF-8,L]"

    As to why I would want to do this, there's no real reason other than bragging rights. As far as I know, the only major difference in XHTML is that you can't do document.write() in Javascript.



  • @joe.edwards said:

    XHTML is not usable? Uh oh, looks like I have to go port the past 50 websites or so I developed to HTML!

    Yeah, you probably should, because it sounds like you don't know anything about the difference between XHTML and HTML other than "XHTML is t3h b3ttar!"  You are probably just serving up the content wrong which means it's getting parsed as tag-soup HTML.

     

    @joe.edwards said:

    XHTML is wonderful, if you know how to keep styles out of your markup and in your CSS.

    This has nothing to do with XHTML.  CSS has been around long before XHTML.  The only significant difference for most people is that XHTML is parsed as XML.  Since most people don't know how to use it right, the end up serving poorly-written HTML, though, which is what I imagine you are doing. 



  • @Spectre said:

    You still can serve it as text/html to IE and as application/xhtml+xml to everyone else.

    Oh, yeah, it's really that simple!  Remember to swap out your doctype, too!  And be sure you remove the terminating slash for single-tag elements!  And don't encode those entities or you'll end up with garbage all over the page!  And remove the CDATA wrappers for your Javascript!

     

    At the end of the day, you can create two completely separate versions of the same site or you can just use HTML 4.01 strict.  I sincerely doubt you need any of the features that are specific to XHTML. 



  • Just to get back on track to the VBScript, I noticed something else interesting with this "Comersus code".  Not only is it chock-full of On Error Resume Next, and these weird byRef subroutines, but I just discovered that the database functions will give up an error UNLESS you use the same cryptic variable names (connTemp, rsTemp, mySQL) - I changed it to connection, rs, and sql and I got an error stating that some arguments were invalid in some part of the "DatabaseFunctions.asp" include file.  The line in question follows:

     

       rsTemp.open mySQL, connTemp    

    So evidently, from what I can translate, the database code checks that you *must* have a variable called "connTemp", because it uses the object in your calling code (which isn't as WTFy as it sounds given that include files just dump all of their code into the "main" page, anyway).  How this program can sell tons and be used by companies like Disney, UCLA, CreativeLabs and others is beyond me (of course, I don't really believe that).  The guy who wrote this code must have either been an amateur, a hack, or drunk on something because that's how bad it is. 



  • @morbiuswilters said:

    Oh, yeah, it's really that simple!  Remember to swap out your doctype, too!

    I wasn't talking about converting XHTML into HTML. As far as my understanding goes, IE can mostly eat XHTML if it's served as text/html. If it can't, well, I withdraw.



  • @Spectre said:

    I wasn't talking about converting XHTML into HTML. As far as my understanding goes, IE can mostly eat XHTML if it's served as text/html. If it can't, well, I withdraw.

    It can usually handle XHTML because it just assumes it's poorly-formatted HTML.  One problem is with entities that need to be encoded in XHTML but not necessarily in HTML.  Basically, it's really a nightmare to make a valid XHTML page that renders the same as HTML in IE.  Additionally, if you are making it render in IE you aren't even using any of the features of XHTML which means you should just be using HTML to begin with. 



  • There's more than one version of XHTML, you know. I think 1.2 is the only version that requires a different Content-type. There's probably millions of pages that are valid XHTML, but are served as text/html and those work just fine.



  • @Cap'n Steve said:

    XHTML 1.2

    LOLWUT?



  • @Cap'n Steve said:

    There's more than one version of XHTML, you know. I think 1.2 is the only version that requires a different Content-type. There's probably millions of pages that are valid XHTML, but are served as text/html and those work just fine.

    XHTML 1.0 can be served as text/html, but because there are no truly native XHTML UAs in wide use, they will interpret anything served as text/html as HTML.  So once again, standards Nazis, it doesn't matter what the hell the spec says, what matters is the end result.  Anything not served with an XML mime type will be handled as HTML tag soup by web browsers.  And no, a shocking number of the "XHTML" docs served as text/html DO NOT meet the standard for well-formatted XML.  The vast majority of web developers don't seem to know this and go about evangelizing XHTML because "HTML is bad".  Even though they are serving up something that technically isn't valid XHTML or HTML.  And even though they are not taking advantage of a single XHTML feature that doesn't exist in HTML.



  • There are some benefits. Firefox 2.0 (at least) will switch parsers if you enable a proper XHTML, and uses an XML parser instead. The page will figuratively blow up, and is entirely unusable if an XML parser can't understand the document. The downside to this is it requires a lot of work to make sure the page is very compliant. The upside is that it does parse and render faster.



    Now, before you guys start spouting off "oh quad core this" and "HTML is so small that", do remember that every millisecond does effect the user's perspective of the site. Most people don't think they notice, but if you're trying to sell your design services to a client, a faster rendering (coupled additionally with a near-zero latency backend!) can be the extra edge in getting the job.



  • @insta said:

    There are some benefits. Firefox 2.0 (at least) will switch parsers if you enable a proper XHTML, and uses an XML parser instead. The page will figuratively blow up, and is entirely unusable if an XML parser can't understand the document. The downside to this is it requires a lot of work to make sure the page is very compliant. The upside is that it does parse and render faster.

    Now, before you guys start spouting off "oh quad core this" and "HTML is so small that", do remember that every millisecond does effect the user's perspective of the site. Most people don't think they notice, but if you're trying to sell your design services to a client, a faster rendering (coupled additionally with a near-zero latency backend!) can be the extra edge in getting the job.

    Opera and Safari also parse as XML with the right content-type.  Unfortunately most pages are served incorrectly and render as tag soup.  Speed is probably the last benefit I would concern myself with.  HTML parsing is not going to be a bottle neck, it's going to be external resources, style handling, Javascript and if the page is dynamic, whatever magic is generating the content.  Seriously, the difference between parsing HTML and XML is negligable when all of the other factors are considered.

     

    There are still come benefits to using XHTML, though.  You can embed other XML documents directly into a page, which is cool, but not a feature 99.9% of XHTML evangelists actually use.  You can write HTML 4.01 strict that looks just as clean as XHTML.  I don't need an XML parser to teach me disciplined coding practices.  And you can still make a mess of an XHTML page that is perfect XML.  It's the static-vs-dynamic typing argument all over again.  Strict machine checking can only validate so much and cannot tell you if you are doing the right thing to begin with.


  • Considered Harmful

    Okay. I've let this thread simmer for a while.

    First off, I do know all about the differences between XHTML and HTML and yes, I do manage to get the proper rendering in all browsers we support and test with (IE6, IE7, IE8 beta 1, Firefox 2, Firefox 3 beta, latest version of Opera, latest version of Safari.) My code is valid and the only browser I have to jump hoops for is IE6, because of a few well known CSS bugs.

    My preferred method of choosing the mime type is to check the Accept header sent in the request. If application/xhtml+xml is in there, I know the browser can support XHTML; if not, I serve it text/html. I've encountered exactly zero issues with this on all browsers we test with.

    The reason I mention separating style into CSS is that XHTML has gone ahead and thrown most style attributes right out the window. This, I feel, is a huge step in the right direction. I also love that it forces conformity in markup. Lowercase-only? Great. Requires quotation marks for all attributes? Great. Requires a closing tag for every element? Great. Got rid of all that shorttag nonsense? Great. All of this makes my job as a developer easier (not harder).

    I've read all the advisories about XHTML not being useful and not a good idea, and I respectfully disagree. I've used it in many places, for a wide variety of (high traffic) websites and it's given me no problems at all.

    The fact that XHTML is valid XML also means I can embed XHTML snippets inside an XML document, which has proven useful on several occasions for AJAXy stuff.

    You can disagree all you want to, but I can and do use XHTML professionally every day, and I'm not going to stop any time soon. Tag soup makes me nauseous. Even if I couldn't get IE to render in standards mode (though, yes, in fact, I can), I'm definitely not going to let Microsoft tell me the world isn't ready.



  • @joe.edwards said:

    Okay. I've let this thread simmer for a while.

    Yeah, I think it's a bit overcooked.

     

    @joe.edwards said:

    I've encountered exactly zero issues with this on all browsers we test with.

    Still not standards-compliant.  Either you are serving up incorrect XHTML or incorrect HTML.

     

    @joe.edwards said:

    The reason I mention separating style into CSS is that XHTML has gone ahead and thrown most style attributes right out the window. This, I feel, is a huge step in the right direction. I also love that it forces conformity in markup. Lowercase-only? Great. Requires quotation marks for all attributes? Great. Requires a closing tag for every element? Great. Got rid of all that shorttag nonsense? Great. All of this makes my job as a developer easier (not harder).

     


    HTML lets you do all of this, too.  If you're the type who requires the parser to enforce standards, you're probably in trouble already.  It's like people who think the compiler catches their errors -- well-formed is not equivalent to good.

     

    @joe.edwards said:

    The fact that XHTML is valid XML also means I can embed XHTML snippets inside an XML document, which has proven useful on several occasions for AJAXy stuff.

    Then you are in the <1% who are actually using XHTML because they need to and not out of some misguided sense of "standards compliancy".



  • @joe.edwards said:

    My code is valid and the only browser I have to jump hoops for is IE6, because of a few well known CSS bugs.
     

    Of course - but you can't really expect anything else from IE6. (Hopefully, you're using conditional comments, and not CSS hacks.)

    My preferred method of choosing the mime type is to check the Accept header sent in the request. If application/xhtml+xml is in there, I know the browser can support XHTML; if not, I serve it text/html. I've encountered exactly zero issues with this on all browsers we test with.

    That's because you don't follow the standard - but to be fair, IE's */* means you can't.

    The reason I mention separating style into CSS is that XHTML has gone ahead and thrown most style attributes right out the window. This, I feel, is a huge step in the right direction. I also love that it forces conformity in markup. Lowercase-only? Great. Requires quotation marks for all attributes? Great. Requires a closing tag for every element? Great. Got rid of all that shorttag nonsense? Great. All of this makes my job as a developer easier (not harder).
     

    If it makes it easier, odds are you're doing it wrong. XHTML 1.0 is, essentially, HTML + />. For XHTML 1.1, odds are you're not using anything XHTML-specific anyway, so you STILL end up with HTML + />.

    I'll accept that it doesn't become harder, but I fail to see what prevents you from coding in the exact same way for HTML (only sans />).

    I've read all the advisories about XHTML not being useful and not a good idea, and I respectfully disagree. I've used it in many places, for a wide variety of (high traffic) websites and it's given me no problems at all.

    Something useless doesn't have to cause problems, nor do bad ideas (they tend to, but they don't HAVE to).

    The fact that XHTML is valid XML also means I can embed XHTML snippets inside an XML document, which has proven useful on several occasions for AJAXy stuff.

    So does that mean you used .innerHTML (which is COMPLETELY wrong for XHTML)? The proper way to go about it is using DOM scripting, usually (but not necessarily) coupled with JSON to save on space/bandwidth - then it doesn't matter if you're using HTML or XHTML.

    In my opinion, only three things are added by XHTML to make switching useful in some cases (sure, there may be other stuff that's cool, but actual use cases seem fairly theoretical to me).

    The first one is in-line MathML. The audience is fairly limited, granted, but it could be particularly useful for a place like Wikipedia.

    The second one is Ruby text (not to be confused with the programming language). This has a much wider audience - not only for furigana in Japanese text, but for other uses as well - but only a single browser supports it out of the box, namely IE. Furthermore, it doesn't look like any other browsers plan to support it any time soon (Firefox has had a ticket for this since 2000, still unresolved!) - and since IE supports <ruby> all the way down to HTML 3.2 (MS proposed it as an addition to that standard), that's a case where I'm willing to live with the W3 validator bitching at me for using something officially not available until XHTML 1.1 (and this although I actually CARE about validation).

    The third one is that it allows XML parsing of the document, but this is mainly useful for mobile devices. The speed difference is neglible on a regular PC.

    Tag soup makes me nauseous.

    As morbiuswilters (and I) pointed out, HTML is only tag soup if you make it as tag soup.

    Even if I couldn't get IE to render in standards mode (though, yes, in fact, I can), I'm definitely not going to let Microsoft tell me the world isn't ready.

    It's not just Microsoft that's saying that - the world ISN'T ready. This is a fact, and no, it won't change even if every person in the world magically decided to use Firefox or Safari or Opera. No browser supports XHTML properly without allowing nasty things that should only work in HTML.



  • @Pidgeot said:

    So does that mean you used .innerHTML (which is COMPLETELY wrong for XHTML)?

    This is another big one for me.  I use innerHTML for all dynamic "AJAX" content because it renders much faster than DOM.  It also requires almost no Javascript, especially not the ridiculously bloated DOM syntax, and it let's me re-use the same server-side code to handle rendering for the main page and for the dynamic content. 



  • @ObiWayneKenobi said:

    I have never, in several years of programming, seen anything remotely like this, where you give a routine what amounts to all ref/out parameters;
     

    Maybe I'm missing something here, but this looks very similiar to the win32 API calls. Lots of the functions take multiple pointers that point to various structs depending on what this or that parameter is, and may or may not contain a valid value based on the return value or another by-ref value. It's a whole mess of insanity and backward compatibility mixed together. Perhaps someone was inspired by that and decided it had to be an industry 'best practice.'

     



  • That greatly depends on the method - but DOM scales way better with more content (in fact, more content can make it faster). The benchmark tests on quirksmode.org don't deal with a very realistic scenario, so it's not as useful - a more true-to-life test should show you that.

    Nevertheless, my point was that innerHTML isn't valid for XHTML (or HTML, for that matter) - the formalized way is using DOM.



  • @ObiWayneKenobi said:

    since there's no Option Explicit the variables are just globally set in God knows where, so they're visible to everyone and everything.
     

    If they aren't explicitly declared public then they are local scope.



  • @Pidgeot said:

    That greatly depends on the method - but DOM scales way better with more content (in fact, more content can make it faster).

    How do you figure?  DOM is always way slower than relying on the parsing engine.

     

    @Pidgeot said:

    Nevertheless, my point was that innerHTML isn't valid for XHTML (or HTML, for that matter) - the formalized way is using DOM.

    Perhaps I wasn't clear here: I know innerHTML isn't valid for XHTML, which is why it's a big deal for me and yet another reason to stick with HTML. 



  • @morbiuswilters said:

    @Pidgeot said:

    That greatly depends on the method - but DOM scales way better with more content (in fact, more content can make it faster).

    How do you figure?  DOM is always way slower than relying on the parsing engine.

    Two tests that inserts HTML with this structure into a document (repeated 1000 times to time properly):

    <p><strong>content</strong></p>
    <div>content<span>content</span>content</div>
    <em>content</em>

    using 4 different methods (from left-to-right, innerHTML when generating with a string, innerHTML by joining an array, DOM by adding each element to one big element, then swapping it with another, and finally DOM where the HTML struture is made first, and text content then inserted afterwards.

    http://dengodekode.dk/artikler/DOM/xmp/innerhtml_xmp_3.html inserts 22 characters worth of text.

    http://dengodekode.dk/artikler/DOM/xmp/innerhtml_xmp_4.html inserts 4105 characters worth of text.

    Simply click the TEST buttons to try it out. While you may not find that DOM is quicker than innerHTML on either, it should be quicker for the long text compared to the short text

    The complete test description can be read at http://dengodekode.dk/artikler/DOM/no_innerhtml.php, but seeing as how it's in Danish, it's probably of little use to you guys.

    (No, I'm not the one who wrote those tests, but I know this guy well enough to know he knows his stuff.)

    @morbiuswilters said:

    @Pidgeot said:

    Nevertheless, my point was that innerHTML isn't valid for XHTML (or HTML, for that matter) - the formalized way is using DOM.

    Perhaps I wasn't clear here: I know innerHTML isn't valid for XHTML, which is why it's a big deal for me and yet another reason to stick with HTML. 

    I wasn't sure whether you were arguing against innerHTML in general, or in conjunction with XHTML, but I decided to clarify. I had a feeling it was the latter, so no problem.



  • In VB you pass variables wither ByRef or ByVal.  You can explicitly state it (ByVal SomeVar as Integer) if you want.  The default is ByRef, which means if the variable is changed in the subroutine it also changed in the calling subroutine.  



  • @Salami said:

    In VB you pass variables wither ByRef or ByVal.  You can explicitly state it (ByVal SomeVar as Integer) if you want.  The default is ByRef, which means if the variable is changed in the subroutine it also changed in the calling subroutine.  

    Correction: this was the behavior of old VB. Post-.NET VB defaults to ByVal, probably because it's saner.



  • @Pidgeot said:

    Two tests that inserts HTML with this structure into a document (repeated 1000 times to time properly):

    I can't really comment much on the tests because I don't understand most of what the page is saying.  I did try running both of the tests though and innerHTML was about 7 times faster than DOM for both tests.  I am running FF2 on Linux.  Additionally, you can gain significant performance increases in DHTML speed by creating one new element with DOM but not appending it to the page, setting the innerHTML in it and then replacing another node on the page with the new node.  This is because normally every time the HTML parser creates a new DOM node it has to refresh the display so the replace method allows the browser to render the entire DOM structure for the HTML and then update the rendered view only once.

     

    If DOM truly was faster than HTML parsing, it would be faster to construct a page using JS than HTML and I don't think you are going to find too many people arguing that point.  The actual parsing of the HTML results in the same data structure as using DOM from JS but it's all done in native code instead of passing control between the browser and the JS interpreter. 


Log in to reply