Development Roadmap

Bryan Powell edited this page Jul 29, 2017 · 41 revisions
Clone this wiki locally

This is the public roadmap for Pakyow development. Everything that the core team has decided to include in the framework will be listed here. You can participate in early discussions on the #code channel in the forums. Consider this a living document that will evolve as we work towards the next release.

Next Release: 1.0

We're currently hard at work on the official 1.0 release. Get excited! 🐧

Note that we'll be dropping support for all but the latest Ruby release (so probably >= 2.4).

Release Goals

1. Pakyow should offer a great out of the box experience for people new to web dev.

We aren't trying to build a better version of some other framework. Instead, we focus on solving new and interesting problems that people encounter building for the modern web. Providing advanced features in a beginner-friendly lets us help make the web accessible to the next generation of developers.

Some related goals:

  • Reduce the time involved to go from new project to working feature
  • Have great user-facing docs along with other learning tools (e.g. screencasts)
  • Improve error messages to explain not only what went wrong, but also how to fix the problem

2. Pakyow's codebase should be well-architected, well-tested, and well-documented.

Features are often implemented as experiments that evolve quite a bit from their original implementation. We've learned a lot through this process, but it's also created quite a bit of technical debt. We want revisit the implementation of current features and rearchitect them based on how we now know they should work.

Here are some more specific aspects to this effort:

  • Simplify the architecture of core features
  • Write comprehensive inline documentation for the public api
  • Create proper unit tests, along with feature tests for each documented feature

3. Pakyow should be as performant as possible.

Our approach to routing and views makes the framework quite performant. Properly implemented, performance should only improve in terms of response times and memory usage. It's important to note that we are far less interested in squeezing out every possible bit of performance and more interested in simply doing less work. Call it sane performance.

We'd like to hit the following metrics:

  • Boot a moderately sized application in less than 250ms
  • Respond to a request in less than 1ms, including db access and view render
  • Reduce the memory footprint to less than 50MB per process

Keep in mind that metrics depend a lot context and honestly don't mean that much.

Refactors & Changes



  • Shared Partials
    discussion | Related Issues: #225, #226
  • Optimizations
    • StringDoc Evaluation
    • Parity Between Attrs / UIAttrs
    • Replace ViewComposer


  • WebSocket Delivery Guarantees
    Related Issues: #237


  • Deprecate Mutators / Mutations
    • replaced with presenters / data objects

New Features

  • Data Layer
  • Asset Pipeline
  • Security By Default


  • Backend View Objects
  • View Query Language
  • Emoji / Icons 😎
  • View Formatters
  • Better Form Setup
    • nested resources
  • Scoped View Versions


  • Tests / Docs
  • NPM Release


  • Official Release / Docs


  • Feature Organization
    discussion | Related Issues: #223
  • Plugins
  • Themes
  • Workers
  • Internationalization
  • Reflection


  • Deferred Socket Messaging
    Related Issues: #238
  • WebSocket File Uploads


  • Bidirectional Component Messaging