Ember.js woes. And it's not even about Discourse



  • I was about to push to production, when I notice ember 1.9 is out. I figure I'll be Johnny on the spot and update right away.

    • Oh wait, you can't use Handlebars 1.3 any more, we suddenly moved to 2.0. No deprecation period. Fuck you.
    • Oh you want handlebars 2.0? Then you better update to 5.0.alpha version of our grunt task
    • Whoa whoa, where are you going, buster? Everyone knows you need 1.9.unstable.use-if-your-a-moran version of ember-template-compiler to run the grunt task 0.5.alpha
    • WTF is this? Ember-template-compiler.1.9.unstable.use-if-your-a-moran needs handlebars.2.0 MINIMUM to work. Not 1.9. 2.0, obviously.
    • Hah, so lame. You're trying to start ember using 1.3 handlebars-runtime, you need 2.0 dude.

    Finally, everything is updated to half-baked alpha versions and seems to compile and start up without issues.

    White screen. No DOM loaded whatsoever.

    I manage to extract "Cannot read property 'length' of undefined" error from somewhere deep in the bowels of handlebars runtime. No stack trace, of course, this is swallowed by Ember somewhere along the way.

    Note this is Ember 1.9 STABLE. Not a beta or anything.

    Fun.

    Contemplating my options:

    1. Revert back to the slow-ass 1.8 and veer off the gilded path towards htmlbars for now
    2. Keep digging through the mud
    3. Get drunk

    Leaning towards no. 3 ATM.

    BTW, no larger point to this, just a whine.

    Filed under: And yes, I know who's TRWTF, shut up



  • @cartman82 said:

    no.

    <rant>

    Number doesn't have an "o" in it, so why is "no." an accepted abbreviation for number?1

    Also, half the time, people leave off the period, so you just get "no". In this case, that would give you "Leaning towards no 3 ATM." So you don't want to get drunk right now? Then why did you list it as an option in the first place?

    There are 3 much more reasonable options here:

    1. You already typed out a long post. Just type out the word "number".
    2. Use an abbreviation that's more sensible and not so potentially ambiguous, like "nbr".
    3. Use the hash symbol, since it is often used in placed of the word number, as "#3".

    </rant>

    1 I did some quick searching. "No." is an abbreviation of the Latin numero.



  • @cartman82 said:

    Oh wait, you can't use Handlebars 1.3 any more, we suddenly moved to 2.0. No deprecation period. Fuck you.
    Oh you want handlebars 2.0? Then you better update to 5.0.alpha version of our grunt task
    Whoa whoa, where are you going, buster? Everyone knows you need 1.9.unstable.use-if-your-a-moran version of ember-template-compiler to run the grunt task 0.5.alpha
    WTF is this? Ember-template-compiler.1.9.unstable.use-if-your-a-moran needs handlebars.2.0 MINIMUM to work. Not 1.9. 2.0, obviously.
    Hah, so lame. You're trying to start ember using 1.3 handlebars-runtime, you need 2.0 dude.

    This is basically my experience with using any ROR project, especially Redmine, and especially if I want it to work with anything else (like apache). 90% of deployment time consists of finding the magical combination of dependency versions that both meet each other's requirements and don't break everything.



  • @abarker said:

    Nr

    There is no "b" in "Nummer".


  • ♿ (Parody)

    @aliceif said:

    There is no "b" in "Nummer".

    But there is in "Noomberal!"



  • @abarker said:

    I did some quick searching. "No." is an abbreviation of the Latin numero.

    Well of course, you uneducated bumpkin, why do you think I used it?

    In other news, I got the app to start up in a general way, but then to break in a 100 different tiny ways. Everywhere I did any kind of "clever" hack, especially regarding helpers, I now have to go and fix it due to some kind of new thing called "streams".

    Sigh.



  • @aliceif said:

    @abarker said:
    Nr

    There is no "b" in "Nummer".

    Your butchering of my quote made your joke fall flat.



  • @cartman82 said:

    In other news, I got the app to start up in a general way, but then to break in a 100 different tiny ways. Everywhere I did any kind of "clever" hack, especially regarding helpers, I now have to go and fix it due to some kind of new thing called "streams".

    Sigh.

    Back to 1.8!



  • @abarker said:

    There are 3 much more reasonable options here:

    1. You already typed out a long post. Just type out the word "number".
    2. Use an abbreviation that's more sensible and not so potentially ambiguous, like "nbr".
    3. Use the hash symbol, since it is often used in placed of the word number, as "#3".

    I vote for no 3!



  • @Evo said:

    I vote for no 3!

    :rolleyes:



  • They made such a mess of things with these new streams, I don't think I'll be able to continue maintaining my customized link-to helper.

    This is the problem right here:

    function linkToHelper(name) {
      // SNIP
      // A bunch of complicated internal stuff,
      // now made even more complicated
    
      return viewHelper.call(this, LinkView, options);
    }
    

    See that LinkView class reference? I need to put my own class there. But there's no way to do that from the outside (it's a local var). Which is why I wrote my own simplified version of this helper. And it sort of works.

    Except, every time there's an update, I'm tearing my hair off, trying to make my shit match their new internals. And it's all because you can't get link-to helper to call your own custom View class. I'm fucking sick of it.

    Fuck it.
    I know what to do.

    Give me half an hour.



  • There we go.

    My special helper:

    Ember.Handlebars.registerHelper("cartman-link", function (/*route, options*/) {
      var options = arguments[arguments.length - 1];
      
      // SNIP: some more stuff
      
      options._LinkViewClass = App.CartmanLinkView;
      return Ember.Handlebars.helpers["link-to"].apply(this, arguments);
    });
    

    "Oh cartman, you silly goose. How will you get ember to accept your special option?"

    npm install --save-dev grunt-regex-replace
    subl Gruntfile.js
    
    grunt.initConfig({
      "regex-replace": {
        fixEmber: {
          src: ["dev/vendor/temp/ember.js"],
          actions: [
            {
              name: "Custom link-to View class",
              search: /return viewHelper\.call\(this, LinkView, options\);/gm,
              replace: "return viewHelper.call(this, options._LinkViewClass || LinkView, options);"
            }
          ]
        }
      }
    });
    

    FUCK YOU EMBER! YOU HAVE DEFIED ME FOR THE LAST TIME!



  • @cartman82 said:

    My special helper

    A special helper for a 'special' framework.

    (A nice example of why you don't drink the Ember Kool-aid, btw. )


  • Banned

    I know @eviltrout spent a lot of time moving us to 1.9 on Friday, he might have some opinions here. Whatever pain points are probably fresh in his mind.

    If it makes you feel any better, 1.9 isn't mega faster than 1.8, but it does move you a lot closer to the bigger changes in 1.10 including HTMLbars. As 1.9 was just released a few days ago, we figured it was better to absorb the pain now in our 1.2 beta period so we would be ready as early as possible for 1.10 where most of the perf gap is finally corrected.



  • @cartman82 said:

    ```
    grunt.initConfig({
    "regex-replace": {
    fixEmber: {
    src: ["dev/vendor/temp/ember.js"],
    actions: [
    {
    name: "Custom link-to View class",
    search: /return viewHelper.call(this, LinkView, options);/gm,
    replace: "return viewHelper.call(this, options._LinkViewClass || LinkView, options);"
    }
    ]
    }
    }
    });

    Wait. You're telling me that you are replacing strings in the underlying code? And that that's a framework feature?


  • @codinghorror said:

    I know @eviltrout spent a lot of time moving us to 1.9 on Friday, he might have some opinions here. Whatever pain points are probably fresh in his mind.

    If it makes you feel any better, 1.9 isn't mega faster than 1.8, but it does move you a lot closer to the bigger changes in 1.10 including HTMLbars. As 1.9 was just released a few days ago, we figured it was better to absorb the pain now in our 1.2 beta period so we would be ready as early as possible for 1.10 where most of the perf gap is finally corrected.

    I got it working in the end. It was mostly my special LinkView-derived class that was making problems.

    And a bunch of deprecations of {{#each list}} style of iterations. Eviltrout was probably running around, replacing everything with {{#each item in list}} constructs, which is annoying but not too difficult.

    I can confirm, 1.9 feels about the same performance-wise.

    @Hanzo said:

    Wait. You're telling me that you are replacing strings in the underlying code? And that that's a framework feature?

    No, it's a hack in my grunt configuration. That's the whole point of the WTF solution. I added it as a step before merging, minification and other normal tasks.



  • @aliceif said:

    There is no "b" in "Nummer".

    There is no "n" in "Bummer".


  • Discourse touched me in a no-no place

    "Dwarf Fortress" contains neither a B nor an N.



  • @abarker said:

    There are 3 much more reasonable options here:

    1. Write the ‘o’ raised and underlined as expected, i.e. No
    2. Use the Correct™ Unicode symbol, ‘№’

    Filed under: Oh, the joys of using html because Discourse markdown does not support list starting numbers (though markdown in general usually does).



  • The docs seem to say that the options parameter to that function will be mixed in to LinkView when it the class is instantiated. No chance of just using that functionality?



  • @Bulb said:

    ‘o’ raised and underlined as expected, i.e. Nº

    FTFY



  • @conartist6 said:

    The docs seem to say that the options parameter to that function will be mixed in to LinkView when it the class is instantiated. No chance of just using that functionality?

    No good. I needed to use my own special LinkView-derived class.



  • @FrostCat said:

    "Dwarf Fortress" contains neither a B nor an N.

    Don't we need a @ben_lubot to reply to this?



  • @ben_lubot does not reply.



  • Hey all! I worked on parts of the streams / HTMLBars / view layer stuff in Ember. Pleeeeease send me a message on IRC (mmun on freenode irc at #emberjs-dev) if you're having upgrade problems. I am eager to help and I'm sure others are too.



  • @mmun said:

    Hey all! I worked on parts of the streams / HTMLBars / view layer stuff in Ember. Pleeeeease send me a message on IRC (mmun on freenode irc at #emberjs-dev) if you're having upgrade problems. I am eager to help and I'm sure others are too.

    I'm doing upgrade to 1.10 beta next week, I'll probably open another whining thread then :-)



  • So you spent hours piggybacking a breaking change into an already-done task and wasted your own time?

    Hint: This is what version control is for.



  • @Captain said:

    So you spent hours piggybacking a breaking change into an already-done task and wasted your own time?

    Hint: This is what version control is for.

    Err... what are you talking about?



  • @cartman82 said:

    @Captain said:
    This is what version control is for.

    Err... what are you talking about?

    File locking.



  • Your story.

    You were going to push to production, but decided to make a last minute, unscheduled change, that presumably took hours to do and broke things.

    Isn't that what you said? It looks like that's what you said.


  • ♿ (Parody)

    @tar said:

    File locking.

    rageguy <emoji borrowed from meta>


  • @Captain said:

    You were going to push to production, but decided to make a last minute, unscheduled change, that presumably took hours to do and broke things.

    Isn't that what you said? It looks like that's what you said.

    Well yeah. And then I finished it that night and deployed. That was a month ago...


Log in to reply