something like this comes to mind: https://github.com/Yomguithereal/react-blessed
However, I think there are probably iterations on very minimal browser interfaces that can be used to put the app in front of people very early on to get user feedback about the core functionality and to test out the abstractions...or to put it another way, don't build everything and then see if some people might use it.
Relevant: http://www.themacro.com/articles/2016/01/minimum-viable-prod...
Good luck.
I can see some valid use cases for the blessed library where there is no way to get a graphical frontend running.
But aiming to build for terminal first?
Even if you do, it might be better to have two separate projects, or one core library implemented by both frontend subproject.
Having one big app covering it all, might be an overkill. I would ask myself the question "Will it be used on a terminal" first. And if the answer is "Yes, it will be used quite frequently on a terminal." then go terminal first.
Also, the very first question should be. Should I use X and Y languages, frameworks, etc...?
You might find better tools for certain problems then react and blessed to have something nice in a terminal.
That is, they'd create a wrapper application (the reactor-blessed example suggests using js) that gives them access to the key components of the application and a way to test it out independent of the (eventual) design goals and dealing with browser compatibility. Really, the suggestion is that they'd focus on creating an http-based API, and use the terminal application as a way to develop/test it. It's a sound approach, as another commenter pointed out, as it forces a stronger separation between presentation and business logic.