Originally posted on Wright Turn

For months now I have been thinking about the design of a web front end for a collection services. There are *SO MANY CHOICES* out there that it’s sometimes difficult to turn off the incoming streams and make a choice. The exercise of thinking about a design often starts with thinking about frameworks. Code frameworks, primarily written for Javascript with a few for Python, do a bunch of work for you. But there’s a price. Frameworks are often large and regularly force you to implement things in one and only one way. Frameworks are not compatible with one another, so a choice locks you into a heavy investment. Should we use NodeJS? React? Flask? The list is seemingly endless.

Wright Turn

For months now I have been thinking about the design of a web front end for a collection services. There are *SO MANY CHOICES* out there that it’s sometimes difficult to turn off the incoming streams and make a choice. The exercise of thinking about a design often starts with thinking about frameworks. Code frameworks, primarily written for Javascript with a few for Python, do a bunch of work for you. But there’s a price. Frameworks are often large and regularly force you to implement things in one and only one way. Frameworks are not compatible with one another, so a choice locks you into a heavy investment. Should we use NodeJS? React? Flask? The list is seemingly endless.

Yesterday, I stumbled upon a podcast that takes an alternate approach. The guest on the show, Chris Ferdinandi, asserts that the conversation need not start with a framework. He…

View original post 131 more words