Loops in JavaScript are okay. JavaScript in loops is not okay.



  • Here's a representative snippet of the internal app driving an Important Ongoing Interactive Business Process that I'm gradually rewriting to support new business units. This is in HTML::Mason, which is sort of like PHP or .erb for Perl, and in many cases would be TRWTF. But today,
    data serialization/initialization is the name of the game.

             <script type="text/javascript">
             <% $js_releases_array_name |h %>[<% $id |n %>] = Array();
    %          for my $release (@associated_releases) {
                 <% $js_releases_array_name |h %>[<% $id |n %>].push('<% $release->{url} |n %>');
    %          }                                                                                                                                                                                                      
             </script>
    


  • In b4 "JavaScript is the real WTF".



  • Yes thank god for JSON... except wait, how is JSON going to print that output? Oh right, using loops. Just that they'll be buried in an implementation layer you don't see.
    Maybe this particular loop JS output isn't the best way to do it because it's a simple array that could be easily implemented through a JSON output, but having server-side loops writing JS (or JSON) is not inherently a problem.



    I suppose I'm really just arguing semantics. Since if you have a method to output JSON from any code object, you would clearly use that rather than do it yourself. But in the end, loops are still being run somewhere ;)



  • @fennec said:

    Here's a representative snippet of the internal app driving an Important Ongoing Interactive Business Process that I'm gradually rewriting to support new business units. This is in HTML::Mason, which is sort of like PHP or .erb for Perl, and in many cases would be TRWTF. But today,
    data serialization/initialization is the name of the game.

             <script type="text/javascript">
             <% $js_releases_array_name |h %>[<% $id |n %>] = Array();
    %          for my $release (@associated_releases) {
                 <% $js_releases_array_name |h %>[<% $id |n %>].push('<% $release->{url} |n %>');
    %          }                                                                                                                                                                                                      
             </script>
    

    Use a modern javascript framework like angular or knockout and do all this crap on the clientside.


  • Trolleybus Mechanic

    @fennec said:

    HTML::Mason
     

    I had to use HTML::Mason once. In 2005. For a class project. For a professor who loved useless libraries that no one would in their right mind ever used.

    And this, you say, is production code?

    ...

    oh.

    In all fairness, HTML::Mason was released in, what, 2002?  And XML didn't become a "teachable" buzzword until-- I dunno, asspull here-- 2005. JSON even later. So I'm not surprised that's how the original coder decided to send an array of strings to the client-side.  Seriously, if you discount XML/JSON/etc, how else would you do that? And if you say CSV: Keep in mind that, and again this may be me misremembering-- but mid-2000s, there wasn't what you would call reliable string-splitting methods for Javascript.


  • Considered Harmful

    @Lorne Kates said:

    @fennec said:

    HTML::Mason
     

    I had to use HTML::Mason once. In 2005. For a class project. For a professor who loved useless libraries that no one would in their right mind ever used.

    And this, you say, is production code?

    ...

    oh.

    In all fairness, HTML::Mason was released in, what, 2002?  And XML didn't become a "teachable" buzzword until-- I dunno, asspull here-- 2005. JSON even later. So I'm not surprised that's how the original coder decided to send an array of strings to the client-side.  Seriously, if you discount XML/JSON/etc, how else would you do that? And if you say CSV: Keep in mind that, and again this may be me misremembering-- but mid-2000s, there wasn't what you would call reliable string-splitting methods for Javascript.


    Why would you have to do it without JSON? Remember that JSON is just a subset of the original Javascript API that Douglas Crockford standardized into a format. It's always been a valid way to initialize an object in Javascript.



  • @DrPepper said:

    @fennec said:
    Here's a representative snippet of the internal app driving an Important Ongoing Interactive Business Process that I'm gradually rewriting to support new business units. This is in HTML::Mason, which is sort of like PHP or .erb for Perl, and in many cases would be TRWTF. But today,
    data serialization/initialization is the name of the game.

             <script type="text/javascript">
             <% $js_releases_array_name |h %>[<% $id |n %>] = Array();
    %          for my $release (@associated_releases) {
                 <% $js_releases_array_name |h %>[<% $id |n %>].push('<% $release->{url} |n %>');
    %          }                                                                                                                                                                                                      
             </script>
    

    Use a modern javascript framework like angular or knockout and do all this crap on the clientside.

    Yeah, even vanilla handlebars templates would be better than this.



  • @Lorne Kates said:

    In all fairness, HTML::Mason was released in, what, 2002?  And XML didn't become a "teachable" buzzword until-- I dunno, asspull here-- 2005. JSON even later.

    XML was pretty much popularized by .NET which came out in 2000. So by 2002 XML would have been fairly well entrenched, at least in the .NET community.


  • Trolleybus Mechanic

    @Soviut said:

    @Lorne Kates said:
    In all fairness, HTML::Mason was released in, what, 2002?  And XML didn't become a "teachable" buzzword until-- I dunno, asspull here-- 2005. JSON even later.

    XML was pretty much popularized by .NET which came out in 2000. So by 2002 XML would have been fairly well entrenched, at least in the .NET community.

    HTML::Mason is a Perl plugin.  XML may be too modern for a Perl coder.  Fuck, the concept of the year 2000 itself may be too modern for a Perl coder.


  • Discourse touched me in a no-no place

    @Lorne Kates said:

    Fuck, the concept of the year 2000 itself may be too modern for a Perl coder.
    Remember! Add 1900 or take the value mod 100 before printing the year.



  • @Lorne Kates said:

    HTML::Mason is a Perl plugin.  XML may be too modern for a Perl coder.  Fuck, the concept of the year 2000 itself may be too modern for a Perl coder.

    I seem to be out of the loop here since I'm still using Mason. (There's a Mason2 around nowadays though.) I find that it handles the 'V' and 'C' parts of MVC just fine and with decent separation.

    So please tell me what's wrong with it? (And please don't use a lame cop-out such as 'it uses Perl')



  • @fennec said:

    This is in HTML::Mason, which is sort of like PHP or .erb for Perl, and in many cases would be TRWTF.

    HTML::Mason is an order of magnitude more capable than PHP. PHP does not even have loops over template parts nor formal parameters for subtemplates and a lot of other useful stuff of HTML::Mason. Sure, Genshi is hard to beat (it's templates are XML/XHTML, can contain placeholder text for direct preview and guarantee well-formed output), but HTML::Mason is certainly not a WTF.



  • @fennec said:

             <script type="text/javascript">
             <% $js_releases_array_name |h %>[<% $id |n %>] = Array();
    %          for my $release (@associated_releases) {
                 <% $js_releases_array_name |h %>[<% $id |n %>].push('<% $release->{url} |n %>');
    %          }                                                                                                                                                                                                      
             </script>
    I can tell what the output code looks like, but I'm curious over what |h and |n do.

    @joe.edwards said:

    Remember that JSON is just a subset of the original Javascript API that Douglas Crockford standardized into a format.
    I'll never forgive him for having taken comments out of the format grammar, no matter what the rationale was.




  • @Zecc said:

    I can tell what the output code looks like, but I'm curious over what |h and |n do.

    | h does HTML-escaping, | u does URL escaping (those %25 thingies) and | n turns off default escaping if someone has configured it. The code seems to be missing escaping suitable for javascript strings and will blow up if there's an apostrophe in the URLs.



  • Another RWTF is that the array name is soft-coded.



  • @Soviut said:

    @Lorne Kates said:
    In all fairness, HTML::Mason was released in, what, 2002?  And XML didn't become a "teachable" buzzword until-- I dunno, asspull here-- 2005. JSON even later.

    XML was pretty much popularized by .NET which came out in 2000. So by 2002 XML would have been fairly well entrenched, at least in the .NET community.

     

    If .NET came out in 2000, why didn't Visual Studio.NET come out until 2002?  Then again, Microsoft tries to pretend that version (which used .NET 1.0) never existed and that .NET came around in Visual Studio .NET 2003 (which used .NET 1.1).


Log in to reply