[Discussion] The future of Ghost's admin UI #2144

Closed
ErisDS opened this Issue Feb 7, 2014 · 129 comments

Comments

Projects
None yet
@ErisDS
Member

ErisDS commented Feb 7, 2014

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 😈

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

This comment has been minimized.

Show comment
Hide comment
@jgable

jgable Feb 8, 2014

Member

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.

Member

jgable commented Feb 8, 2014

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

This comment has been minimized.

Show comment
Hide comment
@javorszky

javorszky Feb 9, 2014

Member

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

Member

javorszky commented Feb 9, 2014

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

@BiosElement

This comment has been minimized.

Show comment
Hide comment
@BiosElement

BiosElement Feb 9, 2014

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.

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

This comment has been minimized.

Show comment
Hide comment
@LevelbossMike

LevelbossMike Feb 9, 2014

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:

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

This comment has been minimized.

Show comment
Hide comment
@jamesbloomer

jamesbloomer Feb 9, 2014

Member

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...

Member

jamesbloomer commented Feb 9, 2014

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

This comment has been minimized.

Show comment
Hide comment
@ErisDS

ErisDS Feb 9, 2014

Member

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

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.

Member

ErisDS commented Feb 9, 2014

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

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

This comment has been minimized.

Show comment
Hide comment
@hswolff

hswolff Feb 9, 2014

Member

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.

Member

hswolff commented Feb 9, 2014

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

This comment has been minimized.

Show comment
Hide comment
@jgable

jgable Feb 10, 2014

Member

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

Member

jgable commented Feb 10, 2014

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

@friksa

This comment has been minimized.

Show comment
Hide comment
@friksa

friksa Feb 10, 2014

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/

friksa commented Feb 10, 2014

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

This comment has been minimized.

Show comment
Hide comment
@trek

trek Feb 14, 2014

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:

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:

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.

trek commented Feb 14, 2014

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:

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:

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

This comment has been minimized.

Show comment
Hide comment
@hswolff

hswolff Feb 14, 2014

Member

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.

Member

hswolff commented Feb 14, 2014

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

This comment has been minimized.

Show comment
Hide comment
@hswolff

hswolff Feb 14, 2014

Member

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 :).

Member

hswolff commented Feb 14, 2014

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

This comment has been minimized.

Show comment
Hide comment
@friksa

friksa Feb 14, 2014

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

friksa commented Feb 14, 2014

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

@trek

This comment has been minimized.

Show comment
Hide comment
@trek

trek Feb 15, 2014

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.

trek commented Feb 15, 2014

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

This comment has been minimized.

Show comment
Hide comment
@pixelhandler

pixelhandler Feb 15, 2014

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.

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

This comment has been minimized.

Show comment
Hide comment
@trek

trek Feb 15, 2014

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.

trek commented Feb 15, 2014

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

This comment has been minimized.

Show comment
Hide comment
@grayrest

grayrest Feb 15, 2014

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.

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

This comment has been minimized.

Show comment
Hide comment
@eviltrout

eviltrout Feb 15, 2014

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! 😕).

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.

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! 😕).

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

This comment has been minimized.

Show comment
Hide comment
@manuelmitasch

manuelmitasch Feb 15, 2014

Contributor

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!

Contributor

manuelmitasch commented Feb 15, 2014

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

This comment has been minimized.

Show comment
Hide comment
@ErisDS

ErisDS Feb 15, 2014

Member

Thank you to everyone who has come here to add something to this discussion 👍

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:

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.

Member

ErisDS commented Feb 15, 2014

Thank you to everyone who has come here to add something to this discussion 👍

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:

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

This comment has been minimized.

Show comment
Hide comment
@JohnONolan

This comment has been minimized.

Show comment
Hide comment
@JohnONolan

JohnONolan Feb 15, 2014

Member

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

Member

JohnONolan commented Feb 15, 2014

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

@javorszky

This comment has been minimized.

Show comment
Hide comment
@javorszky

javorszky Feb 15, 2014

Member

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

Member

javorszky commented Feb 15, 2014

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

@ebryn

This comment has been minimized.

Show comment
Hide comment
@ebryn

ebryn Feb 15, 2014

Contributor

@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.

Contributor

ebryn commented Feb 15, 2014

@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

This comment has been minimized.

Show comment
Hide comment
@trek

trek Feb 15, 2014

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

trek commented Feb 15, 2014

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

@sophiebits

This comment has been minimized.

Show comment
Hide comment
@sophiebits

sophiebits Feb 16, 2014

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.

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

This comment has been minimized.

Show comment
Hide comment
@vjeux

vjeux Feb 16, 2014

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

vjeux commented Feb 16, 2014

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

This comment has been minimized.

Show comment
Hide comment
@ebryn

ebryn Feb 16, 2014

Contributor

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.

Contributor

ebryn commented Feb 16, 2014

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

This comment has been minimized.

Show comment
Hide comment
@trek

trek Feb 17, 2014

So, a few enterprising people have started a spike already. Comments like manuelmitasch/ghost-admin-ember-demo@fba3ab0#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?"

trek commented Feb 17, 2014

So, a few enterprising people have started a spike already. Comments like manuelmitasch/ghost-admin-ember-demo@fba3ab0#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

This comment has been minimized.

Show comment
Hide comment
@timruffles

timruffles Feb 17, 2014

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.

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

This comment has been minimized.

Show comment
Hide comment
@jgable

jgable Feb 17, 2014

Member

@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?

Member

jgable commented Feb 17, 2014

@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

This comment has been minimized.

Show comment
Hide comment
@silentworks

silentworks Feb 17, 2014

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.

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

This comment has been minimized.

Show comment
Hide comment
@timruffles

timruffles Feb 17, 2014

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.

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

This comment has been minimized.

Show comment
Hide comment
@CoreyRab

CoreyRab Feb 17, 2014

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.

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.

@ErisDS

This comment has been minimized.

Show comment
Hide comment
@ErisDS

ErisDS Feb 25, 2014

Member

I thought I'd just post a few links to the examples that have been created.

We're gonna be calling it in tonight's dev meeting in #ghost @ 5:30pm GMT

Member

ErisDS commented Feb 25, 2014

I thought I'd just post a few links to the examples that have been created.

We're gonna be calling it in tonight's dev meeting in #ghost @ 5:30pm GMT

@tgriesser

This comment has been minimized.

Show comment
Hide comment
@tgriesser

tgriesser Feb 25, 2014

Contributor

For the react implementation, it might be worth taking a look at react-router-component for declarative history/route management.

Contributor

tgriesser commented Feb 25, 2014

For the react implementation, it might be worth taking a look at react-router-component for declarative history/route management.

@ErisDS

This comment has been minimized.

Show comment
Hide comment
@ErisDS

ErisDS Feb 26, 2014

Member

Thank you to everyone who joined in this discussion, it is a treasure-trove of valuable insight into choosing a framework.

We decided that Ember.js is the right solution for Ghost. If you're interested in learning more about why, have a read of: http://dev.ghost.org/hello-ember/

If you'd like to get involved in the re-write, please come join us in irc (#ghost on freenode). Discussions about getting the project kicked off are on going :)

Feel kinda sad closing this... it's been fun 😄

Member

ErisDS commented Feb 26, 2014

Thank you to everyone who joined in this discussion, it is a treasure-trove of valuable insight into choosing a framework.

We decided that Ember.js is the right solution for Ghost. If you're interested in learning more about why, have a read of: http://dev.ghost.org/hello-ember/

If you'd like to get involved in the re-write, please come join us in irc (#ghost on freenode). Discussions about getting the project kicked off are on going :)

Feel kinda sad closing this... it's been fun 😄

@karlmikko

This comment has been minimized.

Show comment
Hide comment
@karlmikko

karlmikko Mar 23, 2014

Contributor

Hi All,

I know I am quite late on all this. I just found out about reactjs in the last few days. I will read up on ember also!

From what I have seen - I could be used in a manner that replaces handlebars and still use backbone for routing and models etc.

I see it could have massive improvements for the editor as it keeps a JS copy of the DOM then renders on the changes - this would cause less re-flows in the editor making working on large documents much better as there is currently a lag on the preview when over 2000 words.

You can also render server side so could be used to send the front end also.

What was the result of the react test? I would be interested in talking to the dev who worked on it.

Contributor

karlmikko commented Mar 23, 2014

Hi All,

I know I am quite late on all this. I just found out about reactjs in the last few days. I will read up on ember also!

From what I have seen - I could be used in a manner that replaces handlebars and still use backbone for routing and models etc.

I see it could have massive improvements for the editor as it keeps a JS copy of the DOM then renders on the changes - this would cause less re-flows in the editor making working on large documents much better as there is currently a lag on the preview when over 2000 words.

You can also render server side so could be used to send the front end also.

What was the result of the react test? I would be interested in talking to the dev who worked on it.

@taras

This comment has been minimized.

Show comment
Hide comment
@taras

taras Mar 23, 2014

Contributor

@KingKarl85 @TryGhost already decided to go with Ember and already started rewriting the admin interface with it.

Contributor

taras commented Mar 23, 2014

@KingKarl85 @TryGhost already decided to go with Ember and already started rewriting the admin interface with it.

@karlmikko

This comment has been minimized.

Show comment
Hide comment
@karlmikko

karlmikko Mar 23, 2014

Contributor

@taras thanks, I might have a look at using the ember to create DOM then pass it to reactjs so it can do batch change and update just the effected DOM part not re-render the whole preview. This may give you best of both worlds.

Contributor

karlmikko commented Mar 23, 2014

@taras thanks, I might have a look at using the ember to create DOM then pass it to reactjs so it can do batch change and update just the effected DOM part not re-render the whole preview. This may give you best of both worlds.

@taras

This comment has been minimized.

Show comment
Hide comment
@taras

taras Mar 23, 2014

Contributor

@KingKarl85 there was some work done like that before but HTMLBars implementation with Ember.js will make all of those efforts obsolete. It looks like Ember with HTMLBars might be faster than Reactjs.

Contributor

taras commented Mar 23, 2014

@KingKarl85 there was some work done like that before but HTMLBars implementation with Ember.js will make all of those efforts obsolete. It looks like Ember with HTMLBars might be faster than Reactjs.

@karlmikko

This comment has been minimized.

Show comment
Hide comment
@karlmikko

karlmikko Mar 23, 2014

Contributor

@taras I'll have a look at HTMLBars and see how it goes. It would be interested to benchmark the two next to each other.

Contributor

karlmikko commented Mar 23, 2014

@taras I'll have a look at HTMLBars and see how it goes. It would be interested to benchmark the two next to each other.

@taras

This comment has been minimized.

Show comment
Hide comment
@taras

taras Mar 23, 2014

Contributor

http://jsfiddle.net/Ut2X6/ not the best benchmarks and they're 3 weeks old, but it gives a good picture of what's coming.

Contributor

taras commented Mar 23, 2014

http://jsfiddle.net/Ut2X6/ not the best benchmarks and they're 3 weeks old, but it gives a good picture of what's coming.

@ErisDS

This comment has been minimized.

Show comment
Hide comment
@ErisDS

ErisDS Mar 23, 2014

Member

Please move this conversation to a new issue, thanks 👍

Member

ErisDS commented Mar 23, 2014

Please move this conversation to a new issue, thanks 👍

@karlmikko

This comment has been minimized.

Show comment
Hide comment
@karlmikko

karlmikko Mar 23, 2014

Contributor

move to #2490

Contributor

karlmikko commented Mar 23, 2014

move to #2490

@malixsys

This comment has been minimized.

Show comment
Hide comment
@malixsys

malixsys Jan 25, 2017

Damn, two years too late... Is it still on ( gasp ) Ember?

Damn, two years too late... Is it still on ( gasp ) Ember?

@zeppelin

This comment has been minimized.

Show comment
Hide comment
@zeppelin

zeppelin Jan 25, 2017

Still? What do you mean?

Still? What do you mean?

@malixsys

This comment has been minimized.

Show comment
Hide comment
@malixsys

malixsys Jan 25, 2017

vs React or Angular 2 or Vue or ...

vs React or Angular 2 or Vue or ...

@sophiebits

This comment has been minimized.

Show comment
Hide comment
@sophiebits

sophiebits Jan 25, 2017

I work on React. Ember is a perfectly good choice here and it should be unsurprising, not surprising, that they are still on the same framework they chose 2 years ago.

I work on React. Ember is a perfectly good choice here and it should be unsurprising, not surprising, that they are still on the same framework they chose 2 years ago.

@knownasilya

This comment has been minimized.

Show comment
Hide comment
@knownasilya

knownasilya Jan 25, 2017

Contributor

One of Ember's philosophies is "stability without stagnation", so it's a perfect fit.

Contributor

knownasilya commented Jan 25, 2017

One of Ember's philosophies is "stability without stagnation", so it's a perfect fit.

@jhabdas

This comment has been minimized.

Show comment
Hide comment
@jhabdas

jhabdas Jan 26, 2017

@malixsys you're still not using...pause for dramatic effect...a static site generator?

jhabdas commented Jan 26, 2017

@malixsys you're still not using...pause for dramatic effect...a static site generator?

@zeppelin

This comment has been minimized.

Show comment
Hide comment
@zeppelin

zeppelin Jan 26, 2017

@malixsys what specifically do you expect to gain by rewriting the admin to either of your choices?

@malixsys what specifically do you expect to gain by rewriting the admin to either of your choices?

@jhabdas

This comment has been minimized.

Show comment
Hide comment
@jhabdas

jhabdas Jan 26, 2017

Apologies for speaking out of turn. But for one thing, a rewrite in React will gain you more support from the OSS community. But you'll need to be ready for a barrage of support issues from n00bs, and potential artchiectural slips due to relative inexperience in the React community.

jhabdas commented Jan 26, 2017

Apologies for speaking out of turn. But for one thing, a rewrite in React will gain you more support from the OSS community. But you'll need to be ready for a barrage of support issues from n00bs, and potential artchiectural slips due to relative inexperience in the React community.

@zeppelin

This comment has been minimized.

Show comment
Hide comment
@zeppelin

zeppelin Jan 26, 2017

@jhabdas is Ghost suffering from not having enough contributors to their admin app?

@jhabdas is Ghost suffering from not having enough contributors to their admin app?

@jhabdas

This comment has been minimized.

Show comment
Hide comment
@jhabdas

jhabdas Jan 26, 2017

@zeppelin is that a rethorical question? Or are you just being defensive? In my opinion Ghost, with the funding received, should have been much further along by now. No offense, but I've seen unfunded open source projects with more forward momentum. Not to discredit Erin's work, but Ember was the wrong choice.

jhabdas commented Jan 26, 2017

@zeppelin is that a rethorical question? Or are you just being defensive? In my opinion Ghost, with the funding received, should have been much further along by now. No offense, but I've seen unfunded open source projects with more forward momentum. Not to discredit Erin's work, but Ember was the wrong choice.

@zeppelin

This comment has been minimized.

Show comment
Hide comment
@zeppelin

zeppelin Jan 26, 2017

@jhabdas Not rhetorical at all! I'm honestly curious if this is is a fact or an just general assumption.

@jhabdas Not rhetorical at all! I'm honestly curious if this is is a fact or an just general assumption.

@jhabdas

This comment has been minimized.

Show comment
Hide comment
@jhabdas

jhabdas Jan 26, 2017

@zeppelin fact. If you rewrite in React expect to see Ghost enjoy a renaissance of development activity across the board.

jhabdas commented Jan 26, 2017

@zeppelin fact. If you rewrite in React expect to see Ghost enjoy a renaissance of development activity across the board.

@zeppelin

This comment has been minimized.

Show comment
Hide comment
@zeppelin

zeppelin Jan 26, 2017

@jhabdas I was asking if the lack of contributors was pronounced by someone from the Ghost team.

@jhabdas I was asking if the lack of contributors was pronounced by someone from the Ghost team.

@jhabdas

This comment has been minimized.

Show comment
Hide comment
@jhabdas

jhabdas Jan 26, 2017

There's no I in team. If you're running a serious open source project on Node your UI is running React.

jhabdas commented Jan 26, 2017

There's no I in team. If you're running a serious open source project on Node your UI is running React.

@zeppelin

This comment has been minimized.

Show comment
Hide comment
@zeppelin

zeppelin Jan 26, 2017

@jhabdas ok, never mind.

@jhabdas ok, never mind.

@silentworks

This comment has been minimized.

Show comment
Hide comment
@silentworks

silentworks Jan 26, 2017

@jhabdas I think Ghost has been running for a while now on Ember and have had no problems with it, why switch to something else if what they have is already working? Plus this is a closed case, they have chosen, I don't think they will change unless they find a limitation in what they have chosen.

@jhabdas I think Ghost has been running for a while now on Ember and have had no problems with it, why switch to something else if what they have is already working? Plus this is a closed case, they have chosen, I don't think they will change unless they find a limitation in what they have chosen.

@jhabdas

This comment has been minimized.

Show comment
Hide comment
@jhabdas

jhabdas Jan 26, 2017

Argumentum ad Ignorantiam. If it's not broke don't fix it isn't valid. And two- going on three-year old decisions don't cut it in the development world, which demands continuous improvement in the face of illegitimacy. Given that point, I'm not a stakeholder. Just here to drop some candid feedback. Sometimes the fastest way forward requires taking two steps back.

jhabdas commented Jan 26, 2017

Argumentum ad Ignorantiam. If it's not broke don't fix it isn't valid. And two- going on three-year old decisions don't cut it in the development world, which demands continuous improvement in the face of illegitimacy. Given that point, I'm not a stakeholder. Just here to drop some candid feedback. Sometimes the fastest way forward requires taking two steps back.

@taras

This comment has been minimized.

Show comment
Hide comment
@taras

taras Jan 26, 2017

Contributor

This an open source ptoject you're welcome to create a PR that introduces a replacement in React. My guess is that feature pairity would be a

Contributor

taras commented Jan 26, 2017

This an open source ptoject you're welcome to create a PR that introduces a replacement in React. My guess is that feature pairity would be a

@taras

This comment has been minimized.

Show comment
Hide comment
@taras

taras Jan 26, 2017

Contributor

Oops... pressed send to early.

I'm assuming feature pairity would be a minimum requirement. There are no guaranteees that the PR would be accepted however because Ghost team knows Ember already. They'd need to learn a new tool because you think that it would attract more contributors.

All in all, Ghost team made a pragmatic decision 2 years ago that resulted in a good app that's maintainable and the team seems to be happy with it. Pragmatic decision at this point seems to be to keep what exists and works.

I hope you understand that not every team is bound by the same endless urge to rewrite their working applications in latest popular tech.

Contributor

taras commented Jan 26, 2017

Oops... pressed send to early.

I'm assuming feature pairity would be a minimum requirement. There are no guaranteees that the PR would be accepted however because Ghost team knows Ember already. They'd need to learn a new tool because you think that it would attract more contributors.

All in all, Ghost team made a pragmatic decision 2 years ago that resulted in a good app that's maintainable and the team seems to be happy with it. Pragmatic decision at this point seems to be to keep what exists and works.

I hope you understand that not every team is bound by the same endless urge to rewrite their working applications in latest popular tech.

@ErisDS

This comment has been minimized.

Show comment
Hide comment
@ErisDS

ErisDS Jan 26, 2017

Member

I am locking this down. I'm surprised and disappointed at this conversation - this is a 2 year old issue, which was until now, a stand out example of open source in action. There were 100 comments, all written with great depth and care, which helped us to overcome a major challenge in our growth and capabilities.

I didn't open my inbox this morning because I was busy planning a talk - in which the awesome work done in this issue and since feature heavily. I will be exercising my power to delete non constructive comments. If anyone wants to talk about this further, you're welcome to join our slack channel.

Member

ErisDS commented Jan 26, 2017

I am locking this down. I'm surprised and disappointed at this conversation - this is a 2 year old issue, which was until now, a stand out example of open source in action. There were 100 comments, all written with great depth and care, which helped us to overcome a major challenge in our growth and capabilities.

I didn't open my inbox this morning because I was busy planning a talk - in which the awesome work done in this issue and since feature heavily. I will be exercising my power to delete non constructive comments. If anyone wants to talk about this further, you're welcome to join our slack channel.

@TryGhost TryGhost locked and limited conversation to collaborators Jan 26, 2017

@JohnONolan

This comment has been minimized.

Show comment
Hide comment
@JohnONolan

JohnONolan Jan 26, 2017

Member

I had a response to this half-typed before I had to take a phone call. I'm not going to add a great deal here now, but I do want to clarify why Hannah was 100% right to lock this issue:

@jhabdas you, specifically, were being a dick.

There are multiple people here who are huge fans of React, myself included. There was nothing wrong with the content of your argument. But the second you started shitting on our momentum, accusing people of obtuse logical fallacies, and spouting meaningless drivel such as "If you're running a serious open source project" -- you lost all credibility.

Try being friendly and respectful next time instead of arrogant and dismissive. It doesn't matter how good of an engineer you are if nobody wants to work with you.

All of this is also covered in our (extremely liberal) code of conduct.

Member

JohnONolan commented Jan 26, 2017

I had a response to this half-typed before I had to take a phone call. I'm not going to add a great deal here now, but I do want to clarify why Hannah was 100% right to lock this issue:

@jhabdas you, specifically, were being a dick.

There are multiple people here who are huge fans of React, myself included. There was nothing wrong with the content of your argument. But the second you started shitting on our momentum, accusing people of obtuse logical fallacies, and spouting meaningless drivel such as "If you're running a serious open source project" -- you lost all credibility.

Try being friendly and respectful next time instead of arrogant and dismissive. It doesn't matter how good of an engineer you are if nobody wants to work with you.

All of this is also covered in our (extremely liberal) code of conduct.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.