pselle / choosing-javascript-framework Goto Github PK

The example code at the mo feels too sparse. It's a 'hello world' from each framework, but if people are spending £$¥ to have us help them choose, I think we have to go beyond what's normally on the README.md of the respective projects.

I think we need to cover some of the bread and butter concerns of all web-apps: persistence, animation, testing.

• a slightly messy API to clean up (e.g a 'not quite REST' API with camel_case_keys), and perhaps a local storage persistence for something?
• animations between list and show, loading animations
• a unit test

Just to give people a feel for where the tradeoffs emerge. For example Angular's dependency injection container just apps heaps of confusion (service vs factory vs value) which is paid off in the ease and safety of mocking'n'stubbing when it comes to testing time.

Needs to be a common example so readers can compare and contrast.

add a note to README.md that if the user wants to easily add/switch/upgrade/downgrade dependencies, install NodeJS and Bower. refer them to their specific sites' installation instructions; I dunno best practices for installing global modules on windows.

I’m inclined not to use Ember Data in the Ember example and instead make real ajax requests in the model hooks. Anecdotally, when teaching Ember the “ah ha” moment usually come when showing folks that it’s pretty much a one-liner to get real data into their apps:

App.ProperiesRoute = Ember.Route.extend({
  model: function() {
    return Ember.$.getJSON('https://choosing-a-javascript-framework.io/data/properties.json');
  }
});

@pselle what do you think?

I'm not sure I understand if I'm supposed to be committing over the files already there, or create a new "deep-dive" directory or something and have all the code from the chapter elsewhere...?

Anyone interested in a .jshintrc? Could also add jshint as a devDependency.

How about .editorconfig? Standardize tab/space usage, mainly.

Any reason not to 'use strict' in our JS files?

Hey guys,

I was speaking with Troy and we agreed it would be best if, instead of depth in any single one area, we go for breadth. That's to say, cover as many common concerns as you can.

• there are other resources for deep dives into frameworks
• if a reader is hunting for information on x for a potential framework, we're likely to have it covered, at least briefly

Cover the common topics first. If you have time, and it's not going to add too much length, cover less-common topics. No topic should be covered in excruciating detail.

thanks
Chris

We probably will want some minimal design just so the pages don't look like garbage. In the interest of time, Pure looks like a good fit.

How about this idea:

• Taken from these three colors:
  • AngularJS uses this theme
  • Ember uses this theme
  • Backbone uses this theme

This gives us ready-made styles for just about everything.

Note: does not require YUI.

Pretty soon ember-cli will be the recommended approach for buliding Ember apps. There are pros and cons to adopting ember-cli for the book so I’m listing them here for everyeone’s input:

Pros

• Will become the standard
• Packs a lot of functionality
• Includes generators for common tasks
  e.g. ember generate model property address:string zip:number price:number
• Introduces foward-looking concepts like ES6 modules
• Demonstrates what a “production” ember app looks like

Cons

• Not yet 1.0 and still subject to churn
• Potential NPM pitfalls (wonky NPM installation could scupper a reader’s progress)
• Introduces foward-looking concepts like ES6 modules 😉
• All the additional concepts may overwhelm while we’re trying to introduce the basics
• Would make it somewhat harder to compare side-by-side with the other frameworks

I’m not necessarily suggesting we switch to ember-cli for the example code, but want to put it on everyone’s radar. Either way, I’ll cover it thoroughly somwhere in the Ember chapter.

We can register our repo on Bower if we wish (a main bower.json is now in place on angular branch). That'd make it easier for some to just grab the code. I don't really see any reason why we shouldn't.