[Discussion] The future of Ghost's admin UI

[ErisDS]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Please note:

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

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

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

Next steps:

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

update: moved back from 18th to 25th

[alvincrespo]

Honestly I believe Ember might be your best bet.

Although it may seem tempting to use components, it yet has to be widely supported or proven to be a solution for production use. Angular is a great alternative for easily creating web applications, but falls short in establishing an architecture to follow from the start. Backbone, although great, lacks the necessities for having an out of the box solution.

I've worked with all these alternatives and have found that Ember has helped me and other teams focus on feature development. Although it is fun to work with multiple solutions, establish architecture and best practices, for a product such as Ghost - you may want to focus on creating features that enhance the user experience - this is what Ember will give you.

[petehunt]

I disagree with @visionmedia. Just because web components are being evangelized by the Chrome team does not mean that they are the future, nor do they have a monopoly on modularity. This isn't to say that web components are bad, but ordaining them as the future of the web is very misleading.

[0x-r4bbit]

@petehunt There's an official spec for it, its not just that the chrome guys evangelize the stuff. Mozilla is also working it, just take a look at x-tags for example, or the brick project. Web Components IS the future, what we currently have are polyfills to push us all into the right direction.

[KidkArolis]

I agree with @petehunt that's it a bit too early to call WC the future.

Moreover, correct me if I'm wrong, but even if Web Components prove to be useful they won't neccesserily eliminate the need for Embers, Backbones, Reacts and all of the npm modules really. Those libraries and frameworks solve a lot more concerns such as Routing and Data/Model Management. And some of them (e.g. React.js) arguably solve the view layer better than Web Components without needing all of the template, custom element and node bindings to be in the spec..

[davidmarkclements]

voting for web components.

Polymer to fill the gap, eventual component logic running native is a win.

Even if web components don't "take off" (...they will)... polymer is still a veritable approach, particularly in terms of modularity

[ErisDS]

Web components are an interesting & exciting proposition, a valuable thing to discuss and something which should be at the back of everyone's mind when developing on the frontend. However, they are not a potential solution for the problem at hand. Not only are web components clearly not ready for this kind of project:

... but also, they don't solve a large number of the problems described in the OP, and as pointed out by @KidkArolis there is still room for frameworks to solve those problems. Ghost needs a much more holistic solution.

We're not trying to determine which is the best solution for everyone, or what the future of the web looks like. We're trying to find the correct solution to the set of defined problems that we face now and need to solve in the very near future.

[knownasilya]

Ember and Web Components are best friends, especially with HTMLBars in the works. The plan seems to be to swap out Ember.Component for full blown Web Component, once those are mature.

I actually started working on developing custom functionality in Ghost, but was totally turned off due to the fragility and the code being all over the place (I tried to add a custom setting in the admin.. changed code in 5+ files and still didn't get it to work)..

Ember really gives you the tools to build something of this scale, and it will make Ghost very easy to contribute to, since Ember has great documentation, and improving daily, and Ember apps are all structured in a similar way. So if you've worked on one, you can basically pick up any other app and know how everything is tied together (The Ember Inspector extensions helps a lot as well).

P.S. I love that some of Ember's core team are on TC-39, and others are innovating in other spheres like the issue with stacktraces. They are really looking out for the whole web community as a whole. Pushing the future forward.

[tj]

@petehunt IMO they're a big step closer, especially once we have "real" modules in the browser things will change. Sure these frameworks will still exist, but there will be very little motivation to use them. Why build a "ember progress bar" when you can just have a "progress bar", this is exactly like the jQuery plugin plague we've been trying to get away from for years, it doesn't make sense.

You do certainly get benefits like the Ember inspector at the framework level, however there's no reason that couldn't be a module which many other modules may tap into - removing the need for a framework. It's hard to say that other aspects of web components will work out flawlessly, but modules alone will crush the frameworks. There will always be a large chunk of the community that appreciates the "hand-holding" provided by a framework, and there's nothing wrong with that, hopefully they will be comprised of many smaller modules so you can back out of lock-in if you wish.

[knownasilya]

@visionmedia I totally agree with you, and I can't wait for that future.

Unfortunately that's not the state of the web right now, and we need to move forward now, and frameworks are what we have. Both Ember and Angular have a form of 'web component', so both are relatively future proof, and that makes them great candidates in the mean while.

[tj]

Yeah I'm not sure how far along the polymer stuff is so I can't comment on that. In that case I would go with the one(s) with less lock-in, it's really hard to back out of frameworks when they corner you, BUT that being said it is a blog, so I can't see Ember/Angular getting in the way much there.

[wycats]

@visionmedia I totally agree that ES6 modules are the future. As a member of TC39, I've been a champion of the modules proposal for the past year, and browser modules are a key part of Ember's strategy moving forward.

We already have moved Ember Data to use ES6 modules (see emberjs/data#1623, merged, and emberjs/ember.js#4374, in progress). Ember App Kit, an increasingly popular way to write Ember applications, was an early adopter of ES6 modules, and we use them on Skylight (the Ember app I work on at Tilde).

Regarding modularity, Ember has always been somewhat aggressive about extracting parts of Ember into their own libraries (or even building modules as separate libraries from the get-go):

• RSVP.js , a lightweight promise library
• route-recognizer - an unopinionated URL recognizer.
• router.js - a higher-level routing library built on route-recognizer that adds support for state management and hierarchical routing
• handlebars - the template engine that powers Ember
• simple-html-tokenizer - a standalone HTML tokenizer based on the HTML5 tokenizer spec
• HTMLBars - a new handlebars backend that creates document fragments instead of strings, using simple-html-tokenizer
• bound-templates.js - a bound templates library that is built on top of HTMLBars and acts as a standalone library for data binding to templates.
• backburner.js - the core of the Ember "run loop" deferral mechanism

This has always been an important part of our strategy, and we are very proud of the fact that people use many of these libraries with other frameworks or standalone.

Regarding web components, we are also big believers in the future of web components. About nine months ago, I wrote up Ember's long-term plan for evolving our components together with Polymer's components and data binding story. I would strongly encourage those who are interested to read it through. For the most part, it remains the plan of record, and the ongoing HTMLBars work is the implementation strategy that we are taking today.

I totally agree with @visionmedia that in the long haul, nobody should write an Ember progress bar or an Angular progress bar or a Polymer progress bar. The vision of web components is that the web provides rich enough capabilities on its own to enable this kind of sharing. In the short-to-medium term, however, our best bet is to use libraries and frameworks that track the web component ideas closely. At the end of the day, I expect Ember.Component to be a relatively simple subclass of HTMLElement.

Finally, while web components are a very important part of the future of the web, many people on this thread have correctly pointed out that having well-defined, robust tools for application structure is a critically important part of developing an application like Ghost. The Ember team has spent a lot of time on application structure, routing and whole-app state management. I would encourage you to take a look at the Ember router as well as some of the recent talks @tomdale or I have given that outline our philosophy on this front.

In my view, it's really where Ember shines, and where attempts at head-to-head comparisons often fall short.

[tomdale]

Coincidentally, the talk I gave at QCon in SF was just made public today. It's called Building URL-Driven Web Apps with Ember.js and is about 45 minutes long, if you'd like a high-level overview of how Ember helps you manage multiple components on screen in a way that respects the URL.

[tj]

@wycats good to hear! I can't wait for proper modules alone, nevermind the rest of web components

[petehunt]

@visionmedia Except for shadow DOM, all web components is doing is standardizing and baking an app development framework into the browser. I'm not sure if we should sandbag this GitHub issue with that discussion, but I think that it is an important issue to talk about somewhere.

[wycats]

@petehunt I don't think that's quite the right analysis of what web components is, but I agree that we should have that discussion elsewhere. Maybe open an issue on Polymer and we can discuss it there?

[mgenev]

I've used all 3 and I personally like Ember the most for a number of reasons which I outlined here in my article:

http://www.100percentjs.com/backbone-or-angular-or-ember-here-is-my-choice-and-why/

Ember makes the most sense to me and is best thought out I think, sadly ember-data is not quite ready yet, but should be in due time. There are also alternatives to it.

[AJ-Acevedo]

Is Rendr no longer a contendor? The idea of using the same code on the client side and server side has it's merits. It shortens the learning curve, Ghost is already using Backbone and you write less code.

[sporto]

Either Angular or Ember will definitely deliver, very hard to make a strong case for either of them, it is all opinions. I think that you should just pick the one that the current contributors are more experienced in (or have some experience). But IMO staying with backbone is the less desirable option.

If you want to consider others I suggest looking at CanJS as a possibility. Here are some reasons why:

• It shares some patterns with Backbone, which can help with the learning curve
• It handles destroying views and listeners automatically when removed from the DOM
• It has two way bindings
• It is very small (as in Backbone small) and fast

[RomiSato]

Seems like the discussion is down mostly to Angular and Ember but have you guys looked at DurandalJS? It's relatively new but it compares pretty well to Angular.

Here are a couple posts that compare it to Angular in more detail:

http://blogs.lessthandot.com/index.php/WebDev/UIDevelopment/angularjs-vs-knockout-final-thoughts-9/

http://www.ryankeeter.com/angularjs-vs.-durandaljs%E2%80%93part-3-of-n%E2%80%93reputation

[jeffwhelpley]

Wow. Amazing discussion. I think your options really boil down to Angular or Ember due to the fact we are essentially talking about a potentially large single page app that doesn't necessarily need server side rendering. I am personally a huge fan of Angular and used it to build a fairly sizable app (answers.gethuman.com), but you can create the same type of amazing stuff in either framework and both frameworks have strong communities behind them. For larger web apps, whatever you build in Angular, you can build in Ember or vice versa (likely in a similar time frame assuming you have experienced devs). In my mind it comes down to a style difference. Angular and Ember are very opinionated and those opinions are often quite different.

Angular - testing focused, markup in HTML over coding, one big polyfill for the future (i.e. web components, etc.), not many opinions on structure (every angular app code looks different), no data layer (roll your own)

Ember - very little testing facilities, code over HTML markup, convention over configuration (all ember apps look similar), strong data layer

I prefer Angular because I like the idea of being a future polyfill, I value the easy of testing with their DI system and I look at the lack of opinions on structure as a plus since it provides more flexibility. That flexibility, though, could be a negative for Ghost depending on the preferences of your core contributors.

[tomdale]

one big polyfill for the future

@jeffwhelpley That's a very interesting claim! I'm not aware of any browser vendors planning on proposing Angular's syntax (or semantics, for that matter) as a spec, which is the typical definition of a polyfill. Would you mind pointing us in the right direction?

[jeffwhelpley]

@tomdale apologies for misusing the term polyfill. Obviously taken literally the phrase you quoted is pretty silly. I was more referring to some of the concepts Brian Ford talks about in his presentation The Future of AngularJS. For example, in the future Object.observe can be used to detect changes on plain old JavaScript objects, but in the meantime Angular today provides this functionality from a developer point of view through dirty checking (which I know you are a fan of). I would not expect the current Angular syntax to be adopted by anyone else. In fact, as Brian points out in his presentation and like Igor talked about at ng-conf, they are changing some of their own syntax to align more with ES6 with Angular 2.0.

[knownasilya]

@jeffwhelpley sounds like you're describing Ember as well :smile:

[mgenev]

Angular actually deviates very much from what Javascript devs are used to. That's the reason I dislike it. Almost everything in Angular is made up for angular and particular to it. I dropped it after 6 months, because it felt like I'm deviating from the overall JS way of doing things. This is why Ember gets my vote. It has all the power, but you don't have to relearn everything, it's still JS, jQuery and Handlebars so you're in tune with everything else in the eco-system.

[marknutter]

There's been some great arguments in favor of Ember so as an Angular proponent I'll add a few counterpoints:

• Some people have suggested there aren't large, public applications out there using angular or that Google themselves aren't using it, but Google used Angular for a rewrite of their very large (and very lucrative) Doubleclick application. The devs gave a talk about it at the first ever ng-conf a few months ago: http://www.youtube.com/watch?v=62RvRQuMVyg. HBO, MSNBC, The Guardian, GM, Sony, and more use Angular. In the end it shouldn't be about who else is using angular, it should be about the community that surrounds it. Fortunately, there are great communities around all three of the frameworks you're considering.
• I've written a large app in ember and what bothered me about it was its opinionated nature. I'm a long time rails developer so I actually do prefer convention over configuration but my feeling on it when it comes to single page web application development is that things are still too up in the air to have strong opinions about how to do it. For instance, Ember has gone all-in on relying on routes to structure your application. In fact, they pride themselves on the fact that they treat routes as first class citizens. But we're talking about single-page apps here, not traditional web pages. URLs, while awesome for the web, don't always make sense in single page applications. If I have multiple components on a page with multiple states should I bother routing to each of those states or myriad combinations of states? Ember bootstraps controllers/models/templates based on the routes that are run but routes by their very nature are not well suited to defining state for multiple components in one page.
• With Angular I'm always wondering whether or not I'm structuring my app the right way, and I agree with @trek that it's not just file organization that Ember offers you. Angular pushes their module pattern but there's been too little guidance about how one should actually structure their application when it comes to tying all its functionality together. I have also struggled exactly when to use directives. I've seen them used to encapsulate incredibly complex behaviors (basically entire features) and I've also seen them kept very small and generic in projects or barely even used. There doesn't seem to be consensus about exactly what should go into a directive, although there wasn't much guidance about when to use components in the Ember.js community either so this may just be something we as a web development community aren't quite sure on. Which really enforces my point above about the world of SPA development being too fuzzy right now. We're in the process of transitioning from sprinkling a bit of JS into static web pages coming down from the server to writing large and complex client-side applications that are starting to look like native apps in the patterns they use (MVC, two way binding, etc). At any rate, if you go with Angular you should nail down exactly which conventions you want to follow when it comes to structuring your app.
• I knew I would see the word "transclusion" used pejoratively in this thread and I wasn't disappointed. Don't let terms like that dissuade you from using Angular. It's a tongue-in-cheek term for a very simple concept that can be explained in seconds to any competent developer. The truth is, the only semi-tricky thing to grok with Angular is directives and their somewhat awkward (but powerful and improving) interface but once you do it becomes a joy to develop with. And I actually like their naming style; especially their release names :).
• Keep in mind if you go with Ember you are going all-in on one way to build SPA's. Maybe they're right. If anybody is right about the future of web application development it would be @tomdale and @wycats. The thing is, the web is a very, very hard thing to be right about. It all depends on how much you want to hedge your bets. Angular will allow you to be more flexible and adaptive as time goes on because it is literally advertised as a "toolset for building the framework most suited to your application development". Backbone even more so, and plain old javascript if you're really paranoid.
• If you're thinking about mobile support, library size is going to be an issue. Ember requires JQuery and you'll likely use Ember-Data. It's also fairly large itself. Angular doesn't have those dependencies and can be quite svelte if need be.
• With ember you have to be comfortable with getter/setter interfaces. You will get sick of writing thing.set("blah", "blah"). While it does provide niceties like computed properties it's easy to lose track of just whats happening when you ask an object for data. Are you just getting data back, or are you kicking off some very complex and expensive computed property? There are downsides to not being aware of an interface's intent. I still prefer working with POJOs.
• Ember-Data is still a risk in my opinion. Client-side data persistence is an incredibly nuanced and complex problem to solve and the Ember team is admirably trying to solve it in addition to creating a best in class javascript framework. However, I just don't think it's possible to focus on both and it shows. Ember-Data can be unpredictable and is wonderful until it stops working at which point you either hope a fix is on the way or tread wearily into a world of complex state machines. It also caches the data from one request to the next without a clear way of preventing that data from going stale (a complex problem to solve in general).
• While you can design your Ember app to be modular it certainly doesn't feel that way when you're building with it. The sense I got was that you needed to be all-in with Ember if you were going to use it for your project. With Angular there's a big focus on modularity and isolation of components. If you ever choose to go with some new tech in the future you can likely keep a lot of your angular code around if you modularize it properly. And if web components become a standard you will be well positioned to take advantage of them since directives are an analog for them.
• To me it seems ease-of-testing was a bigger deal from the get-go with Angular where it seemed like an afterthought for Ember. When I first got started on trying to write unit tests for Ember there wasn't nearly the clearly laid out strategy for doing so that there was with Angular. Angular's dependency injection system lends itself really well to good testing.

I'm sure I'll be corrected on some of those points but hopefully it provides some insight. Good luck on your decision!

[yakovkhalinsky]

Just want to add my voice to @marknutter's reply. Your comment is a much needed elaboration of a few points I made earlier.

If you go with Angular you are not locking yourself down to a structure, and can still easily move on to something else in the future. This point alone makes Angular a better choice.

Using a "framework" that leaves open the possibility of an "exit strategy" to something else is a better choice than something that is heavily opinionated. Risk of framework lock in should be something anyone running a project for the long term should carefully consider.

[sporto]

@yakovkhalinsky I will like to hear more on how Angular prevents this framework lock if you don't mind, I don't see how this is the case. Is it that directives may be swappable for web components in the future? I understand that Ember will do this as well.

[yakovkhalinsky]

@sporto in my use of Angular I implement my own data layer, create modules with functions that encapsulate any business logic, all before even rolling out any Angular code.

I use Angular to simply extend the DOM and control UI behaviour.

My points are not pro Angular, just that this is something I find comforting and a plus when looking at what a framework or utility library can offer me.

[taras]

@marknutter

URLs, while awesome for the web, don't always make sense in single page applications. If I have multiple components on a page with multiple states should I bother routing to each of those states or myriad combinations of states?

Yes, but unfortunately serializing widget state is difficult using dynamic url segments. The canary release of Ember has a new query parameters implementation that makes serializing widget state very easy.

Ember bootstraps controllers/models/templates based on the routes that are run but routes by their very nature are not well suited to defining state for multiple components in one page.

The new implementation of query params binds query params in the url to properties on route's controller. This makes it easy to pass query params to components(widgets). When state of a component changes, Ember will automatically update the query params in the url.

This kind of seamless integration of otherwise complicated architecture is enabled by Ember's control over the route/controller/template wiring.

[mikemaccana]

@ErisDS For binding, have you considered Ractive.js from The Guardian? I've been using it for half a year now on Firework.io

The main benefit is simplicity. Learning to use Ractive fits in a tweet:

• Have an object
• Have a mustache template

Update part of the object and the relevant part of the template updates.

That's all.

I've used Angular on a big financial project before and I know its complexity well. With Ractive, you won't be spending your life in Google, and having discussions about your binding tool and the nature of transclusion.

Ractive just works and I've found it much more productive than large frameworks like Angular and Ember. It's new, but so were Ember and Angular at one point, and it's supported by a major news organisation.

[ErisDS]

@mikemaccana Forgive me if I've wrong because I've only taken a very quick look at Ractive.js. It looks to me a lot like Backbone.js with data binding and without routing. So it kinda solves one problem and leaves another one unsolved. It looks like a very useful lightweight tool, but I'm not sure how it would fit in our scenario.

Being required to use mustache when our system is currently built on handlebars would also seem to me to be an issue, not least because the admin and blog code would look like they were the same but be very different. I have a similar concern with Ember in this regard in that Ember code would be tied to Ember's handlebars, as opposed to the express-hbs implementation we use for the theme API.

[mikemaccana]

@erisds: yes, it's exactly that: a data binding system - not a routing library, a new module system, a new way to layout your files, or any other unrelated task that a framework like Angular would provide. Ractive works quite well with existing backbone apps - see http://examples.ractivejs.org/backbone

Re: your scenario:

• Use your existing backbone code base
• Use ractive for data binding.
• Use a routing library or your own code (I do the latter) for routing.

When I say 'mustache', it's a mustache-style templating system - I'd describe handlebars and hogan as also being forms of mustache (they implement the spec, but extend it) the same way. If you're concerned it's missing something: Ractive provides handlebars-like mustache extensions including array index references, object iteration, restricted references, ancestor references and expressions - see http://docs.ractivejs.org/latest/mustaches. It's similar, although not the same as handlebars.

I do understand your point about server-side templating needing to be the consistent with client side - it may be worth talking to @rich_harris about server side ractive.

Also you both really like doge.

[ErisDS]

@mikemaccana LOL

I think the entire debate that is going on here comes down to whether or not Ghost wants something light-touch and un-opinionated, or heavy duty and all-encompassing. There are merits to both approaches, but everytime I re-read the problem statement in my original post I draw the conclusion that we've tried light touch, failed and are now looking for something much more comprehensive.

[Rich-Harris]

Ractive author here. As @mikemaccana says it's definitely not a do-everything framework, in fact it's anti-framework - it's built for people who want the code cleanliness and ease of development that comes with something like Angular or Ember, but without driving you 80% of the way then leaving you stranded by the side of the road, which sometimes happens with frameworks. Do one thing, and do it well, etc. In that sense it's similar to React.

Having said that if you're set on using a framework I would probably check out Meteor - very shallow learning curve, good support for Handlebars, and it really does do a lot of the donkey work for you.

Quick sales pitch tailored to your use case:

• No need to write any render code, view update logic, whatever (unlike Backbone)
• Server-side rendering with the same templates and data
• Views can easily be torn down, no memory leak issues etc
• Transitions and animations can be done completely declaratively using ractive.animate() and transition plugins
• You can create reusable components, as with React, Ember or Angular
• As with React, you can commit to it gradually - one component at a time

[zeppelin]

While I respect portability in theory, I'd argue if it's needed to chased by all costs. I don't see Ember or Angular going away anytime soon, nor will they suddenly stop innovating and promoting bad architecture, so I would't fear of sticking to either of them - the benefits far outweigh the possible lock-in. Which I don't think is as serious as stated by some.

[ebryn]

but without driving you 80% of the way then leaving you stranded by the side of the road

In this analogy how far down the road does Ractive.js get you?

[Rich-Harris]

In this analogy how far down the road does Ractive.js get you?

Heh. In this analogy, Ractive is a bike. It doesn't go as far, but if you hit rocky terrain or get a puncture, you can get off and walk for a while ;-)

[ebryn]

So I'm going to have to do a lot more work and I may or may not actually reach my destination if what I'm trying to build is sufficiently complex.

The idea that you'd somehow get stranded with Ember.js is complete FUD. There's nothing stopping you from writing the same code you'd have written without it if you hit a wall.

[Rich-Harris]

Come on now, I was simply pointing out that the less opinionated Backbone/React/Knockout/Ractive/whatever approach is a better solution for some apps. Apologies if my clumsy wording led you to think I was attacking Ember specifically, because I wasn't (in fact I was praising Ember in a talk I gave just the other day, I think it's a terrific project). There is a bit more work involved, sure - that's the tradeoff for working with tools that are less opinionated.

[mikemaccana]

@ErisDS I understand what you're saying re: large an opinionated. In that case, I'd focus on a full-stack framework rather than trying to create a server component for a client side one like Angular and Ember.

If you want to go opinionated all the way, asides from https://www.meteor.com/ there's also http://derbyjs.com.

[ebryn]

I'd focus on a full-stack framework

That requires a complete rewrite of their backend, which I imagine is off the table.

One of the greatest advantages that writing a browser app has is that you end up with clean separation of concerns. You build your API server and now any type of client can talk to it. iOS, Android, Mac, Windows, whatever. You choose something like Meteor and now you're tightly coupled to the server again.

[mikemaccana]

@ebryn shrug if they're redoing the frontend, they may as well go all the way.

[friksa]

For those that really want to get a better feel for Angular or React, you should watch these free short video clips: https://egghead.io

They are really good and will help you understand if either of those technologies are a good fit or not without writing a bunch of code.

[ebryn]

Come on now, I was simply pointing out that the less opinionated Backbone/React/Knockout/Ractive/whatever approach is a better solution for some apps.

That's up for debate in my mind. Looking forward to dinner on 3/10 ;)

Apologies if my clumsy wording led you to think I was attacking Ember specifically, because I wasn't (in fact I was praising Ember in a talk I gave just the other day, I think it's a terrific project).

I didn't think you were attacking Ember specifically, but I wanted to point out the flaw in your reasoning. You can build faster, further, and more maintainably with these more opinionated tools. I'm completely convinced of that.

There is a bit more work involved, sure - that's the tradeoff for working with tools that are less opinionated.

I think "a bit more work" is an understatement :)

[Rich-Harris]

That's up for debate in my mind. Looking forward to dinner on 3/10 ;)

Ah, didn't realise you'd be there. Excellent - these debates are far better had face to face. I'll save my rebuttals for then, we've hijacked enough of this thread already!

[ErisDS]

@mikemaccana that really doesn't fit with what we are doing or want to do. We have a backend which we are happy with that exposes a JSON API just waiting for us to integrate with it.

Ghost isn't a straightforward client-server application. It has a JSON API in the middle, and a server side app that serves the blog itself - the client that we're looking to replace is the admin UI - we have no intention of replacing all the guts in the middle at this stage.

The JSON API is also important in terms of enabling 3rd parties to integrate with Ghost, and provides a data access layer to internal apps.

[mikemaccana]

@erisds I'm not sure MeteorJS or DerbyJS preclude you from having a JSON API shaped however you'd like, though if you know they do, then fair enough.

Earlier you mentioned server-side templating that was consistent with client side, so I thought you wished to do that (and reduce duplicated logic).

As @Rich-Harris said, perhaps a GitHub issue isn't the best place for this discussion.

[ErisDS]

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

• Ember - https://github.com/manuelmitasch/ghost-admin-ember-demo/ by @manuelmitasch forked & extended version https://github.com/Globegitter/ghost-admin-ember-demo by @Globegitter
• Angular - https://github.com/TryGhost/Ghost/pull/2211 by @hswolff
• Backbone + Marionette - https://github.com/TryGhost/Ghost/pull/2253 by @samccone
• React - https://github.com/TryGhost/Ghost/pull/2259 by @petehunt

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

[tgriesser]

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

[ErisDS]

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 :smile: