[Discussion] The future of Ghost's admin UI

[ErisDS]

There has been much discussion, originally starting here: #951, and most recently in IRC around the future of Ghost's admin UI and the frameworks and tools that it should use.

This discussion is driven by a number of problems that are present in the existing implementation. Any discussion around solutions needs to carefully to consider all the problems that we face in the admin:

1. The admin is halfway between a one-page app, and a multi-page app, resulting in confusion between what goes where, and code split between the client and the server.
2. The confusion and disarray has lead to really poor mobile support
3. A complete lack of data binding, leading to code like this (see #550)
4. No memory management for views (views are never destroyed) (see #951)
5. Views are doing transitions (animations) manually (see #951)
6. Really ugly routing (see #951)
7. Most of our stuff is rendered client side, but is this bad? interesting article
8. Our code is really really fragile. It's easy to break saving, or uploading, or something else critical.

   Discussion point 1: What other problems does the admin suffer from? Can you help us better quantify any of these problems?

It would be great to develop a set of principles / statements that need to be true for any new solution like:

• Data-binding is handled automatically.
• Sub-page routing is easy

Do you have examples of bits of the admin UI that you think are particularly dire? Are their problems you anticipate we might have if we moved from Backbone? Etc..

Discussion point 2: What is the best structure for a complex client side app like this?

This sort of depends on the tool used to build it, but also has implications for choosing a tool.

Is the Ghost admin a single page app, or a collection of single page apps? If you take the dashboard into consideration, I believe that alone is a single page app. The editor is probably the same.

Do you have ideas on how to structure the admin UI, and how to ensure it works as a whole?

Discussion point 3: Is backbone the best framework for the job?

There are many other potential tools we could use, and there are a few main solutions that we consider to be on the table:

1. Improving the current backbonejs implementation by adding more underlying structure and using additional tools like marionette and rendr
2. Switching to emberjs
3. Switching to angular
4. Something else entirely?

Do you have some relevant experience with one of these solutions that you can tell us about? Are you able to put together a code example or demo that shows what it might look like, or specifically how a problem is solved?

Do you have time to implement a more complete demo / example of one of the key features, like the editor, or the post-settings menu?

Please note:

Discussions on topics like these can be hard to keep objective, so I'm going to lay out some ground rules. Comments on this issue should contribute something of real value to one of the above discussion points:

• experience or insight that is relevant to one of the discussion points
• an interesting article providing insight on how other people have solved
• a demo or code example showing how a tool could solve a relevant problem

Please do not post subjective comments suggesting which is your preferred framework, and although we all know the hamster IS a valid reason to choose ember, please keep those sorts of comments to IRC (please)! I have the power to delete comments, and for this thread, I may make use of it without warning :smiling_imp:

Next steps:

This is a call to action for our community, a place to come to put your thoughts, ideas, examples and other contributions. We will then use one of the public development meetings to discuss this further and come up with a decision. I propose that we aim for the meeting on Tuesday 25th February.

update: moved back from 18th to 25th

[jgable]

Read an interesting article comparing the three frameworks yesterday. Gives an even handed survey while still giving an opinion based on what you're trying to build. I'm interested in what other people think about it.

What other problems...

I think you've named most of them. I think the problem is a lack of clear guidance on what client side developers should be doing and organizing their code; which is exacerbated by not having a more opinionated underlying framework.

But, to be more specific to the two items you mentioned; if we stick with Backbone (more opinion on that later) we should use Stickit for binding and our routing can be refactored to instantiate "controllers" to handle navigating from/to same pages on a controller and to other controllers. I really like Chaplins implementation of a router, but Marionette looks to do about the same type of thing.

What is the best structure...

I think the best structure is a client side single page app (more like a collection of single page apps like you say, except no refresh between apps) with fine grained modular code using something like requirejs or es6 loaders that will let you dynamically require code as you go between the different areas of the site. The admin side doesn't have to worry about SEO concerns and the requireJS optimizer can build a first page bundled script to keep initial page loading fast. Combined with something like rendr you can get a great fast loading experience with the snappiness of a single page app.

Is backbone the best framework

I think Backbone is not a framework, when using Backbone you have to build a framework from the primitives it provides. This can be powerful or a burden and it mostly comes down to how much control you care to have.

I help build a large web app by most standards at Sprout Social (150 files and most having thousands of lines of code). We use raw Backbone and I feel like we've been through the full life cycle with it. We started out just using primitives and writing a lot of boilerplate code over and over, then we started doing the standard abstractions like TemplateView and CollectionView and now we're starting to really build a framework that is customized for our app and it's getting to be great. But, it took a long time to get there and we still have a lot of old code that is not converted left in our wake.

Like I said earlier, I think we've just not been confident enough to tell people what the app should be structured like and what patterns we should be using. We're probably going to have that same problem with other frameworks we choose unless we nail that kinda stuff down.

I think Ember is a good choice for Ghost because it's opinionated but smaller than AngularJS (my mistake, Ember is definitely the bigger framework). I think Ember is a natural progression from the existing code we have because we already use handlebars and Backbone. However, I have almost zero experience other than the anecdotal TODO app. I'd love to see someone convert some of our settings pages to Ember as an example, but if it were me I don't think I'd give it a representative solution having so little experience.

[javorszky]

Hm... how did the article measure 34kb for angular? The minified comes to 100kb on my computer...

[BiosElement]

I've done a fair bit of research on the topic in the past and while subjective, I'd say It's a choice between AngularJS/Backbone, if for no other reason than market penetration and popularity. Ember has been around for quite some time, and last year finally became somewhat stable, but from what I can tell, doesn't really have anything unique or unusual that wouldn't be easily done with another system.

Backlift.com has an interesting poll of some startup companies and what they're doing for the frontend dev work. The summary is Backbone is king, with AngularJS a fast growing but far second.

In terms of actual library size, Ember looks to be the largest, most feature rich of the pack and comes in at roughly twice the size of Angular, which again seems off to me as I'm not seeing where the added size adds much in the way of functionality. Perhaps I'm missing something?

After some further research, I found an AngularJS vs Ember article from an Ember dev pretty much slamming Angular and while the article itself is too biased to be worth much, The Reddit discussion is very enlightening. I'd like to point out comments by SubStack and davemo as being particularly useful.

I don't think there's a winner, but I see two real choices.

• AngularJS is the middle of the pack, a larger framework with two way data-binding that certainly isn't a bad choice. It's got a very strong backing (Google, Sony) and it's community is growing very rapidly.
• Backbone.js is just a library, and so is more difficult to compare. Keeping Backbone is going to be the simplest, if not easiest, option and there are a number of great libraries that should help resolve the issues that currently exist with it.

I'm leaving Ember out of this list as honestly I'm not seeing what it brings to the table. It's a monolithic system that has been around for three years without major uptake, looks to be the largest system under discussion and doesn't really seem to excel anywhere. Again, Please note that I have not used it and this opinion is purely from digging through their docs, blog articles and a handful of projects using it, so I may be missing something important, but as it stands I really don't see this as a strong option.

There's also a rather dated but still probably relevant Backbone vs AngularJS article that should be considered. Basically the argument is Backbone is larger than Angular once you're done adding additional plugins and systems to fill the gaps you need. Which is something to remember, if not obsess over.

It's also worth noting that I'm a slight Angular fanboy, but at the end of the day I think Backbone with a databinding system or possibly Marionette would serve Ghost better in both the short and long term.

Hopefully this is at least some useful food for thought. If It's helpful, I'll see about digging up info about what other major projects/sites use since that seems highly relevant to the discussion.

[LevelbossMike]

I have talked to @sebgie and @JohnONolan about this at a recent javascript meetup. I think Ember.js is the way to go for a large open source project simple because of the fact that it is a framework to build ambitious applications and is build up on the paradigm of convention over configuration.

I get the hype around Angular because it is easier to get started with than ember.js and that is thus easier to hack something working together more quickly. But I honestly believe that this is not an advantage for an ambitious open source project. Also I get the notion that Angular like Backbone is not a complete framework. They even state that on their homepage:

AngularJS is a toolset for building the framework most suited to your application development.

That also may be great for a smaller project where you need to get started quickly and include some stuff that you are already accustomed to but Ghost ist not a small project.

All of the problems @ErisDS mentions in the initial posting of this issue are easily manageable with an Ember.js-codebase and are solved by the framework itself without the need for workarounds.

• The frameworks abstractions make it easy to determine what should be implemented on the server and what on the client side.
• Data bindings are built right into the framework and can be turned off for performance reasons when and where necessary
• View Memory Management is built into the framework
• Routing is built into the framework
• Testing support is built right into the framework so it's easy to test drive development to make sure not to break stuff when adding/changing features

Plus Ember.js has very good abstractions around important parts of web-applications so it's easy to change/extend one part of the app without breaking the whole application.

Also I guess it may be important to the core team that new contributors can join the project easily and be productive pretty quickly. That is where convention over configuration shines. Everyone familiar with Ember.js could easily grasp the code and contribute in a meaningful way right from the start.

Of course there might be some people that know a lot about angular and how to build up a big application with it. But can the core team guarantee that these people will contribute code to the project till the end of the lifetime of the project when they started on an angular code base for ghost?

Especially in open source there might be times where some people have the time and passion to contribute to a great project like ghost and after some time leave the project because of multiple reasons (a new job, children, a new relationship etc.).

If the ghost core is build around conventions over configuration it will be much easier to compensate the loss of an experienced contributor than in a situation where a small number of people built up a framework with a toolset for building a web application development framework, contributed code and then left the project.

That is also I think the reason why a lot of big projects are built upon ember.js already. There are some examples of bigger open source projects that are already using ember (for example Discouse and TravisCI) and a lot of big companies are also using Ember on their important projects (Zendesk, Square, Bustle, NbcNews, Runtastic).

I have not heard about a big angular project. That my be my own fault but I don't think Google is even using it on their apps?!

Again, I get why Angular is popular. It seems to be easier to get started with than Ember. But the learning curve is only one decision criterion. Also this is not an issue if you have got some people around that already know ember. Also google trends also may not reflect the whole story about popularity.

I encourage the ghost core team to use ember.js. And I would be happy to help porting the admin ui to Ember :shipit:

[jamesbloomer]

I've been using AngularJS for about a year on a reasonably sized product (feature wise) and I've had no issues with it. The databinding is great, you can test everything due to dependency injection, directives encourage components and there's a reasonable community. Google do appear to be using it too http://builtwith.angularjs.org

Ultimately though any of the frameworks will do the job, one way or the other, so in the end it comes down to a personal preference...

[ErisDS]

Just wanted to say thank you to everyone who has contributed so far - this is excellent and exactly what we need. Please continue :+1:

To add a few points to what has been said:

• Ember's tight integration with handlebars gives it one bonus point for being a clear fit for the Ghost project. This alone however is no where near enough to sway the decision in ember's favour.
• Our existing solution is desperately lacking in opinions, which makes it incredibly hard to manage the frontend development of Ghost at this time. From my own personal perspective as the person hitting the green button, whatever final solution we choose does need to have significantly stronger and well documented opinions about how things should be done so that it becomes possible to measure and test PRs against guidelines. This should make development faster and easier.
• I'm concerned that no solution with backbone will have enough opinions without us putting in significant work. So whilst it has been argued (for good reason) that keeping backbone is the easier solution, I think the opposite could easily be true, depending on the toolkit we add in to backbone and how much work is required to get to a 'happy' place.
• Whichever solution we go with, I believe that strengthening our functional tests for the admin would be the most sensible first step towards a big refactor.

I personally have started to play around with ember, and intend to do the same with angular and backbone, having a go at recreating key bits of Ghost and seeing how the solution fits. However, I'm very keen to see this also done by others and particularly people who are experienced with each solution.

[hswolff]

To give some background before I jump in:

1. I used Backbone.js for over a year at one job. This was pure Backbone.js, no other view management software included. Used it to create a fairly complex application with many moving parts, used by a sizable audience.
2. I have been using AngularJS at my current job for a little over 8 months, using it to build highly interactive pages.

I sadly have had no experience with EmberJS so I am unable to give a completely rounded impression of which of these three frameworks would be most suitable for Ghost.

That being said let me talk as to the strengths of AngularJS and how it could benefit Ghost.

Testing First

AngularJS has made sure that all of its code is testable. It's a priority that is clearly visible through the tools that currently exist to test AngularJS code.

Each type of testing is available with AngularJS: unit and e2e. Because AngularJS makes use of Dependency Injection, all of these tests are easy to mock up. Creating a unit test for AngularJs is is straightforward and similar to our backend tests. That harmony is advantageous.

You can also unit test test code that modifies the DOM. For example being able to unit test code that is responsible for creating modals would be very nice.

e2e tests are covered by Angular's own e2e test runner called protractor. e2e tests look like this. Similar to the functional tests in the backend.

Encourages modular design

I'm aware Ember has components which allow for encapsulation of behavior and style. Similarly AngularJS has their own directives (a topic of much confusion and derision).

To understand directives it's important to understand that a main aspect of AngularJS is its HTML compiler. It's how it accomplishes 2-way data binding and how it knows how to amend the DOM according to your code.

A directive is allows you to extend the functionality of AngularJS HTML compiler. In a directive you can give the compiler knowledge of the <modal> tag. When the compiler sees <modal> in the DOM it knows how it should behave and adds that behavior.

Due to directives just looking like HTML it enables greater involvement from folks who would otherwise be put off by mucking with templates.

Learning Curve

At the end of the day AngularJS is Just JavaScript. It doesn't modify base object prototypes (Ember does so for its computed properties behavior).

There are five key parts of AngularJS, which when learned everything is built on them. I have actually already written an article about these five components on my blog if you'd like to delve a little deeper.

Past those 5 components all APIs that exist are ones you create, allowing everything to be domain specific to Ghost.

Browsing EmberJS it seems that its API footprint is large, requiring more blunt memorization of what does what. However EmberJS does go for naming what is most intuitive (similar to Rails) however it's close to impossible for one's intuition to be the same as everyones.

Other Points

I think the problem is a lack of clear guidance on what client side developers should be doing and organizing their code; which is exacerbated by not having a more opinionated underlying framework.

This is absolutely a result of the un-opinionated nature of BackboneJS - which is by design.

AngularJS doesn't truly have an opinion of how you should organize your code. AngularJS doesn't really approach large-scale application design from a top down view, i.e. here's a page, here's a controller, here's a view, here's a sub-view, sub-controlle etc. It mostly deals with one controller to a page and each page that requires more advanced behavior is comprised of directives.

EmberJS is absolutely the most opinionated of all three options discussed.

What is the best structure for a complex client side app like this?

In my opinion Ghost is a client-side application that is always entirely rendered in the browser. It supports routes so that you can reach aspects of the application directly.

On every page of the admin the server should return the same initial HTML structure. After it reaches the browser it'll inspect what the URL is and depending on the route will render itself.

This is what AngularJS and Ember recommend and are built to do.

I think Ember is a good choice for Ghost because it's opinionated but smaller than AngularJS.

Unclear what you meant exactly by smaller here @jgable but I'm going to focus on just raw sizes of the library.

I've done this estimation many times in the past as the answer always surprised me. Not going to delve into specifics here, welcome to do your own napkin calculations as well.

EmberJS has always clocked in as the largest library in terms of raw KB. EmberJS depends on jQuery and Handlebars. If you're using Ember Data then that as well.

Backbone.js depends on jQuery and underscore.js. Depending on if you use Handlebars or Mustache.js that size is also included.

AngularJS has no dependencies. You can optionally include jQuery if you desire, but to get an AngularJS application running all you need is one file.

File size is only a real concern for mobile applications. As I've seen EmberJS maintainers point out time and again, it's silly to compare file size of libraries when one single .jpg is usually bigger than all the JavaScript included on the page.

Still, it's something to be aware of.

I have not heard about a big angular project. That my be my own fault but I don't think Google is even using it on their apps?!

Google is using AngularJS in many of their internal projects. They actually presented at ng-conf where they talked about creating Massive AngularJS apps. Link to presentation, link to slides.

Of particular note is that AngularJS powers DoubleClick Campaign Manager, part of their ads product, their biggest money maker.

From the slides the application has 71,000 lines of JavaScript and is one of the oldest and largest AngularJS applictions.

A clear stamp of approval and adoption from Google.

---

Hopefully I've been as informative as possible while not being inflammatory.

[jgable]

@hswolff I was mistaken about the size differences between Ember and Angular, Ember is definitely bigger.

[friksa]

It seems that Ember's opinionated approach will help with a larger group of contributors... However AngularJs encourages code reuse and modularity that is critical for collaboration. Also, you will be able to re-use code if / when building native mobile apps. Here are some interesting articles that may help:

http://ionicframework.com http://nathanleclaire.com/blog/2013/12/07/dont-fear-directives-in-angular-js/

[trek]

Full disclosure: I don't currently use Ghost (mostly because I also don't blog) and am a Ember.js core team member. Although I'm on Ember.js's core team, don't think I'm not also a huge fan of other tools and frameworks: I've used Backbone, Angular, and Ember in anger and play around with React.js quite a bit. Based on that @jgable asked me to come weigh in on the discussion.

Having built stuff in all three, I totally agree with @jgable:

I think the problem is a lack of clear guidance on what client side developers should be doing and organizing their code; which is exacerbated by not having a more opinionated underlying framework.

and his assertion that

Backbone is not a framework

Backbone is not an application framework. Every Backbone app I've worked has only been a <scarequote>Backbone</scarequote> application in the sense that it required Backbone as a dependency. Building anything substantial absolutely requires you to layer additional code on top of Backbone.

Sprout Social took this route. Most of the apps at my job (Groupon) have taken this route. Making this decision has one of two outcomes: you end up with a codebase that is totally unstructured and patternless but maybe bound together by a beefed up routing layer or you eventually build a custom, internal framework that you now need to document and provide training for.

If the pain you're feeling with the admin UI is really a lack of proscribed structure, I don't think this will ease your woes.

A better option, if you want to stick with Backbone, is adopting a tool like marionette or chaplin. But, given the number of times community size/adoption has come up in this discussion, that's probably a poor fit too. You won't really be building "a Backbone application" anymore, you'll be building a Chaplin, etc application – Chaplin even let's you drop Backbone as a dependency – and the community of those developers is much smaller than the superset of Backbone developers.

Angular.js is also great a great tool, but will suffer from some of the same problems you might experience with Backbone. Angular itself is not an application framework: it's an HTML compiler (hence terms like "directives" and "transclusion").

Like @hswolff noted:

AngularJS doesn't truly have an opinion of how you should organize your code. AngularJS doesn't really approach large-scale application design from a top down view

If your problem is lack of application structure Angular doesn't provide tools to help resolve this. That's still all up to you.

This is also why Angular has a larger community than Ember: it's a lower-level tool and can be applied to more styles of development. The best pattern I've found for Angular is the mix of client/server rendering that you currently use. Serve a page whose HTML is an <html ng-app>, augment that otherwise static page with dynamic behaviors using Angular, when managing the statefulness starts to become too complicated declare "we should move this part into its own angular app!" and link to a new server generated <html ng-app>.

Managing long-running, wide/deep view hierarchy apps with Angular still requires custom application structure code.

Addressing some of the Ember.js-specific comments in this discussion:

It's a monolithic system

Don't mistake large or proscriptive for monolithic. Ember is made up of a bunch of smaller libraries that people use standalone and some external dependencies:

• RVSP (a Promises/A+ library)
• Backburner (a run loop library with event batching)
• route-recongizer (registering handlers for URL changes/generating URLs)
• container (dependency injection library)
• Handlebars
• jQuery
• ember-metal (a prototypal object system that inherits from Object and polyfills future features like Object.observe)
• ember-runtime (mixins for useful/common object behaviors like memoizing, freezing, enumerating, sorting, etc)
• ember-views, ember-routing, ember-application (what most people think of as "the framework")

that has been around for three years without major uptake

There are a sizable number of deployed, large production apps built on Ember from major and minor companies. Just some ones from well known companies:

• Vine
• Discourse
• American Eagle
• NBC news
• Bustle
• Balanced
• Zendesk's CS app
• Square's web dashboard
• Riak's control panel
• TravisCI
• Netflix's insight tools

looks to be the largest system under discussion

There is no escaping complexity. Any sufficiently interesting application ends up being roughly the same size regardless of JavaScript framework choice. Although, interestingly Discourse and Square both have smaller JavaScript sizes compared to Rdio and Basecamp despite being (IMO) similarly complex applications. Using less JavaScript than Basecamp I've always found especially eye opening because they adopted a mix-environment rendering strategy specifically to limit the amount of JavaScript required.

doesn't really seem to excel anywhere. and last year finally became somewhat stable, but from what I can tell, doesn't really have anything unique or unusual that wouldn't be easily done with another system.

We hit 1.0 in August 2013, use SemVer, and have a Chrome-style release cycle. So we've had five point releases with lots of bug fixes and new features without breaking backwards compatibility. Both Backbone and Angular have had post 1.0 breaking changes (granted: they've been small).

Not sure how much more stability you can ask for.

Functionality Ember uniquely offers for doing browser applications that you probably won't find elsewhere all in one package:

• URL focused app structure (we'd consider things like broken back button in your app a major bug)
• standardized locations for objects (either file or Global based, depending on your tool)
• passive code generation for default behaviors (which helps us cut down on boilerplate code)
• great developer tools
• a defined, SemVer release cycle
• a defined security policy
• a pretty cool, public roadmap

So, should Ghost use Ember as a framework for the admin backend? Not sure. I just don't have sufficient domain expertise with both to say, but it sounds like Ember is designed to specifically address many of the pains you're feeling building a larger app.

If someone with more Ghost chops wants to pair on a spike, I'm happy to make time (or connect you with someone) and generate real data to help make the best decision.

[hswolff]

Terrific comment @trek, really appreciate the insight.

The stark contrast that I seem to see between Angular and Ember is the nature in which the application is conceptualized. Please correct me if I'm wrong.

In Ember the application, for example the Ghost admin, is built as one whole, as everything that occurs inside of it is part of the Ghost admin. The application runtime is designed from the top down. When visiting a page the code path begins in a route, which passes a model to the controller, which then constructs the view and wires up the page.

In contrast AngularJS applications also have routes and controllers and views yet the emphasis is not there (although those are handsomely used). AngularJS encourages through it's directives to break up your application into smaller components where the functionality and behavior are isolated and specific to that area.

Those are, in broad strokes, the conceptual difference in approach between AngularJS and Ember, as I understand it.

Both allow for building massive and complex client-side applications, yet the approach to arrive at that product is different.

Two additional notes:

I'm aware that Ember.Component is designed to allow you to perform similar functionality as an AngularJS directive, however from what I've seen does not seem to be as big of a focus for an Ember application as a directive is in an AngularJS application.

If your problem is lack of application structure Angular doesn't provide tools to help resolve this. That's still all up to you.

AngularJS is starting to address this issue via giving guidance on best practices. They wrote a blog post yesterday where they shared a document titled Best Practice Recommendations for Angular App Structure.

[hswolff]

Ultimately I believe that both AngularJS and EmberJS provide the desired feature-set that we're looking for. We're in a lovely win-win situation :).

[friksa]

http://yeoman.io will also help with structuring the Angular project.

[trek]

I'm aware that Ember.Component is designed to allow you to perform similar functionality as an AngularJS directive, however from what I've seen does not seem to be as big of a focus for an Ember application as a directive is in an AngularJS application.

Ember provides behaviors for both top-down application organization (the routing, controller, data fetching stuff) and the bottom-up view organization (components). Both are a big focus of the framework.

Directives are a bigger focus in Angular that components are in Ember because Angular doesn't intend to solve these for you. Angular – and React.js for the curious – are both view layer libraries. Layers above and below are left up to the developer.

http://yeoman.io will also help with structuring the Angular project.

and

They wrote a blog post yesterday where they shared a document titled Best Practice Recommendations for Angular App Structure.

These both help you structure the files in a project, not the code. Not dismissing this – file organization arguments are the purest form of bike shedding – but this isn't the application structure I was suggesting Ember.js provides.

Although there is a file organization pattern that has emerged in the community (projects like Ember App Kit ) Ember doesn't care how your files are grouped or pulled into the final application.

Ember's application structure answers the "where, in code/flow control, does behavior X belong?"

This is helpful for two reasons: a) you can easily identify when an incoming PR has behavior in the wrong place b) anyone who knows Ember will understand the structure of your application letting them go directly to where they'd like to add or change behavior.

Even with a common file organization pattern, you'll still need to decide how flow control works at layers higher and lower than the view layer patterns Angular provides. You'll have to answer the question "Where does behavior X go? How does it interact with other behaviors?" Answer these and eventually you build a custom framework specific to your needs that uses Angular for views. Committers will need to learn this framework before being able to participate smoothly.

Obviously, if you went with Ember, they'd also need to learn Ember before being able to participate smoothly. There's a whole ecosystem of resources already made to help with that.

[pixelhandler]

One thing I value about any open source project is the community that participates in the life of the project. In addition to evaluation of framework/library features... I would suggest connecting with the communities that support the framework/library. People are far from perfect, but its great when you find a community that is very supportive as well as produces quality software. I have not tried Angular, but can speak for those who use Ember on a day-to-day basis. The support from other developers in the Ember.js community is pretty darn good, and there are many active Ember.js meetups.

[trek]

I've snagged four passes to Code School's Ember.js course for any Ghost developers who haven't used Ember.js and would like to evaluate it. I'm holding one for @ErisDS if she wants it and will pass the other three onto the whoever replies here first asking for them.

Only prerequisite is at least one Ghost.js commit.

[grayrest]

I follow Trek on Twitter and his comment of "if you have something to add, chime in" pulled me in.

The general problem with Backbone apps is what I call the idempotent update problem. Backbone works great when you can get the change event, call render, run your model through a template, and innerHTML it into the DOM. That last operation is idempotent, which isn't an issue in small apps but if the relevant portion of the DOM has any state (filled input fields, scroll position, non-delegated event listeners, sub-components, instantiated widgets) then the update will blow away all that state. I've been arguing for years that Backbone is a trap because this problem is hard to see in toy projects when you're evaluating the framework and it bites you as soon as your project gets large enough to need subviews. A quick glance through the Ghost client code leads me to believe that this is your problem.

Switching your view layer to React solves the idempotent update problem. By rendering the entire template into a virtual dom, diffing the virtual dom against the actual dom, and applying the minimal set of changes, React actually delivers on the promise of the Backbone change pattern. While I have not used Backbone in years, I believe the transition would be the easiest for your codebase and there are quite a few blog posts chronicling successful transitions from Backbone to React. Many include glue code samples.

I believe that the key to building large client side apps lies in controlling your application state.

Backbone is simple both in implementation and in concept but doesn't isolate you from state in the DOM nor save you from having to coordinate your javascript state and DOM state. This results in Backbone apps blowing up in complexity as they grow.

Angular provides two way data binding to solve the state coordination problem and correctly designed directives allow you to fully isolate your app model from the dom to achieve state control and the reasoning/testing benefits that go with it.

Ember provides the same benefits but as a framework, comes with proscriptions on how to use those pieces. This makes it easier for people to achieve state control (it's easy to NOT attain state control in angular) at the cost of having to buy-in to the framework, which makes transitioning into Ember harder. Both Angular and Ember have comparable complexity with different learning curves (early hump with ember vs the cliff wall of angular directives) and any large project WILL have an implementation of all of Ember's pieces.

React is simple in concept and complex in implementation. It does less than either Ember or Angular but pushes you very hard into full state isolation from the dom and therefore delivers the majority of the benefit with a comparatively small amount of conceptual overhead. Without any additional code, your templating language is optionally-sugared javascript. They consider this a plus, I consider it a minus and is the main reason to not adopt the library given your use of handlebars.

Ultimately, any of these will probably work for you. The most important feature is getting ALL your application state out of the dom and solving dom/model state coordination. I mostly felt compelled to post because I'm a fan of Ghost, nobody's made a case for react, and I think it's likely to be your easiest transition. FWIW, I generally use Angular for new projects I'm working on because non-directive angular is super easy for designers and I don't mind dealing with the complexity of directives.

[eviltrout]

Co-Founder of Discourse here and author of one of the most popular Angular vs Ember articles on the web (called "too biased to be worth much" in this very topic! :confused:).

It warms my heart that you guys are taking the time to consider such a large decision for your admin section and are discussing it publicly.

Discourse has had a lot of success with Ember, and I would love to see another large open source project use it so we can trade code and grow in the ecosystem together. Having said that, the really important thing is that you impose structure on your codebase.

It's been mentioned above that Ember is more opinionated than Angular, and I'd like to echo that sentiment. I keep asking Angular developers I respect, if you were to go to another company and open up your IDE on their Angular project, would you know how the code is organized? They always respond "no."

That's not to say Angular projects can't be organized and well designed with established conventions, it's that you have to roll it yourself. And some developers like that!

If you have a particular structure in mind you'd like to establish and enforce, Angular might be for you. If you want to work with a pre-established and battle tested structure, Ember might be for you.

One final thought about popularity. It is undeniable that Angular is more popular than Ember in terms of search engine traffic and such. But two points about that:

1. Where are the large Angular apps? It's been successful for many small apps, but where are the Vines and Squares and Groupons? Google uses it for the Playstation interface, but it doesn't even use URLs! Further, where is the Discourse of Angular? If there is a large and popular open source Angular app, I am not aware of it.
2. If you are choosing a framework based on popularity, why not build the server side portion of Ghost in PHP? I know, I know, it's a :trollface: reason, but my point is there are many good reasons to choose a less popular framework if it suits your purposes.

[manuelmitasch]

I am giving an "Ember Intro and Concepts" talk at the stahlstadt.js meetup in Linz on February 19. I will try to implement a short demo using Ember for the ghost editor and use it as code example for the talk. I will post a link to the repo when done. @sebgie and @JohnONolan feel free to join us again at the meetup!

[ErisDS]

Thank you to everyone who has come here to add something to this discussion :+1:

It seems to me we have reached a point where the conversation has become about angular vs ember, and backbone has fallen into a clear 3rd place - although nothing is certain yet ;) It does seem that our community is keen to take a leap and try something new and that is exciting to hear. React.js has been mentioned to me a couple of times, and I do believe it is worth consideration.

I am not sure how much weight a particular library's popularity or marketshare/adoption should impact our decision. The question on my mind is, if we switch to ember / angular / react are Ghost's contributors going to be onboard with the change? From the reactions so far, it seems everyone is keeping an open mind about getting behind whatever solution we determine is best, which I feel is really wonderful. Even more interestingly, by switching, will we find more people getting involved? I have to say I have been impressed with the contributions and keenness I've seen from people active in the emberjs community.

I have one lingering question / issue that I didn't mention in the initial post, which is the fact that currently a couple of our handlebars helpers are duplicated server and client side. As Ghost develops, that body of code will get larger, and so looking at ways that code can be shared might ought to be considered as part of this discussion.

Moving forward, I think this discussion warrants a little more time and discussion, so I think we are probably looking at the 25th Feb meeting, rather than this week. Largely this is to give us time to try out each of the frameworks. I think running some spikes would be very worthwhile at this stage - I have raised one for all 4 of the solutions mentioned:

• ember #2200
• angular #2201
• backbone + #2202
• react #2203

I will try to make time to personally try out each potential solution before we have a meeting to make sure I can guide the discussion appropriately.

[stefanpenner]

the (in)famous ng-embereño: comparison of ember and angular -> https://docs.google.com/presentation/d/1e0z1pT9JuEh8G5DOtib6XFDHK0GUFtrZrU3IfxJynaA/preview#slide=id.p

[JohnONolan]

@manuelmitasch That is awesome - we'll be there :)

[javorszky]

@trek, may I have one of the ember.js codeschool passes if any are left?

[ebryn]

@ErisDS since you mentioned server-side templating, I wanted to let you know that we're going to be baking in support for server-side rendering of Ember.js applications this year. You'll be able to use the same templates/helpers on both ends.

[trek]

@javorszky for sure. Email me the address you used to sign up at Code School: trek.glowacki@gmail.com

[sophiebits]

Just wanted to mention that React supports server-side rendering already. Simply call React.renderComponentToString and an HTML string will be returned; embed that in your page then call React.renderComponent with the same props, and React will "adopt" the server-rendered markup and attach the event handlers.

[vjeux]

React dev here. I just want to mention that one of the strength of React is that you can progressively include it in your codebase.

At Facebook we don't really believe in big throw away everything and start from scratch rewrites. Instead, the migration path is to build new features using the latest available library. We convert the biggest call sites to the new library. And over time, when you go back to an old part of the code base, you take the time to upgrade it to the latest library.

This methodology worked really well for us and React is very well suited for it. You first convert a small view in React, then another ... Then once enough views are converted you can convert an entire page etc... In a sense React spreads nicely into your code as time goes.

This way, you don't do any upfront investment. If you like it, it will keep spreading, if you don't just write your new views with something else and when you come back to React code, just nicely convert i away as you go

[ebryn]

It's a common misconception that Ember.js is monolithic. I can assure you that isn't actually true. You can pick and choose the parts of Ember that you want or need (for example, the router is totally optional). Our build tools even support picking and choosing which packages you want. You can use it today without jQuery (you will need to shim and have an event delegation library, or even easier use a super-lightweight custom jQuery build).

This is really just a documentation problem. You can use Ember.js just like you would Backbone, Angular, or React to "sprinkle" in richness.

[trek]

So, a few enterprising people have started a spike already. Comments like https://github.com/manuelmitasch/ghost-admin-ember-demo/commit/fba3ab0a59238290c85d4fa0d7c6ed1be2a8a82e#commitcomment-5393621

is an example of what I meant when I said

Ember's application structure answers the "where, in code/flow control, does behavior X belong?"

[timruffles]

Considering Ghost is going for Node.js as a 'platform for the masses', I'd argue that community popularity is a very important vote in Angular's favour. It's trending higher than node! I think it's extremely likely to become the default choice for SPAs, in the same way Twitter bootstrap is the default web framework (to stress: this is entirely independent of quality).

A lot of people who aren't Node devs are very like to have, or develop in the near future, AngularJS skills.

[jgable]

@timruffles I've heard that argument, but the Ember community seems to be having a much better showing here, can you get some call outs to the Angular community to start joining this discussion?

[silentworks]

I use Angular for most of my work and think its a great framework if you already know how you want to structure your app, I will say however that based on the new issue tickets (#2201) that @ErisDS has opened about having handlebar templates on both the client and server, I don't think Angular would be a fit at all at that point as it has its own templating engine.

As stated if you are after structure and handlebar on both client and server, I can say only 1 framework mentioned here fits that and its EmberJS.

[timruffles]

I think the requirement was more sharing helpers than sharing templates, is that correct @ErisDS ? Makes sense as it's not a public-facing UI. Shouldn't be a big issue regardless of template system - Handlebars helpers should be very easy to wrap as AngularJS filters.

[CoreyRab]

If anyone else is interested in trying out the Ember course on Code School, just shoot a quick note to corey@codeschool.com and I will add it to your account.

[Globegitter]

I just wanna throw my 2 cents in as a potentially ghost-user, for future client projects (started evaluating it and it does look very promising). When I was completely new in the game I looked at both Angular and Ember.js and even though Angular hat the Google name behind it and Ember was still in it's pre-RC days I chose Ember.js and I can say it is really paying off. Things that I don't have to worry about anymore, purely because of the things ember does for you. With yeoman and ember-app-kit there are two amazing development/deployment tools and ember-extension makes debugging actually a quite pleasant experience. Speaking as a developer as well as a customer I sincerely vote for ember.

[halfdan]

Interesting article just popped up: http://readwrite.com/2014/02/06/angular-backbone-ember-best-javascript-framework-for-you

[yakovkhalinsky]

Just putting in my 2cents. I'm a current self-install Ghost user.

Not sure if you guys have thought about this, but wouldn't using an opinionated framework such as Ember.js lock you guys into using it for the long term.

Personally, I think the "small modules approach" that Angular.js provides gives you a much easier means of assembling a larger application out of smaller pieces.

Taking a longer term view of your project, I would shy away from building a dependancy on a particular framework.

I would advocate using non-Angular code together with Angular to help with code reuse and to also ensure you aren't strongly coupling your code to a particular framework.

So in short, if Ember.js is chosen is seems a minus that you need to assemble your code in a particular fashion, and that is a plus for Angular.js IMO.

Watching this discussion with interest. Disclaimer: I use Angular.js reguarly for work and personal use.

[tj]

web components, because everything else will be gone in a few years.. doesn't make sense to invest in those IMO, you really shouldn't need some crazy framework for a blog, modules are your friend. If anything I would choose Angular, the API is a lot nicer than the others, but regardless there are plenty of non-framework options that have better APIs than those mentioned, and don't include as much lock-in.

[tgriesser]

My go-to is now Backbone for routing & models, React for views.

I've been impressed with how React has been able to build something so simple yet powerful, really the first major leap since the advent of the MV* front-end app. While the others feel like incremental, opinionated improvements, React is the complete opposite. It does one thing (views) exceptionally well in new ways, and allows for true server-side view rendering with the same code and their "virtual dom".

Maybe a more prescriptive/opinionated framework is needed for a project like Ghost, but in my mind React is definitely worth some consideration. It has such a small learning curve, and would be a great candidate in terms of swapping out incrementally for existing Backbone views.

[ghost]

Sounds like you're using Backbone. As such, it's probably a good idea to stick with Backbone (3). Backbone supports Rivets.js for data binding. According to Hipster Dev Stack:

If you want the indie coffee house to the Starbucks of Angular.js then check out Rivets.js.

For an example using Backbone and Rivets, please check out an easy-to-run and well documented example I put together for a talk last week to see them both in action:

https://github.com/jhabdas/chapless-rivetsjs

The above example uses the Chaplin library for application structure (2) and simple routing (1), provides automatic one-way data binding and an example of two-way bindings as well. It is built using an application assembly tool called Brunch (2), which helps developers build web apps while mitigating the risk of the app toppling over with complexity.

[samselikoff]

I still consider myself a Javascript neophyte, but at this point I've used all three major frameworks. I don't have a strong personal preference for any particular one; what I look for is which tool is most appropriate for the job at hand.

So, what job are we dealing with? The OP mentioned several things:

• "...confusion between what goes where"
• "...complete lack of data binding"
• "No memory management for views"
• "Really ugly routing"
• "Our code is really really fragile"

These items seem to be grasping for a holistic solution. As others have mentioned, the three frameworks exist on a continuum of comprehensiveness. A corollary of a comprehensive solution is one that is inflexible. So one way to think of the frameworks is

Less comprehensiveness,                                            More comprehensiveness,
more flexibility                                                          less flexibility

<------|------------------------------------|-------------------------------------|------>
    Backbone                            Angular                                 Ember

  Minimal solution               Midsize solution                  Comprehensive solution
  High flexibility               Moderately flexible                      Low flexibility  

It is clear Ghost is looking for a complete solution. Some have mentioned paring Backbone with React or Angular with non-Angular modules to get there. This is one approach. And the flexibility can certainly be a plus. But because these approaches were not designed from the ground up to specifically address all the points in the above list - and more - there will be architectural questions without an idiomatic answer.

This is also something to keep in mind when discussing the communities. Because Backbone and Angular are multipurpose, their communities are more diverse. As Ghost members start to build out their system, the community members, tutorials, and resources that will be most valuable will be those that pertain to the particular type of app they're building: namely, a complex client-side application to serve as a complete solution for Ghost's admin interface.

Building this type of app is the explicit goal of the Ember framework. Backbone's docs mention not painting you into a corner and Angular's discuss the ease with which multiple small Angular apps can be injected into a single page, perhaps within an existing app. This means Backbone and Angular are more suitable for many jobs that Ember is not.

But Ember seems particularly well-suited for the job at hand: building an ambitious web application. Somewhat ironically, this is the one thing that Ember does, and does well.

[ErisDS]

To add to @visionmedia's comment. This is a great introduction to web components: http://www.youtube.com/watch?v=fqULJBBEVQE&feature=youtu.be.

Whilst this is undoubtably the future, it doesn't feel 'ready yet' for use in a project like this. Having to depend on a pre-alpha shim library doesn't seem sensible, and at this point it seems to leave a lot of the specific problems we have unsolved. Although I'm yet to really deep-dive into it, it doesn't seem like there are a great deal of resources or examples of building a complex UI out of hundreds of components.

Yet when you think about the dashboard we want to build.. web components do make a lot of sense.

[pixelhandler]

I put together a blog application built with Express and Ember, which includes (end-to-end) integration testing using a live API. I'm using mocha (with supertest) to test the API request/response; and using Ember Testing helpers with QUnit for client integration tests. Both the blog and admin features are using Ember, but the admin features are only accessible using an admin route. For now I faked login. The client tests run using the live API so I'm not mocking anything (I use seeds to prep the database, RethinkDB).

When I decided to get involved using Ember I spent quite a bit of time studying other ember applications. I thought that since what I've been working on is a blog with admin tools using a lightweight API (node.js / Express)... that you may be interested in reviewing the code: https://github.com/pixelhandler/ember-app-builder/tree/blog

The example app is on the blog branch so if you clone the repo be sure to checkout the blog branch.

[zeppelin]

@ErisDS Ember and Web Components by @wycats explains the topic extremely well with a specific focus on where we are now, what tools we currently have - and how to get to WC-land in the (hopefully near) future.

[stefanpenner]

Although ember can seem inflexible, its more that it thoroughly paves the road which enables composition/reuse across many concerns. Under these paved roads, lie flexible primitives that allow the flexibility should you need it.

[hansent]

have you guys taken a look at / considered Vue http://vuejs.org/ ? It's more minimalistic than ember or angular in it's approach, but that's not necessarily a bad thing.

[leggetter]

TLDR; I agree with @visionmedia

A modular architecture is clearly key if the admin UI is going to become a larger app with multiple contributors.

We have an SDK with a codebase of around 150k LoC on top of which we (and our customers) build complex applications (SPAs) of around 50k LoC. We do this in a scalable (maintainable/extendable) way by splitting up our functionality into vertical slices called Blades - you can consider these to be a full piece of business logic within a component. In the future this is likely to be a composite Web Component (a Web Component consisting of many other smaller Web Components).

A Blade contains all the HTML, CSS, JavaScript, i18n, config etc. that is required for that piece of functionality. This encapsulation of assets and functionality, along with a loosely coupled architecture with only a few dependencies (e.g. a Dynamic Service Locator that we call a ServiceRegistry to access services - PersistenceService, LoggingService, EventHub), means we can build and run individual pieces of application functionality in isolation. We then compose those Blades into the application (see marketecture diagram, below).

Inter-Blade communication takes place in a loosely coupled way using either a specific service type (interface) retrieved from the ServiceRegistry or using the EventHub service.

All this results in highly testable and reusable code.

As a reference, here's a video of an old version of one of the apps in action (very web 2.0 UI) of our: http://www.youtube.com/watch?v=0CUXT9P7lNY

It's a trading app and I'm in control in the video - I'm definitely not a trader! Hopefully the video clearly shows how pieces of the UI can be broken up into Blades. We don't use Ember, Angular or any other mainstream framework as part of our core architecture. But we do pull in useful micro-libraries.

The way we're looking at the future of front-end web app development is that it's highly likely to be Web Component based, mixed with the use of a number of micro-libraries to provide the required application architecture - the foundation on which to build the app - or UI wizardry. There will always be room for frameworks such as Ember that are themselves composed of a number of micro-libraries.

Right now we use our open source toolkit, BladeRunnerJS, to enable us to build applications in this way. In the future I think it's highly likely that we won't need quite as much tooling in order for us to achieve the same results as we'll get a lot of what we need out of native web functionality.

The point - as I made at the start - is that a modular approach is key. And whilst Web Components may not be ready right now (I'm sure somebody has looked at Polymer), it is possible to build an application using the same philosophies right now and it's most definitely an approach which provides good results.

[btford]

A couple people have asked me to weigh in on this (since I'm on the Angular core team), but I don't think that there's much more to add.

I think your best bet in choosing is to try out a couple options and see what works best for what you're trying to build. I think AngularJS might be a great choice, but a lot it comes down to personal preference. The Backbone, Ember, React, and other JS framework communities have done a great job, so I don't think you'll be disappointed regardless of your decision.

A modular/web component-based approach might also be good. We're going this route in Angular 2.0.

Cheers!

[rvdende]

This is sounding more and more like an OS :) Count me in

On 18 February 2014 20:39, Brian Ford notifications@github.com wrote:

A couple people have asked me to weigh in on this (since I'm on the Angular core team), but I don't think that there's much more to add.

I think your best bet in choosing is to try out a couple options and see what works best for what you're trying to build. I think AngularJS might be a great choice, but a lot it comes down to personal preference. The Backbone, Ember, React, and other JS framework communities have done a great job, so I don't think you'll be disappointed regardless of your decision.

A modular/web component-based approach might also be good. We're going this route on Angular 2.0.

Cheers!

Reply to this email directly or view it on GitHubhttps://github.com/TryGhost/Ghost/issues/2144#issuecomment-35417559 .

Rouan van der Ende 072 470 3295 rouan@8bo.org rouan@8bo.org

[matsko]

FYI @visionmedia, www.yearofmoo.com is a blog that is powered with Angular.