2.0 goals

JulianLeviston edited this page May 2, 2015 · 10 revisions
Clone this wiki locally

These haven't actually been formally discussed yet. Just some random brainstorm.




Widgets are actually one of the slowest parts of Yesod, and there is probably a lot of potential to optimize the code. However, this can only take us so far - we need an easy way to cache widget content in memory rather than having to continually regenerate it. This entire issue revolves around smartly recognizing when the cache needs to expire. Hopefully Haskell's purity can make cache expiring a little easier.

render smaller portions of a page

  • pjax integration. PJAX uses HTML5 pushState history. This avoids needing to render a layout.


  • General benchmarking & profiling. We have really only benchmarked requests/second for a simple response and worked on making that path is well optimized.

  • sockjs mentioned below makes communicating with the client side faster. We can hold open a connection for every client to send them updates and potentially to reduce tcp slow start latency.

Better client side tools

1.0 is a great server-side framework. We have the basics for help with the client side with widgets and support for organizing and minifying javascript/css, but we need to take this further.

  • integration with responsive design principles. We are already getting some integration with Bootstrap, it seems like a decent default. Have the ability to automatically serve properly sized images (maybe pre-cache different sizes, maybe cache different sizes after generating them). If we go the Bootstrap route we probably need integration with LESS

  • wai-sockjs for a backwards-compatible, high-level websockets interface.

  • integration with Javascript. This could mean writing JS in Haskell. It could mean automatically generating backbone.js model code, automatically updating view code with knockout.js, or FRP JS code with flapjax.

  • Widgets are a great idea, but their syntax could be improved, and the idea really need to go ALL the way right up to the client... we could use React here (because its principles are awesome). In particular, we should take some advice from the Clojurescript wrapper around React called Reagent works... (https://github.com/reagent-project/reagent) (especially with respect to FigWheel, the live-code-reloading project in Clojurescript): https://github.com/bhauman/lein-figwheel

  • Reagent "Components" (similar to our widgets, but only the hamlet/julius portion) are simply native Clojurescript data with lazily evaluated functions embedded in them (vectors in their terminology, Lists in ours).

  • Also, purescript integration with React is worth considering. https://github.com/purescript-contrib/purescript-react

More Extensibility

  • A more official library/plugin API
  • Any other ideas?

Easy deployment

See Wish list