Ember.js woes part 2



  • You remember my "let's prepare for HTMLbars messiah's return to earth" thread? Where I was updating my app to Ember 1.9?

    Well HTMLBars came more than a month ago. And I'm still on 1.9. Open console in Discourse and enter Ember.VERSION. Guess what you'll see.

    Turns out, 1.10 was buggy as shit. In theory, if you had a hello world application, you could just replace a ember.js and go off frolicking with unicorns in the HTMLBars la-la land. In reality, any real application has a thousand little hacks and edge cases, that will suddenly start breaking. Add to that the bugs in the new view layer itself, and it seems both discodevs and me have decided HTMLBars can wait for one more release.

    Well, ember 1.11 is here. Seems more stable, at first glance. Some of the regressions were fixed (although I'm sure a bunch more were added).

    But whatever, I'm giving update another go.

    And... I was almost there. Most of my shit was displaying on the simplest pages.

    So far so good. I then go to a page with some actual dynamic content. My console fills with so many deprecation messages to almost crash Chrome.

     DEPRECATION: Ember.ObjectController is deprecated, please use Ember.Controller and use `model.propertyName`. See http://emberjs.com/guides/deprecations/#toc_objectcontroller for more details.
            at exports.default.ObjectProxy.default.extend.init (http://localhost/js/vendor.js:73928:24)
    

    Hundreds and hundreds of these.

    So what's this about?

    Back in the days of yore (1.10 and earlier), you could do something like this (pseudocode):

    // js
    var john = { name: "John" };
    var controller = {
      model: john,
      validated: "yes"
    };
    var template = new Template(controller, "index.hbs");
    
    <!--​ index.hbs -->
    <p>Name: {{name}}, validated: {{validated}}</p>
    

    See? The template draws its shit from controller. And because it's ObjectController, any property it doesn't have is proxied down to model.

    Very convenient. Everybody was doing this all over the place.

    Deprecated.

    So now I have to go dig through every fucking template in my huge ass codebase and change name to model.name, but NOT change validated (because it is defined on the controller itself). There's no easy way to distinguish between the two, except to dig into the controller code for each one and debug it in head. And if I miss something, it's a silent stinker of an error that only final users will notice (no errors or anything).

    Remember that last update I was bitching about and that produced all sorts of bugs in Discourse? This is worse.

    Fuck.



  • "New users might be confused by Ember doing the right thing by default. To reduce confusion, we're going to make everyone's life suck with State The Obvious."


  • Fake News

    Oh hey, yet another reason for me not to use third-party libs when doing Web UI development - fucking cowboy coders breaking shit for everybody.


  • FoxDev

    @lolwhat said:

    yet another reason for me not to use third-party libs when doing Web UI development

    Unless you're coding absolutely everything in-house, then you are always using third-party libs; kinda unavoidable really…


  • Fake News

    I will grant you that. Still, it appears that an egregious amount of this crap occurs in the Web UI space.



  • @lolwhat said:

    Oh hey, yet another reason for me not to use third-party libs when doing Web UI development - fucking cowboy coders breaking shit for everybody.

    Seriously. The shit Discourse and you are doing is Not Fucking Hard in JavaScript. Just write the 250 or so lines of code your damned self-- I can guarantee you'll end up with a better result.

    I hate programmers who do nothing but Lego-together a million half-baked buggy open source libraries. Hell, we use C#'s WebAPI at work, and I hate that too... the stuff is helps us with saves maybe 350-400 lines of our own code, while using it makes it impossible to auto-hydrate a controller object while also submitting a file. (Not to say our 350-400 line version would let you, but I ended up using that much code to work-around WebAPI's retardness anyway.)



  • @RaceProUK said:

    Unless you're coding absolutely everything in-house, then you are always using third-party libs; kinda unavoidable really…

    Well duh, but you use ones that have been around for at least 5 years and aren't developed by morons. And aren't bloated messes.

    I think the real problem is people really overestimate how much effort these libraries save. Obviously, there's some cases where if you try to do it yourself, you're likely to get it wrong-- for example, OAuth (because it's so fucking over-complicated by bullshit). In those cases, sure, use a library.

    I wrote my own WebAPI which supports XML, JSON, CORS, JSONP, HTTP Auth and all kinds of other shit. It's like 200 lines of code. And probably half of that is the JSON parser.

    But shit like Ember? What did you save? Look back a year later and total it all up-- what did you save?


    Anyway, what a shocker: the people who wrote Discourse made a really bad engineering decision. Add it to the pile of the other 57,000 really bad engineering decisions. Remember the solid 8 months or so they were telling us the Ember upgrade would fix everything everywhere? Yeah.


  • FoxDev

    @blakeyrat said:

    Hell, we use C#'s WebAPI at work, and I hate that too

    I'm not fond of it myself either; the number of headaches that has caused me…
    What was so bad about WCF? OK, the config was a pain in the arse, but once you get it working, it really fucking works. And if you use WCF RIA, so server-side code is automatically replicated in the client too via the service reference, then it's even better!


  • BINNED

    I was, and continue to be, accused of being stupid for not using something like Ember or Angular. Because I wanted MVC serverside so the application is accessible without JS. Yes, I know, edge case (no web crawlers will be allowed on it anyway), but still. Or I could've went with the same option Discourse used: serverside MVC feeding a clientside MVVM

    And then, oooh, and then: "You should have used MVC framework X!". Great, can it consume the same templates my clientside code will? Can it selectively return HTML or JSON for a method call as needed? Does it have a module system? Because I need one.

    "You can modify it!" Yes, and then fear every update because of shit like this. Yay.



  • @RaceProUK said:

    What was so bad about WCF?

    Are you joking? I'm arguing AGAINST bloated over-complicated shit.

    At least WebAPI has reasonable scope. It's still way more bloated than it needs to be, though. And engineered in a wack-ass way which makes something really fucking simple, like submitting a form with a file upload, nearly impossible.



  • In an earlier project, I did make my own frontend library to do the sort of stuff that ember does effortlessly.

    Even with all the problems I've had, I'd take ember any day over my own unmaintainable mess.



  • If your code was unmaintainable, maybe you just suck at it.

    Have fun fixing a million deprecation warnings.



  • @blakeyrat said:

    If your code was unmaintainable, maybe you just suck at it.

    Have fun fixing a million deprecation warnings.

    I'LL HAVE YOU KNOW I ALREADY FIXED LIKE... 5.

    *sob*


  • FoxDev

    @blakeyrat said:

    @RaceProUK said:
    What was so bad about WCF?

    Are you joking? I'm arguing AGAINST bloated over-complicated shit.

    At least WebAPI has reasonable scope. It's still way more bloated than it needs to be, though. And engineered in a wack-ass way which makes something really fucking simple, like submitting a form with a file upload, nearly impossible.


    Oh, it's far from perfect, I agree. But you have to admit, once it's working, it's pretty easy to use. And the fact you can include much richer type information makes it harder to suffer from deserialisation issues.



  • One relatively simple page converted. 100 more to go.

    LOL, if my progress is any indication, you can expect HTMLBars discourse around 2018. Good luck, @riking. :-)



  • @cartman82 said:

    I'LL HAVE YOU KNOW I ALREADY FIXED LIKE... 5.

    sob

    If it makes you feel better, Microsoft libraries are pulling the same shit. Take a look at the next Entity Framework, for example-- it breaks fucking everything.

    There's nobody left interested in building solid, foundational libraries anymore. This industry has been taken over by morons.

    Remember when Apple designed the Macintosh Toolbox which then didn't need to be fundamentally changed in any way for OVER 20 YEARS? In today's environment, you'd be lucky to get 4 years without a breaking change.



  • Which is a shame, because the idea behind Entity Framework wasn't necessarily a bad one.

    Then again, this may be one of those times where they borrowed an idea from another language and didn't know where to go with it.


  • kills Dumbledore

    @blakeyrat said:

    Remember when Apple designed the Macintosh Toolbox which then didn't need to be fundamentally changed in any way for OVER 20 YEARS? In today's environment, you'd be lucky to get 4 years without a breaking change.

    I don't remember a time when an Apple OS let you run software written more than 4 years ago. Still not sure why they felt the need to remove the Classic VM system or Rosetta, they can't have been using up much space compared to a modern OS install



  • @Jaloopa said:

    Still not sure why they felt the need to remove the Classic VM system or Rosetta, they can't have been using up much space compared to a modern OS install

    Probably it fell on the wrong side of the man-hours-to-maintain/any-visible-benefit line.



  • Fuck warnings, all the warning should be disabled by design!

    Now, seriously, this is deprecated, and I'm not sure if this something different for Ember or JS land, but deprecated code doesn't mean shit until it's removed which is when things break.

    I know, you gotta fix it, but it's not like your app is broken right now because of this.


  • FoxDev

    @Eldelshell said:

    Fuck warnings, all the warning should be disabled by design!

    in release builds, yes (which includes minified JS)

    in debug builds, no... those are helpful so you don't add new stuff relying on the deprecated behavior without knowing about it.



  • Thanks, but I was joking and was thinking about compiler warnings.


  • FoxDev

    oh. that makes more sense then.


  • Discourse touched me in a no-no place

    @blakeyrat said:

    Take a look at the next Entity Framework, for example-- it breaks fucking everything.

    This seems like an opportunity for someone to write a compatibility shim library, that maps the old model to the new one.



  • @FrostCat said:

    This seems like an opportunity for someone to write a compatibility shim library, that maps the old model to the new one.

    It would be nice if the person to do that would be, you know, THE ENTITY FRAMEWORK TEAM ITSELF!



  • @blakeyrat said:

    At least WebAPI has reasonable scope. It's still way more bloated than it needs to be, though. And engineered in a wack-ass way which makes something really fucking simple, like submitting a form with a file upload, nearly impossible.

    Ofcourse it still is. It's still built by the same crew that built WCF, making WebAPI the unholy marriage of ASP.NET MVC's convention-over-configuration and WCF's configuration-over-convention, which in far too many cases leaves you smack in the middle of nowhere without a clue what to do when something inevitably breaks and keels over.



  • Why would they, there's random dudes on the internet who'll probably do it for free :P



  • @cartman82 said:

    So far so good. I then go to a page with some actual dynamic content. My console fills with so many deprecation messages to almost crash Chrome.

    You must have a real old version of Chrome. Ha! It takes several thousands of console.log() to crash Chrome these days. Or one with a really long string.

    Fuck.

    Spoken like Cartman. But I understand your pain. Why do you work with such imbecile tools? It doesn't look as if it do that much to write better code, or write the same crap but faster.



  • @Hanzo said:

    You must have a real old version of Chrome. Ha! It takes several thousands of console.log() to crash Chrome these days. Or one with a really long string.

    Linux without 3D acceleration + attaching object and stack trace with each message.

    I had to kill the tab and it took a minute to do it.

    @Hanzo said:

    Spoken like Cartman. But I understand your pain. Why do you work with such imbecile tools? It doesn't look as if it do that much to write better code, or write the same crap but faster.

    As I said, I already did try to make a complex SPA-like application using only jQuery (my own framework-like code). It turned into a mess, of course.

    SPA frameworks are IMO a good idea. The problem is, javascript land is evolving so damn fast. A cool new thing in 2012 is a stodgy outdated oldtimer in 2015. Some frameworks decide to fold up and die (angular). Others like ember attempt to keep up, but the stress causes all sorts of crack to start appearing (outdated documentation, regressions, endless refactoring to keep up etc).

    Of course, nothing is forcing me to keep updating. I can just lock the application to ember 1.9 and it'll just keep working fine. Except when you need support and documentation and new libraries and features, it becomes a problem.

    So I guess I'll just try to keep up as long as I can. At least over the htmlbars hump. Or maybe even up to ember 2.0.

    But it's inevitable that, at some point, I'll decide I've had enough and step off the update train. So someone new who takes it over can complain what a "legacy" mess it is and how we should just throw it all away and rewrite it from scratch in react 3.0 or whatever new thing is popular at that time.


  • ♿ (Parody)

    I don't do this crazy js stuff. What's the point of model, anyways? For your purposes, wouldn't it be simpler to get rid of that and just put all your shit right into controller?

    I'm assuming there's something going on somewhere that needs stuff in model. What if you added a helper to duplicate the data and just put stuff that's in model directly into controller? I guess that bloats your objects, but fuck that shit.


  • FoxDev

    The idea is model has the data, and controller manipulates it


  • ♿ (Parody)

    Fuck the idea, is there something that requires it to be in there? Are we trying to teach a class on pattern purity or get some work done?


  • FoxDev

    I would say it's flavour-of-the-month, but the MVC pattern has been around for ages and is pretty widely used nowadays. It's not all that different from stuff like three-tier architecture; it's a way to keep code well-structured.


  • FoxDev

    @boomzilla said:

    is there something that requires it to be in there?

    requires? no.

    frankly the MVC pattern has always confused me as to why it exists. MVVC even mroe.

    as it's always explained to me it's:

    • Model: Responsible for getting data out of data store
    • Controller: responsible for manipulating data
    • View: shows data to user

    and the reasoning is always so that you can swap out your data store without changing anything other than the model. but that sort of stuff ALWAYS leaks and you're going ot have to end up changing all sorts of shite if you change out your persistence layer, no matter what you do!


  • ♿ (Parody)

    You guys aren't understanding the question. In this particular case, does ember.js or htmlbars or whatever require that stuff to be in model? Like, it actually does something with it? Or is putting stuff in model just a convention to keep the Gods of the patterns content?


  • Notification Spam Recipient

    It's specifically in there so that @cartman82 can complain about it when it breaks



  • As far as I can tell. They gutted the entire implementation and replaced it with a generic controller and a deprecation message. However, the documentation still describes the behavior as if it wasn't gutted. That's worth complaining about - there was no need to break it.


  • Discourse touched me in a no-no place

    @Jaime said:

    That's worth complaining about - there was no need to break it.

    This is some hipster open source Java script thing. This means the documentation will be shit, and it'll change completely when the developers feel some need to for the sake of change without being backwards compatible.



  • @boomzilla said:

    I don't do this crazy js stuff. What's the point of model, anyways? For your purposes, wouldn't it be simpler to get rid of that and just put all your shit right into controller?

    I'm assuming there's something going on somewhere that needs stuff in model. What if you added a helper to duplicate the data and just put stuff that's in model directly into controller? I guess that bloats your objects, but fuck that shit.

    Model has "pure" business data. Eg. "name" and "surname".

    Controller holds temporary and/or derived data. Eg. "fullName" ("$name $surname") and "validationErrors".

    Model is something you'd store in database and use in multiple applications (or on multiple screens / widgets of the same app). Controller makes sense only on your current screen in your current application.

    In other places, this distinction is made through "model" / "viewModel", if that's more familiar.

    I suppose you could load data from db and attach them directly to controller. And then regenerate payload when you want to save. But that's not "The Ember Way", and with these guys, it's "their way or highway" sort of situation (they have a long standing rails hard-on).



  • @boomzilla said:

    Fuck the idea, is there something that requires it to be in there? Are we trying to teach a class on pattern purity or get some work done?

    Wow, I agree with Boomzilla.


  • :belt_onion:

    Who needs compiler warnings?


    Filed Under: Everybody. Literally everybody.



  • @loopback0 said:

    This is some hipster open source Java script thing. This means the documentation will be shit, and it'll change completely when the developers feel some need to for the sake of change without being backwards compatible.

    They didn't just change it, they kicked everyone in the dick who was using this feature. Most open source projects suck due to neglect, this case is special due to the fact that they put effort into making it worse.


  • Discourse touched me in a no-no place

    @Jaime said:

    that they put effort into making it worse.

    Perfect framework for Dischorse then.



  • @Jaime said:

    They didn't just change it, they kicked everyone in the dick who was using this feature. Most open source projects suck due to neglect, this case is special due to the fact that they put effort into making it worse.

    During the lulls of my rage boner, I have to admit this change makes sense. It will make future ember code cleaner and more durable.

    BUT WHY THE FUCK DID THEY HAVE TO SPEND 2 YEARS TELLING EVERYONE THEY SHOULD WRITE APPS THE "WRONG" WAY!? FUCK!



  • @cartman82 said:

    It will make future ember code cleaner and more durable.

    The same could have been accomplished by adding the deprecation message and leaving the implementation intact for a few versions. Then, when it is pulled, the only people complaining would be those who ignored the warnings.

    It would also be nice of them to change the documentation, which currently doesn't match the code.

    I originally looked at the source code thinking I would find some semi-rational thing that you were over-reacting to. I was surprised to find that they handled this deprecation as poorly as they possibly could have.



  • Upfront design? That's so 90's!

    You have to ask yourself, if this is such a great idea, why wasn't it in version 1? Is there an answer other than, "because the developers are morons who didn't think things through?" And you're just sitting here, perfectly ok using software written by morons who didn't think things through.


  • I survived the hour long Uno hand

    @Jaime said:

    adding the deprecation message

    @cartman82 said:

    My console fills with so many deprecation messages to almost crash Chrome.

    Context!



  • @Jaime said:

    The same could have been accomplished by adding the deprecation message and leaving the implementation intact for a few versions. Then, when it is pulled, the only people complaining would be those who ignored the warnings.

    It would also be nice of them to change the documentation, which currently doesn't match the code.

    I originally looked at the source code thinking I would find some semi-rational thing that you were over-reacting to. I was surprised to find that they handled this deprecation as poorly as they possibly could have.

    Even worse, look at their issues page and count how many active regressions / bugs they have. Apparently, that's no barrier whatsoever from publishing the new "stable" release.

    @blakeyrat said:

    Upfront design? That's so 90's!

    You have to ask yourself, if this is such a great idea, why wasn't it in version 1? Is there an answer other than, "because the developers are morons who didn't think things through?" And you're just sitting here, perfectly ok using software written by morons who didn't think things through.

    Designing framework-level software is difficult. NO ONE that I know of has gotten it right the first time. Case in point, .NET 1.0.

    In ember's case, however, they should probably stop for a bit and consolidate, instead of chasing after react or whatever the cool new thing is.

    Also, what's the alternative? The closest any js framework comes to a stodgy conservative development path is dojo, and I just couldn't get into that the last time I tried (although I'll probably give them another shot the next time I need a "quick" admin interface).



  • Yay, another regression. And it might just be bad enough to make 1.11 unusable for me. Such a GREAT thing to discover 8 hours into the update.

    "Oh cartman, you silly goose, why don't you just wait a few days for a bug fix minor version and continue the update then?"

    What, you mean like I waited for 1.10.1? How I followed a release milestone with a bunch of critical fixes, that was stuck on 60% for more than a month? Only to silently disappear a week before 1.11 went out? 1.11, that brought all the needed fixed, but also a whole slew of new bugs, regressions and deprecations? So that I never can just have a stable version, but always have to chose between several half-broken releases and judge which one has the bugs I can live with?

    Yeah, I'd rather not do that again if I can help it.



  • I'd rather leave MVC in the server-side part of my webapp, thanks. My View doesn't need its own MVC framework inside it as its not doing any business logic1 2.

    1 Maybe some form validation, but that's also being done on the server side.
    2 I'm ignoring things like AJAX calls since those are just asking the webapp for more data.


Log in to reply