6 ms·

As a long time (5 years full time) Ember developer, this is quite interesting to me philosophically. I've spent a lot of time trying to tell people that all th

As a long time (5 years full time) Ember developer, this is quite interesting to me philosophically. I've spent a lot of time trying to tell people that all the stuff in Ember is there for a reason; for example, you're going to need a router, you're going to need support for controllers, etc. I still feel strongly that if your app is large and serious you are going to need that stuff. But. A lot of people just want to jump in and start building. React's immense popularity has shown the value in creating a view layer framework without all the extra stuff. It's great for onboarding new developers since there is less surface area to familiarize yourself with, and you can add in extra stuff (work your way towards full Ember) as you go. It also comes with the added benefit of being able to add small components to a page without running the whole thing as an application, which is a use case Ember was not so great at before. Overall I think it's a great announcement.

k__ 9y ago
I used Ember for about 2 years and thought so too. Now I'm using React and I think it's approach is much better. The API is tiny compared to Ember and there aren't much concepts, still it accomplishes everything Ember did. I feel bad to say this, but in the modular, library heavy, NPM based JS world of today, React (and other component frameworks like Cyclejs or hyperapp) fits just in. While Ember feels like a anachronism of the big framework days of Rails. :/
- mwpmaybe 9y ago
  Glimmer.js may be more your speed!
- _____s 9y ago
  With Glimmer as a standalone library, I think ember's going in the right direction. There's been some excellent work on Fastboot and Engines in the last year or so and I really like the approach ember's team is taking with this. React, for me, still offers better composability. You deal in plain JS objects, pass them around, and can build really complex UIs on top of that. I also really like redux. I still use ember heavily though; I think we'll get there as well!
  - Touche 9y ago
    I think Ember is really good at marketing the stuff they work on, but it is usually overhyped. Fastboot, for example, was announced what, 3 years ago? The readme says it's still not ready to use: > The bottom line is that you should not (yet) expect to install this add-on in your production app and have FastBoot work. https://github.com/ember-fastboot/ember-cli-fastboot https://github.com/ember-fastboot/ember-cli-fastboot I find this is often true of Ember projects (like Glimmer 1), a lot of hype for something that has a lot of rough edges.
    - elwayman02 9y ago
      At the end of the day, the Ember team takes a lot of time to not just build things the right way, but also make it as painless as possible for teams to upgrade along the blessed path. This has been a learning process to understand how much more time that takes, and has caused some past announcements to feel like they weren't delivered on, when in fact they simply just took more time to get right.
      - deleted 9y ago
        [deleted]
      - Touche 9y ago
        Yep, the 90-90 rule[1] The other lesson to take is to be more cautious about announcing stuff before its really ready. But they don't seem to have learned that here. Here we have a project with its own logo, a marketing video with a nice electronica beat behind it, and a YouTube Live announcement... ... For something they are telling you to install from their master branch. [1] https://en.wikipedia.org/wiki/Ninety-ninety_rule https://en.wikipedia.org/wiki/Ninety-ninety_rule
    - k__ 9y ago
      Yes, I had the same feeling. While the Ember devs talked about stuff like Fastboot and Glimmer, while other frameworks just had all this out of the box. Their whole approach seems to be rather concept heavy and back in the days (2014/2015) the docs where horribly outdated and you had to check stackoverflow for basic things. I had to use Ember 2 years on a project and found it clunky, but okay. I switched to React 2 years ago. And after I met a few hardcore Ember devs from back in the days, who said they switched to Angular2 or React I think this was the right decision. It's nice that the existing projects get so good support, but I wouldn't recommend anyone to start something new with Ember :\
- 824ueirwfjd 9y ago
  That hasn't been my experience with ember in the past 1.5 years. Granted when I was first introduced to it about 3 years ago, there were many issues and I wasn't keen on using it but since then things have improved a bunch.
  - k__ 9y ago
    Nice to hear, I haven't used Ember for about 2 years now. When they started putting more effort in their CLI, this was the signal for me to jump ship and go for something more light weight.
- elwayman02 9y ago
  Why would you want to build a bespoke React-based framework for every app you make? Why not simply have everything you need out of the box, plus the ability to easily integrate any npm library into your app via first-class build tooling that is miles easier to use than something clunky like Webpack?
  - k__ 9y ago
    Because in my experience the "out-of-the-box" solutions always break down the more you want to customise them. Now I rather prefer solutions that have customisation in mind from start, so it's always easy to switch things.
    - mhd 9y ago
      I remember when that wave hit the Ruby/Python space, with things like Pyramid/Pylons. These days that seems to have gone the way of the dodo, with the big monoliths still being around and then some minimal HTTP decorators like Sinatra/Flask/Node. Problem is that the middle ground would require a level of modularity that we still haven't reached, despite all the talk of "software ICs" that came around with early OOP. I predict that's how we're going to end up in a few years again. Some big monoliths (whatever react is morphing into currently, plus Angular and as the world is a cruel mistress, ExtJS), plus a plethora of DOM wrappers and view libraries. And 72 build systems.
      - ergo14 9y ago
        You know that pyramid powers some of the most important infrastructure for python? Like new version of PYPI (https://pypi.org/ https://pypi.org/)? And lots of big organizations use it - like Mozilla or NASA, sites like Reddit still use pylons. IF you think it went the way of the dodo, I'd suggest doing a bit of better research before predicting the future :D Because IMO you are seriously off here.
        mhd 9y ago
        I'm talking about the trend of build-your-own frameworks, not the software itself. Heck, there are enough sites out there still using Zope, MASON and Aolserver.
- LocalPCGuy 9y ago
  > still it accomplishes everything Ember did That isn't really accurate unless you are adding additional libraries to accomplish all of the things Ember does. I'm not arguing with the rest of your post, just saying that statement is incorrect (in that it doesn't tell the entire story).
finchisko 9y ago
"still feel strongly that if your app is large and serious you are going to need that stuff." My approach usually is, start minimalistic and if you need additional stuff, you can usually add it later. That is why I like React. For example if I need router, I can choose from many implementation, but there are also cases when I don't need it all.
- BigJono 9y ago
  This is a very good way to go. In my experience, adding a new tool can take a day or two of refactoring in a medium sized project; but removing one can take a week. Removing a bunch because you completely over-engineered the solution and can't maintain it can often take a month, or even get dangerously close to "scrap it and rewrite" territory, which is a complete death sentence for a small company. Unless I'm working with people I know well, I'll often elect to start off a fresh project with just React and maybe Redux, and build from there. Even if I know full well that we'll need some stuff like thunk and react-router, my preference is to leave them out and let the team run into the problems they solve before we introduce them. IMO even if just one team member gains a new understanding about why their tools exist and why they're using them, it's worth a bit of refactoring.
  - mnutt 9y ago
    I can see where you're coming from, but I tend to bucket apps I write into either general use case, mostly business-logic apps, or highly specific services. (say, a network proxy or compositor or something) The general use case apps all tend to share a good deal of requirements (multiple pages, authentication, forms, etc) and while it would certainly be possible to pick and choose each component, it's nice to have a shared set of functionality that is well-tested together and that stays the same between multiple projects and teams. I think adopting something like ember is pretty much the opposite of "can't maintain it" since while I understand how it works internally, I don't actually have to maintain it myself. In my experience I've seen more instances where we ended up ripping out a homegrown library to replace with a community-supported solution than the other way around.
    - 9y ago

k__ 9y ago

I used Ember for about 2 years and thought so too. Now I'm using React and I think it's approach is much better. The API is tiny compared to Ember and there aren't much concepts, still it accomplishes everything Ember did. I feel bad to say this, but in the modular, library heavy, NPM based JS world of today, React (and other component frameworks like Cyclejs or hyperapp) fits just in. While Ember feels like a anachronism of the big framework days of Rails. :/

mwpmaybe 9y ago
Glimmer.js may be more your speed!
_____s 9y ago
With Glimmer as a standalone library, I think ember's going in the right direction. There's been some excellent work on Fastboot and Engines in the last year or so and I really like the approach ember's team is taking with this. React, for me, still offers better composability. You deal in plain JS objects, pass them around, and can build really complex UIs on top of that. I also really like redux. I still use ember heavily though; I think we'll get there as well!
- Touche 9y ago
  I think Ember is really good at marketing the stuff they work on, but it is usually overhyped. Fastboot, for example, was announced what, 3 years ago? The readme says it's still not ready to use: > The bottom line is that you should not (yet) expect to install this add-on in your production app and have FastBoot work. https://github.com/ember-fastboot/ember-cli-fastboot https://github.com/ember-fastboot/ember-cli-fastboot I find this is often true of Ember projects (like Glimmer 1), a lot of hype for something that has a lot of rough edges.
  - elwayman02 9y ago
    At the end of the day, the Ember team takes a lot of time to not just build things the right way, but also make it as painless as possible for teams to upgrade along the blessed path. This has been a learning process to understand how much more time that takes, and has caused some past announcements to feel like they weren't delivered on, when in fact they simply just took more time to get right.
    - deleted 9y ago
      [deleted]
    - Touche 9y ago
      Yep, the 90-90 rule[1] The other lesson to take is to be more cautious about announcing stuff before its really ready. But they don't seem to have learned that here. Here we have a project with its own logo, a marketing video with a nice electronica beat behind it, and a YouTube Live announcement... ... For something they are telling you to install from their master branch. [1] https://en.wikipedia.org/wiki/Ninety-ninety_rule https://en.wikipedia.org/wiki/Ninety-ninety_rule
  - k__ 9y ago
    Yes, I had the same feeling. While the Ember devs talked about stuff like Fastboot and Glimmer, while other frameworks just had all this out of the box. Their whole approach seems to be rather concept heavy and back in the days (2014/2015) the docs where horribly outdated and you had to check stackoverflow for basic things. I had to use Ember 2 years on a project and found it clunky, but okay. I switched to React 2 years ago. And after I met a few hardcore Ember devs from back in the days, who said they switched to Angular2 or React I think this was the right decision. It's nice that the existing projects get so good support, but I wouldn't recommend anyone to start something new with Ember :\
824ueirwfjd 9y ago
That hasn't been my experience with ember in the past 1.5 years. Granted when I was first introduced to it about 3 years ago, there were many issues and I wasn't keen on using it but since then things have improved a bunch.
- k__ 9y ago
  Nice to hear, I haven't used Ember for about 2 years now. When they started putting more effort in their CLI, this was the signal for me to jump ship and go for something more light weight.
elwayman02 9y ago
Why would you want to build a bespoke React-based framework for every app you make? Why not simply have everything you need out of the box, plus the ability to easily integrate any npm library into your app via first-class build tooling that is miles easier to use than something clunky like Webpack?
- k__ 9y ago
  Because in my experience the "out-of-the-box" solutions always break down the more you want to customise them. Now I rather prefer solutions that have customisation in mind from start, so it's always easy to switch things.
  - mhd 9y ago
    I remember when that wave hit the Ruby/Python space, with things like Pyramid/Pylons. These days that seems to have gone the way of the dodo, with the big monoliths still being around and then some minimal HTTP decorators like Sinatra/Flask/Node. Problem is that the middle ground would require a level of modularity that we still haven't reached, despite all the talk of "software ICs" that came around with early OOP. I predict that's how we're going to end up in a few years again. Some big monoliths (whatever react is morphing into currently, plus Angular and as the world is a cruel mistress, ExtJS), plus a plethora of DOM wrappers and view libraries. And 72 build systems.
    - ergo14 9y ago
      You know that pyramid powers some of the most important infrastructure for python? Like new version of PYPI (https://pypi.org/ https://pypi.org/)? And lots of big organizations use it - like Mozilla or NASA, sites like Reddit still use pylons. IF you think it went the way of the dodo, I'd suggest doing a bit of better research before predicting the future :D Because IMO you are seriously off here.
      - mhd 9y ago
        I'm talking about the trend of build-your-own frameworks, not the software itself. Heck, there are enough sites out there still using Zope, MASON and Aolserver.
LocalPCGuy 9y ago
> still it accomplishes everything Ember did That isn't really accurate unless you are adding additional libraries to accomplish all of the things Ember does. I'm not arguing with the rest of your post, just saying that statement is incorrect (in that it doesn't tell the entire story).

finchisko 9y ago

"still feel strongly that if your app is large and serious you are going to need that stuff." My approach usually is, start minimalistic and if you need additional stuff, you can usually add it later. That is why I like React. For example if I need router, I can choose from many implementation, but there are also cases when I don't need it all.

BigJono 9y ago
This is a very good way to go. In my experience, adding a new tool can take a day or two of refactoring in a medium sized project; but removing one can take a week. Removing a bunch because you completely over-engineered the solution and can't maintain it can often take a month, or even get dangerously close to "scrap it and rewrite" territory, which is a complete death sentence for a small company. Unless I'm working with people I know well, I'll often elect to start off a fresh project with just React and maybe Redux, and build from there. Even if I know full well that we'll need some stuff like thunk and react-router, my preference is to leave them out and let the team run into the problems they solve before we introduce them. IMO even if just one team member gains a new understanding about why their tools exist and why they're using them, it's worth a bit of refactoring.
- mnutt 9y ago
  I can see where you're coming from, but I tend to bucket apps I write into either general use case, mostly business-logic apps, or highly specific services. (say, a network proxy or compositor or something) The general use case apps all tend to share a good deal of requirements (multiple pages, authentication, forms, etc) and while it would certainly be possible to pick and choose each component, it's nice to have a shared set of functionality that is well-tested together and that stays the same between multiple projects and teams. I think adopting something like ember is pretty much the opposite of "can't maintain it" since while I understand how it works internally, I don't actually have to maintain it myself. In my experience I've seen more instances where we ended up ripping out a homegrown library to replace with a community-supported solution than the other way around.
  - 9y ago