Goat

http://goatweb.org

Description

Goat makes it easier to build complex, data-heavy websites. It's written in Ruby, and aims to be a good tool for building applications in the class of, say, Facebook: data-heavy, interactive, and real-time.

Web development presents a fairly subtle set of problems:

  • Distributing application logic between the client and the server. (You usually can't put it all on the client, but it's unpleasant to wait twenty seconds for a page to refresh before you find out the value of a form field is invalid.)
  • Figuring out how to make changes without interruption -- live data migrations, and code upgrades that (ideally) don't interrupt users.
  • Varying browsers.
  • Multiple programming languages (CSS, JavaScript, HTML, server-side languages).
  • Multiple input devices (touch, mouse, keyboard).
  • May have to scale massively at short notice

Goat

Goat is page-oriented. Pages are the fundamental building block of the web. Complex data often naturally breaks down into discrete pages. In the URL, pages come with one of the most universally used and understood collaboration tools.

Figuring out how to combine presenting a significant amount of data presentation with complex user interaction is tough. It's not easy to imagine what Facebook, Wikipedia, Twitter, Gmail or Quora would look like as desktop applications -- and it's unlikely that they'd be better.

Some applications, such as spreadsheets, probably aren't a good fit for a page-based model, and these applications are not likely to be a good fit for Goat.

Goat avoids HTML templates, and replaces them with programmatic HTML generation and components: a page is composed of one or more components. Components may persist on the server, if you'd like to be able to update the client-side state of a component in real time. Components also group together the code that may be required for a single UI element: client-side JavaScript, server-side Ruby, and CSS.

Goat tries to:

  • Make it easy to build pages that don't require refreshing (i.e., live updating of data).
  • Optimize for the development cycle (all things being equal, the application that's easier to change will end up better).
  • Make writing client-side JavaScript easier. (Intelligent scoping, easy RPC.)
  • Make programmatic HTML generation easy.
  • Not be all-encompassing, but to make sensible assumptions about most parts of the web application stack.

Design decisions

  • Goat should store JS for some set of components in an external file so that JS can be cached across pages.
  • You can't have to load 2mb of JS and have a loading bar when a user visits the site for the first time. URLs should look decent.
  • Make site work well for search engines.
  • Goat doesn't try to abstract away the fact that the web is built with CSS/HTML/JavaScript.