Design things to be simple, but no simpler.

Simple is easy to understand and then only expand when necessary. Sometimes that’s with a generalized abstraction that can easily be used; other times, it’s a simple rewrite or refactor because there’s so little code that needs to be changed.

  1. Simply a text file?
  2. +custom HTML?
  3. +custom CSS?
  4. +plain Javascript?
  5. A simple script?
  6. Embedded client-side script code?
  7. A server?
  8. +cloud computing?
  9. A framework?
  10. A public web API?
  11. Full, client-side single-page app?
  12. State management vs stateless
  13. Distributed vs centralized
  14. Memory management
  15. Static typing
  16. Tests!?
  17. A language many people know vs one few do, or can understand and wield

Most things that have existed existed with old technology. Is this new creation that novel that it requires new technology?

Do you really need an API if there are no public clients?

Does a dynamic single-page app framework need to be used for everything or just a few parts?

Are you letting the sexiness of something new and shiny outweight the needs of the business domain? Something that pays the bills?

Be efficient and spend some time on the hammock to think about what the real requirements are, even with a bit of extensibility, before expending a bunch of money and effort. You’ll be leaner for it and maybe self-sustainable too.

There’s something to be said for Facebook’s philosophy on never forcing tools on developers, but instead to make it so easy for them to use, that they migrate. E.g., React, JSX, Flow, Reason, Hack, etc.

But that can become a Frankenstein monster to outsiders eventually. E.g., JVM interoperability, multi-paradigm languages. Perhaps these new things offer good abilities, but do not enforce one successful convention that everyone gravitates towards. The lowest common denominator of worst practices, if allowed, can and will happen.

Related to maybe only moving a little ahead of the herd of programming languages.

References