Ember.js Prototype Requirements

[DavidLiedle]

Further reading: http://www.omh.cc/blog/2017/jan/13/why-ez-should-adopt-emberjs/

---

Request For Comment

Further clarification:

• Let's determine whether there is community interest in developing an additional Admin UI solution, without eZ's direct involvement, for those that wish to live and work in the world of Ember.
• Also, let's brainstorm not what Ember can do for eZ developers, but what eZ can do for Ember developers. (See comments)

[omh]

If eZ is leaning towards a hybrid model instead of SPA I would not use Ember. While it is possible to use Ember in a hybrid model you wouldn't really be able to take advantage of all that Ember can offer. Other smaller libraries would probably be better then.

Of course I think that a hybrid model would be a mistake. It is easier for developers to extend the admin as they are already familiar with the Symfony stack, however I don't think that would lead to the best possible admin. Whether you like it or not it is in the Javascript space where all the innovation in front end is happening. I don't think the decision to make the new admin a SPA was wrong. However the implementation was somewhat lacking and the API was too chatty.

SPAs are very well suited for dashboard and admin interfaces. With a component oriented framework (such as Ember) it should be fairly easy to extend by allowing developers to swap out components for their own.

[DavidLiedle]

@omh Good points, all of them. While it's true that a Hybrid Model (also not the approach I would argue for, but one I can support as I see its value to the community) will not be able to take full advantage of all that Ember can offer, perhaps we can brainstorm ways that Ember developers can take advantage of all that eZ has to offer.

The idea here is that, while we may not build the new Admin UI using Ember, perhaps we can build it in a manner that makes it super easy for Ember teams to use and reuse.

Two thoughts come to mind:

• webcomponents: Wrapping our Admin UI components in a web standard should keep it Ember-friendly (as well as all the other full front end frameworks)
• SDKs: I'm not familiar enough with Ember to know if it has any unique conventions which would merit an SDK dedicated to Ember, but in general a JS solution should be consumable by Ember teams. Does Ember have an ecosystem (think npm, bower, packagist/composer, etc) that we should look into and consider for community support? [Update: I see this site https://www.emberaddons.com/ but not sure if it is authoritative]

[omh]

I think the best eZ can do to be Ember-friendly is simply support the JSON API standard. This will allow Ember apps to consume eZ API out-of-the-box. Ember is a bit like Symfony, but for the front end where it tries to cover all areas (data persistence, routing, templating, build tools, etc). It doesn't really make sense, imho, to spend much effort, perhaps with the exception of web components, to accommodate Ember in extending the admin interface. Just like eZ doesn't spend much time accommodating Laravel or other PHP frameworks. You can use them, but it doesn't make much sense.

[andrerom]

@DavidLiedle Let's close this, if someone wants to prototype it we can reopen. And I second the suggestion to move closer to JSON API.

[DavidLiedle]

Cool, great discussion guys! This seems to cover the topic fully. If anyone is interested in creating an Ember.js prototype, ping us and we'll get you set up!

Closing this issue here.