Valence roadmap
A few days ago I sent the following note to the Firefox devtools mailing list. The point was to start a discussion about where we want to take Valence (née Firefox Developer Tools Adapter) in 2015. I am reproducing the message below in an effort to broaden the audience, but I would encourage anyone who wants to participate in the discussion to post to the mailing list. However, if that sounds too intimidating (it really shouldn't!), I'm always happy to respond to comments in this blog.
Hey fellow devtoolers!
I know that eggnog and Christmas trees is all that everyone is thinking about right now, but I'd like to take a minute before we all indulge in our holiday festivities, to talk about Valence. And 2015.
2015 will be the year when Valence becomes something more than a promising experiment. It is the year that will (hopefully) see a version 1.0 that has feature-parity with Firefox, for features where the Safari/Chrome debugging protocol aligns well with the Firefox RDP. This is a proposed roadmap of how we'll get there from where we are now.
There are two main themes in this roadmap: do more and do better, and I think we should address them in reverse order. Do-things-better contains what I think we need for cutting a 1.0 release:
Improve existing features (do better)
Most of these tasks have a well understood scope, so it is just a "small" matter of time and available resources. However, another angle on the do-better theme is not to just fix known problems, but also to make them stay fixed and provide a reliable experience to the user. These tasks belong in that category and should probably be done in parallel with the above:
Improve reliability (do better for realz)
I believe the above lists should be enough for a v1.0, but there are many more things we could do to provide value to our users. Here are some obvious features we could add for a v2.0:
Expand our feature set (do more)
Not all of these tasks have been scoped or had a feasibility assessment, but there are some indications that we should be able to pull them off with some effort. These features would make the value proposition of Valence and (Firefox Developer Edition by extension) really enticing for many more developers.
But when you have all this, why stop there? The adaptability of Firefox Developer Tools that Valence affords can take us to a whole new level of debugging functionality that developers have always dreamed of:
Full-stack debugging (do way more)
Only some preliminary research has gone into these tasks, so their feasibility and effort required is still TBD. Most of the above are further out from a priority standpoint and some may well be in the pie-in-the-sky domain, but I think we should at least investigate node.js debugging in 2015. It would be an exciting engineering accomplishment and could provide a concrete value proposition for Valence and Firefox Developer Edition.
Prioritized shortlist
Given all of the above, and taking difficulty and usefulness into account, I think a reasonable, prioritized, shortlist of Valence tasks for 2015 would be the following:
Of course, depending on broader organizational priorities, this list may be too short or not much of a shortlist, for an entire year. Not to mention that planning that far ahead is usually futile and an exercise in frustration. Still, this should hopefully provide a useful base for a discussion about what we want Valence to be and how we want to go about it.
Any and all feedback is welcome (before or while you enjoy your eggnog)!
Cheers,
Panos
Hey fellow devtoolers!
I know that eggnog and Christmas trees is all that everyone is thinking about right now, but I'd like to take a minute before we all indulge in our holiday festivities, to talk about Valence. And 2015.
2015 will be the year when Valence becomes something more than a promising experiment. It is the year that will (hopefully) see a version 1.0 that has feature-parity with Firefox, for features where the Safari/Chrome debugging protocol aligns well with the Firefox RDP. This is a proposed roadmap of how we'll get there from where we are now.
There are two main themes in this roadmap: do more and do better, and I think we should address them in reverse order. Do-things-better contains what I think we need for cutting a 1.0 release:
Improve existing features (do better)
- Get the bundled ios_webkit_debug_proxy working on Windows & Linux
- Implement support for the network panel
- Handle format specifiers in console.log and friends (%s, %c, etc.)
- Display inferred names for functions
- Evaluate expressions in the selected frame when execution is paused
- Support source-mapped CSS
- Break on DOM events
- Fix some longstring-related bugs that we currently work around by using plain strings
- Fix every XXX and TODO comment in the code
- Implement every todoMethod in the actors
Most of these tasks have a well understood scope, so it is just a "small" matter of time and available resources. However, another angle on the do-better theme is not to just fix known problems, but also to make them stay fixed and provide a reliable experience to the user. These tasks belong in that category and should probably be done in parallel with the above:
Improve reliability (do better for realz)
- Deploy some testing infrastructure (probably based on ted's work)
- Port existing Firefox devtools tests and/or write new ones
- Fix stability bugs in Valence
I believe the above lists should be enough for a v1.0, but there are many more things we could do to provide value to our users. Here are some obvious features we could add for a v2.0:
Expand our feature set (do more)
- Support for the performance panel (profiler and timeline)
- Support for the storage panel
- Support for the canvas debugger
- Support for debugging embedded web views on iOS and Android, which would let us become a sort of unofficial development environment for Cordova/PhoneGap
- Support Firefox Developer Tools in the pipeline (memory profiler, worker debugger)
Not all of these tasks have been scoped or had a feasibility assessment, but there are some indications that we should be able to pull them off with some effort. These features would make the value proposition of Valence and (Firefox Developer Edition by extension) really enticing for many more developers.
But when you have all this, why stop there? The adaptability of Firefox Developer Tools that Valence affords can take us to a whole new level of debugging functionality that developers have always dreamed of:
Full-stack debugging (do way more)
- Support debugging server-side node.js applications, with console, scratchpad, debugger and profiler
- (Adding async stack support in Firefox Developer Tools would let us combine server- and client-side stack traces for debugging ecstasy)
- Research the framework ecosystems of languages that compile to JS and can run on node.js and assess the feasibility of supporting them directly via source maps
- Implement adapters for JDWP (to debug Java) and Xdebug (to debug PHP)
Only some preliminary research has gone into these tasks, so their feasibility and effort required is still TBD. Most of the above are further out from a priority standpoint and some may well be in the pie-in-the-sky domain, but I think we should at least investigate node.js debugging in 2015. It would be an exciting engineering accomplishment and could provide a concrete value proposition for Valence and Firefox Developer Edition.
Prioritized shortlist
Given all of the above, and taking difficulty and usefulness into account, I think a reasonable, prioritized, shortlist of Valence tasks for 2015 would be the following:
- Get the bundled ios_webkit_debug_proxy working on Windows & Linux
- Display inferred names for functions
- Implement support for the network panel
- Fix stability bugs in Valence
- Deploy some testing infrastructure
- Port existing Firefox devtools tests and/or write new ones
- Support debugging server-side node.js applications
- Support for debugging embedded web views on iOS and Android
- Handle format specifiers in console.log and friends (%s, %c, etc.)
- Evaluate expressions in the selected frame when execution is paused
- Support source-mapped CSS
- Break on DOM events
Of course, depending on broader organizational priorities, this list may be too short or not much of a shortlist, for an entire year. Not to mention that planning that far ahead is usually futile and an exercise in frustration. Still, this should hopefully provide a useful base for a discussion about what we want Valence to be and how we want to go about it.
Any and all feedback is welcome (before or while you enjoy your eggnog)!
Cheers,
Panos
No comments:
Post a Comment