Ost.io proposal

[paulmillr]

I propose to use ost.io as a Taste App. Ost.io uses custom open-source backend (http://api.ost.io).

Main selling points:

• Real-world and fun. Ost.io is already used by popular open-source projects. Users can play with real data.
• Useful besides its main purpose.

Features:

• Custom open-source REST API server with CORS and access tokens (server spec)
• Authentication (registration, login, logout — w/o page reload), session management
• State management / routing
• Demonstrates CRUD
• Uses dedicated back-end for data. Can be switched in 1 line to production mode
• Multiple views, Sub-views
• Precompiled templates
• Animations
• Permissions
• Relationships between objects (user -> topic -> repo etc)
• Mobile support

The spec is here: https://github.com/paulmillr/ostio-apps

• First implementation (Chaplin + Brunch + Backbone): https://github.com/paulmillr/ostio

Post your thoughts on what should be also included in this app like "I think there should be modals since they are commonly used".

[sindresorhus]

@jeremychone would love your thoughts on what's missing here, even though you're doing your own thing. We want them both to be good ;)

[paulmillr]

@passy @sindresorhus @addyosmani what are your thoughts on this one? Which features does ost.io lack?

[addyosmani]

Just pinging to see if there has been any further activity here or help/suggestions on how to move forward.

@jeremychone anything on your end?

[paulmillr]

At this point ostio is pretty solid and i'm ready to make a second implementation with pure backbone or something. Of course we need to discuss together some issues but overall it's cool.

[jeremychone]

I have been swamped the last couple of weeks, but I have now a very good
idea of the base requirements, specifications, and the first implementation
directions. So, I need a week more to get the first draft spec out. It will
probably in the shape of a website or something.

Requirements:

The idea is to not have too much but just enough to show, login,
privileges, master-details, form validation, in-context editing, and
many-to-many relationships.

Specs:

• Application Type: Project/Task management application.
• UI (clear UI specification):
  • TopBar, LeftNav (for projects), Content which will display the item
    selected and will be part of the #routing.
  • Based on Bootstrap, minimize any custom UI as much as possible.
  • Application Layout over Content Site Layout. Meaning, it will stretch
    vertically with the window, and each panel will have their own scroll-bar
    as appropriate.
• Data model: User, Project, Team (with .project), TeamUser, Task, Label,
  TaskLabel
• Clear REST API specification.

First Implementation:

• UI Tech Stack: jquery - handlebars - brite.js - bootstrap
• Server: Lightweight REST Java, cloud portable, probably use Hibernate
  with HSQL in memory DB to minimize setup. The goal would be to just have a
  "git clone ...." "mvn clean package" "mvn jetty:run" and then, go to
  localhost:8080 and the application will work. Push it to Heroku and it will
  work on Heroku.

Jeremy,

On Tue, Nov 26, 2013 at 12:14 PM, Addy Osmani [email protected]:

Just pinging to see if there has been any further activity here or
help/suggestions on how to move forward.

@jeremychone https://github.com/jeremychone anything on your end?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4#issuecomment-29329561
.

Jeremy Chone
http://britesnow.com/
(415) 699 9912
Building Enterprise HTML5 Applications

[addyosmani]

So, it's been a year since we first started talking about TasteApp and a few months since we last had a meeting to discuss implementations. I think we need to finally make a call on what app idea we use and push on ahead with it, otherwise we face never actually getting the project off the ground :) Does anyone disagree?

Speaking with the rest of the TasteJS team we appear to be split between those that prefer the Ost.io application by Paul Miller and those that preferred the reference application Jeremy originally showed us (basically, an Angular multi-view contact manager style app). I'd love for us to summarize what we liked or disliked about both ideas and come to a decision within a week about what to move ahead with.

It's going to take time for us to 1) complete authoring a spec (though Paul has started one), 2) implement anything missing from our app of choice 3) actually get implementations written in multiple frameworks before the project can launch so it is going to take a while. The sooner we can get started the better.

cc @sindresorhus @passy @ColinEberhardt @stephenplusplus

[addyosmani]

I'll start.

Things I liked about Paul's solution:

• Checks many/most of the boxes in our original discussion
• Uses the GitHub API
• Has a featured implementation written which has been actively used
• Has a draft specification written
• Paul has been responsive and always willing to try authoring ost.io with other frameworks.

What I liked about Jeremy's

• Although ost.io is a multi-view application with proper auth, I do wonder if most developers will be writing multi-user CRUD clients which would be better served by the style of app Jeremy showed us. Things I'm thinking about: register/create account, login, perform some task across multiple views. I don't know if I'm the only one that thinks this though. We discussed GitHub as a backend for ages at the start and that wouldn't have given us a way to do 'create user' or 'register' anyway.

Other notes:

• We would probably want to self-host the backend to TasteApp based on the ost.io backend if we opted for that solution.
• I'm really interested in hear what we could do to better improve ost.io as a candidate. What is it missing? Is it the idea? Is it a set of features or views?

[jeremychone]

Just to give a quick update on the TaskManager thread.

I did the wireframe for the first screen and started the implementation. My
challenge has been to find the time in between all my client's projects.
However, I am definitely working on it as I need it to train our new
developers with our development practice and approach.

My goals (and need) for this applications are the following:

1. Show how to specify and implement a data centric Web application (UI &
   backend), with all common features such as registration, login, CRUD
   operations for master details and many-to-many relationships, and basic but
   extensible permissioning model.

2. Show how to decouple the user interface from service access allowing to
   toggle between server-less to server-backed mode by just changing one
   binding file.

3. Show how to design and build the server side (logic and database).

4. The goal would be to make it trivial to deploy it on Heroku Java /
   Postgres. (steps: create heroku app/db, "git clone ...", set db properties,
   "git push heroku-origin master", go to URL... schema will be created on
   first access, and the app will be up and running).

5. The first/reference implementation will be using
   jquery/handlebars/bootstrap/brite.js on the client and
   Java/Guice/Snow/JaSql on the server (i.e low level of abstraction in both
   cases) .

I think these goals, at least up to #3, could fit TasteJs charter pretty
weel, but the only catch is that it is very hard for me to give any sort of
timeline at this point and that the only thing I can commit is a single
implementation (on the server and UI). My estimation is to have first
version that I could share in the next couple of months.

On Fri, Jan 31, 2014 at 10:35 AM, Addy Osmani [email protected]:

I'll start.

Things I liked about Paul's solution:

• Checks many/most of the boxes in our original discussion
• Uses the GitHub API
• Has a featured implementation written which has been actively used
• Has a draft specification written
• Paul has been responsive and always willing to try authoring ost.iowith other frameworks.

What I liked about Jeremy's

• Although ost.io is a multi-view application with proper auth, I do
  wonder if most developers will be writing multi-user CRUD clients which
  would be better served by the style of app Jeremy showed us. Things I'm
  thinking about: register/create account, login, perform some task across
  multiple views. I don't know if I'm the only one that thinks this though.
  We discussed GitHub as a backend for ages at the start and that wouldn't
  have given us a way to do 'create user' or 'register' anyway.

Reply to this email directly or view it on GitHubhttps://github.com//issues/4#issuecomment-33829124
.

Jeremy Chone
http://britesnow.com/
(415) 699 9912
Building Enterprise HTML5 Applications

[paulmillr]

My estimation is to have first version that I could share in the next couple of months.

Just throwing in my point here:

1. TasteJS idea has been around for two years.
2. TasteJS community-wide discussion has been around for 10 months.
3. Our latest meeting was two months ago.

Why don't we just ship what's currently in so that frontend community may benefit from that today? After that we can iterate and make a good app we want. Be it improved ostio, taskmanager or whatever. Don't real artists ship?

[ColinEberhardt]

TL;DR; TaskManager!

My thoughts are:

ost.io

• Clearly has momentum, we could throw ourselves into writing front ends for this one immediately.
• From what I can gather, the communication with the GitHub APIs is done on the server side. This certainly makes it a more complex and interesting application.
• Is it perhaps too complex?
• This app looks like it would be a lot of fun to write!

TaskManager

• This is a more traditional CRUD style application
• Potentially simpler
• I can see this application having more of the common elements that developers have to tackle, i.e. form validation, signup workflow, straightforward CRUD.

I am very drawn to ost.io because it already has momentum, and looks like a lot of fun.

However, the more pragmatic side of me thinks that a TaskManager is likely to succeed in the long run. I think this kind of project benefits from being a little bit contrived in order that it can focus on the primary goals of the project. Also, a TaskManager is a natural extension of a todo list, which to my mind is another factor that could contribute to its success.

Finally, for people evaluating frameworks via TasteApp, we don't want them to have to put too much effort into understanding the functionality of the app itself. TodoMVC - "oh, it's a todo list", TaskManager - "oh, its a task list", ost.io - "this looks cool, what is it? Oh, its a forum of some sort. What are the topics about? Oh GitHub … how does it integrate with the projects … I must dig into the server code a little ..." - basically I think ost.io, cool though it is, could be a bit distracting.

As a project, ost.io looks great, and in order to back it, perhaps TasteJS should start using it?

Regarding your comment @jeremychone

My estimation is to have first version that I could share in the next couple of months.

I think the best way to tackle this is collaboratively, rather than have just one person sitting on the critical path.

Also, @mrpotes has expressed an interest in TasteServer - which potentially allows us to build the initial front and back end in parallel.

[jeremychone]

The more I think about this TasteJS the more I think it needs something
outthere fast to get some traction and and feedback on what people really
nee. My feeling is that ost.io might be the right first step right now.

The problem with the TaskManager, at least the one I am building to train
my new developers, is that to be useful and instructive, it has to have
level of complexity that might be above what TasteJS needs and my
implementation will focus on an approach I have been maturing over many
years (the "less-framework-more-application approach"), which might not fit
TasteJS's goal.

So, what I am planning to do, is spec and implement taskmanager the way I
need it, and share it with this project so that it can be reuse as is or
modified to fit tasteJS project.

[pkozlowski-opensource]

Hi, I'm Pawel, co-author of https://github.com/angular-app/angular-app that, I believe, was mentioned in some of the discussions. I'm chiming in here to say that:

• TasteJS is a fantastic and much needed initiative
• Would suggest moving on with a (relatively) simple task manager. My reasoning here is very similar to @ColinEberhardt - IMO this is type of CRUD application that many devs working on as part of their daily job;

I would be keen on putting some work into this initiative and share experience from working on angular-app as well as help to define functionality, non-functional requirements etc. if task-manager-like thing is chosen.

[paulmillr]

So? Bump?

@addyosmani

[ericandrewlewis]

Although I am a newcomer to this project, I'd like to call for a public meeting (IRC anyone?) to keep momentum going on this ambitious (and bound for glory) project.

Excuse me if this is the wrong place to drop this, not sure where else to 😃

[getsetbro]

I'm guessing you have moved this discussion else where but on the chance that you haven't I'll throw out another idea.
It's a blog app. The concepts are as familiar to everyone as the todo app. It could run out of github pages.
Here are 2 reasons it would be popular.
It would get used by this who want to drop their hosting package but keep their domain by pointing it to github pages; and who aren't interested in Jekyll style of building and deploying.
Since the articles would be flat html files devs could switch the framework that is serving them to test the performance difference.
A challenge would be SEO but I see they solved that how they built the angular-Docs site.