Rebuild Admin UI in Ember

[talon]

Maybe?

[nicolasembleton]

Hmm... I was thinking about the same but in AngularJS. And then I asked myself 'would be cool, but... would it be useful?'. Hadn't find an answer yet. What's your views on that?

[davidemoro]

I was thinking about the same thing using AngularJS instead.

[izifortune]

+1 for AngularJS

[j-san]

-1 for Angular, had bad pro experiences.

I don't have experience with Ember but personally i'm a happy Backbone user, it is more simple, convenient and effective thant Angular.

[nicolasembleton]

@j-san I would be happy to hear about your bad experience with Angular. I worked with both Ember and Angular and I think they're both good. I would be in favor for Angular but either way is good for me. However I'm just curious if there's any benefit to do that. It's a considerable effort, just to redo the UI, the forms, the events, and I'm not sure there's any gain. In my opinion we're just better off with having Backbone as a back office - doesn't prevent us from hacking an Angular app on the top of it, and then doing anything we want with the 'front' office. And Backbone is simple enough for everyone to catch up on it. imo.

[rezakhanmirzaee]

@j-san please explain your bad experience with angular

[j-san]

@nicolasembleton @rezakhanmirzaee Angular is complex and make obscure magic for simple things like scopes, services or modules and sometimes $scope.$$apply generate more instability than real value. Angular modules make duplicate job if you work with Require.js, if you have a better solution than Require.js for code minification that works with Angular modules please let me know.

The biggest surprise was that i had a lot of pain to implement unit tests while it is the key objective of that choice.

I thinks there is good ideas like directives and very clean implementations in Angular but also too much tricky stuff.

I started with Angular in Version 1.0.X for 2 projects and leave it in V1.2.X.

[riconegri]

+1 for AngularJS

[talon]

An Ember Proposal

Ember Has the Best Router in the Game.

The URL is very important and Ember makes it a first class citizen. Every Model View And Controller is mapped directly to a path in the URL. As it relates to KeystoneJS having clean well thought out URLs makes it easier to direct clients to specific points in the Admin UI.

Dead Simple Components.

Ember's components follow very closely with the web components spec and are dead simple to implement. The primary advantage with components and KeystoneJS is the ability to modularize the fields and forms in the admin UI in a very clean way.

Ember CLI ->

This tool is invaluable for very quickly setting up an Ember application. It defines a beautiful directory structure for you so you can focus on building the application.

It solves a lot of problems through its heavy use of conventions over configuration. This allows for faster application build times and pristine maintainability.

For a lengthy discussion on Ember VS Angular as it relates to Admin UIs I highly suggest you check out this blog post about Ember by the Ghost Team.

[webteckie]

+1 Angular

I'm biased here as it is the framework I chose for my apps. However, I think the separation of concern in the framework is great, the many out the box services and directives provided cover a lot of ground, and once you get going is fairly straightforward. However, because Keystone lets me use whatever I want for the front end UI I'm not too strongly as to what is chosen for the Admin UI. Ultimately I guess it would depend on how much support for the framework used there is in the KeystoneJS community.

But if Ghost already decided on EmberJS then why not KeystoneJS try something else...AngularJS :-)

[fbeaudet]

I used Backbone a lot and love its simplicity and how it integrates with underscore. I don't really know EmberJS and AngularJS. I'm currently reading about Ember.js.

I'm curious about @JedWatson's opinion on this subject. It means a lot of changes from server to client-side.

[nicolasembleton]

I think the main question of "would it be useful?" hasn't been answered yet.

What are you guys argument of changing the framework for the AdminUI? What would we gain?

On my side I would say:

1. Ability to reuse components like the form builder from the backend to the front-end easily. Since you canr really make it a breeze. (either framework)
2. It's cool
3. It's kind of future proof? Because those framework are packing a lot of stuff that are useful for mobiles and solid components
4. And probably a good way to make it easy to augment. Once it's in angular/ember we can easily add reusable code to the stack.

What are your views on the actual problem? (sorry for actually starting the debate of framework in the first place) On May 27, 2014 5:07 AM, "Frederic Beaudet" notifications@github.com wrote:

I used Backbone a lot and love its simplicity and how it integrates with underscore. I don't really know EmberJS and AngularJS. I'm currently reading about Ember.js.

I'm curious about @JedWatson https://github.com/JedWatson's opinion on this subject. It means a lot of changes from server to client-side.

— Reply to this email directly or view it on GitHubhttps://github.com/JedWatson/keystone/issues/387#issuecomment-44220723 .

[fbeaudet]

Exactly @nicolasembleton. The only real advantage I see for now is less server operations. Main downside is code complexity. Guys ?

[talon]

I see the benefits being extensibility and maintainability. After the initial refactor expanding functionality will be significantly easier.

[fbeaudet]

@LegitTalon +1

[nicolasembleton]

Yes. I also think so. It was my point #4. So I +1 too.

But I'm a bit worry that it distracts us from the really needed features. How would such backlog item weight against some other backlog items like high level features?

On the other hand it's one way towards a more configurable and themable AdminUI. So I think it worth the work.

My guess is +1. On May 27, 2014 6:41 AM, "Talon" notifications@github.com wrote:

I see the benefits being extensibility and maintainability. After the initial refactor expanding functionality will be significantly easier.

— Reply to this email directly or view it on GitHubhttps://github.com/JedWatson/keystone/issues/387#issuecomment-44224130 .

[jamlen]

I agree with @nicolasembleton, in that I think that this distracts from other really needed features...

Personally, I'd rather see progress on the User Roles #334 now if some framework like Angular or Ember will really give benefit for something like this feature, then I'd be interested, but I don't think there is any point if it is just because it is cool! I also liked the suggestion for using DryWall as that seems like it would move a lot of the Admin features forward.

Also @robashton is quite vocal in his opinion of Angular - now I'm not saying I agree with him but he does raise some interesting points... I have not really looked in depth at either Angular or Ember and am interested in peoples opinions.

[robashton]

I feel like I've been summoned.

I wouldn't take that article/rant as any reason to use or not use any particular framework. I don't feel as if choosing any framework over any other is going to impact on success or failure in a project.

As a side note, this issue is a weird one - why rewrite something in a framework unless it is going to fix a particular problem you're having?

[nicolasembleton]

Good thing is 'medium term' we can gain benefit as mentioned by @jamlen from the UI rewrite. But I believe not short term. Also the rewrite will have to be synced with the current system as they will both progress at the same time.

I would suggest some UI automation/acceptance/regression tests to be done prior to getting into the UI framework rewrite.

Finally one of my personal long term grail would be to get the form builder done in the client.

[robashton]

Also, funnily enough I'm actually using Keystone in a project at the moment - I don't think I've once given a thought to how the admin UI has been implemented - I suspect I'm probably representative of most users there.

[nicolasembleton]

@robashton I would tend to agree with you.

However one 'problem' to fix is the ease of maintenance, customizability and reusability of the AdminUI. Those could be easier handed with a framework like Angular.js or Ember.JS. It's not a problem "per se". On May 27, 2014 6:43 PM, "robashton" notifications@github.com wrote:

Also, funnily enough I'm actually using Keystone in a project at the moment - I don't think I've once given a thought to how the admin UI has been implemented - I suspect I'm probably representative of most users there.

— Reply to this email directly or view it on GitHubhttps://github.com/JedWatson/keystone/issues/387#issuecomment-44259492 .

[ignlg]

From my point of view, it's too soon to rethink the Admin UI. I would work on the actual one a little more before that big change. We need to learn more about what is right, what is wrong and how to improve it (roles, sub-schemas, static pages, etc).

Also, I'd suggest to prioritize Admin UI tests before any movement in this direction.

[nicolasembleton]

I think short term tests is the way to go. Since it's a mandatory move either way. +1 for adding it to the backlog.

[brianjd]

+1 Backlog

[talon]

I agree tests are an excellent first step. But I think the refactor should be considered as a priority. The current UI is not too complex but not well suited for extensibility and if it were to be cleaned up then execution time on things like User Roles (which I greatly desire as well) would be much faster.

I think there are two major steps to any new KeystoneJS functionality, write code and update Admin UI. It would be beneficial to make the latter step easier.

I might spend some time this evening and do a quick mock up of the KeystoneJS UI in Ember and post a link here. I don't think the rewrite would be all too time consuming.

[JedWatson]

Hey guys, thanks for all the ideas and feedback on this.

The intention is definitely, at some stage, to switch to a more sophisticated application framework for the Admin UI.

One of my main goals is to make it so you can break it up into smaller, reusable components and drop them into the front end of your application (including "private" front-ends like custom dashboards).

The other is to open the Admin UI up for customisation, so you can add-in buttons, forms, and entirely new views as well as custom themes and components.

How we open up an API for custom field types will also play into this.

I've been thinking that rebuilding it in polymer might be a great way to go - imagine being able to take an element for an edit form and drop it into your own application and get the auto-generated form + processing automatically... or an element for the list UI, with configurable fields and restrictions on which data is actually available. Or just an element for an address field. Big configurable blocks made up of little configurable blocks, and you can use the highest level block that suits your requirement.

Another possibility I've been looking into is component, which is by the guys at segment.io including @visionmedia who builds awesome stuff (much of which Keystone is built on).

Anyway, that's the vision.

Aside from that, the biggest question that is blocking the plugin system is: do we want to stick with server-side form generation and processing, or switch to a client-side web app that runs against a set of APIs?

At the moment it's all server-side, which means we've got great support for server-side form processing, which is easy to drop into the front-end of your app regardless of which framework you're using (or not).

In some senses, it would be easier to keep this in place and just do some awesome stuff with progressive-enhancement techniques. Because then you could easily specify, say, a Jade (or Handlebars / EJS / etc) template to drop into a form and it'll be processed on the server with the full functionality available to the Model (inc. virtuals, schema methods, field-type methods, etc). I think it also lowers the barrier of entry for customising the Admin UI because people won't have to learn Ember / Angular / whatever we go with.

On the other hand, moving to a client-side app architecture would enable a faster, better UI. There's a lot that we're not doing yet in the Admin UI that I'd like to, which would be easier to do if it was built on a good client-side architecture.

Features like sub-schemas, or being able to create related items inline, would be easier to implement if we did away with the server-side form generation and processing.

If it weren't that we'd effectively be blocking (or hampering) usage of server-side methods, virtuals, etc. by moving client-side I'd be leaning more strongly towards client-side.

In any case I think that we need to make a call before opening it up to extensions, because if we do server-side extensions today then switch to (component / ember / angular / etc) in a few months it'll be an upgrade nightmare.

So I'd say this isn't urgent, but worth discussing and investigating, so we can make some decisions for the longer term. It might be a good idea to work on streamlining the current implementation in the meantime too, and see how much better we can make it without a framework.

@LegitTalon I would love to see your mock up of the Admin UI as an Ember app, so we can talk about some real code. After reading @wycats's input on Ghost's discussion, I'm keen to check it out.

Other experiments I'd be interested in:

• Polymer or Component proof of concept
• Backbone for routing & models, React for views

... as well as

• Hybrid server-generated forms with client-side enhancements (closer to how it currently works but with a real client-side architecture, possibly custom) vs.
• Entirely client-side application architecture

... with a view to establishing how it would work in terms of a more extensible Admin UI (custom template / view injection, custom field types, etc)

Aside from the issues I see coming if we implement server-side extensions then go client-side in the future, I think there's something to be said for enhancing what's there now and waiting for the web component implementations to mature.

All said and done, granular permissions / user roles, integrating busboy so we can upgrade express, cleaning up the field types and a vastly improved test suite are probably the highest priority items on the roadmap.

[webteckie]

How about building standard REST APIs onto the models? It would then be "easier" to adapt a client framework against standard model APIs, IMO. Someone seems to have already started/attempted something at https://www.npmjs.org/package/keystone-rest

[britztopher]

+10 Angular JS

[talon]

@webteckie :+1: definitely need a REST option in core KeystoneJS.

[nicolasembleton]

Yes. The rest + testing + plan from jed seem to be the way to go. +1 On May 29, 2014 8:42 AM, "Talon" notifications@github.com wrote:

@webteckie https://github.com/webteckie [image: :+1:] definitely need a REST option in core KeystoneJS.

— Reply to this email directly or view it on GitHubhttps://github.com/JedWatson/keystone/issues/387#issuecomment-44482398 .

[balupton]

A few points worth noting in the discussion.

The problem with angular and ember and whatever else, is that you will only get those who like those frameworks onboard. As we can see from this discussion in the way the +1s go. Someone who knows ember will feel alienated with a angular codebase, and vice versa. CoffeeScript VS JavaScript anyone?

The problem with component.io are:

1. Use of pre-processors are discouraged, not by opinions, but the architecture of component.io — you must commit compiled files to your git repo.
2. If github goes down, component.io goes down.
3. Components are not guaranteed to talk to each other, you still end up with the alphabet soup issue that the microjs ecosystem currently suffers from.

Component.io was a good showcase to create discussion around the problems with npm. Which has worked well.

Another thing worth stating is that while angular, or ember, or whatever theoretically support web components, their framework architecture promotes the use of coupling — by promoting that components be developed with context of their surroundings.

We don't want a situation where someone wants to contribute to the keystone admin UI, but then has to spend a few months learning a client-side framework in order to do so.

This is a nice area that more low-level solutions like polymer avoid. Each polymer item is completely isolated, and by design promotes cohesion. It's also nice, as it would be agnostic to the framework religious wars, as polymer is going to be the foundation of angular 2, and perhaps even compatible with ember from what I've read.

All that said. I'm not against using angular or ember. It's just whatever is chosen, the flaws must be as well known (if not better known) than their benefits.

[balupton]

Another series of dialogue worth pursuing, along with the technical aspects, is more along the lines of the philosophical tone @JedWatson instigated earlier. Specifically being, what would this mean for Keystone a few years from now.

Currently keystone's niche which it does better than anyone else is being a framework for creating content management systems. It kicks butt at that.

Currently, CMSs are still defined in the traditional sense of being backend operated. Single page web apps (SPAs) are new to here, and have not yet applied to the CMS world.

Now where this comes into relation is that the admin UI sets the precedent on what the ideal keystone app is. Currently it does well at that in the traditional CMS sense. The keystone admin is a great showcase of how to build your own app, there is high coupling here.

Moving the admin UI to a SPA would cause friction during the development of the maturity of the SPA CMS comes to be. For instance, people would be building traditional CMSs in keystone, while the admin UI migrates into an SPA. Issues here being:

1. Users now lose their sense of grounding, having a good solid base (the admin UI) to refer on
2. Users now have two seperate concepts to grok — the traditional CMS that keystone promotes, and the SPA that the admin promotes
3. Users now have two seperate code bases to contribute to — the library of traditional CMS extensions for the CMSs they make, then the separate library of the SPA CMS that the admin UI is.

In this sense, keystone really has a decision to make:

1. Does it want to remain a traditional CMS provider, stable choice forward?
2. Does it want to have a split of traditional CMS architecture for users, and SPA CMS for their admin UI?
3. Does it want to go completely SPA for their users and backend?

Thirdly, another important concern here is that migration to a SPA for a backend could fragment development efforts if it is an all-encompassing initiative. It may still be possible for keystone to say "We are no longer developing the existing admin ui, and are now putting all admin resources into the new SPA" but even if it is still possible, it is incredibly risky, for something that may have no pay-off in the end besides technical masturbation.

A route that seems to work well here, is to have any SPA side of the admin come naturally in the existing admin. Where a new area would be best served by a completely client-side solution, implement it as such. Poylmer is a good fit here, as we could drop in polymer for certain things, and replace things bit by bit, without breaking anything. However, this path does not address the big architectural and philosophical issues stated earlier, it's only a possible path forward.

[developer-don]

Though a little dated, this article from LinkedIn Engineering comparing a number of templating languages may be of use. The client-side templating throwdown: mustache, handlebars, dust.js, and more

[JedWatson]

The time has come, and we're going with React: #503

There are a lot of good points in this thread; to wrap up quickly, the move will allow us to make a lot of improvements to the Admin UI more easily, and remove some blocks implementing other high priority features.

re: @LegitTalon's original Ember proposal, React also has a great router (react-router) inspired heavily by Ember's, has a component architecture that I think will work very well for Keystone, and also has a great developer workflow with grunt and browserify.

The other thing React has is a good story for crossover between the server and client, and I'm hoping we can make great use of that.

Ultimately there are a lot of great frameworks and I'm sure others would work well too, but we have to pick one, and React seemed the best fit :)

[talon]

React is the bees knees! Huzzah!