top | item 13979474

(no title)

EvilTrout | 9 years ago

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.

discuss

order

k__|9 years 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. :/

_____s|9 years 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!

elwayman02|9 years 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?

824ueirwfjd|9 years 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.

LocalPCGuy|9 years 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).

mwpmaybe|9 years ago

Glimmer.js may be more your speed!

finchisko|9 years 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|9 years 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.