Should we do terminal first web development?
4 comments
From a design standpoint, implementing all the business logic to be accessible from the terminal makes sense : it separates the presentation layer from the core application : it facilitates developing a command based interface : a command based interface provides a strong foundation for a robust API : it makes it clear what the interface is an interface to.
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.
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.
something like this is interesting http://napkinlaf.sourceforge.net/ I basically suggesting a terminal app as an alternative to napkin look and feel
I am fairly new on the webapp scene dominated by React and Angular.
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.
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.
um, no. if you love browsing the net with lynx, more power to you, but you're not even a rounding error in the scheme of things.
OP isn't talking about targeting a (more) minimalist browser like lynx, but about making a terminal (CLI, or TUI) interface to their (ostensible) web application.
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.
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.
I think Django Admin is another way of getting things functional first and then building UI, Web/Native for B2B apps.
something like this comes to mind: https://github.com/Yomguithereal/react-blessed