6 ms·

Ember is an incredible framework that's been carefully thought out by a team of super sharp people with loads of experience, and I'm constantly amazed by how qu

Ember is an incredible framework that's been carefully thought out by a team of super sharp people with loads of experience, and I'm constantly amazed by how quickly I can get real projects built using it. I've used it for many projects since ember-cli came out a few years ago. I feel about Ember for client-side projects how I felt about Rails for server-side projects—it made it fun for me again. But Ember gets a bad wrap from the internet because (admittedly) their marketing materials with the gooofy chipmunks make it look like a toy while React's make it look like you're learning quantum physics. And then there's the timeless "convention over configuration" divide where Ember people are generally on the left side, and React people just love the thought of fiddling around and hand rolling their own custom ungoogleable bespoke artisan framework before actually getting to the meat of the work. I highly recommend using Ember for any size project if you like getting shit done. This is a good talk kinda about this: https://www.youtube.com/watch?v=rWH3UNIKFeg https://www.youtube.com/watch?v=rWH3UNIKFeg

s_kilk 8y ago
Yeah all of this sounds good, thanks!
Ralfp 8y ago
> But Ember gets a bad wrap from the internet because (admittedly) their marketing materials with the gooofy chipmunks make it look like a toy Ember.js is best technology that I've ever dropped, but let me assure you, the Tomster had nothing to do with my decision. Ember got into the spotlight when Atwood and Co. have launched the Discourse. Back then it looked super impressive - first open source forum software and arguably one of first open source apps following "JS fronted and API backend" architecture. And it was all done with Ember.js, js FW marketing itself as the modern way to build JS apps! A lot of people wanted to try it out (myself included), some moving from Angular, other from Backbone, and others coming from backend development. If Ember ever had the cool factor, it was that time. Ember.js was the next big thing, a framework for creating ambitious web applications, and all the people came to it to build their ambitious applications, looking up to Discourse as example of such application. And then those people have hit the roadblock. Ember.js's pitch was building applications, but it's documentation has never moved past explaining individual parts of technology, and into the field of how those should be put together in final application. Angular had millions of easily googleable tutorials like "this is best practice for setting page title when user enters the route" or "this is how you can configure framework to authenticate with your backend technology". I also clearly remember the "calling set on destroyed object" error that happened when you tried to update the state of object that was already destroyed that was impossible to debug, because the error was literally "Error: calling set on destroyed object" and it put world to stop. For comparision, in React.js that was "Warning: calling setState with X, Y and Z on unmounted component ComponentName". That one error was absolute productivity killer when debugging Ember.js apps from day one, and it was years before somebody from Ember.js core actually went to Ember's source code and changed "assert !obj._is_destroyed 'calling set on destroyed object'" to "assert !obj._is_destroyed 'calling set on destroyed object'". There was always bigger fish to fry for Ember.js core team, who were so bussy making blogpost after blogpost of new great features or API changes happening, while being oblivious to comments below those same blogposts asking "can I now do partial updates on models because they are super costful to update?" or "is calling set on destroyed object fixed yet?". And then guys from their ambassador product, Discourse, started writing blog posts following the pattern of "Here's how we've replaced Ember.js's feature with our one because framework's didnt work", and those involved things like `Ember-Data` or Ember views.
- ben_jones 8y ago
  EmberJS was the first front-end framework I learned as a web developer, shortly after learning Django. This was before Ember 1.0 . It was cool at first - but once I started developing real projects I ran head first into unreadable or cryptic internal stack traces and APIs that forced me to adapt my back-end to fit the needs of the front-end app. A short time later I picked up angular 1.x and was off to the races because anytime I ran into a problem with a feature or design decision I could easily find the hack that would keep my momentum going. I always felt like EmberJS meant well but chose rigidness where it should have been flexible, and flexibility where it should have been rigid. It's probably changed and solved many of these early problems. I want to go back and re-evaluate, but nowadays so many different technologies, frameworks, languages, and tools, are pulling at my time that I don't think I will be able to. FWIW my current stack of choice (and at work) is Golang and Vue (w/Typescript) - which might identify where some of my biases and predilections are.
  - anoncoward778 8y ago
    MAN....ember before v 1.0 ???...I'd suggest taking a revisit. Version 2.0 was a different universe let alone 3.1
- okket 8y ago
  > changed "assert !obj._is_destroyed 'calling set on destroyed object'" to "assert !obj._is_destroyed 'calling set on destroyed object'" Umm... those are the same?
  - pilaf 8y ago
    He probably meant something like this on the second case: Ember.assert(`calling set('${inspect(keyName)}') on a destroyed object ${inspect(obj)}`, !obj.isDestroyed);
- dbbk 8y ago
  > first open source forum software This is not at all correct
ravenstine 8y ago
I don't think Ember's bad rap is due to its marketing image. First off, Ember long had a reputation for being less performant out of all frontend frameworks. It was mostly true for some time, but Ember is pretty fast these days. More importantly, I think that frontend development still is influenced by its long history of "duct tape" coding practices resulting from JavaScript and CSS being very crippled for much of their existence. Thus, many JavaScript developers seem to prefer simple libraries that can do a lot with a little investment in configuration and composition. Of course there's also the fact that Tilde is the most notable supporter of Ember, whereas Angular has Google and React has Facebook. But some people, such as myself, like an opinionated toolchain such as Ember.
- Kerrick 8y ago
  I’d say that LinkedIn is a much more notable supporter of Ember than Tilde.
  - lf-non 8y ago
    Given that even after a major overhaul, Linkedin's web interface is sub-par wrt. UX as well as performance, I am not sure Linkedin's endorsement really contributes positively towards popularity of Ember.
    - atonse 8y ago
      Totally agree. I love ember but linked in’s new ember interface just makes my Laptop fans spin like crazy. I worry because I know they’ve hired some of the most talented folks from the Ember community (people who care about performance and scrolling jankyness). This is not a knock on them, but it is worrying that even the best of the best may struggle with larger, more complex apps.

s_kilk 8y ago

Yeah all of this sounds good, thanks!

Ralfp 8y ago

> But Ember gets a bad wrap from the internet because (admittedly) their marketing materials with the gooofy chipmunks make it look like a toy Ember.js is best technology that I've ever dropped, but let me assure you, the Tomster had nothing to do with my decision. Ember got into the spotlight when Atwood and Co. have launched the Discourse. Back then it looked super impressive - first open source forum software and arguably one of first open source apps following "JS fronted and API backend" architecture. And it was all done with Ember.js, js FW marketing itself as the modern way to build JS apps! A lot of people wanted to try it out (myself included), some moving from Angular, other from Backbone, and others coming from backend development. If Ember ever had the cool factor, it was that time. Ember.js was the next big thing, a framework for creating ambitious web applications, and all the people came to it to build their ambitious applications, looking up to Discourse as example of such application. And then those people have hit the roadblock. Ember.js's pitch was building applications, but it's documentation has never moved past explaining individual parts of technology, and into the field of how those should be put together in final application. Angular had millions of easily googleable tutorials like "this is best practice for setting page title when user enters the route" or "this is how you can configure framework to authenticate with your backend technology". I also clearly remember the "calling set on destroyed object" error that happened when you tried to update the state of object that was already destroyed that was impossible to debug, because the error was literally "Error: calling set on destroyed object" and it put world to stop. For comparision, in React.js that was "Warning: calling setState with X, Y and Z on unmounted component ComponentName". That one error was absolute productivity killer when debugging Ember.js apps from day one, and it was years before somebody from Ember.js core actually went to Ember's source code and changed "assert !obj._is_destroyed 'calling set on destroyed object'" to "assert !obj._is_destroyed 'calling set on destroyed object'". There was always bigger fish to fry for Ember.js core team, who were so bussy making blogpost after blogpost of new great features or API changes happening, while being oblivious to comments below those same blogposts asking "can I now do partial updates on models because they are super costful to update?" or "is calling set on destroyed object fixed yet?". And then guys from their ambassador product, Discourse, started writing blog posts following the pattern of "Here's how we've replaced Ember.js's feature with our one because framework's didnt work", and those involved things like `Ember-Data` or Ember views.

ben_jones 8y ago
EmberJS was the first front-end framework I learned as a web developer, shortly after learning Django. This was before Ember 1.0 . It was cool at first - but once I started developing real projects I ran head first into unreadable or cryptic internal stack traces and APIs that forced me to adapt my back-end to fit the needs of the front-end app. A short time later I picked up angular 1.x and was off to the races because anytime I ran into a problem with a feature or design decision I could easily find the hack that would keep my momentum going. I always felt like EmberJS meant well but chose rigidness where it should have been flexible, and flexibility where it should have been rigid. It's probably changed and solved many of these early problems. I want to go back and re-evaluate, but nowadays so many different technologies, frameworks, languages, and tools, are pulling at my time that I don't think I will be able to. FWIW my current stack of choice (and at work) is Golang and Vue (w/Typescript) - which might identify where some of my biases and predilections are.
- anoncoward778 8y ago
  MAN....ember before v 1.0 ???...I'd suggest taking a revisit. Version 2.0 was a different universe let alone 3.1
okket 8y ago
> changed "assert !obj._is_destroyed 'calling set on destroyed object'" to "assert !obj._is_destroyed 'calling set on destroyed object'" Umm... those are the same?
- pilaf 8y ago
  He probably meant something like this on the second case: Ember.assert(`calling set('${inspect(keyName)}') on a destroyed object ${inspect(obj)}`, !obj.isDestroyed);
dbbk 8y ago
> first open source forum software This is not at all correct

ravenstine 8y ago

I don't think Ember's bad rap is due to its marketing image. First off, Ember long had a reputation for being less performant out of all frontend frameworks. It was mostly true for some time, but Ember is pretty fast these days. More importantly, I think that frontend development still is influenced by its long history of "duct tape" coding practices resulting from JavaScript and CSS being very crippled for much of their existence. Thus, many JavaScript developers seem to prefer simple libraries that can do a lot with a little investment in configuration and composition. Of course there's also the fact that Tilde is the most notable supporter of Ember, whereas Angular has Google and React has Facebook. But some people, such as myself, like an opinionated toolchain such as Ember.

Kerrick 8y ago
I’d say that LinkedIn is a much more notable supporter of Ember than Tilde.
- lf-non 8y ago
  Given that even after a major overhaul, Linkedin's web interface is sub-par wrt. UX as well as performance, I am not sure Linkedin's endorsement really contributes positively towards popularity of Ember.
  - atonse 8y ago
    Totally agree. I love ember but linked in’s new ember interface just makes my Laptop fans spin like crazy. I worry because I know they’ve hired some of the most talented folks from the Ember community (people who care about performance and scrolling jankyness). This is not a knock on them, but it is worrying that even the best of the best may struggle with larger, more complex apps.